非中央集権的なPausableの提案

今回はこちらの記事を読んで思いついたSmartContractの紹介記事です。
btcnews.jp

今回、BancorはPausableを継承したSmartContractを作成していたことで、BNTに関してはすぐにpaused状態にして流出を防ぐことができました。
しかし、この処置に関しては上記の通り、中央集権的であり運営が絶対的なパワーを持っている事実は否めません。そこで今回はその問題を回避するためのDecentralizedPausableを作りましたのでその紹介をします。

サーキットブレーカーに関する批判と現状

基本的に今現在利用されているサーキットブレーカーはOwner(=運営)のみが発動することができるフラグとして管理されています。
これはDapps（Decentralized Applications)の基本理念である非中央集権から逸脱した行為であるという批判があります。
この批判はもっともであるものの、現状不測の事態が起きた場合の対処として、一時的にContractの機能を停止する　という方針しか取れないのも事実です。
このような状況でユーザがそれを承知でDappsを利用しているのは、運営にtrustしているためです。（運営が不正を働けばユーザはすぐにいなくなり、結局運営のインセンティブが消滅してしまうため。）

非中央集権的なサーキットブレーカーの提案

サーキットブレーカーとしては以下の要件を満たす必要があります。

• 緊急時に即時停止が可能であること

非中央集権な要素としては以下の要件が必要です。

• ユーザが自分の意思でpause/unpauseを決定できる

上記２つを満たす非中央集権的なサーキットブレーカーの要素を以下のように定義しました。

1. 非常時にはOwnerによって即時停止が可能であること
2. Ownerによって停止された後は各ユーザが自分の意思でunpause可能であること

まぁ、そのまま繋げただけですw

投票制を採用しなかった理由

Decentralizedな方策としてよく例に上がる投票制を導入する案も考えられますが、サーキットブレーカーのような緊急性を要するものには適切ではありません。
その理由としては次の通りです。

• ユーザの無関心による即効性のなさ
• 大多数のユーザが正しい判断を下せるわけではない
• Contractを正常化するのに一番のインセンティブを持っているのはowner

そのため、一旦ownerにより機能を停止し、その後各ユーザが独自の判断でpauseを解除するという方針をとるのがベストだと考えました。

DecentralizedPausableの実装

ということで早速実装してみました。
github.com
リポジトリは以下です。
github.com

疑似コード

こちらの疑似コードで体験してください。EthFiddleだとmethod call時のwallet addressが変更できないのでRemixで試すほうが良いです。
ethfiddle.com

Feature

1. block heightごとにユーザのstateを管理

mapping(uint => mapping(address => bool)) public unpausedUsers;

~~~ snip ~~~

 function unpauseOnlySelf() whenPaused public {
    require(owner != msg.sender); // owner can not calle this.
    unpausedUsers[pauseStartBlock][msg.sender] = true;
    emit UserUnpause(msg.sender);
  }

これで以前のpauseのときに解除したユーザが次回のpause時には状態がリセットされるようになります。

2. ownerは unpauseOnlySelfできない

OwnerはContractを正常な状態に戻して全体のpause状態を解除すべきだからです。
またownerが自分自身のみunpauseできてしまうとビザンチン故障になり得るためです。

まとめ

Upgradable Contractの実装にも今回のような方針は適用できると思っています。（その場合はupgrade後にユーザ投票によってdown gradeを行う）
不測の事態が発生した時の対処の方針は、基本的に中央集権的でなければいけないのも事実です。今回の提案は若干ワークアラウンド的な感じもします。
ですが、非中央集権の大事な要素である「選択ができること」は十分に満たしていると思います。
まだまだSmart Contractに対するPrograming手法も成熟していません。各個人がいろいろ考え積極的に提案して改善していくことが重要です。

以下の場でも日々日本語でEthereumに関する様々な議論を行っておりますのでぜひ興味のある人は覗いてみてください。
research.cryptoeconomicslab.com