Opside ZK-PoW V2 版本:多礦工場景下 ZKP計算可縮短至不到一分鐘

2023-07-05 16:07:52

一、Opside ZK-PoW介紹

Opside 是一個去中心化的ZK-RaaS (ZK-Rollup as a Service)平臺,也是業內領先的ZKP(零知識證明)挖礦網絡。ZK-RaaS (ZK-Rollup as a Service) 可以為任何人提供一鍵生成 ZK-Rollup的服務。Opside 提供通用的 ZK-Rollup launchbase,开發者可以通過launchbase輕松地部署不同類型的ZK-Rollup到不同的base chain上。

  • Base chain,包括Ethereum/Opside chain/BNB chain/Polygon PoS等公鏈。

  • ZK-Rollup類型,包括zkSync、Polygon zkEVM、Scroll、StarkNet 等zkEVMs,以及其他種類的ZK-Rollups。

Opside ZK-PoW Cloud會部署到多鏈上,包括但不限於Ethereum、BNB Chain、Polygon PoS以及Opside Chain本身。在Opside的設計中,开發者可以在上述不同的base chain上部署ZK-Rollups。隨着ZK-Rollup技術的逐漸成熟,未來可能會誕生成百上千個ZK-Rollups,這將帶來極大的ZKP算力需求。Opside使用 ZK-PoW 機制來激勵 Miner 提供 ZKP 算力,從而為 ZK-Rollup 提供完整的硬件設施。

二、ZK-PoW V2.0整體架構

ZK-PoW V2.0的整體架構包括幾個關鍵組件:

  • ZK-PoW Cloud:這是Opside提供的用於ZKP計算的雲基礎設施。它部署在多個鏈上,包括Ethereum、BNB Chain、Polygon PoS和Opside Chain。ZK-PoW Cloud負責協調和管理ZKP計算任務。

  • 礦工節點:這些是由礦工操作的節點,他們貢獻自己的計算能力來執行ZKP計算。礦工可以通過在他們的挖礦硬件上運行專用軟件來參與ZK-PoW網絡。

  • ZKP任務分發:ZK-PoW Cloud將ZKP計算任務分發給礦工節點。分發是以去中心化方式進行的,以確保公平性和效率性。ZKP任務包括為各種ZK-Rollup生成和驗證零知識證明。

  • ZKP計算:礦工節點接收ZKP計算任務,並進行必要的計算來生成所需的證明。這涉及執行密碼學算法和進行復雜的計算。

  • 證明提交和驗證:一旦ZKP計算完成,礦工節點將生成的證明提交給ZK-PoW Cloud進行驗證。雲基礎設施驗證證明的正確性,以確保其有效性和完整性。

  • 激勵機制:礦工通過為他們的計算貢獻獲得獎勵來激勵他們參與ZK-PoW網絡。獎勵系統旨在激勵礦工並維護網絡的安全性和穩定性。

總的來說,ZK-PoW V2.0將礦工的計算資源與雲基礎設施相結合,為各種ZK-Rollup提供高效且可擴展的ZKP計算能力。

Aggregator 是Prover的重要組成模塊, 它負責分發ZKP證明任務並接收任務結果即ZKP證明,管理ZKP證明以及將ZKP證明提交到Base Chain以此獲取獎勵 。因此基於功能將新版Aggregator 分為三個子模塊,分別為:Proof Generator, Proof Manager, Proof Sender。

如上圖虛线框內Proof Generator模塊將負責給prover(PoW礦機) 發布證明任務並接受任務結果:ZKP證明,然後將ZKP證明保存到DB數據庫中。Proof Manager 負責管理完成是ZKP證明,將要上鏈的ZKP證明封裝成發送任務轉交給模塊Proof Sender。模塊Proof Sender 完成ZKP證明上鏈,即提交證明給部署在Base Chain上的 zkevm contract。

下面分別介紹這三個模塊:

Proof generator

Rollup Chain 將一定數量交易,打包成一個batch,然後將若幹個(依據交易的頻繁性等多個因數)batch打包成一個sequence,然後將其提交到Base Chain,因此我們可以說每次上鏈數據單位是sequence。 每個sequence包括1個以上batch,而ZKP證明是證明已提交的sequence的合法性,所以batch是證明任務最小單位。

依據sequence包含的batch不同,需要完成的證明任務也不同,具體如下:

  • batch數目等於1, 證明流程BatchProofTask ----> FinalProofTask,需要依次完成BatchProofTask,FinalProofTask證明任務。

  • sequence包含batch數目大於1, 證明流程多個BatchProofTask ---->AggregatorproofTask ---> FinalProofTask,需要依次完成多個BatchProofTask ,AggregatorproofTask,FinalProofTask證明任務。

為了盡可能提高證明產生的效率,也為了提高PoW礦工收益,我們盡可能並發生成證明。具體表現在以下兩方面:

  • 各個sequence 證明生成沒有上下文或者狀態上依賴,可以並發進行。

  • 同一個 sequence 裏多個BatchProofTask可以並發進行。

以此更好的發揮prover的算力資源,從而能更高效的生成證明。

Proof manager

該模塊主要負責管理ZKP證明,控制ZKP證明上鏈驗證。主要分為三個模塊

  • submitPendingProof: 該模塊只在Aggregator每次啓動時執行一次,目的是將上一次Aggregator服務停止前未完成的ZKP證明提交完成。這裏是針對proofHash提交了且其他礦工提交了proof的情況。關於proofHash, proof的介紹參考Proof Sender。

  • tryFetchProofToSend: 在協程執行,將最新生成的ZKP證明且該證明對應的sequence未被驗證加入到Proof Sender的緩存中等待上鏈。

  • processResend: 在協程執行,目的讓超過時間窗口沒驗證成功的sequence重新提交上鏈。

Proof sender

Opside 提出了一個ZKP兩步提交算法,來實現了prover的去中心化。這種算法既能夠防止ZKP搶跑攻擊,又可以讓更多的礦工獲得獎勵,從而鼓勵更多的礦工在线,並提供穩定、持續的ZKP算力。

  • 第1步:對於某個sequence生產PoW證明記為proof,首先計算Hash(proof / address), 記為proofHash,並向合約提交,若該sequence之前沒有提交過proofHash,則开啓proofHash的提交時間窗口T1, 在之後T1個區塊內礦工都有資格提交該sequence,且T1區塊後才能提交proof。

  • 第2步:提交proof, T1後區塊後,开啓proof提交,且限定在T2個區塊內提交。如果T2區塊後,所有礦工提交proof都沒驗證通過,則之前所有提交過proofHash的礦工都被被懲罰。如果在T1時間窗口能成功提交了proofHash,但是在T2時間窗口內未能成功提交proof,且T2 窗口內其他礦工成功提交了proof,則仍然可以繼續提交該proof。除了以上場景外,重新走兩步提交流程。

如下圖,Proof Sender 基於三個线程安全且優先級排序緩存來實現兩步提交,這三個緩存基於 sequence的起始高度進行排序,保證每次從這個三個緩存獲取元素對應的 sequence高度都是最低的,同時這三個緩存中元素是去重的。對應sequence的高度越低越需要優先處理。

  • finalProofMsgCahce: 存放的是Proof Manager發送來finalProof消息,也就是完成ZKP證明。

  • monitPHTxCache: 存儲要監控proofHash 交易。

  • ProofHashCache: 存儲proof消息,用於proof上鏈。

如下圖:

Proof Sender 模塊啓動後會啓動3個協程,分別消費這三個緩存數據。

簡單流程是:

  1. 協程1負責消費finalProofMsgCahce中的finalProof消息,計算proofHash ,如果符合上鏈條件(在T1條件內),則將proofHash上鏈,同時將proofHash 交易放入到monitPHTxCache中。

  2. 協程2消費monitPHTxCache的proofHash 交易消息,如果在T2時間窗口內,滿足proof上鏈條件,這構造proof消息,存放到ProofHashCache。

  3. 協程3消費proof消息,proof上鏈。

相對舊模塊,結構更加清晰,節省資源开銷。

三、總結

與Version1.0對比

  • V2.0拆分了原有服務為三個子模塊,三個模塊分別負責證明產生,證明管理,證明上鏈,結構更加清晰,三個模塊耦合性低,魯棒性強。

  • 證明產生模塊Proof Generator相對舊版添加了startBatch 參數方便新加入礦工能更快跟上挖礦進度。

  • 證明管理模塊Proof Manager相對舊版更好改進:對於礦工重啓服務或者其他原因導致proof 未提交或者提交失敗會第一時間重發proof,保證礦工利益;同時重發機制不僅針對proof提交失敗情況,也針對所有proof提交失敗或者未提交,重啓時間窗口,保證Rollup Chain安全性。

  • 證明發送模塊Proof Sender基於三個线程安全優先級緩存來實現交易兩步式提交,相對之前版本減少全局鎖使用,保證了低高度的proof能第一時間提交,保證了礦工的利益。同時,整個服務流程更清晰,減少了线程數量,減少了程序執行中資源的消耗。

壓測結果:

  • Version2.0使用10臺64核機器,完成batch 證明566個,耗時7小時38分40秒,平均48.62秒完成一個證明。在多礦工場景下,相較於V1.0,V2.0的zk proof生成效率整體提高了50%

總之,Opside ZK-PoW V2.0優化了多礦工參與ZKP計算的流程,提升了硬件利用率,提高了服務可用性,對礦工更加友好。更重要的是,在多礦工的場景下,將ZKP的計算縮短到不到一分鐘,極大地加快了ZK-Rollup的確認時間。

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

推薦文章

btc日內再次下跌 短线應當如何處理?

盡管以太坊現貨ETF獲批是個好消息,但市場反應卻不如預期。在消息公布後,以太坊價格出現了小幅下跌,...

加密蓮
107 3個月前

7月23日、BTC(合約)ETH(合約)行情分析及操作策略

昨日收益還是不錯的,日內給出的現價空單分別止盈我們目標點位,恭喜跟上的朋友喫肉。時間一晃到月底了,...

倪老師
107 3個月前

幣圈院士:血與淚的教訓!交易者為何總是撞死在同一棵樹上?

幣圈院士談。交易市場中的幾種“死法” 在幣圈市場鱗次櫛比的海洋,風起雲湧,時常讓人感到驚手不及。在...

幣圈院士
111 3個月前

7月23:Mt. Gox 比特幣錢包在市場緊縮的情況下轉移了價值 28.2 億美元的 BTC

7月23:Mt. Gox 比特幣錢包在市場緊縮的情況下轉移了價值 28.2 億美元的 BTC一個引...

168超神
106 3個月前

悅盈:比特幣68000的空完美落地反彈繼續看跌 以太坊破前高看回撤

一個人的自律中,藏着無限的可能性,你自律的程度,決定着你人生的高度。 人生沒有近路可走,但你走的每...

我是周悅盈
88 3個月前

btc完美盈利 晚間波動較大注意

昨日btc空單完美給到,最大化走出一千七百點空間~ btc: 日內开盤下跌繼續測試66000一线,...

加密蓮
95 3個月前