0xの新バージョン(v2)の紹介
0xのソースコードを見ていたらcurrent, previousで大きく分かれる構成となっていた。調べたところ、0xは今夏メジャーアップデートを控えており、これまでの0xが抱えていた技術的な制約を取り払っていくという。
開発者ブログがあったので翻訳してみた。
0xプロトコル v2の紹介
サマリー
今日のエコシステム開発
0xプロトコルが実装された最初のスマートコントラクトは2017年8月にメインネットに公開された。以降0xコアチームはコミュニティからの好評に驚かされた。現在、15の0xリレイヤーがメインネットでERC20トークンを取引していて、dY/dXやSetのように新しい種類のアセット(例えばデリバティブやバスケットなど)を扱うプロトコルを0x上で開発しているチームもある。
エコシステムが驚くほどユーザーに受け入れられていることも重要だ。以下ハイライト。
延トレード数・・・10万以上
出来高・・・183,000,000ドル(約200億円)
24h出来高・・・4,000,000ドル(約4億円)
週次成長率・・・10％
扱ったトークンの種類・・・300以上
(訳者コメント: とはいえ中央集権取引所の出来高に比べると上の数字ではまだまだマイナーの域に過ぎない)
1日ごとの出来高を時系列にすると取引高の大きな成長が容易に見て取れる。
私たちは開発者コミュニティと深い関係を築き、オープンソースのツールを作るためにフィードバックを活かした。それらは0xを使って開発するチーム、ならびにイーサリアム全体のエコシステムのためだ。
組織としては14人のチームに成長し、年内は拡大を続ける予定である。
0xプロトコルの価値は、開発者コミュニティの貢献(例えばOpenRelayのチームによる0xtracker.comはすばらしいプロジェクトだ)によって拡大している。彼らのような情熱を持った開発者・チームなしには我々は成立し得ない。
0x v2について
アセットのトークン化(The tokenization of assets)はすでに始まった。この流れは今後加速度的に続くだろう。私たちがv1をローンチしたときちょうど最初のERC20トークンが誕生し始めたところだった。それからというものERC20のエコシステムは爆発的に広がり、ERC721、セキュリティトークン、デリバティブなどの新しいアセットも出現した。我々の主題である 世界の価値はトークン化 に合わせて、我々は価値が摩擦なくやりとりされるためのツールを作っている。
フレキシブル・モジュラー志向・容易なアップグレードを我々は重視している。
フィードバックを尊重し、ZEIP(zerox improvement proposal)に寄せられた提案の多くを実装している。
新しいコントラクトアーキテクチャはERC721を含むさまざまなトークン規格をサポートしていく。
バージョン1では中心的な役割のコントラクトが2つあった。Exchangeコントラクト はオーダーの発注・キャンセルのロジックを担当し、Proxyコントラクト はトレードが実行されたときのERC20のトークン量を変更するインターフェースとなる(訳注 ERC20は所有者が他のコントラクト、つまりここでは0xに対して取引を認可する仕組みがある。approve()によってエンドユーザーが0xに対して操作の権限を与え、allowance()というview関数を参照すると実際に認可を得ているかが分かる。こういった認可の確認や実際の取引の処理の抽象化をProxyコントラクトが行う)。
これはワークしているものの、このままではERC20以外のアセットをサポートできない。というのはこのやり方では新しいトークン規格に対応するためには Proxyコントラクトを継続的にデプロイしなおす必要 があり、ユーザーはProxyコントラクトが新しくなるたびに認可を与え直す必要がある。
そこでv2では単一のProxyコントラクトと直接やりとりするのではなく、トークン規格ごとにProxyを用意する。この方法なら一つのProxyをデプロイしなおす必要なくトークン規格に対応していくことができる。
v2の開始時点ではERC20, ERC721の対応をローンチする。Ethmoji, Fan Bits, CryptoKitties, LAND、その他のデジタルコレクティブが0xでやりとりできるということだ。
この新しいモジュラーアーキテクチャは既存のスマートコントラクトに修正を加えたり、開発者・ユーザーにアップデートを強いることなくトークン規格に対応することを可能にした。
そのうちENS, ERC777トークン、R-Tokenも0xでやりとりできるだろう！
EIP-712のサポート
メッセージに署名するとき、そのメッセージが読めないことは苦痛じゃないか？
だから0xチームのメンバーはEIP712、構造化データのハッシュ化標準の提案を作り、それをv2で採用する。
以下のスクリーンショットでEIP712による署名がいかに有用かがわかるだろう。
Takerの抽象化
バージョン1では、注文のTakerは fillOrder関数を呼び出したmsg.senderと常に一致していた(訳注: つまり注文を出す人物とトークンの所有者が一致している必要があったので、トークン所有者が別のコントラクトに注文処理を委託するようなことができなかった)。
v2ではTakerはデフォルトでmsg.senderとなるがそのアドレスによる署名が提供されれば別のイーサリアムアドレスで行うことが可能になる。これは新しいユースケースを広げ、0xを利用した以下のような実装を容易にしてくれる。
リレイヤーによるOrder Matching Modelの利用
takerをホワイトリスト方式にしたり、マルチシグによる注文を要求したりできる。
Trade Execution Corrdinators(訳語不明、教えて下さい)をつくってフロントランニングや嫌がらせを防げる。
新しい署名方式のサポート
バージョン1では注文はイーサリアムの標準暗号スキームであるECDSAで署名して作られている。しかしこれには潜在的に制約がありユースケースを制限してしまう。
v2ではEIP712やTrezorのような新しい署名スキームを採用し、ユーザーに各自のスマートコントラクト内で独自の検証を定義することを可能にしている。これで注文をマルチシグやBLS署名、ring署名その他の暗号化方式で作ることが可能になり、新しいユースケースに対応するために0xのスマートコントラクトをデプロイし直す必要がなくなる。
スマートコントラクト自体が任意の署名検証によって0x上で注文を出すことが可能になったのだ。
アトミックなオーダーマッチング、バッチ処理(訳語間違ってるかも)
v1ではユーザーは一括で注文を出すことができるが前もってトランザクションのために原資を用意する必要があった。
この資金の壁を突破しないと、注文をマッチングするリレイヤーを作ったり、アービトラージのbotを運用することができない。
v2では注文は最初のgasコストのETH以外の前金なしでアトミックにマッチング・約定する。
これは裁定取引やオーダーマッチングの障壁を大幅に低くする。
Forwarding Contract
ETHをERC20互換のWETHに変換する作業は一般ユーザーが0xを受け入れるハードルになっている。(訳注: 0xはERCトークンの交換規格のため、ETHそのものを直接的に扱う術がなかった。solidity上はETHとトークンを区別して分岐して処理するとか、ETHを指すマジックナンバーとしてのアドレス, '0xeeeeee'のようなものを用意するなどすれば回避できるはず。KyberNetworkはその方式。)
ユーザーが0xを簡単に使う解決策を探したところ、”forwarding contract” と “trade widget”(訳語不明) の可能性にたどり着いた。
“Forwarding Contract” では、ユーザーはETHと注文をただ一緒に送ればよく、”forwarding contract”が1つのトランザクションの中でETHをwrapして注文を出すことでTakerはWETHが必要なくなる。
v2では誰でも使える我々のバージョンの”forwarding contract”をtrade widgetと一緒もしくは単独で提供する。
これはもちろんオープンソースで誰でも改変したコントラクトを作ってデプロイして良い。
Launch Timeline
5/21・・・v2のインターフェースの最終版を提示
6/9・・・kovanにデプロイ、既存のリレイヤーやdappsと統合テストを実施
7/2・・・DiligenceとQuantstampによるセキュリティ監査の開始
7/30・・・メインネットへデプロイ
リレイヤーのアップデート手順
省略
ユーザーのアップデート手順
v1で作った注文は無効になりv2では処理されない。ただしv1ではそのまま有効となるので約定させたくなければv1に出した注文をキャンセルするか、手持ちのERC20のallowanceを解除すればいい。
ユーザーはv2のProxyコントラクトにallowanceを行う必要がある。
WETHはどちらのバージョンの0xでも利用可能。
v2のローンチと同時にポータルサイトのアップデートも行うので0xリレイヤー、dappsを見つけることができる。
FAQ
v1のスマートコントラクトはどうなるか
v1のコントラクトはv2がローンチされリレイヤー、ユーザーが新しいコントラクトに移行できるまでしばらく有効となる。しかしExchangeコントラクトからProxyコントラクトへのアクセスはMultiSigWalletを使って無効化される。v1の廃止勧告は時期が近づいたらアップデートするが、10月の終わりを目処にしている。
v2のガバナンスについて
Governance in 0x Protocolで説明したように、我々は完全な分散型ガバナンスモデルへの移行を検討している。TCRを開始し、コミュニティの拒否権を近々組み込んでいく。
Proxyコントラクトをコントロールする期限付きのMultiSigはv2でも存在するが段階的に廃止予定。
ERC20, ERC721以外のTokenProxyがデプロイされるのはいつか
それらに関して確かなスケジュールは決まってないが、計画に則って優先的に行っていく。
ユーザーとしてv2でトレードするのに何をすればいいか
ユーザーはただV2のProxyがトレードを実行するためのallowanceを行えば良い。v1の注文はそのまま有効なのでそれらをキャンセルしたければ手動でキャンセルするか、v1のProxyコントラクトに対してallowanceを0にすればいい。
