この記事は技術的な共有のみを目的としており、投資アドバイスを構成するものではありません。
BTCにも独自のスマートコントラクトが存在するのでしょうか?
最近のビットコインエコシステムでは、フラクタルBTCが複数のテストネットを経て、ついに9月にメインネットを立ち上げました。 Fractal の大きな特徴は「スマート コントラクト」を実現できることであり、メインネットの開始とほぼ同時に、新しいトークン プロトコル CAT 20 が開始されました。 CAT 20 にはどのような優れた技術が備わっていますか?何を学べるでしょうか？
フラクタルビットコイン
CAT 20 を理解する前に、Fractal Bitcoin の関係を簡単に理解する必要があります。CAT 20 プロトコルは Fractal Bitcoin に展開されています。
フラクタル ビットコインとしても知られるフラクタル ビットコインは、BTC と完全に互換性のある「第 2 層」ネットワークです。 BTCと比べてブロック確認時間が速く、わずか1分しかかかりません。その基本原理は単純にその名前が示すように、各チェーンがトランザクションを処理できるノードが増えるほど、当然高速になります。ただし、異なるチェーンがどのように通信するかなどの具体的な詳細はまだ明らかになっておらず、参照用の対応する公式の技術文書もありません。
第 2 層のチェーントランザクションだけが高速であれば、興奮する意味がないようです。しかし、セキュリティ上の理由からBTCによってずっと前に放棄されたFractalのOP_CATのアクティブ化により、Fractal Bitcoinの機能がより高いレベルに達し、これによりOP_CATがBTCにスマートコントラクト機能を提供できるようになると言う人もいます。もっと想像力の余地があります。
さて、誰かが Fractal Bitcoin に ERC 20 のようなプロトコルを実装しました。
OP_CAT が放棄された理由と、Fractal Bitcoin で使用できる理由については、後で説明します。ここでは CAT 20 に焦点を当てます。
CAT プロトコル 次の内容については、ホワイト ペーパーを参照してください。 CAT プロトコル (https://catprotocol.org/)
および github リポジトリ: GitHub - CATProtocol/cat-token-box: CAT プロトコルを実装するパッケージのモノリポジトリ (https://github.com/CATProtocol/cat-token-box)
基礎となる OP_CAT サポートにより、対応するプロトコルである CAT プロトコルが間もなく利用可能になります。現在、実際に実行されているプロトコルは CAT 20 プロトコルで、対応するパネルが Unisat に追加されています: https://explorer.unisat.io/fractal-mainnet/cat20。
CAT 20 という名前を見たら誰もが反応できるはずです。ERC 20 にもっと似ているはずです。成熟した ERC 20 プロトコルと比較して、誰にとってもトークンを導入するのは非常に便利です。CAT 20 は ERC 20 と同様のライフサイクルをどのように実装しますか?
展開する
導入前に、ユーザーはウォレット アドレスとトークンに関する基本情報を指定する必要があります。トークンに関する基本情報は、ERC 20 の情報と同様です。
いくつかの違いがあります。CAT 20 では、造幣局ごとにプレマイニングおよび数量制限を設定できます。もちろん、ERC 20 は、契約機能を通じてこれらの機能を実現することもできます。
デプロイメントフェーズ中に、2 つのトランザクションが開始されます。これは、「コミット」と「公開」の 2 つのフェーズとして考えることができます。公式図を引用すると、展開段階は次のとおりです。
「コミット」ステージでは、トークンの名前やシンボルなど、トークンの基本情報がトランザクションの出力スクリプトに書き込まれます。 「コミット」フェーズで開始されたトランザクションの hashId は、他のトークンを区別するためのトークンのシンボルとして使用されます。
このトランザクション「 bc 1 pucq...ashx 」の utxo が commit に相当することがわかります。次に、「 bc 1 pszp...rehc 4 」を指す残りの 2 つのトランザクションが存在します。1 つ目は次の「reveal」ステージのガス料金の支払いに使用され、もう 1 つは変更です。
「reveal」ステージでは、前のコミットステージの最初の 2 つの出力に対応する 2 つの utxo 入力があることがわかります。このトランザクションは最初に OP_RETURN を出力し、そこに CAT 20 の初期状態のハッシュが保存されます。その後、Minter が出力されます。これは後続の Mint プロセスで重要な役割を果たし、Mint プロセスの状態変化を維持するために使用されます。
Deploy プロセス全体を振り返ると、「commit」と「reveal」は、ブロックチェーンで一般的に使用される送信と公開の 2 つのステップに従い、プロジェクトの一部のデータは「reveal」のみにデプロイされます。ステージが明らかになります。
として
Mint Token を初めて見ると、トランザクションは次のようになります。
上の図からもわかるように、Mint のプロセスには次のような特徴があります。
mint の入力は minter であり、デプロイ中に最初に生成されます。
各 minter は入力として 1 つだけの minter を持ち、出力として任意の数の minter を持ちます (少し問題があります)。
各ミントにはトークンが 1 つだけあります (少し問題があります)
出力の順序は必須です。minter の後にトークンが続く必要があります
Mint プロセスを知ると、Mint プロセス全体を興味深いものにするいくつかの特別な状況を実際に発見することができます。
たとえば、minter は、mint トランザクションの出力として、1、複数、または 0 になる可能性があります。 Mint を毎回 1 に設定すると、ネットワーク全体で使用できる minter の数が変更されず (1)、Mint が混雑するため、これを回避するには全員がこの minter を取得する必要があります。この場合、毎回出力される minter の数を 1 より大きく設定して、mint 後にさらに多くの minter を使用できるようにする必要があります。
ただし、minter の出力が追加されるたびに、追加の utxo を支払う必要があることを意味します。経済的理由から、minter を 0 に設定しようとする人が増え、必然的に minter デフレが発生し、一部の人々が寄付をして支払う必要があります。自発的に余分なミンター。
V2 バージョンでは、デフォルトで 2 つのミンターが生成され、2 つのミンターのステータスは可能な限り似たものになります。
トランザクションの構造化
友人の中には、なぜ minter の utxo を使用してトランザクションを構築できるのかという問題を発見した人もいるかもしれません。この問題を理解するには、「契約」のソース コードを分析する必要があります。
1、utxo を表示する
まず、公開プロセス中にトランザクションを分析すると、前のトランザクションの出力コミットが入力として使用されていることがわかります。なぜ私たちのアドレスではない utxo を取得してトランザクションの入力を構築できるのでしょうか?
常識によれば、秘密鍵は公開鍵に対応し、公開鍵によってアドレスが導出されます。入力された utxo が有効かどうかを検証する場合、通常は、公開キーで復号化された署名が元のトランザクションと一致するかどうかを比較することによって判断されます。ロジックのこの部分はビットコイン スクリプトで書かれています。したがって、スクリプトのロジックを巧みに書き換えることで、スクリプトに記述された公開鍵と秘密鍵のペアが自分のアドレスに属するようになり、2 つの異なるアドレスの utxo を制御できるようになります。
ソース コードを見ると、何が起こったのかがわかります。
ここで別の問題が発生します。つまり、秘密キーは公開キーに対応するのに、生成されたコミット アドレスが私たちのアドレスと異なるのはなぜでしょうか。ここでソースコードから見ることができます
言い換えれば、私たちの秘密鍵は、P 2 TR アドレスの特徴でもある ISSUE_PUBKEY に従って公開鍵を調整します。
2、ミンターウーソー
公開プロセス中、入力として異なる utxo を使用しますが、実際には暗号化キーは同じであり、デプロイヤーの秘密キーです。しかし、minter 段階では、誰もがこれらの utxo を入力として使用できます。これはどのように行われるのでしょうか?
この部分が先ほどのOP_CATの能力、つまり各minterがスマートコントラクトの能力なのでしょう。ただし、現時点ではこの部分のソースコードは公開されておらず、具体的な実装はまだ分かりません。
トランザクションステータス (V2)
minter では状態も保存されます。この状態は 2 つの場所に存在します。1 つはトランザクション出力の OP_RETURN にあり、もう 1 つはスマート コントラクト (前述の Minter と Token) に保存されます。
OP_RETURN に格納されるのは現在のトランザクション出力ステータスのハッシュであり、トークンの残りの Mint 時間はコントラクトに格納されます。各ミントの後に、新しく生成されたミンターのミントの数は、残りのミントの数を 2 で割ったものに等しくなります。図で表すと次のようになります。
ゲーム終了時点でミンター全員の残りは0。
元の図に戻ると、Minter がスマート コントラクトであることに加えて、生成された Token もスマート コントラクト、つまり CAT 20 です。 CAT 20 には、数量とトークンの所有者のアドレスという 2 つの基本的な状態があります。以前の BRC 20 や碑文とは異なり、CAT 20 は住所の UTXO 上にないことがわかります。
移行
転送するときは、トランザクション内の入力トークンと出力トークンの数が一致している必要があります。もちろん、異なるトークンの入力番号と出力番号が一貫している限り、同じトランザクション内に複数の異なるトークンが存在する可能性があります。
やけど
トークンを焼きたい場合は、トークンを通常のアドレスに転送するだけです。
要約する
すべての操作はユーザー自身によって構築されており、非常に柔軟であるため、コントラクト部分で多くの検証ロジックを実行する必要があることがわかります。これまでに明らかになった脆弱性の一部は、検証ロジックの不注意によるものでもあります。
このような設計には、次のような利点があります。
すべてのトークンの保有状況を知りたい場合は、トークンのutxoを確認するだけでよく、検索を続ける必要はありません。
mintの現在の状況を確認したい場合は、OP_RETURNでcatとのトランザクションを検索できます。
ZANは敷居のない水を手に入れるためにここにいます！
ヒント: Ethereum エコシステムでの Web3 プロジェクトの体験とテストをサポートするために、24 時間ごとに 0.01 ETH の無料テストネット トークンを受け取ることができます: https://zan.top/faucet?chInfo=ch_WZ。
より多くのパブリック チェーンが間もなくサポートされる予定です ~
この記事は ZAN チーム (X アカウント @zan_team) の Yeezo (X アカウント @GaoYeezo 75065) によって書かれました。