Nguồn: Noemi Glaeser, a16z crypto
Trong Mật mã họcKhóa công khai, luôn có một vấn đề khó khăn, đó là làm thế nào để liên kết mật mãChìa khoá bảo mật (như Khóa công khai) một cách chính xác với một danh tính cụ thể (như một người hoặc tổ chức). Vấn đề quan trọng là cần có một cách công khai và nhất quán để hiển thị mối quan hệ giữa danh tính và Khóa công khai, để mọi người có thể yên tâm sử dụng những Khóa công khai này để mã hóa thông tin.
Nếu không có mối quan hệ rõ ràng như vậy, người khác có thể không xác định được Khóa công khai nào thuộc về ai, điều này có thể dẫn đến việc gửi mã hóa thông tin cho người sai, gây ra rò rỉ thông tin hoặc các hậu quả nghiêm trọng khác. Trong Web3, vấn đề này vẫn tồn tại.
Đối với các vấn đề trên, hiện tại có ba giải pháp: Thư mục Khóa Công khai, mã hóa dựa trên danh tính (IBE) và mã hóa dựa trên đăng ký (RBE). Ba phương pháp này đều có ưu điểm riêng về tính ẩn danh, tương tác và hiệu suất. Ví dụ, IBE yêu cầu một nền tảng tin cậy mạnh mẽ, nhưng trong một số trường hợp, IBE hoạt động tốt hơn về tính ẩn danh và hiệu suất. Bài viết này nhằm mục đích khám phá ứng dụng của ba phương pháp này trên chuỗi Khối và so sánh ưu và nhược điểm của chúng.
Ba phương pháp
一般来说，将mã hóaChìa khoá bảo mật与身份信息关联的常用方法是使用Khóa công khai基础设施（PKI），其中核心部分是一个Khóa công khai目录。在这种方法中，发送信息的人需要与一个受信任的第三方（即维护这个目录的机构，通常是证书颁发机构）进行互动，以便发送mã hóa信息。
Tuy nhiên, trong môi trường Web2, việc duy trì thư mục Khóa công khai này đòi hỏi chi phí cao và thao tác phức tạp. Ngoài ra, người dùng cũng đối mặt với nguy cơ các cơ quan cấp phát chứng chỉ có thể lạm dụng quyền lực.
Một số phương án thay thế được đề xuất bởi các chuyên gia mật mã để giải quyết các vấn đề tồn tại trong cơ sở hạ tầng khóa công khai (PKI). Năm 1984, Adi Shamir đề xuất mã hóa dựa trên danh tính (IBE), trong đó định danh của một bên (ví dụ như số điện thoại, email hoặc tên miền ENS) có thể được sử dụng trực tiếp làm khóa công khai. Phương pháp này loại bỏ nhu cầu duy trì thư mục khóa công khai, nhưng đưa ra một vấn đề mới: phải phụ thuộc vào một bên thứ ba đáng tin cậy (bộ sinh khóa bảo mật) để tạo ra khóa riêng.
Năm 2001, Dan Boneh và Matthew Franklin đã đề xuất cấu trúc IBE đầu tiên thực tế, nhưng công nghệ này chưa được áp dụng rộng rãi, chủ yếu được sử dụng trong một số hệ sinh thái đóng cửa như môi trường triển khai của doanh nghiệp hoặc chính phủ. Một trong những lý do IBE không được sử dụng rộng rãi có thể là nó phụ thuộc vào một giả thiết tin cậy mạnh mẽ, đó là tin tưởng vào việc tạo ra Chìa khoá bảo mật bởi bên thứ ba.
Tuy nhiên, như sẽ được thảo luận trong phần tiếp theo của bài viết này, vấn đề tin tưởng này có thể được giải quyết bằng cách phụ thuộc vào một nhóm người theo lệnh long được tin tưởng (tức là một nhóm người tham gia được coi là hợp pháp), trong khi công nghệ blockchain có thể dễ dàng thực hiện điều này.
Ưu điểm và nhược điểm
Khi so sánh các phương án mã hóa này, cần xem xét nhiều yếu tố khác nhau, tôi đặt ra hai giả định về điều này:
Người dùng sẽ không cập nhật hoặc hủy bỏ Chìa khoá bảo mật của họ: Điều này có nghĩa là trong cuộc thảo luận, giả sử rằng Chìa khoá bảo mật của mỗi người dùng đều là cố định và không thay đổi.
Hợp đồng thông minh không sử dụng bất kỳ dịch vụ khả dụng dữ liệu off-chain (DAS) hoặc dữ liệu blob: nghĩa là giả sử Hợp đồng thông minh hoàn toàn phụ thuộc vào dữ liệu on-chain, không liên quan đến dịch vụ dữ liệu ngoài chuỗi hoặc lưu trữ dữ liệu bổ sung.
![]()
Thư mục Khóa Công khai
任何人都可以通过调用hợp đồng thông minh，将一个没有被别人占用的 ID 也就是 (id, pk) 条目添加到on-chain目录中。
![]()
PKI của Phi tập trung đề cập đến một thư mục giữa một ID và Khóa công khai tương ứng thông qua hợp đồng thông minh. Thư mục này là công khai và không phụ thuộc vào bất kỳ bên thứ ba tập trung nào. Ví dụ, với ENS, nó giữ một bảng ánh xạ giữa tên miền (tức là ID) và Metadata liên quan, bao gồm Địa chỉ được giải quyết bởi tên miền đó (Khóa công khai có thể được suy ra từ các giao dịch của các Địa chỉ này). ENS là một hệ thống phức tạp hơn, không chỉ ghi lại Khóa công khai mà còn lưu trữ các Metadata khác. Chức năng của PKI Phi tập trung tương đối đơn giản: Hợp đồng thông minh chỉ cần duy trì một danh sách, ghi lại Khóa công khai tương ứng với mỗi ID.
Khi người dùng muốn đăng ký một danh tính, trước tiên họ cần tạo ra một cặp Chìa khoá bảo mật (Khóa công khai và Khóa riêng), hoặc sử dụng cặp Chìa khoá bảo mật đã được tạo ra, sau đó gửi ID danh tính và Khóa công khai tới Hợp đồng thông minh (có thể phải trả một khoản phí nhất định), Hợp đồng thông minh sẽ kiểm tra xem ID này đã được đăng ký bởi người khác chưa. Nếu chưa có người sử dụng, Hợp đồng thông minh sẽ thêm ID và Khóa công khai này vào thư mục. Khi đã đăng ký xong, bất kỳ ai cũng có thể yêu cầu Hợp đồng thông minh để lấy Khóa công khai tương ứng với một ID nào đó, để mã hóa tin nhắn gửi cho người dùng đó. Nếu người gửi đã từng mã hóa tin nhắn cho người dùng này trước đó và đã có Khóa công khai của người dùng này, họ không cần phải yêu cầu Hợp đồng thông minh lần nữa. Khi đã có Khóa công khai, người gửi có thể sử dụng nó như bình thường để mã hóa tin nhắn, sau đó gửi tin nhắn đã mã hóa cho người nhận, người nhận sử dụng Khóa riêng tương ứng để giải mã tin nhắn và khôi phục văn bản gốc.
Chúng ta hãy xem xét ưu điểm và nhược điểm của phương pháp này:
Ưu điểmNhược điểmKhông tương tác giải mã: Quá trình giải mã không cần tương tác với bên khác, người giải mã có thể hoàn thành giải mã một cách độc lập. Không súc tích (Not succinct): Hệ thống có thể không đủ súc tích ở một số khía cạnh, có thể ý nghĩa rằng tính phức tạp cao, lượng dữ liệu lớn, hoặc cần nhiều tài nguyên hơn. Tính minh bạch: Hệ thống có thể minh bạch ở một số khía cạnh, ý nghĩa là các hoạt động là công khai, có thể được kiểm tra. Mã hóa tương tác: Quá trình mã hóa có thể cần phải tương tác với các bên khác, tăng thêm tính phức tạp. ID tùy ý: Người dùng có thể tự do chọn hoặc sử dụng bất kỳ ID người dùng tùy ý nào, mà không bị ràng buộc bởi định dạng hoặc quy tắc cụ thể. Người gửi không ẩn danh: Danh tính của người gửi có thể không thể hoàn toàn giữ ẩn danh trong hệ thống.
Dựa trên danh tính mã hóa (IBE)
Vai trò của người dùng được thể hiện bởi Khóa công khai của họ, có nghĩa là Khóa công khai không chỉ được sử dụng để mã hóa, mà còn có thể được sử dụng làm định danh duy nhất của người dùng. Tuy nhiên, phương pháp này cần phụ thuộc vào một hoặc nhiều bên thứ ba đáng tin cậy, những bên này chịu trách nhiệm tạo và phát hành Chìa khoá bảo mật. Ngoài ra, những bên thứ ba này còn cần bảo quản một Chìa khoá bảo mật chính trong suốt vòng đời của hệ thống, Chìa khoá bảo mật chính này có thể được sử dụng để giải mã hoặc thực hiện các hoạt động quan trọng khác trong một số trường hợp.
![]()
Trong hệ thống IBE, người dùng không tạo ra cặp khóa công khai và khóa riêng như trong các hệ thống mã hóa truyền thống. Thay vào đó, người dùng cần đăng ký bằng một công cụ tạo khóa bảo mật được tin cậy. Công cụ tạo khóa bảo mật có một cặp chính khóa bảo mật (bao gồm khóa riêng chính msk và khóa công khai chính mpk). Khi người dùng cung cấp ID của mình, công cụ tạo khóa bảo mật sẽ sử dụng khóa riêng chính msk và ID của người dùng để tính toán một khóa riêng độc quyền cho người dùng đó. Khóa riêng được tạo ra cần được truyền qua một kênh an toàn cho người dùng, thường là sử dụng giao thức trao đổi khóa bảo mật để thiết lập kênh an toàn này.
Đối với người gửi, hệ thống IBE đơn giản hóa quá trình mã hóa. Người gửi chỉ cần tải xuống một lần khóa công khai chính của trình tạo khóa bảo mật (mpk), sau đó có thể sử dụng ID để mã hóa tin nhắn. Đối với người nhận, giải mã cũng rất đơn giản. Người dùng đã đăng ký có thể sử dụng khóa riêng được trình tạo khóa bảo mật gửi cho họ để giải mã bản mã đã nhận được.
Khóa riêng chính của trình tạo khóa (msk) phải được lưu giữ lâu dài, vì nó cần liên tục tạo ra các khóa riêng mới cho người dùng trong quá trình hoạt động của hệ thống. Điều này khác với một số hệ thống SNARK, mà khóa riêng được tạo ra trong quá trình thiết lập được tin cậy và có thể bị hủy sau khi thiết lập hoàn tất. Trong hệ thống IBE, khóa riêng chính không thể bị xóa sau khi được khởi tạo như trong SNARK.
Ngay cả khi Khóa riêng chính (msk) được bảo quản một cách an toàn, mỗi người dùng đăng ký vẫn cần tin tưởng rằng trình tạo khóa sẽ không đọc thông điệp của họ. Điều này là vì trình tạo khóa có thể lưu trữ một bản sao của Khóa riêng người dùng bất cứ lúc nào, hoặc sử dụng Khóa riêng chính để tính toán lại Khóa riêng của người dùng.
Bộ tạo chìa khóa bảo mật cũng có thể cung cấp cho người dùng một chìa khóa riêng có vấn đề hoặc bị giới hạn, chìa khóa riêng này có thể giải mã phần lớn tin nhắn nhưng không thể giải mã một số tin nhắn cụ thể được thiết lập bởi bộ tạo chìa khóa bảo mật. Điều này có nghĩa là bộ tạo chìa khóa bảo mật có khả năng kiểm soát khả năng giải mã của người dùng, do đó có thể một mức độ nào đó kiểm soát hoặc hạn chế giao tiếp của người dùng.
Ưu điểm và nhược điểm lưu trữ on-chain: Hệ thống lưu trữ on-chain yêu cầu một lượng lưu trữ nhỏ hoặc cố định, không tăng theo thời gian. Giả định tin cậy cao: Hệ thống phụ thuộc vào một hoặc nhiều bên thứ ba đáng tin cậy, điều này có nghĩa là cần có niềm tin mạnh mẽ vào những bên thứ ba này. Nếu những bên thứ ba này bị tấn công hoặc không tin cậy, an ninh của hệ thống sẽ bị đe dọa. Mã hóa không tương tác: Quá trình mã hóa không cần tương tác với các bên khác, người gửi có thể tự mình thực hiện mã hóa. Người gửi ẩn danh: Hệ thống có thể giữ danh tính của người gửi ẩn danh, bảo vệ quyền riêng tư. ID tùy ý: Người dùng có thể tự do chọn hoặc sử dụng bất kỳ ID định danh nào, không bị giới hạn bởi định dạng hoặc quy tắc cụ thể.
Dựa trên mã hóa đăng ký (RBE)
Giống như IBE, trong hệ thống này, danh tính của người dùng (ví dụ như địa chỉ email hoặc số điện thoại) được sử dụng trực tiếp như là Khóa công khai của họ. Nhưng khác với IBE, hệ thống này không còn phụ thuộc vào một bên thứ ba đáng tin cậy hoặc một nhóm quorum để quản lý Chìa khoá bảo mật. Thay vào đó, một người quản lý chìa khoá được tin cậy thay thế bên thứ ba đáng tin cậy đó.
Tôi sẽ thảo luận về một cách hiệu quả để xây dựng RBE trong phần này, vì theo tôi biết thì nó có một ưu điểm đáng kể so với cách xây dựng RBE thực tế khác, đó là có thể triển khai on-chain vì nó dựa trên cặp, chứ không phải dựa trên lattice.
![]()
Trong hệ thống RBE, mỗi người dùng tạo ra một cặp Chìa khoá bảo mật riêng (bao gồm Khóa công khai và Khóa riêng). Người dùng cũng cần tính toán một số giá trị cập nhật (được đánh dấu trong hình là a) dựa trên Khóa riêng của họ và một chuỗi tham chiếu công cộng (CRS). Những giá trị cập nhật này được sử dụng cho các hoạt động tiếp theo trong hệ thống. Sự tồn tại của chuỗi tham chiếu công cộng (CRS) có nghĩa là cài đặt của hệ thống không hoàn toàn không cần tin cậy. Tuy nhiên, quá trình tạo ra CRS sử dụng một phương pháp xây dựng được gọi là công cụ mũ tau. Phương pháp xây dựng này có thể được tính toán on-chain thông qua sự hợp tác của nhiều bên tham gia. Miễn là ít nhất một bên tham gia là trung thực, CRS này là an toàn.
Hợp đồng thông minh为预期数量的用户 N 进行了设置，这些用户被分组到不同的 buckets 中，当用户在系统中注册时，需要向Hợp đồng thông minh发送自己的身份ID、Khóa công khai和更新值。Hợp đồng thông minh会维护一组公共参数 pp，这些公共参数不同于前面提到的公共参考字符串（CRS）。可以将 pp 理解为系统中所有已注册用户Khóa công khai的简洁摘要。Hợp đồng thông minh接收到用户的注册请求后，会对更新值进行检查，以验证它们的正确性。一旦验证通过，Hợp đồng thông minh会将该用户的Khóa công khai乘入到 pp 中的相应 buckets 中。这一步操作相当于将新用户的Khóa công khai纳入系统的公共参数集合中，以便后续操作使用。
Trong hệ thống mã hóa dựa trên đăng ký (RBE), người dùng cần lưu trữ một số thông tin cục bộ để giúp họ giải mã tin nhắn. Khi có người dùng mới đăng ký vào cùng nhóm với họ, thông tin này cần được cập nhật. Người dùng có thể tự theo dõi Khối chuỗi để cập nhật thông tin này thủ công, hoặc Hợp đồng thông minh có thể cung cấp thông tin người dùng đăng ký gần đây, người dùng có thể định kỳ nhận các cập nhật này để giữ cho thông tin giải mã của họ luôn mới nhất.
Trong hệ thống này, người gửi chỉ cần làm hai việc:
Tải xuống chuỗi tham chiếu công cộng (CRS): chỉ cần tải xuống một lần, sau đó không cần cập nhật lại.
Tải xuống tham số công cộng: Người gửi cần thỉnh thoảng tải xuống các tham số công cộng mới nhất. Đối với người gửi, quan trọng là các tham số công cộng này chứa khóa công khai của người nhận, không cần phải tải xuống phiên bản mới mỗi lần, chỉ cần tìm thấy khóa công khai của người nhận là được.
Sau đó, người gửi sử dụng CRS đã tải xuống, tham số công khai và ID của người nhận để mã hóa tin nhắn và gửi cho người nhận. Điều này có nghĩa là người gửi không cần phải cập nhật dữ liệu thường xuyên, chỉ cần đảm bảo rằng tham số công khai có chứa Khóa công khai của người nhận.
Khi người dùng nhận được một thông điệp mã hóa, trước tiên họ sẽ kiểm tra thông tin hỗ trợ được lưu trữ cục bộ của mình để xem liệu có giá trị nào đáp ứng điều kiện nào đó (ví dụ như giá trị được kiểm tra qua một quy trình xác thực) hay không. Nếu người dùng không tìm thấy giá trị phù hợp với điều kiện trong máy cục bộ, điều này có nghĩa là họ cần lấy thông tin cập nhật mới nhất từ hợp đồng thông minh. Khi người dùng tìm thấy giá trị thông tin hỗ trợ phù hợp, họ có thể sử dụng giá trị này và khóa riêng của mình để giải mã thông điệp mã hóa nhận được và khôi phục lại thông điệp ban đầu.
Rõ ràng, giải pháp này phức tạp hơn hai giải pháp khác. Tuy nhiên, nó yêu cầu ít lưu trữ on-chain hơn thư mục Khóa công khai và tránh giả định tin cậy mạnh của IBE.
Các tham số đơn giản:
- Mối quan hệ giữa kích thước tham số được lưu trữ trên on-chain và số lượng người dùng là siêu tuyến tính, điều này nhỏ hơn nhiều so với lượng lưu trữ cần thiết cho Khóa công khai (tăng lên tuyến tính), nhưng vẫn không phải là hằng số, do đó ở điểm này không bằng hệ thống mã hóa dựa trên danh tính (IBE).
Mã hóa có tương tác:
- Khi gửi tin nhắn, người gửi cần một bản sao tham số công khai chứa thông tin người nhận. Điều này có nghĩa là người gửi cần cập nhật các tham số này vào một thời điểm sau khi người nhận đăng ký, nhưng không cần cập nhật riêng lẻ cho mỗi người nhận vì một lần cập nhật có thể chứa nhiều chìa khoá bảo mật của nhiều người nhận. Nói chung, giao tiếp khi gửi tin nhắn có tính tương tác cao hơn IBE, nhưng ít hơn so với việc sử dụng danh mục khóa công khai.
Giải mã tương tác:
- Tương tự như mã hóa, người nhận cần một số thông tin phụ trợ phải khớp với phiên bản tham số công cộng được sử dụng khi mã hóa. Khi có người dùng mới đăng ký trong một nhóm nào đó, các tham số công cộng và thông tin phụ trợ sẽ được cập nhật, có thể giải mã giá trị Bản mã tương ứng với phiên bản tham số công cộng được sử dụng khi mã hóa. Người dùng có thể chọn cách thường xuyên cập nhật thông tin phụ trợ, thay vì cập nhật ngay lập tức mỗi lần, trừ khi quá trình giải mã thất bại. Khác với việc cập nhật tham số công cộng, việc cập nhật thông tin phụ trợ thường xuyên hơn sẽ không tiết lộ thông tin riêng tư.
Người gửi ẩn danh:
- Tương tự như trường hợp thư mục khóa công khai, người gửi có thể mã hóa tin nhắn một cách độc lập (miễn là nó có các tham số mới nhất) mà không cần truy vấn thông tin cụ thể về người nhận. Khi người gửi cần đọc thông tin từ chuỗi, nó không liên quan đến người nhận dự định (trừ khi người gửi chỉ yêu cầu một tham số cụ thể được nhóm, có thể tiết lộ một số thông tin).
Transparency:
- Mặc dù hệ thống cần được thiết lập thông qua cài đặt tin cậy (có thể là quản lý phân tán hoặc bên ngoài) và tạo ra một CRS điều chỉnh (Chuỗi tham chiếu công cộng), nhưng một khi thiết lập hoàn tất, nó sẽ không phụ thuộc vào bất kỳ bên thứ ba tin cậy hoặc nhóm trọng tài nào. Mặc dù nó phụ thuộc vào một bên thứ ba điều phối (hợp đồng thông minh), nhưng hệ thống này hoàn toàn minh bạch, bất kỳ ai cũng có thể đóng vai trò người điều phối hoặc kiểm tra xem nó có hoạt động trung thực thông qua việc xác minh trạng thái chuyển đổi (điều này cũng là lý do tại sao nó có thể triển khai như hợp đồng thông minh). Ngoài ra, người dùng cũng có thể yêu cầu một chứng nhận thành viên (không) đơn giản để kiểm tra xem họ hoặc người khác có đăng ký trong hệ thống hay không. Điều này khác biệt so với hệ thống IBE, trong IBE, việc làm cho bên thứ ba tin cậy chứng minh rằng họ không tiết lộ bí mật chìa khóa bảo mật (ví dụ, lưu trữ một bản sao bí mật hoặc tiết lộ cho người khác) là khó khăn. Ngược lại, thư mục khóa công khai hoàn toàn minh bạch.
Bộ sưu tập ID bị hạn chế:
- Đây là phiên bản cơ bản của RBE được mô tả ở đây. Để xác định một ID thuộc về nhóm nào một cách minh bạch, ID phải có một thứ tự chung và xác định. Số điện thoại có thể được sắp xếp một cách đơn giản, nhưng việc sắp xếp chuỗi bất kỳ có thể rất phức tạp hoặc thậm chí không thể, vì số lượng nhóm có thể rất lớn hoặc vô hạn. Điều này có thể được giải quyết bằng cách cung cấp một hợp đồng độc lập để tính toán ánh xạ này, hoặc áp dụng phương pháp cuckoo-hashing được đề xuất trong công việc tiếp theo để giảm bớt sự phức tạp này.
Người nhận ẩn danh：
- Phương pháp này có thể ngăn chặn việc tiết lộ danh tính của người nhận Bản mã.
