Trong khi chúng ta chờ đợi phán quyết trong phiên tòa Storm, thật tốt khi được nhắc nhở rằng các pool được bảo vệ chỉ là toán học, và không khó để hiểu. Bất kỳ ai cũng có thể triển khai một cái. Vì vậy, đây là một chuỗi với trực giác cơ bản về cách chúng hoạt động:

Mục tiêu là xây dựng một hệ thống mà tất cả thông tin trong mỗi giao dịch đều hoàn toàn riêng tư với người dùng. Chúng ta không nên mong đợi gì ít hơn từ các hệ thống giao dịch của mình. Đây là quyền con người cơ bản về sự riêng tư.

Vấn đề là, nếu tất cả thông tin đều riêng tư, thì blockchain làm thế nào để biết giao dịch là hợp lệ? Làm thế nào nó biết rằng người dùng thực sự có số tiền họ dự định gửi? Rằng họ không đang chi tiêu gấp đôi? Câu trả lời rõ ràng là: zk-proofs. Nhưng liệu có thật sự đơn giản như vậy không?

Giả sử bạn có một tài khoản với số dư là 10. Bạn muốn gửi 5 cho sự bảo vệ của Roman. Vì vậy, bạn tạo một zk-proof cho thấy bạn có 10, và giao dịch của bạn gửi 5. Nghe có vẻ đơn giản!

Nhưng chờ đã! Khi bạn đưa ra bằng chứng về việc có 10, bằng chứng đó liên quan đến một trạng thái trong quá khứ, trước khối mới nhất mà giao dịch của bạn được đưa vào. Có thể kể từ đó, bạn đã chi tiêu hết tất cả các đồng xu! Làm thế nào bạn có thể chứng minh rằng bạn vẫn còn 10, tại khối mới nhất?

Điều này thực sự khá phức tạp, và đó là lý do tại sao các pool được bảo vệ không thực sự hoạt động với các hệ thống dựa trên tài khoản - không có cách nào đơn giản và đáng tin cậy để chứng minh cho một blockchain, trong zk, trạng thái mới nhất theo thời gian thực. Giải pháp? Sử dụng UTXOs. "Unspent Tx Outputs" nổi tiếng từ Bitcoin.

Với UTXOs, bạn không có một tài khoản có thể cập nhật duy nhất, mà bạn có những "tờ giấy" riêng lẻ chỉ có thể được chi tiêu một lần, toàn bộ (như một đồng xu thật). Các hệ thống UTXO thường khá phiền phức để phát triển, nhưng thuộc tính "chi tiêu một lần" này làm cho chúng rất hữu ích cho các pool được bảo vệ.

Trong một hệ thống UTXO như Bitcoin, khi bạn muốn chi tiêu một UTXO, tất cả các nút đầy đủ có thể kiểm tra rằng UTXO đó tồn tại (nó đã được tạo ra trong quá khứ) và nó chưa được chi tiêu. Điều này rất đơn giản. Nhưng nếu tất cả dữ liệu trong UTXO được mã hóa, làm thế nào chúng ta có thể kiểm tra điều này?

Không chỉ dữ liệu được mã hóa, mà chúng tôi thậm chí không muốn tiết lộ *UTXO nào* đang được chi tiêu. Nếu chúng tôi làm vậy, thì bất kỳ ai gửi cho bạn UTXO sẽ biết khi nào bạn chi tiêu nó. Trong một thiết kế hồ bơi được bảo vệ lý tưởng, KHÔNG có thông tin nào bị rò rỉ bởi một giao dịch.

Mẹo cốt lõi của các pool được bảo vệ là giới thiệu một giá trị "nullifier" có thể được công khai tiết lộ nhưng được người chi tiêu tạo ra một cách độc nhất cho mỗi UTXO. Để chi tiêu UTXO, blockchain kiểm tra xem nullifier đó chưa tồn tại. Điều này đảm bảo rằng mỗi UTXO chỉ có thể được chi tiêu một lần.

Bây giờ chúng ta có thể quay lại với zk-proof của mình. Chúng ta chỉ cần chứng minh rằng UTXO mà chúng ta đang chi tiêu thực sự tồn tại trên chuỗi, và rằng nullifier mà chúng ta đã tiết lộ cho nó được suy ra đúng cách từ UTXO mà chúng ta đang chi tiêu. Chỉ vậy thôi!

Trên thực tế, điều này có nghĩa là các hệ thống hồ bơi được bảo vệ thường giữ hai cây Merkle khác nhau. Một cây chứa các băm của UTXOs (UTXOs thường được gọi là "ghi chú", và các băm của chúng được gọi là "cam kết ghi chú"), và cây kia chứa các nullifier. Cả hai cây đều chỉ được thêm vào!

Khi một ghi chú mới được tạo ra, băm của nó được lưu trữ trong cây Merkle của ghi chú. Ghi chú đó được mã hóa. Khi một người dùng sau đó muốn chi tiêu ghi chú đó, họ tính toán nullifier cho ghi chú, và họ tạo ra một zk-proof cho thấy ghi chú nằm trong cây Merkle và nullifier là chính xác.

Nullifier được công khai và chuỗi kiểm tra xem nó đã tồn tại trong Cây nullifier chưa. Sau đó, nó được lưu trữ ở đó, vì vậy ghi chú không thể được chi tiêu lại. Không ai thực sự có thể biết ghi chú nào đang được chi tiêu, vì ghi chú gốc vẫn được giữ nguyên trong Cây ghi chú!

Đó là thiết kế cơ bản của tất cả các pool được bảo vệ ngày nay, bao gồm @Zcash, @TornadoCash, @penumbrazone, @namada, và nhiều hơn nữa. Tất nhiên, còn rất nhiều điều khác liên quan đến thiết kế pool được bảo vệ. Hãy theo dõi các chủ đề tiếp theo, nơi chúng tôi sẽ đi sâu vào những cơ chế đó.

@AThryver @0xkaiserkarel Sự hiểu lầm phổ biến và có thể gây hiểu nhầm khi sử dụng thuật ngữ "zk" ở đây. Xem