Erc規格にリブート機能をつけない理由は?


#1

ERC20トークンの問題として不正引き出しなどの深刻な問題を解決できず、イーサリアム自体のハードフォーク頼みになるしかない点がありました。

これを重くみて、Liskなどのトークン管理をmain chainから分離する仕様をウリにするプラットフォームも生まれたほどです。

しかしながら、CryptoKttiesのコードには経営陣によるフリーズコード(下記リンクonlyCEO関数を使う)が存在しており、事実上の中央集権性はあまり問題になりませんでした。

ロールバック・リブートコードの本質的な問題とは、中央集権的であることですが、これをDPoS的な相互監視のモデルで改良できないかどうか気になりました。

もっとも簡単な実装例であれば、ロールバックコントラクトを経営陣が提出、トークン保持者上位30アドレスのうち過半数の署名でロールバック実行、指定のブロックまでbalanceをロールバックするになります。

リブートコードを作ることの設計上の問題は何でしょうか?


#2

基本的にtokenはassetであり、token保持者が何らかのアプリケーションを利用した結果としてtokenの移動が起こるものだと思います。
そのため、token balanceをロールバックする際は同時にアプリケーションの状態もロールバックする必要が出てくるかと思います。
となると、ロールバック可能なtokenを扱うアプリケーションは、何かしらのStandardなロールバック設計が必要となってくる。といった部分が問題になる気がします。


#3

アカウントステートのロールバックならstorageRootとcodeHashさえブロックを辿ってロールバックすればよいのですが、ワールドステート(Merkle Tree)のロールバックに関しては技術が必要ですね・・・。
「なんでついてないの?」って言うのは無理なカンジがする機能ではあります^^


#4

Ethereum自体のロールバックは難しいですし、やったらダメだと思います。ですが、ERC20トークンのみに関していえば、TokenContractの状態をある時点と同じ状態に変更すればよいので可能です。
Contractを新しい状態としてあるblock高と同じ状態にする
という意味でのロールバックは他のステートへの影響なく実現できるのでこの方法でのロールバックのほうが良いかと。
ETHをTokenContractから一度も引き出してないという条件を満たすのであれば、手数料を除いたETHも返却は可能です。だいぶ条件が現実的ではありませんが。。。


#5

Ethereumのロールバックというよりはコントラクトアカウントの状態をロールバックするためにブロックから情報を取る形を想定していました。ワールドステートの情報っていらないカンジですかね?


#6

ワールドステートにはたしか全てのコントラクトの状態を表すマークルルートハッシュしか記録されていないため、個々のコントラクトについて、あるblock高での状態を探すことも、また正しい状態にロールバックできているかを検証することも不可能だと思います。

ワールドステートは詳しくないので間違ってたら是非指摘してほしいです。


#7

あるブロック高での自身のfingerprintを残していくようなtokenだったらrebootable tokenといえるかもしれませんね。

ETHの返却まで膨らませるといろいろと考えないといけない問題が多くなりますが、token残高のみをある時点に戻せるようなtokenは何となくできそうな気がしてきました。

fingerprintはその時点での各token保持数とかを元にmerkle treeを構築して作るとかしたらよさそう。
状態それ自体を保持するのはstorage使い過ぎでgas代考えると現実的でないので、ある時点で戻っているか検証できる方向性で考えるとよさそうですね。