作者：YBBCapital研究員Ac-CoreTLDR

OPSuccinct的主要功能是將ZKP集成到OPStack的模塊化架構(gòu)中，將OPStackRollups轉(zhuǎn)換為經(jīng)過完全驗證的ZKRollups。

如果Ethereum未來的擴展解決方案是將所有Rollups轉(zhuǎn)換為ZKRollups，那么OPSuccinct旨在利用Rust和SP1在OPStack中部署Type-1zkEVM（完全與Ethereum等效）。

OPSuccinctProposer并行實現(xiàn)證明生成，以及證明聚合和驗證。

現(xiàn)有的OPStack系統(tǒng)依賴于“7天防欺詐窗口”，如果發(fā)生爭議，會導(dǎo)致交易延遲。OPSuccinct通過使用ZK證明縮短了交易完成時間，從而無需延長防欺詐窗口。

OPSuccinct可以大大降低交易成本。1、近期回顧：OP主網(wǎng)更新以及OPStack與OPLabs之間的關(guān)系

2.1OPSuccinct架構(gòu)組件

OPSuccinct是基于1.2節(jié)中概述的OPStack組件構(gòu)建的，是對OPStack的輕量級升級，允許鏈使用ZK驗證的區(qū)塊，同時保持其他組件（op-geth、op-batcher和op-node）不變。OPSuccinct由以下四個主要組件組成：

Range程序：處理批處理塊的程序，用Rust編寫，設(shè)計用于在zkVM內(nèi)運行。

Aggregation程序：聚合來自Range程序的證明以降低鏈上驗證成本，也是用Rust編寫的，設(shè)計用于在zkVM中運行。

OPSuccinctL2輸出預(yù)言機：一個Solidity智能合約，包含一個L2狀態(tài)輸出數(shù)組，每個輸出都提交到L2鏈的狀態(tài)。此合約存在于原始Optimism系統(tǒng)中，但已被修改為使用證明驗證作為身份驗證機制。

OPSuccinct提議者：觀察在L1上發(fā)布的交易批次并管理Range和聚合程序的證明生成。2.2OPSuccinct如何融入Ethereum擴展敘事？

由于需要大量的密碼學(xué)專業(yè)知識，構(gòu)建zkEVMRollups一直具有挑戰(zhàn)性。當OPLabs開發(fā)模塊化OPStack時，他們預(yù)計會支持各種證明機制。為此，他們開源了Kona的開發(fā)，使用Rust實現(xiàn)OPStackRollups的STF，最終通過Kona和SP1程序為OPStack生成零知識證明(ZKP)。這意味著，理論上，任何OPStack鏈都可以升級為使用ZKP。

SP1（SuccinctProcessor1）的目標是讓開發(fā)者能夠使用標準Rust代碼無縫集成Type-1zkEVMrollup。借助OPSuccinct，任何現(xiàn)有OPStack鏈升級到Type-1zkEVMrollup的過程可以在一小時內(nèi)完成，具有以下優(yōu)勢：

快速ZKP確認：將證明延遲減少到幾分鐘，取代7天的防欺詐爭議窗口。

成本效率：平均交易成本降低至僅幾美分。

切換OPStack為ZK：通過部署智能合約，啟動輕量級OPSuccinct提案服務(wù)，可通過API調(diào)用生成證明（包括批處理/序列器、op-node、索引器等）。

Type-1zkEVM：所有與OPStackRollups兼容的工具和智能合約都與OPSuccinctRollups兼容。

提高了可擴展性：可定制的OPSuccinctRollup可以根據(jù)需要添加新的預(yù)編譯并修改Rollup邏輯。

根據(jù)GitHub官方文檔，該過程僅需要安裝Rust、Foundry和Docker，即可將任何現(xiàn)有的OPStackrollup升級為Type-1zkEVMrollup。簡化的流程涉及兩個步驟：

部署ZKL2OutputOracle.sol合約。

啟動OPSuccinct提議服務(wù)（詳細步驟參考GitHub擴展鏈接2）。

3、OPSuccinct能否成為OPStack對抗ZKStack的王牌？

圖片來源：@jtguibas

如果Ethereum的擴容方案短期看是OP，長期看是ZK，那么OPSuccinct的潛在成功可能標志著Ethereum發(fā)展道路上的一個重要里程碑。OPSuccinct為ETHRollups從樂觀驗證過渡到零知識證明（ZKP）提供了一條可升級的途徑。這種轉(zhuǎn)變不僅降低了交易成本，還提高了交易速度，同時保留了ZKRollups的安全和隱私屬性，為未來的應(yīng)用層擴展開辟了新的可能性。

在公認的四大Layer2方案中，目前看來OPStack在生態(tài)建設(shè)上略勝ZKStack，未來馬太效應(yīng)或許會更加明顯，OPSuccinct的加入可能會分走ZKStack的部分流量和潛力，如果OPSuccinct成功，甚至可能對傳統(tǒng)的基于zkEVM的Rollups構(gòu)成挑戰(zhàn)。

然而，從目前提出的操作邏輯來看，一個關(guān)鍵問題浮現(xiàn)出來：開發(fā)人員如何確保及時檢測到由修改狀態(tài)轉(zhuǎn)換函數(shù)(STF)或添加新的預(yù)編譯時未知漏洞引起的系統(tǒng)范圍風(fēng)險？這是一個值得長期關(guān)注的領(lǐng)域。