@Dusk #dusk
$DUSK Các thành phần cốt lõi
Mạng Dusk sử dụng kiến trúc mô-đun được thiết kế cho tài chính được quản lý: quyền riêng tư khi cần thiết, tính minh bạch khi hữu ích và quyết toán tất định khi quy trình thị trường yêu cầu. Ở mức tổng quan:
Thành phần :
1. DuskDS
Vai trò :
Nền tảng quyết toán và sẵn sàng dữ liệu: đồng thuận, tính cuối cùng và các mô hình giao dịch của Dusk
Đi đâu tiếp theo :
Dusk có kiến trúc hai lớp:
DuskDS – lớp quyết toán và dữ liệu (đồng thuận, tính sẵn sàng dữ liệu, mô hình giao dịch)
DuskEVM – lớp thực thi EVM nơi hợp đồng thông minh chạy và nơi Hedger sinh sống
Trang này mô tả các mô hình giao dịch trên DuskDS. Đây là phần nền tảng cho những ai muốn hiểu cách quyết toán và quyền riêng tư hoạt động “bên dưới lớp vỏ”. Nếu bạn đang xây dựng dApp trên DuskEVM, bạn chủ yếu sẽ tương tác với Hedger và các hợp đồng EVM thay vì lớp DuskDS.
Phoenix vs Moonlight (trên DuskDS)Trên DuskDS, giá trị có thể di chuyển theo hai cách gốc:
Moonlight – chuyển khoản công khai, dựa trên tài khoản
Phoenix – chuyển khoản được che chắn, dựa trên “note” (bút toán) sử dụng bằng chứng zero-knowledge
Cuối cùng cả hai đều được quyết toán trên cùng một chuỗi, nhưng chúng cung cấp thông tin khác nhau cho người quan sát.
Để xem chi tiết triển khai đầy đủ, bạn có thể tham khảo Whitepaper.
Moonlight – số dư công khai
Moonlight là mô hình giao dịch minh bạch:
Các tài khoản có số dư hiển thị.
Các giao dịch thể hiện người gửi, người nhận và số lượng.
Phù hợp với các luồng cần được quan sát (ví dụ: một số kịch bản liên quan đến ngân khố hoặc báo cáo).
Về mặt khái niệm, nó hoạt động giống mô hình tài khoản tiêu chuẩn.
Đối với đa số người dùng, đây “chỉ là cách minh bạch để chuyển DUSK” ở lớp giao thức.
Phoenix – số dư được che chắn
Phoenix là mô hình bảo vệ quyền riêng tư:
Quỹ được lưu dưới dạng các “note” được mã hóa thay vì các số dư rõ ràng.
Các giao dịch chứng minh tính đúng đắn (không chi tiêu gấp, đủ số dư) bằng bằng chứng zero-knowledge mà không tiết lộ: số lượng đang được chuyển, ai gửi note đó (trừ người nhận), giữa những note cụ thể nào.
Người dùng có thể chọn lọc công bố thông tin thông qua các viewing keys khi quy định hoặc hoạt động kiểm toán yêu cầu.
$DUSK Các thành phần cốt lõi
Mạng Dusk sử dụng kiến trúc mô-đun được thiết kế cho tài chính được quản lý: quyền riêng tư khi cần thiết, tính minh bạch khi hữu ích và quyết toán tất định khi quy trình thị trường yêu cầu. Ở mức tổng quan:
Thành phần :
1. DuskDS
Vai trò :
Nền tảng quyết toán và sẵn sàng dữ liệu: đồng thuận, tính cuối cùng và các mô hình giao dịch của Dusk
Đi đâu tiếp theo :
Dusk có kiến trúc hai lớp:
DuskDS – lớp quyết toán và dữ liệu (đồng thuận, tính sẵn sàng dữ liệu, mô hình giao dịch)
DuskEVM – lớp thực thi EVM nơi hợp đồng thông minh chạy và nơi Hedger sinh sống
Trang này mô tả các mô hình giao dịch trên DuskDS. Đây là phần nền tảng cho những ai muốn hiểu cách quyết toán và quyền riêng tư hoạt động “bên dưới lớp vỏ”. Nếu bạn đang xây dựng dApp trên DuskEVM, bạn chủ yếu sẽ tương tác với Hedger và các hợp đồng EVM thay vì lớp DuskDS.
Phoenix vs Moonlight (trên DuskDS)Trên DuskDS, giá trị có thể di chuyển theo hai cách gốc:
Moonlight – chuyển khoản công khai, dựa trên tài khoản
Phoenix – chuyển khoản được che chắn, dựa trên “note” (bút toán) sử dụng bằng chứng zero-knowledge
Cuối cùng cả hai đều được quyết toán trên cùng một chuỗi, nhưng chúng cung cấp thông tin khác nhau cho người quan sát.
Để xem chi tiết triển khai đầy đủ, bạn có thể tham khảo Whitepaper.
Moonlight – số dư công khai
Moonlight là mô hình giao dịch minh bạch:
Các tài khoản có số dư hiển thị.
Các giao dịch thể hiện người gửi, người nhận và số lượng.
Phù hợp với các luồng cần được quan sát (ví dụ: một số kịch bản liên quan đến ngân khố hoặc báo cáo).
Về mặt khái niệm, nó hoạt động giống mô hình tài khoản tiêu chuẩn.
Đối với đa số người dùng, đây “chỉ là cách minh bạch để chuyển DUSK” ở lớp giao thức.
Phoenix – số dư được che chắn
Phoenix là mô hình bảo vệ quyền riêng tư:
Quỹ được lưu dưới dạng các “note” được mã hóa thay vì các số dư rõ ràng.
Các giao dịch chứng minh tính đúng đắn (không chi tiêu gấp, đủ số dư) bằng bằng chứng zero-knowledge mà không tiết lộ: số lượng đang được chuyển, ai gửi note đó (trừ người nhận), giữa những note cụ thể nào.
Người dùng có thể chọn lọc công bố thông tin thông qua các viewing keys khi quy định hoặc hoạt động kiểm toán yêu cầu.
