Tôi đã cố gắng chốt một chi tiết cụ thể trong thiết kế của các Trustless Bitcoin Vaults, và cuối cùng lại nhận được hai câu trả lời khác nhau từ hai bài viết về cùng một Temp Check. Một tài khoản mô tả bước sau thanh lý là mở cho các bên thanh lý không cần xin phép (permissionless liquidators), những người có thể đổi một vault bị tịch thu lấy WBTC với một mức chênh lệch nhỏ để thanh toán khoản nợ của người vay. Trong khi đó, một tài khoản khác về cùng đề xuất lại mô tả rằng một nhóm arbitrageurs được cấp quyền (permissioned) sẽ mua các vault được ký quỹ đó. Cùng một cơ chế, cùng hồ sơ ngày 25/5, nhưng lại dùng hai từ khác nhau để nói về ai được tham gia.
Điều này quan trọng vì “permissionless” và “permissioned” không phải là các từ đồng nghĩa theo phong cách trong DeFi; chúng cho biết ai cần được chấp thuận để kiếm phần chênh lệch từ thanh lý (liquidation spread). Nếu là permissionless, bất kỳ ai có vốn cũng có thể cạnh tranh để thanh lý, gần với cách Aave vận hành ngay bây giờ. Nếu là permissioned, một nhóm được allowlist sẽ đứng giữa một vault bị mặc định (defaulted) và cách giải quyết (resolution) của nó, điều này lại đưa đúng kiểu “cổng kiểm soát” mà toàn bộ phần chào mời (pitch) hướng tới để tránh.
Tôi nghiêng về hướng permissionless là thiết kế dự định, vì các tài liệu do chính Babylon công bố mô tả layer vault như việc loại bỏ các consortium người ký (signer consortiums) và quyền kiểm soát tùy ý ở khắp nơi khác trong hệ thống. Nhưng ý định không phải lúc nào cũng giống với một bản đặc tả đã công bố, và thiết kế oracle kèm các giả định tin cậy đầy đủ đã được đẩy sang một giai đoạn ARFC sau đó thay vì được chốt ngay bây giờ.
Vậy rốt cuộc là thế nào: làm sao tôi có thể gọi một hệ thống là “trustless” khi các thông tin bên ngoài báo cáo về hồ sơ quản trị của chính nó còn không thể thống nhất về việc ai được phép chạm vào bước cuối cùng?
Thiết kế thanh lý của Babylon có lẽ mang tinh thần permissionless, nhưng vẫn chưa rõ ràng một cách không thể tranh cãi trong hồ sơ công khai, và khoảng trống giữa ý định và tài liệu đáng để theo dõi trước khi giai đoạn ARFC khóa chặt nó mãi mãi.
@BabylonLabs_io $BABY #baby $BANK
Điều này quan trọng vì “permissionless” và “permissioned” không phải là các từ đồng nghĩa theo phong cách trong DeFi; chúng cho biết ai cần được chấp thuận để kiếm phần chênh lệch từ thanh lý (liquidation spread). Nếu là permissionless, bất kỳ ai có vốn cũng có thể cạnh tranh để thanh lý, gần với cách Aave vận hành ngay bây giờ. Nếu là permissioned, một nhóm được allowlist sẽ đứng giữa một vault bị mặc định (defaulted) và cách giải quyết (resolution) của nó, điều này lại đưa đúng kiểu “cổng kiểm soát” mà toàn bộ phần chào mời (pitch) hướng tới để tránh.
Tôi nghiêng về hướng permissionless là thiết kế dự định, vì các tài liệu do chính Babylon công bố mô tả layer vault như việc loại bỏ các consortium người ký (signer consortiums) và quyền kiểm soát tùy ý ở khắp nơi khác trong hệ thống. Nhưng ý định không phải lúc nào cũng giống với một bản đặc tả đã công bố, và thiết kế oracle kèm các giả định tin cậy đầy đủ đã được đẩy sang một giai đoạn ARFC sau đó thay vì được chốt ngay bây giờ.
Vậy rốt cuộc là thế nào: làm sao tôi có thể gọi một hệ thống là “trustless” khi các thông tin bên ngoài báo cáo về hồ sơ quản trị của chính nó còn không thể thống nhất về việc ai được phép chạm vào bước cuối cùng?
Thiết kế thanh lý của Babylon có lẽ mang tinh thần permissionless, nhưng vẫn chưa rõ ràng một cách không thể tranh cãi trong hồ sơ công khai, và khoảng trống giữa ý định và tài liệu đáng để theo dõi trước khi giai đoạn ARFC khóa chặt nó mãi mãi.
@BabylonLabs_io $BABY #baby $BANK