ブリッジの重要性・危険性について解説する【Ethereumの基礎講座】
こんにちは、マナブです。
本日は「イーサリアムのブリッジ」について解説します。
本記事で解決する悩み
- ブリッジって何？なんで重要なの？
- どういった問題や危険性があるの？
- 有名なプロジェクトは、どこかな？
上記のとおり。
そして、まずは下記もご覧ください。
ここまで読んだ方の反応
う〜む、ブリッジか。よく分からないし、これは上級者向けかな。別に細かい知識に興味ないし、この記事はスルーするか。
こういった方へ。ちょっとお待ちください。
というのも、クリプトの世界を理解するには、ブリッジの理解が必須です。
イーサリアムの開発者達が「最も力を入れている分野」といっても、過言じゃないです。
記事を読むことで「イーサリアムの哲学」も学べるはずです。
10分くらいで読めますので、是非お付き合いくださいませ。
本記事のもくじ
- １．Ethereumのブリッジとは（基本）
- ２．最近は「ブリッジの事故」が多い件
- ３．レイヤー２の「基礎知識」を学ぼう
１．Ethereumのブリッジとは（基本）
結論としては、下記の画像のとおりです。
画像のとおりですが、ブリッジは「イーサリアム」と「レイヤー２」を繋いでいます。なお、画像右側の「レイヤー２」の中には「Optimism (オプティミズム)」や「Arbitrum (アービトラム)」と記載されていますが、ここに関しては後述します。
なぜ、レイヤー２が重要なのか？
結論は「イーサリアムの高速化のため」です。現状のイーサリアムは、かなり遅いです。仮に「コインの交換」をイーサリアム上で実行しようとすると、３分ほどかかります。人によっては「３分＝早い」と感じるかもですが、そうでもないです。
ゲームを例にして、速度について考えてみる
例えばですが、皆さんはスマホゲームを使ったことがありますよね。大半のゲームには「アイテムの獲得」や「交換」の機能があります。ゲーム内でポイントを貯めて、そしてアイテムと交換するなど。
では、アイテム交換のたびに「３分の待ち時間」があったら、どう思いますか？ 待つのが面倒で、たぶんアプリを閉じますよね。ちょっと極論かもですが、現在のイーサリアムはこのような状況です。
遅いチェーンだと、ゲームが出来ない
現状のイーサリアムは遅いです。なので「イーサリアム上にメタバース」を作ったとしても、現状だと機能しないはず。
というのも、メタバース内で「アイテム交換」をするたびに、ユーザーが３分くらい待たされます。これじゃあ、大半の人は離脱するはず。こういった問題解決に動いているのが、レイヤー２やブリッジの技術です。
※補足①：ゲームを例にしましたが、その他のアプリでも同じです。例えば「ブロックチェーン上のTwitter」があったとして、ツイートするのに時間がかかったら、誰も使わないですよね。ある程度の速度がないと、実用的じゃないです。
※補足②：イーサリアム上でのコイン交換に「３分ほどかかる」と記載しましたが、正確には時間は変動します。イーサリアムの混み具合にもよりますが、利用者の少ない時間だと「30秒くらい」が目安で、利用者の多い時間だと「３分以上」という感じです。
ブリッジの仕組みを考察する
先ほどの画像を、再度引用します。
ブリッジの真ん中に「Bridge Node」と書かれていますよね。これは要するに「ブリッジのPC」のことです。もっと言うと「ブリッジを管理するパソコン」ですね。そして、このパソコンには「シーケンサー」という機械が繋がっています。シーケンサーとは「シーケンス (=順番) を制御する機械のこと」です。
シーケンサーが、データを保存する
この「シーケンサー」が、要するに「管理者」というイメージです。下記のとおり。
シーケンサーの役割は「データの保存」です。取引データを保存しつつ、定期的に「イーサリアムへの提出」をします。このシーケンサーがあるからこそ、レイヤー２のセキュリティが保たれている訳です。
※補足：シーケンサーの動きを深く学びたい方は「(Almost) Everything you need to know about Optimistic Rollup」をご覧ください。
シーケンサーが「故障 or 不正」をしたらどうする？
ここまで読んで、わりと多くの人は「シーケンサーが管理人なら、その管理者が”故障 or 不正”をしたらどうなるんだ…？」という疑問を持つかもです。ここに関しては解決策があります。詳しくは「記事の後半」で解説します。
イーサリアム単体で高速化できないのか？
レイヤー２は素晴らしいですが、そもそも論として「イーサリアム単体で、もっと高速化できないのか？」という疑問も湧きますよね。ここに関しても記載しておきます。
結論：ブロックチェーンのトリレンマです
上記の画像が「ブロックチェーンのトリレンマ」です。３つの言葉がありますが、これら３つを、同時に満たすことが出来ません。イーサリアムの場合は、下記のとおり。
ブロックチェーンのトリレンマ：イーサリアム版
イーサリアムの場合は「非中央集権」と「安全性」を目指している訳です。なので「拡張性」が犠牲になっています。この犠牲となった拡張性を補うために、現在は「レイヤー２」の技術を開発している訳ですね。他の例としては、下記が「Solana(ソラナ)」の事例です。
ブロックチェーンのトリレンマ：ソラナ版
ソラナチェーンも伸びていますが、ソラナの場合は「非中央集権」の部分を犠牲にしています。というのも、ソラナの場合は「処理速度がめちゃくちゃ早い＝個人がソラナのノードを運営するのは難しい＝ノード運営が中央集権化する」といった仕組みだからです。
イーサリアムとソラナの「ノード数」を比較してみる
上記のとおり。とはいえ、、そこまで数字に大きな差はないですよね。実際のところ、現状のイーサリアムは「ノードが中央集権化している」という状況です。イーサリアムの最大の強みは「分散性」ですが、まだまだ「理想的な状況」は達成できていません。
２．最近は「ブリッジの事故」が多い件
ここからは「ブリッジの事故」について解説します。ブリッジは重要な技術ですが、しかし最近は「ブリッジの事故」が多いです。
- 事例①：ワームホールの事件
- 事例②：ポリゴンチェーンのバグ
- 事例③：オプティミズムのバグ
ここ１〜２ヶ月で、事故が連発しています。その理由として、下記をご覧ください。
上記のとおりで、要するに「ブリッジの中間には、お金が貯まる」という仕組みなんですよね。ハッカー視点で考えたら「ブリッジを狙う→効率的に稼げる」を意味します。なのでブリッジの事故が増えている訳です。順番に事例を見ていきます。
事例①：ワームホールの事件
2022年2月2日に、Wormholeというプロジェクトがハッキングされました。被害総額は「約320億円」です。原因としては、下記のとおり。
tl;dr - Wormhole didn't properly validate all input accounts, which allowed the attacker to spoof guardian signatures and mint 120,000 ETH on Solana, of which they bridged 93,750 back to Ethereum.— samczsun (@samczsun) February 3, 2022
詳細は「上記のホワイトハッカーの解説」を呼んでほしいですが、簡単にまとめると「署名の偽造」です。ブリッジを使う際には、必ず「署名」の技術が使われます。
例えば「１イーサ」をブリッジで移動するなら、移動前に「このイーサは、自分のモノです」という署名をする訳です。この署名があるからこそ、お金を引き出せます。しかしワームホールを襲ったハッカーは、この署名を偽造しました。プログラムコードのミスが原因です。
事例②：ポリゴンチェーンのバグ
ポリゴンチェーンに関しては、直近で２つも事件があります。
- その(1) ブリッジの署名に関するミス
- その(2) 出金のプログラムコードのミス
その(1)に関しては、詳細な内容は「Polygon Lack Of Balance Check Bugfix Postmortem」をご覧ください。要約すると「プログラムのバグを利用することで、署名を偽装できた」という問題です。なお、注目すべきは「被害額」です。
被害額は「全体の９２％」の流出です
幸いなことに、今回のバグは「ホワイトハッカー」が指摘をしたので、資金流出しませんでした。しかし仮に流出していたら、巨大するぎる被害です。
The problem was a "critical" vulnerability in Polygon's proof-of-stake genesis contract, which could have allowed attackers to steal over 9.2 billion MATIC tokens (currently worth over $24 billion). The total supply of MATIC tokens is 10 billion.
上記は「The Block」という媒体からの引用ですが、ハッカーは「9.2ビリオンのトークンを盗むことができた」と書かれています。これはポリゴンチェーンが発行するMATICトークンの「92％」に相当します。
さらにいうと、ポリゴンチェーンは「その(2) 出金のプログラムコードのミス」というミスも起こしています。詳しい内容は、ホワイトハッカーが書いた「Double spending bug in Polygon’s Plasma bridge」の記事をご覧ください。そして注目すべきは下記です。
If I had to guess why the bug happened, I would say it might be due to using someone else’s code and not having a 100% understanding of what it does.
ホワイトハッカーが言うには、今回のバグの原因は「ポリゴンチェーンの開発者が、他人のコードを利用しつつ、そのコードを100%理解していなかったからだ」と指摘しています。人間のミスは仕方ないことでもありますが、、ブリッジの危険性が伝わりますよね。
被害が起きていたら、どうなるのか？
仮に「大量のMATICトークンが流出する」といった被害が起きていたら、ポリゴン上にあるDeFiは大打撃だったはず。例えば「Uniswap」もポリゴン上にありますが、そこにあるコインは、たぶん盗まれますよね。
なにせハッカーは「大量のMATICトークン」を持っている訳なので、簡単に「Uniswap上のイーサ」などと交換できます。僕はポリゴンの利用者だったのですが、今回の事件を見てから、資金の７割を抜きました。
事例③：オプティミズムのバグ
2022年2月2日に、レイヤー２で有名な「Optimism (オプティミズム)」にもバグが発見されました。内容は「Geth (＝ゲス) のバグ」です。Gethとは、要するに「イーサリアムを簡単に操作するためのツール」です。
イーサリアムのネットワークに参加するには、ノードを立てる必要があります。 その際に「Geth」といったツールを使い、イーサリアムのネットワークを操作します。Gethを使わなくても操作できますが、それだと大変なので、ほぼ全員がGethを使っています。
被害は起こりませんでした
今回のバグは「ホワイトハッカー」が発見しました。なので、被害が起きていません。しかし被害が起こっていたら、大きな混乱が起きたはず。というのも、今回のバグでは「ハッカーが、全てのトークンにアクセス可能」という状況だったからです。
オプティミズムには「約340億円」が入っていますので、ここにある資金に被害が及んだはずです。かつ、ハッカーが「レイヤー１への資金移動」にも成功した場合は、イーサリアムにも被害が及んだ可能性があります。
レイヤー２は、別に安全じゃない
よくある話で「レイヤー２はセキュリティが強い」と言われたりします。しかし、正確には、下記のように考えるべきだと思います。
- レイヤー２は、理論的にはセキュリティが強い
- レイヤー２は、実際には、まだまだ問題がある
上記のとおり。イーサリアム創設者のヴィタリック氏は「ブリッジの未来には楽観的である」といった発言をしていますが、これはあくまで「未来の話」です。現状のブロックチェーンには、数々の問題があります。なのでブロックチェーンやDeFiに資金を入れる際には、よく考えてみてください。
なお、こんなことを書きつつも僕は、貯金の９割をブロックチェーン上のDeFiで運用しています。資金を入れつつ、学習しています。DeFiの未来を感じています。なお、DeFiを深く学びたい方は「DeFiを理解するための基礎ガイド」を参考にどうぞ。
補足：最悪の事態が起きたら、どうするか？
参考までに、仮に「レイヤー２の領域で、破壊的な被害が起きた場合」を考えてみます。結論としては「ハードフォークされる可能性が高い」と思います。ハードフォークとは、チェーンの分岐のことです。要するに下記のとおり。
- 手順(1) 破壊的な被害が発生する
- 手順(2) 対策方法の議論が始まる
- 手順(3) ハードフォークが選択される
- 手順(4) チェーンが元の状態に戻る
- 手順(5) 大半の被害はリセットされる
上記のとおり。実は、昔のイーサリアムでも同じことが起こっています。名称は「The DAO事件」と呼ばれています。ハッカーに大量のイーサを盗まれたのですが、コミュニティの決定で「ハードフォーク」が起こりました。その結果として、被害がリセットされた訳です。
とはいえ、、ハードフォークが起こってしまうと、そもそもの「ブロックチェーンへの信頼」が揺らぎますよね。なので、実行前に「要検討すべき」ですが、とはいえ破壊的な被害が起きた場合には、ハードフォークという選択肢が残されています。
※注意点：ハードフォークをしたからといって、全ての被害を消すことはできません。というのも、現状のレイヤー２やブリッジの世界では、色々なチェーンが繋がっています。それぞれの整合性を保たないといけないので、かなり難しい問題です。最終兵器はハードフォークですが、しかし必ずしも「全員が助かる」という状態には戻らないはずです。
３．レイヤー２の「基礎知識」を学ぼう
最後に「補足的なチャプター」として「L2BEAT」を紹介します。
L2BEATでは、レイヤー２の比較ができます。記事で紹介した「オプティミズム」も「４位」にありますね。こちらのサイトを理解することで、ブリッジへの理解も深まりますので、解説しておこうと思います。
５つの指標を学んでいきます
画像の「赤枠」に着目してください。下記のように書かれています。
- State validation
- Data availability
- Upgradeability
- Sequencer failure
- Validator failure
上記のとおり。ぶっちゃけ、よく分からないですよね。僕もそうでした。なので学びつつ、１つ１つを調べましたので、ここで共有していきます。
State validation = セキュリティの検証方法
直訳すると「状態の検証」です。これは要するに「セキュリティの検証方法」を意味します。まずは下記の２つをご覧ください。
- 検証方法①：Fraud proof（不正があったら、話し合いによって検証される）
- 検証方法②：ZK proofs [Validity proofs]：不正が起きないように数式で管理
上記のとおり。なお、ここだけを見ると「ZK proofsの方が、数式で管理されてるので安心では？」と感じるかもですが、ZK proofsには「実装が難しい＆拡張性を犠牲にする」といった問題点があります。とはいえ、将来的には「ZK proofsが主流になるだろう」と言われています。
Data availability = データの有効性
直訳すると「データの有効性」で、これは要するに「問題が起きたときに、各自がデータ検証できるか」という意味です。大半のプロジェクトは「Data availability」が「On chain」だと書かれています。これなら問題なし。つまり「チェーンの上で、データの検証ができます」という意味です。より詳しくは、下記のとおり。
If there is a dispute, users could independently re-create the L2 state and ensure continued system operation or trustlessly exit to L1.
翻訳すると「問題が起きた場合は、データの再発行をしたり、もしくはレイヤー１に脱出することができます」と書かれています。こういった仕組みだと、レイヤー２を使うときに安心ですよね。
Upgradeability = アップデートが可能か
こちらの意味は「根本となるコードのアップデートが可能か？」という意味です。そして、大半のプロジェクトは「Yes」となっています。これはつまり「運営が、お金を持ち逃げすることが可能」であることを意味します。
レイヤー２はブロックチェーン上で動いています。そしてプログラミングコードはブロックチェーン上に記載されています。なので本来なら「コードを書き換えることは、不可能なのでは？」と考えますよね。しかし実際には「システム稼働時に、どのコードを使うのか」という点は変更できます。なので運営が新しいコードを書き、そのコードに悪意があるなら、資金の持ち逃げが可能です。
とはいえ、、上位プロジェクトに関しては、運営が不正をするリスクは少ないはず。仮に不正が起こったら、自分達の信頼を失うだけですからね。そして信頼を失うだけじゃなく、プロジェクトの将来性も消え去ります。このように考えると、現時点で運営が不正をする可能性は低いと思います。
Sequencer failure = シーケンサーの故障
シーケンサーという機械が故障した場合に、どのように資金を取り出すか、という部分です。大半のプロジェクトは「Transact using L1」か「Force exit to L1」と書かれていますね。L1とは「レイヤー１」のことです。つまり、レイヤー１から強制的に操作できることを意味します。これなら安心ですね。
Validator failure = 入力チェックの故障
バリデーターとは「データの正しさを検証する機能」のことです。そして、わりと多くのプロジェクトは「No mechanism」と書かれています。つまり、なんだかの理由で「バリデーター」が動かなくなった場合は、資金が凍結されます。誰も取り出せません。
とはいえですが、大半のバリデーターは「中央集権」で運営されています。なので一時的にバリデーターが止まったとしても、運営チームが復活させてくれるはずです。なので、実際には、そこまで大きな問題じゃないはずです。
というわけで、今回の説明は以上です。
ちょっと難しい内容だったかもですが、重要な部分です。なお、僕がリサーチする際に使った媒体は、記事の最後に貼っておきます。
記事を読んで理解できなかった部分は、ぜひ原文にも目を通してみてください。ただ文章を読むだけじゃなく、考えつつ、疑いつつ読むほうが、効率的に学べると思います。
参考文献のまとめ
- An Incomplete Guide to Rollups
- How does Optimism's Rollup really work?
- What Is Data Availability?
- Polygon Lack Of Balance Check Bugfix Postmortem
- Double spending bug in Polygon’s Plasma bridge
- レイヤー2トラスト構造 誤解と現状の整理
- Is Polygon an L2, or sidechain?
- Attacking an Ethereum L2 with Unbridled Optimism
- What exactly are L2s and why Polygon is not included?
- PoS Bridge - Polygon
- Analyzing Polygon’s Proof of Stake Network