Vài tháng trước, nhóm crypto tại a16z đã xuất bản Thách thức Nakamoto, một danh sách các vấn đề quan trọng cần giải quyết trong blockchain. Vấn đề thứ tư đặc biệt thu hút sự chú ý của chúng tôi: “Tuân thủ Quyền riêng tư có thể lập trình”, vì chúng tôi đã tích cực suy nghĩ về vấn đề này từ một thời gian. Hôm nay, chúng tôi đề xuất một giải pháp đầu tiên bằng cách sử dụng mã hóa đồng cấu và giao thức hợp đồng thông minh bảo mật fhEVM của chúng tôi (nếu bạn chưa quen thuộc với fhEVM, bạn có thể đọc các bài viết của chúng tôi về bảo mật Token ERC20vàđấu giá mù.

FHEVM là một EVM thông thường với một số biên dịch trước cho phép tính toán trên các trạng thái được mã hóa bằng cách sử dụng thư viện mã hóa đồng cấu TFHE-rs của chúng tôi. Từ quan điểm của nhà phát triển, không có mật mã liên quan: họ chỉ cần viết mã Solidity bằng cách sử dụng các loại dữ liệu được mã hóa mà chúng tôi cung cấp (euint32, ebool, v.v.). Một trong những lợi thế lớn của fhEVM so với các giải pháp bảo mật khác là tất cả dữ liệu và tính toán xảy ra trên chuỗi. Điều này có nghĩa là bạn có thể có cùng mức độ khả năng kết hợp và tính khả dụng của dữ liệu như các hợp đồng văn bản thuần thông thường.

Thuộc tính này quan trọng để xây dựng quyền riêng tư có thể lập trình, vì tất cả logic kiểm soát truy cập có thể được xác định trong hợp đồng chính nó. Không có điều gì cần được mã hóa cứng vào giao thức, và không có gì người dùng cần phải làm ngoại mạng để tuân thủ. Ứng dụng có thể thực thi sự tuân thủ trực tiếp, chỉ với vài dòng mã Solidity!

Trong bài viết này, chúng tôi sẽ hướng dẫn cách xây dựng một token ERC20 tuân thủ, sử dụng DIDs trên chuỗi. Mã nguồn cho hướng dẫn này có thể được tìm thấy trong thư mục ví dụcủa kho lưu trữ fhEVM.

Trừu tượng hóa danh tính qua onchain, DIDs bảo mật

Mã định danh phi tập trung (DID) là một danh tính kỹ thuật số duy nhất được cấp bởi một thực thể như chính phủ, nhà đăng ký, công ty hoặc chính người dùng. DID này có thể được gắn với khóa mật mã chứng minh người dùng sở hữu DID, chẳng hạn như ví EVM. Nhưng nó cũng có thể lưu trữ một loạt các thuộc tính, chẳng hạn như tuổi, quốc tịch, số an sinh xã hội của người dùng, v.v. Những thuộc tính này sau đó có thể được sử dụng để chứng minh rằng bạn đáp ứng một số điều kiện (được gọi là "chứng thực"), chẳng hạn như trên 18 tuổi hoặc không phải là công dân Narnia.

Hầu hết các DID được triển khai phía máy khách và sử dụng bằng chứng không có kiến thức để tạo chứng thực. Mặc dù điều này là tốt trong nhiều trường hợp, nhưng nó nhanh chóng trở nên phức tạp khi bạn có nhiều người dùng tham gia vào một giao dịch, khi bạn phải áp dụng các quy tắc phức tạp cho DID hoặc khi bạn cần giữ một bộ quy tắc chung để mọi người tuân theo. Về cơ bản, nó là sự đánh đổi tương tự như trong các ứng dụng cạnh so với đám mây.

Tuy nhiên, việc có một bảng đăng ký DID tập trung sẽ giải quyết những vấn đề này, vì bạn có thể đơn giản yêu cầu bảng đăng ký kiểm tra xem ai cũng tuân thủ. Điều này cũng làm cho việc theo dõi các quy định đơn giản hơn, vì bạn chỉ cần triển khai nó tại một nơi duy nhất. Blockchain sẽ là cơ sở hạ tầng hoàn hảo cho điều này, vì nó sẽ cho phép tính tương hợp giữa các DID và ứng dụng yêu cầu tuân thủ, cũng như tính tương hợp giữa các quy định chính mình.

Vấn đề: mọi người sẽ thấy danh tính của mọi người!

May mắn thay chúng tôi có một giải pháp: mã hóa đồng cấu, và cụ thể hơn là fhEVM! Nhờ khả năng có thể kết hợp trên trạng thái đã mã hóa, chúng tôi có thể lưu trữ các DIDs của người dùng trực tiếp trên chuỗi dữ liệu dưới dạng đã mã hóa, và có thể cho ứng dụng tuân thủ xác minh các thuộc tính bằng cách gọi hợp đồng đơn giản. Khả năng quản lý một danh tính thông qua một hợp đồng thông minh, mà chúng tôi gọi là “Trừu tượng Danh tính”, tương tự như cách mà người ta có thể quản lý quỹ thông qua hợp đồng thông minh với Trừu tượng Tài khoản.

Hướng dẫn này có 3 phần:

• Trừu tượng hóa danh tính được thực hiện thông qua một hợp đồng đăng ký chịu trách nhiệm quản lý danh tính và xác nhận. Ở đây, chúng ta giả định rằng DIDs là các ID chính thức của chính phủ. Bản thân hệ thống đăng ký được quản lý bởi một cơ quan trung ương (ví dụ: AFNIC) có thể tạo ra các nhà đăng ký (ví dụ: các công ty KYC như Onfido, Jumio, v.v.) sau đó có thể tạo ra DIDs người dùng. Người dùng sau đó thông qua nhà đăng ký của họ để quản lý và cập nhật DIDs của họ.
• Quy định được xác định trong một hợp đồng mã hóa một tập hợp các quy tắc cho việc chuyển giao token giữa các cá nhân, dựa trên thông tin chứa trong DIDs của họ. Nó cơ bản là áp dụng quy định ở mức hợp đồng thay vì ở mức người dùng.
• Chuyển nhượng Tuân thủ và Mật mã được thực hiện trong một hợp đồng ERC20 tuân thủ sử dụng hợp đồng quy định để bắt buộc tuân thủ trong việc chuyển nhượng token, mà không có bất kỳ thay đổi nào đối với chính API ERC20. Trong ví dụ này, chúng tôi sử dụng một hợp đồng ERC20 mật mã, trong đó số dư và số lượng được ẩn, nhưng nó cũng hoạt động tốt với một loại token ERC20 thông thường, không mã hóa.

Kiến trúc của Giao thức DID Bí mật Onchain của chúng tôi

Hợp đồng đăng ký danh tính

Hợp đồng IdentityRegistry là một bảng đăng ký các DIDs của người dùng được phát hành bởi các bộ đăng ký và bao gồm một tập hợp các bí danh được mã hóa, chẳng hạn như quốc tịch, tuổi, số bảo hiểm xã hội v.v. Các bí danh này được lưu trữ dưới dạng các giá trị 32 bit được mã hóa (euint32).

Hợp đồng cũng xử lý các quyền, như:

• Cho phép chủ hợp đồng (ví dụ: AFNIC) thêm, loại bỏ hoặc cập nhật người đăng ký.
• Cho phép các bộ đăng ký thêm, xóa hoặc cập nhật các DIDs người dùng họ đã tạo.
• Cho phép người dùng cấp quyền truy cập cho hợp đồng thông minh vào các thuộc tính cụ thể của DIDs. Điều quan trọng cần lưu ý ở đây là người dùng chịu trách nhiệm không cấp quyền truy cập cho các hợp đồng độc hại, giống như việc họ chịu trách nhiệm không để các hợp đồng độc hại tiêu tốn token của họ.

Bước đầu tiên, hãy triển khai logic để tạo và quản lý DID:

Bây giờ bước tiếp theo là triển khai logic cho các định danh và kiểm soát truy cập.

Một định danh đơn giản chỉ là một chuỗi (ví dụ: "ngày tháng năm sinh") và một giá trị 32 bit được mã hóa. Nó chỉ có thể được tạo hoặc cập nhật bởi người đăng ký. Người dùng không thể tạo ra các định danh của riêng họ, vì chúng tôi muốn chúng được chứng nhận bởi người đăng ký.

Vì các định danh được mã hóa, người dùng cần phải cho phép một hợp đồng truy cập các giá trị cụ thể, mà chúng tôi sẽ xử lý thông qua một cơ chế kiểm soát truy cập đơn giản tương tự như cách bạn có thể cho phép một hợp đồng chi tiêu các token ERC20 của bạn.

contract IdentityRegistry là EIP712WithModifier, Ownable

Bây giờ chúng ta có thể hoàn thành hợp đồng danh sách định danh bằng cách thêm các phương thức getter cần thiết, với một số điều kiện và xử lý lỗi.

Hợp đồng IdentityRegistry là EIP712WithModifier, Ownable

Hợp đồng quy định

Bước tiếp theo là tạo hợp đồng quy định của chúng tôi.

Khi triển khai một bộ quy tắc cho việc chuyển khoản giữa hai cá nhân, việc nhận ra rằng những quy tắc này có thể phát triển theo thời gian là rất quan trọng. Việc có một hợp đồng thông minh duy nhất định nghĩa tất cả các quy định cho một ngữ cảnh cụ thể như chuyển tiền có nghĩa là các hợp đồng ERC20 không cần phải theo dõi các quy định một cách tự động. Chính phủ có thể đơn giản cập nhật hợp đồng này và nó sẽ tự động lan truyền đến tất cả các token đã triển khai nó.

Ở cốt lõi, hợp đồng quy định chỉ là một tập hợp các điều kiện được so khớp với các thuộc tính danh tính đã được mã hóa. Để tránh lạm dụng, người dùng sẽ không trực tiếp cấp quyền truy cập cho hợp đồng quy định, mà sẽ cấp quyền truy cập cho hợp đồng token ERC20, sau đó thực hiện một cuộc gọi ủy quyền đến hợp đồng quy định. Phương pháp này đảm bảo rằng chỉ có hợp đồng ERC20, mà người dùng tin tưởng, mới có thể truy cập thông tin của họ. Hãy nhớ rằng cả người gửi và người nhận đều phải đã cấp quyền cho hợp đồng ERC20 trước khi một giao dịch có thể xảy ra giữa họ.

Trong ví dụ này, chúng tôi sẽ thực hiện một số quy tắc cơ bản:

• Các chuyển khoản trong nước không giới hạn, nhưng chuyển khoản sang nước ngoài được giới hạn tại 10.000 token.
• Một người dùng bị đưa vào danh sách đen không thể chuyển hoặc nhận mã thông báo.
• Người dùng không thể chuyển đổi token đến một quốc gia bị đưa vào danh sách đen.

Thay vì thất bại giao dịch, có thể tiết lộ thông tin nhạy cảm, chúng tôi sẽ đơn giản chỉ đặt số tiền chuyển giao thành 0 nếu một trong các điều kiện không được đáp ứng. Điều này sử dụng một toán tử tam hình đồng cấu gọi là cmux: giá trị = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

Hợp đồng ERC20 bí mật tuân thủ

Bây giờ chúng ta đã có một danh sách đăng ký danh tính và một hợp đồng quy định, cuối cùng chúng ta có thể tạo ra hợp đồng mã token tuân thủ quy định, bảo vệ quyền riêng tư của mình. Hợp đồng này sẽ được gọi là CompliantERC20 và có những tính năng chính sau đây:

• Số dư người dùng và số tiền chuyển khoản được mã hóa.
• Sự tuân thủ được thực thi trong việc chuyển khoản bằng cách gọi hợp đồng quy định.
• Sự hiển thị của một số số dư cụ thể có thể được cấp quyền cho các địa chỉ được liệt kê trên danh sách trắng (ví dụ: cơ quan quản lý)

Hợp đồng quy định được gọi thông qua một cuộc gọi đơn giản. Điều này ngụ ý rằng người dùng phải cung cấp quyền truy cập vào hợp đồng ERC20 trước khi khởi đầu bất kỳ chuyển khoản nào; nếu không, việc chuyển khoản sẽ bị hoàn ngược.

Cuối cùng, chúng ta có thể tạo hợp đồng ERC20 của chúng tôi:

Tương tự như cách người dùng cấp quyền cho các giao thức DeFi để tiêu tốn token của họ, họ sẽ cần cấp quyền cho hợp đồng để truy cập các định danh cần thiết bởi hợp đồng quy định. Điều này được thực hiện thông qua cuộc gọi đến Identity.grantAccess(contractAddress, identifiers), mà có thể được truy xuất bằng cách gọi phương thức xem ERC20.identifiers(). Danh sách này đến trực tiếp từ hợp đồng ERC20Rules để cho phép cập nhật thuộc tính.

Sự tuân thủ và quyền riêng tư có thể cùng tồn tại!

Hy vọng rằng hướng dẫn này đã cho bạn thấy rằng tuân thủ không phải là một điều khó khăn nếu có các công cụ phù hợp. Trong khi ban đầu chúng tôi xây dựng fhEVM để cho phép quyền riêng tư trong blockchain, chúng tôi nhanh chóng nhận ra rằng công nghệ này có thể được sử dụng cho quản lý danh tính và do đó tuân thủ có thể được lập trình.

Thiết kế đề xuất ở đâyvẫn chưa hoàn hảo, nhưng chúng tôi tin rằng nó có thể dễ dàng được cải thiện và triển khai như một trường hợp sử dụng thực tế, để mà sự tuân thủ không còn phải đồng nghĩa với giám sát!

Liên kết bổ sung

• Star Kho lưu trữ Github fhEVM của Zamađể chứng thực công việc của chúng tôi.
• Đánh giá Tài liệu fhEVM của Zama.
• Nhận hỗ trợ về các kênh cộng đồng.
• Hỗ trợ tiến bộ không gian FHE với Chương trình Tiền thưởng Zama: Tạo một trò chơi trên chuỗi giữ các trạng thái riêng tư được ẩn bằng cách sử dụng tính năng bảo mật có thể lập trình fhEVM của Zama (15,000€ trong giải thưởng).

Tuyên bố từ chối：

1. Bài viết này được in lại từ [zama]。 Tất cả bản quyền thuộc về tác giả gốc [fhEVM]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ với Cổng Họcđội, và họ sẽ xử lý nhanh chóng.
2. Liability Disclaimer: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không hợp thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.