Tôi đã ngồi với một chi tiết trong thiết kế TBV của Babylon mà chưa thấy ai thực sự “đụng” tới

Điểm mấu chốt là BitVM3 loại bỏ hoàn toàn mô hình signer-committee cũ; việc redemption (hoàn tiền/thu hồi) được kiểm soát trực tiếp bởi hai bên được định trước thay vì một nhóm có thể cấu kết. Được rồi, như vậy sẽ giải quyết được vấn đề cấu kết. Nhưng chẳng ai thực sự đặt câu hỏi tiếp theo: chuyện gì xảy ra nếu một trong hai bên được định trước đó… lại không còn ở đó khi cần thực hiện redemption?

Mô hình committee có một sự đánh đổi khó chịu: càng nhiều người thì càng có khả năng cấu kết, nhưng đồng thời cũng có nhiều người hơn để vẫn có thể “tới được” nếu một người rời đi. Chuyển sang hai bên được định trước thì giảm rủi ro cấu kết, nhưng lại có vẻ như dồn rủi ro về tính sẵn sàng (liveness) vào ít điểm có thể thất bại hơn. Nếu một bên “đi tối” vào đúng thời điểm bất lợi, bên còn lại có thực sự có lối đi rõ ràng để khôi phục quỹ hay là cơ chế proof/challenge (chứng minh/thách thức) cần phải làm rất nhiều công việc thầm lặng để lấp khoảng trống đó?

Tôi không có câu trả lời rõ ràng ở đây. Có thể mọi chuyện chỉ là không đáng kể nếu cửa sổ challenge xử lý tốt. Nhưng “chúng tôi đã loại bỏ rủi ro cấu kết” và “chúng tôi đã loại bỏ rủi ro” không phải là cùng một tuyên bố, và tôi vẫn chưa thấy tài liệu của Babylon đề cập trực tiếp tới phần thứ hai
@BabylonLabs_io $BABY #baby #OilDropsAbout6% #BrentCrudeFallsAbout6%

Điều quan trọng nhất là gì?