Zypher Network 技術白皮書系列解讀（四）：深度解析 Zytron Kit

WEEX 唯客博客， 3.3 Zytron Kit 3.3.1 Sovereign Rollup for Data  3.3.1.1 Sequencer Sequecner是Layer2系統中決定交易順序的重要組件，是整個系統入口的第一個組件。Sequencer負責將內存池中的交易排序，並打包形成Layer2的區塊。並將Layer2的區塊按照順序打包為Batch。後續的交易執行，交易處理等功能，都是基於Sequencer產生的區塊順序執行。 用戶傳輸到Zytron上的交易，會優先被Sequencer進行排序，確定一個全局順序。這個順序的確定由去中心化排序器決定。去中心化排序器只會執行交易排序以及基礎的交易簽名驗證工作，不會執行具體的交易，更不會運行智能合約。這也就意味著Sequencer無法打包產生完整的交易receipt，僅僅只是將交易的排序組成一組Batch交由Zytron的交易分片服務完成。 具體的打包流程如下： Sequencer的各個節點使用不會進行P2P的內存池，發送給這個節點的交易只會在本地進行打包。Sequecer節點每隔固定時間打包一次交易，形成一個交易區塊。 該交易區塊內的交易會被構造為一顆Merkle樹。其中Merkle的根在Sequener的P2P網路中廣播。這個廣播過程只需要廣播Merkle根，而無需要廣播完整的交易體。通過聚合交易塊中的簽名進行驗證，進一步減少了數據量。 Sequencer打包出來的交易區塊具體數據將會提交給外部DA。為了防止 DA 中的確認周期過長而導致延遲，Sequencer將數據臨時提交至「弱」DA上。 Sequencer產生的交易區塊會交由Sequcner的PBFT共識進行進一步打包為Batch。這個Batch會被最終遞交給後續的服務分片中進行具體的交易合約執行。 3.3.1.2 External DA Zytron中使用了兩類DA，分別為」強」DA與「弱「DA。所謂的」弱」DA用於Sequencer打包交易區塊時記錄交易區塊的數據。這種DA不要求共識支持，僅僅為了快速的向Sequencer網路中的節點傳遞具體的交易區塊信息。此類DA可以直接使用可以公開訪問的Server，s3等中心化服務。這個「弱」DA主要支持Zytron的「pipeline」式交易執行優化策略。 「強」DA中記錄的則是Sequencer打包后的Batch數據，這個數據成型后是要作為最終合約執行的輸入。因此此交易的數據必須放置於可訪問性強的系統中。此類數據強調數據的可訪問性，往往會導致數據提交周期變長。因此強DA中的數據更多用於在固定時間點前對鏈上數據執行結果的驗證。 強DA和弱DA的區別如下:   DA與Sequencer交互流程中，Sequencer間通過P2P採用主動推送的模式進行數據廣播。這種數據廣播主要為了快速的在共識前實現數據的廣播，降低交易處理的延時。而具體的交易數據則需要Sequcner主動從對應的節點提取。 3.3.1.3 Sequencer Pending State 在遊戲過程中，經常會有大量的交易頻繁地發送到網路中。由於遊戲低延時性的要求，要求等待交易的執行結果最終被鏈確認后再返回用戶會導致用戶遊戲體驗的急劇下降。因此用戶將交易發送給Sequencer的時候，Sequencer會在本地維護一個Pending State，用戶可以基於自己所連接的Sequeuncer交易節點，不斷地拉取Pending狀態，在交易最終被確認前提前發出新的交易。Sequencer中記錄的Pending State會不斷地與鏈上的最終狀態同步，用於修正自己的Pending State。 3.3.2 ZK Rollup for Assets 資產不同於數據，資產有十分明顯的價值屬性，而且需要流動，因此，對於 layer3 中的資產需要進行單獨的處理，將資產的安全性依賴於更加安全的 layer1/layer2 中，對此，我們設計了一套基於 zk rollup 的 assets 管理解決方案，用於 zytron kit 所發行的 layer3。 使用 zk-Rollups 進行資產管理： L3 資產交易： Merkle 樹存儲：我們將 L3 中產生的資產交易，以及與 L1/L2 source chain 產生的 deposit 和 withdraw 交易，均存放於一顆 Merkle 樹中，該 Merkle 樹 的每一個分支都會有 3 個 leaf，每一個 leaf 代表一個 output。 UTXO 模型：通過採取 UTXO 模型的傳輸演算法，我們促進了所有交易有效性檢查的 zk 聚合，從而可以在 L1/L2 上立即進行驗證。無需像 op一樣有 7 天的挑戰期。 交易類型和流程： Deposit： 存在於source chain上，因此無需將其簽名寫入電路，因為它是完全公開的public inputs。 Transfer：涉及提交inputs和outputs的交易的有效性，並在電路中嵌入用戶簽名來驗證交易。L3 傳輸交易採用field友好的簽名演算法，以實現電路內的高效證明。 Withdraw：與 Transfer 演算法同樣處理，只是該 output 的接受者會被指定成 source chain 對應的賬號格式，可以參與 Merkle 樹的證明，而且無法再被任何 input 所使用。 電路驅動的交易有效性： Leaf 證明和 Merkle Root 更新：Leaf 的變化會導致 Merkle Root 的更新。 這些更改的有效性在電路中得到了證明，減少了更新 Merkle Root 所需的鏈上計算。 提交到 source chain 上的 public inputs：包括 deposit 以及對應的 output， transfer 所關聯的 inputs 和 outputs， withdraw 所產生的 inputs 和 特殊 outputs，以及最終的 Merkle tree root，所有資產交易的有效性都通過 ZKP 進行證明。 UTXO 結構： 資產類型和金額：兩者都是u256類型，能夠處理ERC20代幣類型和ERC721 NFT類型。 Source Chain 上的合約映射：只需要在 source chain 的合約中做好對應的映射關係，就可以實現將資產橋接到L3，將資產的安全假設基於 source chain 上，減少對L3安全性的依賴。 實施計劃包括創建圖表，直觀地解釋處理為 ZK inputs 和 outputs 的 UTXO 交易、從舊 Merkle 根到新 Merkle 根的過渡，以及將資產類型和金額與代幣和 NFT 類型相關聯的映射表，以及映射關係 。 這種結構化方法利用底層區塊鏈層的安全功能，增強了L3資產管理的理解和透明度。 3.3.3 服務分片 Zytron設計目的在於實現低延時的鏈上遊戲服務，因此為了實現這個目的，Zytron上運行的合約會通過將鏈節點的數據服務分片的方式執行。 3.3.3.1 基於 Kademlia 演算法的節點數據分片 Kademlia是一種分散式哈希表演算法，使用節點ID的異或運算測量網路中的節點距離。利用這個距離的規定，可以以此為基準進行節點分片計算，網路中節點發現等功能。原本Kademlia設計用於P2P網路的數據存儲和節點發現方案。而在Zytron中，利用kademlia演算法的節點規則，可以僅通過計算，就完成對服務分片的計算，降低系統中網路請求的數量。 Zytron 會將具體執行合約驗證的節點通過P2P網路連接起來。節點間的定址利用結構化Kademlia演算法完成。同時，網路中合約的執行過程也會按照Kademlia的節點距離進行分片，將指定合約的的執行按照Kademlia的距離規則分散在整個Zytron網路的執行節點中執行。要成為 Zytron 中的執行節點，需要完成如下的流程： Zytron中每一個執行節點均可以接受來自Sequencer發送過來的交易區塊，並且會從Zytron所依賴的上層區塊鏈讀取經過共識過的Batch，以及從DA中讀取具體的Batch數據。 節點利用自己的的私鑰生成一個160位的節點id。 每一個節點需要在上層區塊鏈中進行註冊，註冊後上層區塊鏈的合約會記錄當前節點的ID。 節點加入網路後用過P2P協議發起一次對自己的查詢操作，使得自己能夠被更新到相關鄰居的路由表中。 向周邊節點發起狀態數據同步請求。 同步完成後，向上層區塊鏈註冊同步成功的結果（自己所記錄的數據狀態的Merkle Root）。 當節點成為執行節點之後，節點會向周圍數據發起狀態數據同步請求，這個數據同步請求會將周邊節點中，賬戶地址距離自己節點ID最近的相關數據，餘額，nonce等數據同步至自己的存儲中。 3.3.3.2 地址狀態組 Zytron 中的執行節點不會記錄全局狀態，每個執行節點只會記錄距離自己最近的地址相關的存儲信息。而為了保證節點離線后，執行節點依舊能夠正常驗證交易。執行節點每次從與其最近的地址同步存儲數據時，便會加入或者創建一個地址狀態組。每一個地址狀態組中存在8個成員，他們使用 BFT 演算法在本地更新地址的狀態。 地址狀態組初始化演算法: 當一筆交易被發送到 Zytron 節點中執行時，地址狀態組會基於交易記錄的Address Space將多個地址狀態組聯合起來，執行智能合約，並更新這個交易中的狀態，用以實現對交易狀態的更新。此外，由於 Zytron 具有Address Space Access List 和 Key Space Access List等功能，因此可以在合約執行之前完成地址狀態組的合併，而無需等待合約執行再進行合併。 當某一個節點離線后，相關的地址節點組會將該節點剔除，並向上層區塊鏈記錄此退出行為。 3.3.3.3 交易 Space Access List 欄位 由於 Zytron 中節點的數據被分片存儲，因此執行節點中不太存在完整的全局狀態。即便交易執行過程中地址狀態組會聯合執行交易，也很難動態的不斷增加連接，執行交易等操作。因此為了保證數據能夠正常的分片處理計算，交易發送至鏈上時，需要附加這個交易會更新的State Change信息，這個信息被稱為Space Access Limit。這些信息包括交易會變更的Balance， Nonce，Storage信息。節點收到交易后，會按照Space Access Limit 在節點本地構造滿足合約執行條件的狀態放置於交易「to」地址所在的地址狀態組節點中。當節點執行過程中發現訪問的數據超過了Space Access List 中記錄的數據範圍，或者與其中的狀態變化有差異，則會判定交易失敗。 而每一個 Batch 執行結束后，地址狀態組都會向上層鏈提交一次 State Root，以及相關的 zkproof 或 Fraud Proof。 3.3.3.4 Key Space 估算 對於大部分 EVM 類或者全狀態類合約執行引擎，默認是不存在Space Access List欄位，在智能合約執行結束之前，沒有任何人可以知道交易的執行狀態。因此為了輔助客戶端能夠正常的標註出此欄位，Zytron 提供了Space Access Limit估算功能。此功能會將發送的交易，基於指定的狀態執行智能合約，並基於在合約執行過程中訪問的數據和產生的數據構造Space Access Limit。 3.3.4 定製網路 目前區塊鏈的底層 P2P 網路，很多項目會基於 libp2p或者自定義的庫，這些庫都是基於區塊鏈而產生，最重要的特性是將區塊和交易進行快速傳播，因此特別注重 broadcast 演算法，比如 gossip演算法。用於保證消息能夠在較短的時間內廣播到全網。但是遊戲的場景是有限的節點之間的消息傳輸，甚至只涉及到兩個節點，而且要求這個連接是穩定高效的，不會被隨意斷開，或者在斷開后能夠保證迅速恢復。而區塊鏈的 P2P 庫並不具備這些特點。因此，我們針對 P2P 網路庫進行了定製化開發。 首先就是針對網路傳輸協議，在高頻操作的遊戲中，我們必須要保證網路的延遲極低，假設是 60 幀的遊戲，那麼每秒更新 60 次，就要求延遲必須低於 16ms 才可以無掉幀和避免卡頓。對此，我們不僅需要對客戶端的性能進行優化，也需要對佔大部分時間的網路傳輸進行優化，傳統 P2P 網路，一般採取 TCP的傳輸協議，但是 TCP包含 可靠重傳，並且具有擁塞機制，如果網路中流量很大，就會導致 TCP 的傳輸時間被延長，無法滿足遊戲的要求，因此我們修改了一個基於 KCP傳輸協議的 p2p 網路庫，KCP 基於 UDP實現。KCP是一個快速可靠協議，能以比 TCP 浪費10%-20%的帶寬的代價，換取平均延遲降低 30%-40%，且最大延遲降低三倍的傳輸效果。KCP是純演算法實現，並不負責底層協議（如UDP）的收發，需要使用者自己定義下層數據的發送方式，以 callback的方式提供給 KCP。甚至時鐘都需要外部傳遞進來，內部不會有任何一次系統調用。 為了滿足節點連接的穩定性，我們針對 P2P 核心的定址演算法進行了優化，採取基於雙重 DHT 下的穩定 P2P 網路結構，一層使用節點的 peer id，進行前 160 bit 下的亦或 (xor) 距離下的 kademlia 演算法，並保持該 dht 的 bucket 保持在 8，足夠應對網路中的連接和波動，同時使用 stable kademlia來維持網路節點的進出所引起的 table 波動。另一層採取 socket ip address 的距離演算法，使用 ip 進行物理位置的遠近，這個的優勢是保證，如果兩個節點無法直接連接，比如都存在於區域網中，而且受限於 ISP設備是 Port-Restricted Cone 或者 Symmetric，那麼將無法通過 NAT和 hole punching 直接發起連接的時候，可以使用 relay 演算法，藉助第三個節點，實現穩定的連接，那麼就要求第三個節點物理距離兩者不能太遠，用於提高傳輸效率和減少時間。 3.3.5 Zytron chain 3.3.5.1 Web3 兼容介面 Zytron 使用了多種優化技術來降低交易的延遲，但這些優化技術導致了鏈的介面和數據格式與原始的Web3介面產生了較大差異。因此為了保證開發者一致的用戶體驗，Zytron提供了兩套介面。第一套是Zytron專有的介面，可以較好的利用Zytron優化技術以獲得更低的交易延時。而為了保證開發者生態的一致性，Zytron還會封裝出一套Web3兼容介面，這套介面中，將Web3 介面中的Pending State轉換為Pending相關的查詢，由獨立的Web3兼容介面負責數據定址，交易Space Access List估算等工作。 3.3.5.2 多執行引擎支持 Zytron 本質上是一個交易執行引擎，其設計目的在於降低交易執行的延時，增大網路的TPS。但是在設計中並未限定合約執行引擎的種類，目前設計中允許使用UTXO交易模型與EVM合約引擎。隨著更多的需求的引入，Zytron可以介入更多的執行引擎，以實現多樣化的應用場景。甚至基於需求的不同，Zytron不同的地址狀態組可以使用不同的執行引擎。例如，利用Zytron中的代幣可以使用UTXO模式，避免在交易併發執行時導致的問題，而具體的合約交易使用EVM模型，從而避免gas結算時交易依賴問題等。 3.3.5.3 Zero Gas ERC4337 是一個以太坊標準，它提出了一個無需修改現有層一基礎架構的方法，允許創建 “賬戶抽象錢包”。這種錢包的交易可以由任何人發送到區塊鏈上，而費用可以由第三方支付。這意味著用戶可以執行交易而不必用ETH來支付交易費用或代付手續費。 Zytron原生支持EIP4337的賬戶抽象錢包，利用賬戶抽象錢包，Zytron會對符合規則的賬戶提供豁免交易手續費的功能。此功能直接由Sequencer在交易接收時直接進行轉換，實現了0gas的服務功能。 3.3.5.4 Cross-chain Bridge Zytron 的分片執行模式，使得鏈與上層區塊鏈可以關聯到一個具體的地址狀態組中。因此，在這個特殊的地址狀態組中，Zytron會支持一種特殊的deposit交易。這種交易從上層區塊鏈派生而來，用於可以將上層區塊鏈鎖定的Token在Zytron中mint出來。   WEEX唯客交易所官網：weex.com