來源：登鏈社區(qū)

零知識、簡潔、非交互式知識證明（zk-SNARKs）是一種強大的加密原語，允許一方，即證明者，說服另一方，即驗證者，某個陳述是真實的，而不透露除了該陳述的有效性之外的任何其他信息。由于它們在可驗證的私人計算、提供計算機程序執(zhí)行正確性的證明以及幫助擴展區(qū)塊鏈方面的應(yīng)用，它們引起了廣泛關(guān)注。我們認為 SNARKs 將對塑造我們的世界產(chǎn)生重大影響，正如我們在我們的文章^[6]中所描述的那樣。SNARKs 作為不同類型的證明系統(tǒng)的總稱，使用不同的多項式承諾方案（PCS）、算術(shù)化方案、交互式 Oracle 證明（IOP）或概率可檢查證明（PCP）。然而，這些基本思想和概念可以追溯到 20 世紀 80 年代中期。在比特幣和以太坊的引入后，開發(fā)工作顯著加快，這證明了它們是一個令人興奮且強大的用例，因為你可以通過使用零知識證明（通常稱為此特定用例的有效性證明）來擴展它們。SNARKs 是區(qū)塊鏈可擴展性的重要工具。正如 Ben-Sasson 所描述的，過去幾年見證了加密證明的寒武紀爆發(fā)^[7] 。每個證明系統(tǒng)都有優(yōu)點和缺點，并且在設(shè)計時考慮了某些權(quán)衡。硬件的進步、更好的算法、新的論證和小工具導(dǎo)致了性能的提升和新系統(tǒng)的誕生。其中許多系統(tǒng)正在生產(chǎn)中使用，并且我們不斷推動界限。我們是否會有一個適用于所有應(yīng)用的通用證明系統(tǒng)，還是適用于不同需求的幾個系統(tǒng)？我們認為一個證明系統(tǒng)將統(tǒng)治所有應(yīng)用的可能性不大，因為：

1. 應(yīng)用的多樣性。

2. 我們有不同的約束類型（關(guān)于內(nèi)存、驗證時間、證明時間）。

3. 對魯棒性的需求（如果一個證明系統(tǒng)被破解，我們?nèi)匀挥衅渌到y(tǒng)）。

即使證明系統(tǒng)發(fā)生了很大變化，它們都具有一個重要特性：證明可以快速驗證。通過具有驗證證明并且可以輕松適應(yīng)處理新的證明系統(tǒng)的層， 也解決了與更改基礎(chǔ)層（如以太坊）相關(guān)的困難。

為了概述 SNARKs 的不同特征：

• 密碼假設(shè)：抗碰撞哈希函數(shù)、橢圓曲線上的離散對數(shù)問題、指數(shù)知識。

• 透明 vs 可信設(shè)置。

• 證明者時間：線性 vs 超線性。

• 驗證者時間：常數(shù)時間、對數(shù)、次線性、線性。

• 證明大小。

• 遞歸的便利性。

• 算術(shù)化方案。

• 一元 vs 多元多項式。

本文將探討 SNARKs 的起源、一些基本構(gòu)建模塊以及不同證明系統(tǒng)的興起（和衰落）。本文并不打算對證明系統(tǒng)進行詳盡的分析。相反，我們專注于對我們當前產(chǎn)生影響的那些。當然，這些發(fā)展只有在這一領(lǐng)域的先驅(qū)們的偉大工作和思想的基礎(chǔ)上才得以實現(xiàn)。

基礎(chǔ)知識

正如我們所提到的，零知識證明并不是新鮮事物。定義、基礎(chǔ)、重要定理甚至重要協(xié)議都是從 20 世紀 80 年代中期確立的。一些用于構(gòu)建現(xiàn)代 SNARKs 的關(guān)鍵思想和協(xié)議是在 1990 年代提出的（sumcheck 協(xié)議），甚至在比特幣出現(xiàn)之前（2007 年的 GKR）。當時采用的主要問題，主要是缺乏強大的用例（1990 年代互聯(lián)網(wǎng)發(fā)展不如今日）以及所需的計算能力有關(guān)。

零知識證明：起源（1985/1989）

零知識證明領(lǐng)域在學(xué)術(shù)文獻中首次出現(xiàn)是在 [Goldwasser, Micali and Rackoff](https://people.csail.mit.edu/silvio/Selected Scientific Papers/Proof Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf?ref=blog.lambdaclass.com "Goldwasser, Micali and Rackoff") 的論文中。有關(guān)起源的討論，你可以參見以下視頻^[8] 。該論文引入了完備性、正確性和零知識的概念，并提供了二次剩余（quadratic residuosity）和二次非剩余（quadratic non-residuosity）的構(gòu)造。

Sumcheck 協(xié)議（1992）

sumcheck 協(xié)議^[9]是由 Lund, Fortnow, Karloff, and Nisan^[10] 于 1992 年提出的。它是簡潔交互證明的最重要的構(gòu)建模塊之一。它幫助我們將多元多項式的求值之和的聲明減少到在隨機選擇的點上的單個求值。

Goldwasser-Kalai-Rothblum（GKR）（2007）

GKR 協(xié)議^[11]是一種交互式協(xié)議，其證明者的運行時間與電路的門數(shù)成線性關(guān)系，而驗證者的運行時間與電路的大小成次線性關(guān)系。在該協(xié)議中，證明者和驗證者就深度為 d 的有限域上的扇形二通算術(shù)（an arithmetic circuit of fan-in-two）電路達成一致，其中層 d 對應(yīng)于輸入層，層 0 對應(yīng)于輸出層。協(xié)議從對電路輸出的聲明開始，將其減少為對前一層值的聲明。通過遞歸，我們可以將其轉(zhuǎn)換為對電路輸入的聲明，這可以輕松地進行檢查。這些減少是通過 sumcheck 協(xié)議實現(xiàn)的。

KZG 多項式承諾方案 （2010）

KZG 多項式承諾方案 （KZG polynomial commitment scheme 簡稱 PCS ）Kate, Zaverucha, and Goldberg^[12]于 2010 年引入了使用雙線性配對群的多項式承諾方案。該承諾由單個群元素組成，提交者可以有效地打開對多項式的任何正確評估的承諾。此外，由于批處理技術(shù)，可以對多個評估進行打開。KZG 承諾是 Pinocchio、Groth16 和 Plonk 等幾種高效 SNARKs 提供了基本構(gòu)建模塊。它也是 EIP-4844^[13] 的核心。有關(guān)批處理技術(shù)的直觀理解，你可以參見我們關(guān)于 Mina-Ethereum 橋^[14]的文章。

使用橢圓曲線的實用 SNARKs

2013 年出現(xiàn)了第一個實用的 SNARKs 構(gòu)造。這些構(gòu)造需要預(yù)處理步驟來生成證明和驗證密鑰，并且是程序/電路特定的。這些密鑰可能相當大，并且取決于應(yīng)保持未知的秘密參數(shù)；否則，它們可以偽造證明。將代碼轉(zhuǎn)換為可證明的內(nèi)容需要將代碼編譯成一系列多項式約束系統(tǒng)。起初，這必須以手動編碼方式完成，這是耗時且容易出錯的。該領(lǐng)域的進展試圖消除一些主要問題：

1. 有更高效的證明者。

2. 減少預(yù)處理的數(shù)量。

3. 具有通用而不是特定電路的設(shè)置。

4. 避免信任設(shè)置。

5. 開發(fā)使用高級語言描述電路的方法，而不是手動編寫多項式約束。

Pinocchio (2013)

Pinocchio^[15] 是第一個實用的、可用的 zk-SNARK。SNARK 基于二次算術(shù)程序（QAP）。證明大小最初為 288 字節(jié)。Pinocchio 的工具鏈提供了從 C 代碼到算術(shù)電路的編譯器，進一步轉(zhuǎn)換為 QAP。該協(xié)議要求驗證者生成密鑰，這些密鑰是特定于電路的。它使用橢圓曲線配對來檢查方程。證明生成和密鑰設(shè)置的漸近性與計算大小成線性關(guān)系，驗證時間與公共輸入和輸出的大小成線性關(guān)系。

Groth 16 (2016)

Groth^[16] 引入了一個具有增強性能的新知識論證^[17] ，用于描述 R1CS 的問題。它具有最小的證明大?。▋H三個群元素）和快速驗證，涉及三個配對。它還涉及一個預(yù)處理步驟，以獲得結(jié)構(gòu)化參考字符串。其主要缺點是，它需要針對我們想要證明的每個程序進行不同的信任設(shè)置，這很不方便。Groth16 被 ZCash 使用。

Bulletproofs & IPA (2016)

KZG PCS 的一個弱點是它需要一個信任設(shè)置。Bootle 等人^[18] 引入了滿足內(nèi)積關(guān)系的 Pedersen 承諾開局的有效零知識論證系統(tǒng)。內(nèi)積論證具有線性證明者，對數(shù)通信和交互，但具有線性時間驗證。他們還開發(fā)了一個不需要信任設(shè)置的多項式承諾方案。使用這些想法的多項式承諾方案（PCS） 被 Halo 2 和 Kimchi 使用。

Sonic、Marlin 和 Plonk (2019)

Sonic^[19]、Plonk^[20] 和 Marlin^[21] 解決了 Groth16 中我們所遇到的每個程序都需要信任設(shè)置的問題，通過引入通用和可更新的結(jié)構(gòu)化參考字符串。Marlin 提供了基于 R1CS (Rank-1 Constraint System) 的證明系統(tǒng)，是 Aleo 的核心。

Plonk^[22] 引入了一種新的算術(shù)方案（后來稱為 Plonkish）和使用宏積（grand-product）檢查來檢查復(fù)制約束。Plonkish 還允許為某些操作引入專門的門，即所謂的定制門。幾個項目都有 Plonk 的定制版本，包括 Aztec、ZK-Sync、Polygon ZKEVM、Mina 的 Kimchi、Plonky2、Halo 2 和 Scroll 等。

Lookups (2018/2020)

Gabizon 和 Williamson 在 2020 年引入了 plookup^[23]，使用宏積檢查來證明一個值包含在預(yù)先計算的值表中。盡管查找參數(shù)先前在 Arya^[24] 中提出，但該構(gòu)造需要確定查找的多重性，這使得構(gòu)造不夠高效。PlonkUp^[25] 論文展示了如何將 plookup 參數(shù)引入 Plonk。這些查找參數(shù)的問題在于，它們迫使證明者為整個表支付費用，而與他的查找次數(shù)無關(guān)。這意味著大型表的成本相當大，人們已經(jīng)付出了大量努力來減少證明者僅支付他使用的查找次數(shù)的成本。Hab?ck 引入了 LogUp^[26]，它使用對數(shù)導(dǎo)數(shù)將宏積（grand-product）檢查轉(zhuǎn)換為倒數(shù)的和。LogUp 對于 Polygon ZKEVM^[27] 中的性能至關(guān)重要，他們需要將整個表拆分為幾個 STARK 模塊。這些模塊必須正確鏈接，跨表查找強制執(zhí)行這一點。引入 LogUp-GKR^[28] 使用 GKR 協(xié)議來提高 LogUp 的性能。Caulk^[29] 是第一個證明者時間與表大小亞線性的方案，使用預(yù)處理時間 O(NlogN) 和存儲 O(N)，其中 N 是表大小。隨后出現(xiàn)了幾種其他方案，如 Baloo^[30]、flookup^[31]、cq^[32] 和 caulk+^[33]。Lasso^[34] 提出了幾項改進，避免在表具有給定結(jié)構(gòu)時對其進行提交。此外，Lasso 的證明者只為 lookup 操作訪問的表條目付費。Jolt^[35] 利用 Lasso 通過 lookups 證明虛擬機的執(zhí)行情況。

Spartan (2019)

Spartan^[36] 為使用 R1CS 描述的電路提供了一個 IOP ("Interactive Oracle Proof.")，利用多變量多項式的性質(zhì)和 sumcheck 協(xié)議。使用合適的多項式承諾方案，它產(chǎn)生了一個線性時間證明的透明 SNARK。

HyperPlonk (2022)

HyperPlonk^[37] 基于 Plonk 的思想，使用多變量多項式(multivariate polynomials)。它依賴于 sumcheck 協(xié)議而不是商來檢查約束的執(zhí)行。它還支持高次約束，而不會影響證明者的運行時間。由于它依賴于多變量多項式，因此無需進行 FFT，證明者的運行時間與電路大小成線性關(guān)系。HyperPlonk 引入了一種適用于較小字段的新置換 IOP，以及一種基于 sumcheck 的批量打開協(xié)議，這減少了證明者的工作、證明大小和驗證者的時間。

Folding schemes (2008/2021)

Nova^[38] 引入了折疊（Folding）方案的概念，這是一種實現(xiàn)增量可驗證計算（IVC：incrementally verifiable computation）的新方法。IVC 的概念可以追溯到 Valiant^[39]，他展示了如何將長度為 k 的兩個證明合并為長度為 k 的單個證明。這個想法是，我們可以通過遞歸地證明從第 i 步到第 I +1 步的執(zhí)行是正確的，并驗證一個證明，證明從第 i?1 步到第 i 步的轉(zhuǎn)換是正確的，來證明任何長時間運行的計算。Nova 很好地處理統(tǒng)一計算；隨后它被擴展以處理不同類型的電路，引入了 Supernova^[40]。Nova 使用 R1CS 的一種放松版本，并在友好的橢圓曲線上工作。使用曲線的友好循環(huán)（例如 Pasta 曲線）來實現(xiàn) IVC，也被用于 Pickles，Mina 的實現(xiàn)簡潔狀態(tài)的主要構(gòu)建塊。然而，折疊的概念與遞歸 SNARK 驗證不同。

累加器的想法與批量證明的概念更深入地聯(lián)系在一起。Halo^[41] 引入了累加的概念作為遞歸證明組合的替代方案。Protostar^[42] 為 Plonk 提供了一種非統(tǒng)一的 IVC 方案，支持高次門和向量 lookups。

使用抗碰撞哈希函數(shù)

在 Pinocchio 開發(fā)的同時，有一些想法是生成電路/算術(shù)方案，可以證明虛擬機的執(zhí)行正確性。即使開發(fā)虛擬機的算術(shù)化可能比為一些程序編寫專用電路更復(fù)雜或不太高效，但它的優(yōu)勢在于可以通過展示在虛擬機中正確執(zhí)行程序來證明任何復(fù)雜的程序。TinyRAM 中的想法隨后通過 Cairo vm 的設(shè)計得到改進，并且隨后的虛擬機（如 zk-evms 或通用目的 zkvms）也得到了改進。使用抗碰撞哈希函數(shù)消除了對可信設(shè)置或橢圓曲線操作的需求，但代價是證明變得更長。

TinyRAM（2013）

在 SNARKs for C^[43] 中，他們開發(fā)了基于 PCP 的 SNARK，用于證明 C 程序的執(zhí)行正確性，該程序被編譯為 TinyRAM，即精簡指令集計算機。

備注：PCP， Probabilistically Checkable Proof 概率可檢查證明， 驗證者只需閱讀證明中隨機選擇的一小部分內(nèi)容，就能以很高的置信度檢查證明的有效性。與驗證者需要檢查整個證明的傳統(tǒng)證明系統(tǒng)不同，PCP 只需有限的隨機性即可實現(xiàn)高效驗證。

該計算機采用哈佛結(jié)構(gòu)，具有字節(jié)級可尋址的隨機存儲器。利用非確定性，電路的大小與計算的大小幾乎成線性關(guān)系，可以高效處理任意和數(shù)據(jù)相關(guān)的循環(huán)、控制流和內(nèi)存訪問。

STARKs（2018）

STARKs^[44] 由 Ben Sasson 等人于 2018 年提出。它們實現(xiàn)了0（log^2 n）的證明大小，具有快速的證明者和驗證者，不需要可信設(shè)置，并且被推測為后量子安全。它們首次被 Starkware/Starknet 使用，與 Cairo vm 一起。它的關(guān)鍵引入包括代數(shù)中間表示（AIR）和 FRI 協(xié)議^[45]（快速 Reed-Solomon 交互式 Oracle 接近證明 Fast Reed-Solomon Interactive Oracle Proof of Proximity ）。它也被其他項目使用（Polygon Miden、Risc0、Winterfell、Neptune），或者看到了一些組件的改編（ZK-Sync 的 Boojum、Plonky2、Starky）。

Ligero（2017）

Ligero^[46] 提出了一種證明系統(tǒng)，實現(xiàn)了證明大小為 O(√n) ，其中 n 是電路的大小。它將多項式系數(shù)排列成矩陣形式，并使用線性碼。Brakedown^[47] 建立在 Ligero 的基礎(chǔ)上，引入了領(lǐng)域無關(guān)多項式承諾方案的概念。

一些新的發(fā)展

在生產(chǎn)中使用不同的證明系統(tǒng)展示了每種方法的優(yōu)點，并帶動新的發(fā)展。例如，plonkish 算術(shù)化提供了一種簡單的方法來包含自定義門和lookup arguments；FRI 已經(jīng)顯示出作為 PCS 的出色性能，通向了 Plonky。同樣，在 AIR 中使用宏積檢查（帶來了預(yù)處理的隨機化 AIR）改進了其性能并簡化了內(nèi)存訪問參數(shù)?；诠：瘮?shù)的承諾因其在硬件中的速度或新的適用于 SNARK 的哈希函數(shù)的引入而變得流行。

新的多項式承諾方案（2023）

隨著基于多變量多項式的高效 SNARKs 的出現(xiàn)，例如 Spartan 或 HyperPlonk，人們對適用于這種多項式的新承諾方案產(chǎn)生了更大的興趣。Binius^[48]、Zeromorph^[49] 和 Basefold^[50] 都提出了對多線性多項式進行承諾的新形式。Binius 的優(yōu)勢在于表示數(shù)據(jù)類型時沒有額外開銷（而許多證明系統(tǒng)至少使用 32 位字段元素來表示單個位），并且可以在二進制域上工作。該承諾方案采用了為領(lǐng)域無關(guān)而設(shè)計的 brakedown。Basefold 將 FRI 推廣到除 Reed-Solomon 之外的碼，帶來了一個領(lǐng)域無關(guān)的 PCS。

注 領(lǐng)域無關(guān)：在領(lǐng)域無關(guān)的多項式承諾方案中，承諾過程不依賴于任何特定領(lǐng)域的特定屬性。這意味著可以對任何代數(shù)結(jié)構(gòu)的多項式做出承諾，如有限域、橢圓曲線，甚至整數(shù)環(huán)。

可定制的約束系統(tǒng)（2023）

CCS^[51] 泛化了 R1CS，同時捕捉了 R1CS、Plonkish 和 AIR 算術(shù)化，沒有額外開銷。使用 CCS 與 Spartan IOP 結(jié)合產(chǎn)生了 SuperSpartan，它支持高維約束，而且證明者不需要承擔隨著約束度量增加而擴展的加密成本。特別是，SuperSpartan 為 AIR 提供了一個線性時間證明的 SNARK。

結(jié)論

本文描述了自 20 世紀 80 年代中期以來 SNARKs 的進展。計算機科學(xué)、數(shù)學(xué)和硬件的進步，以及區(qū)塊鏈的引入，導(dǎo)致了新的更高效的 SNARKs 的出現(xiàn)，為許多可能改變我們社會的應(yīng)用打開了大門。研究人員和工程師根據(jù)他們的需求提出了對 SNARKs 的改進和適應(yīng)，關(guān)注證明大小、內(nèi)存使用、透明設(shè)置、后量子安全、證明時間和驗證時間。雖然最初有兩條主要線路（SNARKs vs STARKs），但兩者之間的界限已經(jīng)開始消失，試圖結(jié)合不同證明系統(tǒng)的優(yōu)勢。例如，結(jié)合不同的算術(shù)化方案與新的多項式承諾方案。我們可以預(yù)期，新的證明系統(tǒng)將繼續(xù)涌現(xiàn)，性能將會提高，對于一些需要一些時間來適應(yīng)的系統(tǒng)來說，要跟上這些發(fā)展將會很困難，除非我們可以輕松地使用這些工具而無需改變一些核心基礎(chǔ)設(shè)施。

參考資料

[1]鏈接:https://blog.lambdaclass.com/our-highly-subjective-view-on-the-history-of-zero-knowledge-proofs/

[2]登鏈翻譯計劃:https://github.com/lbc-team/Pioneer

[3]翻譯小組:https://learnblockchain.cn/people/412

[4]Tiny 熊:https://learnblockchain.cn/people/15

[5]learnblockchain.cn/article…:https://learnblockchain.cn/article/7422

[6]文章:https://blog.lambdaclass.com/transforming-the-future-with-zero-knowledge-proofs-fully-homomorphic-encryption-and-new-distributed-systems-algorithms/

[7]加密證明的寒武紀爆發(fā):https://medium.com/starkware/cambrian-explosion-of-cryptographic-proofs-5740a41cdbd2?ref=blog.lambdaclass.com

[8]以下視頻:https://www.youtube.com/watch?v=uchjTIlPzFo&ref=blog.lambdaclass.com

[9]sumcheck 協(xié)議:https://blog.lambdaclass.com/have-you-checked-your-sums/

[10]Lund, Fortnow, Karloff, and Nisan:https://dl.acm.org/doi/pdf/10.1145/146585.146605?ref=blog.lambdaclass.com

[11]GKR 協(xié)議:https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/2008-DelegatingComputation.pdf?ref=blog.lambdaclass.com

[12]Kate, Zaverucha, and Goldberg:https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf?ref=blog.lambdaclass.com

[13]EIP-4844:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md?ref=blog.lambdaclass.com

[14]Mina-Ethereum 橋:https://blog.lambdaclass.com/mina-to-ethereum-bridge/

[15]Pinocchio:https://eprint.iacr.org/2013/279?ref=blog.lambdaclass.com

[16]Groth:https://eprint.iacr.org/2016/260.pdf?ref=blog.lambdaclass.com

[17]具有增強性能的新知識論證:https://blog.lambdaclass.com/groth16/

[18]Bootle 等人:https://eprint.iacr.org/2016/263?ref=blog.lambdaclass.com

[19]Sonic:https://eprint.iacr.org/2019/099?ref=blog.lambdaclass.com

[20]Plonk:https://eprint.iacr.org/2019/953?ref=blog.lambdaclass.com

[21]Marlin:https://eprint.iacr.org/2019/1047?ref=blog.lambdaclass.com

[22]Plonk:https://blog.lambdaclass.com/all-you-wanted-to-know-about-plonk/

[23]plookup:https://eprint.iacr.org/2020/315?ref=blog.lambdaclass.com

[24]Arya:https://eprint.iacr.org/2018/380?ref=blog.lambdaclass.com

[25]PlonkUp:https://eprint.iacr.org/2022/086?ref=blog.lambdaclass.com

[26]LogUp:https://eprint.iacr.org/2022/1530?ref=blog.lambdaclass.com

[27]Polygon ZKEVM:https://toposware.medium.com/beyond-limits-pushing-the-boundaries-of-zk-evm-9dd0c5ec9fca?ref=blog.lambdaclass.com

[28]LogUp-GKR:https://eprint.iacr.org/2023/1284?ref=blog.lambdaclass.com

[29]Caulk:https://eprint.iacr.org/2022/621?ref=blog.lambdaclass.com

[30]Baloo:https://eprint.iacr.org/2022/1565?ref=blog.lambdaclass.com

[31]flookup:https://eprint.iacr.org/2022/1447?ref=blog.lambdaclass.com

[32]cq:https://eprint.iacr.org/2022/1763?ref=blog.lambdaclass.com

[33]caulk+:https://eprint.iacr.org/2022/957?ref=blog.lambdaclass.com

[34]Lasso:https://eprint.iacr.org/2023/1216?ref=blog.lambdaclass.com

[35]Jolt:https://eprint.iacr.org/2023/1217?ref=blog.lambdaclass.com

[36]Spartan:https://eprint.iacr.org/2019/550?ref=blog.lambdaclass.com

[37]HyperPlonk:https://eprint.iacr.org/2022/1355.pdf?ref=blog.lambdaclass.com

[38]Nova:https://eprint.iacr.org/2021/370?ref=blog.lambdaclass.com

[39]Valiant:https://https//iacr.org/archive/tcc2008/49480001/49480001.pdf?ref=blog.lambdaclass.com

[40]Supernova:https://eprint.iacr.org/2022/1758?ref=blog.lambdaclass.com

[41]Halo:https://eprint.iacr.org/2019/1021.pdf?ref=blog.lambdaclass.com

[42]Protostar:https://eprint.iacr.org/2023/620?ref=blog.lambdaclass.com

[43]SNARKs for C:https://eprint.iacr.org/2013/507?ref=blog.lambdaclass.com

[44]STARKs:https://eprint.iacr.org/2018/046?ref=blog.lambdaclass.com

[45]FRI 協(xié)議:https://blog.lambdaclass.com/how-to-code-fri-from-scratch/

[46]Ligero:https://eprint.iacr.org/2022/1608?ref=blog.lambdaclass.com

[47]Brakedown:https://eprint.iacr.org/2021/1043?ref=blog.lambdaclass.com

[48]Binius:https://blog.lambdaclass.com/snarks-on-binary-fields-binius/

[49]Zeromorph:https://eprint.iacr.org/2023/917?ref=blog.lambdaclass.com

[50]Basefold:https://blog.lambdaclass.com/how-does-basefold-polynomial-commitment-scheme-generalize-fri/

[51]CCS:https://eprint.iacr.org/2023/552?ref=blog.lambdaclass.com

[52]DeCert.me:https://decert.me/