原文編纂：南峰
原文編纂：南峰
ただし、この目標の課題の 1 つは、複雑さを定義するのが難しく、場合によっては、異なる種類の複雑性と異なるコストを導入する 2 つのオプションの間でトレードオフを行わなければならないことです。どのように比較すればよいでしょうか?
複雑さについてより細かく考えることを可能にする強力でインテリジェントなツールは、いわゆるカプセル化された複雑さと、システムの複雑さ(systemic complexity)。
「カプセル化された複雑さ」は、システムのサブシステムが内部的には複雑であるが、外部に対しては単純な「インターフェイス」を提供する場合に発生します。 「システムの複雑さ」は、システムのさまざまな部分が明確に分離することさえできず、相互に複雑な相互作用がある場合に発生します。
以下にいくつかの例を示します。
BLS 署名と Schnorr 署名
BLS 署名と Schnorr 署名は、楕円曲線で構成できる 2 つの一般的に使用される暗号署名スキームです。
BLS 署名は数学的に非常に単純に見えます。
H はハッシュ関数、m はメッセージ、k と K は秘密鍵と公開鍵です。ここまではシンプル。しかし、本当の複雑さは、暗号全体の中で最も不可解な数学的部分の 1 つである楕円曲線ペアの e 関数の定義に隠されています。
次に、Schnorr 署名を見てみましょう。 Schnorr 署名は基本的な楕円曲線のみに依存します。ただし、署名と検証のロジックはもう少し複雑です。
例えば：
例えば：
BLS マルチ署名 (2 つの鍵 k1 と k2 の結合署名) の実行は簡単で、σ1+σ2 だけです。しかし、Schnorr マルチ署名では 2 ラウンドの対話が必要であり、いくつかのトリッキーなキーキャンセル攻撃に対処する必要があります。
Schnorr 署名では乱数を生成する必要がありますが、BLS 署名ではその必要はありません。
副題
暗号学と暗号経済学
多くのブロックチェーン設計で生じる重要な設計上の選択は、暗号化と暗号経済学の比較です。これ（ロールアップの場合と同様）は、多くの場合、有効性証明（つまり ZK-SNARK）と不正証明の間で選択されます。
ZK-SNARK は複雑なテクノロジーです。 ZK-SNARK の動作の背後にある基本的な考え方は 1 つの記事で明確に説明できますが、一部の計算を検証するために ZK-SNARK を実際に実装するには、計算自体よりも何倍も複雑な作業が必要です (したがって、ZK-SNARK が次のことを証明するのはこのためです) EVM はまだ開発中ですが、EVM の不正行為の証明はすでにベータ版です)。 ZK-SNARK 証明を効率的に実装するには、特殊目的に最適化された回路設計、なじみのないプログラミング言語の使用、その他多くの課題が伴います。一方、不正行為の証明自体は単純です。誰かが異議を申し立てた場合、オンチェーンで直接計算を実行するだけです。効率性を高めるために、二分探索スキームが追加されることもありますが、それでもそれほど複雑にはなりません。
ZK-SNARK は複雑ですが、その複雑さはカプセル化された複雑さです。一方、不正行為の証明の複雑さが比較的低いのは、システムの複雑さです。以下は、不正行為の証明によってもたらされるシステムの複雑さの例です。
バリデーターのジレンマを回避するには、慎重なインセンティブ エンジニアリングが必要です。
コンセンサスに基づいて行われた場合、不正行為の証明に追加のトランザクション タイプが必要になりますが、同時に不正行為の証明を提出するために多くの参加者が競合した場合に何が起こるかも考慮されます。
これらは同期ネットワークに依存しています。
検閲攻撃が窃盗にも利用できるようになります。
不正防止ベースのロールアップでは、即時出金をサポートする流動性プロバイダーが必要です。
副題
さまざまな例
PoW (ナカモト・コンセンサス):メカニズムが非常にシンプルで理解しやすいため、カプセル化の複雑さは低くなりますが、システムの複雑さは高くなります (利己的マイニング攻撃など)。
ハッシュ関数:パッケージングは非常に複雑ですが、特性がよく理解されているため、システムの複雑さは低くなります。
ランダムシャッフルアルゴリズム:シャッフル アルゴリズムは、内部的には複雑ですが (Whisk など)、強力なランダム性が確保されていて理解しやすい場合もあります。または、内部的には単純ですが、脆弱で分析が難しいランダム プロパティ (システムの複雑さなど) が生成される場合もあります。
マイナー抽出値 (MEV):複雑なトランザクションをサポートするのに十分強力なプロトコルは、内部的にはかなり単純かもしれませんが、それらの複雑なトランザクションは、非常に異常な方法でブロックを提案することにより、プロトコルのインセンティブに複雑な体系的な影響を与える可能性があります。
バークルの木:副題
それをどのように比較検討すればよいでしょうか?
通常、パッケージングの複雑さが低いオプションは、システムの複雑さも低いオプションでもあるため、明らかにより単純なオプションが 1 つあります。しかし、ある複雑さと別の複雑さの間で難しい選択をしなければならない場合もあります。この時点で、複雑さをカプセル化していれば危険性が低いことは明らかです。システムの複雑さによってもたらされるリスクは、仕様の長さの単純な関数ではありません。他の部分と相互作用する仕様の小さな 10 行の断片は、そうでなければ考慮される 100 行の関数よりも複雑になります。ブラックボックス。
ただし、複雑さのカプセル化を優先するこのアプローチには制限があります。ソフトウェアのバグはコードのどの部分にも発生する可能性があり、コードがますます大きくなると、エラーの確率は 1 に近くなります。新しい予期しない方法でサブシステムと対話する必要がある場合、カプセル化の複雑さとして始まったものが、システムの複雑さになる場合があります。
後者の例は、イーサリアムの現在の 2 レベルの状態ツリーです。これは、アカウント オブジェクトのツリーを特徴とし、各アカウント オブジェクトが独自のストレージ ツリーを持っています。
このツリー構造は複雑ですが、最初はこの複雑さがうまくカプセル化されているように見えます。プロトコルの残りの部分は、読み取りおよび書き込み可能なキー/値ストアとしてツリーと対話するため、ツリーがどのように構築されているかを心配する必要はありません。 。
しかし、後になって、この複雑さがシステムに影響を与えることが判明しました。アカウントが任意に大きなストレージ ツリーを持つことができるということは、特定の状態部分 (たとえば、「0x1234 で始まるすべてのアカウント」) が予測可能なサイズを持つことを確実に期待する方法がないことを意味していました。 。これにより、状態を複数の部分に分割することが難しくなり、同期プロトコルの設計が複雑になり、ストレージ プロセスを分散する試みが複雑になります。なぜパッケージングの複雑さが全体的なものになるのでしょうか?インターフェイスが変わったからです。解決策は何ですか? Verkle ツリーへの移行に関する現在の提案には、バランスの取れた単一レベルのツリー設計への移行も含まれています。
結局のところ、どのような状況においてもどのタイプの複雑さが好まれるかということは、簡単に答えられる問題ではありません。私たちにできる最善のことは、カプセル化の複雑さを適度に、しかし過剰にならないようにサポートし、具体的なケースごとに判断を下すことです。持っている場合によっては、システムの複雑さを少し犠牲にして、パッケージングの複雑さを大幅に軽減することが実際にベスト プラクティスとなることがあります。また、何がカプセル化され、何がカプセル化されていないのかを見誤ることさえあるかもしれません。状況はそれぞれ異なります。
