BTC拡張の概念実証：OP_CAT対応BTCへのブリッジ・コントラクトの実装

本稿では、sCryptがどのようにビットコイン上でデモブリッジコントラクトを構築するかについて掘り下げます。この概念実証の実装は、Starknetレイヤー2（L2）ネットワーク用のプロダクショングレードのブリッジの基礎を築くことを目的としています。ブリッジは、複数の入金または出金要求トランザクションを単一のルートトランザクションにマージできるように設計されており、このトランザクションはメインのブリッジ契約に組み込まれ、メルケルツリーで編成されたアカウントセットで構成される状態を更新します。

ブリッジ契約のスクリプトは複雑であるため、sCryptではその実装を書くためにsCrypt固有のドメイン言語（DSL）を利用しました。

概要

ブリッジは再帰的なコントラクトBitcoinスクリプトで構成されています。この文脈では、「コントラクト」は、ロッキングスクリプトが支出トランザクションに条件を課すことができることを意味し、「再帰的」は、上記のルールがチェーン上で永続的なロジックと状態を可能にするのに十分堅牢であることを意味します（任意のオンチェーンスマートコントラクトの基本要件）。

スクリプトは一連のトランザクションの中に存在し、各トランザクションは後続のトランザクションの構造に制約を課し、現在のトランザクションの出力をアンロックする。新しいトランザクションがこのチェーンに追加されるたびに、それはブリッジ状態の更新を意味する。したがって、このチェーンの終わりは現在のブリッジ状態を保持する。

契約状態（具体的にはハッシュ値）は、消費不可能なOP_RETURN出力に格納される。このUTXOを使用することはありませんが、そのデータは契約スクリプトを実行するときに調べることができます。

Merkleツリーは、アカウントスロットの固定セットのデータを保持しています。リーフノードには、住所と残高を含むそれぞれの口座データのハッシュが格納されています。空のアカウントスロットを示すために、これらのスロットはゼロバイトでマークされます。

ブリッジが更新されるたびに、アカウントツリーが変更されます。この更新を容易にするために、ビットコインスクリプトで検証が非常に効率的であるMerkle証明に依存します。更新は主に2つのステップで構成されます。まず、メルクル証明を検証して、証明メルクルツリーに特定のアカウントの現在の状態が含まれていることを示します。次に、そのアカウントの新しい状態を計算した後、前述のメルクル証明と同じ補助ノードを使用して、新しいルートハッシュを導出します。

更新には入金や出金があります。ブリッジは単一のトランザクションでこれらの更新のバッチ操作を実行することができます。

入金

私たちの目標は、ユーザーが独立して入金や出金リクエストを提出できるようにすることです。これを実現するために、ユーザーは入出金アグリゲーション契約に別々に支払われる個別のトランザクションを作成します。コントラクトはこれらのリクエストをメルクルツリーに集約する。このツリーのルートハッシュはメインブリッジコントラクトにマージされ、メインブリッジコントラクトは各入金または引き出しを処理する。

預金データをハッシュ化し、預け入れトランザクションでメルクルツリーを構築することに加え、コントラクトは、コントラクト出力にロックされた預け入れサトシが正しくツリーのルートノードに蓄積されるようにする。集約コントラクトは、正しいオンチェーン・スマートコントラクトのみがこれらの資金を使用できることを保証する。(もちろん、本番環境では、ユーザーがデポジット取引をキャンセルすることもできるようにします）。

このツリー構造の設計は、コントラクトスクリプト構築の制約に由来しており、あまりに多くの入力と出力を含むトランザクションを許可していません。ツリー構造により、潜在的に任意のスループットまで拡張することができます。

出金リクエスト

出金リクエストは入金と同様に集約されますが、いくつかの違いがあります。まず、ユーザーが自分の口座からお金を引き出すことができるように、認証方法が必要です。これは入金とは異なり、誰でもどの口座にも入金でき、ビットコインアドレスが使用される方法と似ている。認証は集約ツリーのリーフノードレベルで行われる。引き出し要求集約契約は、引き出しアドレスがリーフトランザクションで入力された最初のP2WPKHアドレスと一致するかどうかをチェックします。

これにより、アドレスの所有者が引き出しを要求するトランザクションに署名しているため、引き出しを承認していることが保証されます。入金集計と比べたもう一つの微妙な違いは、中間累積額をハッシュ化し、ツリー構造の上方に渡すことである。これは後で詳しく説明するが、出金を拡張するときにこのデータが必要になるからである。

勘のいい読者は、この出金要求認証モデルの潜在的な問題に気づくかもしれません。もしあるオペレーターが不正を決行し、ルートトランザクションの集約ツリーを作成し、その集約ツリーのデータが認証されていない偽の出金リクエストによってローカルで偽造されたとしたらどうなるでしょうか？ルートトランザクションが有効なリーフトランザクションから来ていることを検証する効率的な方法が必要です。

この問題を解決するために、私たちは「ジェネシス・チェック」と呼ばれるものを実行します。基本的に、集計コントラクトにその前のトランザクションと最初の2つのトランザクション、すなわち「祖先トランザクション」をチェックさせる。コントラクトは、これらのトランザクションに同じコントラクトスクリプトが含まれていることを確認し、同じチェックを実行する。このようにして、帰納的トランザクション履歴チェックを実装する。最初の2つのトランザクションは現在のコントラクトと同じチェックを実行するので、これらのトランザクションの「祖先」も、リーフノード（すなわち、作成トランザクション）まで遡って同じチェックを実行することを確認できる。

もちろん、ツリーの両方の枝で検証を実行します。したがって、各集約ノードトランザクションは、合計で最大6つのトランザクションをチェックする。

出金拡張

さて、ソリューションの最後の部分、出金拡張に移りましょう。出金要求のバッチを処理した後、メインブリッジの契約は出金総額を延長契約に支払う出力を強制する。このコントラクトは、フェッチリクエスト集計コントラクトが行った処理の逆プロセスと考えることができる。これはフェッチツリーのルートノードから始まり、それを2つのブランチに展開し、それぞれがそのブランチに支払われるべき対応するフェッチ量を含む。このプロセスはフェッチツリーのリーフノードまで続く。リーフ・トランザクションは、引き落としを要求された金額について、口座所有者のアドレスへの単純な支払い出力を強制する。

Implementation

ブリッジコントラクトを実装するために、私たちは4つのsCryptスマートコントラクトを開発しました。システムの異なる側面を処理します。このセクションでは、各コントラクトの機能の概要を説明します。

DepositAggregatorコントラクト

DepositAggregatorコントラクトは、個々のデポジットをメルケルツリーに集約し、それをメインのブリッジコントラクトにマージします。この集約により、一括入金処理が可能になり、ブリッジが個別に処理する必要のあるトランザクションの数を減らすことができます。さらに、利用者が個別に預金を提出し、それを後でオペレーターが処理することも可能になる。

契約ビルダー関数には次のものがあります。2つのパラメータ:

• operator: 預金を集約する権利を持つブリッジオペレーターの公開鍵。

• bridgeSPK: 集計された預金が正しくマージされることを保証するマスターブリッジ契約のスクリプト公開鍵（SPK）。

預金アグリゲーターの中核機能は、「aggregate」メソッドにカプセル化されています。このメソッドは以下のステップを実行します：

Sighash原本およびオペレーターの署名の検証：取引がブリッジオペレーターによって承認され、sighash原本が正しくフォーマットされ、実行される取引に属していることを確認します。sighash原本の検証についてはこちらの記事をご覧ください。

先行トランザクションIDの構築と検証：集約された先行トランザクションが有効で、正しく参照されていることをチェックします。

先行トランザクションIDの構築：集計された先行トランザクションが正しく参照されているかチェックする。

Merkle Tree Aggregation: ウィットネスハッシュとして渡されたデポジットデータが、先行トランザクションに保存された状態と一致することを検証します。