TÔI KHÔNG GỌI ĐÓ LÀ “TỰ QUẢN” CHO ĐẾN KHI BÊN KIA BIẾN MẤT.

Tôi có thể tin gần như bất kỳ hệ thống nào khi mọi thứ vẫn đang hoạt động.

Thử thách thật sự bắt đầu khi người vận hành ngừng phản hồi.

Vì vậy, một phần trong thiết kế TBV của Babylon quan trọng với tôi hơn cả tiêu đề vay mượn: lộ trình tự yêu cầu (self-claim) của người gửi.

Trong quá trình thoát bình thường, tôi trả khoản nợ, rút tài sản thế chấp, và Nhà cung cấp Vault sẽ thực hiện yêu cầu nhận Bitcoin.

Nhưng điều gì xảy ra nếu nhà cung cấp đó đi offline, trì hoãn quy trình, hoặc đơn giản là từ chối hành động?

Babylon chuẩn bị một tuyến thoát khác ngay từ khi vault được tạo.

Bằng cách sử dụng khóa WOTS dành riêng cho vault và các hiện vật (artifacts) của claimer, người gửi có thể khởi tạo yêu cầu nhận Bitcoin thông qua công cụ watchtower của giao thức. Sau thời gian thách thức, BTC có thể quay về địa chỉ đã được cam kết trong lúc tạo vault.

Không cần sự hợp tác từ nhà cung cấp không sẵn có.

Nhưng ở đây cũng có một trách nhiệm không mấy dễ chịu.

Cơ chế dự phòng này chỉ bảo vệ tôi nếu tôi lưu trữ an toàn những tệp khôi phục đó. Nếu mất chúng, “tự quản” sẽ trở nên yếu hơn rất nhiều đúng lúc tôi cần nhất.

Đó là điều khiến thiết kế này trở nên thú vị.

Babylon không cho rằng mọi người vận hành sẽ luôn sẵn có mãi mãi. Nó chuẩn bị cho tình huống thất bại trước khi BTC đi vào vault.

Bài học của tôi:

Một vault đáng tin không phải là vault hứa hẹn thời gian hoạt động hoàn hảo.

Mà là một vault vẫn giúp tôi có lối thoát đáng tin cậy ngay cả khi thời gian hoạt động biến mất.

@BabylonLabs_io $BABY $BLESS $HOME #baby