マーリン・テクノロジー・プログラムの説明：実際にどのように機能するのか？

By Faust, geekweb3

2023年の碑文の夏から現在に至るまで、Bitcoin Layer2はWeb3全体で常に大きな話題となっています。この分野の出現はイーサリアムのLayer2よりずっと後ですが、POWのユニークな魅力と同様に、わずか半年でビットコインの「証券化」のリスクを心配することなく、スポットETFのスムーズな着地により、Layer2にとってこのスピンオフ・トラックは数百億ドルの資本の注目を集めることになります。

ビットコインのLayer2トラックでは、数十億ドルのTVLを持つマーリンが、間違いなく最大のボリュームと注目を集めている。明確な誓約インセンティブと印象的な利回りで、マーリンは数ヶ月のうちにほとんど突然トップに上り詰め、ブラストを凌ぐエコロジー神話を作り上げた。マーリンの人気が高まるにつれて、その技術的解決策についての議論も関心が高まっている。

この記事では、GeekWeb3がMerlin Chainに焦点を当て、その公開されているドキュメントとプロトコル設計のアイデアを説明します。私たちは、より多くの人にMerlinの一般的なワークフローを理解してもらい、そのセキュリティモデルをより明確に理解してもらうことを約束します。私たちは、より多くの人にマーリンの一般的なワークフローとそのセキュリティモデルを理解してもらい、「頭のビットコイン・レイヤー2」が実際にどのように機能するのかをより直感的に理解できるようにすることを約束します。

Merlinは構築された最初のビットコインレイヤー2です。Merlin's Decentralised Prophecy Machine Network: an open off-chain DAC committee

イーサレイヤー2であろうとビットコインレイヤー2であろうと、すべてのレイヤー2にとって、DAとデータ配布のコストは最も重要な問題の1つです。解決すべき問題の一つである。本質的に大きなデータスループットをサポートしないビットコインネットワーク自体に多くの問題があるため、数十インチのDAスペースをどのように利用するかは、Layer2プロジェクトオーナーの想像力が試される課題となっています。

1つの結論は明らかです。もしLayer2が未処理のトランザクションデータをビットコインブロックに「直接」公開するなら、高いスループットも低い手数料も達成できないでしょう。最も一般的な解決策は、ビットコインブロックにアップロードする前にデータを可能な限り小さいサイズに高度に圧縮するか、ビットコインチェーンに直接データを公開することです。

おそらく、最初のアイデアを採用したLayer2の中で最もよく知られているのはCitreaで、Layer2の状態差分（複数のアカウントで時間をかけて状態を変更した結果）を、対応するZK証明とともにビットコインチェーンにアップロードすることを意図しています。Layer2の状態差分は、対応するZK証明とともにビットコインチェーンにアップロードされる。この場合、誰でもビットコインのメインネットから状態差分とZKPをダウンロードすることができ、Citreaの状態変更の結果を監視することができる。このアプローチは、チェーンにアップロードされるデータのサイズを90％以上圧縮します。

これによってデータサイズは劇的に圧縮されますが、ボトルネックはまだ大きく残っています。ボトルネックはまだ明らかです。短期間に多数のアカウントがステータス変更を受けた場合、Layer2はこれらのアカウント変更をすべて集約してビットコインチェーンにアップロードしなければならず、多くのイーサリアムZKロールアップで見られるように、データ配布の最終コストを低く抑えることはできません。

多くのビットコイン・レイヤー2は、独自のDAレイヤーを構築するか、Celestia、EigenDAなどを使用することで、ビットコインチェーンの下で直接DAソリューションを使用するという、単純に2番目の道を取ります。B^Square、BitLayer、そしてこの記事の主人公であるMerlinは、すべてこのチェーン下のDAスケーリングソリューションに従っています。

geekweb3の以前の記事 - 「B^2の技術ロードマップの新バージョンを説明：ビットコインチェーン下のDAと検証レイヤーの必要性」

これは、ビットコインを非信頼掲示板として使用します。

上述の楽観的なZKロールアップシナリオの下では、Layer2ネットワーク内にチャレンジを開始する特権を持つ人がN人いると仮定し、そのN人の挑戦者の1人が正直で信頼でき、いつでもエラーを検出し、不正の証明を開始できる限り、Layer2の状態遷移は安全です。は安全である。もちろん、より高い完成度を持つ楽観的なRollupは、その引き出しブリッジも不正証明プロトコルによって保護されていることを保証する必要があり、ほぼすべての現在のBitcoin Layer2はこの前提を達成することができず、マルチ署名/MPCに依存する必要があります。

マーリンはブリッジングソリューションにCoboのMPCサービスを選びました。ホットウォレットとコールドウォレットの分離などの対策を採用し、ブリッジング資産はCoboとマーリンチェーンによって管理されます。引き出しはすべてCoboとMerlin ChainのMPC参加者が共同で処理する必要があり、基本的に金融機関の信用裏付けを通じて引き出しブリッジの信頼性を保証する。もちろん、これは現段階での応急処置に過ぎず、プロジェクトの段階的な改善により、「楽観的ブリッジ」の1/Nの信用前提にBitVMと不正証明プロトコルを導入することで、出金ブリッジを置き換えることができるが、現場では難しい（現時点では、Layer2の公式ブリッジのほぼすべてがマルチシグネチャに依存している）。

総合すると、Merlinが導入したPOSベースのDAC、BitVMベースの楽観的ZK-Rollup、CoboベースのMPCアセットホスティングソリューションを整理し、DAC権限を開放することでDAの問題を解決することができます。BitVMと詐欺防止プロトコルを導入することで状態遷移を安全にし、有名な資産ホスティング・プラットフォームであるCoboのMPCサービスを導入することで引き出しブリッジの信頼性を確保します。

Lumozに基づく2段階の検証済みZKP提出スキーム

以前、私たちはマーリンのセキュリティモデルを調べ上げ、楽観的なZK-ロールアップコンセプトを導入しました。ロールアップの概念です。周知のように、プローバはZK-ロールアップ・アーキテクチャの中核的な役割であり、シーケンサが公開したバッチに対してZKプルーフを生成する役割を担っています。 ゼロ知識プルーフの生成プロセスは、多くのハードウェアリソースを消費するため、非常に厄介なものです。

ZK証明の生成を高速化するために、タスクを並列化してプロセスをスライス＆ダイスすることは、最も基本的な操作の1つです。いわゆる並列化とは、実際にはZK証明を生成するタスクを異なる部分にスライスすることであり、それらは異なる証明者によって別々に行われ、最終的にアグリゲーターが複数の証明を全体として集約します。

ZK証明の生成プロセスを高速化するために、MerlinはAggregatorを使ってZK証明を生成します。strong>Merlinは、LumozのProver as a Serviceソリューションを使用します。これは実際に、多数のハードウェアデバイスを集めてマイニングプールを形成し、対応するインセンティブを持つ異なるデバイスに計算タスクを割り当てる方法であり、POWマイニングに多少似ています。

この分散型プローバーのシナリオでは、一般的にgrab-and-run攻撃として知られている、攻撃シナリオのクラスがあります：アグリゲーターAggregatorがZKPを形成し、報酬を得るためにZKPを送信したとします。他のアグリゲータがZKPのコンテンツを見て、同じコンテンツを先に投稿し、ZKPは自分たちによって形成されたと主張したとします。

たぶん、最も直感的に思いつく解決策のひとつは、各アグリゲーターに特定のタスク番号を割り当てることでしょう。たとえば、タスク1はアグリゲーターAだけが拾うことができ、他の人はタスク1を完了しても報酬を得ることはできません。しかし、この方法には問題がある。それは、一点のリスクから守ることができないということだ。アグリゲーターAにパフォーマンス障害が発生したり、ネットワークから脱落したりすると、タスク1は立ち往生したままになってしまう。また、1つのエンティティにタスクを割り当てるこのアプローチは、競争的なインセンティブで生産性を向上させる良い方法ではありません。

ポリゴンzkEVMは、ブログ投稿でProof of Efficiencyと呼ばれるアプローチを提案し、異なるアグリゲーター同士が競争的な動機づけを受けるべきだと述べています。インセンティブは先着順で分配され、最初にZK-Proofをチェーンに提出したAggregatorが報われる。もちろん、彼はMEVラッシュ問題の解決方法については言及していない。

LumozはZK-Proofの2段階検証を採用しています。提出方式では、アグリゲーターがZKプルーフを生成した後、最初に完全なコンテンツを送信する必要はなく、ZKPのハッシュのみを公開する、言い換えれば、ハッシュ（ZKP+アグリゲーターアドレス）を公開する。こうすることで、他の人がハッシュ値を見ても、対応するZKPの内容を知らないので、直接掴んで実行することができない。

誰かが単純にハッシュ全体のコピーを作って最初に公開しても、ハッシュには特定のアグリゲータXのアドレスが含まれているので、アグリゲータAはこのハッシュを最初に公開しても意味がない。アグリゲータAが最初にハッシュを公開したとしても、元のハッシュが公開されたとき、それがAのアドレスではなく、Xのアグリゲータのアドレスを含んでいることが誰にでもわかるでしょう。

この2段階検証ZKP提出スキームにより、Merlin（Lumoz）はZKP提出プロセスにおける先取り問題を解決することができ、ゼロ知識証明を生成するための高い競争インセンティブを実現し、ZKP生成速度を向上させることができる。

Merlin's Phantom: Multi-chain interoperability

マーリンの技術ロードマップによると、次のようなものもサポートする予定です。Merlinがソースチェーンで、他のEVMチェーンがターゲットチェーンの場合、Merlinノードがユーザーからのクロスチェーン相互運用性要求を感知すると、ターゲットチェーン上で後続のワークフローをトリガーします。

たとえば、マーリンネットワークによって制御されるEOAアカウントは、Polygon上に展開することができます。 ユーザーがマーリンチェーン上でクロスチェーン相互運用コマンドを発行すると、マーリンネットワークはまずその内容を解析し、ターゲットチェーン上で実行されるトランザクションデータを生成します。Merlin Networkはまずそのコンテンツを解析してターゲットチェーン上で実行されるトランザクションデータを生成し、次にOracle Networkがそのトランザクションに対してMPC署名処理を行い、トランザクションのデジタル署名を生成する。その後、MerlinのRelayerノードがPolygon上でトランザクションをリリースし、ターゲットチェーンのEOAアカウントにあるMerlinの資産を経由するなどの後続処理を完了する。

ユーザーによって要求された操作が完了すると、対応するアセットがターゲットチェーン上のユーザーのアドレスに直接転送され、理論的にはマーリンチェーンにも直接転送されます。このソリューションには明らかな利点がある。従来のアセット・クロスチェーンやクロスチェーン・ブリッジ契約によって発生する手数料の消耗を避け、クロスチェーン・オペレーションのセキュリティをマーリンのオラクル・ネットワークが直接保証するため、外部のインフラに頼る必要がない。ユーザーがマーリンチェーンを信頼している限り、この種のクロスチェーン相互運用性は問題ないと考えてよいだろう。

まとめ

この記事では、マーリンチェーンの一般的な技術スキームを簡単に説明しましたが、これによってより多くの人がマーリンの一般的なワークフローを理解できると信じています。マーリンの一般的なワークフローを理解し、そのセキュリティモデルをより明確に認識することができる。現在のビットコインエコシステムが本格化していることを考慮すると、このような技術の普及は価値があり、一般大衆に必要とされていると考えます。 私たちは今後長期にわたってMerlinや、bitLayerやB^Squareのような他のプロジェクトをフォローアップし、それらの技術的ソリューションについてより詳細な分析を提供する予定です！