観点｜「サイドチェーン」とは何か？

2020.11.09

共有先

TechFlow厳選深潮セレクト

観点｜「サイドチェーン」とは何か？

かつて、サイドチェーンは一定レベルのイーサリアムのコンポーザビリティと相互運用性を維持しつつ利用可能な唯一の選択肢だった。現在、他のレイヤー2スケーリングソリューションが成熟しつつある中で、サイドチェーンが他のソリューションとどのようによりよく統合できるかを考える時期に来ている。

2020.11.09 - 01:35:14

侧链

Web3業界の深掘り報道に専念し潮流を洞察

著者: barryWhiteHat

翻訳: 阿剣

はじめに

レイヤー2はイーサリアムにとってますます重要になっており、その点については合意が得られている。

しかし、「レイヤー2」というラベルは不正確である。

ある人々が「レイヤー2」と言うとき、単に「イーサリアムのレイヤー1上ではないもの」を意味しているだけの場合もある。

だが実際には、個々のソリューションがどのようにイーサリアムのレイヤー1と相互作用するかという点は非常に重要である。同じ「レイヤー2」と呼ばれる異なるソリューション間でも、特性は大きく異なってもよい。

「レイヤー2」は特定の属性を持つものだけに限定されるべきだと議論することもできる（たとえば、AWS上で展開されたものは誰もがレイヤー2とは認めないだろうが、同程度のセキュリティ保証を持つ他のプロジェクトはレイヤー2と見なされていることもある）。ただし、それがここで私が扱いたいテーマではない。

ここでは、サイドチェーン（sidechains）の特性について議論したい。

サイドチェーンとは何か？

サイドチェーンの基本的な定義は、一組のバリデータが、自らのチェーンの最新状態をメインチェーン上のスマートコントラクトに提出し、それによって進化するシステムのことである。これらの状態チェックポイントはブリッジコントラクトによって利用され、ユーザーの入金・出金を可能にする。

通常、このバリデータグループ内ではリーダー選出プロセスがあり、どの時点において誰がサイドチェーンのブロックを作成するかを決定する。例としてはPoA（権威証明）やPoS（ステーク証明）アルゴリズムがある。

（注：この定義からわかるように、筆者が議論しているのは、メインチェーン上に有効性保証メカニズムを持たないサイドチェーンである。現在「サイドチェーン」という語が広く使われている文脈では、これは広義のサイドチェーンの一部に過ぎない。しかし、本来の「サイドチェーン」という概念、すなわち狭義の定義は、まさに筆者がここで述べている内容と一致している。読者が「サイドチェーン」を専門用語として捉えるか、派生的な意味で使うかは各自の判断による。）

サイドチェーンはイーサリアムエコシステムにおいても重要な役割を果たしてきた。研究者たちがより優れたソリューションを開発するまでの間、スケーラビリティと可用性のための一時的解決策として機能してきた。xDaiのような製品は、より良いユーザーエクスペリエンスの必要性を浮き彫りにし、その需要を広げた。

しかし、サイドチェーンは、広範なイーサリアムコミュニティが期待するようなセキュリティを備えていない。だからといって、サイドチェーン型のソリューションを決して使ってはいけないということではない。

ユーザーが完全に情報を把握した上で使用することを選べば、それは彼ら自身の選択であり、価値があるかもしれない。

だが、もしユーザーが無知のままそれを使ってしまうなら、それは危険である。

本稿の目的は、いくつかの情報を提供することにある。もしだれもがすでにこれらの特性を完全に理解していたなら、この文章を書くことは無害であろう。しかし、この文章が誤解に気づくきっかけになれば、有意義なことだと言える。

では、サイドチェーンはいったいどのようなセキュリティ特性を欠いているのか？ほぼすべてのサイドチェーンは次のものを提供できない：

検閲耐性（Censorship Resistance）
最終性（Finality）
資金所有権の保証

これらすべての特性を求めるなら、サイドチェーンに代わる別のソリューションを探すべきだろう。もちろん、サイドチェーンのコアアーキテクチャを維持したまま、これらの側面でのパフォーマンスを改善できる可能性はある。オープンな議論は誰にとっても有益だと思う。

検閲耐性

明らかに、サイドチェーンの検閲耐性は（よく設計された）ブロックチェーンよりも劣る。そうでなければ、そもそもブロックチェーンなど必要ないだろう。ここではさらに深く掘り下げよう。あるサイドチェーンがN人のバリデータを持ち、M人のバリデータが合意すれば任意のトランザクションを検閲できるとしよう。すると、(N-M)人のバリデータが協力すれば、ブロック全体を検閲できる。これにより興味深いジレンマが生じる：トランザクションの検閲を難しくしようとすれば、ブロックの検閲が容易になる。どちらも望ましくない事態であるため、根本的にサイドチェーンは強固な検閲耐性を得られない（注：論理はこうである。M人のバリデータがブロック生成を拒否すればシステムはブロックを生成できないため、M人で特定のトランザクションの検閲が可能になる。一方で、N-M人が合意すれば常にブロックを生成でき、特定のブロックを除外したり、集団で通信を停止したりできる）。この懸念はPoSを使用しても依然存在し、ステークに基づいてブロック生成の重みを付けるとさらに悪化する可能性がある。なぜなら、閾値に達する独立した当事者の数がさらに少なくなるためだ（最も理想的な場合ですら、ステークが均等に分散しているとしても、非PoSの場合と同等以上にはならない）。

データ可用性の保証

(N-M)人のバリデータだけで新しいブロックを作成できると仮定する。また、他のすべてのバリデータが新しい状態を検証するには、全状態データを保持している必要があるとする。この場合、(N-M)人の悪意のあるバリデータは以下の行動を取れる：

新しいブロックを作成する
正直なバリデータとブロックデータを共有しない
結果としてN-(N-M)=M人の正直なバリデータをコンセンサスプロセスから排除し、システム全体を完全に支配する

このような事態が起こる可能性はどれくらいあるだろうか？結論を出すにはより具体的な詳細が必要だが、次のように考え始めることができる：合理的なバリデータが他者とデータを共有するインセンティブは何だろうか？従来のPoA（権威証明）では、そうしないことで評判が損なわれる可能性がある。しかし実際には、データが故意に隠蔽されたことを証明するのは困難であるため、評判メカニズムもあまり機能しない。他人がすべてのデータをオンチェーンに置かない限り、証明はできない。この解決策はoptimistic rollupに似ていると思えるだろうか？確かにその通りである。つまり、より高いセキュリティを持つサイドチェーンは、本質的に「退化」してoptimistic rollupになってしまうということだ。多くのサイドチェーンでは、バリデータは自身の作業に対して何らかの報酬を得ている。正直なバリデータにとっては、報酬がN人のバリデータ間で分配される。一方、不正なバリデータにとっては、同じ報酬がN-(N-M)=M人の間でしか分配されないため、更新された状態を他者と共有しないインセンティブが生まれる（注：この計算には疑問の余地がある）。ここには根本的な問題がある：データ可用性攻撃を識別することが極めて難しい。正直なバリデータにとって、攻撃が行われたのか、それとも単なる同期問題なのかを区別することは困難である。

最終性

状態遷移のプロセスが次のように表されるとする：state1 => state2 => state3。各遷移には、既存の状態上で有効となるトランザクションが必要であり、それによって状態が変更される。最終性とは、一度有効となったトランザクションが取り消されることはないということを意味する。サイドチェーンのチェックポイントは、サイドチェーンのバリデータ間の合意を経てイーサリアムブロックチェーンに送信され、イーサリアムのコンセンサスによって固定される。そのため、一部の人々は、サイドチェーンの最終性はイーサリアムの最終性と同等であると考えるかもしれない。サイドチェーンのブロックをロールバックするには、イーサリアムのブロックもロールバックしなければならないからだ。しかし、これは完全に誤解である。なぜなら、最終性とはトランザクションのロールバックが不可能であることであって、古い状態を新しい状態で置き換えることが不可能ということではない。たとえ(N-M)人のバリデータが合意すれば、以下のような状態遷移が可能である：state1 => state2 => state1（state3をstate1で置き換えることで、既に確定済みとみなされていたstate2をロールバックしているが、これにはイーサリアムメインチェーンのロールバックは不要である）。

サイドチェーンにおける資金所有権の保証

現在の状態が state1={Alice:1000,Bob:0} であるとする。つまり、Aliceは1000単位の資産を持っており、Bobは持っていない。ここで、Bobが悪意を持っており、POAバリデータの大多数を制御または効率的に腐敗させられる場合、彼はどのように行動できるだろうか？彼は状態遷移を実行し、state1 => state2、そしてstate2={Alice:0,Bob:1000}とすることができる。つまり、Aliceのすべての資金を盗んでBobに与えるのである。したがって、サイドチェーンの防御は、「(N-M)人のバリデータが同意しない限り、そのような不正な状態遷移は実行されない」ということに帰着する。これは周知の事実である（少なくとも私はそう信じている）が、改めて注意喚起する価値がある。あなたがサイドチェーンに抱く信頼とは、バリデータの大多数がそのような行為を行わないという信頼に限られる。サイドチェーンに関するほとんどのセキュリティ分析は、この点に集中すべきである。ある程度信頼できる人物がいるかもしれない。私たちの多くが（さまざまな理由から）中央集権的なサービスプロバイダーを信頼しているのと同じように。時にはそのような妥協は価値があるかもしれない。重要なのは、それが一種のトレードオフであることを認識していることだ。

ガバナンス手順を防御手段として用いることの問題点

「上記のすべての問題はガバナンス手順を使って解決できる」と主張する人もいる。しかし、このアプローチには欠陥がある。なぜなら、システム全体がガバナンスプロセスに依存してしまうからだ。特に私が懸念するのは、その場合、サイドチェーンの他の属性は「劇場」（theater）と化してしまう点である（では、なぜそのような属性が必要なのであろうか？）。たとえば、ガバナンスプロセスが上述の問題に対する最終的な防衛手段であるならば、PoSやPoAといった合意アルゴリズムは本質的に意味を失う。システムのガバナンスこそが真のPoA（権威証明）になってしまうのだ。そしてもちろん、ガバナンスプロセス自体にも、まったく同じ種類の攻撃が可能である。

サイドチェーンの特性が特に有用になりうる場面

より速いブロック生成時間（したがってより良いユーザーエクスペリエンス）といったサイドチェーンの追加的特徴に加えて、サイドチェーンの特性が特に活かせる場面も確かに存在する。例えば：

N-M人のバリデータだけで任意の状態遷移を実行できる仕組みが欲しい場合。高度な管理権限を必要とする企業向けアプリケーションなどが該当する。
M=0かつN人のバリデータが任意の状態遷移を実行できる場合。たとえば四者参加型ゲームなど。ただし問題は、1人のバリデータだけでそのチェーンを停止できてしまうことだ。