Khi tôi nghiên cứu kiến trúc truyền thông cross-chain của Babylon, tôi nhận thấy họ đã dùng một biến thể của giao thức IBC để đồng bộ state.
Cụ thể, Babylon không trực tiếp sửa đổi lớp consensus của Bitcoin; thay vào đó, họ xây dựng một lớp light client ngay trên Bitcoin. Lớp light client này có nhiệm vụ lắng nghe các block header của Bitcoin, xác minh Merkle proof của giao dịch checkpoint, rồi truyền (relay) kết quả xác minh đến chuỗi PoS phía dưới.
Thiết kế này mang lại lợi ích về tính module (modularity): Bitcoin không cần thay đổi gì cả; toàn bộ công việc thích nghi đều được hoàn thành ở tầng giao thức của Babylon.
Tuy nhiên, tôi cho rằng độ khó kỹ thuật thực sự nằm ở việc xử lý “finality” mang tính xác suất của Bitcoin. Finality của Bitcoin là probabilistic: sau khi một block được xác nhận, về lý thuyết vẫn có khả năng bị reorg. Cách làm của Babylon là đợi một số lượng confirmation nhất định (ví dụ 6 block) rồi mới coi checkpoint là final.
Việc chọn “confirmation number” là một sự đánh đổi điển hình giữa bảo mật và độ trễ (security-latency trade-off): đợi càng nhiều confirmation thì an toàn hơn, nhưng độ trễ finality cũng dài hơn.
Hiện tại, các tham số Babylon chọn có vẻ khá thận trọng (conservative). Theo quan điểm cá nhân tôi, ở giai đoạn đầu đây là lựa chọn đúng đắn—thà chậm hơn một chút còn hơn là bị reorg dẫn đến sự kiện slash.
Một điểm khác đáng chú ý là tính atomicity của việc truyền message cross-chain. Babylon cần đảm bảo rằng hai sự kiện—checkpoint được xác nhận trên Bitcoin và checkpoint được thực thi trên chuỗi PoS—phải là atomic. Họ sử dụng một biến thể của giao thức two-phase commit: trước tiên là prepare rồi mới commit; nếu thất bại ở bất kỳ giai đoạn nào thì sẽ rollback.
Thiết kế này trong lĩnh vực hệ phân tán đã rất trưởng thành, nhưng khi áp dụng vào bối cảnh crypto cross-chain, vẫn cần cân nhắc các cam kết về “liveness guarantee” trong điều kiện cực đoan (extreme condition).
$BABY #baby @BabylonLabs_io
Cụ thể, Babylon không trực tiếp sửa đổi lớp consensus của Bitcoin; thay vào đó, họ xây dựng một lớp light client ngay trên Bitcoin. Lớp light client này có nhiệm vụ lắng nghe các block header của Bitcoin, xác minh Merkle proof của giao dịch checkpoint, rồi truyền (relay) kết quả xác minh đến chuỗi PoS phía dưới.
Thiết kế này mang lại lợi ích về tính module (modularity): Bitcoin không cần thay đổi gì cả; toàn bộ công việc thích nghi đều được hoàn thành ở tầng giao thức của Babylon.
Tuy nhiên, tôi cho rằng độ khó kỹ thuật thực sự nằm ở việc xử lý “finality” mang tính xác suất của Bitcoin. Finality của Bitcoin là probabilistic: sau khi một block được xác nhận, về lý thuyết vẫn có khả năng bị reorg. Cách làm của Babylon là đợi một số lượng confirmation nhất định (ví dụ 6 block) rồi mới coi checkpoint là final.
Việc chọn “confirmation number” là một sự đánh đổi điển hình giữa bảo mật và độ trễ (security-latency trade-off): đợi càng nhiều confirmation thì an toàn hơn, nhưng độ trễ finality cũng dài hơn.
Hiện tại, các tham số Babylon chọn có vẻ khá thận trọng (conservative). Theo quan điểm cá nhân tôi, ở giai đoạn đầu đây là lựa chọn đúng đắn—thà chậm hơn một chút còn hơn là bị reorg dẫn đến sự kiện slash.
Một điểm khác đáng chú ý là tính atomicity của việc truyền message cross-chain. Babylon cần đảm bảo rằng hai sự kiện—checkpoint được xác nhận trên Bitcoin và checkpoint được thực thi trên chuỗi PoS—phải là atomic. Họ sử dụng một biến thể của giao thức two-phase commit: trước tiên là prepare rồi mới commit; nếu thất bại ở bất kỳ giai đoạn nào thì sẽ rollback.
Thiết kế này trong lĩnh vực hệ phân tán đã rất trưởng thành, nhưng khi áp dụng vào bối cảnh crypto cross-chain, vẫn cần cân nhắc các cam kết về “liveness guarantee” trong điều kiện cực đoan (extreme condition).
$BABY #baby @BabylonLabs_io