背景知識(shí)1、智能合約以太坊中存在外部賬戶和合約賬戶兩種，外部賬戶(Externally Owned Account, EOA)是被私鑰控制且沒(méi)有任何代碼與之關(guān)聯(lián)的
背景知識(shí)
1、智能合約
以太坊中存在外部賬戶和合約賬戶兩種，外部賬戶(Externally Owned Account, EOA)是被私鑰控制且沒(méi)有任何代碼與之關(guān)聯(lián)的賬戶。而合約賬戶(Contract Account, CA)是給智能合約分配的賬戶，被合約代碼控制且有代碼與之關(guān)聯(lián)。外部賬戶可以發(fā)送交易，這個(gè)交易可以是轉(zhuǎn)賬交易，也可以是和智能合約有關(guān)的交易，用于創(chuàng)建智能合約或者觸發(fā)智能合約。
以太坊的每筆交易Transaction會(huì)被轉(zhuǎn)換成一個(gè)Message對(duì)象，傳入EVM中執(zhí)行，隨后EVM將Message對(duì)象轉(zhuǎn)換成Contract對(duì)象。如果是一筆普通轉(zhuǎn)賬交易，那么直接修改 StateDB 中對(duì)應(yīng)的賬戶余額即可。如果是智能合約的創(chuàng)建或者調(diào)用，則通過(guò) EVM 中的解釋器加載和執(zhí)行字節(jié)碼，執(zhí)行過(guò)程中可能會(huì)查詢或者修改 StateDB。從圖中可以看出，Contract對(duì)象會(huì)根據(jù)合約的地址，從數(shù)據(jù)庫(kù)中加載相應(yīng)的合約代碼，然后送入解釋器中進(jìn)行執(zhí)行。
EVM解釋器是一個(gè)基于棧式的機(jī)器，它有自己的PC、堆棧、內(nèi)存和Gas池。一份合約代碼會(huì)被解釋為一條條OPCode，然后執(zhí)行。在執(zhí)行OPCode之前會(huì)檢查該命令所需要的Gas和當(dāng)前所剩Gas，如果Gas不足，則會(huì)返回ErrOutOfGas錯(cuò)誤。
因?yàn)镋VM是基于棧的虛擬機(jī)，他沒(méi)有寄存器之類的中間存儲(chǔ)，所有的操作都要通過(guò)一個(gè)棧來(lái)進(jìn)行維護(hù)，所以它的運(yùn)行效率比較低，完成一個(gè)復(fù)雜操作可能需要較長(zhǎng)的時(shí)間。更復(fù)雜的操作可能無(wú)法在有效時(shí)間執(zhí)行完畢。具體可參見(jiàn)。
2、隱私資產(chǎn)
區(qū)塊鏈?zhǔn)枪_(kāi)的分布式交易賬本，鏈上的數(shù)據(jù)都是公開(kāi)可見(jiàn)的，雖然一筆交易的發(fā)送方和接收方無(wú)法和現(xiàn)實(shí)生活中買賣雙方進(jìn)行關(guān)聯(lián)，但是可以通過(guò)對(duì)鏈上的數(shù)據(jù)進(jìn)行地址聚簇分析，從而得出一些地址和身份的關(guān)聯(lián)信息。且交易的金額在鏈上也是公開(kāi)的，可見(jiàn)盡管數(shù)據(jù)的公開(kāi)透明保證了賬本真實(shí)和不可篡改的特點(diǎn)，但是這也使得很多需要隱私的場(chǎng)景無(wú)法在區(qū)塊鏈上進(jìn)行運(yùn)用。
在此背景下，隱私資產(chǎn)的概念被提出。通過(guò)使用密碼學(xué)等技術(shù)手段將交易的發(fā)送方、接收方和交易金額進(jìn)行隱藏，而礦工(驗(yàn)證交易者)可以在不需要知道具體數(shù)據(jù)的情況對(duì)一筆交易的合法性進(jìn)行驗(yàn)證。常用的隱私資產(chǎn)實(shí)現(xiàn)的方法有Mimble-Wimble、ZK-SNARK等。
由于合約模式的廣泛使用，一些項(xiàng)目方想到可以通過(guò)使用智能合約來(lái)實(shí)現(xiàn)隱私交易，如Nightfall、Zether、AZTEC等，通過(guò)部署和隱私交易有關(guān)的智能合約來(lái)達(dá)到在鏈上發(fā)行隱私資產(chǎn)的目的。
預(yù)編譯合約
1、預(yù)編譯合約的概念
因?yàn)镋VM是基于棧的虛擬機(jī)，它根據(jù)操作的內(nèi)容來(lái)計(jì)算gas，所以如果牽涉到十分復(fù)雜的計(jì)算，把運(yùn)算過(guò)程放在EVM中執(zhí)行就可能十分地低效，同時(shí)消耗非常多的gas。比如在zk-snark中，需要進(jìn)行橢圓曲線的加減和配對(duì)運(yùn)算，這個(gè)過(guò)程十分復(fù)雜，放在EVM中執(zhí)行是不現(xiàn)實(shí)的。這就是以太坊提出預(yù)編譯合約的初衷。
預(yù)編譯合約是EVM中為了提供一些不適合寫成opcode的較為復(fù)雜的庫(kù)函數(shù)(多用于加密、哈希等復(fù)雜運(yùn)算)而采用的一種折中方案，適用于合約邏輯簡(jiǎn)單但調(diào)用頻繁，或者合約邏輯固定而計(jì)算量大的場(chǎng)景。預(yù)編譯合約通常是在客戶端用客戶端代碼實(shí)現(xiàn)，由于不需要使用EVM，所以運(yùn)行速度快。對(duì)于開(kāi)發(fā)者來(lái)說(shuō)比直接使用運(yùn)行在EVM上的函數(shù)消耗更低。
現(xiàn)在以太坊已經(jīng)實(shí)現(xiàn)的預(yù)編譯合約如下：
從代碼層面來(lái)看，所謂的地址其實(shí)就是合約數(shù)組的下標(biāo)，一個(gè)下標(biāo)標(biāo)識(shí)了一個(gè)預(yù)編譯合約。其中和隱私算法有關(guān)的三個(gè)預(yù)編譯合約是bn256Add()、bn256ScalarMul()、bn256Pairing()。
2、預(yù)編譯合約的實(shí)現(xiàn)
在evm.go文件中，封裝著evm的操作邏輯，里面有4個(gè)函數(shù)用于調(diào)用智能合約，Call()、CallCode()、DelegateCall()、StaticCall()。這四個(gè)函數(shù)做的工作都是生成一個(gè)contract對(duì)象，但是具體的細(xì)節(jié)如參數(shù)等會(huì)有一些差異。contract實(shí)例化之后，都是調(diào)用evm.go中的run函數(shù)來(lái)運(yùn)行智能合約。該函數(shù)對(duì)預(yù)編譯合約和非預(yù)編譯合約調(diào)用兩種情況均有考慮。
下面的代碼中，第一個(gè)分支是當(dāng)該合約是一個(gè)預(yù)編譯合約的時(shí)候，通過(guò)指定precompiles這個(gè)數(shù)組變量的下標(biāo)來(lái)指定某一個(gè)預(yù)編譯合約，從而實(shí)例化p參數(shù)。此處數(shù)組的下標(biāo)其實(shí)就對(duì)應(yīng)了預(yù)編譯合約數(shù)組聲明時(shí)地址的概念。之后調(diào)用RunPrecompiledContract函數(shù)來(lái)執(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)行返回。可以很明顯地看到這部分操作是在客戶端語(yǔ)言的執(zhí)行過(guò)程中進(jìn)行計(jì)算的。具體可參見(jiàn)[2]。
go-ethereum/core/vm/contracts.go
go-ethereum/core/vm/contracts.go
3、預(yù)編譯合約的使用
在智能合約代碼中，預(yù)編譯合約也像普通的合約一樣，可以直接在合約文件中進(jìn)行調(diào)用，但調(diào)用方式有一些不同。通過(guò)在.sol文件中注明一個(gè)assembly代碼塊進(jìn)行預(yù)編譯合約的調(diào)用。調(diào)用規(guī)范和調(diào)用的參數(shù)如下所示。
一個(gè)實(shí)現(xiàn)橢圓曲線加法的實(shí)例如下
預(yù)編譯合約在隱私資產(chǎn)中的應(yīng)用
1、橢圓曲線的預(yù)編譯合約
以太坊現(xiàn)在處理隱私的解決方案是使用zk-snark[6][8]，但是zk-snark是一個(gè)及其復(fù)雜的數(shù)學(xué)過(guò)程，里面牽涉到很多橢圓曲線的計(jì)算。經(jīng)過(guò)前面的分析，這個(gè)過(guò)程放在evm里面執(zhí)行是十分不現(xiàn)實(shí)的，所以為了支持zk-snark的相關(guān)運(yùn)算，以太坊分別在EIP196[3]和EIP197[4]里增加了三個(gè)與zk-snark運(yùn)算有關(guān)的預(yù)編譯合約，可以供開(kāi)發(fā)者調(diào)用。
EIP-196增加了在alt_bn128曲線上的ECADD()和ECMUL()兩個(gè)預(yù)編譯合約，其中ECADD()消耗500gas，ECMUL()消耗40000gas。
EIP-197增加了在alt_bn128曲線上的配對(duì)Pairing函數(shù)，消耗gas為80000*k+100000(k和點(diǎn)對(duì)個(gè)數(shù)有關(guān))。
橢圓曲線上的加和乘比較好理解，pairing的出現(xiàn)是因?yàn)閦k-snark中有KCA(Knowledge of Coefficient Test and Assumption)認(rèn)證過(guò)程[6]，需要用到雙線性映射來(lái)進(jìn)行證明，具體可參見(jiàn)V神medium[7]。Pairing就是證明過(guò)程中會(huì)用到的公式。Pairing函數(shù)的輸入是一個(gè)不定長(zhǎng)的列表，因?yàn)椴煌膠k-snark算法可能數(shù)據(jù)量是不同的，并且pairing函數(shù)所消耗的gas也與輸入的點(diǎn)對(duì)個(gè)數(shù)有關(guān)。
現(xiàn)在許多利用預(yù)編譯合約實(shí)現(xiàn)隱私的算法都使用到了pairing過(guò)程，例如EYBlockchain、AZTEC等。pairing是ZK-snark所必須要求的一個(gè)步驟，耗費(fèi)的gas巨大，當(dāng)然官方也在做優(yōu)化。實(shí)現(xiàn)pairing的過(guò)程一般要在pairing-friendly曲線上來(lái)進(jìn)行，這是一類具有特殊屬性的曲線，主要表現(xiàn)在計(jì)算pairing速度很快。所以如果要用pairing這個(gè)過(guò)程，那么常用的secp256k1這樣的曲線顯然是不適合的，就需要增加對(duì)pairing-friendly曲線的支持。
現(xiàn)在主流的pairing-friendly曲線有Barreto-Naehrig(BN)系列和Barreto-Lynn-Scott(BLS)系列[9]，以太坊使用的就是BN系列，ZCASH使用的是BLS系列，以太坊后續(xù)也會(huì)加上對(duì)BLS曲線的支持。BLS的曲線綜合表現(xiàn)會(huì)好很多，計(jì)算量也相對(duì)較小。但是不管怎么樣，選擇曲線都有安全和效率之間進(jìn)行平衡的一個(gè)取舍。
值得一提的是，如果不需要用到pairing過(guò)程，也就不需要pairing-friendly曲線。另外一種方案是增加對(duì)secp256k1曲線的預(yù)編譯合約的支持。例如PGC團(tuán)隊(duì)雖然使用了bn256ADD和bn256MUL兩個(gè)預(yù)編譯合約，即使用了bn系列的曲線，但是他們的算法是不需要pairing的，如果換成對(duì)secp256k1的預(yù)編譯合約支持會(huì)對(duì)算法效率有提高。
針對(duì)于C++版本實(shí)現(xiàn)的問(wèn)題，現(xiàn)在主要有兩個(gè)外部庫(kù)對(duì)這些操作進(jìn)行了封裝和實(shí)現(xiàn)。首先是Libff，這也是現(xiàn)在以太坊正在 使用的庫(kù)，源碼中LibSnark.cpp調(diào)用了libff庫(kù)的相關(guān)計(jì)算函數(shù)。還有一個(gè)是MCL庫(kù)，這是EIP-1108所推薦的庫(kù)。
2、隱私資產(chǎn)項(xiàng)目
現(xiàn)在在業(yè)內(nèi)比較流行的四個(gè)隱私解決方案是EYBlockchain、PGC、Zether、AZTEC。
EYBlockchain是基于以太坊zk-snark零知識(shí)證明實(shí)現(xiàn)的隱私資產(chǎn)。它通過(guò)移植以太坊推薦的ZoKrates工具包進(jìn)行線下的零知識(shí)證明的生成。算法需要用bn256曲線的add、multiply、pairing過(guò)程。一筆轉(zhuǎn)賬Gas消耗在2.7M左右。
Zether是一個(gè)以太坊上的匿名支付協(xié)議，以智能合約 Zether Smart Contract(ZSC)的形式部署在以太坊上，并且具有稱為 Zether 令牌(ZTH)的代幣，其可作為 ElGamal 公鑰的 Zether 賬戶之間傳輸?shù)妮d體，并支持匿名的智能合約交互。算法需要用到bn256曲線的add、multiply算法。
PGC是改進(jìn)版的Zether算法，PGC使用原版的Elgamal和原版的bulletproof零知識(shí)證明算法。PGC使用了bn256曲線的add、multiply算法，但是，如果secp256k1橢圓曲線的預(yù)編譯合約可以實(shí)現(xiàn)，那么PGC算法可以不使用bn系列的曲線。
AZTEC結(jié)合同態(tài)證明和range proof提供零知識(shí)證明，以在以太坊上提供隱私資產(chǎn)。AZTEC需要使用bn256曲線上的add、multiply、pairing操作，具體操作量為(3n+m-1)add+(2n+2m-2)multiply+1pairing(n和m分別是交易票據(jù)的數(shù)量)。
3、gas問(wèn)題
EIP-196和EIP-197的提出，使得很多零知識(shí)證明的算法可以在以太坊上運(yùn)行。但還是有一個(gè)問(wèn)題，盡管把這些復(fù)雜的數(shù)學(xué)過(guò)程通過(guò)預(yù)編譯合約的方式來(lái)實(shí)現(xiàn)，它所消耗的gas還是十分巨大，不夸張地說(shuō)，在某些場(chǎng)景下，轉(zhuǎn)賬一筆隱私資產(chǎn)所消耗的Gas可能比轉(zhuǎn)賬的金額還要高。以太坊每個(gè)block的最多gas消耗為8M，這就使得很多隱私的項(xiàng)目無(wú)法真正地落地。
為了降低預(yù)編譯合約的gas，AZTEC的員工提出了EIP-1108[5]的改進(jìn)。
EIP-1108是對(duì)add、mul、pairing這三個(gè)預(yù)編譯合約所做的一個(gè)優(yōu)化，通過(guò)對(duì)調(diào)用庫(kù)的底層算法進(jìn)行優(yōu)化，提高了代碼的運(yùn)行效率，從而降低了gas。Golang版本的預(yù)編譯合約名也變成了bn256。bn256就是alt_bn128，只是更換了一個(gè)說(shuō)法。
256是指公式中p的長(zhǎng)度，而128是指曲線的安全等級(jí)。這是一條曲線的兩個(gè)不同的屬性描述。所以EIP-1108并不是更換了曲線降低了gas，而是對(duì)實(shí)現(xiàn)的算法進(jìn)行了優(yōu)化。更新后的gas對(duì)比圖如下。EIP-1108目前處于draft的狀態(tài)，代碼中算法部分已經(jīng)進(jìn)行改進(jìn)，但是gas的值還沒(méi)有進(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值是一個(gè)嚴(yán)峻的問(wèn)題。預(yù)編譯合約gas的設(shè)置是和操作的計(jì)算量有關(guān)的，例如EIP-1108中介紹了Pairing gas的計(jì)算方法。它是根據(jù)ecrecover的效率和既定gas來(lái)決定的。一次ecrecover調(diào)用需要花費(fèi)116ms，它的gas被設(shè)置成了3000，這樣得到了1ms運(yùn)行花費(fèi)25.86gas的事實(shí)。
因?yàn)閜airing計(jì)算花費(fèi)的時(shí)間分為兩個(gè)部分，一個(gè)是基時(shí)間base_tim，可以理解為運(yùn)算的啟動(dòng)時(shí)間，還有一個(gè)是浮動(dòng)時(shí)間per_pair_time，它和輸入的計(jì)算量有關(guān)。計(jì)算1個(gè)pairing需要耗費(fèi)3037ms，計(jì)算10個(gè)pairing耗費(fèi)14663ms。得出base_time和per_pair_time，乘以既定好的25.86gas，得出pairing過(guò)程的gas消耗。如此，則可以根據(jù)具體的環(huán)境做相關(guān)的benchmark以規(guī)范gas的設(shè)置。
Qtum與隱私資產(chǎn)
Qtum每個(gè)block的最多gas消耗為40M，每個(gè)transaction的最多gas消耗為20M，因此隱私資產(chǎn)在Qtum上運(yùn)行基本不會(huì)受到gas的限制。但是使用EVM去運(yùn)行一些計(jì)算量大的隱私算法是非常低效的。所以，未來(lái)將會(huì)把一些基礎(chǔ)的、通用的隱私算法做成預(yù)編譯合約的形式，讓隱私資產(chǎn)能夠更加高效地運(yùn)行在Qtum上，也節(jié)省了合約的開(kāi)發(fā)工作。
對(duì)于橢圓曲線而言，下一步可以考慮增加BLS和secp256k1橢圓曲線的預(yù)編譯合約。BLS的性能和安全性都優(yōu)于bn256，且是pairing-friendly，所以可以用于代替bn256。并且如果要部署pairing預(yù)編譯合約，也可以找一個(gè)已經(jīng)定好gas的預(yù)編譯合約進(jìn)行參照，分別benchmark，進(jìn)行類似的gas設(shè)定。secp256k1雖然不是pairing-friendly，但其性能更好，且通用性更強(qiáng)，廣泛用于區(qū)塊鏈的簽名、加密算法中。
對(duì)于零知識(shí)證明而言，未來(lái)可以考慮增加Bulletproof算法作為預(yù)編譯合約。Bulletproof是目前區(qū)塊鏈中廣泛使用的范圍證明算法，主要用于證明MimbleWimble中隱藏的交易金額是一個(gè)正數(shù)。Bulletproof已經(jīng)在Grin和Beam項(xiàng)目中實(shí)現(xiàn)并穩(wěn)定運(yùn)行。Bulletproof的驗(yàn)證過(guò)程計(jì)算量大，因此使用預(yù)編譯合約實(shí)現(xiàn)是更為合適的選擇。有了Bulletproof預(yù)編譯合約之后，MimbleWimble就能以合約的方式高效地運(yùn)行于Qtum上。（Qtum研究院）
