原文：《Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế》
Từ: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar và Ameen Soleimani
Biên soạn: Odaily Planet Daily Husband How
Hôm nay, V God và những người khác là đồng tác giả của một bài nghiên cứu về các giao thức bảo mật có tựa đề "Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế" (Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế).
Bài viết xây dựng một giao thức nâng cao quyền riêng tư dựa trên hợp đồng thông minh mới, nhóm quyền riêng tư và thảo luận về ưu điểm và nhược điểm của nó, cho thấy cách nó cân bằng giữa người dùng trung thực và không trung thực. Giao thức này nhằm mục đích sử dụng bằng chứng không có kiến thức để xác minh tính hợp pháp của tiền của người dùng mà không tiết lộ toàn bộ lịch sử giao dịch của họ, cân nhắc các yêu cầu về quyền riêng tư và quy định trong khi lọc ra các khoản tiền liên quan đến hoạt động tội phạm.
Odaily Planet Daily hiện nay tổng hợp nội dung chính của bài báo như sau.
I. Giới thiệu
Các chuỗi khối công khai được thiết kế minh bạch. Ý tưởng cơ bản là bất kỳ ai cũng có thể chọn xác minh giao dịch mà không cần phải dựa vào bên thứ ba tập trung; bằng cách giảm sự phụ thuộc, nó cung cấp nền tảng trung lập cho các ứng dụng khác nhau, bao gồm nhưng không giới hạn ở tài chính và bản sắc tự chủ.
Tuy nhiên, từ góc độ quyền riêng tư, một tập dữ liệu công khai có mọi giao dịch chứa mọi địa chỉ blockchain. Bất cứ khi nào ai đó chuyển một tài sản sang địa chỉ khác hoặc tương tác với hợp đồng thông minh, giao dịch đó sẽ hiển thị mãi mãi trên blockchain. Điều này rõ ràng không tuân thủ các yêu cầu về quyền riêng tư.
Ví dụ: Alice thanh toán bữa tối tại nhà hàng bằng ví blockchain. Người nhận thanh toán bây giờ biết địa chỉ của Alice và có thể phân tích tất cả hoạt động trong quá khứ và tương lai tại địa chỉ đó. Tương tự như vậy, Alice hiện biết địa chỉ ví của nhà hàng và có thể sử dụng thông tin này để lấy địa chỉ ví của những vị khách khác hoặc để kiểm tra thu nhập của nhà hàng. Hoặc một bên thứ ba (chẳng hạn như mạng xã hội) biết nhà hàng và địa chỉ ví của Alice có thể dễ dàng suy ra địa chỉ cư trú thực tế của Alice và nghiên cứu các giao dịch trong quá khứ và tương lai của cô ấy.
**Sự gia tăng của các giao thức nâng cao quyền riêng tư là để giải quyết các vấn đề trên. Nó cho phép người dùng gửi tiền vào giao thức, sử dụng một địa chỉ và rút tiền từ giao thức vào thời điểm sau đó, sử dụng một địa chỉ khác. Tất cả các khoản tiền gửi và rút tiền vẫn hiển thị trên blockchain, nhưng sự tương ứng giữa các lần chuyển tiền vào và ra cụ thể không còn được công khai. **
Một trong những giao thức nâng cao quyền riêng tư nổi tiếng nhất là Tornado Cash. Nó giải quyết thành công các vấn đề trên và cho phép người dùng giữ được một số quyền riêng tư. Tuy nhiên, ngoài những người dùng hợp pháp đang cố gắng bảo vệ dữ liệu của họ, Tornado Cash còn bị nhiều kẻ xấu sử dụng. Dữ liệu tiền gửi cho thấy nhóm hacker đã chuyển tiền thông qua giao thức này. Có bằng chứng cho thấy giao thức tăng cường quyền riêng tư này cũng được các nhóm hack Triều Tiên sử dụng, cuối cùng dẫn đến việc các địa chỉ hợp đồng thông minh của giao thức này được đưa vào danh sách Các quốc gia bị chỉ định đặc biệt và những người bị chặn do Văn phòng Kiểm soát tài sản nước ngoài Hoa Kỳ (OFAC) duy trì. (thường được gọi là danh sách SDN)).
**Vấn đề chính với Tornado Cash là ranh giới giữa người dùng hợp pháp và người dùng tội phạm bị mờ đi. **Như vậy, Tornado Cash cung cấp tính năng tuân thủ cho phép người dùng tạo bằng chứng về khoản tiền gửi mà khoản rút tiền nhất định đến từ đâu. Mặc dù cơ chế này cho phép mọi người chứng minh sự vô tội của mình nhưng nó phải trả giá bằng việc phải tin tưởng vào một trung gian tập trung và tạo ra sự bất cân xứng về thông tin. Cuối cùng, cơ chế này đã được rất ít người dùng sử dụng.
Bài viết này thảo luận về việc mở rộng phương pháp này cho phép người dùng chứng thực công khai thông tin về nguồn tiền gửi mà số tiền họ rút mà không làm mất quyền riêng tư. **Các nhóm bảo mật đưa ra một khái niệm chung: Cho phép bằng chứng về tư cách thành viên ("Tôi xác nhận rằng số tiền rút của tôi đến từ một trong những khoản tiền gửi này") hoặc bằng chứng loại trừ ("Tôi xác nhận rằng số tiền rút của tôi không đến từ bất kỳ khoản tiền gửi nào trong số này" ) . **Bài viết này thảo luận về đề xuất này và giải thích cách sử dụng đề xuất này để đạt được sự cân bằng giữa người dùng trung thực và không trung thực.
Lưu ý rằng nhóm quyền riêng tư cung cấp các lựa chọn bổ sung bằng cách mở rộng nhóm hành động của người dùng. Họ vẫn có thể cung cấp chứng nhận chi tiết hơn cho các đối tác cụ thể nếu được yêu cầu. Tuy nhiên, trong một số trường hợp, bằng chứng về tư cách thành viên hoặc loại trừ có thể là đủ. Ngoài ra, tùy chọn phát hành công khai các chứng nhận này mang lại một số lợi thế so với việc tiết lộ song phương.
2. Nền tảng kỹ thuật
Trong phần này, chúng tôi cung cấp thông tin tổng quan ngắn gọn về kỹ thuật và thảo luận về các khối xây dựng kỹ thuật cũng như nguyên tắc chung của các giao thức như Nhóm quyền riêng tư.
1. Quyền riêng tư của blockchain trước ZK-SNARK
Trong lịch sử, những người ủng hộ blockchain đã lập luận rằng mặc dù tất cả các giao dịch đều minh bạch nhưng blockchain vẫn bảo vệ quyền riêng tư vì chúng cung cấp tính ẩn danh.
Với sự ra đời của các công cụ phân tích và phân cụm hiện đại, việc bảo vệ quyền riêng tư này đã trở nên không đủ. Để cải thiện tính riêng tư của các chuỗi khối công khai, các công nghệ mạnh mẽ hơn như Token Join và Monero đã được giới thiệu. Tuy nhiên, những công nghệ này vẫn tiềm ẩn nguy cơ rò rỉ dữ liệu. **
Sau đó, sự xuất hiện của các công nghệ chứng minh không có kiến thức có mục đích chung, chẳng hạn như Zcash và Tornado Cash, có thể làm cho tập hợp ẩn danh của mỗi giao dịch bằng toàn bộ tập hợp của tất cả các giao dịch trước đó. Kỹ thuật này thường được gọi là ZK-SNARK.
2, ZK-SNARK
ZK-SNARK là một kỹ thuật cho phép người chứng minh chứng minh một tuyên bố toán học nhất định về dữ liệu công khai và riêng tư đồng thời đáp ứng hai đặc tính chính: không có kiến thức và tính đơn giản. **
● Không có kiến thức: Sẽ không có thông tin nào về dữ liệu riêng tư được tiết lộ ngoại trừ việc chứng minh rằng dữ liệu riêng tư nói trên tuân thủ các tuyên bố.
● **Đơn giản: **Bằng chứng ngắn gọn và có thể được xác minh nhanh chóng, ngay cả khi những tuyên bố đã được chứng minh yêu cầu tính toán tốn nhiều thời gian.
ZK-SNARK đã nhận được sự chú ý rộng rãi từ cộng đồng blockchain vì tầm quan trọng của chúng đối với khả năng mở rộng, chẳng hạn như ZK-rollups. Đối với các ứng dụng bảo mật, tính đơn giản không đặc biệt quan trọng nhưng không có kiến thức là điều cần thiết.
"Tuyên bố" được ZK-SNARK chứng minh có thể được coi là một loại chương trình được gọi là "mạch", tính toán kết quả của hàm f(x, w) với đầu vào công khai và riêng tư, sau đó chứng minh rằng đối với một công khai nhất định đầu vào x , tồn tại một đầu vào riêng w sao cho f(x, w) đánh giá là True.
3. Ứng dụng ZK-SNARK trong các hệ thống như Zcash và Tornado Cash
Có một số khác biệt nhỏ giữa các phiên bản khác nhau của Zcash và các hệ thống lấy cảm hứng từ nó (chẳng hạn như Tornado Cash). Tuy nhiên, logic cơ bản mà họ dựa vào rất giống nhau. Phần này mô tả một phiên bản đơn giản gần tương ứng với cách thức hoạt động của các giao thức này.
Mã thông báo bao gồm các bí mật do chủ sở hữu của chúng nắm giữ. Hai giá trị có thể được lấy từ s:
● ID mã thông báo công khai L = hàm băm + 1)
● nullifierU = hàm băm + 2)
Trong số đó, hàm băm (hash) dùng để chỉ hàm băm mật khẩu, chẳng hạn như SHA 256. Cho trước s, ID mã thông báo và bộ ghi số 0 có thể được tính toán. Tuy nhiên, với một tập hợp các số 0 và ID mã thông báo công khai, hành vi giả ngẫu nhiên của hàm băm đảm bảo rằng bạn không thể xác định số 0 nào được liên kết với ID mã thông báo nào trừ khi bạn biết các bí mật đã tạo ra cả hai.
Chuỗi khối theo dõi tất cả các ID mã thông báo đã được "tạo", cũng như tất cả các số 0 đã được "chi tiêu". Cả hai bộ đều không ngừng phát triển (trừ khi giao thức muốn thực thi khi phải sử dụng mã thông báo).
Một tập hợp các ID mã thông báo được lưu trữ trong cấu trúc dữ liệu được gọi là cây Merkle: nếu cây chứa N mục thì mỗi mục liền kề sẽ được băm (kết quả là ⌈ N/2 ⌉ băm) và mỗi giá trị băm liền kề này sẽ được băm lại (kết quả là trong hàm băm ⌈ N/4 ⌉), v.v., cho đến khi toàn bộ dữ liệu được đưa vào một "băm gốc" duy nhất.
Với một giá trị cụ thể trong cây và hàm băm gốc, bạn có thể cung cấp nhánh Merkle: "các giá trị chị em" được băm cùng nhau ở mỗi bước trên đường dẫn từ giá trị đó đến gốc. Nhánh Merkle này rất hữu ích vì nó là một đoạn dữ liệu nhỏ (log 2(N) băm) có thể được sử dụng để chứng minh rằng bất kỳ giá trị cụ thể nào thực sự có trong cây. Hình dưới đây cho thấy một ví dụ về cây Merkle có chiều cao 4.
Khi người dùng gửi tiền cho người khác, họ sẽ cung cấp những thông tin sau:
● Zerizer U bạn muốn chi tiêu
● ID mã thông báo L' của mã thông báo mới mong muốn được tạo (người nhận được yêu cầu cung cấp thông tin này)
● ZK-SNARK.
ZK-SNARK chứa các đầu vào riêng sau:
● bí mật của người dùng
● Nhánh Merkle trong cây ID mã thông báo, chứng minh rằng mã thông báo có ID mã thông báo L = hash(s + 1) thực sự đã được tạo tại một thời điểm nào đó trong quá khứ
Nó cũng chứa các đầu vào công cộng sau:
● U, số 0 của mã thông báo đang được sử dụng
● R, hàm băm gốc mà bằng chứng Merkle đang hướng tới
ZK-SNARK chứng minh hai tính chất:
● U = hàm băm + 2)
● Nhánh Merkle hợp lệ
Ngoài ZK-SNARK, giao thức còn kiểm tra những điều sau:
● R là hàm băm gốc hiện tại hoặc lịch sử của cây ID mã thông báo
● U không nằm trong tập hợp các số 0 đã sử dụng
Nếu giao dịch hợp lệ, nó sẽ thêm U vào tập hợp số nilifier đã chi và L' vào danh sách ID mã thông báo. Việc hiển thị U sẽ ngăn không cho một mã thông báo bị chi tiêu gấp đôi. Tuy nhiên, sẽ không có thông tin nào khác được tiết lộ. **Thế giới bên ngoài chỉ có thể biết thời điểm giao dịch được gửi; họ không có cách nào biết được thông tin về người đã gửi hoặc nhận các giao dịch đó và không có cách nào để phân biệt nguồn mã thông báo thống nhất. **
Có hai trường hợp ngoại lệ đối với mô hình trên: gửi tiền và rút tiền. Trong khoản tiền gửi, ID mã thông báo có thể được tạo mà không làm mất hiệu lực một số mã thông báo trước đó. Từ góc độ bảo vệ quyền riêng tư, tiền gửi không ẩn danh vì sự liên kết giữa L nhất định và sự kiện bên ngoài cho phép thêm L (trong Tornado Cash, gửi ETH vào hệ thống; trong Zcash, khai thác ZEC mới) là công khai.
Nói cách khác, **tiền gửi được liên kết với lịch sử giao dịch trong quá khứ của họ. **Khi rút tiền, một Zeroizer sẽ được sử dụng mà không cần thêm ID token mới. Điều này có thể ngắt kết nối việc rút tiền từ khoản tiền gửi tương ứng và gián tiếp khỏi lịch sử giao dịch trong quá khứ. Tuy nhiên, việc rút tiền có thể được liên kết với bất kỳ giao dịch nào trong tương lai xảy ra sau sự kiện rút tiền.
Phiên bản đầu tiên của Tornado Cash không có khái niệm chuyển khoản nội bộ, nó chỉ cho phép gửi và rút tiền. Các phiên bản sau này, vẫn đang trong giai đoạn thử nghiệm, cũng cho phép chuyển tiền nội bộ và tiền xu có mệnh giá khác nhau, bao gồm hỗ trợ cho các hoạt động "tách" và "hợp nhất". Chúng ta sẽ thảo luận về cách mở rộng hệ thống chuyển tiền riêng tư cơ bản và nhóm quyền riêng tư sang các mệnh giá tùy ý trong các chương sau.
4. ZK-SNARK trong nhóm riêng tư
**Ý tưởng cốt lõi của nhóm quyền riêng tư là người dùng không chỉ chứng minh rằng việc rút tiền có liên quan đến khoản tiền gửi trước đó thông qua bằng chứng không có kiến thức mà còn chứng minh rằng nó thuộc về một tập hợp liên kết chặt chẽ hơn. **Bộ sưu tập được liên kết có thể là tập hợp con của tất cả các khoản tiền gửi được thực hiện trước đó, một bộ sưu tập chỉ chứa tiền gửi của chính người dùng hoặc bất kỳ thứ gì ở giữa. Người dùng chỉ định tập hợp bằng cách cung cấp gốc Merkle của tập hợp được liên kết làm đầu vào công khai.
Như được hiển thị trong hình bên dưới, để đơn giản, chúng tôi không trực tiếp chứng minh rằng tập hợp liên quan thực sự là tập hợp con của các khoản tiền gửi được thực hiện trước đó; thay vào đó, chúng tôi chỉ yêu cầu người dùng sử dụng cùng một ID xu với nút lá để chứng minh hai nhánh Merkle thông qua kiến thức bằng không:
● Nhập nhánh Merkle của gốc R của tổng số ID xu
● Nhập nhánh Merkle của gốc RA của tập hợp liên kết được cung cấp
Mục đích là đặt bộ liên kết hoàn chỉnh ở đâu đó (có thể trên chuỗi). Khái niệm cốt lõi là: thay vì yêu cầu người dùng chỉ định chính xác số tiền họ rút đến từ khoản tiền gửi nào hoặc ở thái cực khác, không cung cấp thông tin nào khác ngoài bằng chứng về việc không chi tiêu gấp đôi, chúng tôi cho phép người dùng cung cấp một bộ tùy chọn có thể là nguồn số tiền, Và bộ này có thể rộng hoặc hẹp tùy theo ý muốn của họ.
Chúng tôi khuyến khích một hệ sinh thái giúp người dùng dễ dàng chỉ định một tập hợp các liên kết phù hợp với sở thích của họ hơn. Phần còn lại của bài viết này sẽ chỉ mô tả cơ sở hạ tầng dựa trên cơ chế cốt lõi đơn giản này và những hậu quả của nó.
3. Những cân nhắc thực tế và trường hợp sử dụng
Phân tích cách sử dụng các giao thức tăng cường quyền riêng tư trong thực tế từ góc độ ứng dụng.
1. Trường hợp sử dụng của các bộ sưu tập liên quan
Để minh họa giá trị của chương trình này trong môi trường thực thi pháp luật, đây là một ví dụ:
Giả sử chúng ta có năm người dùng: Alice, Bob, Carl, David, Eve. Bốn người dùng đầu tiên là những người dùng trung thực, tuân thủ pháp luật nhưng có ý thức bảo mật, trong khi Eve là một tên trộm. Bởi công chúng biết Eve chính là kẻ trộm qua thông tin những đồng xu tại địa chỉ có dấu “Eve” đã bị đánh cắp. Trong thực tế, điều này thường xảy ra: trên các chuỗi khối công khai, số tiền được tạo ra do khai thác lỗ hổng giao thức DeFi sẽ được theo dõi và gắn thẻ để xác định các khoản tiền bất hợp pháp chảy vào Tornado Cash.
Khi mỗi người trong số năm người dùng thực hiện rút tiền, họ có thể chọn nhóm liên quan để chỉ định. Nhóm liên kết của họ phải bao gồm tiền gửi của riêng họ, nhưng họ có thể tự do lựa chọn địa chỉ nào khác để bao gồm. Bốn người dùng đầu tiên một mặt được thúc đẩy bởi mong muốn bảo vệ quyền riêng tư của họ ở mức độ lớn nhất có thể. Điều này thúc đẩy họ có xu hướng mở rộng tập hợp hiệp hội của mình. Mặt khác, họ muốn giảm nguy cơ đồng tiền của họ bị người bán hoặc sàn giao dịch coi là đáng ngờ. Có một cách dễ dàng để làm điều này: họ không đưa Eve vào bộ sưu tập liên quan của họ. Vì vậy, đối với bốn người trong số họ, sự lựa chọn rất rõ ràng: hãy đặt liên kết của họ là {Alice, Bob, Carl, David}.
Tất nhiên, Eve cũng muốn tối đa hóa tập liên kết của mình. Nhưng cô ấy không thể loại trừ khoản tiền gửi của chính mình, vì vậy cô ấy buộc phải có số tiền liên quan của mình bằng với tập hợp của cả năm khoản tiền gửi. Việc lựa chọn bộ sưu tập liên quan của người tham gia được hiển thị trong hình bên dưới.
Mặc dù bản thân Eve chưa cung cấp bất kỳ thông tin nào, nhưng thông qua một quy trình loại trừ đơn giản, chúng ta có thể rút ra một suy luận rõ ràng: bước rút lui thứ năm chỉ có thể đến từ Eve.
2. Xây dựng các bộ sưu tập liên quan
Phần trước đã minh họa một cách khả thi để sử dụng các nhóm liên kết trong một giao thức tương tự như nhóm quyền riêng tư và cách tách những người tham gia trung thực khỏi những nhóm xấu. Lưu ý rằng hệ thống này không phụ thuộc vào lòng vị tha của Alice, Bob, Carl và David; họ có những động cơ rõ ràng để biện minh cho sự chia ly của mình. Bây giờ chúng ta hãy xem xét việc xây dựng một bộ sưu tập kết hợp chi tiết hơn. Nói chung, có hai chiến lược chính để tạo ra các bộ sưu tập kết hợp. Chúng được mô tả dưới đây và được hiển thị trong hình bên dưới.
● **Bao gồm (hoặc tư cách thành viên): **Xác định một nhóm tiền gửi cụ thể mà chúng tôi có bằng chứng thuyết phục rằng chúng có rủi ro thấp và xây dựng một nhóm liên quan chỉ chứa các khoản tiền gửi này.
● Loại trừ: Xác định một nhóm tiền gửi cụ thể mà chúng tôi có bằng chứng mạnh mẽ cho thấy có rủi ro cao và xây dựng một tập hợp liên kết bao gồm tất cả các khoản tiền gửi ngoại trừ những khoản tiền gửi đó.
Trong thực tế, người dùng không chọn thủ công các khoản tiền gửi để đưa vào bộ sưu tập liên quan của họ. Thay vào đó, người dùng sẽ đăng ký các bên trung gian mà chúng tôi gọi là Nhà cung cấp bộ sưu tập liên kết (ASP), tạo ra Bộ sưu tập liên kết với các thuộc tính cụ thể. **Trong một số trường hợp, ASP có thể được xây dựng hoàn toàn trên chuỗi mà không cần sự can thiệp của con người (hoặc AI). Trong các trường hợp khác, ASP sẽ tạo các bộ sưu tập liên kết một cách độc lập và xuất bản các bộ sưu tập liên kết trên chuỗi hoặc ở nơi khác.
Chúng tôi thực sự khuyên bạn nên xuất bản ít nhất gốc Merkle của bộ liên kết trên chuỗi; điều này loại bỏ khả năng các ASP độc hại thực hiện một số loại tấn công nhất định đối với người dùng (ví dụ: cung cấp cho những người dùng khác nhau các bộ liên kết khác nhau nhằm cố gắng loại bỏ ẩn danh của họ). Toàn bộ bộ sưu tập phải có sẵn thông qua API hoặc lý tưởng nhất là thông qua hệ thống lưu trữ phi tập trung chi phí thấp như IPFS.
Khả năng tải xuống toàn bộ bộ sưu tập liên kết rất quan trọng vì nó cho phép người dùng tạo bằng chứng tư cách thành viên cục bộ mà không tiết lộ bất kỳ thông tin bổ sung nào cho ASP, thậm chí không tiết lộ số tiền gửi tương ứng với số tiền họ rút.
Đây là cách ASP có thể được cấu trúc trong thực tế:
● Bổ sung bị trì hoãn, loại trừ các tác nhân xấu: Mọi khoản tiền gửi sẽ tự động được thêm vào bộ sưu tập liên quan sau một thời gian cố định (ví dụ: 7 ngày), nhưng nếu hệ thống phát hiện khoản tiền gửi có liên quan đến hành vi xấu đã biết (ví dụ: trộm cắp quy mô lớn hoặc địa chỉ trong danh sách trừng phạt do chính phủ công bố), khoản tiền gửi sẽ không bao giờ được thêm vào. Trong thực tế, điều này có thể đạt được thông qua các khoản thu thập do cộng đồng quản lý hoặc các nhà cung cấp dịch vụ sàng lọc giao dịch hiện có đã thực hiện công việc xác định và theo dõi tiền gửi liên quan đến hành vi xấu.
● Phí hàng tháng cho một người: Để tham gia bộ sưu tập liên quan, giá trị của khoản tiền gửi phải dưới mức tối đa cố định nào đó và người gửi tiền phải chứng minh mà không hề biết rằng họ nắm giữ một số mã thông báo nhận dạng (ví dụ: bởi một chính phủ được hỗ trợ hệ thống ID quốc gia hoặc các cơ chế nhẹ như xác minh tài khoản mạng xã hội). Được kết hợp với một tham số bổ sung đại diện cho cơ chế thu thập dữ liệu của tháng hiện tại để đảm bảo rằng mỗi danh tính chỉ có thể gửi tiền gửi vào bộ sưu tập liên quan mỗi tháng một lần. Thiết kế cố gắng thực hiện tinh thần của nhiều quy tắc AML phổ biến, theo đó các khoản thanh toán vi mô dưới một ngưỡng nhất định sẽ cho phép mức độ riêng tư cao hơn. Lưu ý rằng điều này có thể được thực hiện hoàn toàn như một hợp đồng thông minh, không yêu cầu giám sát thủ công để duy trì hoạt động liên tục.
● **Phí hàng tháng cho thành viên cộng đồng đáng tin cậy: **Tương tự như phí hàng tháng cho một người độc thân, nhưng hạn chế hơn: người dùng phải chứng minh họ là thành viên của một cộng đồng có độ tin cậy cao. Các thành viên cộng đồng có độ tin cậy cao đồng ý cung cấp quyền riêng tư cho nhau.
● **Tính điểm theo thời gian thực dựa trên AI: **Hệ thống AI ASP có thể cung cấp điểm rủi ro cho mỗi khoản tiền gửi trong thời gian thực và hệ thống sẽ đưa ra một tập hợp liên quan chứa các khoản tiền gửi có điểm rủi ro dưới một ngưỡng nhất định. Có khả năng, ASP có thể xuất ra nhiều bộ tương ứng với nhiều ngưỡng điểm rủi ro.
4. Mô tả kỹ thuật bổ sung
Trong phần này, chúng tôi phân tích cách đề xuất hỗ trợ các mệnh giá tùy ý và thảo luận về các trường hợp đặc biệt như chứng nhận lại, bằng chứng trực tiếp song phương và bằng chứng tuần tự.
1. Hỗ trợ bất kỳ giáo phái nào
Hệ thống tiền xu bảo vệ quyền riêng tư được đơn giản hóa ở trên chỉ hỗ trợ chuyển tiền xu có cùng mệnh giá. Zcash hỗ trợ các mệnh giá tùy ý bằng cách sử dụng mô hình UTXO. Mỗi giao dịch có thể có nhiều đầu vào (cần xuất bản số nilifier cho mỗi đầu vào) và nhiều đầu ra (cần xuất bản ID mã thông báo cho mỗi đầu ra). Mỗi ID mã thông báo được tạo phải có mệnh giá mật mã được đính kèm. Ngoài việc chứng minh tính hợp lệ của zeroizer, mỗi giao dịch phải kèm theo bằng chứng bổ sung rằng tổng mệnh giá của các đồng tiền được tạo ra không vượt quá tổng mệnh giá của các đồng tiền đã bỏ ra. Hình dưới đây minh họa bằng chứng bổ sung này.
Thiết kế này có thể được mở rộng để hỗ trợ việc gửi và rút tiền bằng cách coi tiền gửi là đầu vào (không được mã hóa) và việc rút tiền là đầu ra (không được mã hóa). Ngoài ra, thiết kế có thể bị hạn chế để đơn giản hóa việc phân tích. Ví dụ: chỉ có thể cho phép rút một phần để giao dịch có một đầu vào được mã hóa và hai đầu ra: đầu ra không được mã hóa thể hiện việc rút tiền và đầu ra "thay đổi" được mã hóa thể hiện số tiền còn lại, có thể được sử dụng để rút tiền trong tương lai.
Một câu hỏi tự nhiên là làm thế nào để mở rộng thiết kế này để hỗ trợ các nhóm quyền riêng tư. Việc chèn nó vào nhóm quyền riêng tư không thay đổi là không lý tưởng vì biểu đồ giao dịch không nhất quán với những gì chúng tôi mong đợi bằng trực giác: nếu người dùng gửi 10 mã thông báo và sau đó chi 1 + 2 + 3 + 4 trong bốn mã thông báo rút tiền liên tiếp, chúng tôi muốn xử lý từng mã thông báo đó. trong số bốn lần rút tiền này làm nguồn gửi 10 token ban đầu. Nhưng kết quả thực tế như được hiển thị bên dưới: nguồn của lần rút tiền đầu tiên là khoản gửi 10 mã thông báo và sau đó nguồn của lần rút thứ hai là đầu ra thay đổi của 9 mã thông báo được tạo bởi lần rút tiền đầu tiên, v.v. Điều này gây ra vấn đề trong thực tế vì nó yêu cầu ASP xác thực khoản tiền gửi trung gian và thêm nó vào bộ sưu tập liên quan của nó.
Để tất cả bốn lần rút tiền trong ví dụ này có thể lấy 10 xu ban đầu làm nguồn, chúng ta cần giải quyết hai vấn đề:
● Đảm bảo rằng mỗi lần rút tiền một phần không được liên kết công khai với các lần rút tiền khác
● Cho phép mỗi lần rút tiền một phần bao gồm khoản tiền gửi với tư cách là thành viên của bộ sưu tập được liên kết
Nếu chúng tôi chỉ hỗ trợ rút tiền một phần, thay vì các giao dịch MIMO phức tạp hơn và đảm bảo rằng mỗi lần rút tiền có một "khoản tiền gửi gốc" tương ứng được xác định duy nhất, thì có nhiều cách để đạt được điều này một cách trực tiếp. Một cách tiếp cận tự nhiên và có thể mở rộng là truyền bá lời hứa về một số thông tin thông qua các giao dịch. Ví dụ: chúng tôi có thể yêu cầu giao dịch chứa hàm băm cam kết (coinID+hash®), thêm một số giá trị ngẫu nhiên r để đảm bảo làm mù và yêu cầu ZK-SNARK chứng minh rằng cam kết trong giao dịch giống với giao dịch gốc của nó. Nếu bản thân giao dịch gốc là rút tiền thì cam kết giống với ID coin của khoản tiền gửi ban đầu và nếu giao dịch gốc là tiền gửi thì cam kết giống với ID coin của khoản tiền gửi ban đầu. Do đó, mọi giao dịch trong chuỗi phải có cam kết về ID tiền gửi ban đầu và yêu cầu bằng chứng rằng giá trị này nằm trong tập hợp liên quan do giao dịch cung cấp.
Để cải thiện quyền riêng tư trước các cuộc tấn công tổng hợp số dư, chúng tôi cũng có thể hỗ trợ hợp nhất tiền xu. Ví dụ: nếu tôi còn một số xu, tôi có thể hợp nhất chúng với khoản tiền gửi tiếp theo của mình. Để đáp ứng điều này, chúng tôi có thể yêu cầu các giao dịch cam kết với một bộ ID đồng xu và yêu cầu các giao dịch có nhiều đầu vào cam kết với sự kết hợp của cha mẹ chúng. Việc rút tiền sẽ chứa bằng chứng cho thấy tất cả các ID xu đã cam kết đều nằm trong tập hợp được liên kết.
2. Trường hợp đặc biệt
● **Chứng nhận lại: **Người dùng cần thông tin tiền gửi bí mật để rút tiền gửi tương tự như các giao thức nhóm riêng tư. Thông tin bí mật tương tự cũng được sử dụng để xây dựng bằng chứng về tư cách thành viên của tập hợp kết hợp. Việc lưu giữ thông tin bí mật cho phép người dùng tạo bằng chứng mới cho các bộ khác nhau hoặc các bộ liên quan được cập nhật. Điều này mang lại cho người dùng sự linh hoạt cao hơn nhưng cũng có thể gây ra những rủi ro bổ sung.
● Bằng chứng trực tiếp song phương: Trong một số trường hợp, người dùng có thể được yêu cầu tiết lộ nguồn rút tiền chính xác cho bên kia. Người dùng có thể tạo một bộ sưu tập liên quan chỉ chứa tiền gửi của họ và tạo bằng chứng chống lại bộ sưu tập đó. Những bằng chứng này thường là trường hợp ngoại lệ và chỉ góp phần đảm bảo quyền riêng tư một phần khi được chia sẻ giữa hai bên. Tuy nhiên, việc chia sẻ bằng chứng đòi hỏi phải thiết lập các giả định tin cậy mạnh mẽ.
● Bằng chứng về trình tự: Trong nền kinh tế giao dịch nhanh sử dụng hệ thống như nhóm bảo mật, giao thức cần được sửa đổi để thích ứng với môi trường này. Ngoài các loại giao dịch gửi và rút tiền, giao thức cũng cần hỗ trợ các hoạt động gửi nội bộ để tăng hiệu quả. Ngoài ra, bằng cách chuyển các nhánh và khóa Merkle, người dùng có thể truyền bá thông tin liên quan đến lịch sử giao dịch để người nhận có thể xác minh nguồn gốc của tiền. Điều này đảm bảo rằng mỗi người dùng có thông tin tối thiểu họ cần để tin tưởng vào số tiền họ nhận được.
Trong thực tế, một đồng xu có thể có nhiều “nguồn gốc”. Ví dụ: Bob là chủ quán cà phê, anh ấy nhận được 5 token từ Alice, 4 token từ Ashley, 7 token từ Anne và cuối ngày anh ấy cần trả cho Carl 15 token để trả tiền cho bữa tối. Thay vào đó, David có thể đã nhận được 15 token từ Carl, 25 token từ Chris và muốn gửi 30 token cho Emma (một sàn giao dịch). Trong những trường hợp phức tạp hơn này, chúng tôi tuân theo cùng một nguyên tắc: lịch sử đã được thêm vào bộ sưu tập liên quan đủ sớm có thể bị bỏ qua, trong khi lịch sử mới hơn cần được chuyển tiếp.
5. Thêm chi tiết
Một hệ thống như nhóm quyền riêng tư có thể cho phép người dùng được bảo vệ nhiều hơn về quyền riêng tư của dữ liệu giao dịch tài chính của họ trong khi vẫn duy trì khả năng chứng minh sự tách biệt khỏi hoạt động bất hợp pháp đã biết. Chúng tôi hy vọng rằng những người dùng trung thực sẽ được khuyến khích tham gia vào chương trình như vậy thông qua sự kết hợp của hai yếu tố:
● Mong muốn quyền riêng tư
● Mong muốn tránh khơi dậy sự nghi ngờ
1. Sự đồng thuận xã hội và tập hợp liên kết
Nếu có sự đồng thuận hoàn toàn về việc quỹ tốt hay xấu thì hệ thống sẽ tạo ra một trạng thái cân bằng riêng biệt đơn giản. Tất cả người dùng có nội dung “tốt” đều có động cơ mạnh mẽ và khả năng chứng minh rằng họ thuộc về nhóm liên kết “chỉ tốt”. Mặt khác, những kẻ xấu sẽ không thể cung cấp bằng chứng này. Họ vẫn có thể gửi tiền "xấu" vào nhóm, nhưng điều đó sẽ không mang lại lợi ích gì cho họ. Mọi người đều có thể dễ dàng xác định rằng tiền đã được rút từ một giao thức tăng cường quyền riêng tư và thấy rằng việc rút tiền tham chiếu đến một bộ sưu tập liên quan có chứa tiền gửi từ các nguồn đáng ngờ. Hơn nữa, tiền "xấu" không làm hỏng tiền "tốt". Khi tiền được rút từ các khoản tiền gửi hợp pháp, chủ sở hữu của chúng có thể chỉ cần loại trừ tất cả các khoản tiền gửi "xấu" đã biết khỏi bộ sưu tập liên quan của họ.
Khi có sự đồng thuận toàn cầu và khi kết luận về việc tài trợ được coi là "tốt" hay "xấu" phụ thuộc vào quan điểm xã hội hoặc quyền tài phán, thì tập hợp các hiệp hội có thể khác nhau đáng kể. Giả sử có hai khu vực pháp lý với các bộ quy tắc khác nhau. Các chủ thể ở cả hai khu vực pháp lý A và B có thể sử dụng cùng một giao thức tăng cường quyền riêng tư và chọn cấp các chứng nhận đáp ứng các yêu cầu của khu vực pháp lý tương ứng của họ. Cả hai đều có thể dễ dàng thực hiện quyền riêng tư trong các bộ sưu tập liên quan của riêng mình và loại trừ các khoản rút tiền không tuân thủ các yêu cầu của khu vực pháp lý tương ứng của họ. Nếu được yêu cầu, bằng chứng tư cách thành viên có thể được cấp cho sự giao nhau của hai tập hợp liên kết, qua đó chứng minh một cách đáng tin cậy rằng tiền gửi tương ứng với số tiền rút của họ tuân thủ các yêu cầu của cả hai khu vực pháp lý.
Vì vậy, đề xuất này rất linh hoạt và nên được coi là cơ sở hạ tầng trung lập. Một mặt, nó chống lại sự kiểm duyệt. Nó cho phép mọi người tham gia bộ sưu tập liên quan mà họ lựa chọn và duy trì quyền riêng tư trong cộng đồng của riêng họ. Mặt khác, người ngoài có thể yêu cầu bằng chứng chống lại một nhóm hiệp hội cụ thể đáp ứng các yêu cầu quy định của họ. Do đó, ngay cả khi có một cộng đồng những kẻ xấu tham gia giao thức tăng cường quyền riêng tư, họ sẽ không thể che giấu nguồn gốc đáng ngờ của các khoản tiền gửi miễn là thông tin được phản ánh chính xác trong quá trình xây dựng tập hợp liên quan.
2. Thuộc tính của các bộ sưu tập liên quan
Bộ sưu tập liên kết cần phải có các thuộc tính nhất định để hoạt động. Việc thu thập cần phải chính xác để người dùng có thể tin tưởng rằng họ đang sử dụng số tiền đã rút một cách an toàn. Hơn nữa, các thuộc tính của mỗi bộ phải ổn định, tức là ít có khả năng thay đổi theo thời gian. Điều này làm giảm nhu cầu rút tiền xác nhận lại đối với các bộ sưu tập mới. Cuối cùng, để đạt được sự bảo vệ quyền riêng tư có ý nghĩa, tập liên kết phải đủ lớn và chứa nhiều loại tiền gửi khác nhau. Tuy nhiên, các thuộc tính này xung đột với nhau. Nói chung, các bộ sưu tập lớn và đa dạng có thể có đặc tính bảo mật tốt hơn nhưng có thể kém chính xác và ổn định hơn, trong khi các bộ sưu tập nhỏ hơn dễ bảo trì hơn nhưng cung cấp ít quyền riêng tư hơn.
3. Cân nhắc thực tế và cạnh tranh
Các thực thể được quản lý chấp nhận tài sản tiền điện tử phải đảm bảo rằng luật pháp và quy định mà họ phải tuân theo cho phép chấp nhận các khoản tiền đó. Ngày nay, nhiều thực thể trong số này dựa vào cái gọi là công cụ sàng lọc giao dịch: phần mềm hoặc dịch vụ phân tích chuỗi khối để xác định hoạt động đáng ngờ tiềm ẩn, liên kết đến địa chỉ bất hợp pháp hoặc các giao dịch không tuân thủ khác. Các công cụ sàng lọc thường thể hiện rủi ro liên quan đến mỗi giao dịch thông qua điểm rủi ro. Điểm này dựa trên điểm đến của số tiền được chuyển và lịch sử giao dịch của chúng. Về vấn đề này, các giao thức tăng cường quyền riêng tư có thể đặt ra những thách thức. Họ loại bỏ mối liên kết có thể nhìn thấy giữa tiền gửi và rút tiền. Do đó, với sự hiện diện của các giao thức tăng cường quyền riêng tư, việc chấm điểm rủi ro cần phải tính đến bằng chứng và chỉ định điểm dựa trên các tập hợp liên quan.
Các công cụ và dịch vụ sàng lọc giao dịch chủ yếu được cung cấp bởi các công ty chuyên nghiệp có chuyên môn về phân tích blockchain và các lĩnh vực pháp lý liên quan. Lý tưởng nhất là các công ty này (và bất kỳ ai khác) sẽ có quyền truy cập vào tất cả các chứng chỉ thành viên và các bộ sưu tập liên quan tương ứng của họ để cung cấp điểm rủi ro chính xác cho tất cả các giao dịch. Do đó, chúng tôi khuyên bạn nên lưu trữ tất cả bằng chứng trên blockchain hoặc kho lưu trữ bằng chứng có thể truy cập công khai khác. Ngoại lệ duy nhất là chứng chỉ thành viên có kích thước một được chia sẻ với một đối tác cụ thể. Vì những lý do hiển nhiên, những lời chứng thực này không nên được công bố rộng rãi.
Việc lưu trữ bằng chứng trực tiếp trên chuỗi sẽ làm tăng thêm chi phí giao dịch, nhưng làm giảm nỗ lực phối hợp, giúp cạnh tranh công bằng hơn và giảm thiểu rủi ro gần như độc quyền mà các nhà cung cấp công cụ sàng lọc có thể tạo ra do hiểu biết về bằng chứng không công khai.
Thiết lập chung của nhóm riêng tư rất linh hoạt. Giao thức có thể được tùy chỉnh cho các trường hợp sử dụng khác nhau bằng cách tạo các bộ sưu tập liên kết cụ thể. Dưới đây là hai ví dụ về các bộ sưu tập liên kết đặc biệt này:
● **Liên minh ngân hàng thương mại có thể tạo một bộ sưu tập liên quan chỉ chứa tiền gửi của khách hàng của họ. **Điều này đảm bảo rằng mọi khoản rút tiền được tạo bằng bằng chứng về việc thu thập đều phải trải qua các thủ tục nhận biết khách hàng (KYC) và chống rửa tiền (AML) tại một trong các ngân hàng tham gia, nhưng không tiết lộ khoản rút tiền nào thuộc về khách hàng nào.
● **Trong trường hợp các trung gian tài chính được yêu cầu ghi lại rõ ràng nguồn tiền, họ có thể yêu cầu người dùng cung cấp bằng chứng đối với một tập hợp liên quan chỉ chứa tiền gửi của người dùng. **Bằng chứng này sau đó sẽ được trao đổi song phương với bên trung gian, cho phép họ theo dõi tiền như thể người dùng chưa bao giờ sử dụng nhóm bảo mật. Mặc dù điều này yêu cầu người dùng tin tưởng vào bên trung gian không tiết lộ bằng chứng, nhưng lý tưởng nhất là nó cho phép người dùng tuân thủ các quy định mà không cần phải tiết lộ thông tin cho công chúng.
4. Lựa chọn và thay thế thiết kế
Các thiết lập dựa trên tập hợp liên kết, bằng chứng zk và tiết lộ tự nguyện rất linh hoạt. Mặc dù điều này rất hữu ích trong việc đảm bảo rằng đề xuất có thể được điều chỉnh cho phù hợp với các khu vực pháp lý khác nhau, nhưng cần hết sức thận trọng đối với các lựa chọn thiết kế cụ thể. Đặc biệt, có hai điều chỉnh tiềm năng mà chúng tôi phản đối. Chúng tôi tin rằng chúng có vấn đề về yêu cầu niềm tin và có thể tạo ra cấu trúc thị trường gần như độc quyền. Dưới đây chúng tôi mô tả ngắn gọn và thảo luận về các lựa chọn thay thế này:
● Quyền truy cập tập trung: Các cơ quan thực thi pháp luật, nhà cung cấp dịch vụ chấm điểm rủi ro tiền điện tử hoặc các tác nhân tương tự có thể có quyền truy cập để xem các liên kết giữa các giao dịch của người dùng trong khi vẫn duy trì quyền riêng tư với những người khác.
● **Danh sách trắng trên toàn hệ thống: **Hệ thống quyền riêng tư có thể đặt ra các hạn chế đối với loại người dùng có thể gửi tiền vào nhóm của họ, yêu cầu họ cung cấp bằng chứng bổ sung hoặc yêu cầu gửi tiền phải chờ trong một khoảng thời gian trong đó Điểm rủi ro tập trung hệ thống có thể từ chối tiền gửi.
Hai phương pháp này giống nhau ở chỗ chúng đặc quyền cho các thực thể cụ thể. Điều này đặt ra những câu hỏi phức tạp về quản trị: Ai có quyền truy cập vào thông tin này? Ai có thẩm quyền quản lý quyền? Các công ty tư nhân dường như không phải là một lựa chọn tốt, vì bất kỳ đặc quyền nào cũng có thể tạo ra cấu trúc thị trường độc quyền, trong đó một số công ty có quyền truy cập vào dữ liệu cho phép họ cung cấp các dịch vụ này, trong khi những công ty khác không thể cạnh tranh.
Tương tự như vậy, nhiều vấn đề về quản trị và chính trị sẽ phải đối mặt khi giao quyền cho các tổ chức công, đặc biệt là trong môi trường quốc tế. Ngay cả khi một tổ chức cho đến nay vẫn đáng tin cậy 100%, không lạm dụng quyền lực của mình để theo đuổi một chương trình nghị sự chính trị và không phụ thuộc vào các thực thể khác có thể buộc tổ chức đó lạm dụng quyền lực của mình thì tình trạng này vẫn là triệu chứng của một trạng thái không hoạt động. Các tổ chức, thành viên, quốc gia và cơ cấu chính trị trong tổ chức thay đổi theo thời gian. Có thể có áp lực từ bên ngoài và sự tồn tại của những đặc quyền này có thể tạo thêm động lực để phá vỡ và giành được ảnh hưởng đối với hệ thống quản trị của tổ chức.
Hơn nữa, các cuộc tấn công bên trong hoặc bên ngoài tổ chức hoặc lỗi thay mặt cho các thực thể tập trung có thể gây ra hậu quả sâu rộng. Chúng tôi tin rằng nên ngăn chặn việc tạo ra các điểm thất bại tập trung như vậy.
Tuy nhiên, chúng tôi nhận thấy rằng các quy mô và hoàn cảnh giao dịch khác nhau có thể yêu cầu các kết hợp chứng nhận khác nhau. Ví dụ: đối với các giao dịch lớn, nhiều người dùng có thể sẽ cung cấp bằng chứng cơ bản về loại trừ trên chuỗi và cung cấp thông tin chi tiết hơn về nguồn tiền cho đối tác của họ.
5. Hướng nghiên cứu chuyên sâu
Mặc dù nghiên cứu này cung cấp cái nhìn tổng quan về cách có thể sử dụng các giao thức nâng cao quyền riêng tư dựa trên zkSNARK trong các cài đặt được quản lý, nhưng có một số khía cạnh cần được nghiên cứu thêm.
Đầu tiên, mọi người cần nhận ra rằng quyền riêng tư đạt được thông qua các giao thức này phụ thuộc vào nhiều yếu tố khác nhau. Kẻ tấn công có thể liên kết việc rút tiền với các khoản tiền gửi cụ thể dựa trên tập hợp liên kết không đủ lớn, lựa chọn gốc kém và lỗi người dùng.
Ngoài ra, lựa chọn của người dùng khác có thể ảnh hưởng xấu đến quyền riêng tư của bạn. Trong những trường hợp cực đoan, những người khác trong nhóm sẽ công bố bằng chứng về tư cách thành viên cỡ một, tiết lộ mối liên hệ trực tiếp giữa việc gửi và rút tiền của họ. Rõ ràng, điều này sẽ ngầm tiết lộ mối liên hệ giữa các giao dịch gửi và rút tiền duy nhất còn lại. Trong một ví dụ tinh tế hơn, các ràng buộc từ nhiều bằng chứng thành viên khác nhau có thể được sử dụng để trích xuất thông tin và có khả năng liên hệ giữa việc gửi và rút tiền với xác suất cao. Khi thông tin được chứng thực này được kết hợp với siêu dữ liệu giao dịch, các thuộc tính quyền riêng tư của giao thức có thể bị xâm phạm.
Cuối cùng, một ASP độc hại có thể chọn biên dịch tập hợp liên kết được đề xuất theo cách cho phép chúng tối đa hóa việc trích xuất thông tin hoặc tăng tính ẩn danh được nhận thức bằng cách thêm tiền gửi vào nơi đã biết số tiền rút tương ứng. Tất cả những vấn đề này đòi hỏi phải nghiên cứu thêm để đánh giá các thuộc tính quyền riêng tư được cung cấp. Theo hướng tương tự, sẽ rất thú vị khi nghiên cứu sâu hơn về các đặc tính của sự cân bằng tách biệt, mô hình hóa cách người chơi tốt và người chơi xấu hành xử theo các giả định nhất định và bằng chứng công khai về điều trước ảnh hưởng đến quyền riêng tư của người sau.
Các chuyên gia pháp lý có thể nghiên cứu thêm các yêu cầu công bố thông tin cụ thể. Kế hoạch được đề xuất trong bài viết này rất linh hoạt và những hiểu biết sâu sắc từ các chuyên gia pháp lý có thể giúp điều chỉnh thỏa thuận và hệ sinh thái được xây dựng xung quanh nó để đảm bảo tuân thủ trong các khu vực pháp lý khác nhau.
6. Kết luận
Trong nhiều trường hợp, quyền riêng tư và tuân thủ được coi là xung đột với nhau. Bài viết này đề xuất rằng điều này không nhất thiết phải xảy ra nếu các giao thức tăng cường quyền riêng tư cho phép người dùng chứng minh các thuộc tính nhất định về nguồn tiền của họ. Ví dụ: giả định rằng người dùng có thể chứng minh rằng tiền của họ không liên quan đến tiền gửi từ các nguồn bất hợp pháp đã biết hoặc tiền là một phần của một khoản tiền gửi cụ thể mà không tiết lộ thêm bất kỳ thông tin nào.
Thiết lập như vậy có thể tạo ra trạng thái cân bằng riêng biệt trong đó người dùng trung thực được khuyến khích mạnh mẽ để chứng minh rằng họ thuộc về một số nhóm liên kết tuân thủ và duy trì quyền riêng tư trong nhóm đó. Ngược lại, đối với những người dùng không trung thực thì họ không thể cung cấp bằng chứng đó. Điều này cho phép người dùng trung thực tách mình khỏi khoản tiền gửi của bên thứ ba mà họ không đồng ý hoặc ngăn họ sử dụng tiền của mình trong một môi trường tuân thủ. Chúng tôi tin rằng đề xuất này rất linh hoạt và có thể được điều chỉnh theo các yêu cầu pháp lý tiềm năng khác nhau.
Bài viết này nên được coi là một đóng góp cho sự tồn tại tiềm năng trong tương lai của quyền riêng tư và quy định tài chính. Chúng tôi muốn tạo điều kiện thuận lợi cho các cuộc thảo luận và hướng cuộc trò chuyện theo hướng tích cực, mang tính xây dựng hơn. Cần phải có sự hợp tác giữa các học viên, học giả từ nhiều ngành khác nhau, các nhà hoạch định chính sách và cơ quan quản lý để mở rộng và sửa đổi đề xuất này; mục tiêu cuối cùng là tạo ra cơ sở hạ tầng nâng cao quyền riêng tư có thể được sử dụng trong các môi trường được quản lý.
Xem bản gốc
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.
Bài viết mới nhất của Buterin: Giao thức nhóm quyền riêng tư bảo vệ quyền riêng tư của người dùng và đáp ứng các yêu cầu tuân thủ như thế nào?
原文：《Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế》
Từ: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar và Ameen Soleimani
Biên soạn: Odaily Planet Daily Husband How
Hôm nay, V God và những người khác là đồng tác giả của một bài nghiên cứu về các giao thức bảo mật có tựa đề "Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế" (Quyền riêng tư và tuân thủ quy định của Blockchain: Hướng tới sự cân bằng thực tế).
Bài viết xây dựng một giao thức nâng cao quyền riêng tư dựa trên hợp đồng thông minh mới, nhóm quyền riêng tư và thảo luận về ưu điểm và nhược điểm của nó, cho thấy cách nó cân bằng giữa người dùng trung thực và không trung thực. Giao thức này nhằm mục đích sử dụng bằng chứng không có kiến thức để xác minh tính hợp pháp của tiền của người dùng mà không tiết lộ toàn bộ lịch sử giao dịch của họ, cân nhắc các yêu cầu về quyền riêng tư và quy định trong khi lọc ra các khoản tiền liên quan đến hoạt động tội phạm.
Odaily Planet Daily hiện nay tổng hợp nội dung chính của bài báo như sau.
I. Giới thiệu
Các chuỗi khối công khai được thiết kế minh bạch. Ý tưởng cơ bản là bất kỳ ai cũng có thể chọn xác minh giao dịch mà không cần phải dựa vào bên thứ ba tập trung; bằng cách giảm sự phụ thuộc, nó cung cấp nền tảng trung lập cho các ứng dụng khác nhau, bao gồm nhưng không giới hạn ở tài chính và bản sắc tự chủ.
Tuy nhiên, từ góc độ quyền riêng tư, một tập dữ liệu công khai có mọi giao dịch chứa mọi địa chỉ blockchain. Bất cứ khi nào ai đó chuyển một tài sản sang địa chỉ khác hoặc tương tác với hợp đồng thông minh, giao dịch đó sẽ hiển thị mãi mãi trên blockchain. Điều này rõ ràng không tuân thủ các yêu cầu về quyền riêng tư.
Ví dụ: Alice thanh toán bữa tối tại nhà hàng bằng ví blockchain. Người nhận thanh toán bây giờ biết địa chỉ của Alice và có thể phân tích tất cả hoạt động trong quá khứ và tương lai tại địa chỉ đó. Tương tự như vậy, Alice hiện biết địa chỉ ví của nhà hàng và có thể sử dụng thông tin này để lấy địa chỉ ví của những vị khách khác hoặc để kiểm tra thu nhập của nhà hàng. Hoặc một bên thứ ba (chẳng hạn như mạng xã hội) biết nhà hàng và địa chỉ ví của Alice có thể dễ dàng suy ra địa chỉ cư trú thực tế của Alice và nghiên cứu các giao dịch trong quá khứ và tương lai của cô ấy.
**Sự gia tăng của các giao thức nâng cao quyền riêng tư là để giải quyết các vấn đề trên. Nó cho phép người dùng gửi tiền vào giao thức, sử dụng một địa chỉ và rút tiền từ giao thức vào thời điểm sau đó, sử dụng một địa chỉ khác. Tất cả các khoản tiền gửi và rút tiền vẫn hiển thị trên blockchain, nhưng sự tương ứng giữa các lần chuyển tiền vào và ra cụ thể không còn được công khai. **
Một trong những giao thức nâng cao quyền riêng tư nổi tiếng nhất là Tornado Cash. Nó giải quyết thành công các vấn đề trên và cho phép người dùng giữ được một số quyền riêng tư. Tuy nhiên, ngoài những người dùng hợp pháp đang cố gắng bảo vệ dữ liệu của họ, Tornado Cash còn bị nhiều kẻ xấu sử dụng. Dữ liệu tiền gửi cho thấy nhóm hacker đã chuyển tiền thông qua giao thức này. Có bằng chứng cho thấy giao thức tăng cường quyền riêng tư này cũng được các nhóm hack Triều Tiên sử dụng, cuối cùng dẫn đến việc các địa chỉ hợp đồng thông minh của giao thức này được đưa vào danh sách Các quốc gia bị chỉ định đặc biệt và những người bị chặn do Văn phòng Kiểm soát tài sản nước ngoài Hoa Kỳ (OFAC) duy trì. (thường được gọi là danh sách SDN)).
**Vấn đề chính với Tornado Cash là ranh giới giữa người dùng hợp pháp và người dùng tội phạm bị mờ đi. **Như vậy, Tornado Cash cung cấp tính năng tuân thủ cho phép người dùng tạo bằng chứng về khoản tiền gửi mà khoản rút tiền nhất định đến từ đâu. Mặc dù cơ chế này cho phép mọi người chứng minh sự vô tội của mình nhưng nó phải trả giá bằng việc phải tin tưởng vào một trung gian tập trung và tạo ra sự bất cân xứng về thông tin. Cuối cùng, cơ chế này đã được rất ít người dùng sử dụng.
Bài viết này thảo luận về việc mở rộng phương pháp này cho phép người dùng chứng thực công khai thông tin về nguồn tiền gửi mà số tiền họ rút mà không làm mất quyền riêng tư. **Các nhóm bảo mật đưa ra một khái niệm chung: Cho phép bằng chứng về tư cách thành viên ("Tôi xác nhận rằng số tiền rút của tôi đến từ một trong những khoản tiền gửi này") hoặc bằng chứng loại trừ ("Tôi xác nhận rằng số tiền rút của tôi không đến từ bất kỳ khoản tiền gửi nào trong số này" ) . **Bài viết này thảo luận về đề xuất này và giải thích cách sử dụng đề xuất này để đạt được sự cân bằng giữa người dùng trung thực và không trung thực.
Lưu ý rằng nhóm quyền riêng tư cung cấp các lựa chọn bổ sung bằng cách mở rộng nhóm hành động của người dùng. Họ vẫn có thể cung cấp chứng nhận chi tiết hơn cho các đối tác cụ thể nếu được yêu cầu. Tuy nhiên, trong một số trường hợp, bằng chứng về tư cách thành viên hoặc loại trừ có thể là đủ. Ngoài ra, tùy chọn phát hành công khai các chứng nhận này mang lại một số lợi thế so với việc tiết lộ song phương.
2. Nền tảng kỹ thuật
Trong phần này, chúng tôi cung cấp thông tin tổng quan ngắn gọn về kỹ thuật và thảo luận về các khối xây dựng kỹ thuật cũng như nguyên tắc chung của các giao thức như Nhóm quyền riêng tư.
1. Quyền riêng tư của blockchain trước ZK-SNARK
Trong lịch sử, những người ủng hộ blockchain đã lập luận rằng mặc dù tất cả các giao dịch đều minh bạch nhưng blockchain vẫn bảo vệ quyền riêng tư vì chúng cung cấp tính ẩn danh.
Với sự ra đời của các công cụ phân tích và phân cụm hiện đại, việc bảo vệ quyền riêng tư này đã trở nên không đủ. Để cải thiện tính riêng tư của các chuỗi khối công khai, các công nghệ mạnh mẽ hơn như Token Join và Monero đã được giới thiệu. Tuy nhiên, những công nghệ này vẫn tiềm ẩn nguy cơ rò rỉ dữ liệu. **
Sau đó, sự xuất hiện của các công nghệ chứng minh không có kiến thức có mục đích chung, chẳng hạn như Zcash và Tornado Cash, có thể làm cho tập hợp ẩn danh của mỗi giao dịch bằng toàn bộ tập hợp của tất cả các giao dịch trước đó. Kỹ thuật này thường được gọi là ZK-SNARK.
2, ZK-SNARK
ZK-SNARK là một kỹ thuật cho phép người chứng minh chứng minh một tuyên bố toán học nhất định về dữ liệu công khai và riêng tư đồng thời đáp ứng hai đặc tính chính: không có kiến thức và tính đơn giản. **
● Không có kiến thức: Sẽ không có thông tin nào về dữ liệu riêng tư được tiết lộ ngoại trừ việc chứng minh rằng dữ liệu riêng tư nói trên tuân thủ các tuyên bố.
● **Đơn giản: **Bằng chứng ngắn gọn và có thể được xác minh nhanh chóng, ngay cả khi những tuyên bố đã được chứng minh yêu cầu tính toán tốn nhiều thời gian.
ZK-SNARK đã nhận được sự chú ý rộng rãi từ cộng đồng blockchain vì tầm quan trọng của chúng đối với khả năng mở rộng, chẳng hạn như ZK-rollups. Đối với các ứng dụng bảo mật, tính đơn giản không đặc biệt quan trọng nhưng không có kiến thức là điều cần thiết.
"Tuyên bố" được ZK-SNARK chứng minh có thể được coi là một loại chương trình được gọi là "mạch", tính toán kết quả của hàm f(x, w) với đầu vào công khai và riêng tư, sau đó chứng minh rằng đối với một công khai nhất định đầu vào x , tồn tại một đầu vào riêng w sao cho f(x, w) đánh giá là True.
3. Ứng dụng ZK-SNARK trong các hệ thống như Zcash và Tornado Cash
Có một số khác biệt nhỏ giữa các phiên bản khác nhau của Zcash và các hệ thống lấy cảm hứng từ nó (chẳng hạn như Tornado Cash). Tuy nhiên, logic cơ bản mà họ dựa vào rất giống nhau. Phần này mô tả một phiên bản đơn giản gần tương ứng với cách thức hoạt động của các giao thức này.
Mã thông báo bao gồm các bí mật do chủ sở hữu của chúng nắm giữ. Hai giá trị có thể được lấy từ s:
● ID mã thông báo công khai L = hàm băm + 1)
● nullifierU = hàm băm + 2)
Trong số đó, hàm băm (hash) dùng để chỉ hàm băm mật khẩu, chẳng hạn như SHA 256. Cho trước s, ID mã thông báo và bộ ghi số 0 có thể được tính toán. Tuy nhiên, với một tập hợp các số 0 và ID mã thông báo công khai, hành vi giả ngẫu nhiên của hàm băm đảm bảo rằng bạn không thể xác định số 0 nào được liên kết với ID mã thông báo nào trừ khi bạn biết các bí mật đã tạo ra cả hai.
Chuỗi khối theo dõi tất cả các ID mã thông báo đã được "tạo", cũng như tất cả các số 0 đã được "chi tiêu". Cả hai bộ đều không ngừng phát triển (trừ khi giao thức muốn thực thi khi phải sử dụng mã thông báo).
Một tập hợp các ID mã thông báo được lưu trữ trong cấu trúc dữ liệu được gọi là cây Merkle: nếu cây chứa N mục thì mỗi mục liền kề sẽ được băm (kết quả là ⌈ N/2 ⌉ băm) và mỗi giá trị băm liền kề này sẽ được băm lại (kết quả là trong hàm băm ⌈ N/4 ⌉), v.v., cho đến khi toàn bộ dữ liệu được đưa vào một "băm gốc" duy nhất.
Với một giá trị cụ thể trong cây và hàm băm gốc, bạn có thể cung cấp nhánh Merkle: "các giá trị chị em" được băm cùng nhau ở mỗi bước trên đường dẫn từ giá trị đó đến gốc. Nhánh Merkle này rất hữu ích vì nó là một đoạn dữ liệu nhỏ (log 2(N) băm) có thể được sử dụng để chứng minh rằng bất kỳ giá trị cụ thể nào thực sự có trong cây. Hình dưới đây cho thấy một ví dụ về cây Merkle có chiều cao 4.
Khi người dùng gửi tiền cho người khác, họ sẽ cung cấp những thông tin sau:
● Zerizer U bạn muốn chi tiêu
● ID mã thông báo L' của mã thông báo mới mong muốn được tạo (người nhận được yêu cầu cung cấp thông tin này)
● ZK-SNARK.
ZK-SNARK chứa các đầu vào riêng sau:
● bí mật của người dùng
● Nhánh Merkle trong cây ID mã thông báo, chứng minh rằng mã thông báo có ID mã thông báo L = hash(s + 1) thực sự đã được tạo tại một thời điểm nào đó trong quá khứ
Nó cũng chứa các đầu vào công cộng sau:
● U, số 0 của mã thông báo đang được sử dụng
● R, hàm băm gốc mà bằng chứng Merkle đang hướng tới
ZK-SNARK chứng minh hai tính chất:
● U = hàm băm + 2)
● Nhánh Merkle hợp lệ
Ngoài ZK-SNARK, giao thức còn kiểm tra những điều sau:
● R là hàm băm gốc hiện tại hoặc lịch sử của cây ID mã thông báo
● U không nằm trong tập hợp các số 0 đã sử dụng
Nếu giao dịch hợp lệ, nó sẽ thêm U vào tập hợp số nilifier đã chi và L' vào danh sách ID mã thông báo. Việc hiển thị U sẽ ngăn không cho một mã thông báo bị chi tiêu gấp đôi. Tuy nhiên, sẽ không có thông tin nào khác được tiết lộ. **Thế giới bên ngoài chỉ có thể biết thời điểm giao dịch được gửi; họ không có cách nào biết được thông tin về người đã gửi hoặc nhận các giao dịch đó và không có cách nào để phân biệt nguồn mã thông báo thống nhất. **
Có hai trường hợp ngoại lệ đối với mô hình trên: gửi tiền và rút tiền. Trong khoản tiền gửi, ID mã thông báo có thể được tạo mà không làm mất hiệu lực một số mã thông báo trước đó. Từ góc độ bảo vệ quyền riêng tư, tiền gửi không ẩn danh vì sự liên kết giữa L nhất định và sự kiện bên ngoài cho phép thêm L (trong Tornado Cash, gửi ETH vào hệ thống; trong Zcash, khai thác ZEC mới) là công khai.
Nói cách khác, **tiền gửi được liên kết với lịch sử giao dịch trong quá khứ của họ. **Khi rút tiền, một Zeroizer sẽ được sử dụng mà không cần thêm ID token mới. Điều này có thể ngắt kết nối việc rút tiền từ khoản tiền gửi tương ứng và gián tiếp khỏi lịch sử giao dịch trong quá khứ. Tuy nhiên, việc rút tiền có thể được liên kết với bất kỳ giao dịch nào trong tương lai xảy ra sau sự kiện rút tiền.
Phiên bản đầu tiên của Tornado Cash không có khái niệm chuyển khoản nội bộ, nó chỉ cho phép gửi và rút tiền. Các phiên bản sau này, vẫn đang trong giai đoạn thử nghiệm, cũng cho phép chuyển tiền nội bộ và tiền xu có mệnh giá khác nhau, bao gồm hỗ trợ cho các hoạt động "tách" và "hợp nhất". Chúng ta sẽ thảo luận về cách mở rộng hệ thống chuyển tiền riêng tư cơ bản và nhóm quyền riêng tư sang các mệnh giá tùy ý trong các chương sau.
4. ZK-SNARK trong nhóm riêng tư
**Ý tưởng cốt lõi của nhóm quyền riêng tư là người dùng không chỉ chứng minh rằng việc rút tiền có liên quan đến khoản tiền gửi trước đó thông qua bằng chứng không có kiến thức mà còn chứng minh rằng nó thuộc về một tập hợp liên kết chặt chẽ hơn. **Bộ sưu tập được liên kết có thể là tập hợp con của tất cả các khoản tiền gửi được thực hiện trước đó, một bộ sưu tập chỉ chứa tiền gửi của chính người dùng hoặc bất kỳ thứ gì ở giữa. Người dùng chỉ định tập hợp bằng cách cung cấp gốc Merkle của tập hợp được liên kết làm đầu vào công khai.
Như được hiển thị trong hình bên dưới, để đơn giản, chúng tôi không trực tiếp chứng minh rằng tập hợp liên quan thực sự là tập hợp con của các khoản tiền gửi được thực hiện trước đó; thay vào đó, chúng tôi chỉ yêu cầu người dùng sử dụng cùng một ID xu với nút lá để chứng minh hai nhánh Merkle thông qua kiến thức bằng không:
● Nhập nhánh Merkle của gốc R của tổng số ID xu
● Nhập nhánh Merkle của gốc RA của tập hợp liên kết được cung cấp
Mục đích là đặt bộ liên kết hoàn chỉnh ở đâu đó (có thể trên chuỗi). Khái niệm cốt lõi là: thay vì yêu cầu người dùng chỉ định chính xác số tiền họ rút đến từ khoản tiền gửi nào hoặc ở thái cực khác, không cung cấp thông tin nào khác ngoài bằng chứng về việc không chi tiêu gấp đôi, chúng tôi cho phép người dùng cung cấp một bộ tùy chọn có thể là nguồn số tiền, Và bộ này có thể rộng hoặc hẹp tùy theo ý muốn của họ.
Chúng tôi khuyến khích một hệ sinh thái giúp người dùng dễ dàng chỉ định một tập hợp các liên kết phù hợp với sở thích của họ hơn. Phần còn lại của bài viết này sẽ chỉ mô tả cơ sở hạ tầng dựa trên cơ chế cốt lõi đơn giản này và những hậu quả của nó.
3. Những cân nhắc thực tế và trường hợp sử dụng
Phân tích cách sử dụng các giao thức tăng cường quyền riêng tư trong thực tế từ góc độ ứng dụng.
1. Trường hợp sử dụng của các bộ sưu tập liên quan
Để minh họa giá trị của chương trình này trong môi trường thực thi pháp luật, đây là một ví dụ:
Giả sử chúng ta có năm người dùng: Alice, Bob, Carl, David, Eve. Bốn người dùng đầu tiên là những người dùng trung thực, tuân thủ pháp luật nhưng có ý thức bảo mật, trong khi Eve là một tên trộm. Bởi công chúng biết Eve chính là kẻ trộm qua thông tin những đồng xu tại địa chỉ có dấu “Eve” đã bị đánh cắp. Trong thực tế, điều này thường xảy ra: trên các chuỗi khối công khai, số tiền được tạo ra do khai thác lỗ hổng giao thức DeFi sẽ được theo dõi và gắn thẻ để xác định các khoản tiền bất hợp pháp chảy vào Tornado Cash.
Khi mỗi người trong số năm người dùng thực hiện rút tiền, họ có thể chọn nhóm liên quan để chỉ định. Nhóm liên kết của họ phải bao gồm tiền gửi của riêng họ, nhưng họ có thể tự do lựa chọn địa chỉ nào khác để bao gồm. Bốn người dùng đầu tiên một mặt được thúc đẩy bởi mong muốn bảo vệ quyền riêng tư của họ ở mức độ lớn nhất có thể. Điều này thúc đẩy họ có xu hướng mở rộng tập hợp hiệp hội của mình. Mặt khác, họ muốn giảm nguy cơ đồng tiền của họ bị người bán hoặc sàn giao dịch coi là đáng ngờ. Có một cách dễ dàng để làm điều này: họ không đưa Eve vào bộ sưu tập liên quan của họ. Vì vậy, đối với bốn người trong số họ, sự lựa chọn rất rõ ràng: hãy đặt liên kết của họ là {Alice, Bob, Carl, David}.
Tất nhiên, Eve cũng muốn tối đa hóa tập liên kết của mình. Nhưng cô ấy không thể loại trừ khoản tiền gửi của chính mình, vì vậy cô ấy buộc phải có số tiền liên quan của mình bằng với tập hợp của cả năm khoản tiền gửi. Việc lựa chọn bộ sưu tập liên quan của người tham gia được hiển thị trong hình bên dưới.
Mặc dù bản thân Eve chưa cung cấp bất kỳ thông tin nào, nhưng thông qua một quy trình loại trừ đơn giản, chúng ta có thể rút ra một suy luận rõ ràng: bước rút lui thứ năm chỉ có thể đến từ Eve.
2. Xây dựng các bộ sưu tập liên quan
Phần trước đã minh họa một cách khả thi để sử dụng các nhóm liên kết trong một giao thức tương tự như nhóm quyền riêng tư và cách tách những người tham gia trung thực khỏi những nhóm xấu. Lưu ý rằng hệ thống này không phụ thuộc vào lòng vị tha của Alice, Bob, Carl và David; họ có những động cơ rõ ràng để biện minh cho sự chia ly của mình. Bây giờ chúng ta hãy xem xét việc xây dựng một bộ sưu tập kết hợp chi tiết hơn. Nói chung, có hai chiến lược chính để tạo ra các bộ sưu tập kết hợp. Chúng được mô tả dưới đây và được hiển thị trong hình bên dưới.
● **Bao gồm (hoặc tư cách thành viên): **Xác định một nhóm tiền gửi cụ thể mà chúng tôi có bằng chứng thuyết phục rằng chúng có rủi ro thấp và xây dựng một nhóm liên quan chỉ chứa các khoản tiền gửi này.
● Loại trừ: Xác định một nhóm tiền gửi cụ thể mà chúng tôi có bằng chứng mạnh mẽ cho thấy có rủi ro cao và xây dựng một tập hợp liên kết bao gồm tất cả các khoản tiền gửi ngoại trừ những khoản tiền gửi đó.
Trong thực tế, người dùng không chọn thủ công các khoản tiền gửi để đưa vào bộ sưu tập liên quan của họ. Thay vào đó, người dùng sẽ đăng ký các bên trung gian mà chúng tôi gọi là Nhà cung cấp bộ sưu tập liên kết (ASP), tạo ra Bộ sưu tập liên kết với các thuộc tính cụ thể. **Trong một số trường hợp, ASP có thể được xây dựng hoàn toàn trên chuỗi mà không cần sự can thiệp của con người (hoặc AI). Trong các trường hợp khác, ASP sẽ tạo các bộ sưu tập liên kết một cách độc lập và xuất bản các bộ sưu tập liên kết trên chuỗi hoặc ở nơi khác.
Chúng tôi thực sự khuyên bạn nên xuất bản ít nhất gốc Merkle của bộ liên kết trên chuỗi; điều này loại bỏ khả năng các ASP độc hại thực hiện một số loại tấn công nhất định đối với người dùng (ví dụ: cung cấp cho những người dùng khác nhau các bộ liên kết khác nhau nhằm cố gắng loại bỏ ẩn danh của họ). Toàn bộ bộ sưu tập phải có sẵn thông qua API hoặc lý tưởng nhất là thông qua hệ thống lưu trữ phi tập trung chi phí thấp như IPFS.
Khả năng tải xuống toàn bộ bộ sưu tập liên kết rất quan trọng vì nó cho phép người dùng tạo bằng chứng tư cách thành viên cục bộ mà không tiết lộ bất kỳ thông tin bổ sung nào cho ASP, thậm chí không tiết lộ số tiền gửi tương ứng với số tiền họ rút.
Đây là cách ASP có thể được cấu trúc trong thực tế:
● Bổ sung bị trì hoãn, loại trừ các tác nhân xấu: Mọi khoản tiền gửi sẽ tự động được thêm vào bộ sưu tập liên quan sau một thời gian cố định (ví dụ: 7 ngày), nhưng nếu hệ thống phát hiện khoản tiền gửi có liên quan đến hành vi xấu đã biết (ví dụ: trộm cắp quy mô lớn hoặc địa chỉ trong danh sách trừng phạt do chính phủ công bố), khoản tiền gửi sẽ không bao giờ được thêm vào. Trong thực tế, điều này có thể đạt được thông qua các khoản thu thập do cộng đồng quản lý hoặc các nhà cung cấp dịch vụ sàng lọc giao dịch hiện có đã thực hiện công việc xác định và theo dõi tiền gửi liên quan đến hành vi xấu.
● Phí hàng tháng cho một người: Để tham gia bộ sưu tập liên quan, giá trị của khoản tiền gửi phải dưới mức tối đa cố định nào đó và người gửi tiền phải chứng minh mà không hề biết rằng họ nắm giữ một số mã thông báo nhận dạng (ví dụ: bởi một chính phủ được hỗ trợ hệ thống ID quốc gia hoặc các cơ chế nhẹ như xác minh tài khoản mạng xã hội). Được kết hợp với một tham số bổ sung đại diện cho cơ chế thu thập dữ liệu của tháng hiện tại để đảm bảo rằng mỗi danh tính chỉ có thể gửi tiền gửi vào bộ sưu tập liên quan mỗi tháng một lần. Thiết kế cố gắng thực hiện tinh thần của nhiều quy tắc AML phổ biến, theo đó các khoản thanh toán vi mô dưới một ngưỡng nhất định sẽ cho phép mức độ riêng tư cao hơn. Lưu ý rằng điều này có thể được thực hiện hoàn toàn như một hợp đồng thông minh, không yêu cầu giám sát thủ công để duy trì hoạt động liên tục.
● **Phí hàng tháng cho thành viên cộng đồng đáng tin cậy: **Tương tự như phí hàng tháng cho một người độc thân, nhưng hạn chế hơn: người dùng phải chứng minh họ là thành viên của một cộng đồng có độ tin cậy cao. Các thành viên cộng đồng có độ tin cậy cao đồng ý cung cấp quyền riêng tư cho nhau.
● **Tính điểm theo thời gian thực dựa trên AI: **Hệ thống AI ASP có thể cung cấp điểm rủi ro cho mỗi khoản tiền gửi trong thời gian thực và hệ thống sẽ đưa ra một tập hợp liên quan chứa các khoản tiền gửi có điểm rủi ro dưới một ngưỡng nhất định. Có khả năng, ASP có thể xuất ra nhiều bộ tương ứng với nhiều ngưỡng điểm rủi ro.
4. Mô tả kỹ thuật bổ sung
Trong phần này, chúng tôi phân tích cách đề xuất hỗ trợ các mệnh giá tùy ý và thảo luận về các trường hợp đặc biệt như chứng nhận lại, bằng chứng trực tiếp song phương và bằng chứng tuần tự.
1. Hỗ trợ bất kỳ giáo phái nào
Hệ thống tiền xu bảo vệ quyền riêng tư được đơn giản hóa ở trên chỉ hỗ trợ chuyển tiền xu có cùng mệnh giá. Zcash hỗ trợ các mệnh giá tùy ý bằng cách sử dụng mô hình UTXO. Mỗi giao dịch có thể có nhiều đầu vào (cần xuất bản số nilifier cho mỗi đầu vào) và nhiều đầu ra (cần xuất bản ID mã thông báo cho mỗi đầu ra). Mỗi ID mã thông báo được tạo phải có mệnh giá mật mã được đính kèm. Ngoài việc chứng minh tính hợp lệ của zeroizer, mỗi giao dịch phải kèm theo bằng chứng bổ sung rằng tổng mệnh giá của các đồng tiền được tạo ra không vượt quá tổng mệnh giá của các đồng tiền đã bỏ ra. Hình dưới đây minh họa bằng chứng bổ sung này.
Thiết kế này có thể được mở rộng để hỗ trợ việc gửi và rút tiền bằng cách coi tiền gửi là đầu vào (không được mã hóa) và việc rút tiền là đầu ra (không được mã hóa). Ngoài ra, thiết kế có thể bị hạn chế để đơn giản hóa việc phân tích. Ví dụ: chỉ có thể cho phép rút một phần để giao dịch có một đầu vào được mã hóa và hai đầu ra: đầu ra không được mã hóa thể hiện việc rút tiền và đầu ra "thay đổi" được mã hóa thể hiện số tiền còn lại, có thể được sử dụng để rút tiền trong tương lai.
Một câu hỏi tự nhiên là làm thế nào để mở rộng thiết kế này để hỗ trợ các nhóm quyền riêng tư. Việc chèn nó vào nhóm quyền riêng tư không thay đổi là không lý tưởng vì biểu đồ giao dịch không nhất quán với những gì chúng tôi mong đợi bằng trực giác: nếu người dùng gửi 10 mã thông báo và sau đó chi 1 + 2 + 3 + 4 trong bốn mã thông báo rút tiền liên tiếp, chúng tôi muốn xử lý từng mã thông báo đó. trong số bốn lần rút tiền này làm nguồn gửi 10 token ban đầu. Nhưng kết quả thực tế như được hiển thị bên dưới: nguồn của lần rút tiền đầu tiên là khoản gửi 10 mã thông báo và sau đó nguồn của lần rút thứ hai là đầu ra thay đổi của 9 mã thông báo được tạo bởi lần rút tiền đầu tiên, v.v. Điều này gây ra vấn đề trong thực tế vì nó yêu cầu ASP xác thực khoản tiền gửi trung gian và thêm nó vào bộ sưu tập liên quan của nó.
Để tất cả bốn lần rút tiền trong ví dụ này có thể lấy 10 xu ban đầu làm nguồn, chúng ta cần giải quyết hai vấn đề:
● Đảm bảo rằng mỗi lần rút tiền một phần không được liên kết công khai với các lần rút tiền khác
● Cho phép mỗi lần rút tiền một phần bao gồm khoản tiền gửi với tư cách là thành viên của bộ sưu tập được liên kết
Nếu chúng tôi chỉ hỗ trợ rút tiền một phần, thay vì các giao dịch MIMO phức tạp hơn và đảm bảo rằng mỗi lần rút tiền có một "khoản tiền gửi gốc" tương ứng được xác định duy nhất, thì có nhiều cách để đạt được điều này một cách trực tiếp. Một cách tiếp cận tự nhiên và có thể mở rộng là truyền bá lời hứa về một số thông tin thông qua các giao dịch. Ví dụ: chúng tôi có thể yêu cầu giao dịch chứa hàm băm cam kết (coinID+hash®), thêm một số giá trị ngẫu nhiên r để đảm bảo làm mù và yêu cầu ZK-SNARK chứng minh rằng cam kết trong giao dịch giống với giao dịch gốc của nó. Nếu bản thân giao dịch gốc là rút tiền thì cam kết giống với ID coin của khoản tiền gửi ban đầu và nếu giao dịch gốc là tiền gửi thì cam kết giống với ID coin của khoản tiền gửi ban đầu. Do đó, mọi giao dịch trong chuỗi phải có cam kết về ID tiền gửi ban đầu và yêu cầu bằng chứng rằng giá trị này nằm trong tập hợp liên quan do giao dịch cung cấp.
Để cải thiện quyền riêng tư trước các cuộc tấn công tổng hợp số dư, chúng tôi cũng có thể hỗ trợ hợp nhất tiền xu. Ví dụ: nếu tôi còn một số xu, tôi có thể hợp nhất chúng với khoản tiền gửi tiếp theo của mình. Để đáp ứng điều này, chúng tôi có thể yêu cầu các giao dịch cam kết với một bộ ID đồng xu và yêu cầu các giao dịch có nhiều đầu vào cam kết với sự kết hợp của cha mẹ chúng. Việc rút tiền sẽ chứa bằng chứng cho thấy tất cả các ID xu đã cam kết đều nằm trong tập hợp được liên kết.
2. Trường hợp đặc biệt
● **Chứng nhận lại: **Người dùng cần thông tin tiền gửi bí mật để rút tiền gửi tương tự như các giao thức nhóm riêng tư. Thông tin bí mật tương tự cũng được sử dụng để xây dựng bằng chứng về tư cách thành viên của tập hợp kết hợp. Việc lưu giữ thông tin bí mật cho phép người dùng tạo bằng chứng mới cho các bộ khác nhau hoặc các bộ liên quan được cập nhật. Điều này mang lại cho người dùng sự linh hoạt cao hơn nhưng cũng có thể gây ra những rủi ro bổ sung.
● Bằng chứng trực tiếp song phương: Trong một số trường hợp, người dùng có thể được yêu cầu tiết lộ nguồn rút tiền chính xác cho bên kia. Người dùng có thể tạo một bộ sưu tập liên quan chỉ chứa tiền gửi của họ và tạo bằng chứng chống lại bộ sưu tập đó. Những bằng chứng này thường là trường hợp ngoại lệ và chỉ góp phần đảm bảo quyền riêng tư một phần khi được chia sẻ giữa hai bên. Tuy nhiên, việc chia sẻ bằng chứng đòi hỏi phải thiết lập các giả định tin cậy mạnh mẽ.
● Bằng chứng về trình tự: Trong nền kinh tế giao dịch nhanh sử dụng hệ thống như nhóm bảo mật, giao thức cần được sửa đổi để thích ứng với môi trường này. Ngoài các loại giao dịch gửi và rút tiền, giao thức cũng cần hỗ trợ các hoạt động gửi nội bộ để tăng hiệu quả. Ngoài ra, bằng cách chuyển các nhánh và khóa Merkle, người dùng có thể truyền bá thông tin liên quan đến lịch sử giao dịch để người nhận có thể xác minh nguồn gốc của tiền. Điều này đảm bảo rằng mỗi người dùng có thông tin tối thiểu họ cần để tin tưởng vào số tiền họ nhận được.
Trong thực tế, một đồng xu có thể có nhiều “nguồn gốc”. Ví dụ: Bob là chủ quán cà phê, anh ấy nhận được 5 token từ Alice, 4 token từ Ashley, 7 token từ Anne và cuối ngày anh ấy cần trả cho Carl 15 token để trả tiền cho bữa tối. Thay vào đó, David có thể đã nhận được 15 token từ Carl, 25 token từ Chris và muốn gửi 30 token cho Emma (một sàn giao dịch). Trong những trường hợp phức tạp hơn này, chúng tôi tuân theo cùng một nguyên tắc: lịch sử đã được thêm vào bộ sưu tập liên quan đủ sớm có thể bị bỏ qua, trong khi lịch sử mới hơn cần được chuyển tiếp.
5. Thêm chi tiết
Một hệ thống như nhóm quyền riêng tư có thể cho phép người dùng được bảo vệ nhiều hơn về quyền riêng tư của dữ liệu giao dịch tài chính của họ trong khi vẫn duy trì khả năng chứng minh sự tách biệt khỏi hoạt động bất hợp pháp đã biết. Chúng tôi hy vọng rằng những người dùng trung thực sẽ được khuyến khích tham gia vào chương trình như vậy thông qua sự kết hợp của hai yếu tố:
● Mong muốn quyền riêng tư
● Mong muốn tránh khơi dậy sự nghi ngờ
1. Sự đồng thuận xã hội và tập hợp liên kết
Nếu có sự đồng thuận hoàn toàn về việc quỹ tốt hay xấu thì hệ thống sẽ tạo ra một trạng thái cân bằng riêng biệt đơn giản. Tất cả người dùng có nội dung “tốt” đều có động cơ mạnh mẽ và khả năng chứng minh rằng họ thuộc về nhóm liên kết “chỉ tốt”. Mặt khác, những kẻ xấu sẽ không thể cung cấp bằng chứng này. Họ vẫn có thể gửi tiền "xấu" vào nhóm, nhưng điều đó sẽ không mang lại lợi ích gì cho họ. Mọi người đều có thể dễ dàng xác định rằng tiền đã được rút từ một giao thức tăng cường quyền riêng tư và thấy rằng việc rút tiền tham chiếu đến một bộ sưu tập liên quan có chứa tiền gửi từ các nguồn đáng ngờ. Hơn nữa, tiền "xấu" không làm hỏng tiền "tốt". Khi tiền được rút từ các khoản tiền gửi hợp pháp, chủ sở hữu của chúng có thể chỉ cần loại trừ tất cả các khoản tiền gửi "xấu" đã biết khỏi bộ sưu tập liên quan của họ.
Khi có sự đồng thuận toàn cầu và khi kết luận về việc tài trợ được coi là "tốt" hay "xấu" phụ thuộc vào quan điểm xã hội hoặc quyền tài phán, thì tập hợp các hiệp hội có thể khác nhau đáng kể. Giả sử có hai khu vực pháp lý với các bộ quy tắc khác nhau. Các chủ thể ở cả hai khu vực pháp lý A và B có thể sử dụng cùng một giao thức tăng cường quyền riêng tư và chọn cấp các chứng nhận đáp ứng các yêu cầu của khu vực pháp lý tương ứng của họ. Cả hai đều có thể dễ dàng thực hiện quyền riêng tư trong các bộ sưu tập liên quan của riêng mình và loại trừ các khoản rút tiền không tuân thủ các yêu cầu của khu vực pháp lý tương ứng của họ. Nếu được yêu cầu, bằng chứng tư cách thành viên có thể được cấp cho sự giao nhau của hai tập hợp liên kết, qua đó chứng minh một cách đáng tin cậy rằng tiền gửi tương ứng với số tiền rút của họ tuân thủ các yêu cầu của cả hai khu vực pháp lý.
Vì vậy, đề xuất này rất linh hoạt và nên được coi là cơ sở hạ tầng trung lập. Một mặt, nó chống lại sự kiểm duyệt. Nó cho phép mọi người tham gia bộ sưu tập liên quan mà họ lựa chọn và duy trì quyền riêng tư trong cộng đồng của riêng họ. Mặt khác, người ngoài có thể yêu cầu bằng chứng chống lại một nhóm hiệp hội cụ thể đáp ứng các yêu cầu quy định của họ. Do đó, ngay cả khi có một cộng đồng những kẻ xấu tham gia giao thức tăng cường quyền riêng tư, họ sẽ không thể che giấu nguồn gốc đáng ngờ của các khoản tiền gửi miễn là thông tin được phản ánh chính xác trong quá trình xây dựng tập hợp liên quan.
2. Thuộc tính của các bộ sưu tập liên quan
Bộ sưu tập liên kết cần phải có các thuộc tính nhất định để hoạt động. Việc thu thập cần phải chính xác để người dùng có thể tin tưởng rằng họ đang sử dụng số tiền đã rút một cách an toàn. Hơn nữa, các thuộc tính của mỗi bộ phải ổn định, tức là ít có khả năng thay đổi theo thời gian. Điều này làm giảm nhu cầu rút tiền xác nhận lại đối với các bộ sưu tập mới. Cuối cùng, để đạt được sự bảo vệ quyền riêng tư có ý nghĩa, tập liên kết phải đủ lớn và chứa nhiều loại tiền gửi khác nhau. Tuy nhiên, các thuộc tính này xung đột với nhau. Nói chung, các bộ sưu tập lớn và đa dạng có thể có đặc tính bảo mật tốt hơn nhưng có thể kém chính xác và ổn định hơn, trong khi các bộ sưu tập nhỏ hơn dễ bảo trì hơn nhưng cung cấp ít quyền riêng tư hơn.
3. Cân nhắc thực tế và cạnh tranh
Các thực thể được quản lý chấp nhận tài sản tiền điện tử phải đảm bảo rằng luật pháp và quy định mà họ phải tuân theo cho phép chấp nhận các khoản tiền đó. Ngày nay, nhiều thực thể trong số này dựa vào cái gọi là công cụ sàng lọc giao dịch: phần mềm hoặc dịch vụ phân tích chuỗi khối để xác định hoạt động đáng ngờ tiềm ẩn, liên kết đến địa chỉ bất hợp pháp hoặc các giao dịch không tuân thủ khác. Các công cụ sàng lọc thường thể hiện rủi ro liên quan đến mỗi giao dịch thông qua điểm rủi ro. Điểm này dựa trên điểm đến của số tiền được chuyển và lịch sử giao dịch của chúng. Về vấn đề này, các giao thức tăng cường quyền riêng tư có thể đặt ra những thách thức. Họ loại bỏ mối liên kết có thể nhìn thấy giữa tiền gửi và rút tiền. Do đó, với sự hiện diện của các giao thức tăng cường quyền riêng tư, việc chấm điểm rủi ro cần phải tính đến bằng chứng và chỉ định điểm dựa trên các tập hợp liên quan.
Các công cụ và dịch vụ sàng lọc giao dịch chủ yếu được cung cấp bởi các công ty chuyên nghiệp có chuyên môn về phân tích blockchain và các lĩnh vực pháp lý liên quan. Lý tưởng nhất là các công ty này (và bất kỳ ai khác) sẽ có quyền truy cập vào tất cả các chứng chỉ thành viên và các bộ sưu tập liên quan tương ứng của họ để cung cấp điểm rủi ro chính xác cho tất cả các giao dịch. Do đó, chúng tôi khuyên bạn nên lưu trữ tất cả bằng chứng trên blockchain hoặc kho lưu trữ bằng chứng có thể truy cập công khai khác. Ngoại lệ duy nhất là chứng chỉ thành viên có kích thước một được chia sẻ với một đối tác cụ thể. Vì những lý do hiển nhiên, những lời chứng thực này không nên được công bố rộng rãi.
Việc lưu trữ bằng chứng trực tiếp trên chuỗi sẽ làm tăng thêm chi phí giao dịch, nhưng làm giảm nỗ lực phối hợp, giúp cạnh tranh công bằng hơn và giảm thiểu rủi ro gần như độc quyền mà các nhà cung cấp công cụ sàng lọc có thể tạo ra do hiểu biết về bằng chứng không công khai.
Thiết lập chung của nhóm riêng tư rất linh hoạt. Giao thức có thể được tùy chỉnh cho các trường hợp sử dụng khác nhau bằng cách tạo các bộ sưu tập liên kết cụ thể. Dưới đây là hai ví dụ về các bộ sưu tập liên kết đặc biệt này:
● **Liên minh ngân hàng thương mại có thể tạo một bộ sưu tập liên quan chỉ chứa tiền gửi của khách hàng của họ. **Điều này đảm bảo rằng mọi khoản rút tiền được tạo bằng bằng chứng về việc thu thập đều phải trải qua các thủ tục nhận biết khách hàng (KYC) và chống rửa tiền (AML) tại một trong các ngân hàng tham gia, nhưng không tiết lộ khoản rút tiền nào thuộc về khách hàng nào.
● **Trong trường hợp các trung gian tài chính được yêu cầu ghi lại rõ ràng nguồn tiền, họ có thể yêu cầu người dùng cung cấp bằng chứng đối với một tập hợp liên quan chỉ chứa tiền gửi của người dùng. **Bằng chứng này sau đó sẽ được trao đổi song phương với bên trung gian, cho phép họ theo dõi tiền như thể người dùng chưa bao giờ sử dụng nhóm bảo mật. Mặc dù điều này yêu cầu người dùng tin tưởng vào bên trung gian không tiết lộ bằng chứng, nhưng lý tưởng nhất là nó cho phép người dùng tuân thủ các quy định mà không cần phải tiết lộ thông tin cho công chúng.
4. Lựa chọn và thay thế thiết kế
Các thiết lập dựa trên tập hợp liên kết, bằng chứng zk và tiết lộ tự nguyện rất linh hoạt. Mặc dù điều này rất hữu ích trong việc đảm bảo rằng đề xuất có thể được điều chỉnh cho phù hợp với các khu vực pháp lý khác nhau, nhưng cần hết sức thận trọng đối với các lựa chọn thiết kế cụ thể. Đặc biệt, có hai điều chỉnh tiềm năng mà chúng tôi phản đối. Chúng tôi tin rằng chúng có vấn đề về yêu cầu niềm tin và có thể tạo ra cấu trúc thị trường gần như độc quyền. Dưới đây chúng tôi mô tả ngắn gọn và thảo luận về các lựa chọn thay thế này:
● Quyền truy cập tập trung: Các cơ quan thực thi pháp luật, nhà cung cấp dịch vụ chấm điểm rủi ro tiền điện tử hoặc các tác nhân tương tự có thể có quyền truy cập để xem các liên kết giữa các giao dịch của người dùng trong khi vẫn duy trì quyền riêng tư với những người khác.
● **Danh sách trắng trên toàn hệ thống: **Hệ thống quyền riêng tư có thể đặt ra các hạn chế đối với loại người dùng có thể gửi tiền vào nhóm của họ, yêu cầu họ cung cấp bằng chứng bổ sung hoặc yêu cầu gửi tiền phải chờ trong một khoảng thời gian trong đó Điểm rủi ro tập trung hệ thống có thể từ chối tiền gửi.
Hai phương pháp này giống nhau ở chỗ chúng đặc quyền cho các thực thể cụ thể. Điều này đặt ra những câu hỏi phức tạp về quản trị: Ai có quyền truy cập vào thông tin này? Ai có thẩm quyền quản lý quyền? Các công ty tư nhân dường như không phải là một lựa chọn tốt, vì bất kỳ đặc quyền nào cũng có thể tạo ra cấu trúc thị trường độc quyền, trong đó một số công ty có quyền truy cập vào dữ liệu cho phép họ cung cấp các dịch vụ này, trong khi những công ty khác không thể cạnh tranh.
Tương tự như vậy, nhiều vấn đề về quản trị và chính trị sẽ phải đối mặt khi giao quyền cho các tổ chức công, đặc biệt là trong môi trường quốc tế. Ngay cả khi một tổ chức cho đến nay vẫn đáng tin cậy 100%, không lạm dụng quyền lực của mình để theo đuổi một chương trình nghị sự chính trị và không phụ thuộc vào các thực thể khác có thể buộc tổ chức đó lạm dụng quyền lực của mình thì tình trạng này vẫn là triệu chứng của một trạng thái không hoạt động. Các tổ chức, thành viên, quốc gia và cơ cấu chính trị trong tổ chức thay đổi theo thời gian. Có thể có áp lực từ bên ngoài và sự tồn tại của những đặc quyền này có thể tạo thêm động lực để phá vỡ và giành được ảnh hưởng đối với hệ thống quản trị của tổ chức.
Hơn nữa, các cuộc tấn công bên trong hoặc bên ngoài tổ chức hoặc lỗi thay mặt cho các thực thể tập trung có thể gây ra hậu quả sâu rộng. Chúng tôi tin rằng nên ngăn chặn việc tạo ra các điểm thất bại tập trung như vậy.
Tuy nhiên, chúng tôi nhận thấy rằng các quy mô và hoàn cảnh giao dịch khác nhau có thể yêu cầu các kết hợp chứng nhận khác nhau. Ví dụ: đối với các giao dịch lớn, nhiều người dùng có thể sẽ cung cấp bằng chứng cơ bản về loại trừ trên chuỗi và cung cấp thông tin chi tiết hơn về nguồn tiền cho đối tác của họ.
5. Hướng nghiên cứu chuyên sâu
Mặc dù nghiên cứu này cung cấp cái nhìn tổng quan về cách có thể sử dụng các giao thức nâng cao quyền riêng tư dựa trên zkSNARK trong các cài đặt được quản lý, nhưng có một số khía cạnh cần được nghiên cứu thêm.
Đầu tiên, mọi người cần nhận ra rằng quyền riêng tư đạt được thông qua các giao thức này phụ thuộc vào nhiều yếu tố khác nhau. Kẻ tấn công có thể liên kết việc rút tiền với các khoản tiền gửi cụ thể dựa trên tập hợp liên kết không đủ lớn, lựa chọn gốc kém và lỗi người dùng.
Ngoài ra, lựa chọn của người dùng khác có thể ảnh hưởng xấu đến quyền riêng tư của bạn. Trong những trường hợp cực đoan, những người khác trong nhóm sẽ công bố bằng chứng về tư cách thành viên cỡ một, tiết lộ mối liên hệ trực tiếp giữa việc gửi và rút tiền của họ. Rõ ràng, điều này sẽ ngầm tiết lộ mối liên hệ giữa các giao dịch gửi và rút tiền duy nhất còn lại. Trong một ví dụ tinh tế hơn, các ràng buộc từ nhiều bằng chứng thành viên khác nhau có thể được sử dụng để trích xuất thông tin và có khả năng liên hệ giữa việc gửi và rút tiền với xác suất cao. Khi thông tin được chứng thực này được kết hợp với siêu dữ liệu giao dịch, các thuộc tính quyền riêng tư của giao thức có thể bị xâm phạm.
Cuối cùng, một ASP độc hại có thể chọn biên dịch tập hợp liên kết được đề xuất theo cách cho phép chúng tối đa hóa việc trích xuất thông tin hoặc tăng tính ẩn danh được nhận thức bằng cách thêm tiền gửi vào nơi đã biết số tiền rút tương ứng. Tất cả những vấn đề này đòi hỏi phải nghiên cứu thêm để đánh giá các thuộc tính quyền riêng tư được cung cấp. Theo hướng tương tự, sẽ rất thú vị khi nghiên cứu sâu hơn về các đặc tính của sự cân bằng tách biệt, mô hình hóa cách người chơi tốt và người chơi xấu hành xử theo các giả định nhất định và bằng chứng công khai về điều trước ảnh hưởng đến quyền riêng tư của người sau.
Các chuyên gia pháp lý có thể nghiên cứu thêm các yêu cầu công bố thông tin cụ thể. Kế hoạch được đề xuất trong bài viết này rất linh hoạt và những hiểu biết sâu sắc từ các chuyên gia pháp lý có thể giúp điều chỉnh thỏa thuận và hệ sinh thái được xây dựng xung quanh nó để đảm bảo tuân thủ trong các khu vực pháp lý khác nhau.
6. Kết luận
Trong nhiều trường hợp, quyền riêng tư và tuân thủ được coi là xung đột với nhau. Bài viết này đề xuất rằng điều này không nhất thiết phải xảy ra nếu các giao thức tăng cường quyền riêng tư cho phép người dùng chứng minh các thuộc tính nhất định về nguồn tiền của họ. Ví dụ: giả định rằng người dùng có thể chứng minh rằng tiền của họ không liên quan đến tiền gửi từ các nguồn bất hợp pháp đã biết hoặc tiền là một phần của một khoản tiền gửi cụ thể mà không tiết lộ thêm bất kỳ thông tin nào.
Thiết lập như vậy có thể tạo ra trạng thái cân bằng riêng biệt trong đó người dùng trung thực được khuyến khích mạnh mẽ để chứng minh rằng họ thuộc về một số nhóm liên kết tuân thủ và duy trì quyền riêng tư trong nhóm đó. Ngược lại, đối với những người dùng không trung thực thì họ không thể cung cấp bằng chứng đó. Điều này cho phép người dùng trung thực tách mình khỏi khoản tiền gửi của bên thứ ba mà họ không đồng ý hoặc ngăn họ sử dụng tiền của mình trong một môi trường tuân thủ. Chúng tôi tin rằng đề xuất này rất linh hoạt và có thể được điều chỉnh theo các yêu cầu pháp lý tiềm năng khác nhau.
Bài viết này nên được coi là một đóng góp cho sự tồn tại tiềm năng trong tương lai của quyền riêng tư và quy định tài chính. Chúng tôi muốn tạo điều kiện thuận lợi cho các cuộc thảo luận và hướng cuộc trò chuyện theo hướng tích cực, mang tính xây dựng hơn. Cần phải có sự hợp tác giữa các học viên, học giả từ nhiều ngành khác nhau, các nhà hoạch định chính sách và cơ quan quản lý để mở rộng và sửa đổi đề xuất này; mục tiêu cuối cùng là tạo ra cơ sở hạ tầng nâng cao quyền riêng tư có thể được sử dụng trong các môi trường được quản lý.