全鏈遊戲101：預編譯合約

來源：Gametaverse

目前兩款最有潛力的全鏈遊戲引擎Curio和Argus都選擇通過定制化節點的預編譯合約來提高對遊戲狀態的查詢性能以及增加對特定全鏈遊戲的適配性，那麼究竟什麼是預編譯合約，以及為什麼預編譯合約可以提高性能呢？結下來請看這篇科普短文：全鏈遊戲101之預編譯合約。

**什麼是預編譯合約？ **

預編譯合約是EVM 中用於提供更複雜庫函數(通常用於加密、散列等複雜操作)的一種折衷方法，也可以理解為一種特殊的合約，這些函數不適合編寫操作碼。它們適用於簡單但經常調用的合約，或邏輯上固定但計算量很大的合約。預編譯合約是在使用節點客戶端代碼實現的，因為它們不需要EVM，所以運行速度很快。與使用直接在EVM 中運行的函數相比，它對開發人員來說成本也更低。

如下代碼可以看到， evm.go的合約中run函數有兩個分支：第一個分支是通過預編譯索引來實例化索引參數從而指定預編譯合約，第二個分支是如果它不是預編譯合約那evm將會被調用。

// run 運行給定的合約並負責運行預編譯，並回退到字節碼解釋器。 func run(evm *EVM, 合約 *合約, 輸入 []byte, readOnly bool) ([]byte, error) { if Contract.CodeAddr != nil { 預編譯 := PrecompiledContractsHomestead if evm.ChainConfig().IsByzantium(evm.BlockNumber) { 預編譯 = PrecompiledContractsByzantium } if p := 預編譯[*contract.CodeAddr]; p != nil { 返回 RunPrecompiledContract(p, 輸入, 合約) } } 對於_，解釋器：=範圍evm.interpreters { ifterpreter.CanRun(contract.Code) { if evm.interpreter != 解釋器 { // 確保解釋器指針被設置回來 // 返回時返回其當前值。 defer func(i 解釋器) { evm.解釋器 = i }(evm.解釋器) evm.interpreter = 解釋器 } 返回解釋器.Run（合同，輸入，只讀） } } 返回 nil，ErrNoCompatibleInterpreter }

用圖形來表示的話，具體的邏輯如下圖：

那麼預編譯合約的瓶頸在哪裡？

以太坊目前有八個預編譯的合約：

1. ECRecover - 通過簽名恢復對應地址
2. SHA256 - 計算SHA256哈希
3. RIPEMD160 - 計算RIPEMD160哈希
4. Identity - 返回輸入數據的原值
5. ModExp - 進行模數指數運算
6. ECAdd - 橢圓曲線點加法
7. ECMul - 橢圓曲線點乘法
8. ECPairing - 配對運算,驗證橢圓曲線點

可以看到第一到第四個預編譯合約提供的基礎的簽名，哈希等加密功能，第五個到第八個提供了橢圓曲線運算，這些和zk-snark相關。

那麼問題來了，為什麼以太坊預編譯只支持了八個預編譯合約，預編譯合約不是降低了gas消耗嗎？而且為什麼不直接把ECS（全鏈遊戲的框架）植入以太坊預編譯合約中呢？

其實主要是以下三個原因：

1.過度依賴預編譯合約會降低整個平台的去中心化程度：

首先，預編譯合約的代碼需要集成在客戶端節點代碼中,增加了客戶端的複雜性。第二，驗證節點可能因為安全原因可能會過濾掉預編譯合約的計算，所以大部分預編譯合約的請求是由全節點完成的，目前全球的以太坊全節點的數量只有4000-6000個，而且驗證節點有50萬個，確實比起非預編譯合約要中心化很多。

2.預編譯合約的新增和修改需要硬分叉升級,不易靈活演進。

預編譯合約的支持需要進行EIP流程，舉個例子：EIP-196增加了在alt_bn128曲線上的ECADD（）和ECMUL（）兩個預編譯合約。 EIP-197增加了在alt_bn128曲線上的配對Pairing函數。基本都是為了讓隱私在以太坊上可用進行支持，而且整個EIP的流程是漫長和考究的，等待EIP通過也不是一個現實的問題。

3.預編譯合約之間難以進行交互和組合,擴展性差。

這點就不多做解釋了，很直觀。

預編譯合約在全鏈遊戲扮演什麼角色？

預編譯合約跳過EVM直接通過節點執行,可以提昇運算效率,但同時降低了全鏈的去中心化程度。將高頻使用的遊戲核心邏輯置於預編譯中,可以優化該類游戲的性能。不同的遊戲類型,其關鍵邏輯也不盡相同。因此,針對某一類游戲的專用鏈上,其預編譯設計可以高度優化該類型遊戲的需求。在遊戲迭代過程中,最具效率的預編譯合約組合也會逐步優化出來。