前言
兩週前在0x Protocol簡介這篇文章中，介紹了 0x 這個給大家創造去中心化ERC 20 代幣交換的智能合約協定。就純粹ERC20 Token交換而言，0x的智能合約體系已經是非常成熟穩定，但0x的開發團隊這一年來仍然不斷為新一代的合約努力，也終於在最近釋出了0x v2的所有library，也已經將主合約上架到ETH主網。
0x Contract 2.0
新一代的合約帶來的變化可不僅僅是效率優化這種小事，而是提供了一個更全面、更彈性化、並且有利於未來升級的合約架構。以下我會列舉幾個重要的大改動：
支援 ERC721 Token 以及未來新的Token Standard
在原本的0x Protocol合約中，只能夠支援ERC20 Token彼此之間的交易。說實在話現在幾乎所有在以太坊上有價值的代幣都屬於ERC20，所以其實沒有支援其他代幣標準也無傷大雅。但人們比較擔心的是未來如果有其他重大的代幣標準升級，初代的0x 合約就勢必要被淘汰。例如去年底開始流行的ERC 721 Token Standard，就無法使用0x Protocol來交易。因此在新一代的0x 合約中，對於授權、Proxy機制、還有傳遞資料的處理都有不同的規定，就是為了 兼容不同代幣標準的互換，同時保留未來升級的空間。
v1
在初代的0x 合約中，交易的實際執行是由Proxy.sol來執行，我們需要事前授權(approve)這個Proxy的地址挪用我們某數量的ERC20 Token。但是ERC712(或是其他比較新的token standard)的approve 與ERC20並不相同，例如ERC 721的approve就多了指定授權代理人「挪用我的哪一個代幣」Token ID。這是初代一個proxy contract不能夠解決的。
v2
第二代的合約架構中，其實就是用了最直觀的方法，利用不同的AssetProxy來代理不同代幣標準的幣別交換。因此在我們指定要交易哪種token時，如果是不同Token Standard，會透過不同的方法來表示這個「Asset」。我可以在Library中看到 EncodeERC20Token()以及EncodeERC721Token()等等不同的函式，未來如果出了不同的Token標準，也可以在另外規定他的Encode規則。經由不同的Encode規則得出的結果就是AssetData ，合約可以經由AssetData判斷要交易的是哪種Token，進而選擇透過不同的AssetProxy來進行交換。
符合EIP 712 規範的簽名
EIP712這個協定其實就是由0x 的工程師Leonid Logvinov 等人提出的。在v1的時候大家注意到對於一個orderHash進行直接簽名是一個危險的舉動，畢竟大家在看到一個hash值時根本不會知道內容正確與否。（如下圖，圖片取自EIP712 Doc）
EIP712其實就是希望未來大家都規定好，簽名不要再純粹只是對字串進行簽章，而是有系統性地對一個「結構化的資料」進行簽章。如此一來大家可以各自實作不同的介面，對使用者顯示他們實際要簽署的資料、格式，未來要提交的合約地址，或是官方網站網址等資訊。而在智能合約驗章的部分，也透過一樣的方法解析、驗證簽名。
未來簽署的格式可能如下：
0x 由於自己開發者就是該協議提倡者，所以應該算是最早實作這一協議的一群人，我們也可以從他們eip712_utils.js程式碼中看看實作個過程。有興趣對EIP712了解更多的人可以看這篇文章 : EIP712: A small change towards global adoption of crypto。
獨立Taker 以及Sender
最後再提一點，在v2中，relayer可以選擇提供使用者「幫忙上鏈」的服務。在新的生態系中多了一個被稱為「Sender」的角色，負責呼叫fillOrder執行該筆訂單。如果沒有指明的話任何人都可以提交，這就跟taker的設計一樣，可以指名也可以不指名。這麼做給予了Relayer的建設更多的彈性，可以由Relayer的地址一次呼叫多筆訂單的執行，不再需要每個end user自行上鏈。
小結尾
今天簡單介紹了0x Protocol 第二版合約的架構改動，除了合約本身以外，JavaScript的套件包也是完完全全徹頭徹尾的大改了一波，現在有了更好的模組化，我覺得用起來滿順手的。
官方團隊表示今年十二月就會全面升級至V2的合約，真是期待呀～ 希望那一天快點來，我想要退伍了。
P.S. 有興趣了解更深的人，可以看0x 官方提供的 0x Protocol V2 Specification了解更多細節以及實施標準。相信對於各位對於去中心化應用設計會有很大的幫助！