Tôi đã từng giẫm bẫy trong pool dùng chung của cầu cross-chain—người khác thao tác rồi bị thanh lý liên đới, làm mất đi một phần vị thế của tôi. Tiền không nhiều, nhưng cảm giác bức bối vì “lỗi của người khác tôi phải đứng ra gánh” đến giờ vẫn còn nhớ.
Từ đó về sau, khi xem bất kỳ phương án nào đưa BTC vào DeFi, tôi đều hỏi một câu: Trong hệ thống có thứ gì đó có thể khóa rủi ro lại ở “phía người khác” không, để nó không chảy sang chỗ của tôi?
Khi lật tài liệu Babylon, tôi phát hiện ra một thứ gọi là ApplicationRegistry. Đây là một hợp đồng trên Ethereum, có nhiệm vụ ghi lại các ứng dụng DeFi đã được quản trị chấp thuận và có thể nhận tiền từ kho quỹ (treasury). Ứng dụng mới muốn kết nối phải đi qua quy trình xét duyệt quản trị, đồng thời triển khai hợp đồng adapter của riêng mình. Hiện tại, mới chỉ có adapter của Aave v4 đã được đăng ký. Không phải ai muốn kết nối cũng được.
Phản ứng đầu tiên của tôi là: Ồ, kiểu như danh sách trắng, không cho dự án kém chất lượng vào.
Nhưng đọc lần thứ hai, tôi thấy một chi tiết mà trước đó mình đã bỏ qua—ApplicationRegistry không gắn với “ứng dụng”, mà gắn với “hợp đồng adapter tương ứng với ứng dụng”. Sau khi adapter được đăng ký, các quy tắc sẽ bị “đóng băng”, sẽ không bị sửa đổi âm thầm khi bạn không hay biết.
Đến đây tôi mới nhận ra—trước đây tôi tưởng nó chỉ là “duyệt xem ai được phép vào”, nhưng thực ra nó là “hàn cứng các quy tắc”. Aave gặp sự cố chỉ ảnh hưởng đến adapter của Aave; GoMining gặp sự cố chỉ ảnh hưởng đến adapter của GoMining. Kho quỹ BTC của bạn tách rời khỏi lớp ứng dụng, nên lỗi ở tầng ứng dụng không thể lây xuống tầng tài sản.
Logic thiết kế này tôi thấy là hợp lý. Nhưng cái giá cũng khá rõ ràng: mỗi ứng dụng mới đều phải đi qua quy trình quản trị, nên tốc độ mở rộng sẽ chậm hơn nhiều so với các phương án “ai cũng có thể kết nối”.
Thứ khiến tôi còn giữ thái độ dè chừng là hiệu quả của “cơ chế cho phép/thẩm định đầu vào” khi mở rộng quy mô—khi có vài chục ứng dụng xếp hàng để kết nối, liệu nhịp độ quản trị có giữ vững được không? Hiện tại tôi chưa thấy đủ dữ liệu thực nghiệm để chứng minh.
Tuy vậy, có một điểm quan điểm của tôi đã thay đổi—trước đây tôi nghĩ “cách ly rủi ro” chỉ là điều gì đó khá trừu tượng, nhưng ApplicationRegistry đã cho tôi thấy đường đi cụ thể: biến mỗi ứng dụng thành một module cắm (slot) độc lập; cắm nhầm thì chỉ cháy phần đó, không làm cháy cả căn nhà.
Thiết kế này theo bạn là “chậm” hay “vững”?
$BABY @BabylonLabs_io #baby
Từ đó về sau, khi xem bất kỳ phương án nào đưa BTC vào DeFi, tôi đều hỏi một câu: Trong hệ thống có thứ gì đó có thể khóa rủi ro lại ở “phía người khác” không, để nó không chảy sang chỗ của tôi?
Khi lật tài liệu Babylon, tôi phát hiện ra một thứ gọi là ApplicationRegistry. Đây là một hợp đồng trên Ethereum, có nhiệm vụ ghi lại các ứng dụng DeFi đã được quản trị chấp thuận và có thể nhận tiền từ kho quỹ (treasury). Ứng dụng mới muốn kết nối phải đi qua quy trình xét duyệt quản trị, đồng thời triển khai hợp đồng adapter của riêng mình. Hiện tại, mới chỉ có adapter của Aave v4 đã được đăng ký. Không phải ai muốn kết nối cũng được.
Phản ứng đầu tiên của tôi là: Ồ, kiểu như danh sách trắng, không cho dự án kém chất lượng vào.
Nhưng đọc lần thứ hai, tôi thấy một chi tiết mà trước đó mình đã bỏ qua—ApplicationRegistry không gắn với “ứng dụng”, mà gắn với “hợp đồng adapter tương ứng với ứng dụng”. Sau khi adapter được đăng ký, các quy tắc sẽ bị “đóng băng”, sẽ không bị sửa đổi âm thầm khi bạn không hay biết.
Đến đây tôi mới nhận ra—trước đây tôi tưởng nó chỉ là “duyệt xem ai được phép vào”, nhưng thực ra nó là “hàn cứng các quy tắc”. Aave gặp sự cố chỉ ảnh hưởng đến adapter của Aave; GoMining gặp sự cố chỉ ảnh hưởng đến adapter của GoMining. Kho quỹ BTC của bạn tách rời khỏi lớp ứng dụng, nên lỗi ở tầng ứng dụng không thể lây xuống tầng tài sản.
Logic thiết kế này tôi thấy là hợp lý. Nhưng cái giá cũng khá rõ ràng: mỗi ứng dụng mới đều phải đi qua quy trình quản trị, nên tốc độ mở rộng sẽ chậm hơn nhiều so với các phương án “ai cũng có thể kết nối”.
Thứ khiến tôi còn giữ thái độ dè chừng là hiệu quả của “cơ chế cho phép/thẩm định đầu vào” khi mở rộng quy mô—khi có vài chục ứng dụng xếp hàng để kết nối, liệu nhịp độ quản trị có giữ vững được không? Hiện tại tôi chưa thấy đủ dữ liệu thực nghiệm để chứng minh.
Tuy vậy, có một điểm quan điểm của tôi đã thay đổi—trước đây tôi nghĩ “cách ly rủi ro” chỉ là điều gì đó khá trừu tượng, nhưng ApplicationRegistry đã cho tôi thấy đường đi cụ thể: biến mỗi ứng dụng thành một module cắm (slot) độc lập; cắm nhầm thì chỉ cháy phần đó, không làm cháy cả căn nhà.
Thiết kế này theo bạn là “chậm” hay “vững”?
$BABY @BabylonLabs_io #baby