CRS（共同參考字串）

什麼是 CRS（共同參考字串）？

CRS 是 Common Reference String（共同參考字串）的縮寫，指零知識證明系統使用的一組共享公開密碼學參數。

在加密貨幣領域，CRS 最常與 zk-SNARK、隱私協議、有效性證明、zk-rollup、多項式承諾及區塊鏈擴容系統相關。

CRS 為證明者與驗證者提供共同基礎，讓證明者無須揭露私密資訊即可建立證明並供驗證者檢查。

證明者使用 CRS 產生證明，驗證者則使用相同的 CRS 檢查證明是否有效。

ethereum.org 的零知識證明指南說明，部分零知識系統使用的公開參數統稱為 Common Reference String。

CRS 不是密碼、私鑰、錢包助記詞或使用者機密。

CRS 通常是公開資訊，但其產生方式可能極為敏感。

若 CRS 以誠實方式產生，且秘密設定資料已銷毀，證明系統便能依預期運作。

若 CRS 以不誠實的方式產生，或秘密設定資料仍被保留，某些證明系統可能會讓人得以建立偽造證明。

因此，在許多加密貨幣使用的零知識系統中，CRS 安全性是最重要的信任假設之一。

CRS 為何在加密貨幣領域很重要？

CRS 很重要，因為零知識證明已成為區塊鏈隱私、擴容、身分識別及可驗證運算的核心技術。

零知識證明讓某人能證明一項陳述為真，而不必揭露該陳述背後的隱藏資料。

在加密貨幣領域，這可能代表證明一筆私密交易有效、證明一批鏈下交易已正確計算，或證明使用者符合某項規則而不必揭露全部個人資料。

許多高效率的 zk-SNARK 系統都需要先備妥公開參數，才能產生及驗證證明。

這些公開參數就是 CRS，或與 CRS 密切相關的結構，例如 Structured Reference String（結構化參考字串）。

ZKProof 對設定儀式的討論說明，zk-SNARK 會依賴 CRS 作為證明與驗證的公開參數。

因此，CRS 的品質對開發者與使用者都很重要。

開發者需要確認 CRS 是否符合電路、證明系統及安全模型。

使用者則需要了解協議依賴的是可信任設定、通用設定、可更新儀式，還是無須可信任設定的透明證明系統。

對加密貨幣投資人與交易者而言，CRS 聽起來可能相當技術性，但它會影響隱私幣、zk-rollup、跨鏈橋、證明系統及代幣化應用程式的可信度。

CRS 的運作方式

CRS 的運作方式是向證明系統中的所有參與者提供相同的公開參考資料。

證明者使用這些參考資料，將私密見證與公開陳述轉換成精簡證明。

驗證者則使用這些參考資料，檢查證明是否依照系統規則產生。

公開陳述是待驗證的主張。

私密見證則是讓該陳述成立的隱藏資訊。

例如，使用者可以證明某筆交易符合協議規則，而不揭露完整的私密交易細節。

CRS 協助證明系統連結數學陳述、私密見證及驗證演算法。

在許多 zk-SNARK 系統中，CRS 會在一般使用者開始產生證明前建立。

這項設定可能只適用於某一個電路，也可能採用足以支援多個電路的通用設定。

具體細節取決於證明系統、密碼學假設及實作設計。

CRS 的產生、儲存、發布及驗證方式應能降低遭到暗中操控的可能性。

CRS、SRS 與公開參數

CRS 常被用作廣義術語，指證明系統所使用的公開參考資料。

SRS 是 Structured Reference String（結構化參考字串）的縮寫，通常表示參考字串具有特殊的代數結構。

「公開參數」是更廣泛的說法，可能包括 CRS、SRS、證明金鑰、驗證金鑰及其他設定輸出。

在一般加密貨幣討論中，有時會將 CRS 與 SRS 當作同義詞使用。

在較技術性的文章中，SRS 通常是某些 SNARK 或多項式承諾方案使用的一種特定 CRS。

ZKDocs 的 KZG 多項式承諾指南介紹 KZG 承諾的預先產生公開參數，並指出這些參數有時稱為 Structured Reference String。

這項差異很重要，因為不同證明系統使用的設定資料不盡相同。

某些系統需要電路專屬 CRS。

某些系統則使用可支援多個電路、且具有指定容量上限的通用 SRS。

某些系統採用透明設計，完全不需要可信任設定儀式。

開發者應仔細確認專案所指的 CRS、SRS、設定參數、證明金鑰及驗證金鑰各代表什麼。

可信任設定與 CRS

可信任設定是部分零知識證明系統用來產生 CRS 的流程。

之所以稱為「可信任」，是因為參與者必須相信設定流程執行正確，而且任何秘密隨機資料都已銷毀。

這類隱藏的設定資料通常稱為 toxic waste（有毒廢料）。

若攻擊者取得仍未銷毀的有毒廢料，在某些系統中可能就能建立假證明。

這並不代表所有 CRS 都不安全。

這表示部分以 CRS 為基礎的系統，其安全性取決於設定流程是否安全。

可信任設定可以由單一方執行，但這會產生嚴重的信任問題。

現代系統通常偏好多方儀式，以減少對單一參與者的依賴。

在許多多方設定儀式中，只要至少一位誠實參與者提供隨機資料，並銷毀自己的秘密貢獻，系統便可能維持安全。

因此，公開儀式通常會盡量提高參與度、透明度、可重現性及獨立驗證能力。

對加密貨幣使用者來說，問題不只是 CRS 是否存在，還包括它是如何產生的。

多方計算儀式

多方計算儀式是一種設定流程，由多位獨立參與者提供隨機資料來產生 CRS。

其目標是避免將完整的設定秘密交由單一個人、公司、驗證者群體或開發團隊掌控。

每位參與者都會為儀式加入熵，接著銷毀自己的私密貢獻。

在許多儀式設計中，只要至少一位參與者誠實行事，最終 CRS 就能維持安全。

當證明系統需要可信任設定，但社群又希望降低對單一方的信任時，通常會採用這種模式。

Ethereum KZG 儀式是加密貨幣領域的知名公開儀式案例，用於產生 KZG 承諾的設定資料。

Ethereum Foundation 的 KZG 儀式總結將這項儀式描述為支援 EIP-4844 密碼學基礎的公開流程。

儀式應發布足夠資訊，讓其他人能稽核整個流程。

完善的儀式設計也會防範惡意貢獻、薄弱的隨機性、軟體遭入侵及集中協調風險。

完善的儀式無法讓系統毫無風險，但可以降低 CRS 背後的信任負擔。

CRS 與 zk-SNARK

zk-SNARK 是 Zero-Knowledge Succinct Non-Interactive Argument of Knowledge（零知識簡潔非互動式知識論證）的縮寫。

許多 zk-SNARK 系統驗證速度快、證明檔案小，因此適合用於區塊鏈。

證明檔案較小很重要，因為區塊鏈的儲存與驗證成本可能很高。

非互動式證明也很重要，因為證明者只需產生一次證明並發布，任何人之後都能驗證。

在許多 SNARK 建構方式中，CRS 有助於實現這種非互動模式。

若沒有正確的設定參數，證明者與驗證者可能無法共享產生及驗證證明所需的數學參考資料。

不同的 SNARK 類別對 CRS 的需求各不相同。

某些較早期的系統要求每個電路都分別進行可信任設定。

某些較新的系統採用通用或可更新設定模式。

另有一些證明系統透過不同的密碼學設計，減少或免除可信任設定的需求。

因此，加密貨幣專案不能只說自己使用 zk-SNARK 就不再提供說明。

專案應說明設定模式、CRS 類型、稽核流程及升級路徑。

CRS 與 zk-rollup

zk-rollup 是一種區塊鏈擴容系統，使用有效性證明來證明鏈下交易批次已正確處理。

ethereum.org 的 zk-rollup 文件說明，ZK-SNARK 協議可能需要 CRS，因為 CRS 為有效性證明的產生與驗證提供公開參數。

在 zk-rollup 中，證明者會一次為多筆交易產生證明。

基礎區塊鏈只需驗證證明，而不必重新執行該批次中的每一筆交易。

這可以減少基礎層所需的資料量與運算量。

若 rollup 使用以 CRS 為基礎的證明系統，CRS 就是該 rollup 信任與安全架構的一部分。

使用者應關注該 rollup 是否採用可信任設定、設定是否為電路專屬，以及未來升級是否需要進行新的儀式。

品質不佳或遭到入侵的 CRS 可能削弱有效性證明系統。

完善的設定流程有助於讓人相信 rollup 的證明難以偽造。

因此，CRS 設計並非純粹的學術議題，因為它可能影響擴容系統中的使用者資金。

CRS 與 KZG 承諾

KZG 承諾是一種多項式承諾方案，應用於現代區塊鏈擴容研究及部署。

多項式承諾讓一方可以對多項式作出承諾，之後再證明其中數值的相關主張，而不必揭露整個多項式。

這對資料可用性、rollup 擴容及證明系統都很實用，因為它能對大型資料結構進行精簡驗證。

EIP-4844 引入了攜帶 blob 的交易，並在 Ethereum 擴容路線圖中使用 KZG 承諾及 KZG 證明。

EIP-4844 規格介紹了 blob 交易，以及協議設計中的 KZG 證明驗證。

KZG 承諾依賴具結構的設定資料。

這些設定資料通常稱為 SRS，可視為一種專門形式的 CRS。

KZG 系統的安全性取決於設定過程中是否銷毀了某些秘密設定隨機資料。

這也是 KZG 儀式受到加密貨幣工程領域高度關注的原因。

KZG SRS 不只是技術檔案，因為它可能成為使用該資料的應用程式長期依賴的密碼學基礎。

通用 CRS 與電路專屬 CRS

電路專屬 CRS 是為某一個特定電路或運算產生的。

若電路有所變更，專案可能需要重新設定。

這可能造成不便，因為區塊鏈應用程式往往會隨時間升級。

通用 CRS 或通用 SRS 可支援多個電路，但會受到指定的規模或複雜度限制。

多個應用程式可以重複使用相同設定資料，因此開發流程可能更簡單。

可更新 CRS 允許新參與者在初始設定後繼續加入隨機資料。

由於設定可以持續納入新的貢獻，這種方式可能提升可信度。

通用及可更新設計變得重要，是因為它們能減少反覆舉辦可信任設定儀式的作業負擔。

不過，通用不代表不受限制。

通用 CRS 通常仍有適用範圍、假設、支援的橢圓曲線、電路最大規模及實作規則。

開發者仍須確認 CRS 是否適用於正在建置的應用程式。

透明證明系統與 CRS

透明證明系統不需要可信任設定儀式。

這類系統可能使用公開隨機資料、雜湊函數或其他避免使用秘密設定資料的建構方式。

zk-STARK 通常被描述為透明系統，因為它不像許多 zk-SNARK 那樣需要可信任設定 CRS。

這是 STARK 系統吸引部分區塊鏈應用程式的原因之一。

取捨在於，透明系統可能在證明大小、驗證成本、證明者成本或實作要求方面有所不同。

不需要可信任設定的系統，不代表在所有用途上都一定更好。

以 CRS 為基礎的 SNARK 可能提供更小的證明及更有效率的驗證。

透明證明系統則可能降低對設定的信任需求，但需要接受不同的效能取捨。

良好的協議設計會比較安全假設、成本、效能、開發工具、稽核品質及長期可維護性。

對使用者而言，重點很簡單：有些 ZK 系統需要 CRS，有些則設計成不需要可信任 CRS。

CRS 安全風險

CRS 最大的風險是設定遭到入侵。

若秘密設定資料未被銷毀，攻擊者在某些證明系統中可能得以偽造證明。

偽造證明的風險可能十分嚴重，因為區塊鏈可能會將錯誤證明視為有效。

在付款系統中，這可能威脅私密餘額規則或隱匿交易的有效性。

在 rollup 中，這可能威脅鏈下狀態轉換的正確性。

在跨鏈橋中，這可能影響存款、提領或跨鏈狀態相關主張的安全性。

另一項風險是對錯誤的電路或證明系統使用了不相符的 CRS。

CRS、電路、證明金鑰、驗證金鑰及實作之間不匹配，可能破壞安全性或導致證明失敗。

第三項風險是儀式透明度不足。

若使用者無法驗證 CRS 的產生方式，就只能相信專案團隊的說法。

第四項風險是設定期間的軟體安全管理不佳。

惡意軟體、有缺陷的隨機資料、隱藏後門或不安全的建置流程，都可能破壞儀式。

因此，CRS 安全性同時涉及密碼學問題與作業安全問題。

開發者如何使用 CRS

開發者在建置依賴證明產生及驗證的應用程式時會使用 CRS。

CRS 可能從可信任的版本下載、透過儀式產生、嵌入軟體，或由協議規格指定。

證明者軟體會使用設定資料，為某個電路產生有效證明。

驗證者軟體則使用相關驗證資料，有效率地檢查證明。

在智能合約系統中，驗證金鑰可能會放入鏈上驗證合約。

如此一來，區塊鏈便能驗證證明是否有效，而無須看到私密見證。

開發者必須確保 CRS 來自正確的儀式，並符合確切的證明系統版本。

他們也應檢查雜湊值、簽章、可重現建置、官方文件及稽核報告。

設定稍有不符，就可能導致驗證失敗、浪費 Gas 費、應用程式損壞或安全性下降。

因此，正式上線的 ZK 系統會將設定檔視為關鍵基礎設施。

CRS 與隱私幣

歷來，CRS 對使用 zk-SNARK 的隱私型加密貨幣系統十分重要。

隱私協議可以使用零知識證明，在不揭露敏感交易細節的情況下，證明隱匿交易有效。

早期高效率的 zk-SNARK 設計通常仰賴可信任設定儀式。

Zcash 是最知名的加密貨幣專案之一，曾將可信任設定及後續移除設定列為重要研究主題。

Zcash 對 zk-SNARK 的說明指出，Zcash 以 Halo 2 引入 Orchard 隱匿付款協議，並說明 Halo 移除了可信任設定，同時支援私密數位付款。

這段演進歷程顯示，CRS 設計會隨時間改變。

早期系統可能接受可信任設定，以取得小型證明及實用效能。

後續系統則可能轉向降低設定信任，或在協議關鍵部分移除設定需求的證明設計。

對使用者而言，重要的是評估隱私宣稱時，也要一併考量設定假設。

完善的隱私協議應說明隱藏哪些資訊，以及需要哪些信任假設。

CRS 與區塊鏈升級

區塊鏈升級可能帶來 CRS 方面的挑戰，因為新的電路或證明系統可能需要新的設定資料。

若協議變更交易規則、擴容設計或證明系統，舊 CRS 可能不再適用。

電路專屬設定可能需要為重大升級重新舉辦儀式。

通用設定可能提供更大的彈性，但仍有其限制。

協議團隊必須規劃設定變更的提案、稽核、執行、發布及啟用方式。

治理同樣重要，因為使用者需要確信升級不會暗中引入較弱的證明假設。

完善的升級流程應記錄舊設定、新設定、遷移風險及驗證方式的變更。

對去中心化系統而言，社群審查十分重要，因為 CRS 變更可能影響所有依賴證明有效性的使用者。

保障存款、提領、私密餘額或 rollup 狀態根的系統尤其如此。

因此，CRS 治理是加密貨幣長期安全的一環。

如何評估採用 CRS 的加密貨幣專案

第一個問題是：專案是否使用以 CRS 為基礎的證明系統？

第二個問題是：CRS 是由單一方產生，還是透過公開的多方儀式產生？

第三個問題是：設定屬於電路專屬、通用，還是可更新？

第四個問題是：儀式紀錄、軟體、參數及驗證說明是否公開？

第五個問題是：獨立研究人員或稽核人員是否審查過設定及證明系統？

第六個問題是：未來升級是否需要重新設定？

第七個問題是：使用者能否將參數雜湊值與官方版本比對驗證？

第八個問題是：專案是否說明設定遭入侵後的影響？

第九個問題是：若證明系統出現漏洞，是否有緊急應變計畫？

第十個問題是：該證明系統是否適合保障協議所涉及的價值？

這些問題有助於使用者超越行銷宣稱，評估實際的密碼學假設。

對 CRS 的常見誤解

一種常見誤解是 CRS 必須保密。

在多數證明系統中，CRS 是公開的；真正的風險來自設定時使用、且應被銷毀的秘密隨機資料。

另一種誤解是所有零知識系統都需要可信任設定。

有些證明系統採用透明設計，不需要可信任設定儀式。

第三種誤解是同一個 CRS 適用於所有應用程式。

CRS 可能與特定證明系統、橢圓曲線、電路規模或應用程式設計綁定。

第四種誤解是可信任設定必然不安全。

若至少有一份誠實貢獻不為攻擊者所知，設計完善的多方儀式便能降低信任需求。

第五種誤解是 CRS 只是開發者才需要關心的事，使用者無須了解。

實際上，CRS 可能影響隱私協議、rollup、跨鏈橋或以證明為基礎的應用程式是否安全。

常見問題

CRS 在加密貨幣領域代表什麼？

CRS 是 Common Reference String（共同參考字串）的縮寫，是部分零知識證明系統用來產生及驗證證明的公開參考資料。

CRS 和 SRS 相同嗎？

CRS 是較廣泛的術語，而 SRS 通常是部分 SNARK 及多項式承諾方案使用的一種結構化 CRS。

為什麼 zk-SNARK 需要 CRS？

許多 zk-SNARK 需要 CRS，讓證明者與驗證者能共享支援非互動式證明產生及驗證的公開參數。

CRS 是私密的嗎？

不是。CRS 通常是公開的，但在可信任設定系統中，用來產生 CRS 的秘密隨機資料必須銷毀。

可信任設定中的有毒廢料是什麼？

有毒廢料是秘密設定資料；在某些證明系統中，若攻擊者保留這些資料，就可能據此建立假證明。

什麼是 CRS 儀式？

CRS 儀式是由一位或多位參與者為證明系統產生公開參考字串的設定流程。

為什麼要舉辦多方儀式？

舉辦多方儀式是為了降低產生 CRS 時對單一可信任參與者的依賴。

zk-STARK 需要可信任 CRS 嗎？

zk-STARK 通常被視為透明證明系統，因為它不像許多 zk-SNARK 系統那樣需要可信任設定 CRS。

有問題的 CRS 會讓加密貨幣資金面臨風險嗎？

會。若協議接受偽造證明，且這些證明會影響餘額、提領、跨鏈橋主張或 rollup 狀態，遭入侵的 CRS 就可能造成危險。

使用者如何檢查 CRS 的信任假設？

使用者可以查看專案文件、儀式紀錄、參數雜湊值、稽核報告、證明系統細節及升級流程。

結論

CRS（共同參考字串）是零知識密碼學的基礎概念，也是現代加密貨幣系統的重要安全議題。

CRS 提供共享的公開參數，讓證明者能產生證明，驗證者則能檢查證明。

在許多 zk-SNARK 系統中，CRS 透過可信任設定產生，因此設定流程必須具備嚴謹的安全措施與透明度。

若秘密設定資料已銷毀，且儀式設計完善，以 CRS 為基礎的系統便能支援高效率、精簡的證明驗證。

若秘密設定資料遭到入侵，部分系統可能面臨證明遭偽造的風險。

因此，CRS 設計會影響隱私協議、zk-rollup、KZG 承諾、跨鏈橋、身分系統及其他以證明為基礎的加密貨幣應用程式。

重點是，CRS 通常是公開的，但必須了解其產生過程背後的信任假設。

評估零知識加密貨幣專案時，應了解 CRS 如何產生、設定採用可信任或透明模式、設定是通用還是電路專屬，以及未來升級如何處理證明參數。