タグ: "ERP"

イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

2018/03/06 at 3:07 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。 本記事は盗難・凍結したETHを取り戻す方法を提案したEIP-867にまつわる連載記事の後半です。前半記事では、EIP-867で提案されたETH回収の仕組みについて解説しました。本記事ではこの提案に関する考察と、イーサリアムEIPコミュニティの編集者である平井氏が示した2つの懸念に焦点を当てて解説をします。 ハードフォークによる救済 当時最大級のハッキング被害が発生したThe DAO事件では、イーサリアムがハードフォークすることによってハッキングが無かったことになり、ETHは取り戻されました。ハードフォークではブロックチェーンに大幅な仕様変更を加えるために、それまでのブロックチェーンとの互換性は保たれなくなります。 ハードフォークする新たなブロックチェーンが提案された際、この新しいブロックチェーンを正当なものとして受け入れるかどうかは、ネットワーク上の各ノード(ブロックチェーンの管理やマイニングを行っている世界中に分散したコンピュータ)が選択します。 The DAO事件では、ある特定のハッキングのみを無効にするということが、ブロックチェーンの特長である ”過去に起こったことが変更不可能である” という性質に反するとして、1割程度のノードから反対されました。結果として、9割方のノードが採用した新しいブロックチェーンが正式なイーサリアムとなり、反対の立場にあるノードが元のブロックチェーンを運用し、これがイーサリアムクラシックとなりました。 このようにハードフォークを行うには、その提案を行う事自体の労力に加えて、ノード全体の半分以上の同意が必要であり、簡単に実現できるわけではありません。 EIP-867によるソフトフォーク EIP(Ethereum Improvement Proposals)コミュニティでは、現状のイーサリアムの問題に対する解決策が議論され、一般的に現状のイーサリアムに互換性のある形式の提案が承認され、アップデートとして配信されます。 EIP承認の流れやERCについての記事はこちら ネットワーク上のノードは、このEIPで承認されたアップデートをマイナーな公式アップデートとして受け取り有効化していきます。 EIP-867で提唱されたETHの救済方法は、このEIPの承認手順に則ったソフトフォーク的な方法だと言えます。 EIP Editorとは? EIPコミュニティには、EIP Editorという権限を持つ人物がいます。彼らは新たな提案を受け取り、その提案が適切である場合はEIPとして番号を与えて、EIPに関するGithubレポジトリに提案を検討(Draft)状態として公開します。 また、公開された提案に対する議論の末、EIPが公式アップデートとして取り込むべきと判断した場合には、提案を承認(Accept)し最終版を確認(Final)した上で公式なアップデートとします。 (提案されたEIPが経るプロセスフローチャート 引用:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md ) 2018年2月22日現在、EIP Editorはイーサリアムの開発者であるVitalik Buterin氏を含め6名です。EIP EditorやEIPコミュニティの目的やガイドラインについてはEIPの1番としてGithub上に掲げられています。 EIP Editor 平井洋一氏の懸念と辞職 2017年2月上旬に、6名いるEIP Editorの一人であった日本人論理学者の平井洋一氏が、EIP-867に関する提案を以下の2つの懸念事項を理由に受け入れられないと表明しました。平井氏はその後、この件をきっかけにEIP Editorを辞職します。この一件は、今回巻き起こっているEIP-867に関する倫理的な議論を象徴する出来事だと言えるでしょう。以下に平井氏の懸念事項を紹介し考察します。 平井氏の懸念 ① 〜イーサリアムの分散自治的な側面〜 ブロックチェーン技術に根ざしているイーサリアムは、そもそも国家や政府はもちろんのこと、どの様な立場の人や組織も管理権限を持たない分散自治組織的な設計がされています。この組織では権限者が居ないかわりに、全ての意思決定で全ユーザーの投票により過半数以上の賛成を必要とします。 しかし、そうとは言ってもイーサリアムの技術的な変更も公平なユーザーの投票によって過半数を得る事が最善とは言い切れません。イーサリアムは元々Vitalik氏を中心とした天才的なプログラマ達によって開発されている緻密な暗号理論に基づいたシステムです。これを正しく更新し続ける為には高度な専門知識が必要になります。そのため、イーサリアムEIPではこの様な背景から、EIP Editorが改善案の承認を最終的に行う事で初めて公式なアップデートとなるような一部の管理権限を認める仕組みを設けています。 この様な理由から権限を持つEIP Editorは慎重に検討して、イーサリアムコミュニティ全体にとって公平な改善案のみを承認するべきだと言えます。 平井氏の懸念事項の一つ目はこの点です。つまり、もし今回提案されたEIP-867が承認されれば、今後不正(と思われる)ETHの盗難や凍結があった場合に、この資金を最終的にどのように処理するのかと言う、極めて特定の利益に関わる決定権をEIP Editorが持つことになります。 これは上述したイーサリアムの分散システムの哲学に反します。EIP Editorはイーサリアム利用者の信任を得て決定される訳でも無く、また、その存在についても一般に高く認知はされていません。よってEIP Editorが特定のアカウントの残高情報を変更する強い権限を持つべきではない、というのが平井氏の指摘です。 “I don't think anybody has the authority to make an irregular state change. I don't think I have the authority to review processes regarding who has the authority to make an irregular state change. These beliefs come from the lack of authorizations from Ethereum users. I don't think all users of Ethereum gave authorization to this EIP process, or know about the EIP process. The EIP process is not mentioned in the licenses of Ethereum clients. EIP editors are not chosen democratically either.” (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の懸念 ② 〜日本の刑法との抵触の可能性〜 また日本人である平井氏がEIP Editorとして今後このEIP-867で述べられたERPを承認した場合に、日本の刑法 ”電磁的記録不正作出及び供用” に抵触する可能性があることを述べています。この刑法は、ある電磁記録に関する権限を持っていない状態で記録を作り出す・改変することを罰するという内容のものです。 例えば他人の預金残高の記録を持ち主の許可無く改変することはこの刑法で罰せられる可能性があります。 平井氏は直接的にどのように抵触するかについては言及していませんが、おそらく、EIP Editorとして他人のETH資金の情報を所有者の許可なしに書き換えるERP案を承認する行為が、この刑法での犯罪の幇助にあたると考えているのでしょう。 The Japanese penal code defines a crime called "Unauthorized Creation of Electromagnetic Records". (edit: this item applies also outside of Japan) I'm currently not in Japan but in Germany. I suspect there might be a similar rule in Germany, and I don't know how broadly that applies. Once I thought it's enough not to touch individual cases because I had civil cases in mind. After realizing the penal code aspects, I'm not sure if I can do anything here in this pull-request. (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の辞職 平井氏は当初、上述した2つの懸念事項を理由にEIP-867に対する否定的なコメント寄せました。ただし平井氏はその後の議論を経て、イーサリアムの哲学に反するという①の懸念事項については解釈を無視することで解決できるとしました。しかし、②の刑法への抵触については無視できないとしました。 平井氏が否定的なコメントを寄せる一方、イーサリアムのコミュニティマネジメント及びParityのテクニカルコミュニケーションを担当しているアフリ氏は、今回のERPの提案を強く支持しています。 そして、アフリ氏はTwitter上にて、日本という一つの国の法律に抵触する恐れがあるという理由で、イーサリアムに有用な提案が拒否されることは、イーサリアムコミュニティで起こるべきではないという旨の意見を表明し、平井氏がEIP Editorを辞任することを呼びかけました。 平井氏はこれに応答し、もし平井氏自身が辞任したとしても、それは後続のEIP Editorが刑法を無視することになるだけだという意見を表明しました。結果として、その10時間後にEIP Editorを辞任するに至りました。 各国の規制と分散自治組織の対立 今回紹介したEIP-867に関する議論は、イーサリアムにて大きな問題となっている盗難・凍結された資金の回収に関するものでした。しかしここから、イーサリアムと言う分散型システムを開発・推進するコミュニティが実際に存在することによって発生する、日本の法規制との対立構造が浮き彫りになりました。 公開されたブロックチェーンによって作られるシステムは、一般的に国などの従来の枠組みを超えた分散自治的な特徴を持っています。しかし、そのコミュニティに参加する人々は、何処かしらの国籍を持ち、自国の法規制に束縛されます。 今後ブロックチェーンをベースとした分散自治的な組織が更に拡大するでしょう。そして、そこで発生する従来の国や政府などの枠組みによる規制との対立をどのように解決していくのかは、分散自治組織を現実社会で利用する上で非常に重要な視点となるでしょう。
イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

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

2018/02/28 at 7:41 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用した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%が影響を受けているとされています。 Unfortunately, our multi-sig is among those frozen. @ParityTech is working on the situation and will provide updates when available. — Polkadot (@polkadotnetwork) 2017年11月7日 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に関して巻き起こっている様々な議論について解説していきます。