era boojum下載 -era era boojum原始碼下載

era boojum

其他源碼

下載

警告

該箱子已存檔。開發已轉移到 zksync-crypto 儲存庫。請改用它。

布瓊姆

zkSync Era 是第 2 層匯總，它使用零知識證明來擴展以太坊，而不會影響安全性或去中心化。由於它與 EVM 相容（Solidity/Vyper），因此 99% 的以太坊專案可以重新部署，而無需重構或重新審核一行程式碼。 zkSync Era 也使用基於 LLVM 的編譯器，最終讓開發人員可以用 C++、Rust 和其他流行語言編寫智慧合約。

關於

該庫的目的是使用非常具體的算術運算以及有關字段大小的附加假設。粗略地說，我們期望有一個帶有 |F| 的字段F ~ 64 位元（機器字的大小）（關於欄位大小的假設對於算術和閘佈局策略並不重要，但在依賴特定欄位大小的特定函數的小工具實作中斷言）。

該系統具有邏輯功能（小工具）的層次結構 - 門（可以將自身記錄到追蹤中的實體） - 和求值器（多項式之間的關係）。評估器以特徵的形式編寫，允許我們稍後自動編寫函數來檢查可滿足性和計算證明，以及合成普通驗證器和遞歸驗證器。門附加了額外的工具，允許門本身追蹤它們應該放置在跡線中的位置的邏輯。請注意，我們依靠 Plonk 的複製約束並處理「變數」的可複製邏輯實體來組成最終的可證明語句。該系統不適用於 AIR 算術，且不允許表達跨越追蹤的多行的約束。

一般來說，痕跡包含很少種類的柱子。主要區別在於：

通用列 - 可以允許不同類型的門使用某些變數列（可複製）、見證列（不可複製，有時也稱為「建議」列）和常數，從而需要將選擇器放在前面商多項式中的相應項。對於這些通用列，放置邏輯很簡單：我們嘗試根據系統中對應類型的指定列數，在閘/求值器允許的範圍內放入盡可能多的相同關係的重複項。稍後，當選擇器具體化時，可以添加一些額外的常數列。一般來說，門的預設行為是嘗試「攤銷」常數，從某種意義上說，在同一行上，我們嘗試放置使用相同常數的門。這是一種合理的方法，因為實際上大多數電路都是“循環”，因此我們可以“填充”該行。
「專用」列 - 人們可以為特定的閘/評估器指定一組單獨的列，因此評估器強制執行的關係必須適用於這些列中的每一行。這在某些經常使用特定閘的電路中可能是有益的。在多個集合被用於相同關係的情況下，人們可以指定這些列的幾種不同的利用模式，即在集合之間是否共享常數。

此外，追蹤可讓您新增查找參數，該參數還可以使用專用列來容納查找表的條目，或僅使用通用列。目前，表格僅被編碼為一組多項式，因此追蹤的總長度必須大於表中的條目總數。

請注意，每個「門」（作為 Rust 類型）都是唯一的，因此門只能放置在專用列或通用列中，但不能同時放置在兩者中。如果需要這樣的功能，那麼可以製作一個新類型包裝器。

更高層級的邏輯函數（如布林分解、範圍檢查、零檢查等）用於使電路以不同的方式在內部記錄自己，這取決於 CS 的特定實例中是否允許某些閘。從 Rust 的角度來看，具有不同閘集的 CS 實例被視為不同的類型，我們依靠一些內聯/常數 prop/編譯器來減少靜態跳轉的分支。

施工分部注意事項

僅實現了 2^64 - 2^32 + 1 字段。非向量化數學實現是基於為 Plonky2 開發的實現，但針對 const 特徵重新制定
自動向量化主要用於加法，其好處是顯而易見的
Poseidon MDS和輪常數等於Plonky2，提供使用者一定的相容性
Poseidon2 輪常數重用了 Poseidon 常數
算術約束僅影響一行。放置策略是透過按行或按列平鋪來盡可能攤銷常數
複製排列參數取自 Plonk（基於大乘積的參數）。稍後可能會改為對數導數（加法導數）
找出參數是對數導數（加法）
目前電路中的查找表必須具有相同的寬度
目前還沒有任何欄位可以與預言分離並輸入到另一個證明中
目前，向擴展字段的移動僅在 FRI 聚合上完成（因此在先前的階段挑戰是|F| ，因此我們必須重複參數），但這將被更改，以便我們移動到擴展字段，如下所示提交給證人後儘可能快地避免分母為零的相當“大”的機會。證明中計算費用的影響可忽略不計
零知識尚未實現，但已計劃（門本身將決定如何在尚未使用的行中放置令人滿意的但隨機的見證人）
FFT 未最佳化
哈希值有所最佳化
實現的門是固執己見的，以及算術化

關於查找參數的注意事項

我們使用透過關係sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta)執行的查找參數，其中對專用列selector(x_i)只是一個身分。我們也不將表格編碼為較小次數的多項式以消除額外的次數邊界檢查，而是用零填充它們。請注意，表條目永遠不會包含(0,0,...,0)元素，因為在多個表的情況下（即使只使用一個表），我們對表類型使用單獨的ID 列，並且使用ID就像這樣從1開始。

像這樣的查找參數的一個很好的功能是，由於其附加性質，如果我們在同一個表中查找多個witness多項式，而不是對每個多項式（元組）重複該參數（這將需要一個單獨的多重性列，以及稍後的一些中間多項式），我們可以「新增」多重性並將參數轉換為類似sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) ，因此查找的總成本僅為 1 個多重數列和 2 個（與見證相關的） + 1 個（與表相關的）中間多項式，用於編碼單位根上的左側和右側關係。

這個論點的正確性是顯而易見的。為了合理性，我們使用「快速尋找的緩存商」論文引理 2.4 中的原始參數。我們需要證明，提交total_multiplicity就足夠了，而不是分別提交witness_0和witness_1的多重性。

假設方程式sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X)成立。我們需要證明witness_0和witness_1包含在表t中。令f = (witness_0 | witness_1) ，值的串連。上面的等式意味著sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) （注意 LHS 上i的區間長度是上面的兩倍）。根據引理 2.4，我們得到f subset t ：“子集”，即向量f的每個座標都是t的座標。特別是， witness_0, witness_1 subset f subset t 。

請注意，該論點也適用於多個witness_i 。對於所選的beta ，其餘的穩健性論證直接遵循上述工作。

計劃擴建

僅適用於基準測試中的小數

有 8kB SHA256 的基準，使用我們認為是 SHA256 電路的閘 + 表的最佳配置。請注意，儘管證明器有點快，但我們沒有正確優化 FFT，並且仍然使用 Poseidon（而不是 Poseidon2）進行我們希望將證明用於遞歸的配置。兩個腳本sha256_bench_recursive.sh和sha256_bench_non_recursive.sh允許您執行相應的測試（是否預計將在遞歸中使用證明），並且您應該查找一行Proving is done, taken ...以查看證明時間，因為在它之後運行的驗證程序非常冗長。這些基準測試使用 LDE 因子 8，儘管我們所有的約束都是 4 級或更小 - 然而，它是一些其他公共基準測試中使用的參數。我們也不在這些證明中使用 PoW，因為 20 位元的 PoW 可以忽略不計（30 毫秒），而且我們還不支援代數哈希上的 PoW（然而，這些僅慢約 2 倍，所以也可以忽略不計）。安全等級大約為100位，但可以透過增加查詢數量來提高 FRI 健全性，且查詢數量的增加不會增加證明時間（不要與更改 FRI 速率混淆）。追蹤長度為2^16 ，它使用 60 個通用列和 8 個寬度為 4 的查找參數。

注意：基準測試只是嘗試編譯為本機架構，目前通常只對 AArch64（讀取 Apple M1）架構進行端對端測試。 x86-64 算術實現進行了有效性測試，但未進行端到端的完整證明。請注意，除了cpu = native之外，最大效能 x86-64 還需要額外的編譯器功能標誌（即使在本機 CPU 上，Rust 編譯器也不使用 AVX512 集）