イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

目次

    イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。

    本記事では2本連載にて前半ではこの提案の内容について、後半でこれにまつわる議論や出来事を整理して解説していきます。

    ERCとEIPについて

    ERCとして公開された技術仕様に関する文章は、まず単なる問題提起からスタートします。提案された問題や技術が重要であれば議論が進み、最終的にはEIP(Ethereum Improvement Proposals)として採択されます。

    EIP採択までの過程には、Draft(検討段階)→Accepted(承認済み段階)といったステータス(状態)があります。AcceptedされたEIPは最終的にまとめられ、イーサリアムの仕様として正式に採用(Final)されることになります。採用されたものは、イーサリアムの公式なアップデートとしてネットワーク上のクライアントに組み込まれていきます。

    イーサリアムのバージョンアップや仕様変更などは、全てこのプロセスを経て行われることになっています。この一連のプロセスの解説については本メディアの過去の記事で解説しております。

    EIP-867の概要について

    EIP-867は前述した通り、ICOなどによって調達したETHがハッキング被害やコードの不備などによって意図せず盗難・凍結した際に、被害者が資金を取り戻すリクエスト(ERP: Ethereum Recovery Proposals)を行い、これが承認された際にその資金が取り戻せる方法を標準化しようと試みた提案です。

    これは2017年2月2日に、Musiconomiの開発者であるDan Phifer氏、そしてTapTrustの開発者であるJames Levy氏、Reuben Youngblom氏によって提案されました。

    過去の被害と対処例

    この提案が行われた背景には、過去に多発したICOで調達した資金の盗難・凍結があります。代表的な例として、The DAOでのハッキングやマルチシグウォレットサービスParityでのバグによる被害が挙げられます。

    The DAO

    The DAOは非常に大きな注目を浴び、短期間で1億米ドル以上の資金を調達し、クラウドファンディングによる史上最高記録を塗り替えました。しかし調達直後に致命的なコードのバグによって、ハッキングの被害に遭い8000万米ドル相当の資金を盗難されました。

    これはイーサリアム自体にとってもその価値を下げる大きな問題であった為に、イーサリアム自体がハードフォークし、このハッキングを無かったことにし、資金を元のウォレットに戻すという対応が取られました。最終的に、The DAOはこの対処によって盗難した資金を取り戻すことに成功しました。

    Parity

    次にParityの例について見てみましょう。

    Parityは、スマートコントラクト上で実行されるウォレットサービスです。このParityの2017年7月20日にリリースされたバージョンにて、あるバグが報告されました。

    このバグは、ある操作で通常のウォレットがマルチシグウォレットに意図せず変更されてしまい、この際にウォレットを開けるために必要な秘密鍵が資金と共にウォレットの中に保存されてしまうというものでした。

    これはある部屋に入るために必要な鍵が部屋の中にある言わば”閉じこもり状態”であり、このマルチシグウォレットの中に保管されていたETHは事実上凍結されて、誰も移動することができなくなってしまうものでした。

    プライベートブロックチェーンとパブリックブロックチェーンをリンクさせるというアイディアで、ICOにて1億4000米ドルを調達したPolkadotもこの被害にあっており、その調達資金のうちの60%が影響を受けているとされています。

    EIP-867の提案者であるDan氏が、ICOを行った音楽系のサービスMisiconomiも被害を受けています。そして昨今このような被害報告が急増しています。しかし、それに対する救済措置は殆ど行われていないのが現状です。むしろThe DAOで行われたハードフォークは、イーサリアム開発者の全面協力による特例的な対応であったと言えるでしょう。

    そこで資金盗難・流出が発生した際に、大規模なハードフォークを行わずに資金回収をする方法がEIP-867で具体的に提案されました。

    EIP-867で提案された資金回収方法

    この提案では、実際に起こったParityの事件に限らず、ハッキングやコードの不備など様々な原因によって、あるウォレットからの資金が意図せず盗難・凍結した場合に、これを取り戻す方法が示されています。ここではある誤送金の例を用いて資金を取り戻すまでの一連の流れを解説します。

    あるICOプロジェクトにてプロジェクト責任者が、誤ってテストネット(プログラムの評価や動作確認に使用する実際の金銭価値の無いネットワーク)で作成した振込先のアドレスをホームページ上に掲載した場合を考えます。

    このアドレスはメインネット(金銭価値がある本物のネットワーク)でも有効ではありますが、秘密鍵はテストネットのものとは異なるために、この責任者はここに振り込まれた資金を利用することはできません。

    問題が発覚した時には既に100人の投資家によってこの間違ったアドレスに500ETHが送金され、この500ETHは実質的に凍結されてしまいました。

    ここでこの責任者は凍結した資金を解除するリクエストERP(Ethereum Recovery Proposals)によって、500ETHを投資家の元のアドレスに戻すような送金をすることを試みます。

    まず責任者は、ERPの提案者としてイーサリアムのEIPコミュニティに、ERPの原案をEIP-xxx(xxxには提案番号が入る)として投稿します。

    ERPの原案の中身

    ERP原案には主に以下の内容が含まれています。

    Verification script(検証コード)

    Verification scriptとは、イーサリアムのブロックチェーン上に存在するデータなどの事実を使って、State Change Actionsによって凍結資金の解除を実行するかどうかを決定する検証を行うコードです。

    検証コードに具体的に記述された条件が満たされた場合に、検証コードはイーサリアムクライアントが実行できる形式のState Change Objectを生成して、凍結資金解除のトランザクションを生成します。

    ここでは検証コードの例として、

    • ブロック番号○○~xxまでの取引にて誤ってメインネット上のテストネット用アドレスに500ETHが送金されたこと
    • テストネット上でのこのアドレスには確かにICOプロジェクトのスマートコントラクトが実装されていたこと(つまり確立論的にメインネット上にこのアドレスの所有者は存在し得ないこと)
    • 上記の全てが真実である場合には全ての送金者に投資されたイーサリアムを返却するState Change Objectを生成する

    と言った内容が書いてあるとします。

    State Change Object

    これはイーサリアムネットワークのクライアントによって実行されるファイルの標準形式です。

    この中には、ERPの番号(ERP id)や変更を要するブロック番号(Target Block)、そして検証コードを実行した際のブロック高(sourceBlock)と検証コードのバージョン(version)に加えて、資金返還を行うトランザクションがState Change Actionsとして記述されます。

    State Change Actions

    この中には送金元のアドレス(凍結資金が保管されているアドレス)と送金先のアドレス(合計500ETHを送金した100人のアドレス)と返金するべき金額など、トランザクションの情報が具体的に記載されます。

    (ERPの構造)

    ERPが承認されるまでの流れ

    EIPコミュニティに投稿されたERP原案は、以下の2つの立場の人たちからのフィードバックを受け、最後にEIP編集者の承認を受けます。

    この資金凍結の関係者

    プロジェクト関係者や実際に送金を行った投資家などがあたります。

    特に被害に遭った投資家は、ERP原案のState Change Actionの中に確かに振り込んだ金額のETHが自分のアドレスに戻るようなコードが書かれているかを確認し、何かしらの誤りがあればコミュニティ上で指摘することができます。

    非関係者

    この資金凍結に関係が無い立場の人間が、検証コードに書かれている内容などが正しく実際に発生した事を記述できているか、これが実行された際に正しい資金凍結の解除がされるのかを判断します。これは裁判で言う陪審員や裁判官の役割に近いでしょう。

    EIP編集者(EIP Editorship)による承認

    フィードバックの期間は最低でも30日程度が必要だと述べられています。このフィードバック作業は、公開にて行われコミュニティ上では色々な議論が巻き起こるはずです。そして最終的にEIPの編集者が、コミュニティでの議論内容を踏まえてこのERPの提案を承認(Accept)するかを決定します。

    ここで承認された提案はEIP可決案となり、公式なイーサリアムのアップデートとしてイーサリアムネットワークに拡散されることになります。

    (ERP承認までの流れ)

    ERP承認から資金凍結解除までの流れ

    クライアントノードに伝わったERP可決案は、それぞれのクライアントノードで実行されていきます。まず検証コードが実行され、この時確かに検証内容が正しいと判断された場合には、State Change Actionsを含むState Change Objectを生成し、実際に資金凍結解除のトランザクションがイーサリアムネットワーク上に書き込まれていきます。

    通常のトランザクション同様に、この凍結解除処理トランザクションも一定の時間が経過すれば有効となり、無事凍結した資金は送金者の元に戻っていくことになります。

    (可決されたERP案はクライアントノードにて実行される)

    以上がEIP-867で提案された凍結されたETHの取り戻しに関する仕組みになります。しかし凍結資金の取り戻しは非常にセンシティブな問題であり、議論が間違った方向に進めば誤って人の資金を不正に送金するツールになってしまう可能性も孕んでいます。後半の記事ではこの様なEIP-867に関して巻き起こっている様々な議論について解説していきます。

    コメントする

    メールアドレスが公開されることはありません。