#baby Gần đây tôi đã xem TBV của @BabylonLabs_io .
Bắt đầu từ đó, tôi không còn chăm chăm theo dõi trang nạp tiền nữa.
Thay vào đó, tôi tập trung nghiên cứu chuyện gì sẽ xảy ra sau khi Provider biến mất.
Câu trả lời nằm trong WOTS keypair và các hiện vật (artifacts) của claimer.
Khi tạo Vault.
Người dùng sẽ nhận được một khóa ký một lần.
Cùng với cả một bộ giao dịch đã được pre-sign và dữ liệu thử thách (challenge).
Những thứ này bình thường trông giống như phụ kiện kỹ thuật.
Nhưng nếu sự cố thật sự xảy ra, chúng có thể lại là lối thoát duy nhất.
Vault Provider đang online.
Nó có thể hỗ trợ người dùng thực hiện Claim, Assert và Payout.
Provider không phản hồi.
Về lý thuyết, người dùng vẫn có thể chạy công cụ dòng lệnh, đi theo đúng lộ trình giao dịch đã được thiết lập để rút về địa chỉ gốc của $BTC .
Nghe có vẻ là rất ít cần tin tưởng.
Nhưng ngay lập tức tôi nghĩ đến một kịch bản thực tế hơn.
Provider rớt mạng.
Máy tính cũ của người dùng cũng hỏng.
File WOTS chỉ tồn tại trên đúng thiết bị ban đầu.
Không có bản sao khôi phục lưu offline.
Trong tình huống này, giao thức không thu giữ tài sản.
Script cũng không ngăn việc thoát.
Thế nhưng người dùng vẫn có thể đứng trước lối ra, lại không tìm được chìa khóa để mở cửa.
Vì vậy, “không cần phê duyệt của người vận hành” chỉ mới là bước 1.
Bước tiếp theo là giúp người dùng phổ thông thực sự có năng lực khôi phục độc lập.
Dữ liệu tôi muốn xem cũng rất đơn giản.
Có bao nhiêu người dùng đã sao lưu tài liệu.
Tỷ lệ thành công của Self-Claim là bao nhiêu.
Một lần khôi phục đầy đủ mất bao lâu.
Thất bại chủ yếu kẹt ở bước nào.
Câu chuyện về hạ tầng của $BABY có thể rất lớn.
Nhưng TBV có thực sự trưởng thành hay không, không thể chỉ nhìn vào việc đã nạp thành công được bao nhiêu $BTC .
Bài kiểm tra áp lực thực sự là: khi tất cả các vai trò hỗ trợ đều không online, người dùng có thể chỉ dựa vào những tệp họ tự lưu để mang toàn bộ tài sản đi trọn vẹn hay không.
#baby
Bắt đầu từ đó, tôi không còn chăm chăm theo dõi trang nạp tiền nữa.
Thay vào đó, tôi tập trung nghiên cứu chuyện gì sẽ xảy ra sau khi Provider biến mất.
Câu trả lời nằm trong WOTS keypair và các hiện vật (artifacts) của claimer.
Khi tạo Vault.
Người dùng sẽ nhận được một khóa ký một lần.
Cùng với cả một bộ giao dịch đã được pre-sign và dữ liệu thử thách (challenge).
Những thứ này bình thường trông giống như phụ kiện kỹ thuật.
Nhưng nếu sự cố thật sự xảy ra, chúng có thể lại là lối thoát duy nhất.
Vault Provider đang online.
Nó có thể hỗ trợ người dùng thực hiện Claim, Assert và Payout.
Provider không phản hồi.
Về lý thuyết, người dùng vẫn có thể chạy công cụ dòng lệnh, đi theo đúng lộ trình giao dịch đã được thiết lập để rút về địa chỉ gốc của $BTC .
Nghe có vẻ là rất ít cần tin tưởng.
Nhưng ngay lập tức tôi nghĩ đến một kịch bản thực tế hơn.
Provider rớt mạng.
Máy tính cũ của người dùng cũng hỏng.
File WOTS chỉ tồn tại trên đúng thiết bị ban đầu.
Không có bản sao khôi phục lưu offline.
Trong tình huống này, giao thức không thu giữ tài sản.
Script cũng không ngăn việc thoát.
Thế nhưng người dùng vẫn có thể đứng trước lối ra, lại không tìm được chìa khóa để mở cửa.
Vì vậy, “không cần phê duyệt của người vận hành” chỉ mới là bước 1.
Bước tiếp theo là giúp người dùng phổ thông thực sự có năng lực khôi phục độc lập.
Dữ liệu tôi muốn xem cũng rất đơn giản.
Có bao nhiêu người dùng đã sao lưu tài liệu.
Tỷ lệ thành công của Self-Claim là bao nhiêu.
Một lần khôi phục đầy đủ mất bao lâu.
Thất bại chủ yếu kẹt ở bước nào.
Câu chuyện về hạ tầng của $BABY có thể rất lớn.
Nhưng TBV có thực sự trưởng thành hay không, không thể chỉ nhìn vào việc đã nạp thành công được bao nhiêu $BTC .
Bài kiểm tra áp lực thực sự là: khi tất cả các vai trò hỗ trợ đều không online, người dùng có thể chỉ dựa vào những tệp họ tự lưu để mang toàn bộ tài sản đi trọn vẹn hay không.
#baby