Việc áp dụng công nghệ zk-SNARK trong hệ thống xác minh kỹ thuật số để bảo vệ quyền riêng tư đã trở thành một thực tiễn phổ biến. Nhiều dự án xác minh kỹ thuật số dựa trên zk-SNARK đang phát triển các gói phần mềm thân thiện với người dùng, cho phép người dùng chứng minh rằng họ sở hữu danh tính hợp lệ mà không cần tiết lộ chi tiết danh tính. Số lượng người dùng World ID được xác minh bằng công nghệ sinh trắc học và bảo mật quyền riêng tư thông qua zk-SNARK gần đây đã vượt qua 10 triệu. Một số dự án xác minh kỹ thuật số của chính phủ cũng bắt đầu áp dụng công nghệ zk-SNARK.
Bề ngoài, việc áp dụng rộng rãi danh tính kỹ thuật số dựa trên zk-SNARK dường như là một chiến thắng lớn cho nguyên tắc phi tập trung hóa (d/acc). Nó có thể bảo vệ mạng xã hội, hệ thống bỏ phiếu và các dịch vụ Internet khác của chúng ta khỏi các cuộc tấn công của phù thủy và sự thao túng của robot mà không hy sinh quyền riêng tư. Nhưng liệu mọi thứ có đơn giản như vậy không? Danh tính dựa trên zk-SNARK có còn tồn tại rủi ro không? Bài viết này sẽ trình bày những quan điểm sau:
zk-SNARK đóng gói đã giải quyết nhiều vấn đề quan trọng.
Danh tính được đóng gói bằng zk-SNARK vẫn tồn tại rủi ro. Những rủi ro này chủ yếu xuất phát từ việc duy trì nghiêm ngặt thuộc tính "một người một danh tính".
Chỉ sử dụng "chứng minh tài sản" để chống lại các cuộc tấn công của phù thủy là không đủ trong hầu hết các tình huống, chúng ta cần một giải pháp "giống như danh tính".
Trạng thái lý tưởng là chi phí để có N danh tính là N².
Danh tính đa dạng là giải pháp thực tế nhất. Danh tính đa dạng có thể là danh tính rõ ràng ( như danh tính dựa trên mạng xã hội ), cũng có thể là danh tính dạng ẩn ( với nhiều loại xác minh kỹ thuật số đồng tồn tại ).
zk-SNARK đóng gói danh tính hoạt động như thế nào?
Hãy tưởng tượng rằng bạn đã có được World ID bằng cách quét võng mạc, hoặc nhận diện danh tính dựa trên hộ chiếu bằng cách đọc qua NFC trên điện thoại. Trong điện thoại của bạn có một giá trị bí mật s. Trong sổ đăng ký toàn cầu trên chuỗi có một giá trị băm công khai H(s). Khi đăng nhập vào ứng dụng, bạn sẽ tạo ra một ID người dùng cụ thể cho ứng dụng đó, tức là H(s, app_name), và xác minh qua zk-SNARK: ID này có nguồn gốc từ cùng một giá trị bí mật s với một giá trị băm công khai nào đó trong sổ đăng ký. Do đó, mỗi giá trị băm công khai chỉ có thể tạo ra một ID cho mỗi ứng dụng, nhưng sẽ không bao giờ tiết lộ ID độc quyền của một ứng dụng tương ứng với giá trị băm công khai nào.
Trên thực tế, thiết kế có thể phức tạp hơn một chút. Trong World ID, ID ứng dụng độc quyền thực chất là giá trị băm của ID ứng dụng và ID phiên, do đó các thao tác khác nhau trong cùng một ứng dụng cũng có thể được giải liên kết với nhau. Thiết kế dựa trên zk-SNARK cũng có thể được xây dựng theo cách tương tự.
zk-SNARK bản thân không thể đạt được tính ẩn danh
Giả sử một nền tảng danh tính bằng zk-SNARK hoạt động hoàn toàn theo mong đợi, tái hiện tất cả các logic ở trên một cách nghiêm ngặt, thậm chí đã tìm ra cách có thể bảo vệ thông tin riêng tư của người dùng không có kỹ thuật trong thời gian dài mà không phụ thuộc vào các tổ chức tập trung. Nhưng trong khi đó, chúng ta có thể đưa ra một giả thuyết gần gũi với thực tế: các ứng dụng sẽ không chủ động phối hợp với việc bảo vệ quyền riêng tư, chúng sẽ tuân thủ nguyên tắc "chủ nghĩa thực dụng", các giải pháp thiết kế mà chúng áp dụng mặc dù mang danh "tối đa hóa sự thuận tiện cho người dùng", thực tế dường như luôn có xu hướng nghiêng về lợi ích chính trị và thương mại của chính chúng.
Trong bối cảnh như vậy, các ứng dụng mạng xã hội sẽ không sử dụng thiết kế phức tạp như thay đổi thường xuyên khóa phiên, mà thay vào đó phân bổ cho mỗi người dùng một ID ứng dụng độc quyền duy nhất, và do hệ thống danh tính tuân theo quy tắc "mỗi người một danh tính", người dùng chỉ có thể sở hữu một tài khoản. Trong thế giới thực, việc đạt được tính ẩn danh thường cần nhiều tài khoản: một tài khoản cho "danh tính thông thường", các tài khoản khác cho nhiều danh tính ẩn danh khác nhau. Do đó, trong mô hình này, tính ẩn danh mà người dùng thực sự có thể đạt được có thể thấp hơn mức hiện tại. Như vậy, ngay cả hệ thống "mỗi người một danh tính" được bao bọc bởi zk-SNARK cũng có thể khiến chúng ta dần dần tiến đến một thế giới mà tất cả các hoạt động đều phải gắn liền với một danh tính công khai duy nhất. Trong thời đại rủi ro gia tăng này, việc tước đi quyền lựa chọn của mọi người để bảo vệ bản thân qua tính ẩn danh sẽ mang lại những tác động tiêu cực nghiêm trọng.
zk-SNARK bản thân không thể bảo vệ bạn khỏi sự cưỡng ép
Ngay cả khi bạn không công khai giá trị bí mật của mình s, không ai có thể thấy mối liên hệ công khai giữa các tài khoản của bạn, nhưng nếu có ai đó buộc bạn phải công khai thì sao? Chính phủ có thể yêu cầu tiết lộ giá trị bí mật của bạn để xem tất cả các hoạt động của bạn. Đây không phải là nói suông: một số quốc gia đã bắt đầu yêu cầu người xin visa công khai tài khoản mạng xã hội của họ. Hơn nữa, nhà tuyển dụng cũng có thể dễ dàng đặt điều kiện tuyển dụng là phải tiết lộ thông tin công khai đầy đủ. Thậm chí, một số ứng dụng ở cấp độ kỹ thuật cũng có thể yêu cầu người dùng tiết lộ danh tính của họ trên các ứng dụng khác trước khi cho phép đăng ký sử dụng.
Tương tự, trong những trường hợp này, giá trị của thuộc tính zk-SNARK đã biến mất, nhưng nhược điểm của thuộc tính mới "mỗi người một tài khoản" vẫn còn tồn tại.
Chúng ta có thể giảm thiểu rủi ro bị ép buộc thông qua việc tối ưu hóa thiết kế: ví dụ, áp dụng cơ chế tính toán đa bên để tạo ra ID riêng cho từng ứng dụng, cho phép người dùng và bên dịch vụ cùng tham gia. Như vậy, nếu không có sự tham gia của bên điều hành ứng dụng, người dùng sẽ không thể chứng minh ID riêng của mình trong ứng dụng đó. Điều này sẽ làm tăng độ khó trong việc ép buộc người khác tiết lộ danh tính đầy đủ, nhưng không thể hoàn toàn loại bỏ khả năng này, và các giải pháp này cũng có những nhược điểm khác, chẳng hạn như yêu cầu nhà phát triển ứng dụng phải là thực thể hoạt động liên tục, chứ không giống như hợp đồng thông minh trên chuỗi thụ động.
zk-SNARK bản thân không thể giải quyết các rủi ro không thuộc về quyền riêng tư
Tất cả các hình thức danh tính đều có các trường hợp biên:
Dựa trên danh tính do chính phủ cấp, bao gồm hộ chiếu, không thể bao trùm những người không quốc tịch và cũng không bao gồm những người chưa có được các giấy tờ như vậy.
Mặt khác, hệ thống danh tính dựa trên chính phủ này sẽ trao cho những người có nhiều quốc tịch những đặc quyền độc đáo.
Cơ quan cấp hộ chiếu có thể bị tấn công bởi hacker, thậm chí các cơ quan tình báo của các quốc gia thù địch có thể làm giả một lượng lớn danh tính giả.
Đối với những người có đặc điểm sinh học liên quan bị tổn hại do bệnh tật, danh tính sinh trắc học sẽ hoàn toàn không còn hiệu lực.
Danh tính sinh trắc học rất có thể bị đánh lừa bởi hàng giả. Nếu giá trị của danh tính sinh trắc học trở nên cực cao, chúng ta thậm chí có thể thấy ai đó chuyên nuôi cấy cơ quan con người, chỉ để "sản xuất hàng loạt" loại danh tính này.
Những trường hợp biên này gây hại lớn nhất trong các hệ thống cố gắng duy trì thuộc tính "mỗi người một danh tính", và chúng không liên quan gì đến quyền riêng tư. Do đó, zk-SNARK không thể làm gì với điều này.
Dựa vào "chứng minh tài sản" để phòng ngừa tấn công phù thủy thì không đủ để giải quyết vấn đề, vì vậy chúng ta cần một hình thức nào đó của hệ thống danh tính.
Trong cộng đồng hacker mã hóa thuần túy, một giải pháp thay thế phổ biến là: hoàn toàn dựa vào "bằng chứng tài sản" để phòng ngừa các cuộc tấn công phù thủy, thay vì xây dựng bất kỳ hình thức hệ thống danh tính nào. Bằng cách yêu cầu mỗi tài khoản phải phát sinh một chi phí nhất định, có thể ngăn chặn ai đó dễ dàng tạo ra nhiều tài khoản. Cách làm này đã có tiền lệ trên Internet, chẳng hạn như một số diễn đàn yêu cầu tài khoản đăng ký phải trả một khoản phí một lần, nếu tài khoản bị cấm, khoản phí này sẽ không được hoàn lại.
Về lý thuyết, thậm chí có thể làm cho việc thanh toán có tính điều kiện: khi đăng ký tài khoản, bạn chỉ cần ký quỹ một khoản tiền, chỉ mất khoản tiền này trong những trường hợp hiếm hoi như tài khoản bị cấm. Về lý thuyết, điều này có thể làm tăng đáng kể chi phí tấn công.
Giải pháp này có hiệu quả rõ rệt trong nhiều tình huống, nhưng hoàn toàn không khả thi trong một số loại tình huống nhất định. Tôi sẽ tập trung thảo luận về hai loại tình huống, tạm gọi là "tình huống giống như thu nhập cơ bản toàn dân" và "tình huống giống như quản trị".
Nhu cầu về danh tính trong bối cảnh thu nhập cơ bản toàn dân
Khái niệm "kịch bản thu nhập cơ bản gần như toàn cầu" đề cập đến việc cần phát hành một số lượng tài sản hoặc dịch vụ cho một nhóm người dùng rất rộng lớn, mà không xem xét khả năng thanh toán của họ. Một số dự án đang thực hiện điều này một cách hệ thống: bất kỳ ai có danh tính cụ thể đều có thể nhận được một lượng token nhỏ định kỳ. Nhiều airdrop token cũng đạt được mục tiêu tương tự theo cách ít chính thức hơn, cố gắng để ít nhất một phần token rơi vào tay càng nhiều người dùng càng tốt.
Loại "thu nhập cơ bản toàn cầu nhỏ" này có thể giải quyết vấn đề thực tế là: giúp mọi người có đủ số lượng tiền điện tử để thực hiện một số giao dịch cơ bản trên chuỗi và mua sắm trực tuyến. Cụ thể có thể bao gồm:
Lấy tên ENS
Xuất bản băm trên chuỗi để khởi tạo một danh tính zk-SNARK
Thanh toán phí nền tảng mạng xã hội
Nếu tiền điện tử được áp dụng rộng rãi trên toàn cầu, vấn đề này sẽ không còn tồn tại. Nhưng trong bối cảnh tiền điện tử chưa phổ biến, đây có thể là cách duy nhất để mọi người tiếp cận các ứng dụng phi tài chính trên chuỗi và các dịch vụ hàng hóa trực tuyến liên quan, nếu không họ có thể hoàn toàn không tiếp cận được những tài nguyên này.
Ngoài ra, còn một cách khác có thể đạt được hiệu ứng tương tự, đó là "dịch vụ cơ bản toàn dân": cung cấp cho mỗi người có danh tính quyền gửi một số lượng giao dịch miễn phí hạn chế trong các ứng dụng cụ thể. Cách này có thể phù hợp hơn với cơ chế khuyến khích và có hiệu quả vốn cao hơn, vì mỗi ứng dụng hưởng lợi từ sự áp dụng này có thể làm như vậy mà không cần phải trả tiền cho người không dùng; tuy nhiên, điều này cũng đi kèm với một số đánh đổi, tức là tính phổ quát sẽ giảm. Nhưng ngay cả như vậy, vẫn cần một giải pháp danh tính để ngăn chặn hệ thống khỏi các cuộc tấn công thông tin rác, đồng thời tránh tạo ra tính loại trừ, mà tính loại trừ này phát sinh từ việc yêu cầu người dùng phải thanh toán qua một hình thức nào đó, và hình thức thanh toán này có thể không phải ai cũng có thể sử dụng.
Một loại quan trọng cuối cùng cần được nhấn mạnh là "mức ký quỹ cơ bản cho mọi người". Một trong những chức năng của danh tính là cung cấp một đối tượng có thể được sử dụng để truy cứu trách nhiệm mà không cần người dùng phải ký quỹ số tiền tương đương với quy mô khuyến khích. Điều này cũng giúp đạt được một mục tiêu: giảm sự phụ thuộc của ngưỡng tham gia vào khối lượng vốn cá nhân.
Nhu cầu về danh tính trong các tình huống quản lý
Hãy tưởng tượng một hệ thống bỏ phiếu: nếu nguồn lực của người dùng A gấp 10 lần của người dùng B, thì quyền bỏ phiếu của A cũng sẽ gấp 10 lần của B. Tuy nhiên, từ góc độ kinh tế, lợi ích mà mỗi đơn vị quyền bỏ phiếu mang lại cho A là gấp 10 lần lợi ích mà nó mang lại cho B. Do đó, tổng thể mà nói, lợi ích từ việc bỏ phiếu của A cho chính mình là gấp 100 lần lợi ích từ việc bỏ phiếu của B cho chính mình. Chính vì lý do này, chúng ta sẽ thấy A sẽ投入 nhiều năng lượng hơn để tham gia bỏ phiếu, nghiên cứu cách bỏ phiếu để tối đa hóa mục tiêu của mình, thậm chí có thể chiến lược thao túng thuật toán. Đây cũng là lý do cơ bản khiến "cá voi" có thể tạo ra ảnh hưởng quá mức trong cơ chế bỏ phiếu token.
Lý do phổ biến hơn và sâu sắc hơn là: hệ thống quản trị không nên coi "một người kiểm soát 100.000 đô la" và "1000 người cùng sở hữu 100.000 đô la" có trọng số như nhau. Cái sau đại diện cho 1000 cá nhân độc lập, do đó sẽ chứa đựng nhiều thông tin giá trị phong phú hơn, thay vì thông tin có quy mô nhỏ với sự lặp lại cao. Tín hiệu từ 1000 người cũng thường "ôn hòa" hơn, vì ý kiến của các cá nhân khác nhau thường sẽ tự triệt tiêu lẫn nhau.
Điều này áp dụng cho cả hệ thống bỏ phiếu chính thức và "hệ thống bỏ phiếu không chính thức", chẳng hạn như khả năng của mọi người tham gia vào sự tiến hóa văn hóa thông qua việc lên tiếng công khai.
Điều này cho thấy, các hệ thống quản trị kiểu này sẽ không thực sự hài lòng với cách tiếp cận "không phân biệt nguồn vốn, các nhóm vốn cùng quy mô đều được đối xử như nhau". Hệ thống thực sự cần phải hiểu mức độ phối hợp nội bộ của các nhóm vốn này.
Cần lưu ý rằng, nếu bạn đồng ý với khung mô tả mà tôi đã trình bày cho hai loại tình huống trên, thì từ góc độ kỹ thuật, nhu cầu về quy tắc rõ ràng "mỗi người một phiếu" sẽ không còn nữa.
Đối với các ứng dụng của mô hình thu nhập cơ bản toàn dân, giải pháp danh tính thực sự cần thiết là: danh tính đầu tiên miễn phí, giới hạn số lượng danh tính có thể lấy được. Khi chi phí để có được nhiều danh tính hơn cao đến mức khiến hành vi tấn công hệ thống trở nên vô nghĩa, thì hiệu ứng giới hạn đã đạt được.
Đối với các ứng dụng trong bối cảnh quản trị, nhu cầu cốt lõi là: có thể thông qua một chỉ số gián tiếp để xác định, nguồn tài nguyên mà bạn đang tiếp xúc, có phải là do một chủ thể thao tác duy nhất điều khiển, hay là một nhóm "hình thành tự nhiên" với mức độ phối hợp thấp.
Trong hai tình huống này, danh tính vẫn rất hữu ích, nhưng cần tuân thủ "một người một danh tính".
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
6 thích
Phần thưởng
6
4
Đăng lại
Chia sẻ
Bình luận
0/400
ShitcoinConnoisseur
· 08-06 15:36
Bảo vệ quyền riêng tư rất khó để thực hiện một cách triệt để
Xem bản gốcTrả lời0
BearMarketSurvivor
· 08-06 15:35
Bảo mật và quyền riêng tư khó mà cùng lúc đạt được
zk-SNARK xác minh kỹ thuật số của những vấn đề về quyền riêng tư và các giải pháp đa dạng
zk-SNARK xác minh kỹ thuật số của nhiều thử thách
Việc áp dụng công nghệ zk-SNARK trong hệ thống xác minh kỹ thuật số để bảo vệ quyền riêng tư đã trở thành một thực tiễn phổ biến. Nhiều dự án xác minh kỹ thuật số dựa trên zk-SNARK đang phát triển các gói phần mềm thân thiện với người dùng, cho phép người dùng chứng minh rằng họ sở hữu danh tính hợp lệ mà không cần tiết lộ chi tiết danh tính. Số lượng người dùng World ID được xác minh bằng công nghệ sinh trắc học và bảo mật quyền riêng tư thông qua zk-SNARK gần đây đã vượt qua 10 triệu. Một số dự án xác minh kỹ thuật số của chính phủ cũng bắt đầu áp dụng công nghệ zk-SNARK.
Bề ngoài, việc áp dụng rộng rãi danh tính kỹ thuật số dựa trên zk-SNARK dường như là một chiến thắng lớn cho nguyên tắc phi tập trung hóa (d/acc). Nó có thể bảo vệ mạng xã hội, hệ thống bỏ phiếu và các dịch vụ Internet khác của chúng ta khỏi các cuộc tấn công của phù thủy và sự thao túng của robot mà không hy sinh quyền riêng tư. Nhưng liệu mọi thứ có đơn giản như vậy không? Danh tính dựa trên zk-SNARK có còn tồn tại rủi ro không? Bài viết này sẽ trình bày những quan điểm sau:
zk-SNARK đóng gói danh tính hoạt động như thế nào?
Hãy tưởng tượng rằng bạn đã có được World ID bằng cách quét võng mạc, hoặc nhận diện danh tính dựa trên hộ chiếu bằng cách đọc qua NFC trên điện thoại. Trong điện thoại của bạn có một giá trị bí mật s. Trong sổ đăng ký toàn cầu trên chuỗi có một giá trị băm công khai H(s). Khi đăng nhập vào ứng dụng, bạn sẽ tạo ra một ID người dùng cụ thể cho ứng dụng đó, tức là H(s, app_name), và xác minh qua zk-SNARK: ID này có nguồn gốc từ cùng một giá trị bí mật s với một giá trị băm công khai nào đó trong sổ đăng ký. Do đó, mỗi giá trị băm công khai chỉ có thể tạo ra một ID cho mỗi ứng dụng, nhưng sẽ không bao giờ tiết lộ ID độc quyền của một ứng dụng tương ứng với giá trị băm công khai nào.
Trên thực tế, thiết kế có thể phức tạp hơn một chút. Trong World ID, ID ứng dụng độc quyền thực chất là giá trị băm của ID ứng dụng và ID phiên, do đó các thao tác khác nhau trong cùng một ứng dụng cũng có thể được giải liên kết với nhau. Thiết kế dựa trên zk-SNARK cũng có thể được xây dựng theo cách tương tự.
zk-SNARK bản thân không thể đạt được tính ẩn danh
Giả sử một nền tảng danh tính bằng zk-SNARK hoạt động hoàn toàn theo mong đợi, tái hiện tất cả các logic ở trên một cách nghiêm ngặt, thậm chí đã tìm ra cách có thể bảo vệ thông tin riêng tư của người dùng không có kỹ thuật trong thời gian dài mà không phụ thuộc vào các tổ chức tập trung. Nhưng trong khi đó, chúng ta có thể đưa ra một giả thuyết gần gũi với thực tế: các ứng dụng sẽ không chủ động phối hợp với việc bảo vệ quyền riêng tư, chúng sẽ tuân thủ nguyên tắc "chủ nghĩa thực dụng", các giải pháp thiết kế mà chúng áp dụng mặc dù mang danh "tối đa hóa sự thuận tiện cho người dùng", thực tế dường như luôn có xu hướng nghiêng về lợi ích chính trị và thương mại của chính chúng.
Trong bối cảnh như vậy, các ứng dụng mạng xã hội sẽ không sử dụng thiết kế phức tạp như thay đổi thường xuyên khóa phiên, mà thay vào đó phân bổ cho mỗi người dùng một ID ứng dụng độc quyền duy nhất, và do hệ thống danh tính tuân theo quy tắc "mỗi người một danh tính", người dùng chỉ có thể sở hữu một tài khoản. Trong thế giới thực, việc đạt được tính ẩn danh thường cần nhiều tài khoản: một tài khoản cho "danh tính thông thường", các tài khoản khác cho nhiều danh tính ẩn danh khác nhau. Do đó, trong mô hình này, tính ẩn danh mà người dùng thực sự có thể đạt được có thể thấp hơn mức hiện tại. Như vậy, ngay cả hệ thống "mỗi người một danh tính" được bao bọc bởi zk-SNARK cũng có thể khiến chúng ta dần dần tiến đến một thế giới mà tất cả các hoạt động đều phải gắn liền với một danh tính công khai duy nhất. Trong thời đại rủi ro gia tăng này, việc tước đi quyền lựa chọn của mọi người để bảo vệ bản thân qua tính ẩn danh sẽ mang lại những tác động tiêu cực nghiêm trọng.
zk-SNARK bản thân không thể bảo vệ bạn khỏi sự cưỡng ép
Ngay cả khi bạn không công khai giá trị bí mật của mình s, không ai có thể thấy mối liên hệ công khai giữa các tài khoản của bạn, nhưng nếu có ai đó buộc bạn phải công khai thì sao? Chính phủ có thể yêu cầu tiết lộ giá trị bí mật của bạn để xem tất cả các hoạt động của bạn. Đây không phải là nói suông: một số quốc gia đã bắt đầu yêu cầu người xin visa công khai tài khoản mạng xã hội của họ. Hơn nữa, nhà tuyển dụng cũng có thể dễ dàng đặt điều kiện tuyển dụng là phải tiết lộ thông tin công khai đầy đủ. Thậm chí, một số ứng dụng ở cấp độ kỹ thuật cũng có thể yêu cầu người dùng tiết lộ danh tính của họ trên các ứng dụng khác trước khi cho phép đăng ký sử dụng.
Tương tự, trong những trường hợp này, giá trị của thuộc tính zk-SNARK đã biến mất, nhưng nhược điểm của thuộc tính mới "mỗi người một tài khoản" vẫn còn tồn tại.
Chúng ta có thể giảm thiểu rủi ro bị ép buộc thông qua việc tối ưu hóa thiết kế: ví dụ, áp dụng cơ chế tính toán đa bên để tạo ra ID riêng cho từng ứng dụng, cho phép người dùng và bên dịch vụ cùng tham gia. Như vậy, nếu không có sự tham gia của bên điều hành ứng dụng, người dùng sẽ không thể chứng minh ID riêng của mình trong ứng dụng đó. Điều này sẽ làm tăng độ khó trong việc ép buộc người khác tiết lộ danh tính đầy đủ, nhưng không thể hoàn toàn loại bỏ khả năng này, và các giải pháp này cũng có những nhược điểm khác, chẳng hạn như yêu cầu nhà phát triển ứng dụng phải là thực thể hoạt động liên tục, chứ không giống như hợp đồng thông minh trên chuỗi thụ động.
zk-SNARK bản thân không thể giải quyết các rủi ro không thuộc về quyền riêng tư
Tất cả các hình thức danh tính đều có các trường hợp biên:
Những trường hợp biên này gây hại lớn nhất trong các hệ thống cố gắng duy trì thuộc tính "mỗi người một danh tính", và chúng không liên quan gì đến quyền riêng tư. Do đó, zk-SNARK không thể làm gì với điều này.
Dựa vào "chứng minh tài sản" để phòng ngừa tấn công phù thủy thì không đủ để giải quyết vấn đề, vì vậy chúng ta cần một hình thức nào đó của hệ thống danh tính.
Trong cộng đồng hacker mã hóa thuần túy, một giải pháp thay thế phổ biến là: hoàn toàn dựa vào "bằng chứng tài sản" để phòng ngừa các cuộc tấn công phù thủy, thay vì xây dựng bất kỳ hình thức hệ thống danh tính nào. Bằng cách yêu cầu mỗi tài khoản phải phát sinh một chi phí nhất định, có thể ngăn chặn ai đó dễ dàng tạo ra nhiều tài khoản. Cách làm này đã có tiền lệ trên Internet, chẳng hạn như một số diễn đàn yêu cầu tài khoản đăng ký phải trả một khoản phí một lần, nếu tài khoản bị cấm, khoản phí này sẽ không được hoàn lại.
Về lý thuyết, thậm chí có thể làm cho việc thanh toán có tính điều kiện: khi đăng ký tài khoản, bạn chỉ cần ký quỹ một khoản tiền, chỉ mất khoản tiền này trong những trường hợp hiếm hoi như tài khoản bị cấm. Về lý thuyết, điều này có thể làm tăng đáng kể chi phí tấn công.
Giải pháp này có hiệu quả rõ rệt trong nhiều tình huống, nhưng hoàn toàn không khả thi trong một số loại tình huống nhất định. Tôi sẽ tập trung thảo luận về hai loại tình huống, tạm gọi là "tình huống giống như thu nhập cơ bản toàn dân" và "tình huống giống như quản trị".
Nhu cầu về danh tính trong bối cảnh thu nhập cơ bản toàn dân
Khái niệm "kịch bản thu nhập cơ bản gần như toàn cầu" đề cập đến việc cần phát hành một số lượng tài sản hoặc dịch vụ cho một nhóm người dùng rất rộng lớn, mà không xem xét khả năng thanh toán của họ. Một số dự án đang thực hiện điều này một cách hệ thống: bất kỳ ai có danh tính cụ thể đều có thể nhận được một lượng token nhỏ định kỳ. Nhiều airdrop token cũng đạt được mục tiêu tương tự theo cách ít chính thức hơn, cố gắng để ít nhất một phần token rơi vào tay càng nhiều người dùng càng tốt.
Loại "thu nhập cơ bản toàn cầu nhỏ" này có thể giải quyết vấn đề thực tế là: giúp mọi người có đủ số lượng tiền điện tử để thực hiện một số giao dịch cơ bản trên chuỗi và mua sắm trực tuyến. Cụ thể có thể bao gồm:
Nếu tiền điện tử được áp dụng rộng rãi trên toàn cầu, vấn đề này sẽ không còn tồn tại. Nhưng trong bối cảnh tiền điện tử chưa phổ biến, đây có thể là cách duy nhất để mọi người tiếp cận các ứng dụng phi tài chính trên chuỗi và các dịch vụ hàng hóa trực tuyến liên quan, nếu không họ có thể hoàn toàn không tiếp cận được những tài nguyên này.
Ngoài ra, còn một cách khác có thể đạt được hiệu ứng tương tự, đó là "dịch vụ cơ bản toàn dân": cung cấp cho mỗi người có danh tính quyền gửi một số lượng giao dịch miễn phí hạn chế trong các ứng dụng cụ thể. Cách này có thể phù hợp hơn với cơ chế khuyến khích và có hiệu quả vốn cao hơn, vì mỗi ứng dụng hưởng lợi từ sự áp dụng này có thể làm như vậy mà không cần phải trả tiền cho người không dùng; tuy nhiên, điều này cũng đi kèm với một số đánh đổi, tức là tính phổ quát sẽ giảm. Nhưng ngay cả như vậy, vẫn cần một giải pháp danh tính để ngăn chặn hệ thống khỏi các cuộc tấn công thông tin rác, đồng thời tránh tạo ra tính loại trừ, mà tính loại trừ này phát sinh từ việc yêu cầu người dùng phải thanh toán qua một hình thức nào đó, và hình thức thanh toán này có thể không phải ai cũng có thể sử dụng.
Một loại quan trọng cuối cùng cần được nhấn mạnh là "mức ký quỹ cơ bản cho mọi người". Một trong những chức năng của danh tính là cung cấp một đối tượng có thể được sử dụng để truy cứu trách nhiệm mà không cần người dùng phải ký quỹ số tiền tương đương với quy mô khuyến khích. Điều này cũng giúp đạt được một mục tiêu: giảm sự phụ thuộc của ngưỡng tham gia vào khối lượng vốn cá nhân.
Nhu cầu về danh tính trong các tình huống quản lý
Hãy tưởng tượng một hệ thống bỏ phiếu: nếu nguồn lực của người dùng A gấp 10 lần của người dùng B, thì quyền bỏ phiếu của A cũng sẽ gấp 10 lần của B. Tuy nhiên, từ góc độ kinh tế, lợi ích mà mỗi đơn vị quyền bỏ phiếu mang lại cho A là gấp 10 lần lợi ích mà nó mang lại cho B. Do đó, tổng thể mà nói, lợi ích từ việc bỏ phiếu của A cho chính mình là gấp 100 lần lợi ích từ việc bỏ phiếu của B cho chính mình. Chính vì lý do này, chúng ta sẽ thấy A sẽ投入 nhiều năng lượng hơn để tham gia bỏ phiếu, nghiên cứu cách bỏ phiếu để tối đa hóa mục tiêu của mình, thậm chí có thể chiến lược thao túng thuật toán. Đây cũng là lý do cơ bản khiến "cá voi" có thể tạo ra ảnh hưởng quá mức trong cơ chế bỏ phiếu token.
Lý do phổ biến hơn và sâu sắc hơn là: hệ thống quản trị không nên coi "một người kiểm soát 100.000 đô la" và "1000 người cùng sở hữu 100.000 đô la" có trọng số như nhau. Cái sau đại diện cho 1000 cá nhân độc lập, do đó sẽ chứa đựng nhiều thông tin giá trị phong phú hơn, thay vì thông tin có quy mô nhỏ với sự lặp lại cao. Tín hiệu từ 1000 người cũng thường "ôn hòa" hơn, vì ý kiến của các cá nhân khác nhau thường sẽ tự triệt tiêu lẫn nhau.
Điều này áp dụng cho cả hệ thống bỏ phiếu chính thức và "hệ thống bỏ phiếu không chính thức", chẳng hạn như khả năng của mọi người tham gia vào sự tiến hóa văn hóa thông qua việc lên tiếng công khai.
Điều này cho thấy, các hệ thống quản trị kiểu này sẽ không thực sự hài lòng với cách tiếp cận "không phân biệt nguồn vốn, các nhóm vốn cùng quy mô đều được đối xử như nhau". Hệ thống thực sự cần phải hiểu mức độ phối hợp nội bộ của các nhóm vốn này.
Cần lưu ý rằng, nếu bạn đồng ý với khung mô tả mà tôi đã trình bày cho hai loại tình huống trên, thì từ góc độ kỹ thuật, nhu cầu về quy tắc rõ ràng "mỗi người một phiếu" sẽ không còn nữa.
Trong hai tình huống này, danh tính vẫn rất hữu ích, nhưng cần tuân thủ "một người một danh tính".