文章

この調査では、イーサリアムと同様の実装システムを比較し、トランザクションの並列実行の難しさと可能性を分析しました。チェーン自体は、UTXO モデルではなくアカウント モデルに基づいて設計されています。

最初のレベルのタイトル

1. FISCO-BCOS など、中国の多くのアライアンス チェーンは、ブロック内でのトランザクション検証の並列実行をサポートしています。

2. パブリック チェーン プロジェクトである Khipu は、イーサリアム プロトコルのスカラ実装です。

3. Aptos、パブリック チェーン プロジェクト、仮想マシンの移動。

最初のレベルのタイトル

トランザクションの並列実行の難しさ

まず、従来のトランザクション実行プロセスを確認してみましょう。

実行モジュールはブロックからトランザクションを1つずつ取り出して、1つずつ実行します。実行プロセス中に最新のワールド状態が変更され、トランザクションの実行後に状態が蓄積され、ブロック完了後に最新のワールド状態に達します。次のブロックの実行は、前のブロックの実行後の世界の状態に厳密に依存するため、トランザクションの従来の線形実行プロセスを並列実行用に適切に最適化することはできません。

1. アカウントの競合。 2 つのスレッドがアドレス アカウントの残高やその他の属性を同時に処理する場合、それらは順次処理の結果と一致するかどうか、つまり世界状態が明確な有限状態マシンであるかどうか。

3. 契約間の通話の競合。本来、コントラクト Ar が最初にデプロイされ、コントラクト B はコントラクト A を呼び出すためにコントラクト A がデプロイされるまで待つ必要があります。しかし、トランザクションが並列している場合、そのような順序は存在せず、競合が発生します。

FISCO-BCOS

最初のレベルのタイトル

トランザクション並列方式の比較

最初のレベルのタイトル

概要

FISCO-BCOS 2.0 は、トランザクションの処理過程でグラフ構造を使用し、DAG モデルに基づいて並列トランザクション エグゼキュータ (PTE、Parallel Transaction Executor) を設計します。 PTE はマルチコア プロセッサの利点を最大限に発揮し、ブロック内のトランザクションを可能な限り並列実行できます。同時に、シンプルで使いやすいプログラミング インターフェイスをユーザーに提供するため、ユーザーは面倒な並列実装の詳細を気にする必要がなくなります。ベンチマーク テスト プログラムの実験結果は、従来のシリアル トランザクション実行スキームと比較して、理想的な条件下で、4 コア プロセッサ上で実行される PTE は約 200% ～ 300% のパフォーマンス向上を達成でき、コンピューティングの向上は従来のシリアル トランザクション実行スキームに匹敵することを示しています。コアの数 コアの数が多いほど、パフォーマンスは高くなります。

プログラム詳細

循環のない有向グラフは、有向非循環グラフ (DAG) と呼ばれます。トランザクションのバッチにおいて、各トランザクションが占有する相互に排他的なリソースを特定の方法で識別でき、その後、ブロック内のトランザクションの順序と相互に排他的なリソースの占有関係に従って、トランザクションに依存する DAG グラフを構築できます。 。以下の図に示すように、入次数が 0 (依存する事前注文タスクがない) のすべてのトランザクションは並列実行できます。左側の元のトランザクション リストの順序に基づいてトポロジー ソートを行うと、右側のトランザクション DAG を取得できます。

モジュール式アーキテクチャ

• ユーザーは、SDK を通じて直接的または間接的にトランザクションを開始します。

• その後、ノード間でトランザクションが同期され、パッケージ化権を持つノードがスケーラ(Sealer)を呼び出して(TxPool)から一定量のトランザクションを取り出してブロックにパッケージ化します。その後、ブロックはノード間の合意のためにコンセンサスユニット (Consensus) に送信されます。

• 合意に達する前にトランザクション検証を実行する必要があり、ここから PTE の作業が始まります。アーキテクチャ図からわかるように、PTE はまずブロック内のトランザクションを順番に読み取り、それらを DAG コンストラクターに入力します。 DAG コンストラクターは、各トランザクションの依存関係に基づいてすべてのトランザクションを含むトランザクション DAG を構築します。その後、PTE はワーカー スレッド プールを起動し、複数のスレッドを使用してトランザクション DAG を並列実行します。ジョイナーは、ワーカー スレッド プール内のすべてのスレッドが DAG の実行を終了するまで、メイン スレッドを一時停止する責任があります。このとき、Joiner は各トランザクションペアの状態の変更記録に基づいて状態ルートと受信ルートを計算し、実行結果を上位の呼び出し元に返します。

• ブロック検証に合格した後、ブロックはチェーンにアップロードされます。トランザクションの実行後、各ノードのステータスが一貫していれば、合意が得られます。その後、ブロックは基礎となるストレージ (ストレージ) に書き込まれ、ブロックチェーンに永続的に記録されます。

トランザクション DAG 構築プロセス

1. パッケージ化されたブロックからブロックのトランザクションをすべて取り出します。

2. トランザクション数を頂点の最大数として DAG インスタンスを初期化します。

3. すべてのトランザクションを順番に読み取ります。トランザクションが並列化可能な場合は、その競合ドメインを解決し、以前のトランザクションがこのトランザクションと競合していないかどうかを確認します。競合がある場合、対応するトランザクション間に依存エッジが構築されます。トランザクションを並列化できない場合は、前のすべてのトランザクションが実行された後にトランザクションを実行する必要があるとみなされ、このトランザクションと以前のすべてのトランザクションの間に依存エッジが確立されます。

備考: すべての依存エッジが確立された後は、それらを並行して実行することはできず、順次にのみ実行できます。

DAG実行プロセス

1. メインスレッドはまずハードウェアコア数に応じて対応するサイズのスレッドグループを初期化し、ハードウェアコア数の取得に失敗した場合、他のスレッドは作成されません。

2. DAG の実行が完了していない場合、スレッドはループし、DAG からの waitPop メソッドが入力次数 0 の準備完了トランザクションを取得するのを待ちます。実行対象のトランザクションの取り出しに成功すると、トランザクションが実行され、実行後に後続の依存タスクの入次数が1減ります。トランザクションの次数が 0 になった場合は、そのトランザクションを topLevel に追加します。失敗した場合は、DAG が実行され、スレッドが終了したことを意味します。

問題と解決策

1. 同じブロックについて、すべてのノードが実行され、同じステータス (3 つのルートが一致) になることを確認するにはどうすればよいですか?

FISCO BCOS では、状態ルート、トランザクション ルート、レシート ルートのトリプルが等しいかどうかを検証する方法を使用して、状態が一貫しているかどうかを判断します。トランザクションルートは、ブロック内のすべてのトランザクションに基づいて計算されるハッシュ値であり、すべてのコンセンサスノードで処理されるブロックデータが同じである限り、トランザクションルートは同じでなければなりません。これは比較的簡単に保証できるため、トランザクションの実行後に生成される状態がレシート ルートと同じであることを保証する方法に焦点が当てられます。

異なる CPU コアで並列実行される命令の場合、命令間の実行順序を事前に予測できないことはよく知られています。並行して実行されるトランザクションについても同様です。従来のトランザクション実行スキームでは、トランザクションが実行されるたびにステート ルートが 1 回変更され、変更されたステート ルートがトランザクション レシートに書き込まれます。すべてのトランザクションが実行された後、最終状態のルートは現在のブロックチェーンの状態を表し、すべてのトランザクションの受信に基づいて受信ルートが計算されます。

従来の実行スキームでは、ステート ルートがグローバル共有変数と同様の役割を果たしていることがわかります。トランザクションが並列かつ順不同で実行される場合、ステート ルートを計算する従来の方法は明らかに適用できなくなります。これは、一般にトランザクションの実行順序がマシンごとに異なり、現時点では最終状態のルートの一貫性が保証できないためです。同様に、受信ルートの一貫性も保証できません。FISCO BCOS では、まずトランザクションを並列実行し、各トランザクションの状態変化履歴を記録し、すべてのトランザクションが実行された後、これらの履歴記録に基づいてステートルートを総合的に計算します。これにより、トランザクションが並行して実行された場合でも、最終コンセンサスノードでコンセンサスに到達できることが保証されます。

2. 2 つのトランザクションが依存しているかどうかを判断するにはどうすればよいですか?

2 つのトランザクションに依存関係がないにもかかわらず、依存関係があると判断された場合、不必要なパフォーマンスの損失が発生します。逆に、2 つのトランザクションが同じアカウントの状態を書き換えるにもかかわらず並行して実行される場合、アカウントの最終的な状態が不確実になる可能性があります。 。したがって、

依存関係の決定はパフォーマンスに影響を与え、ブロックチェーンが正常に動作できるかどうかさえ決定する重要な問題です。

単純な転送トランザクションでは、転送の送信者と受信者のアドレスに基づいて 2 つのトランザクション間に依存関係があるかどうかを判断できます。

例として、A→B、C→D、D→E の 3 つの転送トランザクションを考えます。トランザクション D→E はトランザクション C→D の結果に依存していることが簡単にわかりますが、トランザクション A→B は他の 2 つのトランザクションと関係がないため、並列実行できます。

この分析は、単純な転送のみをサポートするブロックチェーンに当てはまります。しかし、ユーザーが作成した譲渡契約にどのような操作が含まれているかを正確に知ることはできないため、この種の分析をチューリングが完成し、スマート コントラクトを実行するブロックチェーンに組み込むと、精度が十分ではありません。

考えられる状況は次のとおりです。A → B トランザクションは C と D のアカウント ステータスとは何の関係もないようですが、ユーザーの基本的な実装では、A は特別なアカウントであり、A アカウントを介して送金されるすべての資金は最初に送金される必要があります。 C からの送金 一定の手数料が口座から引き落とされます。このシナリオでは、3 つのトランザクションはすべて関連しているため、並行して実行することはできません。従来の依存関係解析手法に従ってトランザクションも分割すると、必ず問題が発生します。

では、ユーザーの契約内容に基づいて、トランザクションに実際にどの依存関係が存在するかを自動的に推定できるでしょうか?答えは否定的です。静的分析でも述べたように、コントラクトの依存関係や実行プロセスの分析は困難です。

FISCO BCOS では、トランザクションの依存関係を指定するタスクを、契約内容に詳しい開発者に割り当てます。具体的には、トランザクションが依存する相互排他的なリソースを文字列のセットで表すことができます。 FISCO BCOS は、開発者にインターフェイスを公開します。開発者は、トランザクションが依存するリソースを文字列の形式で定義し、チェーン上の実行者に通知します。実行者は、ブロック内のすべてのトランザクションをトランザクション DAG に従って自動的に配置します。開発者によって指定されたトランザクションの依存関係。たとえば、単純な転送コントラクトでは、開発者は各転送トランザクションの依存関係が {送信者アドレス + 受信者アドレス} であることを指定するだけで済みます。さらに、開発者が転送ロジックに別のサードパーティ アドレスを導入する場合、依存関係を {送信者アドレス + 受信者アドレス + サードパーティ アドレス} として定義する必要があります。

この方法はより直感的で実装が簡単で、より一般的ですべてのスマート コントラクトに適用できますが、それに応じて開発者の肩にかかる責任も増加します。開発者はトランザクションの依存関係を指定する際に十分に注意する必要があり、依存関係が正しく記述されていない場合、結果は予測不可能になります。

パラレルフレームワーク契約フィスコ BCOS では、開発者がパラレルコントラクトのフレームワークを利用するために、いくつかの契約書作成仕様を定めています。並列ミューテックス2 つのトランザクションを並行して実行できるかどうかは、2 つのトランザクションが存在するかどうかによって異なります。。

相互排他的

• 。相互排他とは、2 つのトランザクションが相互に排除されることを意味します。操作コントラクトのストレージ変数のセット間に共通部分がありますたとえば、転送シナリオでは、トランザクションはユーザー間の転送操作です。 transfer(X, Y) を使用してユーザー X からユーザー Y への転送インターフェイスを表すと、相互排他は次のようになります。相互に排他的なパラメータ

• ：契約インターフェース

、コントラクトストレージ変数の「読み取り/書き込み」操作に関連するパラメーター。たとえば、転送インターフェイスは transfer(X, Y) です。ここで、X と Y は相互に排他的なパラメーターです。

ミューテックス

: トランザクションにおいて、相互排他的なパラメータに従って抽出された特定の相互排他的なコンテンツ。たとえば、転送インターフェイスは transfer(X, Y) で、このインターフェイスを呼び出すトランザクションの特定のパラメータは transfer(A, B) であり、この操作の相互排他的なオブジェクトは [A, B] であり、別のトランザクションです。呼び出しのパラメータは transfer(A, C) であり、この操作のミューテックス オブジェクトは [A, C] です。

２つのトランザクションを同時に並列実行できるかどうかの判断は、２つのトランザクションの相互に排他的なオブジェクトが重複するかどうかを判断することである。相互の交差部分が空であるトランザクションは並列実行できます。

FISCO-BCOS は、パラレル コントラクトを作成する 2 つの方法を提供します。1 つはソリッドティ コントラクト、もう 1 つはプリコンパイルされたコントラクトです。ここでは Solidity コントラクトのみを紹介します。プリコンパイルされたコントラクトも同様です。

堅牢性契約パラレルフレームワーク

並列 Solidity コントラクトを作成する場合、基本的に必要なのは、並列である必要があるコントラクトの基本クラスとして ParallelContract.sol を使用し、 registerParallelFunction() メソッドを呼び出して並列インターフェイスを登録することだけです。

ParallelContract コードは次のとおりです。

• 以下は、パラレルフレームワーク契約に基づいて作成された譲渡契約です。

インターフェイスが並列化可能かどうかを判断する

並列コントラクト インターフェイスは以下を満たす必要があります。

外部契約への呼び出しはありません。

• 他の関数を呼び出すためのインターフェイスがありません。

相互排除パラメータの決定

インターフェイスを作成する前に、インターフェイスの相互排他パラメータを決定する必要があります。インターフェイスの相互排他は、グローバル変数の相互排他です。相互に排他的なパラメータを決定するためのルールは次のとおりです。

• インターフェイスはグローバル マッピングにアクセスし、マッピングのキーは相互に排他的なパラメータです。"globalA",• インターフェイスはグローバル配列にアクセスし、配列の添え字は相互に排他的なパラメーターです。

• インターフェイスは単純型のグローバル変数にアクセスし、単純型のすべてのグローバル変数はミューテックス パラメータを共有し、異なる変数名をミューテックス オブジェクトとして使用します。例: コントラクトには複数の単純なタイプのグローバル変数があり、異なるインターフェイスが異なるグローバル変数にアクセスします。異なるインターフェイスを並列化する必要がある場合は、グローバル変数を変更したインターフェイス パラメーターで相互に排他的なパラメーターを定義し、呼び出し時にどのグローバル変数が使用されるかを指定する必要があります。呼び出し時に、対応して変更されたグローバル変数の「変数名」をアクティブに mutex パラメータに渡し、このトランザクションの mutex オブジェクトを示します。たとえば、グローバル パラメータ globalA が setA(int x) 関数で変更された場合、setA 関数を set(string aflag, int x) として定義する必要があり、呼び出し時に setA(

10) 変数名「globalA」を使用して、このトランザクションのミューテックス オブジェクトが globalA であることを示します。string、address、uint 256、int 256 相互に排他的なパラメータを決定した後、ルールに従ってパラメータのタイプと順序を決定します。ルールは次のとおりです。

パラメータのタイプと順序を決定する

- インターフェースパラメータは以下に制限されます。

(将来的には、さらに多くのタイプがサポートされる予定です)。- 相互に排他的なすべてのパラメータは、インターフェイス パラメータの先頭に配置されます。。

Khipu

見てわかるように、

実際、FISCO-BCOS トランザクションの並列処理は、ユーザーが作成したコントラクトの仕様に大きく依存しています。ユーザーが作成した契約書が標準化されていない場合、システムがそれを急いで並列実行すると、台帳ルートの不整合が発生する可能性があります。

最初のレベルのタイトル

概要

FISCO-BCOS とは異なり、エラーなくコントラクトを作成する際に、ユーザーが静的競合が発生するアドレス範囲を特定してマークすることは非現実的だと Khipu 氏は考えています。

レースが発生するかどうか、どこで、どのような条件で発生するかは、確定的取得が現在の状態に関係する場合にのみ判断できます。現在の契約プログラミング言語では、コードの静的解析によって完全にエラーや欠損のない結果を得るのはほぼ不可能です。

キプはこの点に関して包括的な試みを行い、プロジェクトの実施を完了しました。

プログラム詳細

Khipu の実装では、同じブロック内の各トランザクションは前のブロックのワールド状態から開始され、その後並行して実行され、実行中に理想的なエクスペリエンス パスで遭遇した上記 3 つのレースすべてが記録されます。並列実行フェーズが終了すると、マージフェーズに進みます。マージフェーズでは、並列世界のステートを 1 つずつマージしていきますが、トランザクションをマージする際には、まず、記録された静的状態から、以前にマージされた競合状態と矛盾するかどうかが判断されます。そうでない場合は、直接マージします。その場合は、以前にマージされたワールド状態からこのトランザクションを再度実行します。最終的なマージされたワールド状態は、ブロックのハッシュで決定されます。これは最後の防御線であり、検証が間違っている場合、以前の並列スキームは放棄され、ブロック内のトランザクションが直列に再実行されます。並列処理インデックス：

Khipu 氏はここで並列性インデックス、つまり、再実行せずに結果を直接マージできるブロック内のトランザクションの割合を導入しました。イーサリアムのジェネシスブロックから最新ブロックまでの数日間のリプレイ観察を通じて、Khipu 氏は、この比率 (並列性) が平均 80% に達する可能性があることを発見しました。

一般に、コンピューティング タスクを完全に並列化できれば、より多くの CPU コアを常にノードに追加できるため、単一チェーンのスケーラビリティは無限大になります。そうでない場合、理論上の最大レートは次のように制限されます。

アンダルの定理

システムを高速化できる限界は、並列化できない限界の逆です。つまり、99% の確率で並列化できれば、100 倍の高速化を達成できます。しかし、95% の並列化しか達成できない場合、20 倍の高速化しか達成できません。

競合マーカー

イーサリアムの全トランザクションを再生した場合、約80%のトランザクションは並列化でき、20%は並列化できないため、Khipuによるイーサリアム高速化の平均効率は約5倍となります。

evm コード命令を解釈すると、一部の限定された命令がストレージ用の読み取りおよび書き込みプロセスを生成するため、これらの読み取りおよび書き込み場所を記録することで読み取りおよび書き込みセットを形成できるという矛盾があることがわかります。静的コード分析だけでは、これらのプロセスが確実に記録されることはできないため、各ブロックでトランザクションを処理する際には、各トランザクションを事前に並行して実行する必要があります。実行前プロセスを通じて、これらのトランザクションが同じアカウントまたはストレージに対して読み書きするかどうかを知ることができ、トランザクションごとに readSet と writeSet を生成します。つまり、実行前プロセスでは、最初にすべてのトランザクションの初期状態としてワールド状態のコピーを複数作成します。ブロックチェーンに 100 個のトランザクションがあると仮定すると、これらの 100 個のトランザクションはスレッド プールを通じて並行して実行できます。各コントラクトは同じ初期ワールド状態を持ち、実行中に 100 個の readSet と writeSet が生成され、それぞれ 100 個の新しい状態が生成されます。

イーサリアムメインネットのトランザクションリプレイを通じて、多くの競合が存在する場合、そのほとんどは同じブロック内の取引所によって実行される相互関連したトランザクションであることがわかります。これはこのプロセスとも一致しています。

Aptos

工程流れ図

具体的な並列実行プロセス

最初のレベルのタイトル

概要

Aptos は、Diem の Move 言語と MoveVM に基づいて高スループットのチェーンを作成し、並列実行を可能にしました。 Aptos のアプローチは、ユーザー/開発者に対して透過的に関連付けを検出することです。つまり、トランザクションは、状態のどの部分 (メモリの場所) を使用するかを明示的に示す必要はありません。

プログラム詳細

Aptos は、Block-STM と呼ばれるソフトウェア トランザクション メモリの修正バージョンを使用して、Block-STM 論文に基づいた並列実行エンジンを実装しました。

Block-STM は、MVCC (Multi-Version Concurrency Control) を使用して、書き込みと書き込みの競合を回避します。同じ場所へのすべての書き込みは、tx-id と書き込み tx が再実行された回数を含むバージョンとともに保存されます。トランザクション tx が特定のメモリ位置の値を読み取るとき、トランザクション tx は、読み取り/書き込み競合があるかどうかを判断するために、MVCC から tx の前に現れた位置に書き込まれた値と関連するバージョンを取得します。 Block-STM では、トランザクションはブロック内で事前に順序付けされ、実行中にプロセッサ スレッド間で分割されて並列実行されます。並列実行では、トランザクションを実行するための依存関係がないと仮定して、トランザクションによって変更されたメモリの場所が記録されます。実行後、すべてのトランザクション結果が検証されます。検証中に、前のトランザクションによって変更されたメモリ位置にトランザクションがアクセスしていることが判明した場合、そのトランザクションは無効化されます。トランザクションの結果を更新し、トランザクションを再実行します。このプロセスは、ブロック内のすべてのトランザクションが実行されるまで繰り返されます。 Block-STM は、複数のプロセッサ コアが使用されている場合に実行を高速化します。高速化はトランザクション間の相互依存性の度合いによって異なります。

Aptos で採用されているスキームは上記の Khipu とほぼ似ていますが、実装の詳細が若干異なることがわかります。主な違いは次のとおりです。

• Khipu はブロック内のトランザクションに並列実行と逐次検証を使用しますが、Aptos はブロック内のトランザクションに並列実行と並列検証を使用します。どちらのオプションにも長所と短所があります。 Khipu のスキームは実装が簡単ですが、効率が若干劣ります。 Aptos の Block-STM 実装は、多くのスレッドで同期と信号操作を使用するため、コードで実装するのは困難ですが、より効率的です。

• Move はグローバル リソース アドレッシングをネイティブにサポートしているため、並列実行に適している場合、Aptos はブロック間であってもトランザクションを並べ替えます。関係者は、このソリューションは並列効率を向上させるだけでなく、MEV の問題も解決できると主張していますが、これがユーザー エクスペリエンスに影響を与えるかどうかはまだ検討されていません。

ベンチマーク

Block-STM を統合した後、Aptos は対応するベンチマークを作成し、順次実行と並列実行の場合の 10,000 トランザクションのブロックのパフォーマンスを比較しました。

上の図からわかるように、Block STM は、32 個のスレッドが並列実行される場合、スレッドの順次実行と比較して 16 倍の高速化を達成します。一方、Block-STM は、高競合条件下では 8 倍以上の高速化を実現します。

最初のレベルのタイトル

要約する

要約すると、一部のソリューションでは、静的および動的分析によって依存関係を見つけることができるように、ユーザーがコントラクトを作成するときに確立されたルールに従ってストレージを作成する必要があります。 Solana とSui は同様のアプローチを採用していますが、ユーザーの認識は異なります。このようなソリューションは基本的に、より良い分析結果を得るためにストレージ モデルを変更するものです。

Khipu と Aptos のソリューションはユーザーを意識しません。つまり、ユーザーはコントラクトを慎重に記述する必要がなく、仮想マシンは実行前に依存関係を動的に分析するため、依存関係の並列実行は発生しません。このタイプのスキームは実装が難しく、並列処理の程度はトランザクションのアカウント分割にある程度依存します。トランザクションの競合が多数ある場合、再実行が継続すると重大なパフォーマンスの低下につながります。アプトス氏は論文の中で、依存関係をより適切に分析し、より高速な実行速度を達成するために、将来的にはユーザー作成のコントラクトに対していくつかの最適化が行われる可能性があると述べています。

エンジニアリングの実装と効率の問題を考慮すると、OlaVM は Khipu+ カスタマイズされたストレージ モデル ソリューションを採用する可能性が最も高くなります。パフォーマンスを向上させながら、Block-STM の導入によってもたらされる複雑さを回避し、後の段階でのエンジニアリングの最適化を促進します。

2.FISCO-BCOS Github, FISCO-BCOS

3.Khipu Github, GitHub - khipu-io/khipu: An enterprise blockchain platform based on Ethereum

4.Aptos Github, GitHub - aptos-labs/aptos-core: Aptos is a layer 1 blockchain built to support the widespread use of of blockchain through better technology and user experience.

参照する：

1. Block-STM 論文: [ 2203.06871 ] Block-STM: Ordering Curse to a Performance Blessing (arxiv.org) によるブロックチェーン実行のスケーリング

最初のレベルのタイトル

私たちについて

Sin7y は 2021 年に設立され、トップのブロックチェーン開発者で構成されています。私たちはプロジェクト インキュベーターであると同時にブロックチェーン テクノロジー研究チームでもあり、EVM、レイヤー 2、クロスチェーン、プライバシー コンピューティング、自律型決済ソリューションなどの最も重要で最先端のテクノロジーを研究しています。チームは、高速でスケーラブルな EVM 互換の初の ZKVM を構築することを目的として、2022 年 7 月に OlaVM ホワイト ペーパーを発表しました。

WeChat 公開アカウント: 罪 7 年

公式サイト：https://sin 7 y.org/

ホワイトペーパー: https://olavm.org/

Github：Sin 7 y

コミュニティ: http://t.me/sin 7 y_labs