Hôm nay tôi lại lật đọc lại whitepaper của BabylonLabs một lần nữa, và lần này thứ làm tôi khựng lại không phải chi tiết kỹ thuật, mà là một bảng biểu. Bảng so sánh giả định tin cậy đa phương trong Mục 5.1, đặt "kho lưu ký không cần tin cậy" cạnh DLC và cầu BitVM tổng quát để đối chiếu. Mấy mục đầu nhìn khá choáng: người vay rút tài sản thế chấp, bên thanh lý thực hiện thanh lý, tất cả đều là Trustless. Nhưng đến dòng "người cho vay khoản nhỏ rút từ hợp đồng vay", thì ghi là "tin cậy (n-k+1)-of-n bên thanh lý hoặc (m-j+1)-of-m người cho vay khoản lớn" — gần như cùng một câu với ô của cầu BitVM tổng quát. #baby @BabylonLabs_io

Nói thẳng ra: nếu bạn là người cho vay đã bỏ một khoản nhỏ vào pool cho vay, mức độ an toàn tài sản của bạn cũng chẳng cao hơn người dùng cầu là bao nhiêu; thứ bạn đang tin không phải mật mã học, mà là "trong đám bên thanh lý và cá voi này, đa số không phải kẻ xấu". Nó chẳng khác gì hội nghị cư dân khu chung cư: bạn đóng phí quản lý, hợp đồng viết là "quyết nghị chung của các chủ sở hữu", nghe rất phi tập trung, nhưng đến lúc có sự cố, việc có lấy lại được tiền đặt cọc hay không lại phụ thuộc vào việc vài chục chủ nhà lớn đi họp kia có đủ đáng tin hay không, chứ không liên quan gì đến việc bạn có đóng tiền hay không.

Bản whitepaper tự nó đã đặt dữ liệu của dòng này ra đó, không giấu giếm, điểm này tôi thấy khá thành thật. Nhưng các tham số ngưỡng cụ thể k, n, j, m sẽ được đặt như thế nào khi triển khai thực tế cho pool cho vay, và do ai biểu quyết quyết định, hiện trong tài liệu công khai tôi vẫn chưa tìm thấy; ghi chú lại một dòng trước đã.

$BABY Về phía token, thiết kế phân tầng tin cậy của Trustless Bitcoin Vaults thực chất đã tách rất rõ "không cần tin cậy ở tầng protocol" và "tin cậy theo dạng pool ở tầng ứng dụng". Điều này là một mô-đun nền tảng không thể né tránh cho cách định giá rủi ro và đặt tham số khi tích hợp nhiều ứng dụng về sau, nhưng liệu có thể đi đến quy trình chuẩn hóa để triển khai hay không thì tôi sẽ tiếp tục theo dõi dữ liệu trên testnet. #baby $BABY