Truebit を 5 分で理解: プロトコルのメカニズム、アプリケーション シナリオ、経済モデル
作者: エッセンス ラボ
強気相場の最終ラウンド中に立ち上げられたベテランの Layer2 プロジェクトとして、Truebit は 4 月末にようやく控えめな形で稼働を開始しました。トークンの価格が上昇し続け、その特別価格設定メカニズムと TruebitOS 裁定取引の機会をめぐる議論が進むにつれ、Truebit コミュニティの熱意は加熱し続けています。この記事は、Truebit ネットワークのプロトコル メカニズム、アプリケーション シナリオ、経済モデルを整理することで、ユーザーがプロジェクトの全体像を把握できるようにすることを目的としています。
さらに、V God の最新の Optimistic Rollup EVM ソリューションについても読者とともに詳しく見ていきます。
最後に、Truebit ネットワークへの参加を練習したい場合は、記事の最後にある思慮深いガイダンスをお見逃しなく。
問題の背景
現在、イーサリアムには次の問題があります。
全体的なスループットが低い。大量の計算能力を消費しますが、スループットはスマートフォンと同等です。
検証度は低いです。この問題は検証者のジレンマとして知られています。パッケージ化権を獲得したノードには報酬があり、他のノードは検証する必要があるが報酬は得られず、検証熱も低い。時間が経つと計算が検証されなくなり、チェーン上のデータ セキュリティにリスクが生じる可能性があります。
計算量に制限（gasLimit）があり、計算コストが高くなります。
上記の問題は、イーサリアムの全（フル）ノードが検証を行う設計となっているために発生します。冗長な計算量が多すぎます。 TrueBit は、コンピューティング タスクの「完全ノード冗長性検証」設計を、少数のオフチェーン ノードのみでの冗長検証に削減します。
協定の枠組み
TrueBit プロトコルにはスマート コントラクトが含まれています。ユーザーはこのスマート コントラクトにコンピューティング タスクを送信し、このタスクに対して支払ってもよい価格を与えることができます。これらのユーザーはタスク ギバーと呼ばれます。
ソルバーは、タスクを完了して報酬を受け取りたい参加者です。ソルバーは、タスクに割り当てられるように契約にいくらかのデポジットを支払い、この計算タスクを完了することで報酬を受け取ります。
ゲームを検証する
ゲームを検証する
前のセクションのプロトコル フレームワークの紹介からわかるように、意見の相違がある場合、ソルバーとチャレンジャーのどちらが正しいかを判断するための検証ゲームが必要になります。この検証ゲームはスマートコントラクトによって組織されています。スマート コントラクトが多くの計算を支払う必要がある場合、チェーンのランニング コストが非常に高くなり、gasLimit を超える可能性があります。私たちの目標は、チェーン上の計算をできるだけ少なくすることです。
この目標を達成するための現在の方法は、ソルバーとチャレンジャーが双方の計算プロセスで最初の分岐点を見つけられるようにすることです。最後の同じ点から最初の分岐点までの計算量は非常に少なく、この点だけが必要です。契約で実行されるべきことを計算して、どちらが正しいかを判断できます。具体的なプロトコルを以下に簡単に説明します。
メインループステージ
時間間隔 t の計算に疑問があると仮定し、時間 t を c 個の等しい部分に分割し、ソルバーが各時点の状態をマークル ツリーで表します。ツリーの葉ノードはすべてマシンの状態変数です。そして、コントラクトにコミットする c マークル ツリー ルートをハッシュします。
挑戦者が i 番目の時点でハッシュを見つけた場合、それはローカルで計算されたハッシュと一致しない最初の時点になります。契約書を提出します。
裁判官は C ハッシュと番号 i の正当性をチェックします。
次のステップでは、i-1 と i の間の時間間隔を疑わしいオブジェクトとして取得し、前のステップを再帰的に繰り返します。
確認段階
副題
賞品の仕組み（ジャックポット）
ソルバーは独自の計算結果を提供し、検証者は計算を繰り返して、ソルバーによって提供された結果が正しいことを検証します。これは通常の動作ロジックです。しかし、このロジックには次のような問題があります。
検証タスクが検証者に割り当てられ、その対価として検証者が支払われる場合、検証者は二重計算をまったく行わず (このために計算コストを支払わない)、ソルバーの結果を直接二次的に利用する可能性があり、これは非常に危険です。プロトコル。
検証者が見つけたバグ結果に対してのみ料金を支払う場合、検証者はいつバグを見つけるかわかりません。実際、長い間バグが見つからない可能性があり、検証者が参加するインセンティブがありません。両方とも予想されます。そして実用的。
副題
実装と応用のシナリオ
検証ゲームを実現するには、命令アーキテクチャを統一する必要があります。 TrueBit プロジェクトは当初、Lanai アーキテクチャを使用することを希望していましたが、後に Lanai コンパイラの実装が遅いことが判明しました。現在は代わりに WebAssembly を使用しています。
初期の TrueBit 計画のアプリケーション シナリオは次のとおりです (当時は RollUp 拡張のアイデアはありませんでしたが、昨日、Vitalik は TrueBit OS の発売後に楽観的な RollUp についての提案を TrueBit に提供しました。詳細については次のセクションを参照してください)。
外部委託されたコンピューティング能力: 以前に導入されました。
分散型鉱山プール: 分散型鉱山プールの利点は、単一ポイント (集中型鉱山プールの運営者) が攻撃されるのを防ぐことです。分散型マイニングプールはスマートコントラクトを通じて実装できますが、ZCash の POW を検証するなどの作業が GasLimit を超えますが、これは TrueBit メカニズムを通じて克服できます。このような分散型マイニングプールの実現を支援します。
副題
プロトコルのレビュー
TrueBit プロトコルのインタラクティブな検証ゲームにより、ユーザーはあらゆるコンピューティング タスクを送信 (アウトソーシング) し、正しい結果を得ることができます。
TrueBit は、他のマイナーによる冗長な検証作業を削減し、報酬構造を最適化します。検証者のジレンマの問題が軽減されました。
Vitalik: Truebit に基づいた楽観的ロールアップ EVM の構築
元のリンク元のリンク, このソリューションは Truebit をブラック ボックスとして扱います。つまり、それに命令を入力し、一定の遅延期間後に結果が返されることを期待できます。このモデルに基づいて、EVM オプティミスティック ロールアップを構築できます。
Truebit は WebAssembly (WASM) 命令を受け入れることができ、C++、Go、Rust、Java などの最新の高級言語のほとんどを WASM バイトコードにコンパイルできます。つまり、これらの言語で記述された Ethereum クライアントは、 WASM にコンパイルされることも Truebit に実装されています。 Truebit に基づいて EVM を構築する場合、最初のステップはステートレスな Ethereum クライアントを構築することです。ステートレス クライアントはこの方法で実装できます。ブロックの実行に必要な状態データは、実行のための状態クエリ テーブルの形式で入力パラメータとしてクライアントに渡されます。このようなクライアントは状態自体を維持する必要はありません。純粋関数メソッド process_block(state_lookup_table, block) -> post_state_root に抽象化できます。このような純粋関数のステートレス クライアントは、wasm にコンパイルし、実行のために Truebit に渡すことができます。
2 番目のステップは、チェーン上にモジュールを構築することですが、ここでの難点の 1 つは、ブロックチェーンがステートフルであることです。オプティミスティック ロールアップ チェーン上の N 番目のブロックが不正防止プロセスの実行を開始する場合、N 番目のブロックの stateRoot に関連する状態データが利用可能であるという暗黙の前提が存在します。この前提があるため、誤ったブロックが送信された場合、人々はそもそもブロックのエラーを証明できます。ただし、Truebit は純粋に機能するステートレス インタラクティブ コンピューティング システムであり、Truebit 呼び出し以外のインタラクティブ検証プロセスのいくつかのステップを通じて、このような制限を回避できます。
プログラム フローは次のように設計できます。
1. ブロック ハッシュと stateRoot をチェーン上のコントラクトに保存します: List[Tuple[block_hash, state_root]]
2. シーケンサー (実装者によって決定され、1 つ以上の可能性があります) はブロックの追加を担当します。これはメソッド add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32) を呼び出すことによって実装されます。このメソッドは実行前に stateRoot を必要とします。パラメーターとして渡されると、((block, post_state)) がチェーンに追加されます。
3. チャレンジャーは、次のロジックを実行するメソッドChallenge(index: int, lookup_table: bytes, block: bytes)を呼び出すことでstateRootにチャレンジできます。
送信されたブロックが保存されたハッシュと一致することを確認します
Truebit で process_block() を呼び出してブロックのコンテンツを実行します。
ルックアップ テーブルのマークル ルートを計算して保存します。
チャレンジが開始されると、preStateRoot をルートとしてメルケル パス上の値を送信し、それをチャレンジャーによって提供されたメルケル パス上の同じ値と比較することで、誰でも、チャレンジャーによって提供されたクエリ テーブルが間違っていることに異議を唱えることができます。争いがあれば、それは挑戦者に問題があることを意味し、挑戦者は罰せられることになる。
待機期間後に Truebit が実行ブロックの結果 post_state_root を返したら、それはチャレンジが正常である (つまり、チャレンジャーに問題があることを誰も証明しない) ことを意味します。つまり、返された結果は通常の正しい結果です。ブロック実行。次に、結果が正しいという仮定に基づいて、次のロジックが実行されます。
結果が以前に送信された post_state_root と一致せず、エラー ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE ではない場合、チャレンジは成功し、元の送信者は罰せられ、他の人は引き続き正しいブロックと状態データを送信して、 1 つのブロックと状態が間違っています。
副題
経済モデルの概要
Truebit のトークンは TRU で、タスクの提出者がソルバーと検証者に支払いを行うために使用されます。支払いを受け取った後、ソルバーと検証者はタスクの実行を開始できます。
副題
TRUトークンの供給方法
TRU トークンは、累積的な需要に基づいて時間の経過とともに作成および破棄されます。ユーザーはETH経由でTRUトークンを「購入」または「出金」できます。すべての購入取引では ETH の一部が準備金エスクローに入金され (残りは会社に送られます)、すべての販売取引では ETH の一部が準備金から引き出しられます。すべての Truebit タスクも TRU トークンを焼きます。 Truebit OS の「タスク コスト」コマンドを使用すると、現在の「バーン レート」と「トークン価格」を知ることができ、現在の TRU の購入価格と売却価格を理解するのに役立ちます。
副題
期間限定のインセンティブ
副題
ETH手数料
副題
価格設定方針
Truebit は価格設定に結合曲線モデルを採用しており、需要が増加しトークンの総量が増加すると、曲線上の価格も同時に上昇します。
副題
Truebit ネットワークに早期に参加する方法
現在、ユーザーは、個人/組織の紹介、Github アドレス、Truebit の利用シナリオなどの申請フォームを提出することで、Truebit への早期アクセスを取得できます。送信後、管理者が内容を確認し、返信させていただきます。
申請アドレスは以下の通りです。
https://truebit.substack.com/p/truebit-early-access
さらに、Truebit の使用とメカニズムに関するあらゆる議論は、gitter で開発者と通信できます。
https://gitter.im/TruebitProtocol/community
著者について：
Essence Labs は、DeFi と Web3.0 の方向に向けて新しく設立された起業家チームであり、そのビジョンは、Web3.0 の実現を促進し、一般の人々がアクセスできるより多くのアプリケーション シナリオへの分散型信頼を強化することです。
Essence Labs のメンバーは、ブロックチェーンのコア コンセンサス メカニズムの研究、ブロックチェーン プラットフォームの開発と実装の経験に加え、最先端のインターネットおよび金融テクノロジーのバックグラウンドを持っています。私たちは、Web3.0 ミドルウェア、スケーラビリティ ソリューション、DeFi プロトコルなどのトラックに細心の注意を払っており、業界の同僚とともにブロックチェーン業界の将来の方向性を探求することを楽しみにしています。
