Tôi đang xem cách Quỹ Magic Newton mô tả cơ cấu quản trị của chính mình, và có điều gì đó đã thu hút sự chú ý của tôi — họ vận hành bởi cái mà họ gọi là hội đồng quản trị độc lập, với một báo cáo minh bạch được công bố riêng tại docs.newt.foundation. Cơ cấu này khiến tôi thấy thú vị vì Newton định vị mình như một lớp ủy quyền trung lập, nơi các tổ chức, cơ quan quản lý và các tác nhân tự chủ đều có thể kết nối vào một cách bình đẳng. Nhưng tính trung lập là một điều kỳ lạ để tuyên bố khi vẫn có một hội đồng đang đưa ra quyết định ở đâu đó phía thượng nguồn. Tôi đôi khi tự hỏi rằng một lớp chính sách có thể thực sự “trung lập” đến mức nào, nếu bạn cân nhắc rằng rốt cuộc vẫn là một nhóm người được xác định đang điều phối quỹ chịu trách nhiệm quản lý và chăm sóc nó.
Điều có vẻ đáng chú ý là Bộ Công cụ Bảo vệ Vault (Vault Protection Kit) được phát hành kèm theo bản beta mainnet, trong đó gói ghém các hướng dẫn chính sách trừng phạt OFAC cùng với phần tích hợp Chainalysis Hexagate để giám sát rủi ro cho hợp đồng thông minh. Đây là một “cược” rất cụ thể và rất ưu tiên tuân thủ. Newton không chỉ xây dựng hạ tầng chung — họ đang xây dựng hạ tầng nhắm thẳng đến nhóm vốn mang tính tổ chức, những bên cần có sàng lọc trừng phạt được nhúng sẵn trước khi thậm chí họ mới cân nhắc chạm vào một vault. Nó khiến tôi nghĩ dự án này ít tập trung vào người dùng bản địa DeFi hơn, mà chủ yếu là thuyết phục các đội rủi ro và tuân thủ ở các tổ chức truyền thống rằng các “đường ray” onchain có thể đáp ứng nghĩa vụ hiện có của họ mà không cần một quy trình rà soát thủ công cho mọi giao dịch.
Nhưng điều đó cũng gợi ra một mâu thuẫn tiềm ẩn. Các chính sách được viết bằng Rego — một ngôn ngữ mang tính khai báo — và các bộ sưu tập viên định nghĩa quy tắc “trước” để vault sau đó tự động thực thi. Nếu toàn bộ lời chào là biến việc tuân thủ thành mã, thì chính mã đó lại trở thành thứ mà các cơ quan quản lý và kiểm toán viên cần tin tưởng, chứ không chỉ là ý định đằng sau nó. Ai sẽ rà soát các chính sách Rego về tính đúng đắn khi chúng đã được đưa vào vận hành? Có một dấu vết kiểm toán công khai cho các thay đổi chính sách hay không, theo cách tương tự như có dấu vết xác thực (attestation) cho các giao dịch? Tôi chưa thấy được trình bày rõ ràng điều này, và nó khiến tôi tò mò liệu “tuân thủ-as-code” một cách âm thầm có thể chuyển gánh nặng từ các đội pháp lý sang bất kỳ ai đã viết logic của chính sách đó hay không — đó là một kiểu trách nhiệm giải trình rất khác.
Nhìn từ bên ngoài, tham vọng này có vẻ nhất quán — thay thế các công việc tuân thủ thủ công, ngoài chuỗi bằng một cơ chế có thể kiểm chứng và được thực thi ngay ở cấp độ giao thức. $NEWT nằm bên dưới tất cả điều đó như là token tiện ích dùng để chi trả cho công việc ủy quyền và xác minh, và cảm giác nó gần như là yếu tố phụ so với câu hỏi về kiến trúc thực sự. Mối không chắc lớn đối với tôi không phải là liệu thiết kế kỹ thuật có hoạt động trong một bản demo hay không, mà là liệu các tổ chức có sẵn sàng giao việc thực thi chính sách cho một lớp trung lập giai đoạn beta hay không, trước khi có một lịch sử dài về cách xử lý các tranh chấp, các tình huống biên và các lỗi chính sách trên công khai. Tạm thời thì khung này đọc lên khá rõ ràng trên giấy, nhưng hiệu quả của nó khi các rủi ro tuân thủ thực sự được đưa vào cuộc vẫn là một câu hỏi ngỏ... dù sao thì thời gian sẽ trả lời thôi👍