Tiêu đề gốc: "Quyền riêng tư của Blockchain ;Matthias  ; Nadler, Fabian Schar và Ameen Soleimani và những người khác đã cùng viết một bài nghiên cứu về các giao thức bảo mật, có tiêu đề" Quyền riêng tư của Blockchain và tuân thủ quy định: 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 mô tả một giao thức mới nâng cao quyền riêng tư dựa trên hợp đồng thông minh - nhóm quyền riêng tư, thảo luận về ưu điểm và nhược điểm của nó, đồng thời cho thấy cách nó cân bằng giữa người dùng trung thực và người dùng không trung thực . Người dùng trung thực. Giao thức được thiết kế để sử dụng bằng chứng không có kiến thức nhằm 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 bằng 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.

1. 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 các 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 nhiều ứng dụng, 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 hiện 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 khách khác hoặc xem doanh thu 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 mờ nhạt giữa người dùng hợp pháp và người dùng tội phạm. 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 quyền riêng tư đề xuất 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 việc rút tiền 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 việc rút tiền 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.  

II. 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ấ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 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 tin rằng mặc dù tất cả các giao dịch đều được thực hiện minh bạch, blockchain 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 đó, các công nghệ chứng minh không có kiến thức nói chung xuất hiện, 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 ngang bằng với tất cả các giao dịch trước đó. Toàn bộ bộ sưu tập các giao dịch. Kỹ thuật này thường được gọi là ZK-SNARK.

2. ZK-SNARKs

ZK-SNARKs  một người chứng minh để chứng minh một khẳng định toán học nhất định về dữ liệu công cộng 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ư đó tuân thủ các tuyên bố.

● Tính đơn giản: Bằng chứng ngắn gọn và có thể được xác minh nhanh chóng, ngay cả khi tuyên bố được chứng minh đòi hỏi 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 trong 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ác yêu cầu chứng minh ZK-SNARKs Có thể được xem như một loại chương trình được gọi là mạch tính toán hàm f( x, w), sau đó chứng minh rằng đối 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 tư w sao cho kết quả của f(x, w) là True.

3. Ứng dụng ZK-SNARK in Zcash và Tornado hệ thống tiền mặt

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 nắm giữ. Hai giá trị có thể được bắt nguồn từ s :

● Mã thông báo công khai ID L  ;=  hàm băm(s + 1)

● Bộ vô hiệu hóaU =  ;hash(s + 2 ) 

Trong số đó, hàm băm (hash) đề cập đến hàm băm mật khẩu, chẳng hạn như SHA 256  ;. Cho trước, 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à một mã thông báo ID 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 phương thức đã tạo ra cả hai Bí mật .

Blockchain theo dõi tất cả các ID token đã đượ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 mã thông báo ID  được lưu trữ trong cấu trúc dữ liệu được gọi là a Merkle cây: nếu cây chứa N items , thì mỗi mục liền kề được băm (dẫn đến hàm băm ⌈ N/2 ⌉) và mỗi mục liền kề được băm lại (dẫn đến hàm băm ⌈ N/4 ⌉), v.v., cho đến khi toàn bộ dữ liệu được băm được cam kết thành một hàm 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 một nhánh Merkle  các giá trị được băm cùng nhau ở mỗi bướ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)) 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ọ cung cấp những thông tin sau:

● Zerozer mà bạn muốn chi tiêu U

● Muốn tạo Token ID L』 của mã thông báo mới (người nhận được yêu cầu cung cấp mã thông báo này)

● A ZK-SNARK.  

ZK-SNARK Chứa các đầu vào riêng tư sau:

●  Bí mật s

● Merkle nhánh trong cây thông báo ID cây, chứng minh rằng mã thông báo ID là L  ;= hash (s + 1) Mã thông báo thực sự đã được tạo vào một thời điểm nào đó trong quá khứ 

Nó cũng chứa Đầu vào công khai sau:

● U, số 0 của mã thông báo đang được sử dụng

● R, hàm băm gốc Bằng chứng Merkle đang nhắm mục tiêu 

ZK-SNARK chứng minh hai thuộc tính:

●  ;U = hash(s + 2)

● Nhánh Merkle là hợp lệ 

Ngoài ZK-SNARK , giao thức còn kiểm tra những điều sau:

● R là hiện tại hay hàm băm gốc lịch sử của mã thông báo ID cây

● U không còn được sử dụng trong bộ zeroizer 

Nếu giao dịch hợp lệ, nó sẽ Thêm  U  vào bộ zeroizer đã chi và  L』 vào danh sách mã thông báo ID  Hiển thị U ngăn không cho một mã thông báo bị chi tiêu hai lần. 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; họ không thể biết được ai gửi hoặc nhận các giao dịch này và không thể phân biệt nguồn gốc thống nhất của các mã thông báo.

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, mã thông báo ID có thể được tạo mà không làm mất hiệu lực mã thông báo trước đó. Tiền gửi không ẩn danh từ góc độ quyền riêng tư, vì sự liên kết giữa L  nhất định và một sự kiện bên ngoài cho phép bổ sung L  ETH được gửi vào hệ thống trong Zcash, ZEC mới được khai thác).

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à tiền xu có mệnh giá khác nhau, bao gồm hỗ trợ cho các hoạt động phân 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 quyền riêng tư

Nhóm quyền riêng tư Ý tưởng cốt lõi 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 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ị 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 đồng xu ID làm nút lá, chứng minh hai Merkle  thông qua không có kiến thức:

● Enter tổng số xu  ;ID  Merkle nhánh của gốc R của bộ sưu tập

● Nhập Merkle nhánh của bộ sưu tập gốc  được liên kết được cung cấp; RA 

Mục đích là đặt toàn bộ các liên kết ở đâu đó (có thể là cấp trên của 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 ở một thái cực khác, không cung cấp bất kỳ thông tin nào khác ngoài việc chứng minh không có 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 từ đó tiền có thể đã đế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 hơn trong việc 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ọ. 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 áp dụng các giao thức tăng cường quyền riêng tư thực hành từ góc độ ứng dụng được sử dụng trong.

1.  Các trường hợp sử dụng cho các bộ sưu tập liên quan 

Để minh họa trong việc thực thi pháp luật môi trường Giá trị của giải pháp này, 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 và 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 là kẻ trộm qua thông tin những đồng xu ở địa chỉ có ghi “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 khi các lỗ hổng trong giao thức DeFi bị khai thác 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 rút tiền, họ có thể chọn bộ liên kết nào để chỉ định. Nhóm liên kết của họ phải bao gồm tiền gửi của chính 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 hợ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 nhóm người tham gia liên quan được hiển thị trong hình bên dưới.  

Mặc dù Eve Tôi không 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 tôi 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 giải thích Cái duy nhất có thể cách sử dụng các bộ sưu tập 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 người xấu. Lưu ý rằng hệ thống này không dựa 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 các bộ sưu tập liên quan một cách chi tiết hơn. Thông thường, có hai chiến lược chính để tạo tập hợp liên kết. Chúng được mô tả bên dưới và hiển thị trong hình ả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 chắc chắn để coi là có rủi ro thấp và xây dựng một bộ sưu tập liên quan chỉ chứa những 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 thuyết phục rằng chúng có rủi ro cao và xây dựng một Một bộ sưu tập liên quan chứa tất cả các khoản tiền gửi ngoại trừ các khoản tiền gửi này.

Trong thực tế, người dùng không chọn thủ công các mục để đưa vào bộ sưu tập liên quan của họ gửi tiền vào. Thay vào đó,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 các 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, 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 bộ sưu tập được liên kết một cách độc lập và xuất bản bộ sưu tập được 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 Merkle gốc của bộ sưu tập được liên kết trên chuỗi; điều này giúp loại bỏ 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. khả năng tấn công (ví dụ: cung cấp cho những người dùng khác nhau các nhóm liên kết khác nhau nhằm cố gắng loại bỏ tính ẩn danh của chúng). 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ộ 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 về tư cách thành viên cục bộ mà không tiết lộ bất cứ điều gì cho ASP  yêu cầu 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 xây dựng trong thực tế:

●  Việc 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 kết với các tác nhân xấu đã biết (ví dụ:  7  ;ngày) Trộm cắp quy mô lớn hoặc một địa chỉ nằm trong danh sách trừng phạt do chính phủ công bố), tiền đặt cọc 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 một bộ sưu tập liên quan, giá trị của khoản tiền gửi phải dưới mức cố định tối đa 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 (chẳng hạn như hệ thống ID quốc gia được chính phủ hỗ trợ hoặc một 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 chống rửa tiền phổ biến, theo đó các khoản thanh toán nhỏ dưới một ngưỡng nhất định sẽ mang lại 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, nhưng hạn chế hơn: Người dùng phải Chứng minh bản thân với tư cách 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 cho nhau quyền riêng tư.

● 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  trong thời gian thực và Hệ thống đưa ra một bộ sưu tậ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 sâu hơn

Trong phần này, chúng tôi sẽ phân tích đề xuất Cách thực hiện hỗ trợ các mệnh giá tùy ý và thảo luận các trường hợp đặc biệt như chứng nhận lại, chứng nhận trực tiếp song phương và chứng nhận tuần tự.

1. Hỗ trợ bất kỳ mệnh giá nào

Hệ thống tiền xu bảo vệ quyền riêng tư đơn giản hóa ở trên chỉ hỗ trợ tương tự chuyển tiền mệnh giá. Zcash hỗ trợ mọi mệnh giá 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ố 0 của 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 mã thông báo ID đượ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.

Có thể đạt được thiết kế này bằng cách coi tiền gửi là đầu vào (không được mã hóa) và tiền rút là (không được mã hóa) đầu ra theo quy mô để hỗ trợ tiền gửi và rút tiền. 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ụ: có thể chỉ cho phép rút tiền 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 bảo mậ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  trong bốn lần rút tiền liên tiếp + 2 + 3  ;+ 4 token, chúng tôi muốn coi bốn lần rút tiền này là nguồn gửi tiền 10 token ban đầu. Nhưng kết quả thực tế như hình bên dưới: Nguồn của lần rút đầu tiên là nguồn gửi  10 token, sau đó nguồn của lần rút thứ hai là nguồn 9 token được tạo bởi lần rút tiền đầu tiên. Thay đổi đầu ra, 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ó.

Để có thể chuyển đổi bản gốc của 10 tiền gửi với tư cách là nguồn của chúng, chúng tôi 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 sẽ 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 một phần bao gồm khoản tiền gửi như một thành viên của tập hợp được liên kết của nó

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 ban đầu tương ứng được xác định duy nhất, có nhiều cách để thực hiện phương pháp trực tiếp này. 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 phải chứa một cam kết hash(coinID+hash®), thêm một số giá trị ngẫu nhiên r để đảm bảo gây mù và yêu cầu ZK-SNARK chứng minh rằng cam kết trong giao dịch là giống nhau như giao dịch mẹ 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 đồng tiền gửi ban đầu và yêu cầu bằng chứng rằng giá trị 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ợ việc 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ả ID đồng xu đã cam kết của nó đều nằm trong tập hợp được liên kết của nó.

2. Các 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 để phù hợp với 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 chính xác của việc rút tiền cho bên kia buổi tiệ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 như nhóm quyền riêng tư, giao thức cần phải được được sửa đổi để phù hợp với loạ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 token có thể có nhiều "nguồn". Ví dụ: Bob  là chủ quán cà phê và anh ấy nhận được 5 mã thông báo từ Alice , 4 mã thông báo từ Ashley  và Anne  anh ấy cần phải trảCarl15 xu cho bữa tối. Thay vào đó, David có thể đã nhận được 15 token từ Carl và 25 token từ Chris và muốn gửi tiền bằng Emma (một sàn giao dịch) Gửi 30 token. 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ông tin chi tiết

Một hệ thống tương tự như nhóm quyền riêng tư có thể cho phép người dùng duy trì bằng chứng và hành vi bất hợp pháp đã biết Khả năng tách biệt các hoạt động đồng thời đượ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ọ. Chúng tôi hy vọng rằng những người dùng trung thực sẽ có động lực tham gia vào chương trình như vậy nhờ sự kết hợp của hai yếu tố:

● Mong muốn về quyền riêng tư

● Mong muốn về quyền riêng tư

● Mong muốn tránh gây ra sự nghi ngờ

1. Sự đồng thuận và liên kết xã hội 

Nếu có sự đồng thuận hoàn toàn về việc quỹ tốt hay xấu, hệ thống sẽ tạo ra một trạng thái cân bằng tách biệt đơn giản. Tất cả người dùng có nội dung “tốt” đều có động cơ khuyến khích 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à kết luận về việc nguồn tài trợ được coi là "tốt" hay "xấu" tùy thuộc vào quan điểm xã hội hoặc quyền tài phán, các khoản thu của hiệp hội có thể thay đổi đá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 nhóm 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ý.

Do đó, đề xuất này rất linh hoạt và nên được coi là trung lập về cơ sở hạ tầng. 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 kết 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 chứng nhận cho 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 được liên kết 

Các bộ sưu tập được liên kết cần có một số thuộc tính nhất định để chơi vai trò. 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 từng 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. Những cân nhắc thực tế và sự cạnh tranh 

Các tổ chức được quản lý chấp nhận tài sản tiền điện tử phải đảm bảo rằng chúng là đối tượng Luật pháp và các quy định 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. Xếp hạng 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 họ. Các giao thức tăng cường quyền riêng tư có thể đặt ra những thách thức trong vấn đề này. Chúng loại bỏ mối liên hệ rõ ràng giữa tiền gửi và tiền rút. Do đó, với sự hiện diện của các giao thức tăng cường quyền riêng tư, điểm rủi ro cần phải tính đến chứng thực và ấn định điểm dựa trên tập hợp các liên kết.

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 bớt các nhà cung cấp công cụ sàng lọc khỏi các rủi ro gần như độc quyền có thể phát sinh từ sở hữu kiến thức chưa được chứng minh công khai.

Cài đặt chung của nhóm quyền 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 nhờ thu 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 một nhờ thu liên kết chỉ chứa tiền gửi của khách hàng của họ

mạnh>. Đ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 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 chống lại một tập hợp liên quan rằng 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. Các lựa chọn và phương án thiết kế

Cài đặt rất linh hoạt dựa trên bộ sưu tập liên kết, chứng chỉ zk và tiết lộ tự nguyện. Mặc dù điều này 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 họ có vấn đề với các yêu cầu về lòng 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ơ quan thực thi pháp luật, nhà cung cấp điểm rủi ro mã hóa hoặc Tương tự người tham gia 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 ở chế độ 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 bảo mật có thể đặt ra các hạn chế đối với những 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 khoản tiền gửi phải chờ trong một khoảng thời gian mà hệ thống tính điểm rủi ro tập trung có thể từ chối khoản tiền gửi.

Hai phương pháp này giống nhau ở chỗ chúng cấp đặ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ự, 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  100% đáng tin cậy, 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 nó lạm dụng quyền lực của mình, tình trạng này là triệu chứng của một trạng thái không hoạt động . Theo thời gian, 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. Có thể có những áp lực 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.

Ngoài ra, 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 một 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 bằng chứng 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. Định hướng nghiên cứu chuyên sâu

Mặc dù nghiên cứu này cung cấp những hiểu biết sâu sắc về cách thực hiện Tổng quan về môi trường sử dụng các giao thức nâng cao quyền riêng tư dựa trên zkSNARK, nhưng có một số khía cạnh đáng được nghiên cứu thêm.

Trước hết, 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, 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 bằng cách thêm các khoản tiền gửi đã biết với rút tiền tương ứng để tăng tính ẩn danh nhận thức. 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 sâu hơn về 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à sự tuân thủ được coi là mâu thuẫn 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.

Việc thiết lập như vậy có thể tạo ra một trạng thái cân bằng riêng biệt trong đó những 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 nhóm liên kết tuân thủ nào đó 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, 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 cho phù hợp với các yêu cầu pháp lý khác nhau.

Bài viết này nên được xem như một đóng góp cho khả năng cùng tồn tại trong tương lai của quyền riêng tư và quy định tài chính. Chúng tôi hy vọng sẽ kích thích 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ý.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia