「サイドチェーン」がわかるこの記事

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfa​​ns)編集者注: この記事は以下から引用しました

イーサリアム愛好家 (ID: ethfa​​ns)

、著者：barryWhiteHat、翻訳：A Jian、Odailyによる許可を得て転載。

導入

免責事項: ここで表明された意見は私自身のものであり、必ずしも私の雇用主や他の誰かの意見を代表するものではありません。

読んでコメントしてくれた Albert Ni に感謝します。

導入

イーサリアムにとってレイヤー 2 の重要性は日に日に高まっており、コンセンサスが得られています。

ただし、「Layer-2」は不正確なラベルです。一部の人が「レイヤー 2」について話すとき、それは単に「イーサリアムのレイヤー 1 にないもの」を意味します。しかし実際には、ソリューションが Ethereum Layer-1 とどのように対話するかが非常に重要です。同じ「レイヤー 2」名の下にある異なるソリューションの特性は、大きく異なる場合があります。 「レイヤー 2」とは、特定のプロパティを持つものを指すべきだと主張することもできます (たとえば、AWS にデプロイされているものはレイヤー 2 ではないということにはおそらく誰もが同意できますが、同様のセキュリティ保証を備えたプロジェクトもいくつかあります)。レイヤ 2 が考慮されます)。ただし、これはここでの私の議論の主題ではありません。

ここで説明するのはサイドチェーンの特性です。

サイド チェーンの基本的な意味は、検証者のグループがチェーンの最新の状態を (メイン チェーン上の) スマート コントラクトに送信することで、ある種のシステムを促進することです。これらの（最新の）チェックポイントは、ユーザーの入金と出金をサポートするためにブリッジ コントラクトで使用できます。一般的に言えば、特定の時点で誰がサイドチェーンブロックを作成するかを決定するために、この検証者のグループの間で、PoA 権限証明アルゴリズムや PoS アルゴリズムなどのリーダー選出プロセスも行われます。 （訳者注：この定義から、著者が議論しているのは、メインチェーン上に設計された正当性保証機構を持たないサイドチェーンであることがわかります。現在の広義の「サイドチェーン」の定義によれば、著者は先生は一般化した側鎖について議論していますが、本来の「側鎖」、つまり狭義の側鎖概念は著者がここで提唱しているものと全く同じです。 " を固有名詞として使用することも、その派生した意味を喜んで使用することもできます。)

• サイドチェーンもイーサリアムのエコシステムで重要な役割を果たします。これらは、研究者がより良いものを開発するまでの、スケーラビリティと使いやすさのための一時的な修正です。 xDai のような製品も、より良いユーザー エクスペリエンスとそれを広める必要性を指摘しています。

• ただし、サイドチェーンには、広範なイーサリアム コミュニティが期待するセキュリティがありません。これは、サイドチェーンを決して使用すべきではないということではありません。人々が十分な情報を持っていて、喜んでそれを使用するのであれば、それは彼らの選択であり、価値があるかもしれません。しかし、人々が知識を持たなければ、それは危険です。この記事は、いくつかの情報を提供することを目的としています。誰もがすでにこれらの機能を十分に認識しているのであれば、私が別の記事を書いても問題はありません。しかし、この記事が人々の誤解に気づくのに役立つのであれば、それは良いことです。

• では、サイドチェーンにはどのようなセキュリティ機能が欠けているのでしょうか?ほとんどすべてのサイドチェーンは以下を提供できません。

検閲への抵抗

資金の所有権の保証

これらすべての機能が必要な場合は、サイドチェーンを置き換える別のソリューションを見つける必要があるかもしれません。もちろん、サイドチェーンのコア アーキテクチャを維持しながら、これらの次元で特定のソリューションのパフォーマンスを向上させることも可能です。

オープンな議論は誰にとっても良いことだと思います。

検閲への抵抗

明らかに、サイドチェーンは（適切に設計された）ブロックチェーンよりも検閲耐性が低いです。それ以外の場合、ブロックチェーンはまったく必要ありません。しかし、ここではもう少し深く掘り下げてみましょう。

特定のサイドチェーンに N 人の検証者がいて、M 人の検証者が全会一致で同意する限り、どのトランザクションもレビューできる場合、ブロックをレビューするには (NM) つの検証者だけが団結する必要があります。これは興味深いジレンマにつながります。トランザクションの検閲が困難になると、ブロックの検閲が容易になります。トランザクションの検閲とブロックの検閲は悪いことであるため、サイドチェーンは基本的に堅牢な検閲耐性を達成することができず、システムはブロックを生成できないため、当然のことながら、ブロックの生成を拒否してトランザクションをレビューする必要があるのは M 人の検証者だけですが、これはまた、 NM 検証者が同意する限り、ブロックを任意に生成できます (特定のブロックではなく他のコンテンツを含むブロック、またはグループプレイさえ消滅します)。

• この懸念は、PoS を使用する場合にも続き、ステークごとにブロックの重みを計算しても、しきい値に達する独立エンティティの数が少なくなる可能性があるため、状況はさらに悪化します (フルステークの最良のケースでも、均等に分散されており、PoS を使用しない場合とまったく同じです)。 、良くなりません）。

• データ可用性の保証

• (NM) バリデータのみがブロックを作成できると仮定します。さらに、新しい状態を検証するには、他のすべてのバリデーターが状態データ全体を持っている必要があると仮定します。次に、(NM) バリデーターが悪意がある限り、次のことが可能になります。

新しいブロックを作成する

正直なバリデーターとのブロックデータの共有を拒否する

基本的にコンセンサスプロセスから N-(NM) = M 人の正直なバリデータを削除し、システムを完全に制御します

これが起こる可能性はどのくらいですか?結論を導き出すには明らかに、より具体的な詳細が必要ですが、次のように考えることができます。合理的なバリデーターが他のユーザーとデータを共有するインセンティブはどこにあるのでしょうか?従来の権威証明メカニズムでは、そうしないと評判が損なわれる可能性があります。ただし、誰かがすべてのデータをチェーンに載せない限り、実際にはデータが保留されていることを証明する方法がないため、評判メカニズムも機能するのが困難です。このソリューションは楽観的なロールアップのように聞こえると思いますか?そうです、それです。これは、セキュリティが向上したサイドチェーンは本質的に楽観的なロールアップに「退化」することも意味します。

ほとんどのサイドチェーン スキームでは、バリデーターはその作業に対して何らかの形で支払いを受け取ります。正直なバリデーターの場合、報酬は N 人のバリデーター間で共有されます。不正なバリデーターの場合、同額の報酬は N-(NM)=M 個のバリデーターの間でのみ共有されるため、バリデーターには更新された状態を他の人と共有しないというあらゆる動機があります (翻訳者注: ここでの計算は間違っていると思われます)。

state1 => state2 => state3

ここには根本的な問題があります。それは、データ可用性攻撃を識別することが難しいということです。正直な検証者にとって、誰かが攻撃を開始したかどうか、または同期に問題があるかどうかを判断することは困難です。

ファイナリティ

状態遷移の流れは次のようになるとします。

state1 => state2 => state1

また、各変換では、状態を変更するために既存の状態にいくつかのトランザクションを適用する必要があります。ファイナリティとは、トランザクションが一度有効になると取り消すことができないことを意味します。

サイドチェーンのチェックポイントは、サイドチェーン検証者のコンセンサスを経てイーサリアムブロックチェーンに送信され、イーサリアムのコンセンサスメカニズムに従って固定化されます。したがって、サイドチェーンのファイナリティはイーサリアムのファイナリティと同等であると考える人もいるかもしれませんが、サイドチェーンのブロックをロールバックするには、イーサリアムのブロックもロールバックする必要があります。しかし、これはすべて間違っています。

ファイナリティはトランザクションをロールバックできないことを意味するため、古い状態を新しい状態に置き換えることができないという意味ではありません。 (NM) バリデーターが同意する限り、次の状態遷移を実行できます。

(state1 を使用して state3 を置き換えることは、デフォルトで完了した state2 をロールバックすることと同じですが、これには Ethereum メインチ​​ェーンをロールバックする必要はありません。)

サイドチェーンファンドの所有権保証

現在の state1={Alice:1000, Bob:0} であるとします。つまり、アリスは 1000 元を持っていますが、ボブは何も持っていません。では、ボブが悪意を持って大多数の POA バリデーターを制御している (または効率的に破壊できる) 場合、ボブは何ができるでしょうか?

彼は、state1 => state2 および state2={Alice:0,Bob:1000} という状態遷移を実行できます。つまり、アリスのお金をすべて盗んでボブに渡します。

したがって、サイドチェーンの防御は、そのような違法な状態遷移の実行に同意する (NM) バリデーターが存在しないという事実に帰着します。

これはすでに知られています（少なくとも私はそう信じています）が、皆さんに思い出していただく必要があると思います。大多数のバリデーターがそのようなことをしないと信じる場合にのみ、サイドチェーンに信頼を置くことができます。サイドチェーンのセキュリティ分析のほとんどはこれに焦点を当てる必要があります。

ある程度信頼できる人はまだいるかもしれません。私たちの多くが（さまざまな理由から）集中型サービスプロバイダーを信頼しているのと同じです。時には犠牲を払う価値があることもあります。これはトレードオフであることを理解することが重要です。

防御手段としてガバナンスプロセスを使用する場合の問題

• 「ガバナンス手順を利用すれば、上記の問題はすべて解決できる」という格言があります。このアプローチには欠陥があります。システム全体が 1 つのガバナンス プロセスに堕落してしまうからです。このステートメントが私を特に懸念させる理由の 1 つは、サイドチェーンの他のプロパティがシアターであることを暗示していることです (そのようなプロパティがいつ、なぜ必要になるのでしょうか?)。例えば、ガバナンスプロセスが上記の問題を防ぐ究極の手段であるならば、PoSもPoAも重要ではないことを意味します。システムのガバナンス プロセスが本当の PoA です。さらに、同じ攻撃がシステムのガバナンス プロセスに対して開始される可能性があることは明らかです。

• ブロック時間の高速化 (したがってユーザー エクスペリエンスの向上) など、サイドチェーンのいくつかの追加特性を除けば、サイドチェーンの機能が輝ける場面が実際にあります。例えば：

エピローグ

NM バリデーターが任意の状態遷移を実行できるようにしたいだけです。例としては、高度な制御が必要なエンタープライズ アプリケーションが挙げられます。

M=0 で N 個の検証者が任意の状態遷移を実行できる場合。例えば、４者が参加するゲーム。しかし問題は、1 つのバリデータがチェーンをシャットダウンできることです。

• エピローグ

• かつては、イーサリアムとの一定レベルの構成可能性と相互運用性を維持しながら利用できる唯一のソリューションはサイドチェーンでした。現在、他のレイヤー 2 スケーリング ソリューションが成熟しているため、サイドチェーンを他のソリューションとより適切に統合する方法を検討する時期が来ています。

• サイドチェーンの統合に適したプロパティがいくつかあります。

• 手数料無料で大規模な移行を実現し、ユーザーが手数料のために動けなくなり退出できなくなることを防ぎます。

リーダーの選出を、より検閲に強い他のものに置き換えます (PoS は間違った方向性である可能性があります。この投稿を参照してください)