Written by Manabu Bannai

ブリッジの重要性・危険性について解説する【Ethereumの基礎講座】

こんにちは、マナブです。
本日は「イーサリアムのブリッジ」について解説します。

本記事で解決する悩み

上記のとおり。
そして、まずは下記もご覧ください。

ここまで読んだ方の反応

う〜む、ブリッジか。よく分からないし、これは上級者向けかな。別に細かい知識に興味ないし、この記事はスルーするか。

こういった方へ。ちょっとお待ちください。

というのも、クリプトの世界を理解するには、ブリッジの理解が必須です。
イーサリアムの開発者達が「最も力を入れている分野」といっても、過言じゃないです。

記事を読むことで「イーサリアムの哲学」も学べるはずです。
10分くらいで読めますので、是非お付き合いくださいませ。

本記事のもくじ

1.Ethereumのブリッジとは(基本)

結論としては、下記の画像のとおりです。

L2 bridge

画像のとおりですが、ブリッジは「イーサリアム」と「レイヤー2」を繋いでいます。なお、画像右側の「レイヤー2」の中には「Optimism (オプティミズム)」や「Arbitrum (アービトラム)」と記載されていますが、ここに関しては後述します。

なぜ、レイヤー2が重要なのか?

結論は「イーサリアムの高速化のため」です。現状のイーサリアムは、かなり遅いです。仮に「コインの交換」をイーサリアム上で実行しようとすると、3分ほどかかります。人によっては「3分=早い」と感じるかもですが、そうでもないです。

ゲームを例にして、速度について考えてみる

例えばですが、皆さんはスマホゲームを使ったことがありますよね。大半のゲームには「アイテムの獲得」や「交換」の機能があります。ゲーム内でポイントを貯めて、そしてアイテムと交換するなど。

では、アイテム交換のたびに「3分の待ち時間」があったら、どう思いますか? 待つのが面倒で、たぶんアプリを閉じますよね。ちょっと極論かもですが、現在のイーサリアムはこのような状況です。

遅いチェーンだと、ゲームが出来ない

現状のイーサリアムは遅いです。なので「イーサリアム上にメタバース」を作ったとしても、現状だと機能しないはず。

というのも、メタバース内で「アイテム交換」をするたびに、ユーザーが3分くらい待たされます。これじゃあ、大半の人は離脱するはず。こういった問題解決に動いているのが、レイヤー2やブリッジの技術です。

※補足①:ゲームを例にしましたが、その他のアプリでも同じです。例えば「ブロックチェーン上のTwitter」があったとして、ツイートするのに時間がかかったら、誰も使わないですよね。ある程度の速度がないと、実用的じゃないです。

※補足②:イーサリアム上でのコイン交換に「3分ほどかかる」と記載しましたが、正確には時間は変動します。イーサリアムの混み具合にもよりますが、利用者の少ない時間だと「30秒くらい」が目安で、利用者の多い時間だと「3分以上」という感じです。

ブリッジの仕組みを考察する

先ほどの画像を、再度引用します。

L2 bridge

ブリッジの真ん中に「Bridge Node」と書かれていますよね。これは要するに「ブリッジのPC」のことです。もっと言うと「ブリッジを管理するパソコン」ですね。そして、このパソコンには「シーケンサー」という機械が繋がっています。シーケンサーとは「シーケンス (=順番) を制御する機械のこと」です。

シーケンサーが、データを保存する

この「シーケンサー」が、要するに「管理者」というイメージです。下記のとおり。

L2 sequencer

シーケンサーの役割は「データの保存」です。取引データを保存しつつ、定期的に「イーサリアムへの提出」をします。このシーケンサーがあるからこそ、レイヤー2のセキュリティが保たれている訳です。

※補足:シーケンサーの動きを深く学びたい方は「(Almost) Everything you need to know about Optimistic Rollup」をご覧ください。

シーケンサーが「故障 or 不正」をしたらどうする?

ここまで読んで、わりと多くの人は「シーケンサーが管理人なら、その管理者が”故障 or 不正”をしたらどうなるんだ…?」という疑問を持つかもです。ここに関しては解決策があります。詳しくは「記事の後半」で解説します。

イーサリアム単体で高速化できないのか?

レイヤー2は素晴らしいですが、そもそも論として「イーサリアム単体で、もっと高速化できないのか?」という疑問も湧きますよね。ここに関しても記載しておきます。

結論:ブロックチェーンのトリレンマです

trilemma

上記の画像が「ブロックチェーンのトリレンマ」です。3つの言葉がありますが、これら3つを、同時に満たすことが出来ません。イーサリアムの場合は、下記のとおり。

ブロックチェーンのトリレンマ:イーサリアム版

trilemma eth

イーサリアムの場合は「非中央集権」と「安全性」を目指している訳です。なので「拡張性」が犠牲になっています。この犠牲となった拡張性を補うために、現在は「レイヤー2」の技術を開発している訳ですね。他の例としては、下記が「Solana(ソラナ)」の事例です。

ブロックチェーンのトリレンマ:ソラナ版

trilemma sol

ソラナチェーンも伸びていますが、ソラナの場合は「非中央集権」の部分を犠牲にしています。というのも、ソラナの場合は「処理速度がめちゃくちゃ早い=個人がソラナのノードを運営するのは難しい=ノード運営が中央集権化する」といった仕組みだからです。

イーサリアムとソラナの「ノード数」を比較してみる

上記のとおり。とはいえ、、そこまで数字に大きな差はないですよね。実際のところ、現状のイーサリアムは「ノードが中央集権化している」という状況です。イーサリアムの最大の強みは「分散性」ですが、まだまだ「理想的な状況」は達成できていません。

2.最近は「ブリッジの事故」が多い件

ここからは「ブリッジの事故」について解説します。ブリッジは重要な技術ですが、しかし最近は「ブリッジの事故」が多いです。

ここ1〜2ヶ月で、事故が連発しています。その理由として、下記をご覧ください。

bridge-money

上記のとおりで、要するに「ブリッジの中間には、お金が貯まる」という仕組みなんですよね。ハッカー視点で考えたら「ブリッジを狙う→効率的に稼げる」を意味します。なのでブリッジの事故が増えている訳です。順番に事例を見ていきます。

事例①:ワームホールの事件

2022年2月2日に、Wormholeというプロジェクトがハッキングされました。被害総額は「約320億円」です。原因としては、下記のとおり。

詳細は「上記のホワイトハッカーの解説」を呼んでほしいですが、簡単にまとめると「署名の偽造」です。ブリッジを使う際には、必ず「署名」の技術が使われます。

例えば「1イーサ」をブリッジで移動するなら、移動前に「このイーサは、自分のモノです」という署名をする訳です。この署名があるからこそ、お金を引き出せます。しかしワームホールを襲ったハッカーは、この署名を偽造しました。プログラムコードのミスが原因です。

事例②:ポリゴンチェーンのバグ

ポリゴンチェーンに関しては、直近で2つも事件があります。

その(1)に関しては、詳細な内容は「Polygon Lack Of Balance Check Bugfix Postmortem」をご覧ください。要約すると「プログラムのバグを利用することで、署名を偽装できた」という問題です。なお、注目すべきは「被害額」です。

被害額は「全体の92%」の流出です

幸いなことに、今回のバグは「ホワイトハッカー」が指摘をしたので、資金流出しませんでした。しかし仮に流出していたら、巨大するぎる被害です。

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上のイーサ」などと交換できます。僕はポリゴンの利用者だったのですが、今回の事件を見てから、資金の7割を抜きました。

事例③:オプティミズムのバグ

2022年2月2日に、レイヤー2で有名な「Optimism (オプティミズム)」にもバグが発見されました。内容は「Geth (=ゲス) のバグ」です。Gethとは、要するに「イーサリアムを簡単に操作するためのツール」です。

イーサリアムのネットワークに参加するには、ノードを立てる必要があります。 その際に「Geth」といったツールを使い、イーサリアムのネットワークを操作します。Gethを使わなくても操作できますが、それだと大変なので、ほぼ全員がGethを使っています。

被害は起こりませんでした

今回のバグは「ホワイトハッカー」が発見しました。なので、被害が起きていません。しかし被害が起こっていたら、大きな混乱が起きたはず。というのも、今回のバグでは「ハッカーが、全てのトークンにアクセス可能」という状況だったからです。

オプティミズムには「約340億円」が入っていますので、ここにある資金に被害が及んだはずです。かつ、ハッカーが「レイヤー1への資金移動」にも成功した場合は、イーサリアムにも被害が及んだ可能性があります。

レイヤー2は、別に安全じゃない

よくある話で「レイヤー2はセキュリティが強い」と言われたりします。しかし、正確には、下記のように考えるべきだと思います。

上記のとおり。イーサリアム創設者のヴィタリック氏は「ブリッジの未来には楽観的である」といった発言をしていますが、これはあくまで「未来の話」です。現状のブロックチェーンには、数々の問題があります。なのでブロックチェーンやDeFiに資金を入れる際には、よく考えてみてください。

なお、こんなことを書きつつも僕は、貯金の9割をブロックチェーン上のDeFiで運用しています。資金を入れつつ、学習しています。DeFiの未来を感じています。なお、DeFiを深く学びたい方は「DeFiを理解するための基礎ガイド」を参考にどうぞ。

補足:最悪の事態が起きたら、どうするか?

参考までに、仮に「レイヤー2の領域で、破壊的な被害が起きた場合」を考えてみます。結論としては「ハードフォークされる可能性が高い」と思います。ハードフォークとは、チェーンの分岐のことです。要するに下記のとおり。

上記のとおり。実は、昔のイーサリアムでも同じことが起こっています。名称は「The DAO事件」と呼ばれています。ハッカーに大量のイーサを盗まれたのですが、コミュニティの決定で「ハードフォーク」が起こりました。その結果として、被害がリセットされた訳です。

とはいえ、、ハードフォークが起こってしまうと、そもそもの「ブロックチェーンへの信頼」が揺らぎますよね。なので、実行前に「要検討すべき」ですが、とはいえ破壊的な被害が起きた場合には、ハードフォークという選択肢が残されています。

※注意点:ハードフォークをしたからといって、全ての被害を消すことはできません。というのも、現状のレイヤー2やブリッジの世界では、色々なチェーンが繋がっています。それぞれの整合性を保たないといけないので、かなり難しい問題です。最終兵器はハードフォークですが、しかし必ずしも「全員が助かる」という状態には戻らないはずです。

3.レイヤー2の「基礎知識」を学ぼう

最後に「補足的なチャプター」として「L2BEAT」を紹介します。

l2beat

L2BEATでは、レイヤー2の比較ができます。記事で紹介した「オプティミズム」も「4位」にありますね。こちらのサイトを理解することで、ブリッジへの理解も深まりますので、解説しておこうと思います。

5つの指標を学んでいきます

l2beat info

画像の「赤枠」に着目してください。下記のように書かれています。

上記のとおり。ぶっちゃけ、よく分からないですよね。僕もそうでした。なので学びつつ、1つ1つを調べましたので、ここで共有していきます。

State validation = セキュリティの検証方法

State validation

直訳すると「状態の検証」です。これは要するに「セキュリティの検証方法」を意味します。まずは下記の2つをご覧ください。

上記のとおり。なお、ここだけを見ると「ZK proofsの方が、数式で管理されてるので安心では?」と感じるかもですが、ZK proofsには「実装が難しい&拡張性を犠牲にする」といった問題点があります。とはいえ、将来的には「ZK proofsが主流になるだろう」と言われています。

Data availability = データの有効性

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.

翻訳すると「問題が起きた場合は、データの再発行をしたり、もしくはレイヤー1に脱出することができます」と書かれています。こういった仕組みだと、レイヤー2を使うときに安心ですよね。

Upgradeability = アップデートが可能か

Upgradeability

こちらの意味は「根本となるコードのアップデートが可能か?」という意味です。そして、大半のプロジェクトは「Yes」となっています。これはつまり「運営が、お金を持ち逃げすることが可能」であることを意味します。

レイヤー2はブロックチェーン上で動いています。そしてプログラミングコードはブロックチェーン上に記載されています。なので本来なら「コードを書き換えることは、不可能なのでは?」と考えますよね。しかし実際には「システム稼働時に、どのコードを使うのか」という点は変更できます。なので運営が新しいコードを書き、そのコードに悪意があるなら、資金の持ち逃げが可能です。

とはいえ、、上位プロジェクトに関しては、運営が不正をするリスクは少ないはず。仮に不正が起こったら、自分達の信頼を失うだけですからね。そして信頼を失うだけじゃなく、プロジェクトの将来性も消え去ります。このように考えると、現時点で運営が不正をする可能性は低いと思います。

Sequencer failure = シーケンサーの故障

Sequencer failure

シーケンサーという機械が故障した場合に、どのように資金を取り出すか、という部分です。大半のプロジェクトは「Transact using L1」か「Force exit to L1」と書かれていますね。L1とは「レイヤー1」のことです。つまり、レイヤー1から強制的に操作できることを意味します。これなら安心ですね。

Validator failure = 入力チェックの故障

Validator failure

バリデーターとは「データの正しさを検証する機能」のことです。そして、わりと多くのプロジェクトは「No mechanism」と書かれています。つまり、なんだかの理由で「バリデーター」が動かなくなった場合は、資金が凍結されます。誰も取り出せません。

とはいえですが、大半のバリデーターは「中央集権」で運営されています。なので一時的にバリデーターが止まったとしても、運営チームが復活させてくれるはずです。なので、実際には、そこまで大きな問題じゃないはずです。

というわけで、今回の説明は以上です。

ちょっと難しい内容だったかもですが、重要な部分です。なお、僕がリサーチする際に使った媒体は、記事の最後に貼っておきます。

記事を読んで理解できなかった部分は、ぜひ原文にも目を通してみてください。ただ文章を読むだけじゃなく、考えつつ、疑いつつ読むほうが、効率的に学べると思います。

参考文献のまとめ