Mấy ngày nay tôi xem lại @Dusk , thứ khiến tôi quan tâm nhất không hẳn là hai chữ “riêng tư”, mà là cách nó xử lý những thứ dễ bị bỏ sót nhất trong một giao dịch: trạng thái.
Moonlight và Phoenix đã cho tôi một lối nhìn rất trực quan. Trước hết, cái đầu thể hiện số dư, bên gửi, bên nhận và số tiền trên tài khoản công khai; còn cái sau biến tài chính thành các note được mã hóa. Giao dịch không trải trực tiếp số tiền, bên gửi và các note cụ thể ra ngoài, mà dùng ZKP để chứng minh số tiền có đủ, có bị chi tiêu hai lần hay không, và khi cần kiểm toán vẫn có thể công bố qua viewing key. Hai mô hình nhìn thì khác rất nhiều, nhưng cuối cùng đều phải trả lời cùng một câu hỏi: sau khi giao dịch này hoàn tất, trạng thái trên chuỗi rốt cuộc phải thay đổi thành gì? Thứ tôi thực sự dừng lại để suy nghĩ chính là Transfer Contract—nó nhận các loại payload khác nhau, rồi chuyển cho logic xác thực tương ứng xử lý, cuối cùng đưa kết quả vào cùng một bộ trạng thái toàn cục. Bước này thực ra quyết định rằng giao dịch riêng tư sẽ không trở thành một sổ cái biệt lập khác.
Đi tiếp theo mạch trạng thái, DuskDS chịu trách nhiệm cho đồng thuận, tính cuối cùng, tính khả dụng của dữ liệu và thanh toán; DuskVM đảm nhiệm việc chạy các hợp đồng đã được biên dịch thành WASM, bám sát việc thực thi trên Dusk L1; còn DuskEVM lại cung cấp một đường dẫn thực thi khác theo kiểu EVM. Hedger chạy trên DuskEVM, dùng mã hóa đồng cấu (homomorphic encryption) và ZKP để hiện thực giao dịch bí mật. Ghép tất cả lại với nhau, điểm thật sự thú vị của Dusk không phải là “giấu giao dịch đi”, mà là khiến những giao dịch có mức độ hiển thị khác nhau vẫn có thể đi vào cùng một hệ thống cập nhật trạng thái và thanh toán.
$DUSK đảm nhận gas và staking, đưa chi phí thực thi và an ninh mạng vào cùng một lớp kinh tế. Với tôi, bước tiếp theo đáng được nhìn kỹ là: sau khi thiết kế này đi vào quy trình tài chính thực tế, liệu nó có thể đảm bảo những gì cần ẩn thì ẩn được, những gì cần xác minh thì xác minh được, và để trạng thái cuối cùng đủ chắc chắn, đủ sẵn dùng hay không.
#dusk $DUSK @Dusk
Moonlight và Phoenix đã cho tôi một lối nhìn rất trực quan. Trước hết, cái đầu thể hiện số dư, bên gửi, bên nhận và số tiền trên tài khoản công khai; còn cái sau biến tài chính thành các note được mã hóa. Giao dịch không trải trực tiếp số tiền, bên gửi và các note cụ thể ra ngoài, mà dùng ZKP để chứng minh số tiền có đủ, có bị chi tiêu hai lần hay không, và khi cần kiểm toán vẫn có thể công bố qua viewing key. Hai mô hình nhìn thì khác rất nhiều, nhưng cuối cùng đều phải trả lời cùng một câu hỏi: sau khi giao dịch này hoàn tất, trạng thái trên chuỗi rốt cuộc phải thay đổi thành gì? Thứ tôi thực sự dừng lại để suy nghĩ chính là Transfer Contract—nó nhận các loại payload khác nhau, rồi chuyển cho logic xác thực tương ứng xử lý, cuối cùng đưa kết quả vào cùng một bộ trạng thái toàn cục. Bước này thực ra quyết định rằng giao dịch riêng tư sẽ không trở thành một sổ cái biệt lập khác.
Đi tiếp theo mạch trạng thái, DuskDS chịu trách nhiệm cho đồng thuận, tính cuối cùng, tính khả dụng của dữ liệu và thanh toán; DuskVM đảm nhiệm việc chạy các hợp đồng đã được biên dịch thành WASM, bám sát việc thực thi trên Dusk L1; còn DuskEVM lại cung cấp một đường dẫn thực thi khác theo kiểu EVM. Hedger chạy trên DuskEVM, dùng mã hóa đồng cấu (homomorphic encryption) và ZKP để hiện thực giao dịch bí mật. Ghép tất cả lại với nhau, điểm thật sự thú vị của Dusk không phải là “giấu giao dịch đi”, mà là khiến những giao dịch có mức độ hiển thị khác nhau vẫn có thể đi vào cùng một hệ thống cập nhật trạng thái và thanh toán.
$DUSK đảm nhận gas và staking, đưa chi phí thực thi và an ninh mạng vào cùng một lớp kinh tế. Với tôi, bước tiếp theo đáng được nhìn kỹ là: sau khi thiết kế này đi vào quy trình tài chính thực tế, liệu nó có thể đảm bảo những gì cần ẩn thì ẩn được, những gì cần xác minh thì xác minh được, và để trạng thái cuối cùng đủ chắc chắn, đủ sẵn dùng hay không.
#dusk $DUSK @Dusk
