ミニ四駆で喩える ERC-20 と脆弱性

先日 batchOverflow と呼ばれる脆弱性が発見され、クリプト界隈がざわつきました。

結局のところ、影響は限定的であるということで落ち着きましたが、何が問題でなぜ深刻でないのか、技術系に明るくない方々の中には、もやもやとしたものが残っている方もいらっしゃるかもしれません。

本稿では、喩え話を使って、今回の脆弱性について解説しておきたいと思います。

...

現代日本における国民的玩具の一つにミニ四駆があります。ミニ四駆で遊んだことがない方でも、その存在くらいはご承知と思います。

ミニ四駆は、様々な部品でカスタマイズすることで特徴のある車両を作ることができます。

しかしながら、全てのミニ四駆は、(世代により数種類ありますが)共通のフレームを用いています。

外見がどうであれ、車輪間の距離や車高は、一定の範囲に収まっています。そのような制約をかけることで、専用のコースで競争できるようにしてあるわけです。

...

Ethereum 上でトークンアセットを実現する ERC-20 は、なんとなくそのような実体があるような理解でおられる方もいらっしゃるかもしれません。しかし、ERC-20 というプログラム(ソースコード)はありません。

ERC-20 は、ミニ四駆で喩えるならば、フレームの形状を決めるもの「前輪と後輪との間隔はこれくらい」「タイヤは4つついていないとダメ」等々の決まりごと(仕様)を示しているものです。

ERC-20 という仕様があることで、たとえば、トークン開発者は(トークン毎にウォレットを開発するのではなく)「ERC-20 対応ウォレット」にトークンの管理を任せられるようになります。トークンを保持する方も、一つのウォレットで済むなら、嬉しい話ですね。

さて、ERC-20 の仕様に沿ったソースコードのサンプルは、存在します。そして、ここが大事なのですが、そのソースコードを基に、ERC-20 仕様の要求を損わない上で拡張したものも ERC-20 準拠トークンと呼べます。

カスタマイズしても、規約に則っていればミニ四駆と呼べるのと同じです。

今回明らかになった脆弱性 (batchOverflow と名付けられました) は、特定の ERC-20 準拠トークンの拡張部分にバグがあり、期待しない量のトークンを生成できるというものでした。

ミニ四駆で喩えてみるなら、派手な電飾をしてみたら電池が耐えきれずに暴発して炎上、みたいなものです。その車両が燃え尽きたとしても、ミニ四駆という製品群が危険だったり、他のカスタマイズした車両が同じく炎上したりということにはなりません。

…

…というわけで、今回の脆弱性の影響は限定的であり、イーサリアムや大多数の ERC-20 準拠トークンは直接の影響を受けない、ということが言えます。

ただし、他の ERC-20 準拠トークンが同様の脆弱性を別の形で抱えているという可能性について、完全否定はできません。

完全否定するには、コントラクトのソースコードが公開されていればソースコードを、そうでなければブロックチェーン上に記録されている EVMバイトコードを解析する必要があります。

この手の解析を行う技術は、概ね確立されています。しかし、実際に行うとなると、手間のかかる作業にはなります。

今後起きるかもしれない(起きないかもしれない)脆弱性に対し、自衛できる手段は、限られます。技術クラスタ以外の仮想通貨民ならば、なおさらです。

ソースコードが公開されていて技術者クラスタから安全のお墨付きが出ているトークンか、脆弱性が明らかになった際に(補償含めて)なんらかの対応を期待できるトークンか、いずれにしか手を出さない。これが当業者BOTの中の人の、推奨です。

そして、「スマコンの不具合で保有トークンの資産価値が失われるリスクは織り込み済み」と開き直ったうえでリスク管理していくのも、一つの考え方ではあります。