Thành thật mà nói, tôi đã dừng lại ở một ví dụ trong whitepaper của Babylon mà cảm thấy quá “sạch” để có thể là lời giải thực sự.

Một người vay sẽ khóa BTC để vay từ một bên cho vay trên Ethereum. Theo whitepaper, cả hai bên sẽ cùng ký trước một bộ các giao dịch Bitcoin ngay từ đầu, xác định chính xác thời điểm mỗi bên có thể nhận/chiếm số tiền.
Tôi kỳ vọng bài viết sẽ dừng ở đó và coi như đã giải quyết xong. Nhưng không phải vậy. Dòng tiếp theo nêu rằng cách ký trước này chỉ hoạt động với đúng một sự kiện kích hoạt cụ thể, và không thể mở rộng để áp dụng cho các điều kiện DeFi bất kỳ.

Chi tiết đơn lẻ đó đã khiến tôi chú ý. Một cơ chế được thiết kế để chứng minh tính không cần tin cậy (trustlessness) ngay lập tức, theo đúng lời của nó, rằng nó chỉ bao phủ một loại sự kiện cụ thể và không thể “kéo giãn” để xử lý các điều kiện bất kỳ.

Vì vậy mà BitVM3 tồn tại ngay trong phần thiết kế. Cũng theo tài liệu đó, nó tổng quát hóa ý tưởng này để đối phó với mọi bằng chứng về trạng thái ngoài chuỗi (off-chain), không chỉ một trigger được mã cứng, đồng thời loại bỏ nhu cầu để một bên đối tác phải luôn online.

Tôi đã ngồi suy nghĩ một lúc về trình tự của phần giải thích đó. Hầu hết các phiên bản TBV đều dẫn thẳng đến cơ chế hoàn chỉnh. Whitepaper đi qua phiên bản đơn giản, chỉ ra nơi nó đạt đến giới hạn, rồi sau đó giới thiệu bản sửa thật sự.

Hầu hết các bản tóm tắt đều nhảy thẳng tới BitVM3. Gần như không có bản nào đề cập tới việc trước đó điều gì phải bị bỏ lại. Với tôi, thứ tự đó vẫn là phần “thành thật” nhất trong thiết kế.

@BabylonLabs_io #baby $BABY