因為它，中心化交易所要慌（黃）了嗎？
作者 | Gnosis
譯者 | 臣天
自門頭溝事件以來，中心化交易所屢屢出現安全問題，造成大量金錢丟失，由於區塊鏈技術的去中心化特徵，去中心化交易所大勢所趨，被認為更加安全。
Snark 是以太坊下一個側鏈解決方案，由以太坊研究者 Barry Whitehat、Harry R、Alex Gluchowski 等人共同提出，理論上可以使以太坊網路實現 17000TPS 的吞吐量。
本文我們將著重介紹基於 Snark 的去中心化交易所 dFusion。基於程式碼，它真的可以實現上萬TPS吞吐量嗎？如果實現，能否真正幹掉中心化交易所？
跟隨作者，一探究竟！
dFusion是一個完全去中心化的交易所，基於Snark方案，能後將網路交易能力大大擴充套件。這項擴充套件技術使得資訊通過Snark技術後僅儲存在默克爾樹根，並且只能通過預先留下的邏輯閘CP進行操作與處理，從而加快了交易速度。
為了允許更多的Snark引數，我們計劃採用DIZK（分發零知識證明系統）中的想法。對於批量交易的處理，我們採用了Gnosis開發的無套利價格清算技術。下面讓我們詳細地去了解一下其架構。
現實中大多數交易所並不是去中心化的，交易所收下使用者的幣和錢，將數額記錄在使用者的賬戶上，交易只是雙方賬戶數字上的增減，記錄在交易所的資料庫裡，不寫在區塊上。在我們設想的交易所中，使用者通過N種預定義的ERC20代幣（代表N種數字貨幣）進行限價交易。
對於每種代幣，都會有一棵默克爾樹作為交易集與之對應，默克爾樹根的雜湊值為：balanceTRH_I （for 0<I<=N）。在每棵默克爾樹中，每一個葉子節點只會儲存某個使用者的單一類代幣餘額。
交易所賬戶的地址和交易輪次資訊儲存在另一顆默克爾樹中，這棵交易樹根雜湊值為accountsRH。
balanceTRH_Token與accountsRH是一一對應的，balanceTRH_Token中第i個葉子節點的餘額屬於accountsRH中第i個葉子節點的賬戶。
所有的交易都被編碼為以下交易格式：
（accountLeafIndex，fromTokenIndex，toTokenIndex，limitPrice，amount，nounce，signature）。
交易的處理邏輯為：
葉子索引為 accountLeafIndex 的使用者，希望從 fromTokenIndex 賬戶中的代幣向 toTokenIndex 賬戶轉移 amount 的代幣，當且僅當 amount < limitPrice 時執行。
對於所有樹根的雜湊值[accountsRH, balanceRH_1, ..., balanceRH_N]將會被合併後一起雜湊。balance樹按默克爾樹規則散列出balanceRH_，再與accountsRH合併處理，得到最終雜湊值stateTRH。最終雜湊值“stateTRH”儲存在“錨定的”智慧合約鏈上，合約將儲存一切與交易相關的資訊。
儲存系統架構
交易的工作流如下：
1. 獲取交易列表（獲得交易通過後所得雜湊值）
2. 過渡處理：將SHA雜湊值轉換為Pederson雜湊值
3. 挖礦：尋找最優清算價格
4. 上鍊：更新餘額
5. 處理待處理的存取操作
6. 從第一步重新開始下一輪交易
我們將對工作流逐一介紹：
1、獲取交易資訊
通過呼叫以太坊上智慧合約程式設計內建的Kecca256函式：
這個函式能夠輕鬆地更新orderHashSHA變數，這個變數隨著新交易的產生而改變。這個函式是public的，可以被任一方呼叫，從而達到去中心化的目的。按照我們的預計，“執行者” 會將所有使用者的交易捆綁到一起，然後再一同進行雜湊。因為是在Snark側鏈上操作，所有交易只會作為事件來進行傳送和請求，並不會儲存到以太坊虛擬機器中。
2、過渡處理
在上一步中，我們利用SHA演算法對交易進行雜湊處理。這是因為在EVM中SHA演算法是十分“廉價”的（消耗gas量小），而在Snark中，SHA演算法十分昂貴。為此，我們必須更改計算方法，將原hash轉化為Pederson雜湊值。
我們利用Snark做以下的工作：
Snark – TransitionHashes & Validation snark 將執行以下操作：
通過比較Private input所有交易的SHA雜湊值與原public input是否一致來判斷Private input是否合法，不合法則終止
重新迭代所有交易，並按順序進行Pederson雜湊，將雜湊值作為輸出
請注意，我們允許零元交易（交易不攜帶發起人的代幣），這些訂單將在結算後進行整理並上鏈。
在智慧合約中，我們提供了以下功能：
任何人都可以通過提供代幣所有權與簽名來提出更新狀態機的請求：
如果發現更新請求的資訊不正確，任何人都有權利通過提供代幣所有權與簽名傳送“質詢請求”：
在預設情況下，除非最終解決方案者在規定時間內提交正確的Snark證明，任何有簽名的“質詢請求”都是合法的，並一定會在有限時間內執行。
通過newState碼，我們可以在EVM中對證明進行驗證，使用以下函式，當且僅當證明是有效的時候，系統會更新這個默克爾樹根：
3、挖礦：尋找最優清算價格
在上一步之後，這一輪次的交易已經整理完畢。現在我們需要用一種方式去選出這一輪交易的記錄者，這種方法就是通過計算統一清算價格選出。
統一清算價格是指能夠最大化交易對之間的交易盈餘的一個數字（交易盈餘=(限價價格 - 統一清算價格)x訂單量），這一步類似於公鏈上挖礦的過程。這種計算是一個NP-hard問題，短時間內很難找到最優解。
經過測試，我們認為3-10分鐘是比較合理的選擇。雖然找到的解有可能並不是全域性最優解，但每個人都是公平地去計算並提交自己的最佳解決方案，程式仍然保證了公平與去中心化。程式最後會選擇最大化交易盈餘的清算價格作為最終解決方案。
這種演算法意味著統一清算價格是以一種去中心化的方式計算出的，每個解決方案提交到合約時都會伴有提交者的簽名。若一位提交者被選中，他還必須在下一個步中進行更新餘額資訊服務，並且需要回應來自任何人的質詢請求。
4、上鍊：更新餘額
在競價期後，合約會選出所有提交解決方案中的最優解，此解決方案的提交者（上文的最終解決方案者，下文中通過使用者A代替）需要執行兩個步驟：
a) 將整個解決方案發布至以太坊公鏈上，整個解決方案包含一個價格向量P，一個新的balanceRootHash，還有每個交易的交易盈餘（VV）向量；
注：P只是所有代幣相對於參考代幣Token_1的價格向量，由於沒有套匯的存在，Token_i：Token_k的值等同於（Token_i：Token_1）:( Token_1：Token_k)。
b) 在實際中，並非所有低於限價的交易都能被成功上鍊。有些時候發起交易的賬戶並沒有足夠的餘額去支付。我們將這些交易稱為”uncovered orders"，這些交易需要被挑出並排除。
因此，使用者A需要給每個交易都分一小部分交易盈餘作為補償。
這兩部分構成了解決方案：VV和P作為合約資料的有效載體，記錄交易資料，再一同通過SHA演算法雜湊到hashBatchInfo中。
到此為止，上鍊的部分告一段落了。
現在可以開啟檢查通道了，如上文所說網路中每個人都可以去檢查這個解決方案是否合法，如果非法，每個人都可以發起質詢請求，當用戶A面對質詢請求時，他必須提交正確的Snark證明自己的行為合法。
需要進行以下內容：
priceMatrix/orderVolume：hashBatchInfo通過SHA演算法散列出的值；
檢查向量[balanceTRH_i for 0<i<=N]雜湊值是否為balanceRH；
檢查[VV]是否合法；
對於每一筆交易：
檢查餘額樹種賬戶餘額；檢查賬戶許可權；檢查輪次是否有效並更新至最新狀態；if FollowUpOrderOfAccount == 0；
檢查餘額是否為正（否則，檢查與後續交易賬戶有關的其它交易的收款賬戶和其餘額）；
通過轉移所有權來更新餘額；檢查每個代幣的總銷售盈餘、總購買盈餘、總銷售量和總購買量是否正確；
對於每一種代幣，檢查出入量是否相等；
檢查交易損差的計算值是否與交易總資產相同。
4、存取款操作處理
存取款的操作也需要按順序記錄在“balanceRH”中，我們再次使用Snarks側鏈技術和“質詢請求”的設計。
如果使用者想要存款到公鏈上，可以通過執行以下程式碼實現：
有關存款操作的所有資訊都會被儲存在一個32位位元串depositHash中。每當有20個區塊生成就會產生一個新的depositHash
通過呼叫以下函式，可以完成存款整合：
這個函式會通過整合blockNr至blockNr+19這20個塊中的存款量來更新stateRH
和上文所說的相似，任何人都有權利檢查stateRH是否正確更新，任何人也有權利對錯誤的行為提交“質詢請求”。
這個存款的質詢請求格式如下：
這個需要檢查以下內容：
通過對[deposit information]佇列進行雜湊得到depositHash，檢查是否一致
對於每一筆存款：檢查存款賬戶當前餘額；檢查deposit.sender是否為accountLeaf.address；更新餘額；計算新的stateRH
取款的操作與存款相似，但也有不同之處。在取款中我們只需要小心一件事情：取款的函式一定要在交易所賬本數目減少好再被呼叫，需要保證足夠的處理與同步時間，否則很有可能遭到雙重支付的問題。
下面是取款的智慧合約：
網路中的任何人都可以呼叫以下函式來更新stateRH：
Function incorporateWithdrawals(uint blockNr, bytes32 oldBalanceHash, bytes32 newBalanceHash, bytes32 withdrawalAmounts)
和上面存款操作類似，連續20塊的取款請求會放在一起進行處理。
通過oldBalanceHash和withdrawalAmounts（合法取款數量）來獲取newBalanceHash。
取款的質詢請求格式如下：
需要檢查以下內容：
通過對[exitRequest informaiton]佇列進行雜湊得到exitRequestHash，檢查是否一致
對於每一筆取款：檢查存款賬戶當前餘額；檢查deposit.sender是否為accountLeaf.address&&賬戶餘額是否大於提取金額（更新餘額、計算新的stateRH、withdrawalAmounts+=withdrawal.amount）
如果未收到質詢請求，使用者將會在一天後提款到賬。withdrawalAmounts會被儲存到餘額樹中withdrawalAmounts[blockNr]中。
5、系統可行性分析
這個系統受資訊通過以太坊公鏈的燃料費與對Snark引數數量這兩個因素限制：
a) 燃料費計算
對於每個交易 (accountLeafIndex, fromTokenIndex, toTokenIndex, limitprice, amount, signature)，有以下規定：
最多在交易中使用2^6個不同的代幣
最多有2^16個不同的子葉
價格被編碼為64位浮點數（61位有效位數）
數字簽名為一對（s，r，v），其中s和r大小與橢圓曲線素數相近，這代表（s，r）大致有512位元大小。綜上，我很可以用三個bytes32來儲存任何交易。
K個交易的燃料費計算公式為：
transaction initiation costs + k* order as payload costs + k* signature verification cost + k* hashing costs + updating the orderHashSHA+21000+ 21000+k*(6+16+16+64+64+512)*68/8+k*3000+k*60+5000
經過測試，1000個交易大概只需要880萬gas來進行處理。
b) Snark引數計算
按照DIZK論文的架構，我們理論上可以達到數十億的邏輯閘運算能力，這種並行化的方法僅適用於特定的橢圓曲線，以太坊所有的alt-bn128曲線滿足其條件。理論上可以達到2.6億—26億的邏輯閘運算能力。
很明顯，最大的成本來源於檢查操作。我們通過雜湊頻率來估計狀態機的情況，按照網路的構造，這種估計所得值理論上合理。
按照Snark-applyAuction操作的計算，每個pedersonHash可以擁有1.1k個引數，也就是說，我們可以用1M大小的賬戶來處理大約5K比交易。
目前我們所能想到的最大的制約條件在於計算能力可能不足導致交易無法得到及時處理。
為了保證去中心化，我們還需要考慮價格操控的問題。
如果一筆有利潤剩餘的交易（低於限價）發生後，不法者通過增補價格來破壞市場的平衡，從而操控了代幣之間的轉換價格。在這種情況下人們無法提交自己的合法交易，從而導致交易網路癱瘓。不法者去可以通過惡意炒幣來進行低買高賣，從中獲利。
有兩種方法可以防止這種情況發生：
對交易加密：將交易用分散式祕鑰進行加密，當且僅當交易完成後才能解密，這樣不法者就無法獲得正常的市場價格，無法去操作幣價。
將部分交易轉換為期貨：98%的交易用普通的方式進行處理，剩餘2%與GNO / OWl或其它數字貨幣繫結，這樣，不法者就更難去控制所有交易，從而更難去操控價格。
隨著對數字貨幣感興趣的人數增多以及數字貨幣的普及，去中心化的交易所是未來的交易所發展方向和趨勢。希望在技術的進步之下，值得信任的，去中心化的交易網路能趕快到來。
原文連結：
https://github.com/gnosis/dex-research/blob/cc9cdb9ebed2d27732aa512bc649ebbffd5fed91/dFusion/dFusionSpec.md#finding-batch-price-optimization-of-batch-trading-surplus
--【完】--
公眾號又又又改版了，為不錯過最新技術乾貨和行業資訊，建議你按照圖片提示，將【區塊鏈大本營】設為星標（安卓使用者設為“置頂”），看大圖更爽喲！
推薦閱讀
大力戳↑↑↑ 加入區塊鏈大本營讀者⑦群
（內容轉載請聯絡微信：171075719）
（商務合作請聯絡微信：fengyan-1101）