Hôm nay, khi nghĩ về một khoản thanh toán đang bị tranh chấp, tôi nhận thấy điều gì đó. Điều khiến tôi nhớ không phải bản thân giao dịch, mà là phán quyết cần thiết sau khi hệ thống đã ghi nhận nó.
Thông thường, tôi nghĩ về smart contract dựa trên ưu điểm lớn nhất của chúng: tính tất định. Càng nghiên cứu hạ tầng tài chính, tôi càng thấy rõ ưu điểm này có một giới hạn. Một hợp đồng có thể thực thi đúng như thiết kế, nhưng tình huống tài chính xung quanh vẫn cần được diễn giải.
Sự khác biệt đó quan trọng với tôi trong các thị trường được quản lý. Các tranh chấp, tái cơ cấu, quyết định phục hồi và các hoạt động doanh nghiệp đặc biệt có thể tạo ra những tình tiết vốn không hề tồn tại khi quy tắc ban đầu được viết ra. Vấn đề không nhất thiết là mã lỗi. Thực tế có thể đã thay đổi sau khi quy tắc được xác định.
Điều đó khiến tôi thay đổi cách nhìn về tự động hóa. Tôi không hứng thú với việc đưa mọi quyết định tài chính vào mã chỉ vì điều đó có thể được mã hóa. Câu hỏi hữu ích hơn là: logic tất định nên dừng ở đâu và phần phán quyết do quản trị chi phối nên bắt đầu từ khi nào.
Nếu mọi ngoại lệ đều được mã hóa trước, tôi nghĩ hợp đồng sẽ khó bảo trì hơn và quản trị sẽ trở nên phức tạp hơn. Nếu mọi ngoại lệ vẫn nằm ngoài giao thức, thì quá nhiều khâu trong quy trình sẽ tiếp tục phụ thuộc vào điều phối thủ công.
Đó là lúc @Dusk trở nên thú vị với tôi. Dusk tách việc thực thi khỏi nền tảng thanh toán: DuskVM hỗ trợ các hợp đồng Rust/WASM trên L1, DuskEVM cung cấp thực thi EVM, còn DuskDS cung cấp đồng thuận, tính cuối cùng và khả năng sẵn sàng dữ liệu.
Câu hỏi kiến trúc đằng sau chúng còn quan trọng hơn: liệu ranh giới giữa thực thi tự động và sự cân nhắc/uy quyền mang tính thể chế có thể được nêu rõ, được kiểm soát và có thể kiểm toán hay không?
Với tôi, mục tiêu không phải là tự động hóa tối đa. Đó là tự động hóa chính xác: biết mã nên quyết định điều gì, con người nên quyết định điều gì, và hệ thống tài chính ghi nhận sự khác biệt đó như thế nào. ⚖️
#dusk #BinanceSquare $DUSK $PROM $SPK @Dusk
Thông thường, tôi nghĩ về smart contract dựa trên ưu điểm lớn nhất của chúng: tính tất định. Càng nghiên cứu hạ tầng tài chính, tôi càng thấy rõ ưu điểm này có một giới hạn. Một hợp đồng có thể thực thi đúng như thiết kế, nhưng tình huống tài chính xung quanh vẫn cần được diễn giải.
Sự khác biệt đó quan trọng với tôi trong các thị trường được quản lý. Các tranh chấp, tái cơ cấu, quyết định phục hồi và các hoạt động doanh nghiệp đặc biệt có thể tạo ra những tình tiết vốn không hề tồn tại khi quy tắc ban đầu được viết ra. Vấn đề không nhất thiết là mã lỗi. Thực tế có thể đã thay đổi sau khi quy tắc được xác định.
Điều đó khiến tôi thay đổi cách nhìn về tự động hóa. Tôi không hứng thú với việc đưa mọi quyết định tài chính vào mã chỉ vì điều đó có thể được mã hóa. Câu hỏi hữu ích hơn là: logic tất định nên dừng ở đâu và phần phán quyết do quản trị chi phối nên bắt đầu từ khi nào.
Nếu mọi ngoại lệ đều được mã hóa trước, tôi nghĩ hợp đồng sẽ khó bảo trì hơn và quản trị sẽ trở nên phức tạp hơn. Nếu mọi ngoại lệ vẫn nằm ngoài giao thức, thì quá nhiều khâu trong quy trình sẽ tiếp tục phụ thuộc vào điều phối thủ công.
Đó là lúc @Dusk trở nên thú vị với tôi. Dusk tách việc thực thi khỏi nền tảng thanh toán: DuskVM hỗ trợ các hợp đồng Rust/WASM trên L1, DuskEVM cung cấp thực thi EVM, còn DuskDS cung cấp đồng thuận, tính cuối cùng và khả năng sẵn sàng dữ liệu.
Câu hỏi kiến trúc đằng sau chúng còn quan trọng hơn: liệu ranh giới giữa thực thi tự động và sự cân nhắc/uy quyền mang tính thể chế có thể được nêu rõ, được kiểm soát và có thể kiểm toán hay không?
Với tôi, mục tiêu không phải là tự động hóa tối đa. Đó là tự động hóa chính xác: biết mã nên quyết định điều gì, con người nên quyết định điều gì, và hệ thống tài chính ghi nhận sự khác biệt đó như thế nào. ⚖️
#dusk #BinanceSquare $DUSK $PROM $SPK @Dusk
