Tối qua tôi lật sổ tay TBV của BabylonLabs, đọc đến đoạn xác thực bằng ZK proof của phần withdrawal thì tôi dừng lại. Tôi vẽ lại toàn bộ đường đi xác minh, rồi mới phát hiện trước đó mình nghĩ vấn đề quá đơn giản.@BabylonLabs_io
Tôi vẫn luôn băn khoăn: vì sao không để mainchain Bitcoin trực tiếp hiểu sự thay đổi trạng thái của một giao thức bên ngoài? Câu trả lời nằm ở ranh giới xác minh. Thiết kế script của Bitcoin vốn dĩ không phải để xử lý trạng thái bên ngoài; nếu bắt nó xử lý ngược lại sẽ làm thay đổi logic xác minh ban đầu. Vì vậy TBV đi một con đường thận trọng hơn. Giao thức bên ngoài tạo ra kết quả, thông qua cơ chế chứng minh chuyển thành điều kiện chi tiêu (spending conditions) mà Bitcoin có thể tự xác thực; Bitcoin chỉ cần kiểm tra xem các điều kiện được gửi lên có hợp lệ theo quy tắc hay không.
Trong whitepaper chính thức, họ nhấn đi nhấn lại chữ "Translation"; theo cách hiểu của tôi, tức là chuyển đổi trạng thái bên ngoài thành các điều kiện niềm tin mà Bitcoin có thể xác minh. Kết quả tính toán của giao thức bên ngoài bị ràng buộc bởi chứng minh; Bitcoin chịu trách nhiệm xác minh. Hai bên được nối với nhau bằng chứng minh mật mã, và từ đầu đến cuối không dùng chung một nguồn niềm tin. Đây cũng chính là logic thiết kế cốt lõi nhất của TBV.
Nhưng tối thiểu hóa niềm tin không đồng nghĩa với việc không có rủi ro. Light client của Babylon chỉ đồng bộ header khối và xác minh các chứng minh Merkle; nếu mạng Bitcoin xảy ra reorg, các giao dịch gửi tiền trong các khối bị cô lập sẽ bị rollback, trong khi tài sản trên chuỗi hợp đồng có thể đã được đúc sẵn trước đó. Một tổ chức kiểm toán an ninh đã mô phỏng một tình huống: sau khi chuỗi Babylon tắt máy rồi khởi động lại, light client vẫn nhận ở độ cao cũ; sau đó một nhóm mining độc hại có thể gửi một nhánh fork giả mạo để vượt qua xác minh. Đây là ràng buộc mang tính chất vật lý của mô hình light client, không phải là lỗ hổng ở tầng code.
Để giải quyết vấn đề này, cơ chế quản trị $BABY được đưa vào: người nắm giữ token sẽ bỏ phiếu để quyết định số khối cần xác nhận. Những điều đó thực chất là lựa chọn khẩu vị rủi ro, không phải kiểu hard-code về mặt kỹ thuật.
Nói tóm lại, điểm đáng chú ý thật sự của TBV không nằm ở việc nó kết nối được bao nhiêu kịch bản, mà ở chỗ trong điều kiện không làm thay đổi mô hình an ninh của Bitcoin, nó có thể giúp BTC tham gia vào những logic tài chính phức tạp đến mức nào. Điều BABY đáng theo dõi, có lẽ không nằm ở việc nó đã gắn được bao nhiêu ứng dụng, mà ở cách phối hợp giữa quy tắc xác minh và phép tính bên ngoài: liệu rốt cuộc có thể mở ra những khả năng mới hay không.#baby
Tôi vẫn luôn băn khoăn: vì sao không để mainchain Bitcoin trực tiếp hiểu sự thay đổi trạng thái của một giao thức bên ngoài? Câu trả lời nằm ở ranh giới xác minh. Thiết kế script của Bitcoin vốn dĩ không phải để xử lý trạng thái bên ngoài; nếu bắt nó xử lý ngược lại sẽ làm thay đổi logic xác minh ban đầu. Vì vậy TBV đi một con đường thận trọng hơn. Giao thức bên ngoài tạo ra kết quả, thông qua cơ chế chứng minh chuyển thành điều kiện chi tiêu (spending conditions) mà Bitcoin có thể tự xác thực; Bitcoin chỉ cần kiểm tra xem các điều kiện được gửi lên có hợp lệ theo quy tắc hay không.
Trong whitepaper chính thức, họ nhấn đi nhấn lại chữ "Translation"; theo cách hiểu của tôi, tức là chuyển đổi trạng thái bên ngoài thành các điều kiện niềm tin mà Bitcoin có thể xác minh. Kết quả tính toán của giao thức bên ngoài bị ràng buộc bởi chứng minh; Bitcoin chịu trách nhiệm xác minh. Hai bên được nối với nhau bằng chứng minh mật mã, và từ đầu đến cuối không dùng chung một nguồn niềm tin. Đây cũng chính là logic thiết kế cốt lõi nhất của TBV.
Nhưng tối thiểu hóa niềm tin không đồng nghĩa với việc không có rủi ro. Light client của Babylon chỉ đồng bộ header khối và xác minh các chứng minh Merkle; nếu mạng Bitcoin xảy ra reorg, các giao dịch gửi tiền trong các khối bị cô lập sẽ bị rollback, trong khi tài sản trên chuỗi hợp đồng có thể đã được đúc sẵn trước đó. Một tổ chức kiểm toán an ninh đã mô phỏng một tình huống: sau khi chuỗi Babylon tắt máy rồi khởi động lại, light client vẫn nhận ở độ cao cũ; sau đó một nhóm mining độc hại có thể gửi một nhánh fork giả mạo để vượt qua xác minh. Đây là ràng buộc mang tính chất vật lý của mô hình light client, không phải là lỗ hổng ở tầng code.
Để giải quyết vấn đề này, cơ chế quản trị $BABY được đưa vào: người nắm giữ token sẽ bỏ phiếu để quyết định số khối cần xác nhận. Những điều đó thực chất là lựa chọn khẩu vị rủi ro, không phải kiểu hard-code về mặt kỹ thuật.
Nói tóm lại, điểm đáng chú ý thật sự của TBV không nằm ở việc nó kết nối được bao nhiêu kịch bản, mà ở chỗ trong điều kiện không làm thay đổi mô hình an ninh của Bitcoin, nó có thể giúp BTC tham gia vào những logic tài chính phức tạp đến mức nào. Điều BABY đáng theo dõi, có lẽ không nằm ở việc nó đã gắn được bao nhiêu ứng dụng, mà ở cách phối hợp giữa quy tắc xác minh và phép tính bên ngoài: liệu rốt cuộc có thể mở ra những khả năng mới hay không.#baby