帶你走進零知識證明
一、零知識證明起源
“零知識”的概念最早在80年代由麻省理工學院的研究人員Shafi Goldwasser,Silvio Micali和Charles Rackoff所提出。當時這些人正在研究與互動證明系統相關的問題——即一種理論系統,使得甲方(證明者)可以和乙方(驗證者)交換資訊,並藉此說服乙方接受(透過驗證)某個數學論述為真 。
在Goldwasser等人之前,這個領域的研究工作主要聚焦在加強證明系統的可靠性(Soundness)。也就是說原先大家都假設,會有惡意的證明者試圖耍手段,誤導驗證者接受錯誤的論述。但Goldwasser等人卻從另一個角度思考了這個問題:如果我們壓根就不相信驗證者,該怎麼辦?
更具體的來說,他們更關心資訊洩露的問題。他們丟擲了這樣的思考:“在驗證者的驗證過程中,究竟會獲取多少單純驗證論述真假無需知道的額外資訊。”
這裡要強調一下,這個問題不是單純的理論思考,而是在真實、具體的應用中,會面到臨的問題。
我們舉個例子,假設今天在真實世界有個客戶端想要使用密碼登入web伺服器,在“真實世界”的標準操作流程中,包含將密碼以雜湊形式儲存在客戶端。我們可以將“登入”這個動作視作某種證明——也就是我們要能夠提供一串輸入,這串輸入經過雜湊運算後的值與密碼的雜湊相同(因為雜湊運算的單向性,這串輸入只能是我們的密碼)。但這有個問題是:客戶端實際上知道我們的密碼。
大多數系統以這種絕對最糟糕的方式進行“證明”——客戶端直接將原始密碼傳送給伺服器,伺服器重新計算密碼雜湊並將其與儲存值進行比較。這裡的問題很明顯:在協議結束時,伺服器已經取得我們的明文密碼。因此,保障現代密碼安全很大程度上要祈禱伺服器不會遭受攻擊。
Goldwasser,Micali和Rackoff等人提出了一種全新的方法來完成“證明”。如果零知識證明真的可行,它將允許我們在證明某些數學陳述為真的同時,保證不會有任何不相關的資訊被透露出去。
二、零知識證明理解
通俗的來講,零知識證明就是我讓你相信我說的一句話或一個結論而不需要向你透露任何有關該結論的有用資訊.舉個簡單的例子,比如說凡爾賽文學,我可以再不向你透露我有多少資產的前提下讓你相信我非常有錢,畢竟財產總數是我的私人資訊,我不想告訴任何人。
下面透過三個小故事簡單的進行對零知識證明的理解:
①阿里巴巴與四十大盜
有一天,阿里巴巴被強盜抓住了,強盜向他索要開啟山洞大門的咒語。
但此時阿里巴巴面臨一個兩難的問題,如果把密碼告訴強盜,自己就沒有利用價值了,最後肯定會被殺。
如果不告訴強盜咒語,強盜以為自己不知道咒語,自己還是會被殺。
怎麼能做到讓他們相信自己確實知道咒語,但是還不能讓他們知道咒語是什麼。
這確實是一個很難的問題,但是阿里巴巴想出了一個好辦法。
他對強盜頭領提議說,你們離我30米遠,然後用弓箭指著我,當你舉起雙手後,我就唸咒語開啟山洞大門;當你把雙手放下後,我就唸咒語關上山洞大門,如果我要是逃跑,你們就用弓箭射死我。
對於強盜頭領來說,這顯然是個好主意,於是照辦。
強盜頭領先是舉起雙手,看到阿里巴巴動了動嘴皮子,門就開了,然後放下雙手,阿里巴巴又動了動嘴皮子,門就關了。
顯然,強盜相信了阿里巴巴。
這樣,阿里巴巴在沒有告訴強盜頭領開門咒語的情況下,又向強盜證明了,自己是知道開門咒語的。
②地圖著色問題
如何用三種顏色染色一個地圖,保證任意兩個相鄰的地區都是不同的顏色。我們把這個「地圖三染色問題」轉變成一個「連通圖的頂點三染色問題」。假設每個地區都有一個首府(節點),然後把相鄰的節點連線起來,這樣地圖染色問題可以變成一個連通圖的頂點染色問題。
下面我們設計一個互動協議:
-
「證明者」Alice
-
「驗證者」 Bob
Alice手裡有一個地圖三染色的答案,總共有6個頂點,9條邊。
現在Alice想證明給Bob她有答案,但是又不想讓Bob知道這個答案。Alice要怎麼做呢?
Alice先要對染過色的圖進行一些「變換」,把顏色做一次大挪移,例如把所有的綠色變成橙色,把所有的藍色變成綠色,把所有的綠色變成橙色。然後Alice得到了一個新的染色答案,這時候她把新的圖的每一個頂點都用紙片蓋上,然後出示給Bob看。
看下圖,這時候 Bob 要出手了(請見下圖),他要隨機挑選一條「邊」,注意是隨機,不讓 Alice 提前預測到的隨機數。
假設 Bob 挑選的是最下面的一條邊,然後告訴Alice。
這時候Alice揭開這條邊兩端的紙片,讓Bob檢查,Bob發現這兩個頂點的顏色是不同的,那麼Bob認為這次檢驗同構。 這時候,Bob只看到了圖的區域性,能被說服剩下的圖頂點的染色都沒問題嗎? 你肯定覺得這遠遠不夠,也許恰好Alice蒙對了呢? 其它沒暴露的頂點可能是胡亂染色的。
沒關係,Bob可以要求Alice再來一遍,看下圖
Alice再次把顏色做一次變換,把藍色改成紫色,改綠色改成棕色,把橙色改成灰色,然後把所有的頂點蓋上紙片。 然後Bob再挑選一條邊,比如像上圖一樣,選擇的是一條豎著的邊,然後讓Alice揭開紙片看看,如果這時候Bob再次發現這條邊兩端的頂點顏色不同,那麼Bob這時候已經有點動搖了,可能Alice真的有這個染色答案。 可是,兩次仍然不夠,Bob還想再多來幾遍。
那麼經過反覆多次重複這三個步驟,可以讓Alice作弊並能成功騙過Bob的機率會以指數級的方式減小。假設經過n輪之後,Alice作弊的機率為
這裡|E|是圖中所有邊的個數, 如果n足夠大,這個機率Pr會變得非常非常小,變得「微不足道」。
可是,Bob每次看到的區域性染色 情況都是Alice變換過後的結果,無論Bob看多少次,都不能拼出一個完整的三染色答案出來。實際上,Bob在這個過程中,雖然獲得了很多「資訊」,但是卻沒有獲得真正的「知識」。
③比特幣隱私交易場景
在比特幣網路中,使用者需要將交易明文廣播給所有礦工,由他們來校驗交易的合法性。但是有些情況下,基於隱私的考慮,又不想把交易的具體內容公佈出來。這就形成了一對矛盾。
解決這個矛盾的關鍵思路是:校驗一個事件正確與否,並不需要驗證者重現整個事件。
比如,驗收一款軟體,通常只要看最終測試結果是否透過即可,並不需要把整個軟體開發過程的每一個細節都重放一遍。對於比特幣的例子,一筆轉帳交易合法與否,其實只要證明三件事:
-
傳送的錢屬於傳送交易的人
-
傳送者傳送的金額等於接收者收到金額
-
傳送者的錢確實被銷燬了
整個證明過程中,礦工其實並不關心具體花掉了多少錢,傳送者具體是誰,接受者具體是誰。礦工只關心繫統的錢是不是守恆的。
zcash就是用這個思路實現了隱私交易。
三、零知識證明原理
零知識證明過程有兩個參與方,一方叫證明者,一方叫驗證者。證明者掌握著某個秘密,他想讓驗證者相信他掌握著秘密,但是又不想洩漏這個秘密給驗證者。雙方按照一個協議,透過一系列互動,最終驗證者會得出一個明確的結論,證明者是或不掌握這個秘密。
零知識證明原理詳解見物質實驗室github倉庫(不同演算法採用的實現原理有部分割槽別)
倉庫連結:
這裡主要介紹一下三種典型的零知識證明技術:
zk-SNARKs, Zk-STARKs和BulletProofs。
(1) Bulletproofs和Zk-STARKs不需要可信設定,zk-SNARKs則需要可信設定;
zk-STARKs:透過證明者與驗證者之間的互動來執行,以一種有效的數學方法,使得驗證者透過驗證每一個步驟,最終確信證明者確實知道某個資訊或者擁有某種權益。其特點是:證明快、驗證快,但證明體積大。
SNARK指無需雙方互動,證明人單方出具即可,不需要反覆在雙方之間傳遞資訊。其特點是:證明慢、驗證快,證明體積小。
(2)證明速度對比:
zk-STARKs>zk-SNARKs>Bulletproofs
(3)檔案大小:
zk-SNARKs<Bulletproofs<Zk-STARKs
3種技術的對比圖,可以明晰3個技術的區別:
下圖來源物質實驗室,是對三種技術的進一步對比,相對來說SNARKs發展時間更長,積累的資料更多,更易學習,所以後文所述內容以SNARKs為主。
四、零知識證明應用
零知識證明可以解決的問題
-
零知識證明技術可以解決資料的信任問題,計算的信任問題。
-
零知識證明技術可以「模擬」出一個第三方,來保證某一個論斷是可信的。
零知識證明應用
-
資料的隱私保護:在一個資料表格中,多多少少都有一些資訊不想被暴露,比如當年我的成績單,我只想向人證明,我的成績及格了,但是我不想讓別人知道我到底考了61分還是62分,這會很尷尬。我沒有心臟病,但是保險公司需要了解這一點,但是我不想讓保險公司知道我的隱私資訊。那我可以證明給保險公司看,我沒有心臟病,但是病歷的全部並不需要暴露。我是一家企業,我想向銀行貸款,我只想向銀行證明我具備健康的業務與還款能力,但是我不想讓銀行知道我們的一些商業秘密。
-
計算壓縮與區塊鏈擴容:在眾多的區塊鏈擴容技術中,Vitalik採用 zkSNARK技術能夠給現有的以太坊框架帶來幾十倍的效能提升。因為有了計算的證明,同樣一個計算就沒必要重複多次了,在傳統的區塊鏈架構中,同樣的計算被重複多次,比如簽名的校驗,交易合法性校驗,智慧合約的執行等等。這些計算過程都可以被零知識證明技術進行壓縮。
-
端到端的通訊加密:使用者之間可以互相發訊息,但是不用擔心伺服器拿到所有的訊息記錄,同時訊息也可以按照伺服器的要求,出示相應的零知識證明,比如訊息的來源、與傳送的目的地。
-
身份認證:使用者可以向網站證明,他擁有私鑰,或者知道某個只要使用者自己才知道的秘密答案,而網站並不需要知道,但是網站可以透過驗證這個零知識證明, 從而確認使用者的身份
-
去中心化儲存:伺服器可以向使用者證明他們的資料被妥善儲存,並且不洩露資料的任何內容。
-
信用記錄:信用記錄是另一個可以充分發揮零知識證明優勢的領域,使用者可以有選擇性的向另一方出示自己的信用記錄,一方面可以有選擇的出示滿足對方要求的記錄分數,同時證明信用記錄的真實性。
-
構造完全公平的線上數字化商品的交易協議。
-
更多的例子,可以是任何形式的資料共享,資料處理與資料傳輸。
零知識證明例項
(目前本人對這幾個專案的研究還尚淺,這裡先完全引用前人栽的樹,後續有所研究再來補充)
第一個場景:ZCash專案
Zcash專案,大家都知道是“隱私交易”。Zcash代表了zkSNARK的一個應用方向:隱私。隱私有不同的程度,ZCash的隱私交易指的是隱藏交易的傳送方,接收方以及交易金額。Zcash已經經歷過三個版本:Sprout,Overwinter,Sapling。這三個版本本質上都沒有太大的變化,只是支援的功能更多,生成證明更快,體驗更好。
一筆轉賬用Note來表示,包括轉賬的金額v和一個隨機數。 Note有兩個外在的表現形式: 一個是Commitment,一個是Nullifier。 Commitment和Nullifier都是透過不同的Hash函式生成。 Commitment代表一次金額轉入,Nullifier代表一次消費。 注意,對於一個Note,Commitment和Nullifier都是唯一的。 因為Commitment和Nullifier是Hash的結果,即使這兩個資料公開,其他人也無法推斷出Commitment和Nullifier之間存在聯絡。 也就是說,提供一個Commitment,能說明進行了一筆轉賬(具體資訊其他人未知)。 能提供對應的Nullifier,就能消費。 區塊鏈,作為一個隱私轉賬平臺,將所有的Commitment(cm),組成一個Merkle樹:
某個使用者需要消費某個cm,必須向區塊鏈提供零知識證明:
①他知道一個Note,並能生成一個cm,而且這個cm在以rt為樹根的Merkle樹上
②用同樣的Note資訊,能生成一個nullfier,而且這個nullfier之前沒有生成過。
以上只是最簡單的概括Zcash零知識證明的大體思路,ZCash的設計非常複雜和嚴謹,有很多細節。順便說一句,理解ZCash,只需要看ZCash的白皮書protocol.pdf。理解了白皮書的設計,看原始碼非常直接。這就是零知識證明的一個重要的運用方向-隱私,現實中還有很多應用類似技術的專案:EYBlockchain(EY,安永),Quorum(JPMorgan)。
第二個場景:Filecoin專案
Filecoin是儲存行業比較熱門的專案。Filecoin想搭建一個去中心化的儲存交易平臺。去中心化的儲存,有個核心問題,怎麼證明儲存提供方,真實有效的儲存了指定的資料。Filecoin是透過PoREP以及PoST演算法實現的(其中就包括零知識證明)。PoREP是資料儲存證明演算法(證明使用者資料被正確的處理)。PoRep演算法的全稱是ZigZag-DRG-PoRep。
Sector中未Seal的原始資料首先依次分成一個個小資料,每個小資料32個位元組。 這些小資料之間按照DRG(Depth Robust Graph)建立連線關係。 按照每個小資料的依賴關係,透過VDE(Verifiable Delay Encode)函式,計算出下一層的所有小資料。 整個PoRep的計算過程分為若干層(目前程式碼設定為4層),仔細觀察每一層的DRG關係的箭頭方向,上一層向右,下一層就向左,因此得名ZigZag(Z字型)。
每一層的輸入稱為d(data),每一層的VDE的結果稱為r(replica)。 對每一層的輸入,建構默克爾樹,樹根為comm_d, 整個樹的資料結構稱為tree_d。 對每一層的輸出,建構默克爾樹,樹根為comm_r,整個樹的資料結構稱為tree_r。 簡單的說,PoREP透過零知識證明,證明每一層的資料都經過VDE計算生成,並提供最後結果的Merkle樹的樹根。 在資料處理並儲存後,每隔一段時間,需要提交存在性證明,也就是PoST演算法。 PoST演算法的基本思想,隨機挑選一個Merkle樹的葉子節點位置,需要提供出一條Merkle路徑的零知識證明。
這個零知識證明的第二個應用方向:鏈上資料壓縮。PoREP演算法,透過零知識證明證明資料已經正確處理,並提供了處理後資料形成的Merkle樹的樹根。PoST,每隔一段時間,隨機抽選一個葉子資料,需要儲存提供者在一定的時間內提供從該葉子資料到Merkle樹根的路徑證明。如果,處理完的資料沒有儲存在一個可靠的儲存上,無法在合理的時間內重建整個Merkle樹,也就無法提供證明。
第三個場景:Loopring DEX 3.0專案
從2017年,路印從“環路撮合”的最初設計,經過了1.0,2.0以及3.0的三個大的版本的協議升級。1.0/2.0,相對來說,受限以太坊本身效能的限制,交易流程複雜,體驗和中心化交易所相比,有較大的差距。路印協議3.0,透過零知識證明技術(ZKP),在zk Rollup的基礎上,結合DEX的業務場景開發設計,兼顧去中心化和交易效能。
相對1.0,2.0來說,路印協議3.0採用零知識證明(ZKP)技術,將所有的撮合邏輯都在鏈下完成。每一筆撮合(Settlement)都會生成證明並提交到鏈上,證明鏈下的撮合正確無誤。路印協議採用和以太一致的“賬戶”模型,所有的賬戶的“狀態”(餘額)都記錄在鏈下。所有和狀態相關的操作,都是在鏈下更改,提交Proof到鏈上記錄。因為存在鏈上鍊下的狀態同步,賬戶的任何操作有三個狀態:
1. Committed (操作已經提交)
2. Verified (該操作已經提供了相應的Proof)
3. Finalized(之前的所有的操作都已經提交正確的Proof)
以使用者Deposit“充值”的操作為例:
使用者轉賬到路印協議的智慧合約,轉賬在鏈上確認(鏈上完成充值)。 該操作的狀態就是“Committed”。 鏈下的Relay,監測到“Committed”的狀態後,更改鏈下的狀態,生成Proof,並將證明提交到鏈上,此時該“充值”操作的狀態為“Verified” - 鏈下也已經完成充值。 如果之前的所有操作都是Verified,那該操作的狀態就是Finalized(也就是這個狀態是確定的,不會被篡改的)。
鏈下的狀態用三層的四叉Merkle樹來表示:
Account是一層,Balance是一層,Trade History是一層。 這幾層一起組成了整個賬戶鏈下的狀態。
路印3.0,採用的是zkSNARK的Groth16演算法提供零知識證明。針對每種操作,Relay都會提供對應的ZKP證明電路。以鏈下撮合為例,相應的電路證明的邏輯如下:
假 設Account X鏈下轉賬給Account Y。 ZKP證明電路,包括:
1. TradeHistory中Order Ox的變化導致TraderHistory的樹根的變化
2. TradeHistory中Order Oy的變化導致TraderHistory的樹根的變化
3. Balance Bx變化導致Balance的樹根的變化
4. Balance By變化導致Balance的樹根的變化
5. 兩個賬戶的Balance的變化一致
6. Account X和Account Y賬戶的變化導致的Account樹根的變化
這個是零知識證明的第三個方向:擴充套件性。在足夠多的交易的情況下,路印3.0的TPS在目前的以太坊上達到了350。在君士坦丁堡升級後,TPS能達到1400。每筆交易平均下來的費用大約在1美分。
其他還有一些有意思的專案:
Coda(零知識遞迴證明)
Mixer(混幣)
zkPOD(透過零知識證明實現通用資料的交易)
五、零知識證明開源倉庫及介紹
下面介紹幾個熱度比較高的零知識證明實現倉庫及其原始碼分析文章,很多的零知識專案都是基於這幾個倉庫的程式碼做的。
libsnark
libsnark是實現一個C++版本的零知識證明庫。
倉庫連結:
原始碼分析:
https://mp.weixin.qq.com/s/UHqpfl6ImVwa4HtsiksqJA
實戰:
bellman
bellman是Zcash團隊用Rust語言開發的一個zk-SNARK軟體庫,實現了Groth16演算法。
倉庫連結:
原始碼分析:
https://mp.weixin.qq.com/s/NvX11tNSEpV1DR-3PwpIAQ
snarkjs
snarkjs是實現一個javascript版本的零知識證明庫,實現了Groth16。
倉庫連結:
六、zkSNARK安全問題
-
zkSNARK合約「輸入假名」漏洞致眾多混幣專案爆雷
-
硬核!360高階安全專家彭峙釀以Zcash為例,談零知識性證明的安全和隱私問題
-
如何利用Groth16的漏洞偽造證明
版權宣告:本文為CSDN博主「KAZIMIYA」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處連結及本宣告。
原文連結:
https://blog.csdn.net/qq_40392981/article/details/123041409
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70012206/viewspace-2933130/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 初識零知識證明
- 帶你走進Choerodon豬齒魚的知識管理
- CSS基本知識點——帶你走進CSS的新世界CSS
- [譯]零知識證明: an illustrated primer
- 從零認識webpack4.0,帶你走進神祕的webpackWeb
- 帶你走進 RedisRedis
- 什麼是零知識證明 (Zero Knowledge Proof)?
- 零知識證明的最新發展和應用
- 零知識證明: Tornado Cash 專案學習
- 零知識證明初見
- 帶你走進Java集合之ArrayListJava
- 帶你走進Java集合之HashMapJavaHashMap
- 帶你走進CSS定位詳解CSS
- 詳細講解:零知識證明 之 zk-SNARK 開篇
- 零知識證明在隱私保護和身份驗證中的應用
- 帶你走進Java集合之ConcurrentHashMapJavaHashMap
- 詳細講解:零知識證明 之 ZCash 完整的匿名交易流程
- 零知識證明與同態加密:隱私計算的雙劍加密
- 區塊鏈交易隱私如何保證?華為零知識證明技術實戰解析區塊鏈
- APISpace 帶你一起走進西湖美景API
- 一張圖帶你走進Retrofit原始碼世界原始碼
- Miox帶你走進動態路由的世界路由
- 【重構前端知識體系之HTML】2022,你還會來看HTML嗎?帶你重溫亦或走進!前端HTML
- css零星進階知識點CSS
- 【隱私計算筆談】MPC系列專題(六):零知識證明和位元承諾
- 帶你走進神一樣的Elasticsearch索引機制Elasticsearch索引
- 帶你走進MySQL全新高可用解決方案-MGRMySql
- 手把手帶你走進Babel的編譯世界Babel編譯
- 帶你走進webpack世界,成為webpack頭號玩家。Web
- 六個學習方法帶你走進學習狀態
- 一文帶你走進 Linux 小工具 - tmuxLinux
- 視覺化,帶你走進“真實”的虛擬世界視覺化虛擬世界
- 帶你走進memcache,老牌記憶體快取技術記憶體快取
- 帶你走進SAP專案實施過程——前言(0)
- Google Glass帶你走進可穿戴式智慧裝置時代Go
- 帶你走進Oracle資料安全的世界一觀(轉)Oracle
- 實在智慧RPA帶你走進企業數字化
- 帶你走進SAP專案實施過程——立項(1)