Contents ...
udn網路城邦
《 心得小筆記 - 零知識證明ZK與靈魂綁定代幣SBT》
2022/11/12 21:32
瀏覽456
迴響0
推薦7
引用0
《 心得小筆記 - 零知識證明ZK與靈魂綁定代幣SBT》

為使未來web3裏的虛擬社會,能像實體世界一樣,是構建在每個人社會身份基礎上運作的人際互動網絡,而豐富web3概念的實用性,以太坊(Ethereum)共同創辦人 “V神” Vitalik Buterin 提出 “靈魂綁定代幣”(soulbound token, SBT)的概念,用無法轉讓交易的SBT作為每個 “靈魂”(帳號)在web3世界裏的社會身份表彰,例如從某個學校畢業、某項工作經歷,都有相對應的SBT作為證明。

但若將一個人的社會身份資訊赤裸裸地放在網路上展示,必將增加個資外泄,甚至身份被盜用的風險,針對此一情況,遂有 “零知識證明”(zero-knowledge proof, ZK)概念的發想。

所謂的 “零知識證明”,是指當一方(證明者)向另一方(驗證者)證明一個“陳述為真”時,並不會透露任何超出陳述本身有效性的信息。例如當驗證需求為 “是否為東海大學畢業生”,證明者僅需回覆 “是” 或 “不是” 的陳述,無需透露實際畢業學校、就讀科系、畢業年級、在校成績等其它資訊,以保障當事人的個資。

以上僅是 “零知識證明” 的觀念概述,要在網路環境運作,遠比此複雜多了。日前在網路上看到一篇有關 ZK-SNARK實作方式的介紹,簡略整理如下。

[基本觀念]

舉例來說,SBT 的用戶是證明者,向用戶發放 SBT 的項目方是驗證者。假設項目方要查證用戶是否具有某個社會身份屬性S,用戶只須證明他們是否擁有屬性S,但不會泄露S的內容。以電腦程式表達,可寫作

def C(H, S);
    return (sha256(H) == S)
我們定義一個函數C,其中H為公共哈希金鑰,如果S的SHA-256哈希值等於 H,則回傳true布林值,反之則回傳布林值false。如此一來,使用函數C(H, S)`,用戶僅需要創建他們擁有S的證明,而不需要透露S的內容,這就是zk-SNARK的運作原理。

[問題]

由於設定的函數C回傳的僅是布林值true或false 二者其中之一,所以駭客可以在不知道社會身份屬性S的秘密內容情況下創建評估為true或false 的假證明,故流程設計需更複雜些,要利用到加密金鑰的機制。

[流程設計]

1.隨機產生加密金鑰生成器

加密金鑰雖有保護力,但若有人了解加密金鑰生成器相關參數,仍有被人創設假證明的風險,故隨機產生加密金鑰生成器秘密參數 lambda(入)是重要的第一步,以確保沒有人能在任何地方發現和存儲加密金鑰生成器秘密參數。

2.生成證明金鑰和驗證金鑰

項目方設計一個金鑰生成程序G,利用先前產生的秘密參數 入 和程序C生成兩個公開的金鑰--證明金鑰`pk`,和驗證金鑰`vk`以電腦程式表達,可寫作

(pk, vk) = G(C, 入)

3.證明和驗證金鑰的共享

項目方將與用戶共享證明金鑰`pk`和驗證金鑰`vk`。然後,這些金鑰可以用來生成基於用戶屬性的證明,以及驗證用戶的社會身份屬性。

4.證明的生成

用戶使用證明金鑰 pk、公共哈希金鑰H 和 用戶的社會身份屬性S,使用證明算法“generate_proof”來創建證明“prf”

prf = generate_proof(pk, H, S)


5.用戶社會身份屬性驗證

用戶將生成的證明“prf”提供給項目方,項目方再利用運行驗證函數“verify(vk, H, prf)”進行驗證,如果證明正確則返回 true,否則返回 false。

《 心得小筆記 - 零知識證明ZK與靈魂綁定代幣SBT》

為使未來web3裏的虛擬社會,能像實體世界一樣,是構建在每個人社會身份基礎上運作的人際互動網絡,而豐富web3概念的實用性,以太坊(Ethereum)共同創辦人 “V神” Vitalik Buterin 提出 “靈魂綁定代幣”(soulbound token, SBT)的概念,用無法轉讓交易的SBT作為每個 “靈魂”(帳號)在web3世界裏的社會身份表彰,例如從某個學校畢業、某項工作經歷,都有相對應的SBT作為證明。

但若將一個人的社會身份資訊赤裸裸地放在網路上展示,必將增加個資外泄,甚至身份被盜用的風險,針對此一情況,遂有 “零知識證明”(zero-knowledge proof, ZK)概念的發想。

所謂的 “零知識證明”,是指當一方(證明者)向另一方(驗證者)證明一個“陳述為真”時,並不會透露任何超出陳述本身有效性的信息。例如當驗證需求為 “是否為東海大學畢業生”,證明者僅需回覆 “是” 或 “不是” 的陳述,無需透露實際畢業學校、就讀科系、畢業年級、在校成績等其它資訊,以保障當事人的個資。

以上僅是 “零知識證明” 的觀念概述,要在網路環境運作,遠比此複雜多了。日前在網路上看到一篇有關 ZK-SNARK實作方式的介紹,簡略整理如下。

[基本觀念]

舉例來說,SBT 的用戶是證明者,向用戶發放 SBT 的項目方是驗證者。假設項目方要查證用戶是否具有某個社會身份屬性S,用戶只須證明他們是否擁有屬性S,但不會泄露S的內容。以電腦程式表達,可寫作

def C(H, S);
    return (sha256(H) == S)
我們定義一個函數C,其中H為公共哈希金鑰,如果S的SHA-256哈希值等於 H,則回傳true布林值,反之則回傳布林值false。如此一來,使用函數C(H, S)`,用戶僅需要創建他們擁有S的證明,而不需要透露S的內容,這就是zk-SNARK的運作原理。

[問題]

由於設定的函數C回傳的僅是布林值true或false 二者其中之一,所以駭客可以在不知道社會身份屬性S的秘密內容情況下創建評估為true或false 的假證明,故流程設計需更複雜些,要利用到加密金鑰的機制。

[流程設計]

1.隨機產生加密金鑰生成器

加密金鑰雖有保護力,但若有人了解加密金鑰生成器相關參數,仍有被人創設假證明的風險,故隨機產生加密金鑰生成器秘密參數 lambda(入)是重要的第一步,以確保沒有人能在任何地方發現和存儲加密金鑰生成器秘密參數。

2.生成證明金鑰和驗證金鑰

項目方設計一個金鑰生成程序G,利用先前產生的秘密參數 入 和程序C生成兩個公開的金鑰--證明金鑰`pk`,和驗證金鑰`vk`以電腦程式表達,可寫作

(pk, vk) = G(C, 入)

3.證明和驗證金鑰的共享

項目方將與用戶共享證明金鑰`pk`和驗證金鑰`vk`。然後,這些金鑰可以用來生成基於用戶屬性的證明,以及驗證用戶的社會身份屬性。

4.證明的生成

用戶使用證明金鑰 pk、公共哈希金鑰H 和 用戶的社會身份屬性S,使用證明算法“generate_proof”來創建證明“prf”

prf = generate_proof(pk, H, S)


5.用戶社會身份屬性驗證

用戶將生成的證明“prf”提供給項目方,項目方再利用運行驗證函數“verify(vk, H, prf)”進行驗證,如果證明正確則返回 true,否則返回 false。

有誰推薦more

限會員,要發表迴響,請先登入