字體：小 中 大 |
|
|
|
|
|
||
|
字體：小 中 大 |
|
|
|
| 2022/11/12 21:32:55瀏覽436｜回應0｜推薦7 | |
| 《 心得小筆記 - 零知識證明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。 |
|
| ( ｜ ) |
|
|
|
|
|
||
