CAT20：Fractal BTC上のトークンプロトコル

この記事は技術の共有のためであり、投資助言を提供するものではありません。

BTC 上也要有自己的スマートコントラクト了？

最近、BTCエコシステムでは、Fractal BTCが複数回のテストネットを経験した後、ついに9月にメインネットに上がりました。Fractalの最大の特徴は「スマートコントラクト」の機能を持っていることであり、メインネットのリリースとほぼ同時に、新しいトークンプロトコルCAT 20がリリースされました。CAT 20にはどのような技術的な巧妙な設計があり、私たちは何を学ぶことができるのでしょうか？

フラクタルビットコイン

CAT 20を理解する前に、まずFractal Bitcoinを簡単に理解する必要があります。彼らの関係はERC 20とETHの関係と同様であり、CAT 20プロトコルはFractal Bitcoin上に展開されています。

フラクタルビットコイン、またはフラクタルBTCとも呼ばれ、BTCに完全互換性のある「第2層」ネットワークです。BTCと比べて、ブロックの確認時間が1分しかかりません。基本的な原理はその名前が示すとおり単純で、BTCネットワークを複製し、各チェーンが取引を処理し、処理できるノードが多くなると速度も自然に速くなります。ただし、異なるチェーン間の具体的な通信方法など、現時点では明確ではありません。また公式の参考技術文書もありません。

レイヤー 2 トランザクションが高速であるというだけなら、エキサイティングなポイントはないように思えます。しかし、フラクタルでは以前からセキュリティ上の理由からBTCが非推奨となっていたオペレーションコードOP_CATを有効にすることでフラクタルビットコインの能力が高レベルに引き上げられており、OP_CATはBTCにスマートコントラクトを持たせることができるため、空想の余地が広がるという人もいます。

現在、Fractal BitcoinでERC 20に類似したプロトコルが実装されています。

OP_CATが非推奨になった理由と、フラクタルビットコインで使用できる理由については、後で拡張できます。

CATプロトコル以下内容参考ホワイトペーパー：Introduction | CATプロトコル ()

およびgithubリポジトリ：GitHub - CATProtocol/cat-token-box：CATプロトコルを実装するパッケージのためのモノレポ（）。

OP_CATのサポートを利用することで、すぐに対応するプロトコルであるCAT Protocolが利用可能になりました。現在、実際に実行されているプロトコルの1つはCAT 20プロトコルであり、Unisatにも対応するパネルが追加されました：

CAT 20 の名前を見たら、多くの人が ERC 20 に似ていることに気付くはずです。成熟した ERC 20 プロトコルに比べ、Token を展開することは非常に簡単になりました。CAT 20 は ERC 20 と同様のライフサイクルをどのように実現しているのでしょうか。

デプロイ

部署の前に、ユーザーは自分のウォレットアドレスとトークンの基本情報を指定する必要があります。トークンの基本情報は ERC 20 と類似しています：

CAT20：Fractal BTC上的代币协议

いくつかの違いがあります。 CAT 20 では、予め採掘とミントの数量制限を設定することができます。もちろん、ERC 20 でも契約の機能を利用してこれらの機能を実現することができます。

デプロイメントフェーズでは、2つのトランザクションが開始され、「 commit 」および「 reveal 」の2つの段階と見なすことができます。公式の図を引用すると、展開段階は次のようになります：

CAT20：Fractal BTC上的代币协议

「commit」段階では、トークンの基本情報（トークン名、シンボルなど）が取引の出力スクリプトに書き込まれます。「commit」段階で開始された取引のhashIdは、他のトークンと区別するためにそのトークンを識別するためのものとして使用されます。

CAT20：Fractal BTC上的代币协议

このトランザクション「bc 1 pucq...ashx」は、UTXOがcommitに対応していることがわかります。そして、残りの2つのトランザクションは、「bc 1 pszp...rehc 4」を指しています。最初のトランザクションは「reveal」ステージのガス料金支払いに使用され、もう一方はお釣りです。

「reveal」フェーズでは、2つのutxo入力が見られ、これは以前のcommitフェーズの最初の2つの出力に対応しています。このトランザクションはまずOP_RETURNを出力し、その中にCAT 20の初期状態のハッシュを保存します。その後、Minterが出力され、これは後続のMintプロセスで重要な役割を果たし、Mintプロセスの状態変化を維持するために使用されます。

CAT20：Fractal BTC上的代币协议

Deployのプロセス全体を振り返ると、「commit」と「reveal」は、ブロックオンチェーンの一般的な提出と公開の2つの手順に従っています。これは、プロジェクトを展開するための一般的な方法です。一部のデータは「reveal」の段階でのみ公開されます。

ミント

Mint Tokenを見てみましょう。取引は次のようになります。

CAT20：Fractal BTC上的代币协议

図のように、Mintのプロセスには次の特徴があります。

mintの入力はminterであり、最初はデプロイ時に生成されます。 *すべてのミントには、1つのミンターのみが入力としてあり、複数のミンターが出力としてあります（少し問題があります）
すべてのミントには1つだけTOKENがあります（少し問題があります）
出力の順序は重要であり、minter の後ろには必ず token が来る必要があります

Mintのプロセスを知っていると、特殊な状況があることに気付くことができます。それはMintプロセスを面白くすることができます。

例えば、mint取引の出力としてのminterは、1つ、複数の場合も、0の場合もあります。Mintを実行するたびに、1つに設定すると、使用可能なminterの数が変わらず（1つ）になり、Mintが混雑することになります。皆がこのminterを奪い合う必要があります。このような状況を避けるために、出力されるminterの数を1より大きく設定する必要があります。これにより、minterを使用できる人数が増えていきます。

ただし、minter を追加するたびに、追加の UTXO を支払わなければならないため、経済的な観点から、より多くの人々が minter を0に設定することに喜んでいます。これにより、minter は必然的に通貨の価値が下がりますので、追加の minter を自発的に支払う人々が必要です。

V2バージョンでは、デフォルトで2つのMinterが生成され、そして2つのMinterの状態ができるだけ似ています。

トランザクションの構築

おそらく、いくつかの友達が1つの問題に気付いたかもしれませんが、それはなぜminterのutxoを使用して取引を構築できるのかということですか？この問題を理解するには、「契約」のソースコードを分析する必要があります。

1、utxoを明らかにする

まず、revealプロセス中の取引を分析しましたが、前の取引の出力コミットを入力として使用していることがわかりました。なぜ私たちのアドレスでないutxoを取引の入力として使用できるのでしょうか？

通常、秘密鍵には公開鍵が対応しており、公開鍵からアドレスが生成されます。UTXOの入力が有効かどうかを検証する際、一般的には公開鍵で署名を解読し、元のトランザクションと一致するかどうかを確認します。この部分の論理はBTCスクリプトに記述されています。したがって、スクリプトの論理を巧みに変更し、スクリプトに記述された公開鍵と秘密鍵が私たち自身のアドレスのものであれば、異なる2つのアドレスのUTXOを制御することができます。

ソースコードを見れば、何が起こったかがわかります。

CAT20：Fractal BTC上的代币协议

ここにはもう1つ問題があります。それは1つの秘密鍵に1つの公開鍵が対応しているということですが、なぜ生成されたcommitアドレスが私たちのアドレスと異なるのでしょうか？ソースコードから確認できます。

CAT20：Fractal BTC上的代币协议

つまり、私たちの秘密鍵は ISSUE_PUBKEY に基づいて公開鍵を調整し、これが P 2 TR アドレスの特徴の一つです。

2、ミンターUTXO

revealのプロセスでは、異なるutxoを入力として使用しますが、実際には暗号化された秘密鍵は同じ鍵です。つまり、デプロイヤーの秘密鍵です。しかし、ミンター段階では、誰でもこれらのutxoを入力として使用することができます。これはどのように実現されているのでしょうか？

この部分は、OP_CAT機能、つまりスマートコントラクト機能として言及されたものだと推測します。つまり、各マイントランザクションはスマートコントラクトです。ただし、現時点ではこの部分のソースコードは公開されていないため、具体的な実装方法はわかりません。

取引のステータス（V2）

minterには状態も残っています。この状態は2つの場所に存在します：1つは取引の出力にあるOP_RETURNであり、もう1つはスマートコントラクトに格納されており、つまり上記で言及されているMinterおよびTokenです。

OP_RETURNには、現在のトランザクション出力の状態のハッシュが格納され、契約ではTokenの残りのMint回数が格納されます。Mint後、新しく生成されるMinterのmint数は残りのmint可能数を2で割ったものになります。図で表すと：

CAT20：Fractal BTC上的代币协议

最後に打ち終わったとき、すべてのMinterの残量は0になります。

最初の図に戻って、Minterがスマートコントラクトであること以外に、生成されたトークンもスマートコントラクトであり、CAT 20であることがわかります。CAT 20には数量とトークンの所有者のアドレスの2つの基本的な状態があります。以前のBRC 20やインスクリプションとは異なり、CAT 20はアドレスのUTXOにはありません。