Hầu hết các dự án trên thị trường đang đi theo lộ trình “phát token rồi bổ phiếu”: token được thổi lên trước, thanh khoản được đào lên trước, còn vấn đề tuân thủ thì sau đó tìm một công ty luật ra một văn bản ý kiến là coi như đã “xong chuyện”. Nói thẳng thì dưới con mắt giám sát của cơ quan quản lý, kiểu mô hình này có thể trụ được qua mấy chu kỳ bull market, tôi thật sự không dám chắc.
Cho đến khi tách riêng và mổ xẻ Zedger và tiêu chuẩn XSC của @Dusk , tôi mới nhận ra có một đội ngũ đã nghĩ thấu đáo vấn đề này. Họ mã hóa trực tiếp các logic tuân thủ như kiểm tra nhà đầu tư đủ điều kiện, hạn chế chuyển nhượng, cơ chế bỏ phiếu phân phối lợi nhuận… thành các quy tắc “cứng” ở tầng hợp đồng. Trước khi mỗi giao dịch được thanh toán, đầu tiên phải qua một vòng kiểm tra tuân thủ—đạt thì mới tạo ra chứng từ trên chuỗi để cho phép, không đạt thì bị chặn ngay tại chỗ. Không phải đợi giao dịch đã lên chuỗi rồi mới đi truy trách nhiệm, mà ngay từ nguồn sẽ từ chối mọi thao tác không tuân thủ.
Cách tiếp cận “kiểm tra trước” này tương đồng một cách khác thường với logic nền tảng mà Newton dùng cho quản trị rủi ro giao dịch—chỉ khác là Dusk áp dụng vào một lớp nhạy cảm hơn: việc hiện thực hóa tuân thủ dưới sự giám sát của cơ quan quản lý.
Tầng dữ liệu dựa vào bộ nhớ trong tài khoản riêng để thực hiện vòng khép kín kiểm tra, về mặt lý thuyết thì cao hơn một bậc so với những dự án dựa vào kiểm duyệt thủ công ngoài chuỗi. Độ tin cậy của việc định giá do RedStone cung cấp đã được xác thực trên hơn 110 chuỗi, phần này tôi không quá lo.
Nhưng tôi phải nói rằng, trong các tài liệu công khai hiện nay có một điểm khiến tôi không ngủ yên: quyền hạn sửa đổi quy tắc không rõ ràng.
Hợp đồng thông minh dù chạy “mượt” đến đâu, nếu phía sau lại cất giấu một “cửa hậu của quản trị viên” có thể lúc nào cũng sửa tham số, đổi quy tắc, thì năng lực chống chịu rủi ro của toàn bộ hệ thống sẽ phải chấm một dấu hỏi lớn. Nếu chính sách quản lý thay đổi thì sao? Quy tắc thuế điều chỉnh thì ai là người kích hoạt việc sửa đổi? Cơ chế time lock và đa chữ ký có bị ràng buộc bắt buộc không? Nhìn vào hiện tại, tôi chưa thấy câu trả lời rõ ràng cho các vấn đề then chốt đó.
Nhận định của tôi là: hướng đi đúng, nhưng con đường còn dài. Mô hình kiểm tra trước biến các quy định quản lý thành năng lực nền tảng ở tầng chuỗi—tôi nhìn dài hạn là rất đáng kỳ vọng. Nhưng Dusk vẫn cần một bài kiểm tra với quy mô vốn thực tế—chạy thử với vài triệu đô la không đồng nghĩa là ở quy mô vài chục tỷ cũng sẽ vững vàng. Sau này tôi sẽ tập trung theo dõi tiến độ triển khai DuskTrade hợp tác với NPEX: khi toàn bộ quy trình từ khớp lệnh, thanh/ quyết toán, đến kiểm tra tuân thủ đều chạy thông suốt, thì mới thật sự chứng minh được tính khả thi của lộ trình này.
Các bạn nghĩ sao: tuân thủ “native” trên chuỗi có phải là giải pháp chung cuộc, hay quá lý tưởng hóa? Hãy thảo luận ở phần bình luận.
#dusk $DUSK @Dusk
Cho đến khi tách riêng và mổ xẻ Zedger và tiêu chuẩn XSC của @Dusk , tôi mới nhận ra có một đội ngũ đã nghĩ thấu đáo vấn đề này. Họ mã hóa trực tiếp các logic tuân thủ như kiểm tra nhà đầu tư đủ điều kiện, hạn chế chuyển nhượng, cơ chế bỏ phiếu phân phối lợi nhuận… thành các quy tắc “cứng” ở tầng hợp đồng. Trước khi mỗi giao dịch được thanh toán, đầu tiên phải qua một vòng kiểm tra tuân thủ—đạt thì mới tạo ra chứng từ trên chuỗi để cho phép, không đạt thì bị chặn ngay tại chỗ. Không phải đợi giao dịch đã lên chuỗi rồi mới đi truy trách nhiệm, mà ngay từ nguồn sẽ từ chối mọi thao tác không tuân thủ.
Cách tiếp cận “kiểm tra trước” này tương đồng một cách khác thường với logic nền tảng mà Newton dùng cho quản trị rủi ro giao dịch—chỉ khác là Dusk áp dụng vào một lớp nhạy cảm hơn: việc hiện thực hóa tuân thủ dưới sự giám sát của cơ quan quản lý.
Tầng dữ liệu dựa vào bộ nhớ trong tài khoản riêng để thực hiện vòng khép kín kiểm tra, về mặt lý thuyết thì cao hơn một bậc so với những dự án dựa vào kiểm duyệt thủ công ngoài chuỗi. Độ tin cậy của việc định giá do RedStone cung cấp đã được xác thực trên hơn 110 chuỗi, phần này tôi không quá lo.
Nhưng tôi phải nói rằng, trong các tài liệu công khai hiện nay có một điểm khiến tôi không ngủ yên: quyền hạn sửa đổi quy tắc không rõ ràng.
Hợp đồng thông minh dù chạy “mượt” đến đâu, nếu phía sau lại cất giấu một “cửa hậu của quản trị viên” có thể lúc nào cũng sửa tham số, đổi quy tắc, thì năng lực chống chịu rủi ro của toàn bộ hệ thống sẽ phải chấm một dấu hỏi lớn. Nếu chính sách quản lý thay đổi thì sao? Quy tắc thuế điều chỉnh thì ai là người kích hoạt việc sửa đổi? Cơ chế time lock và đa chữ ký có bị ràng buộc bắt buộc không? Nhìn vào hiện tại, tôi chưa thấy câu trả lời rõ ràng cho các vấn đề then chốt đó.
Nhận định của tôi là: hướng đi đúng, nhưng con đường còn dài. Mô hình kiểm tra trước biến các quy định quản lý thành năng lực nền tảng ở tầng chuỗi—tôi nhìn dài hạn là rất đáng kỳ vọng. Nhưng Dusk vẫn cần một bài kiểm tra với quy mô vốn thực tế—chạy thử với vài triệu đô la không đồng nghĩa là ở quy mô vài chục tỷ cũng sẽ vững vàng. Sau này tôi sẽ tập trung theo dõi tiến độ triển khai DuskTrade hợp tác với NPEX: khi toàn bộ quy trình từ khớp lệnh, thanh/ quyết toán, đến kiểm tra tuân thủ đều chạy thông suốt, thì mới thật sự chứng minh được tính khả thi của lộ trình này.
Các bạn nghĩ sao: tuân thủ “native” trên chuỗi có phải là giải pháp chung cuộc, hay quá lý tưởng hóa? Hãy thảo luận ở phần bình luận.
#dusk $DUSK @Dusk
