論文Anonymous Zether實驗復現（持續更）

Zero發表於2020-11-14

附上論文地址：https://github.com/ConsenSys/anonymous-zether/blob/master/docs/AnonZether.pdf

以太坊隱私智慧合約層Zether概述

什麼是Zether？

史丹佛大學的博士生Benedikt Bunz（Bulletproofs防彈證明方案作者之一）、史丹佛大學教授Dan Boneh以及Visa研究部門，聯合提出了一種針對以太坊智慧合約平臺的隱私協議：Zether。

Zether是一個以太坊上的匿名支付協議，以智慧合約Zether Smart Contract（ZSC）的形式部署在以太坊上，並且具有稱為Zether令牌（ZTH）的代幣，其在作為ElGamal公鑰的Zether賬戶之間傳輸的載體，並支援匿名的智慧合約互動。

Zether的論文首發於史丹佛密碼應用小組，地址是：
https://crypto.stanford.edu/~buenz/papers/zether.pdf

論文的其中一位作者Benedikt Bunz，已開源了Zether協議的部分程式碼及測試程式碼，有興趣的讀者可以瞭解一下，地址如下：

https://github.com/bbuenz/BulletProofLib/tree/master/src/main/java/edu/stanford/cs/crypto/efficientct/zetherprover
https://github.com/bbuenz/BulletProofLib/tree/master/src/test/java/edu/stanford/cs/crypto/efficientct/zether

二、Zether的特點

在論文中，開發人員總結了他們的貢獻，同時結合作者自己理解，總結Zether的特點如下（需要注意隱私和匿名是不同的兩個概念，該專案均能實現，為了方便閱讀，統一稱為隱私）：

1、代幣屬於剛需：代幣ZTH不是ERC20的代幣，是其內生代幣，如果沒有的話，技術上其隱私功能無法實現，屬於剛性需求。

2、具備隱私性：Zether的交易是保密的，賬戶餘額和交易地址始終是加密的。

3、新的隱私演算法：為了讓Zether變得更有效，研究者提出了一種新的零知識證明機制，稱為Σ-Bullets，結合了Bulletproofs（防彈協議）與Σ協議特性，以此為基礎建立了其隱私賬戶體系，並且不需要Zcash的可信啟動。

4、易於實現：理論上，支援智慧合約的鏈均可以實現該專案，目前團隊已經在以太坊上進行了初步實現和測試。

5、互操作性：Zether支援智慧合約的互動。在論文當中，作者們展示了Zether可構建的四種應用，分別是：保密競拍應用、保密支付通道、保密權益投票、以及私密權益證明（private proof-of-stake）。

6、基於賬戶模式：目前門羅、Zcash等各種隱私幣都是基於UTXO的，而Zether是基於賬戶模型的，有可能是第一個。

三、Zether方案概述

以下部分略顯枯燥，如果純投資考慮的話，可以直接看第四部分：Zether面臨的挑戰。

一個基本的Zether功能：

Zether賬戶使用ElGamal加密進行標識，這些公鑰儲存在ZSC的內部狀態當中。使用者通過Fund transaction存入以太幣到指定一個Elgamal公鑰，來建立一個Zether賬戶。例如：通過公鑰y，使用者將b ETH傳送到這個智慧合約，可以獲得b ZTH的賬戶。使用者通過Transfer transaction將ZTH從Zether帳戶轉移到另一個帳戶。使用者通過Burn transaction將Zether帳戶相關聯的所有ZTH換成以太坊地址中的以太幣。若干連續的區塊組成一個Zether的epoch，各項交易都需要在當前的epoch內完成。

所有的交易通過Σ-Bullets來有效地證明各方交易餘額。

Front-running（非正常預先交易）：

Zether簡化版本的第一個問題，就是零知識證明需要保證合約和賬戶狀態不變，例如，轉賬交易中的零知識證明，需顯示剩餘餘額為正。使用者Alice將生成與其當前賬戶餘額相關的證明，以加密形式儲存在合約當中。然而，如果另一個使用者Bob將一些ZTH傳輸給Alice，並且Bob的交易首先得到處理，則Alice自己的交易將被拒絕，因為餘額證明將不再有效。請注意，Bob可能是一個誠實使用者，但在這種情況下，Alice因為處理自己交易失敗而失去其支付的費用。論文將這種情況稱為非正常預先交易（Front-running）。Burn transactions也有類似的問題：如果密文發生變化，加密某個值的密文證明將會失效。

為了解決這一問題，論文可引入一種新的交易型別，它只鎖定賬戶，以防任何傳入的轉賬。Alice可等到自己的交易寫入區塊鏈後，再開始其他交易。雖然這似乎解決了問題（需兩步流程為代價），但它為像Bob這樣希望將ZTH傳送給Alice的使用者，帶來了新的問題。當Bob釋出傳輸交易Tx時，Alice的帳戶可能不會被鎖定，但它可能在Tx進入之前被鎖定，從而導致Tx被拒絕。

當引入匿名機制後，任何一種鎖定方法都變得更加不可靠。如果Alice想隱藏自己，為了確保她的交易通過，她必須鎖定匿名集中的所有帳戶。顯然，這是不允許的：Alice不能有權利鎖定其他使用者的帳戶。另外，Alice只能將鎖定的帳戶放在她自己的匿名集中。但是，如果有人在Alice的交易完成之前，解鎖了他們的帳戶，那麼Alice的匿名程度就會降低了。

Pending transfer（待處理交易）：

為了解決非正常預先交易（Front-running）問題，論文把所有的傳入傳輸保留在一個等待狀態中。這些轉賬會不時地轉入賬戶，以便轉入的資金可被使用。這種滾動法不能在任意時間發生，否則證明將會再次失效。

為了解決這個問題，協議作者將時間分為epoch時期，其中一個epoch由k個連續區塊組成。k的選擇取決於兩個因素：a）區塊鏈最新狀態與任何使用者檢視之間的間隔；b）將交易納入區塊鏈所需的時間。在每一個epoch週期結束時，待處理的轉賬將轉入相應的賬戶。使用者需要在epoch週期開始時釋出他們的交易。因此，即使他們沒有看到區塊鏈的最新狀態，他們也不會進入下一個epoch週期。只要明智地選擇k，交易將在帳戶更改狀態之前處理。

Rolling over on a smart contract（智慧合約重新整理）：

不幸的是，重新整理智慧合約並不像看起來那麼簡單，因為除非向其傳送交易，否則智慧合約不會做任何事情。人們不能指望每個使用者都為每個epoch傳送重新整理訊息，而且他們也無法在合適的時間獲得這樣的資訊。

第一個想法是在收到epoch中的第一條訊息時翻轉所有帳戶的待處理轉帳。 然而，這給該訊息的傳送者帶來了不合理的負擔：它將不得不支付重新整理其不擁有的帳戶的成本，這可能非常多的GAS。 此外，使用者無法知道他們的交易是否是一個epoch的第一個，因此他們無法估計合適的GAS。

當收到來自此帳戶的第一條訊息時，我們在一個eopch中重新整理一個帳戶; 因此，一條訊息僅覆蓋一個帳戶。 為了實現這一點，論文定義了一個單獨的（內部）方法來進行重新整理，而每個其他方法所做的第一件事就是呼叫這個方法。 由於沒有從它們發起任何交易，因此可能存在幾個連續時期沒有重新整理的帳戶。 這不是問題，因為帳戶持有人，比如Alice，並不是想用她的錢。 在稍後的某個時間點，當Alice想要對她的帳戶進行操作時，她將釋出交易。 自上次滾存以來轉入其帳戶的所有資金將立即轉入並可用於支出。 實際上，當Alice建立一個ZK證明時，她會假設她的帳戶狀態是當所有待處理的轉移都轉入其中時的狀態。

重放攻擊保護（Replay protection）：

與任何其他支付機制一樣，Zether需要處理重放攻擊。 以太坊通過將nonce與每個帳戶相關聯來提供自己的重放保護，這需要在每個事務中籤名。 不幸的是，由於兩個原因，Zether的這種保護水平是不夠的：（1）Zether帳戶有自己的公鑰; 它們與以太坊地址無關。 （2）Zether事務包含非互動式ZK證明。 惡意行為者可以竊取這些證據並將其置於新的交易中。 如果帳戶的狀態沒有改變，那麼新的交易也將成功處理，導致資金損失。

為了防止此類問題，我們將nonce與每個Zether帳戶相關聯。隨著事務的處理，隨機數增加。來自帳戶的新交易必須與交易資料一起簽署與該帳戶相關聯的隨機數的最新值，該交易資料包括任何ZK證明。此方法將事務的所有元件繫結在一起並確保最新。 ZK證明無法匯入惡意事務，無法重播有效事務。

有一種方式正嘗試是否有辦法使用以太坊自身作為Zether帳戶。然後，帳戶將使用與地址對應的金鑰進行操作，這樣將免費獲得重放保護和簽名驗證。但是，這會強制使用者從固定的以太坊地址操作Zether帳戶。他們無法將帳戶委託給不同的地址，例如將帳戶鎖定到智慧合約時。此外，以太坊地址只是公鑰的雜湊，而不是完整形式，零知識中雜湊的證明非常昂貴。最後，為Zether帳戶提供單獨的公鑰也有助於使設計更加模組化和獨立於平臺。

與智慧合約互動：

Zether的主要設計目標是與任意智慧合約互操作，這些智慧合約可能包含錯誤甚至是惡意設計。與常規智慧合約之間的一個重要區別是普通合約無法生成ZK證明，因為它們沒有任何祕密狀態，無法啟動ZTH轉移。

我們通過引入鎖定/解鎖功能使Zether與其他智慧合約互操作。舉個例子，假設Alice擁有一個帳戶acc。 她可以鎖定自己的賬戶到到任意智慧合約，比如說合約SC。實際上，這會將acc的所有權轉移給SC。現在，Zether將僅處理來自SC的acc交易。 Alice和其他使用者或其他合同傳送的任何交易都將被拒絕。但是，如果需要，ZK證明仍將由Alice生成，並通過SC轉移到Zether智慧合約,SC最終可以解鎖acc以將其控制權返回給Alice。

四、Zether面臨的挑戰

同樣的，該技術由於剛起步，也面臨很多挑戰。

1、GAS消耗量過大，成本過於高昂。目前一筆最簡單的轉賬需要0.014ETH的手續費，如果進行智慧合約的互動，則手續費會成為天價。幸運的是，隨著演算法改進和以太坊升級，手續費可能會大幅下降。

2、以太坊的GAS機制可能會導致隱私洩露。因為部署在以太坊上的智慧合約需要支付GAS來執行，一旦一個地址轉移ZTH代幣，他就需要同時向礦工支付GAS，這個時候他的以太坊地址就暴露了。有兩種可能的解決方法，一個是使用者不停的更換地址來保持匿名，但這樣很麻煩，另一個是讓礦工接收ZTH作為手續費。最後如何解決，還要看團隊的思路。

3、網路繁忙可能會導致交易失敗。對於傳統以太坊交易，網路繁忙可以一直等待，直到網路不再擁堵來完成交易，但在Zether則不行，因為每個epoch都有自己對應的唯一的證明集合，交易必須在自己的epoch完成，如果不能完成，則證明集合會發生變化導致交易失敗。

4、同樣的，為保證成功，傳送賬戶需要保證在當前epoch內，所對應的匿名集不能先於他接收新的交易之前進行更新，否則會導致失敗。

五、實驗復現

https://github.com/ConsenSys/anonymous-zether

執行環境：

  • Yarn, version v1.22.5
    Javascript 包管理器
  • Node.js, version v12.18.4
    Node.js 就是執行在服務端的 JavaScript
  • Truffle v5.1.48 (core: 5.1.48)
    Truffle是針對基於以太坊的Solidity語言的一套開發框架。本身基於Javascript。
    詳細介紹：https://truffle.tryblockchain.org/
    https://learnblockchain.cn/docs/truffle/getting-started/running-migrations.html

引數設定

執行Node.js demo

  • Node.js示例專案將首先部署必要的合同：InnerProductVerifier.sol，ZetherVerifier.sol，BurnVerifier.sol，最後是ZCS.sol（取決於這些先前的合同）。
    完成此操作後，Node.js應用程式將為帳戶 注資，新增“朋友”並進行匿名轉移。
  • 在zether的packages目錄下執行node example
Inner product verifier mined (address = "0x9d13C6D3aFE1721BEef56B55D303B09E021E27ab").
Cash token contact mined (address = "0x1349F3e1B8D71eFfb47B840594Ff27dA7E603d17").
Burn verifier mined (address = "0xd9d64b7DC034fAfDbA5DC2902875A67b5d586420").
Zether verifier mined (address = "0x8a5E2a6343108bABEd07899510fb42297938D41F").
ZSC main contract deployed (address = "0xFe0602D820f42800E3EF3f89e1C39Cd15f78D283").
ERC20 funds minted (balance = 1000).
ERC funds approved for transfer to ZSC (allowance = 1000).
Registration submitted (txHash = "0x2999991dffacd1f440a6d5fcfd74b7c7f4aeee0208e788927a2786ae1bd305c1").
Registration successful.
Initiating deposit.
Deposit submitted (txHash = "0xcd2fbed07abbb90f7dcee85589e7101b433863e842871e7e50e6cdcd3c60f3d3").
Deposit of 100 was successful. Balance now 100.
Your withdrawal has been queued. Please wait 4 seconds, for the release of your funds...
Withdrawal submitted (txHash = "0x10510500abcf7ff64e881e8e56170ea23d508005d47efba13a70ac910739ac46").
Withdrawal failed: Error: Transaction has been reverted by the EVM:
{
  "blockHash": "0xe73c5f42db34afba25ed5752da12018c28f124ba5d0e154aafc5a02ea6c7e171",
  "blockNumber": 221,
  "contractAddress": null,
  "cumulativeGasUsed": 354476,
  "from": "0xed9d02e382b34818e88b88a309c7fe71e65f419d",
  "gasUsed": 354476,
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "status": false,
  "to": "0xfe0602d820f42800e3ef3f89e1c39cd15f78d283",
  "transactionHash": "0x10510500abcf7ff64e881e8e56170ea23d508005d47efba13a70ac910739ac46",
  "transactionIndex": 0,
  "events": {}
}
Error: Transaction has been reverted by the EVM:
{
  "blockHash": "0xe73c5f42db34afba25ed5752da12018c28f124ba5d0e154aafc5a02ea6c7e171",
  "blockNumber": 221,
  "contractAddress": null,
  "cumulativeGasUsed": 354476,
  "from": "0xed9d02e382b34818e88b88a309c7fe71e65f419d",
  "gasUsed": 354476,
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "status": false,
  "to": "0xfe0602d820f42800e3ef3f89e1c39cd15f78d283",
  "transactionHash": "0x10510500abcf7ff64e881e8e56170ea23d508005d47efba13a70ac910739ac46",
  "transactionIndex": 0,
  "events": {}
}
    at Object.TransactionError (/Users/zhaozijun/anonymous-zether/node_modules/web3-core-helpers/src/errors.js:63:21)
    at Object.TransactionRevertedWithoutReasonError (/Users/zhaozijun/anonymous-zether/node_modules/web3-core-helpers/src/errors.js:75:21)
    at /Users/zhaozijun/anonymous-zether/node_modules/web3-core-method/src/index.js:448:48
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  receipt: {
    blockHash: '0xe73c5f42db34afba25ed5752da12018c28f124ba5d0e154aafc5a02ea6c7e171',
    blockNumber: 221,
    contractAddress: null,
    cumulativeGasUsed: 354476,
    from: '0xed9d02e382b34818e88b88a309c7fe71e65f419d',
    gasUsed: 354476,
    logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
    status: false,
    to: '0xfe0602d820f42800e3ef3f89e1c39cd15f78d283',
    transactionHash: '0x10510500abcf7ff64e881e8e56170ea23d508005d47efba13a70ac910739ac46',
    transactionIndex: 0,
    events: {}
  }
}

我這裡報了錯誤，暫時還沒調好

相關文章