イーサリアムの高騰は止まらず、フィアット建てではATHを記録し、9万円を記録しました。今年イーサリアムはエンタープライズイーサリアムのローンチに始まり、200倍の価格まで高騰。DAGサイズの増加によるイーサリアムマイニングのGPUハッシュレート低下を修正し、更にネットワークバージョンのホームステッドからメトロポリスへ移行し、ビザンチウムの実装を行いました。
そんな中イーサリアムクライアントを開発するParityの提供するマルチシグウォレットに致命的なバグが発見され34億円が盗まれ、更にバグを修正するホットフィックスにも再度致命的なバグにより316億円がウォレット内に凍結。イーサリアムは今後の未来を考え、ハードフォークを行いプロトコルの修正を検討しています。
スポンサーリンク速報:イーサリアム価格は9万円に到達。年内10万円まで後1万円を切りました #イーサリアム #Ethereum #仮想通貨 $ETH #ブロックチェーン pic.twitter.com/gY0msi51U8
— 墨汁うまい(Not giving away ETH) (@bokujyuumai) December 13, 2017
目次
1.Parityのハックとイーサリアムの凍結
2017年7月30日、Parityによりマルチシグウォレットの致命的な脆弱性が発表され、約34億円のETHがハッカーに盗まれ、15万ETHが取引所に移動され投げ売りされてしまいました。その後ホットフィックスがリリースされ、マルチシグウォレットが再度デプロイされたものの、約4ヶ月後となる11月7日デベロッパーが偶然コントラクトを破壊。約316億円というETHがウォレット内に凍結し、送金ができなくなりました。
この事件によりイーサリアムコミュニティではハードフォークをすべきかどうかで多くの議論を呼んだものの、ハードフォーク議論は収束してしまいました。
今回の事件の一連の概要は下記記事を参照してください。
2.イーサリアムの資金凍結問題
Parityが11日に公開した主張によると、今回の316億円の凍結への対策を発表。この内容ではVitalik氏の提案しているEIP-156や0x0アドレスへの誤送金、及びイーサリアムとイーサリアムクラシックへのスプリット問題を解決し、ユーザビリティの向上に務め、同様の誤送金を防止するという内容でした。
Parityによると、4つの潜在的に考えられる資産の凍結問題を解決する方法が検討されており、プロトコルの変更が必要であるためハードフォークを必要とします。
0x0アドレスの問題点については下記wikiを参照してください。
2-1.The DAOハードフォークのスプリット問題
イーサリアムネットワークは2016年7月20日1,920,000ブロックにてThe DAOのコード脆弱性をついた12,000,000ETH、現在の価格にして約1兆円が不正送金された事件を修正するためハードフォークを行いました。
ロードマップに存在しないイレギュラーなハードフォークでしたがネットワークの97%のコンセンサスを得れたとし開発者のVitalik氏は
「現時点では85%のマイナーが新たなチェーンに移行しており、ハードフォークはスムーズに行われました。」
と発表しました。
Copyright © Ethereum Doundation
2-1-1.ハードフォークに対するリスク認識の甘さ
コンセンサスは得られたと思ったものの、The DAOのミスを”救済する”ためのハードフォークをよく思わない一部のユーザーと、破棄されるはずだった元チェーンのEtherに価値がついたことに目をつけた中国人マイナーのChandler Guo氏の支持によりイーサリアムのオリジナルチェーンであるとし”イーサリアムクラシック”として息を吹き返しました。
*イーサリアムクラシックはイーサリアムのフォークでありません。ETHが破棄したオリジナルチェーンに残りThe DAOフォークでの変更をしていない元チェーンとなります。
2-1-2.リプレイプロテクションの知識不足
イーサリアム(以下ETHとする)は元チェーンとなるイーサリアムクラシック(以下ETC)は97%のコンセンサスが得られ、ネットワーク全体が新しいチェーンに移動し、元チェーンは破棄されるものとして行っていたためリプレイプロテクションの周知を行っていませんでした。
このリプレイプロテクション問題により、当時イーサリアムとイーサリアムクラシック間でのコントラクトへのデポジット問題により多くのETHの凍結問題を引き起こしました。
例：ETCで生成されたコントラクトで、ETHへ送金されたがETHでコントラクトを生成していない
今年最大の問題となったSegWit2xは意図的にリプレイプロテクションを導入しておらず、失敗していなかったら大きな問題となっていたでしょう。
詳細は下記を参照してください。
2-2.ERC20トークンのコントラクトアドレスの送金問題
イーサリアムは2016年のイーサリアムベースのERC20トークン(以下ERC20とする)ICOラッシュにより多くのERC20が発表され、プロジェクトごとのコントラクトアドレスがネットワーク上にデプロイされました。このコントラクトアドレス自体には送金機能を持たず、アドレスのコピーミスなどによりコントラクトアドレスへ誤送金をしてしまうことにより、ICOプロジェクトでさえアクセスができず、返金が不可能となるETHの凍結が多く起こっています。
コントラクトアドレスはICOのためにネットワーク上に既にデプロイされており、送金機能を持たないコントラクトを「デプロイ後に変更することができない」というのが原因となっています。
3.イーサリアムの不変条件
イーサリアム上にシステムを構築する際に最も重要なことはなんでしょう？デベロッパーは正しい実装や開発を行えていると判断するために”不変条件”が最も重要となります。
イーサリアムにおける絶対的な不変条件は
sum(balance(account) for all accounts) = totalSupply
でしょう。これは全てののアカウントが保有するETHの総数は、ネットワーク全体の全供給量と等しいということです。つまり、アカウントの保有するETH総数が1,000,000ETHで全供給量が900,000ETHということには絶対になりえません。
スポンサーリンク＊不変条件とは・・・ネットワークが正常に稼働している間その条件が常に真であり、不変であること
3-1.The DAOフォークが変更した不変条件
イーサリアムネットワークには何点かの不変条件が存在し、一部はシステムにとって更に重要なものとなっています。1,920,000ブロックで行ったThe DAOフォークでは
「ブロック内の状態ルートハッシュは親ブロックのハッシュによって表される状態に対して実行されたブロックのトランザクションの結果である」
という不変条件に対し、「イレギュラーな状態変更」を追加し
「もしブロックナンバーが1,920,000である場合のみ変更を加えます。」
イーサリアムクラシックではこの追加された変更点を排除し、開発が行なわれれています。
3-2.トランザクションスパムアタック
イーサリアムネットワークは2016年9月、中国でDEVCON2が開催されている中、複数回に渡りDDoS攻撃を受けました。これはガスコストの低いOPCODEを狙った低コストのトランザクションスパム攻撃でした。
詳細は下記を参照してください。
3-2-1.EIP-150 OPCODEのガスコスト変更
トランザクションスパムアタックによるネットワーク遅延を防ぐため、イーサリアムはOPCODEのガスプライスを変更するEIP-150を含んだハードフォークを実行しました。これはロードマップにないハードフォークではありましたが、イーサリアムプロトコルの致命的なバグであり、ネットワークを強固にする（DDoS対策）ために必要であり無事コンセンサスを得ることができました。
3-2-2.63/64ガスルール
更にセキュリティを強化するために追加された63/64ガスルールはコールスタックリミットの1024へ到達しないようにするためのものです。このルールでは63/64以上消費することができず、ガスコストをG、N回CALLする場合
G ＊ (63/64)^n
となります。
3-2-3.潜在的なDoS攻撃への対策
Vitalik氏によるEIP-150の63/64ルールの説明によると
「実際のコールスタックの深さは1024に到達することなく、～340まで制限され、CALLを使用した潜在的に起こり得る二次的なDoS攻撃を緩和する」
としています。
3-3.ハードフォークの注意点
ENSデベロッパーのNick Johnson氏はこのイーサリアムの不変条件変更のハードフォークについて「不変条件の変更は必ずしも毎回問題があるわけではないが、十分に考慮する必要がある」と述べています。
また不変条件の変更を行う際は下記の3点を十分に考慮すべきだとしています。
1.変更の性質
2.この変更におけるネットワークの利点
3.変更の結果、いかにして確実に行うか
と述べており、プロトコルを変更した際に起こるとかんがえられる事象についてよく考慮する必要があるとしています。
3-4.The DAOフォークとEIP-150の違い
The DAOフォークはネットワークの供給量から占める多くのETHが盗まれたことにより、ハッカーの投げ売りによる長期的な価格の大幅下落の可能性と、プロジェクトの救済を目的としたもので多くの議論を呼びました。対してトランザクションスパムアタックのフォークは「プロトコルレベルのバグ」を修正、更に63/64ルールによる制限によりイーサリアムネットワークへのDoS攻撃対策をし、結果的にネットワークを強固にするという結果となりました。
最終的にDDoS攻撃の対策を講じている際に２次的バグが誘発し、コンセンサスバグでGethとParityが別々のチェーンへフォークするという事件もありましたが、ワールドコンピューターを目指すプロトタイプのイーサリアムにとっては不測の事態への対処という経験を積むことができました。
つまりネットワークをより強固にするという大きな利点があったEIP-150フォークを行うインセンティブは大きかったということがわかります。
4.Parityの提案する凍結したイーサリアムの救出
Parityにより提案された新たなEIPではParityのマルチシグウォレットが全てのウォレットロジックを持つライブラリコントラクトの偶然の破壊による316億円のETH凍結をはじめとする上記で説明した0x0問題、ETCのスプリットとリプレイプロテクション問題、コードが存在しないコントラクト問題を修正するというものでした。
現在では送金ができないコントラクトは775まで増加、更に凍結総額は5000ETH、現在の価格にて4250万円を超え、最大の凍結額はYobitより送金された2400ETHとなっています。
| コントラクトアドレス | 凍結ETH額 |
|---|---|
| 0x56099a588ad9515dd78f0f7dc831aa7d6897e9b7 | 2400.00000ETH |
| 0x55423da56319ddd796dcd6deb9eb8e885c9241f6 | 1002.29455ETH |
| 0xae7a1b1ba864696bcdcec94a34fb5836ca9a3910 | 999.98800ETH |
| 0x3a5fb0f79c258942c1acf8142cbc601c1aff1ac4 | 262.70574ETH |
| 0x6198db1e212846b9ecbaee75182a456077c1ccb2 | 212.88300ETH |
| 0x1a54be38f6ee09a73230cedbcbb9eb8bc5c4e8d0 | 128.00000ETH |
| 0x355df8116962306b02218143c97c37943670d9c3 | 109.02731ETH |
| 0xe1d6b08f3d3b5c80c1fde685e98c04a6bcbc77e9 | 101.16000ETH |
4-1.EIP-156(Vitalik案)
ETHとETCのスプリットコントラクトバグ問題や既存の凍結問題を解決するEIP-156が最有力候補とされています。EIP-156では”create-transaction”と同様の動作を行うビルトイン関数createatを導入、ただしコントラクトアドレスを生成するために使用されたナンスを指定するパラメータの追加があります。
詳しくは下記を参照してください。
4-2.EVMのOPCODEを変更する(Parity案)
Parityの提案ではEVMのシステムオペレーションのOPCODE、SELFDESTRUCTを使用すしコントラクトを参照して資産をロックするリスクがとても高いとし、変更を行いコントラクトの消滅による資産の凍結問題を解決するというものです。
4-3.4つの提案されているビルトイン関数
1.CREATEAT・・・Callerのアドレスと特定の過去のナンスから生じるアドレス内の任意のコントラクト
2.CLAIM・・・CREATEATと同様ですが、生成されたコントラクトが使用可能にする前に500,000ブロックの遅延
3.PROXY・・・CREATEATと同様ですが、Callerに最初に明示的な代理のCall承認を要求。更にCallerに全ての資金を送金するための代理コントラクトアドレスを新しく生成する
4.MULTI_PROXY・・・Callerのアドレスと特定の過去のナンスから生じる代理のコントラクトをアドレスに生成、更にアドレスのコールが送信される様に任意のコーラーが設定出来るようにする。そして更にCallerに全ての資金を送金するための代理コントラクトアドレスを新しく生成する
4-3-1.新しいビルトイン関数の不変条件
Nick氏によるとParityの提案は下記2点の不変条件を破ろうとしているとしています。
1.コントラクトアドレスのコードは変更されない。
2.コントラクトの作成者は生成されたコントラクトに関しては特別なアクセス権または特権を有さない
１.の不変条件には「SELFDESTRUCTにより消去されたコントラクトを除く」という条件が入ることにより、2.の「アクセス権と特権を持たない」という点を排除しようとしているということです。
4-3-2.不変条件の変更の性質と利点
変更の性質としてはイーサリアムクラシックでも問題となった「コードの不変性を緩和する」という波紋を呼ぶ可能性が高い内容となっています。「SELFDESTRUCTによるものは例外とする」という点においてはThe DAOと同様にも見えますが、ユーザビリティの向上と今後の予見される資産の凍結問題を解決、更に凍結された多くの資産を救出するという利点があります。
5.イーサリアムデベロッパーの意見
イーサリアムのオフチェーン解決ライデンネットワークのデベロッパーLefteris Karapetsas氏によると
「個人的に納得できないのは4つの提案ともに、今までにデプロイされたSELFDESTRUCTを含むコントラクトがこの変更を導入するというファンダメンタルの変更が必要という点です。
気持ちはわかるし、可能なら行いたいが何か他の方法での資産を回復する方が望ましい」
と述べています。
またNick氏も同様にSELFDESTRUCTを使用したコントラクトの数から予測困難であるとし、
「既にデプロイされているSELFDESTRUCTを含んだコードの数からとても難しいと考えており、潜在的なリスクによりどの4つの不変条件変更の提案は個人的に推奨できない」
と述べており、支持していません。
6.凍結資産救出ハードフォークの結論と考察
今回のハードフォーク問題はとてもセンシティブな内容であり、かつとても難しい内容となっているためどれが正しいかという点を見極めるのがとても難しくなっています。Parityの主張するユーザビリティと今後の事故の対策としては私個人としては支持したい内容となっています。
6-1.不変条件から考察する不変性
ではここで今回のOPCODEの変更と、ビルトイン関数から変更される不変条件を再度確認してみます。SELFDESTRUCTが持つコードのないコントラクトの資産凍結問題は深刻であり、対策が必要だと私は考えています。ですが、今後起こりうる同様の資産凍結は多くのコード監査による防止が可能であり、OSSプロジェクトとしての有利で重要な点です。
そもそも今回の議論の基となっているParityのマルチシグウォレットのバグによるハックはコード監査不足によるものが多く、一つの例から不変条件を変更することにより、不変性を弱めることはデプロイされたコントラクトへの影響などを考慮するとネットワークのセキュリティホールになる可能性もあるでしょう。
6-2.イーサリアムはハードフォークを行うのか？
例えばEIP-156を実装するとした場合でも不変条件は変更され、大きな影響を及ぼすこととなり、イーサリアムはThe DAOフォークと同様の賛否両論の実装を行うこととなってしまうでしょう。プロジェクトとして分裂することはフォークプロジェクトが存続できないことから可能性はほぼ０ですが、信用問題となってくるためイーサリアムファンデーションもフォークに関してはとても慎重となっています。
私個人としてはユーザビリティの向上はとても重要であり、今後高い確率で起こりうる資産凍結に対する対策と考えるとフォークに賛成ですが、Nick氏やLefteris氏の意見の通り簡単に容認出来るものではなく、例え行うにしてもスパムアタックのときと同様な長期的議論が必要となるでしょう。
イーサリアムの購入は安全に資産を管理できるbitFlyerがオススメです。
関連する記事
スポンサーリンク
ビットコインやイーサリアムその他仮想通貨の情報はツイッター上で速報を出しています。
Follow @bokujyuumai Tweet
仮想通貨ランキング Tweets by bokujyuumai