Giải thích shielded pool, Unified Address và viewing key của Zcash

Trong Zcash, pool không phải sàn hay công ty giữ tiền gửi mà là trạng thái giá trị tuân theo các quy tắc đồng thuận riêng. Pool minh bạch dùng UTXO công khai. Người đọc chuỗi có thể xem output nào được tạo, giao dịch nào về sau đã tiêu output đó và số tiền hiển thị. Địa chỉ không tự tiết lộ danh tính pháp lý, nhưng lịch sử công khai vẫn cho thấy việc sử dụng địa chỉ và liên kết dòng tiền.

Shielded pool biểu diễn giá trị bằng note thay vì UTXO công khai. Mạng ghi dữ liệu note đã mã hóa, cây commitment và kiểm tra số dư pool. Bằng chứng cho phép đồng thuận xác minh tính hợp lệ, bảo toàn giá trị và ngăn chi tiêu hai lần mà không cho người quan sát thông thường đọc người nhận và số tiền như với output minh bạch. Tài liệu đặc tả giao thức Zcash mô tả cả hai cách biểu diễn.

Sapling và Orchard là các shielded pool riêng biệt, có giao thức và cây commitment khác nhau; số dư của chúng không phải một trạng thái có thể hoán đổi. Sprout là giao thức shielded đầu tiên của Zcash. Kể từ khi ZIP 211 được kích hoạt, không thể thêm giá trị mới vào pool Sprout, dù các giao dịch Sprout cũ vẫn còn trong lịch sử chuỗi.

Trạng thái mạng cần ghi rõ thời điểm. Chỉ mục ZIP chính thức cho biết NU6.2 là nâng cấp Mainnet mới nhất đã hoàn tất, kích hoạt ở block 3.364.600 vào ngày 3 tháng 6 năm 2026. NU6.2 bật lại các hành động Orchard sau biện pháp giảm thiểu lỗ hổng tạm thời và dùng quy tắc circuit đã sửa. NU6.3 và pool Ironwood vẫn là đề xuất dạng bản nháp, không phải quy tắc Mainnet hiện hành. Xem ZIP 257, chỉ mục ZIP và bản nháp ZIP 258.

Một shielded note gắn giá trị trong một pool với quyền chi tiêu của người nhận. Giá trị, chi tiết người nhận và memo được mã hóa để ví có thông tin nhận tương ứng có thể giải mã. Chuỗi lưu dữ liệu đã mã hóa và commitment của note, không lưu nội dung rõ. Commitment giúp xác minh mà không công khai nội dung note.

Khi note được chi tiêu, giao dịch tiết lộ nullifier tương ứng. Người chi tiêu chứng minh mình biết note và công bố nullifier; mạng kiểm tra nullifier đó chưa từng được dùng. Người quan sát thấy nullifier và cây commitment nhưng không thể xác định nullifier ứng với commitment cũ nào. Cơ chế này ngăn chi tiêu hai lần mà không làm mọi dữ liệu đồng thuận trở nên bí mật. Sapling và Orchard cùng theo thiết kế tổng quát đó nhưng dùng thành phần mật mã và bằng chứng khác nhau; chi tiêu vẫn cần quyền riêng tư tương ứng.

Unified Address (UA) là một chuỗi được mã hóa có thể chứa receiver Orchard, Sapling, P2SH minh bạch hoặc P2PKH minh bạch. UA Revision 0 đang hoạt động phải có ít nhất một receiver shielded. Chuỗi được thiết kế để không thể nhìn bằng mắt mà biết bên trong có receiver nào. ZIP 316 phân biệt Revision 0 với Revision 2 được đề xuất.

Ví gửi không thanh toán đến tất cả receiver. Trong Revision 0, thứ tự ưu tiên là Orchard, Sapling, P2SH minh bạch rồi P2PKH minh bạch; bên gửi phải dùng receiver có ưu tiên cao nhất mà ví hỗ trợ. Nếu ví hỗ trợ Orchard thì chọn Orchard; nếu không hỗ trợ Orchard nhưng hỗ trợ Sapling thì có thể chọn Sapling. Vì vậy pool thực tế phụ thuộc vào khả năng của ví gửi, không chỉ vào chuỗi địa chỉ được hiển thị.

Bản nháp Revision 2 đề xuất tiền tố zu cho địa chỉ chỉ shielded và tu cho định dạng có thể chứa receiver minh bạch. Chỉ mục ZIP chính thức vẫn đánh dấu đây là bản nháp; đừng xem chúng là định dạng UA Mainnet thông thường hiện tại. Trước khi gửi, hãy kiểm tra trong ví loại địa chỉ, mạng đang chọn và receiver thực sự được dùng.

Chuyển từ minh bạch sang shielded (t→z) có thể tiêu UTXO công khai và tạo note Sapling hoặc Orchard. Người quan sát thấy input minh bạch, thay đổi trong pool minh bạch và giá trị ròng đi vào shielded pool. Tuy nhiên, họ không đọc được địa chỉ nhận shielded thông thường hay từng số tiền note như với UTXO minh bạch. Việc đưa giá trị vào pool vẫn để lại thông tin ở ranh giới.

Ở chiều ngược lại (z→t), địa chỉ và số tiền của output minh bạch là công khai, đồng thời thay đổi tương ứng của giá trị trong shielded pool có thể quan sát được. Khoản thanh toán tạo note bên trong cùng pool có thể che người nhận và số tiền, còn chuyển giữa Sapling và Orchard có thể khiến thay đổi số dư từng pool trở nên hữu ích để phân tích. Riêng giá trị ở ranh giới không xác định một người hay note cũ, nhưng có thể được đối chiếu với số tiền, thời điểm và hồ sơ bên ngoài.

Đừng chỉ hỏi địa chỉ có shielded không; hãy hỏi giá trị bắt đầu ở đâu và đi qua pool nào. Thời điểm hoặc số tiền đã biết của lần rút từ sàn, thanh toán tại cửa hàng hay giao dịch cá nhân có thể được so sánh với dữ liệu ranh giới công khai. Điều đó không tự động tiết lộ mọi chủ sở hữu hay đường đi nội bộ, nhưng có thể thu hẹp các khả năng.

ZIP 316 định nghĩa viewing key là thông tin cần để xem các khoản thanh toán đến địa chỉ. Full Viewing Key (FVK) còn có thể xem thông tin về khoản thanh toán đi từ địa chỉ đó. Có thể dẫn xuất Incoming Viewing Key (IVK) từ FVK và dẫn xuất địa chỉ từ IVK. Unified Viewing Key gộp các mục viewing key của nhiều giao thức.

Chỉ có viewing key thì không thể ký lệnh chi tiêu; cần spending key riêng hoặc hệ thống ký. Dù vậy, viewing key không phải dữ liệu công khai vô hại: loại key và cách triển khai của ví quyết định phạm vi giao dịch có thể xem. Key ở cấp tài khoản có thể tiết lộ nhiều hơn một địa chỉ nhận. Trước khi chia sẻ với kế toán hoặc dịch vụ, hãy kiểm tra phạm vi, thời hạn lưu, cách xóa và việc key có được kết hợp với địa chỉ khác hay không.

Viewing key không xóa những manh mối vốn đã công khai: input và output minh bạch, số tiền và thời điểm có thể được phân tích mà không cần key. Ngược lại, explorer hay ví thiếu hỗ trợ có thể không hiện một giao dịch shielded mà chuỗi vẫn ghi nhận. “Ứng dụng không hiển thị” không có nghĩa “giao dịch không có trên chuỗi”.

Mức độ hiển thị phụ thuộc pool và loại receiver. Luồng hoàn toàn minh bạch cho thấy địa chỉ, số tiền và liên kết UTXO. Thanh toán shielded mã hóa người nhận và giá trị note, nhưng commitment, nullifier, thời điểm và dữ liệu giao thức vẫn xuất hiện trên chuỗi. Ranh giới pool, các pool mà ví hỗ trợ, thời điểm thanh toán đã biết, hồ sơ sàn và viewing key được chia sẻ có thể tạo manh mối riêng.

Unified Address không buộc mọi khoản thanh toán phải dùng Orchard. Receiver được chọn có thể phụ thuộc phiên bản, thiết lập, cách triển khai và luồng giao dịch của ví. Đừng suy ra quyền riêng tư chỉ từ việc dán địa chỉ; hãy xem trước hoặc kiểm tra kết quả giao dịch. [Hướng dẫn quyền riêng tư Monero](/vi/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) trình bày thiết kế khác; [hướng dẫn tái sử dụng địa chỉ Bitcoin](/vi/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) so sánh với sổ cái minh bạch.

Quyền riêng tư mạng là lớp khác. Nhà cung cấp RPC, máy chủ light-wallet, sàn hoặc dịch vụ thanh toán có thể thấy yêu cầu tạo hay chuyển tiếp giao dịch và giữ IP, tài khoản hoặc thời điểm ở ngoài chuỗi. Bằng chứng mật mã không tự xóa nhật ký của dịch vụ. Thay vì tuyên bố một mức ẩn danh tuyệt đối, hãy xác định ai nhận metadata và họ lưu giữ dữ liệu ra sao.

Trước hết hãy xác nhận ví đang kết nối Mainnet hay Testnet đúng như dự định. Khi xem lại khoản thanh toán, xác nhận người nhận đưa Unified Address và kiểm tra receiver mà ví sẽ chọn. Chuỗi UA không cho thấy trực quan danh sách receiver, vì vậy hãy xem pool, số tiền, memo và phí trong ví. Nếu người nhận yêu cầu thanh toán shielded nhưng phần xem trước cho thấy output minh bạch, hãy kiểm tra hỗ trợ giao thức ở cả hai ví trước khi gửi.

Để tra giao dịch đã có, hãy đối chiếu transaction ID và mạng, rồi xem input và output liên quan pool nào. Địa chỉ và số tiền minh bạch hiển thị trên explorer công khai; chi tiết note có thể không hiện ở công cụ thiếu hỗ trợ. Nếu cần viewing key để kiểm tra, hãy làm rõ lý do và phạm vi dữ liệu; đừng dán spending key hay viewing key vào trang lạ. Hướng dẫn ví custodial và non-custodial cũng giải thích trách nhiệm ký giao dịch.

Đừng kết luận “tôi dùng địa chỉ shielded nên khoản thanh toán hoàn toàn riêng tư” hay “explorer không hiện giá trị nên giao dịch chưa xảy ra”. Lịch sử ví, mạng, transaction ID, trạng thái chuỗi, số xác nhận và quyền xem là các dữ kiện khác nhau. Nếu người nhận cần xác nhận đã nhận tiền, hãy kiểm tra ví của họ có hỗ trợ và đã đồng bộ đúng pool hay chưa.

Giả sử Lee gửi 1,25 ZEC từ một UTXO minh bạch đến Unified Address Revision 0 có receiver Orchard, Sapling và minh bạch. Đây chỉ là số minh họa, không phải mức phí hay mặc định của ví. Nếu ví Lee hỗ trợ Orchard, quy tắc ưu tiên của ZIP 316 chọn receiver Orchard. Chuỗi công khai cho thấy input minh bạch và dữ liệu ranh giới, chẳng hạn giá trị ròng vào shielded pool, nhưng không hiển thị địa chỉ shielded và số tiền note của người nhận như các output công khai thông thường.

Nếu ví Lee không hỗ trợ Orchard nhưng có Sapling thì có thể chọn Sapling. Ví không hỗ trợ pool shielded nào có thể dùng receiver minh bạch nếu receiver và định dạng thanh toán đó sẵn có. UA Revision 0 phải chứa receiver shielded, nhưng người gửi chỉ chọn receiver mà ví hỗ trợ. Do đó cùng một UA có thể tạo ra pool và dữ liệu ranh giới công khai khác nhau tùy khả năng của ví.

Cuối cùng, nếu người nhận chia sẻ viewing key riêng với dịch vụ kế toán, dịch vụ đó có thể thấy hoạt động shielded trong phạm vi key. Việc ví báo nhận, explorer không hiển thị chi tiết note và chuỗi ghi giao dịch hợp lệ theo đồng thuận là ba sự thật khác nhau. Unified Address giúp tương thích giữa nhiều thế hệ giao thức, nhưng không đảm bảo riêng tư hoàn toàn và không thay thế việc chọn receiver, quản lý key hay bảo vệ metadata mạng.

• Specyfikacja protokołu Zcash v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Disabling New Value to the Sprout Pool
• ZIP 257: NU6.2 i tymczasowe zabezpieczenie Orchard
• ZIP 258: projekt wdrożenia NU6.3
• Chỉ mục ZIP chính thức: trạng thái Mainnet và các đề xuất