技術共有：CAT20 - フラクタルBTC上のトークン・プロトコル

以下のことがわかります。この取引「 bc1pucq.....ashx  "このutxoはコミットに対応し、残りの2つは" bc1pszp....rehc4 "を指しています。.rehc4  "トランザクションを指し、1つは次の" reveal  "フェーズのガス料金の支払いに使用され、もう1つは変更である。

「 reveal 」フェーズでは、前のコミットフェーズの最初の2つの出力に対応する2つのutxo入力があることがわかります。このトランザクションはまずOP_RETURNを出力し、その中にCAT20の初期状態のハッシュが格納され、次にMinterを出力する。Minterはその後のMintプロセスで重要な役割を果たし、Mintプロセスの状態変化を維持するために使用される。

Deployプロセス全体を振り返ってみると、「commit」は最初にできることです。Deployプロセス全体の「commit 」と「 reveal 」は、ブロックチェーンで一般的に使用されているcommitとrevealの2つのステップに従っており、プロジェクトをデプロイする比較的一般的な方法で、プロジェクトのデータの一部は「 reveal 」の段階でのみ公開されます。

Mint

まずは、トランザクションがこのようになるときのMintトークンを見てみましょう。

上の画像では、Mintトークンの取引が以下のようになっています。を見ると、ミントのプロセスには次のような特徴があることがわかる。

• ミントへの入力はミンターで、これは最初にデプロイによって生成されます。

• すべてのミントは入力として1つだけのミンターを持ち、出力として任意の数のミンターを持ちます。mint has one and only one token (a bit of problem)

• 出力の順番が必要で、minterの後にtokenが続かなければならない

ミントプロセスを知ることで、ミントプロセス全体を面白くするような特殊なケースを見つけることができます。

例えば、ミントトランザクションの出力であるミントは、1、多数、あるいは0になることもあります。すべてのミントを1に設定すると、ネットワーク全体で使用できるミントの数は同じ（1）のままとなり、ミントは混雑し、誰もがミントをつかむ必要があります。このような状況を避けるためには、毎回ミントの数を1より多く設定し、ミントの後、使用できるミントの数がますます多くなるようにする必要があります。造幣局以降、ミンターは誰でも使えるようになる。

しかし、ミンターが1つ増えるごとに、追加のutxoを支払う必要があり、経済的な理由から、ミンターを0にして喜ぶ人が増えるので、必然的にミンターがデフレになり、余分なミンターのために自発的にお金を払う人の献身が必要になります。

V2では、デフォルトで2つのミンターが生成され、2つのミンターの状態は可能な限り似ています。

トランザクションの構築

問題に気づいた人もいるかもしれません。これを理解するには、「コントラクト」のソースコードを分析する必要があります。

1.utxoを明らかにする

まず、明らかにするプロセスのトランザクションを分析すると、前のトランザクションであるcommitの出力を入力として使用していることがわかります。commitを入力として使用している。なぜ私たちのアドレスではないutxoをトランザクションの入力とすることが可能なのでしょうか。

常識的に考えて、秘密鍵は公開鍵に対応し、公開鍵はアドレスを導き出す。入力されたutxoの有効性を検証する場合、一般的には公開鍵で復号化された署名が元のトランザクションと一致するかどうかを比較することで判断される。このロジックの一部はビットコインのスクリプトに書かれている。そのため、スクリプトのロジックを巧妙に書き換えて、自分のアドレスの公開鍵と秘密鍵のペアを含めることで、2つの異なるアドレスのutxoを制御することができる。

ソースコードを見ると、何が起こっているのかがわかります：

ここでもう一つ疑問があります。秘密鍵は公開鍵に対応しているのに、なぜ生成されるコミットアドレスが私たちのものと異なるのでしょうか？以下はソースコードです

つまり、私たちの秘密鍵は、P2TRアドレスの特徴であるISSUE_PUBKEYに基づいて公開鍵を調整します。

2.minterのutxo

公開処理では、異なるutxoを入力として使用しますが、実際には暗号化キーは同じです！これは配備者の秘密鍵である。しかし採掘段階では、誰もがこれらのutxoを入力として使うことができます。

これは部分的には、先ほどお話ししたOP_CATの機能であり、スマートコントラクトの機能です。ただし、この部分のソースコードは公開されていないので、実装がどうなっているかはわかりません。

トランザクションの状態（V2）

マイナーにも状態があります。

OP_RETURNにはトランザクション出力の現在の状態のハッシュが格納され、コントラクトにはトークンの残りのMintが格納される。契約書にはトークンの残り Mint 数が格納される。各Mintの後、新しく生成されたMinterのMint数は、残りのMint数を2で割った数に等しくなる。

元の図に戻ると、ミンターがスマート・コントラクトであることに加えて、生成されるトークンもスマート・コントラクトであるCAT20であり、これには2つの基本状態があります。CAT20には2つの基本的な状態があります。トークンの番号と、トークンが属する人のアドレスです。以前のBRC20やMinterとは異なり、あなたのCAT20はあなたのアドレスのUTXOにはありません。

送金

送金では、構築されたトランザクションの入力トークンと出力トークン内のトークン数が一致している必要があります。もちろん、同じトランザクション内に複数のトークンを持つことができるので、異なるトークンの入力と出力の数を一貫させておくだけでよい。

燃やす

トークンを燃やしたいときは、通常のアドレスに転送するだけです。

まとめ

ご覧の通り、すべての操作はユーザーによって構築され、柔軟性が高いため、コントラクト部分には多くのチェックロジックがあります。これまで出てきた脆弱性のいくつかは、チェックサムロジックの見落としによるものでもあります。

この設計にはいくつかの利点があります：

1. すべてのトークンがどのように保持されているかを調べたい場合は、トークンのutxoをチェックするだけです。トークンのutxoより先に進む必要はありません。

2. 造幣局の現在のステータスを確認したい場合は、OP_RETURNにcatを持つトランザクションを検索できます。