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