背景知識

1、智能合約

以太坊中存在外部賬戶和合約賬戶兩種，外部賬戶（Externally Owned Account， EOA）是被私鑰控制且沒有任何代碼與之關聯的賬戶。而合約賬戶（Contract Account， CA）是給智能合約分配的賬戶，被合約代碼控制且有代碼與之關聯。外部賬戶可以發送交易，這個交易可以是轉賬交易，也可以是和智能合約有關的交易，用于創建智能合約或者觸發智能合約。

以太坊的每筆交易Transaction會被轉換成一個Message對象，傳入EVM中執行，隨后EVM將Message對象轉換成Contract對象。如果是一筆普通轉賬交易，那么直接修改 StateDB 中對應的賬戶余額即可。如果是智能合約的創建或者調用，則通過 EVM 中的解釋器加載和執行字節碼，執行過程中可能會查詢或者修改 StateDB。從圖中可以看出，Contract對象會根據合約的地址，從數據庫中加載相應的合約代碼，然后送入解釋器中進行執行。

EVM解釋器是一個基于棧式的機器，它有自己的PC、堆棧、內存和Gas池。一份合約代碼會被解釋為一條條OPCode，然后執行。在執行OPCode之前會檢查該命令所需要的Gas和當前所剩Gas，如果Gas不足，則會返回ErrOutOfGas錯誤。因為EVM是基于棧的虛擬機，他沒有寄存器之類的中間存儲，所有的操作都要通過一個棧來進行維護，所以它的運行效率比較低，完成一個復雜操作可能需要較長的時間。更復雜的操作可能無法在有效時間執行完畢。

2、隱私資產

區塊鏈是公開的分布式交易賬本，鏈上的數據都是公開可見的，雖然一筆交易的發送方和接收方無法和現實生活中買賣雙方進行關聯，但是可以通過對鏈上的數據進行地址聚簇分析，從而得出一些地址和身份的關聯信息。且交易的金額在鏈上也是公開的，可見盡管數據的公開透明保證了賬本真實和不可篡改的特點，但是這也使得很多需要隱私的場景無法在區塊鏈上進行運用。

在此背景下，隱私資產的概念被提出。通過使用密碼學等技術手段將交易的發送方、接收方和交易金額進行隱藏，而礦工（驗證交易者）可以在不需要知道具體數據的情況對一筆交易的合法性進行驗證。常用的隱私資產實現的方法有Mimble-Wimble、ZK-SNARK等。

由于合約模式的廣泛使用，一些項目方想到可以通過使用智能合約來實現隱私交易，如Nightfall、Zether、AZTEC等，通過部署和隱私交易有關的智能合約來達到在鏈上發行隱私資產的目的。

預編譯合約

1、預編譯合約的概念

因為EVM是基于棧的虛擬機，它根據操作的內容來計算gas，所以如果牽涉到十分復雜的計算，把運算過程放在EVM中執行就可能十分地低效，同時消耗非常多的gas。比如在zk-snark中，需要進行橢圓曲線的加減和配對運算，這個過程十分復雜，放在EVM中執行是不現實的。這就是以太坊提出預編譯合約的初衷。

預編譯合約是EVM中為了提供一些不適合寫成opcode的較為復雜的庫函數（多用于加密、哈希等復雜運算）而采用的一種折中方案，適用于合約邏輯簡單但調用頻繁，或者合約邏輯固定而計算量大的場景。預編譯合約通常是在客戶端用客戶端代碼實現，由于不需要使用EVM，所以運行速度快。對于開發者來說比直接使用運行在EVM上的函數消耗更低。

現在以太坊已經實現的預編譯合約如下：

從代碼層面來看，所謂的地址其實就是合約數組的下標，一個下標標識了一個預編譯合約。其中和隱私算法有關的三個預編譯合約是bn256Add（）、bn256ScalarMul（）、bn256Pairing（）。

2、預編譯合約的實現

在evm.go文件中，封裝著evm的操作邏輯，里面有4個函數用于調用智能合約，Call（）、CallCode（）、DelegateCall（）、StaticCall（）。這四個函數做的工作都是生成一個contract對象，但是具體的細節如參數等會有一些差異。contract實例化之后，都是調用evm.go中的run函數來運行智能合約。該函數對預編譯合約和非預編譯合約調用兩種情況均有考慮。下面的代碼中，第一個分支是當該合約是一個預編譯合約的時候，通過指定precompiles這個數組變量的下標來指定某一個預編譯合約，從而實例化p參數。此處數組的下標其實就對應了預編譯合約數組聲明時地址的概念。之后調用RunPrecompiledContract函數來執行預編譯合約。而如果是非預編譯合約，從代碼中可以看到是調用了evm的解釋器進行執行。

go-ethereum/core/vm/evm.go

在RunPrecompiledContract函數中，可以看到p變量實現接收器進行bn256曲線加的操作，然后將結果進行返回。可以很明顯地看到這部分操作是在客戶端語言的執行過程中進行計算的。具體可參見［2］。

go-ethereum/core/vm/contracts.go

go-ethereum/core/vm/contracts.go

3、預編譯合約的使用

在智能合約代碼中，預編譯合約也像普通的合約一樣，可以直接在合約文件中進行調用，但調用方式有一些不同。通過在.sol文件中注明一個assembly代碼塊進行預編譯合約的調用。調用規范和調用的參數如下所示。

一個實現橢圓曲線加法的實例如下

預編譯合約在隱私資產中的應用

1、橢圓曲線的預編譯合約

以太坊現在處理隱私的解決方案是使用zk-snark［6］［8］，但是zk-snark是一個及其復雜的數學過程，里面牽涉到很多橢圓曲線的計算。經過前面的分析，這個過程放在evm里面執行是十分不現實的，所以為了支持zk-snark的相關運算，以太坊分別在EIP196［3］和EIP197［4］里增加了三個與zk-snark運算有關的預編譯合約，可以供開發者調用。

EIP-196增加了在alt_bn128曲線上的ECADD（）和ECMUL（）兩個預編譯合約，其中ECADD（）消耗500gas，ECMUL（）消耗40000gas。

EIP-197增加了在alt_bn128曲線上的配對Pairing函數，消耗gas為80000*k+100000（k和點對個數有關）。

橢圓曲線上的加和乘比較好理解，pairing的出現是因為zk-snark中有KCA（Knowledge of Coefficient Test and Assumption）認證過程［6］，需要用到雙線性映射來進行證明，具體可參見V神medium［7］。Pairing就是證明過程中會用到的公式。Pairing函數的輸入是一個不定長的列表，因為不同的zk-snark算法可能數據量是不同的，并且pairing函數所消耗的gas也與輸入的點對個數有關。

現在許多利用預編譯合約實現隱私的算法都使用到了pairing過程，例如EYBlockchain、AZTEC等。pairing是ZK-snark所必須要求的一個步驟，耗費的gas巨大，當然官方也在做優化。實現pairing的過程一般要在pairing-friendly曲線上來進行，這是一類具有特殊屬性的曲線，主要表現在計算pairing速度很快。所以如果要用pairing這個過程，那么常用的secp256k1這樣的曲線顯然是不適合的，就需要增加對pairing-friendly曲線的支持。

現在主流的pairing-friendly曲線有Barreto-Naehrig（BN）系列和Barreto-Lynn-Scott（BLS）系列［9］，以太坊使用的就是BN系列，ZCASH使用的是BLS系列，以太坊后續也會加上對BLS曲線的支持。BLS的曲線綜合表現會好很多，計算量也相對較小。但是不管怎么樣，選擇曲線都有安全和效率之間進行平衡的一個取舍。

值得一提的是，如果不需要用到pairing過程，也就不需要pairing-friendly曲線。另外一種方案是增加對secp256k1曲線的預編譯合約的支持。例如PGC團隊雖然使用了bn256ADD和bn256MUL兩個預編譯合約，即使用了bn系列的曲線，但是他們的算法是不需要pairing的，如果換成對secp256k1的預編譯合約支持會對算法效率有提高。

針對于C++版本實現的問題，現在主要有兩個外部庫對這些操作進行了封裝和實現。首先是Libff，這也是現在以太坊正在 使用的庫，源碼中LibSnark.cpp調用了libff庫的相關計算函數。還有一個是MCL庫，這是EIP-1108所推薦的庫。

2、隱私資產項目

現在在業內比較流行的四個隱私解決方案是EYBlockchain、PGC、Zether、AZTEC。

EYBlockchain是基于以太坊zk-snark零知識證明實現的隱私資產。它通過移植以太坊推薦的ZoKrates工具包進行線下的零知識證明的生成。算法需要用bn256曲線的add、multiply、pairing過程。一筆轉賬Gas消耗在2.7M左右。

Zether是一個以太坊上的匿名支付協議，以智能合約 Zether Smart Contract（ZSC）的形式部署在以太坊上，并且具有稱為 Zether 令牌（ZTH）的代幣，其可作為 ElGamal 公鑰的 Zether 賬戶之間傳輸的載體，并支持匿名的智能合約交互。算法需要用到bn256曲線的add、multiply算法。

PGC是改進版的Zether算法，PGC使用原版的Elgamal和原版的bulletproof零知識證明算法。PGC使用了bn256曲線的add、multiply算法，但是，如果secp256k1橢圓曲線的預編譯合約可以實現，那么PGC算法可以不使用bn系列的曲線。

AZTEC結合同態證明和range proof提供零知識證明，以在以太坊上提供隱私資產。AZTEC需要使用bn256曲線上的add、multiply、pairing操作，具體操作量為（3n+m-1）add+（2n+2m-2）multiply+1pairing（n和m分別是交易票據的數量）。

3、gas問題

EIP-196和EIP-197的提出，使得很多零知識證明的算法可以在以太坊上運行。但還是有一個問題，盡管把這些復雜的數學過程通過預編譯合約的方式來實現，它所消耗的gas還是十分巨大，不夸張地說，在某些場景下，轉賬一筆隱私資產所消耗的Gas可能比轉賬的金額還要高。以太坊每個block的最多gas消耗為8M，這就使得很多隱私的項目無法真正地落地。

為了降低預編譯合約的gas，AZTEC的員工提出了EIP-1108［5］的改進。

EIP-1108是對add、mul、pairing這三個預編譯合約所做的一個優化，通過對調用庫的底層算法進行優化，提高了代碼的運行效率，從而降低了gas。Golang版本的預編譯合約名也變成了bn256。bn256就是alt_bn128，只是更換了一個說法。256是指公式中p的長度，而128是指曲線的安全等級。這是一條曲線的兩個不同的屬性描述。所以EIP-1108并不是更換了曲線降低了gas，而是對實現的算法進行了優化。更新后的gas對比圖如下。EIP-1108目前處于draft的狀態，代碼中算法部分已經進行改進，但是gas的值還沒有進行更新。

若使用EIP-1108的改進方法，許多隱私資產的算法可以得到大大的優化。Zether一筆轉賬交易gas消耗可從7188000減少到1700000。PGC一筆轉賬交易gas消耗可從6563000減少到1100000。AZTEC則從121000n+41000m+219000降低到12200n+6200m+85930。

如果要部署預編譯合約，如何確定預編譯合約的Gas值是一個嚴峻的問題。預編譯合約gas的設置是和操作的計算量有關的，例如EIP-1108中介紹了Pairing gas的計算方法。它是根據ecrecover的效率和既定gas來決定的。一次ecrecover調用需要花費116ms，它的gas被設置成了3000，這樣得到了1ms運行花費25.86gas的事實。因為pairing計算花費的時間分為兩個部分，一個是基時間base_tim，可以理解為運算的啟動時間，還有一個是浮動時間per_pair_time，它和輸入的計算量有關。計算1個pairing需要耗費3037ms，計算10個pairing耗費14663ms。得出base_time和per_pair_time，乘以既定好的25.86gas，得出pairing過程的gas消耗。如此，則可以根據具體的環境做相關的benchmark以規范gas的設置。

Qtum與隱私資產

Qtum每個block的最多gas消耗為40M，每個transaction的最多gas消耗為20M，因此隱私資產在Qtum上運行基本不會受到gas的限制。但是使用EVM去運行一些計算量大的隱私算法是非常低效的。所以，未來將會把一些基礎的、通用的隱私算法做成預編譯合約的形式，讓隱私資產能夠更加高效地運行在Qtum上，也節省了合約的開發工作。

對于橢圓曲線而言，下一步可以考慮增加BLS和secp256k1橢圓曲線的預編譯合約。BLS的性能和安全性都優于bn256，且是pairing-friendly，所以可以用于代替bn256。并且如果要部署pairing預編譯合約，也可以找一個已經定好gas的預編譯合約進行參照，分別benchmark，進行類似的gas設定。secp256k1雖然不是pairing-friendly，但其性能更好，且通用性更強，廣泛用于區塊鏈的簽名、加密算法中。

對于零知識證明而言，未來可以考慮增加Bulletproof算法作為預編譯合約。Bulletproof是目前區塊鏈中廣泛使用的范圍證明算法，主要用于證明MimbleWimble中隱藏的交易金額是一個正數。Bulletproof已經在Grin和Beam項目中實現并穩定運行。Bulletproof的驗證過程計算量大，因此使用預編譯合約實現是更為合適的選擇。有了Bulletproof預編譯合約之后，MimbleWimble就能以合約的方式高效地運行于Qtum上。