幾個月前，a16z 的加密團隊發布了 Nakamoto Challenge（中本挑戰），這是一份在區塊鏈中解決的最重要問題清單。其中，第四個問題特別引起了我們的注意：「合規可編程隱私」，因為我們一直在積極思考這個問題，今天，我們提出了使用同態加密和 fhEVM 機密智能合約協議的第一個解決方案。

fhEVM 是一個常規的 EVM，其中包含一些 precompiles，可以使用我們的 TFHE-rs 同態加密庫在加密狀態上進行計算。從開發者的角度來看，沒有涉及到密碼學，他們只需使用我們提供的加密數據類型（euint32，ebool 等）編寫 Solidity 代碼。fhEVM 相對於其他隱私解決方案的一個重大優勢是，所有的數據和計算都發生在鏈上。這意味著您可以獲得與常規明文合約相同的可組合性和數據可用性。

這個特性對於構建可編程隱私至關重要，因為所有的訪問控制邏輯都可以在合約本身中定義。在協議中沒有需要硬編碼的內容，用戶無需在鏈外執行任何操作以確保合規性。應用程序可以直接強制執行合規性，只需幾行 Solidity 代碼。

在這篇文章中，我們將展示如何使用鏈上 DIDs 構建一個合規的 ERC20 代幣。本教程的源代碼可以在 fhEVM 儲存庫的 examples 文件夾中找到。

通過鏈上、保密的 DID 進行身份抽象

去中心化標識（DID）是由政府、註冊機構、公司或用戶自身等實體頒發的獨特數字身份。這個 DID 可以與證明用戶擁有 DID 的加密密鑰綁定，例如 EVM 錢包。但它還可以儲存一系列屬性，比如用戶的年齡、國籍、社會安全號等。這些屬性反過來可以用來證明你滿足某些條件（稱為「證明」），比如年滿 18 歲或不是納尼亞公民。由政府、註冊機構、公司或用戶自身等實體頒發的，比如政府、註冊機構、公司或用戶本身。

大多數 DID 實際上是在用戶端實現的，它們利用零知識證明生成證明。雖然在許多情況下這是可行的，但當涉及多個用戶參與交易、需要對 DID 應用複雜規則，或者需要所有人遵循一套通用規則時，情況就會變得複雜。這本質上與邊緣應用與雲應用的權衡相似。

然而，擁有一個集中式的 DID 註冊表可以解決這些問題，因為您可以簡單地要求註冊表檢查每個人是否符合規定。這還將使得法規跟蹤變得更簡便，因為您只需在一個地方進行實施。區塊鏈將是這個理想的基礎設施，因為它將允許 DID 和需要遵循規定的應用之間的可組合性，以及規定之間的可組合性。這本質上與邊緣應用與雲應用的權衡相似。

問題：每個人都會看到所有人的身份！

幸運的是，我們有一個解決方案：同態加密，更具體地說是 fhEVM！由於在加密狀態上具有可組合性的能力，我們可以直接在鏈上以加密形式託管用戶的 DID，並通過簡單的合約調用讓合規的應用程序驗證屬性。通過智能合約管理身份的能力，我們稱之為「身份抽象」，類似於通過具有帳戶抽象的智能合約管理資金的方式。

本教程分為 3 個部分：

身份抽象是通過一個註冊合約實現的，該合約負責管理身份和證明。在這裡，我們假設 DIDs 是官方政府身份證。註冊表本身由中央機構（例如 AFNIC）管理，該機構可以創建註冊機構（例如 KYC 公司，如 Onfido，Jumio 等），然後註冊機構可以創建用戶 DIDs。然後，用戶通過其註冊機構來管理和更新其 DID。

監管在一個合約中定義，該合約對基於用戶 DID 中包含的資訊的個體之間的代幣轉移規則進行編碼。它基本上在合約級別而不是用戶級別執行監管。

合規的機密轉賬是在一個合規的 ERC20 合約中實現的，該合約使用法規合約來強制執行代幣轉移的合規性，而不對 ERC20 API 本身進行任何更改。在這個例子中，我們使用了一個機密的 ERC20 合約，其中餘額和金額是隱藏的，但對於一個常規的、明文的 ERC20 代幣同樣有效。

身份註冊合約

身份註冊合約是一個由註冊機構發放用戶 DID 的註冊表，其中包含一組加密標識，如國籍、年齡、社會安全號等。這些標識以加密的 32 位值（euint32）的形式儲存。

該合約還處理權限，包括：

允許合約所有者（例如 AFNIC）添加、刪除或更新註冊機構。

允許註冊機構添加、刪除或更新他們創建的用戶 DID。

允許用戶授予智能合約訪問其 DID 特定屬性的權限。這裡需要注意，用戶有責任不向惡意合約授予訪問權限，就像他們有責任不讓惡意合約花費他們的代幣一樣。

第一步，實現創建和管理 DID 的邏輯：

下一步是實現標識和訪問控制的邏輯。

標識符簡單來說是一個字符串（例如「出生日期」）和一個加密的 32 位值。它只能由註冊機構創建或更新。用戶不能創建自己的標識符，因為我們希望它們經過註冊機構的認證。

然而，由於標識符是加密的，用戶需要授予合約訪問特定值的權限，我們將通過一個簡單的訪問控制機制來處理，類似於您可以允許合約花費您的 ERC20 代幣的簡單訪問控制機制。

現在我們可以通過添加必要的獲取器，加入一些條件和錯誤處理，來完成我們的身份註冊合約。

監管合約

下一步是創建監管合約。

在實施兩個個體之間的轉賬規則時，重要的是要認識到這些規則可能會隨時間演變。有一個單一的智能合約來定義給定上下文（如資金轉移）的所有監管規定，這意味著 ERC20 合約無需自己跟蹤監管規定。政府只需更新此合約，它將自動傳播到實施了它的所有代幣。

在核心部分，監管合約只是一組與加密身份屬性匹配的條件。為了防止濫用，用戶不會直接授予監管合約訪問權限，而是授予 ERC20 代幣合約訪問權限，然後由 ERC20 代幣合約執行對監管合約的委託調用。這種方法確保只有用戶信任的 ERC20 合約才能訪問他們的資訊。請記住，在發件人和接收人在它們之間發生轉賬之前，它們都必須已經授予 ERC20 合約許可。

在這個例子中，我們將實施一些基本規則：

國內的轉賬是無限制的，但向外國的轉賬上限為 1 萬代幣。

黑名單用戶無法轉賬或接收代幣。

用戶不能將代幣轉賬到黑名單國家。

與其使交易失敗，可能會泄露敏感資訊，如果其中一個條件不滿足，我們將簡單地將轉賬金額設置為 0。這使用了一個稱為 cmux 的同態三元運算符：value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse);

合規的隱私 ERC20 合約

現在我們有了身份註冊和監管合約，我們終於可以創建符合要求的、保護隱私的代幣合約了。這個合約將被稱為 CompliantERC20，具有以下關鍵特點：

用戶餘額和轉賬金額都是加密的。

合規性通過調用監管合約來執行轉賬。

可以向白名單地址（例如監管機構）授予對某些餘額的可見性。

可簡單的調用監管合約。這意味著用戶在發起任何轉賬之前必須提供對 ERC20 合約的訪問權限；否則，轉賬將被回滾。

最後，我們現在可以創建我們的 ERC20 合約：

類似於用戶授予 DeFi 協議花費他們的代幣的權限，他們需要授予合約訪問監管合約所需的標識的權限。這是通過調用 Identity.grantAccess(contractAddress, identifiers) 來實現的，可以通過調用 ERC20.identifiers() 視圖方法來檢索。此列表直接來自 ERC20Rules 合約，以允許屬性的更新。

合規和隱私可以共存

如果有合適的工具，建立合規並不難。雖然我們最初構建 fhEVM 以在區塊鏈中實現隱私，但我們很快意識到這項技術可以用於身份管理，從而實現可編程合規。

此設計還遠非完美，但我們相信它可以繼續改進，並作為一個真實的用例推出，使合規不再等同於監管。

原文連結