誤って失ったREPが救済される(かもしれない)

ジェネシスユニバースへの移行が自動化されることが決まりましたが(詳しくはこちら)、そのついでに誤って失ったREPが救済されるかもしれません。

「誤って失ったREP」とは

あるコントラクトアドレスに送信してしまったREPや、テストネットのアドレスに送信してしまったREPなど、明らかに誤って送信したと判断できるREPが救済対象です。

「救済」とは

誤って送信したと判断されたREPの送信元アドレスに対して、ジェネシスユニバースへの移行時にREPを新規生成するようです。

従って、現在総発行量として定められている 1,100万 REP よりも増えることはありませんが、紛失した(誤ってBurnしてしまった)と思われていたREPが移行時に復活する可能性があります。誤って送信してしまった人には朗報ですね。「復活させなければ有効なREP量が減って所有するREPの価値が上がるのに…余計なことを…」と考えた人、握手してください

実際に救済が行われるかは未確定

この救済を行うには監査済みのコントラクトを修正する必要があるらしく「興味深い課題だが、とりあえず現状の課題を片付け終えてからもう一度検討しよう」ということで、実際に救済が行われるかは確定していません。

救済行為は中央集権的では?

ところで、一部のユーザーを救済するためにコードを書き換えた事件として、Ethereum Classic誕生の原因となったTheDAOハッキング事件を思い出しました。
この時は、TheDAOのスマートコントラクトの脆弱性を突いて、プールされていた大量のETHが別のアドレスに送信されてしまいました。最終的にはEthereumがハードフォークして(この送金を無かったことにして)対処しましたが、この対応の是非を巡って多くの議論が行われました。

今回の自動移行時に紛失したREPを救済するとして、その後同様に紛失したユーザーが救済を要求した場合、開発チームはその要望にどこまで応じるのか?応じる/応じないの線引きはどうするのか?その操作を行う決定権が開発チームにあるのならば、Augurは中央集権的ではないか?と思い、開発チームに質問をぶつけてみました。

回答は次の通りでした。

今回の救済がもし行われるとすると、「移行を自動実行する」という特殊なケースに便乗して行われる作業でありリリースに伴う特殊な作業である。もしリリース後に救済を行う場合は新しくコントラクトを作成する必要があるため、Augurがハードフォークすることになる。その時ユーザーは旧コントラクトに残るのか、新コントラクトを選ぶのか選択することができる。

つまり「将来的に救済は可能だが、その時はTheDAO事件同様ハードフォークが発生する」ということでした。そもそもAugurのリリース当初は「デベロッパーモード」と呼ばれるモードで、緊急時に備え開発者によるシステム停止などが可能な状態で運用されます。安全を重視し、リリース当初は敢えて開発者がシステムの稼働を制御する「中央集権的な運用」になっています。

リリース当初の一時的な中央集権的運用は予定されたことであり、私の上記の質問は少し見当外れだったのかもしれません。

蛇足ですが、このデベロッパーモードを終え、開発者の管理下から解放された状態のAugurを「アンチェインド・ビーストモード(仮称)」と呼ぶそうです。中二くさカッコいいですね。