ジェレミー・ルービンは、2週間前に「Un’FE’d Covenants（FE = Functional Encryption）」というタイトルの提案を発表しました。ビットコインの契約提案に関する継続的な議論を考慮すると、彼の提案は新しい実用的なオプションを示しています。これまでのすべての契約提案はソフトフォーク（実際のオペコード）、未検証の暗号技術（機能的暗号化）の開発と実装、または使用するための非常に高い金銭的コスト（ColliderScript）を要求しています。
ジェレミーの提案は、ソフトフォークを必要とせず、ユーザーが利用するために負担の大きく非現実的なコストを課すことはありません。その能力のトレードオフは、根本的に異なるセキュリティモデルです。オラクルのシステムを使用し、スラッシング可能なBitVMベースのボンドを利用することで、ビットコイン上で契約をエミュレートすることができます。
オラクル
この計画の最初の部分は、異なる契約条件を強制するオラクルです。これは比較的簡単な設定であり、ジェレミーの提案に必要な最初の構成要素です。このスキームではオラクルが資金を管理し、契約条件の施行を任されています。オラクルが管理する各コインの契約条件をローカルで追跡する必要がないようにしたいです。これにより、オラクルのデータベースが破損または喪失した場合に、すべてのコインの正直な施行をどのように処理するか分からなくなる状態リスクが生じます。この問題を回避するために、ジェレミーはタプロートを利用しています。
Schnorrベースのキーは、データのハッシュを使用して公開鍵を修正することによって「調整」できます。これにより、調整された鍵のために署名できるように対応する秘密鍵を調整することが可能になり、また、公開鍵を調整するために使用されたデータがその鍵によってコミットされたことを証明できます。オラクルが鍵を生成し、ユーザーがその鍵を契約プログラムで調整することで、オラクルが強制することになっている内容にコミットしながら、その情報を保存する負担をユーザーに負わせることができます。
オラクルは、単一の当事者に対して必要な信頼を最小限に抑えるために連合化することもできます。ここから、ユーザーは結果として得られたアドレスを簡単に読み込み、条件を強制したいときに、支払いトランザクション、オラクルプログラム、およびオラクルに提供されたトランザクションが契約の条件を満たしていることを証明するために必要な証人データを持ってアプローチできます。トランザクションが契約ルールに従って有効であれば、オラクルはそれに署名します。
結果が事前に知られている単純な契約（例えばCHECKTEMPLATEVERIFY（CTV））に対しては、ユーザーはオラクルに契約を強制するトランザクションを事前に署名させ、必要になるまで単に使用を遅らせることができます。
追加機能が必要な重要なシナリオは、定期的に進行し、実際の状態（ユーザーの現在の残高）を追跡する必要がある状態ベースの契約、例えばロールアップです。そのような契約の場合、オラクルが署名するトランザクションは、OP_RETURNを使用して契約の現在の状態にコミットしなければなりません。これにより、オラクルは、すべての履歴の証人データをダウンロードすることなく、ロールアップまたは他のシステムを更新する各トランザクションを効率的に検証できます。これは、オラクルがローカルに状態を保存する必要がないようにするためです。
長期的には、オラクルのデータ要件はゼロ知識証明を使用することによって最適化される可能性があります。これにより、オラクルは、署名を求められているトランザクションが契約のルールに従っていることを確認するための証明を単に検証できるようになります。ただし、ロールアップのようなシステムの場合、システムから退出するために必要なデータがユーザーに提供されていることを保証するように設計する際には注意が必要です。
BitVMボンド
これまでのところ、このスキームは完全に信頼されています。基本的に、あなたは他の誰かにお金を渡し、彼らが恣意的な契約の条件を強制することができると信じることを期待しています。上記のスキームをわずかに修正することによって、これは純粋な信頼ではなく、暗号経済的インセンティブで安全にすることができます。
上記では、ステートフル契約のためにOP_RETURNを使用して状態を追跡する必要があることが説明されました。OP_RETURNは、契約トランザクションの証人データを公開して、条件が正しく満たされたことを証明するためにも使用できます。
BitVM回路は、オラクルによって署名されたトランザクションが、強制している契約の条件に成功裏に一致するかどうかを確認するために構築できます。生成された鍵自体と、送信される資金は、強制される契約の条件にコミットしています。つまり、データと、アドレスから支出されるトランザクションは、BitVMインスタンスに入力できます。
オラクルは、BitVMオペレーターに担保ボンドを投稿することが求められる場合があります（オラクルが虚偽の告発を受けた場合にオラクルが請求できるボンドも投稿しなければなりません）。このように、ボンドの価値がオラクルによって担保された契約の価値よりも大きければ、システムは安全に使用できます。オラクルが強制している契約の条件を違反する方法はなく、全体としてお金を失うことになります。
トレードオフ
ここには、合意ルールでの契約の実装よりも実質的に悪化する明確なトレードオフがあります。まず、オラクルはオンラインでアクセス可能でなければならず、オラクルによって強制される契約を利用するにはそうでなければなりません。CTVのような事前に署名された契約を除いて、ユーザーが契約を強制する必要があるときにオラクルがオフラインであれば、彼らはそれを行うことができません。オラクルは署名するために存在しなければなりません。
第二に、オラクルボンドの流動性要件は、システムが広く採用された場合に膨大になる可能性があります。これにより、合意レベルでの契約オペコードのネイティブ実装と比較して信じられないほど非効率的になります。
最後に、BitVMボンドスキームが機能するためにオンチェーンで投稿する必要がある追加データは、ネイティブ契約実装と比べてブロックスペースの使用においてはるかに非効率的です。
全体として、この提案はネイティブ契約と比べて効率的でも安全でもありません。一方で、もし我々が早期の硬直化という最悪のシナリオに陥った場合、これは未確認の暗号技術やエンドユーザーに課せられる完全に非現実的なコストに依存することなく、ビットコインに契約を無理やり組み込む非常に実用的な方法です。
ジェレミーは、ビットコインで構築できるものの設計空間を拡張するための最悪のシナリオのオプションを提供してくれました。
出典: Bitcoin Magazine
投稿 A Last Resort: Un’FE’d Covenants For Bitcoin は Crypto Breaking News に初めて掲載されました。
