Gần đây tôi đã từ từ đọc lại các whitepaper blockchain cũ hơn, chủ yếu vì tò mò về cách các dự án khác nhau thực sự xử lý quy định thay vì chỉ né tránh nó. Dusk Network là dự án khiến tôi phải dừng lại.
Điểm gây chú ý không phải là mật mã học — đến nay khá tiêu chuẩn trong lĩnh vực này — mà là một mô hình giao dịch có tên Zedger, được xây dựng riêng xoay quanh luật chứng khoán. Nó yêu cầu các bên tham gia nằm trong danh sách cho phép (whitelist), buộc người nhận phải phê duyệt rõ ràng các giao dịch chuyển đến, và cho phép một người vận hành được chỉ định có thể tái dựng đầy đủ hồ sơ sở hữu tại bất kỳ thời điểm nào. Phần đó về cơ bản là một yêu cầu kiểm toán, được viết trực tiếp vào trong giao thức. Đây là một trong rất ít lần tôi thấy một thiết kế whitepaper tập trung vào tuân thủ hơn là coi nó như một thứ chỉ cần lách đi sau này.
Tuy vậy, tôi không nghĩ một bản đặc tả viết tốt có thể tự “giải quyết” mọi thứ. Một whitelist chỉ đáng tin đến mức người vận hành nó, và một smart contract có thể thực thi một quy tắc, nhưng không thể quyết định ai mới là người thực sự tuân thủ theo luật. Phần quyết định đó vẫn thuộc về một cá nhân hoặc tổ chức. Whitepaper cũng thường được viết từ nhiều năm trước khi bất cứ điều gì thật sự được dùng, và khoảng cách giữa một thiết kế tốt với một hệ thống vận hành, được quản lý theo quy định, thường lớn hơn những gì nhìn trên giấy.
Tất cả những điều đó không làm ý tưởng kém thú vị, chỉ khiến nó “chưa hoàn thiện” hơn những gì cách đọc gợi ra. Nó là một lời nhắc tốt để đọc chậm lại, tự hỏi: thứ gì thực sự được thực thi, thứ gì chỉ được thiết kế, và đừng tin lời của bất kỳ hệ thống nào. Những thói quen nhỏ như vậy cộng dồn lại — tôi hiểu thêm một chút với mỗi thứ tôi ngồi xuống và thực sự đọc.
@Dusk_Foundation #dusk $DUSK
Điểm gây chú ý không phải là mật mã học — đến nay khá tiêu chuẩn trong lĩnh vực này — mà là một mô hình giao dịch có tên Zedger, được xây dựng riêng xoay quanh luật chứng khoán. Nó yêu cầu các bên tham gia nằm trong danh sách cho phép (whitelist), buộc người nhận phải phê duyệt rõ ràng các giao dịch chuyển đến, và cho phép một người vận hành được chỉ định có thể tái dựng đầy đủ hồ sơ sở hữu tại bất kỳ thời điểm nào. Phần đó về cơ bản là một yêu cầu kiểm toán, được viết trực tiếp vào trong giao thức. Đây là một trong rất ít lần tôi thấy một thiết kế whitepaper tập trung vào tuân thủ hơn là coi nó như một thứ chỉ cần lách đi sau này.
Tuy vậy, tôi không nghĩ một bản đặc tả viết tốt có thể tự “giải quyết” mọi thứ. Một whitelist chỉ đáng tin đến mức người vận hành nó, và một smart contract có thể thực thi một quy tắc, nhưng không thể quyết định ai mới là người thực sự tuân thủ theo luật. Phần quyết định đó vẫn thuộc về một cá nhân hoặc tổ chức. Whitepaper cũng thường được viết từ nhiều năm trước khi bất cứ điều gì thật sự được dùng, và khoảng cách giữa một thiết kế tốt với một hệ thống vận hành, được quản lý theo quy định, thường lớn hơn những gì nhìn trên giấy.
Tất cả những điều đó không làm ý tưởng kém thú vị, chỉ khiến nó “chưa hoàn thiện” hơn những gì cách đọc gợi ra. Nó là một lời nhắc tốt để đọc chậm lại, tự hỏi: thứ gì thực sự được thực thi, thứ gì chỉ được thiết kế, và đừng tin lời của bất kỳ hệ thống nào. Những thói quen nhỏ như vậy cộng dồn lại — tôi hiểu thêm một chút với mỗi thứ tôi ngồi xuống và thực sự đọc.
@Dusk_Foundation #dusk $DUSK