nguyên bản:Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium》
Tác giả: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar và Ameen Soleimani
Biên soạn: Những kẻ hèn nhát hàng ngày như thế nào
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 hiện 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 tăng cường 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. Bằng chứng cho thấy nhóm hack Triều Tiên cũng sử dụng giao thức tăng cường quyền riêng tư này, đỉnh điểm là các địa chỉ hợp đồng thông minh của giao thức đượ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 (thường được gọi là Danh sách SDN) do Văn phòng Tài sản nước ngoài của Hoa Kỳ duy trì. Kiểm soát (OFAC). ).
Vấn đề chính của 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.Do đó, 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ư.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 chứng minh 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 chứng minh 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 nó để đạ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 tổng quan kỹ thuật ngắn gọn và thảo luận về cấu trúc kỹ thuật cũng như các nguyên tắc chung của các giao thức như Nhóm bảo mậ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 quyền riêng tư trên 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.
Tiếp theo là các kỹ thuật chứng minh không có kiến thức có mục đích chung 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-SNARKs
ZK-SNARK là công nghệ cho phép người chứng minh chứng minh các tuyên bố toán học nhất định về dữ liệu công khai và riêng tư,Đáp ứng đồng thời hai thuộ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 việc chứng minh rằng dữ liệu riêng tư đó tuân thủ các yêu cầu bồi thường.
● Sự đơ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 thời gian.
ZK-SNARK đã nhận được sự chú ý rộng rãi từ cộng đồng blockchain do 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.
Đã được chứng minh bởi ZK-SNARKs"tuyên bố"có thể được xem như là một"mạch điện"Một loại chương trình tính toán kết quả của hàm f(x, w) trên đầu vào công cộng và đầu vào riêng tư, sau đó chứng minh rằng với một đầu vào công khai x nhất định, tồn tại một đầu vào riêng w sao cho f(x, w) ước tính bằng ĐÚNG VẬY.
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 = hash(s + 1)
● NullifierU = hash(s + 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 bộ vô hiệu hóa 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ể chắc chắn bộ vô hiệu hóa 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.
Theo dõi chuỗi khối có"tạo nên"Tất cả ID mã thông báo của và có"tiêu"của tất cả các chất vô hiệu hóa. 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).
Bộ sưu tập 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, mỗi mục liền kề sẽ được băm (dẫn đến ⌈ N/2 ⌉ băm), mỗi giá trị băm liền kề này sẽ được băm lại (kết quả là ⌈ N/4 ⌉ băm), v.v., cho đến khi toàn bộ dữ liệu được gửi đến một"hàm băm gốc"ở giữa.
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: hàm băm được băm cùng nhau ở mỗi bước trên đường dẫn từ giá trị đó đến gốc."giá trị chị em". 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:
● Zeroizer 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 = hash(s + 2)
● Nhánh Merkle hợp lệ
Ngoài ZK-SNARK, giao thức cũng 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 các giao dịch được gửi đ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 token 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ã 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 mã thông báo 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à nhiều mệnh giá tiền xu khác nhau, bao gồm cả các cặp tiền."sự phân đoạn"Và"hợp nhất"Hỗ trợ hoạt động. 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 quyền 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 đó hoặc một bộ sưu tập chỉ chứa khoản 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á, và 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 bộ ID coin tổng
●Vào nhánh Merkle của tập hợp gốc RA đượ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. Các trường hợp sử dụng cho tập hợp kết hợp
Để 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 thông qua thông tin những đồng tiền từ đị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 trong các giao thức DeFi sẽ được truy tìm và gắn thẻ, từ đó 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 không cung cấp bất kỳ thông tin nào, nhưng thông qua một quá 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 thành viên):Xác định một nhóm tiền gửi cụ thể mà chúng ta 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 tập hợp tiền gửi cụ thể mà chúng ta có bằng chứng thuyết phục để coi là 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ọ. ngược lại,Người dùng sẽ đăng ký với 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 cung cấp 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ộ tập hợp các hiệp hội rất quan trọng vì điều này 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í cả 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 khoảng 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 như trộm cắp hàng loạt hoặc một địa chỉ trong danh sách trừng phạt do chính phủ công bố, tiền gửi 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 người độc thân:Để tham gia nhóm liên kết, 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 cần biết rằng họ nắm giữ một số mã thông báo nhận dạng (chẳng hạn như hệ thống ID quốc gia được chính phủ hỗ trợ hoặc cơ chế nhẹ, chẳng hạn 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.
● Các thành viên cộng đồng đáng tin cậy được thanh toán hàng tháng:Tương tự như phí hàng tháng dành cho một người, 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 trí tuệ nhân tạo: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 đưa ra một tập hợp tiền gửi liên quan 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 zeroizer cho mỗi đầu vào) và nhiều đầu ra (cần xuất bản ID mã thông báo của mỗi đầu ra). Mỗi ID mã thông báo được tạo phải đi kèm với giá trị mệnh giá mật 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ó không thay đổi vào nhóm quyền riêng tư 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 đều có nguồn gửi 10 xu ban đầu, 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 liên quan
Điều gì sẽ xảy ra nếu chúng ta 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 giao dịch tương ứng được xác định duy nhất?"tiền gửi ban đầu", có một số cách để thực hiện việc 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 tiền xu và yêu cầu các giao dịch có nhiều đầu vào cam kết liên kết các giao dịch gốc của 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. Hoàn cảnh đặc biệt
● Chứng minh lại:Người dùng cần thông tin tiền gửi bí mật để rút tiền gửi trong các giao thức như nhóm quyền 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.
● Chứng nhận 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 một bên khác. 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 giống như nhóm quyền riêng tư, giao thức sẽ 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 về 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ê và anh ấy nhận được 5 token từ Alice, 4 token từ Ashley, 7 token từ Anne và vào cuối ngày anh ấy cần phải trả cho Carl 15 token để trả tiền cho bữa tối. Thay vào đó, David có thể đã nhận được 15 xu từ Carl, 25 xu từ Chris và muốn gửi 30 xu cho Emma (một cuộc trao đổi). 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 sự riêng tư
● Mong muốn tránh khơi dậy sự nghi ngờ
1. Sự đồng thuận xã hội và các hiệp hội
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ả khu vực pháp lý A và B có thể sử dụng cùng một thỏa thuận nâng cao 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 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:
● Một tập đoàn các ngân hàng thương mại có thể tạo ra một bộ sưu tập liên quan chỉ chứa tiền gửi của khách hàng.Điều này đảm bảo rằng bất kỳ khoản rút tiền nào được thực hiện đối với nhóm này đều chứng minh rằng các thủ tục nhận biết khách hàng (KYC) và chống rửa tiền (AML) đã được thực hiện 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 nguồn tiền rõ ràng, 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 số 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 thiết kế và giải pháp thay thế
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:
● Truy cập tập trung:Các cơ quan thực thi pháp luật, nhà cung cấp đ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 người khác.
● Danh sách trắng toàn hệ thống:Hệ thống bảo mậ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 tiền gửi phải tuân theo một khoảng thời gian chờ đợi, trong đó hệ thống tính điểm rủi ro tập trung 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 môi trường được quản lý, nhưng có một số khía cạnh đáng đượ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ý.
