什麼是零知識證明？

     證明者在不洩露任何有效知識的情況下，驗證者可以驗證某個論斷是正確的。圖1給出一個有趣的例子， Alice 把自己的簽名的信封放到一個保險箱中， Bob 說他知道這個保險箱的密碼， Alice 讓 Bob 證明給她看。 Bob 開啟保險箱，把信封拿出來給 Alice 。 Alice 驗證信封上的簽名，確認了 Bob 確實知道這個密碼。這個例子就是 Bob 沒有告訴 Alice 密碼卻證明自己知道密碼的的過程很好的解釋了零知識證明的概念。基於非對稱加密和數字簽名的證書認證過程，其實也是一個零知識證明的過程，驗證者並不需要知曉 CA 證書，就可以驗證對方是由 CA 簽發的下一級證書。零知識證明技術不管應用於金融還是其他領域，都可以對隱私保護，效能提升，或者安全性等場景帶來很多幫助。下面，主要從隱私維度來分享華為零知識證明相關技術。

 

                   圖1 零知識證明

零知識證明應用於同態加密保護交易隱私，使能金融業務

     目前金融轉賬交易場景中對於隱私保護已經越來越重視，隱私也成為區塊鏈急需解決的一個重要問題。那基於如下問題 , A 向 B 轉賬 10 元，需要區塊鏈節點記賬，但是不想讓區塊鏈節點知道交易金額以及最新餘額，也是金融場景中一個非常常見的問題。

 

 

                       圖2同態加密

 

    基於這種場景如何解決區塊鏈技術應用於金融的隱私和可用性？華為目前引入同態加密 ( 解決隱私問題 ) 。同態加密（英語： Homomorphic encryption ）是一種加密形式，它允許人們對密文進行特定形式的代數運算得到仍然是加密的結果，將其解密所得到的結果與對明文進行同樣的運算結果一樣。 換言之，這項技術令人們可以在加密的資料中進行諸如檢索、比較等操作，得出正確的結果，而在整個處理過程中無需對資料進行解密。在此基礎上創新式提出了 同態加密範圍證明 ( 一種針對數字的零知識證明技術，在不洩露具體數字值的情況下，獲得數字的範圍，從而驗證數字所代表的交易的有效性 ) 。

    基於整合到區塊鏈系統中的同態加密庫以及修改同態加密庫實現的零知識證明能力實現了隱私轉賬的能力，一個密文和另一個密文相加或相乘實現轉賬中的密文交易，零知識證明在整個的計算過程中不暴露任一方的資訊證明對方可以完成轉賬這一流程，在不洩露具體數字的情況下得到數字的範圍。從而驗證數字所代表交易的有效性。

使用同態加密庫的app端sample程式碼示例

    下面我們看一下零知識證明在程式碼中是如何應用的， Demo 程式碼使用地址： https://support.huaweicloud.com/devg-bcs/bcs_devg_0020.html 。下面講解的程式碼都可以在上面的地址中下載全量程式碼檢視。

func   transaction ()   error   {

        addrA :=   calcAddr ( userdata . PubKey )

setup :=   & sdk_client . BaseSetupImpl {

ConfigFile :       conf ,

ChannelID :        channelid ,

OrgID :            orgid ,

ConnectEventHub :   false ,

ChainCodeID :      idchaincode ,

}

if  err :=  setup . Initialize ();  err !=   nil   {

fmt . Println ( "fail to init sdk: " ,  err . Error ())

return  errors . New ( "fail to init sdk: "   +  err . Error ())

}

 

        setup . ChainCodeID =  txchaincode

transRec :=  sdk_client . TransRecord {}

 

resps ,  err :=  sdk_client . Query ( setup ,   "QueryBalance" ,   [][] byte {[] byte ( addrA )})

if  err !=   nil   {

fmt . Println ( "Fail to query balance of sender: " ,  err . Error ())

return  err

}

 

err =  json . Unmarshal ( resps [ 0 ]. ProposalResponse . GetResponse (). Payload ,   & transRec )

if  err !=   nil   {

fmt . Println ( "fail to unmarshal balance result: " ,  err . Error ())

return  err

}

        var  pubKeyB string

 

setup . ChainCodeID =  idchaincode

 

resps ,  err =  sdk_client . Query ( setup ,   "QueryPubkey" ,   [][] byte {[] byte ( addrB )})

 

if  err !=   nil   {

fmt . Println ( "Fail to query pubkey of receiver: " ,  err . Error ())

return  errors . New ( "Fail to query pubkey of receiver: "   +  err . Error ())

}

 

pubKeyB =   string ( resps [ 0 ]. ProposalResponse . GetResponse (). Payload )

fmt . Println ( "Get B's ID successfully" )

 

cipherBalanceAKeyA :=  transRec . Balance

txInfoSer ,  err :=  pswapi_sdk . PrepareTxInfo ( cipherBalanceAKeyA ,  tx ,  userdata . PubKey ,  pubKeyB ,  userdata . PriKey ,  propwd )

if  err !=   nil   {

fmt . Println ( "fail to prepare tx info: " ,  err . Error ())

return  errors . New ( "fail to prepare tx info: "   +  err . Error ())

}

 

setup . ChainCodeID =  txchaincode

_ ,  err =  sdk_client . Invoke ( setup ,   "Transfer" ,   [][] byte {[] byte ( addrA ),   [] byte ( addrB ),   [] byte ( txInfoSer )})

 

if  err !=   nil   {

fmt . Println ( "Invoke Transfer error for user: " ,  addrA ,  err . Error ())

return  errors . New ( "Invoke Transfer error for user: "   +  addrA +  err . Error ())

}

 

return   nil }

                圖 3 同態加密業務程式碼

圖3是同態加密的實現業務程式碼，首先寫一個transaction的方法，返回值是error。第一步需要進行初始化獲取sdk_client物件也就是setup變數。然後透過sdk_client.Querry方法基於key“QueryBalance“查詢賬戶A的加密餘額,同樣的方法基於key "QueryPubkey"拿到b的公鑰。第二步PrepareTxInfo方法構建A向B的轉賬資訊，最後一步透過invoke呼叫完成A到B的轉賬的過程。

func   ( t * TransChaincodeDemo )   transfer ( stub shim . ChaincodeStubInterface ,  args [] string )  pb . Response {

   AddrA :=  args [ 0 ]

   AddrB :=  args [ 1 ]

   txInfo :=  args [ 2 ]

    if  strings . Compare ( AddrA ,  AddrB )   ==   0   {

      logger . Error ( "A' addr is the same B'Addr" )

       return  shim . Error ( "A' addr is the same B'Addr" )

    }

 

   transRecA ,  err :=  stub . GetState ( AddrA )

    if  err !=  nil {

       return  shim . Error ( "Failed to get state" )

    }

    if  transRecA ==  nil {

       return  shim . Error ( "Entity not found" )

    }

 

    var  transRecAStruct =  TransRecord {}

   err =  json . Unmarshal ( transRecA ,   & transRecAStruct )

    if  err !=  nil {

      logger . Error ( "fail to unmarshal user's trans record" )

       return  shim . Error ( "fail to unmarshal user's trans record" )

    }

 

   transRecB ,  err :=  stub . GetState ( AddrB )

    if  err !=  nil {

       return  shim . Error ( "Failed to get state" )

    }

    if  transRecA ==  nil {

       return  shim . Error ( "Entity not found" )

    }

 

    var  transRecBStruct =  TransRecord {}

   err =  json . Unmarshal ( transRecB ,   & transRecBStruct )

    if  err !=  nil {

      logger . Error ( "fail to unmarshal user's trans record" )

       return  shim . Error ( "fail to unmarshal user's trans record" )

    }

 

   cipherBalanceAKeyABlock :=  transRecAStruct . Balance

   cipherBalanceBKeyBBlock :=  transRecBStruct . Balance

 

   newCipherBalanceA ,  newCipherBalanceB ,  newCipherTxA ,  newCipherTxB ,  err :=  pswapi_cc . ValidateTxInfo ( txInfo ,  cipherBalanceAKeyABlock ,  cipherBalanceBKeyBBlock )

    if  err !=  nil {

      logger . Error ( "fail to validate trans information" )

       return  shim . Error ( "fail to validate trans information" )

    }

 

   transRecAStruct . Balance =  newCipherBalanceA

   transRecAStruct . TX   =  newCipherTxA

   transRecAStruct . TXType =   "P"

 

   AvalbytesUpdate ,  err :=  json . Marshal ( transRecAStruct )

    if  err !=  nil {

      logger . Error ( "fail to marshal balance update info" )

       return  shim . Error ( "Marshal Error" )

    }

 

   err =  stub . PutState ( AddrA ,  AvalbytesUpdate )

    if  err !=  nil {

      logger . Error ( "fail to store state: " ,  err . Error ())

       return  shim . Error ( err . Error ())

    }

 

   transRecBStruct . Balance =  newCipherBalanceB

   transRecBStruct . TX   =  newCipherTxB

   transRecBStruct . TXType =   "R"

   BvalbytesUpdate ,  err :=  json . Marshal ( transRecBStruct )

    if  err !=  nil {

      logger . Error ( "fail to marshal balance update info" )

       return  shim . Error ( "Marshal Error" )

    }

 

   err =  stub . PutState ( AddrB ,  BvalbytesUpdate )

    if  err !=  nil {

       return  shim . Error ( err . Error ())

    }

 

    return  shim . Success ([] byte ( "Success" ))}

圖4同態加密鏈程式碼

     圖 4 是同態加密核心的transfer 鏈程式碼，在這個方法中首先透過 getstate 獲取 A 和 B 兩個賬戶的當前餘額，然後最重要的一步，是驗證他的餘額，在方法 validatetxinfo中會 基於範圍 / 等式證明驗證交易資料的合規性，基於同態加密演算法計算交易後的賬戶餘額，最後更新交易後 A 賬戶和 B 賬戶的餘額。同態加密的這一步中，應用了零知識證明的相關的技術和能力來促進同態加密更加高效和安全。

基於zksnark的零知識證明技術

互動式證明和非互動式證明

 

圖 5 互動式證明

    零知識證明又分為互動式證明和非互動式證明，有兩個有趣的例子很好的解釋了這個概念。如上圖 5 所示，男子向女子聲稱有 CD 處的鑰匙，女子不相信說 “你拿出來給我看啊”，男子想“你讓我拿我就拿多沒面子啊”，男子說”這樣吧，按下面步驟玩個遊戲”

1. 女子站在 A 點

2. 男子從 B 點走到 C 點或者 D 點

3. 男子從 B 點消失後，女子從 A 點走到 B 點

4. 女子喊話 “從左邊出來”，或者“從右邊出來”

5. 男子按照女子的要求從對應一側走出

女子說 “你肯定作弊，剛才我喊左邊出來，你剛好就是從左邊進去的”，

男子說： “你回到 A 點，我們再來一遍 ”

如果每次都成功，說明 B 確實有 CD 處的鑰匙，該證明是需要 A ， B 不停的互動。

    非互動式零知識（ NizK ）證明方案由演算法設定、證明和驗證定義，具體來說，我們有 params=Setup() ，其中輸入是安全引數，輸出是 ZKP 演算法系統的引數。證明語法由證明 = 證明（ x,w ）給出。該演算法接收某些 NP 語言 L 的例項 x 和見證 w 作為輸入，並輸出零知識證明。驗證演算法接收證明作為輸入，並輸出位 b ，如果驗證者接受證明，則該位等於 1 。通俗一點就比如說我有一個秘密，我不想告訴別人，但是我又得讓別人相信。我是知道這個秘密的，類似於這種，但是我們為什麼需要有這種非互動式呢？因為互動式證明的其實只對原始的驗證者有效，其他的任何人都不能夠信任這個證明。這種場景下呢，就會導致這個驗證者可以和這個證明人串通，證明人可以偽造證明。驗證者也可以用這種方式做一些偽造。因此，驗證者必須儲存一些資料，直到相關的證明被驗證完畢。這樣就會造成一些秘密引數洩露的這種風險。這種互動式證明也有它的用處，就比如說一個證明人只想讓一個特定的驗證者來去驗證，但是這個證證明人和驗證者必須保持線上，並且去對每一個驗證者執行同樣的計算。

什麼是zk-snark？

   zk-SNARK 是 Zero-knowledge succinct non-interactive arguments of knowledge 的縮寫，他的意思是： zero knowledge ：零知識，即在證明的過程中不透露任何隱私資料： succinct ：簡潔的，主要是指驗證過程不涉及大量資料傳輸以及驗證算 法簡單； non-interactive ：無互動。證明者與驗證者之間不需要互動即可實現證 明，互動的零知識證明要求每個驗證者都要向證明者傳送資料來完成證明， 而無互動的零知識證明，證明者只需要計算一次產生一個 proof ，所有的驗 證者都可以驗證這個 proof 。 zk-SNARK 是證明某個宣告是真卻不洩露關於該宣告的隱私資訊的一 個很有創新性的演算法，他可以證明某人知道某個秘密卻不會洩露關於這個 秘密的任何資訊。這個演算法可以解決什麼問題呢？

它是對所有零知識證明問題的通用解決方法，由加密數字貨幣 zcash 首次使用並開源。 zk-SNARK 的優點：

1. 通用庫，可以解很多零知識證明問題

2. 驗證證明效能較高（ 300tps ）

zk-SNARK 的不足：

1. 底層模型不容易理解，使用者需要根據具體的零知識證明問題，在上層構建自己的業務模型，這塊開發的工作量較大。

2.生成每筆交易時延較長（ 57s ）

應用場景

   ZKP 的應用場景包括匿名可驗證投票、數字資產安全交換、安全遠端生物識別認證和安全拍賣，具體如下。

    匿名可核查投票：投票是保障一個國家或控股公司民主的重要組成部分。然而，選民的隱私可能在投票過程中被洩露。此外，投票結果很難得到安全的核實。 ZKP 是實施匿名可核查投票的一種可用方法。根據 ZKP 的使用，符合條件的選民可以在不洩露身份的情況下投票表決顯示他們的權利。此外， ZKP 允許符合條件的選民要求提供可核查的證據，證明他們的選票包含在負責報告投票結果的機構的最終計票中。

    數字資產的安全交換：數字資產是二進位制資料的集合，它們是唯一可識別和有價值的。如果兩個使用者希望交換其數字資產，則使用者的隱私，包括身份和交換數字資產的內容，可能會在交換過程中洩露。根據 ZKP 的使用，數字資產可以在不洩露使用者隱私的情況下交換。此外， ZKP 生成了可驗證的證據，其中包含數字資產交換的過程。

    安全遠端生物識別身份驗證：遠端生物識別身份驗證是一種可用於透過使用指紋、面部影像、虹膜或血管模式等生物識別模式識別使用者訪問許可權的方法。但是，在實施遠端生物識別認證時，使用者的生物識別模式可能會洩露給不受信任的第三方。使用 ZKP 可以解決這個問題。此外， ZKP 生成還提供了可核查的證據，其中包括識別使用者訪問許可權的過程。

    安全拍賣：政府拍賣是政府從多個供應商中選擇最低出價的拍賣，這些供應商以競爭性方式銷售其商品和服務。本次拍賣包括兩個階段。在第一階段，多個供應商投標，但公眾不知道。在第二階段，這些投標是開放的。政府選擇中標供應商，後者出價最低。然而，中標供應商的選擇可能會洩露其他中標供應商的投標和身份。 ZKP 可以解決這個問題。 ZKP 為每個輸標供應商生成可核查的證據。該證明證實輸標供應商的投標與中標供應商的投標之間的差額是正的。

 

zk-snark應用於區塊鏈的挑戰及實現

    零知識證明是指一方（證明者）向另 一方（驗證者）證明一個陳述是正確的， 而無需透露除該陳述正確以外的任何信 息，適用於解決 任 何 NP 問題。而區塊 鏈 恰好可以抽象成多方驗證交易是否有效 （ NP 問題）的平臺，因此，兩者是天然相 適 應的。將零知識證明應用到區塊 鏈中 需要考慮的 技 術 挑戰分為兩大類：一類 是適用於隱私保護的區塊鏈架構設計方 案，包括隱秘交易所花資產存在性證明、匿 名資產雙花問題、匿名資產花費與轉移、隱 秘交易不可區分等技術挑戰；另一類是零 知識證明技 術 本身帶來的 挑戰，包括 參 數 初始化階段、演算法 效能以及安 全問題 等技術挑戰。

華為整合了 zksnark 架構到區塊鏈系統中來解決上面的挑戰。我們知道有多種方法可以為區塊鏈啟用 zkSNark 。這些都降低了配對函式和橢圓曲線操作的實際成本。

1. 提高合約虛擬機器的效能

相較第二種更難實現。可以在合約虛擬機器中新增功能和限制，這將允許更好的實時編譯和解釋，而無需在現有實現中進行太多必要的更改。下面的轉賬場景就是基於此種方案的實現。

2. 僅提高某些配對函式和橢圓曲線乘法的在合約虛擬機器的效能

透過強制所有區塊鏈客戶端實現特定的配對函式和在特定橢圓曲線上的乘法作為所謂的預編譯契約來實現。好處是，這可能更容易和更快地實現。另一方面，缺點是我們固定在一定的配對函式和一定的橢圓曲線上。區塊鏈的任何新客戶端都必須重新實施這些預編譯的合同。此外，如果有人找到更好的 zkSNark 、更好的配對函式或更好的橢圓曲線，或者如果在橢圓曲線、配對函式或 zkSNark 中發現缺陷，必須新增新的預編譯合同。

轉賬應用

 

  圖 6 轉賬初始化

    圖 6 包含了對這個餘額初始化的過程，生成交易也就是真正轉賬的過程包含驗證，證明，完成驗證，生成交易即收款等步驟。拿初始化舉個例子，比如說愛麗絲初始化了一個 100 塊錢的一個餘額，然後鮑勃十塊錢。轉賬的過程就可以描述為，愛麗絲轉 20 塊錢給鮑勃，內部生成一對 Spending key / Paying Key , 相當於臨時交易的一個賬戶， Paying Key 給對方， Spending Key 留給自己，用於證明交易鏈上的交易是屬於誰的。

     拿到生成的交易和相關的證明，就完成了交易生成這一步。下一步就要進行轉賬的驗證證明，驗證邏輯如下：

1.  Nullifier NF.axxxxx1和NF.axxxxx2是否在Nullifiers列表中，也就是說，是否有被花過;

2.  驗證NF.axxxxx1和NF.axxxxx2是格式是否合法的花費憑據，且對應的commitment在鏈上(Proof + Merkle tree root)，這裡有需要驗證Merkle tree root在 是有效的;

3.  驗證input == output金額守恆，即：100 + 0 = 80+0+20;

4.  數字範圍滿足要求：100-20 >0 && 20 > 0

   過程驗證完了以後就進入最後一步。完成驗證還會做一些類似於交易內容的隱藏 , 身份隱藏，交易行為的隱藏，來保護整個的這個轉賬交易過程的安全性，包括做一些混淆電路的能力。混淆交易內容且加密，驗證者並不知道使用鏈上是哪個 Commitment 作為輸入，只知道沒有被花過，且在鏈上。身份隱藏讓其無法確定接收方是誰，交易行為隱藏讓其無法確定這個交易是傳送還是接收。基於安全性的保證，才能完成整個驗證過程。最後生成交易，然後收款，整個轉賬過程就結束了。基於零知識證明的轉賬，被華為整合在零知識證明使用介面中。整合的零知識證明架構也能用來開發一些隱私之類的應用，實現區塊鏈隱私保護的解決方案。

總結

    交易隱私保護這塊的技術應該是比較多的，零知識證明技術並不一定是一個最好的選擇，在安全領域中還有很多諸如同態，秘密分享，不經意傳輸，或者基於 TEE 硬體的一些隱私保護能力，可以去做一些隱私保護。但是零知識證明其優點也是很顯著，未來區塊鏈的隱私保護仍然任重而道遠，如何實現快速高效、可信的零知識證 明演算法以及如何實現能夠抵抗量子計算 的零知識證明演算法，都是需要進一步解決 的問題。基於線上我們提供的一些基本的能力，要是大家感興趣，可以到之前的網址下載相應的程式碼示例。