如何使用以太坊實(shí)現(xiàn)預(yù)編譯合約

背景知識

1、智能合約

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

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

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

2、隱私資產(chǎn)

區(qū)塊鏈?zhǔn)枪_的分布式交易賬本，鏈上的數(shù)據(jù)都是公開可見的，雖然一筆交易的發(fā)送方和接收方無法和現(xiàn)實(shí)生活中買賣雙方進(jìn)行關(guān)聯(lián)，但是可以通過對鏈上的數(shù)據(jù)進(jìn)行地址聚簇分析，從而得出一些地址和身份的關(guān)聯(lián)信息。且交易的金額在鏈上也是公開的，可見盡管數(shù)據(jù)的公開透明保證了賬本真實(shí)和不可篡改的特點(diǎn)，但是這也使得很多需要隱私的場景無法在區(qū)塊鏈上進(jìn)行運(yùn)用。

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

由于合約模式的廣泛使用，一些項(xiàng)目方想到可以通過使用智能合約來實(shí)現(xiàn)隱私交易，如Nightfall、Zether、AZTEC等，通過部署和隱私交易有關(guān)的智能合約來達(dá)到在鏈上發(fā)行隱私資產(chǎn)的目的。

預(yù)編譯合約

1、預(yù)編譯合約的概念

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

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

現(xiàn)在以太坊已經(jīng)實(shí)現(xiàn)的預(yù)編譯合約如下：

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

2、預(yù)編譯合約的實(shí)現(xiàn)

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

go-ethereum/core/vm/evm.go

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

go-ethereum/core/vm/contracts.go

go-ethereum/core/vm/contracts.go

3、預(yù)編譯合約的使用

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

一個實(shí)現(xiàn)橢圓曲線加法的實(shí)例如下

預(yù)編譯合約在隱私資產(chǎn)中的應(yīng)用

1、橢圓曲線的預(yù)編譯合約

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

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

EIP-197增加了在alt_bn128曲線上的配對Pairing函數(shù)，消耗gas為80000*k+100000（k和點(diǎn)對個數(shù)有關(guān)）。

橢圓曲線上的加和乘比較好理解，pairing的出現(xiàn)是因?yàn)閦k-snark中有KCA（Knowledge of Coefficient Test and AssumpTIon）認(rèn)證過程［6］，需要用到雙線性映射來進(jìn)行證明，具體可參見V神medium［7］。Pairing就是證明過程中會用到的公式。Pairing函數(shù)的輸入是一個不定長的列表，因?yàn)椴煌膠k-snark算法可能數(shù)據(jù)量是不同的，并且pairing函數(shù)所消耗的gas也與輸入的點(diǎn)對個數(shù)有關(guān)。

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

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

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

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

2、隱私資產(chǎn)項(xiàng)目

現(xiàn)在在業(yè)內(nèi)比較流行的四個隱私解決方案是EYBlockchain、PGC、Zether、AZTEC。

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

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

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

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

3、gas問題

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

為了降低預(yù)編譯合約的gas，AZTEC的員工提出了EIP-1108［5］的改進(jìn)。

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

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

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

Qtum與隱私資產(chǎn)

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

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

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