ラビトブをプレイするすべてのプロセスで何が起こるのでしょうか? 長い警告、暗号化とビットコイン取引に関する一定の知識が必要です Labitbu は、今日午前 2 時から始まるビットコイン メインネットの小さな全体像であり、以前の碑文や準碑文プロトコルとは異なり、負荷情報を保存するために Taproot プロトコルに依存しています このプロジェクトは、今年の@PlebFiハッカソンの2番目の優勝者である@stutxoによって開発され、ハッカソンにはビットコイン WizardとOrdinalsの開発者が参加しているようで、まだ一定のゴールド含有量があります GitHubリポジトリ: ウェブサイトをキャストする際には、次の 3 つの手順があります。 1. ウォレットを接続し、ランダムなラビットを生成します。 2. bc1p で始まる P2TR アドレスに転送すると、Web サイトはデフォルトで 10,000 sats をこのアドレスに転送します。 3. 鋳造を完了し、ウォレットの公開鍵に対応する bc1p アドレスを入力ボックスに入力し、鋳造トランザクションをチェーンに送信します。 まず、ウォレットに接続して bc1p ウォレットの公開鍵を取得し、公開鍵に基づいて Labitbu を生成します。 リポジトリのjsonファイルによると、各labitbuに8つのスタイルがあり、最大の違いは色であることがわかります。 しかし、それが 10k NFT コレクションの場合、色は多くのラビットを区別するのに十分ではないようですか? 各 labitbu はウォレットの公開鍵に基づいて生成されるため、理論的には各ウォレットによって鋳造されるすべての labitbu は同じスタイルになります (ただし、早朝の実際の鋳造中にウォレットが異なるスタイルで鋳造される場合がありますが、これは一部の省略や朝の失神😇が原因である可能性があります) 前のステップの後、生成された labitbu はバイト データ ペイロードに変換され、Web ページはこのペイロードに基づいて制御ブロックを構築します。 ここではビルドと呼ばれ、実際の制御ブロックは[制御バイト] + [インデックス公開鍵] + [イメージペイロード]です。 実際の taproot スクリプトでは、制御ブロックは [制御バイト] + [内部公開鍵] + [マークル パス] であり、labitbu は画像ペイロードをマークル パスとして直接使用します。 Taproot Control ブロック関連コンテンツ: ペイロードをマークル パスとして使用し、ウォレットの公開鍵をロック スクリプトとして使用した後、Web ページ上の BC1P アドレスである P2TR アドレスを生成でき、このウォレットに BTC を送信するプロセスは、碑文プロトコルのコミットと見なすことができます。 最後に、bc1p アドレスとウォレットを入力して、最終的な鋳造操作を完了する必要があります。 このプロセスでは、画像ペイロードを制御ブロックとしてフロントのロックが解除され、公開鍵ロック スクリプトが引き換えスクリプトの出力として使用され、ウォレットを使用して最終トランザクションに署名して送信します。 上記は labitbu プロトコルをキャストする過程における技術的な内容であり、タップルート スクリプトの構築とアドレスの生成の技術的な詳細は書かれていませんので、興味のある友人は情報をチェックして見ることができます labitbu の鋳造プロセスは碑文に似ていますが、碑文の利点は、鋳造プロセスのコミットがリレーとして新しいアドレスを生成する必要がなく、鋳造プロセス全体を 1 つのウォレットで完了できることであり、ある程度便利です。 ただし、制御ブロックのサイズが4kbであるという制限があり、保存できる画像ロードのサイズが制限されます。 GitHub では、dev はインデックス作成を容易にするために鋳造に固定の内部公開鍵を使用しているため、dev もインデックス作成の次のステップを実行する予定であり、トランザクションに実装できるかどうかは待つしかないことがわかります。

このとき、鋳造量は 10k を超える必要があり、過去の経験によれば、小さな画像コレクションの数は通常 10k であるため、今すぐ鋳造を続けることはお勧めしません