Nói về nút Babylon, nhiều người nghĩ rằng chạy Vigilante (Sentinel) thì nhất định phải kèm một nút Bitcoin full node đầy đủ, nếu không thì không chơi được. Lúc đầu tôi cũng nghĩ vậy. Sau đó lật tài liệu chính thức mới thấy tầng Sentinel thực ra có thể chạy ở chế độ light client, tiết kiệm dung lượng đĩa, nhưng khả năng tự xác minh sẽ bị giảm.
Module BTC Light Client của Babylon không lưu toàn bộ khối, mà chỉ đồng bộ chuỗi block header. Light client dùng SPV (xác minh giao dịch đơn giản) để kiểm tra nhánh Merkle, từ đó xác nhận được độ cao hiện tại của mainnet và chuỗi header có liên tục hay không. Sentinel làm hai việc: giám sát xem Finality Provider có tạo ra khối bị double-sign hay không; nếu phát hiện hành vi gian lận thì dùng EOTS hai chữ ký để suy ra khóa riêng, rồi phát tán giao dịch phạt. Việc suy ra khóa riêng là tính toán thuần mật mã, không phụ thuộc vào lịch sử của full node, nên light client cũng làm được. Nhưng nó không thể tự mình xác minh “một UTXO nào đó có thật sự được khóa vào script của Babylon hay không” — chuyện này cần full node hoặc indexer phối hợp; light client chỉ tin vào chuỗi header.
Hướng dẫn cài đặt Vigilante trong tài liệu chính thức yêu cầu “một synced Bitcoin full node”. Nhưng trong thực tế, dùng Bitcoin Core ở chế độ nhẹ (prune=1) chạy cùng với script của sentinel qua thử nghiệm, sau khi khóa 0.05 testnet BTC thì sentinel đã báo FP skip chữ ký một lần, nhưng không bị bỏ sót.
Nếu mainnet xuất hiện deep reorg ( >6 khối), light client có thể tạm thời hiểu sai vị trí theo timestamp; còn full node sẽ nhận ra trước. Light client tiết kiệm dung lượng (khoảng 80MB/năm), đổi lại khi nguồn header bị ô nhiễm thì có thể bị dẫn đi. Cá nhân chạy sentinel bằng light client là đủ dùng, với điều kiện tin vào nguồn header mà mình chọn. Còn kiểu người cẩn thận thì chạy full node kèm indexer, tự xác minh mọi thứ.
Không phải lựa chọn một trong hai: đó là sự đánh đổi giữa chi phí và mức độ tự quản lý.
#baby $BABY @BabylonLabs_io
Module BTC Light Client của Babylon không lưu toàn bộ khối, mà chỉ đồng bộ chuỗi block header. Light client dùng SPV (xác minh giao dịch đơn giản) để kiểm tra nhánh Merkle, từ đó xác nhận được độ cao hiện tại của mainnet và chuỗi header có liên tục hay không. Sentinel làm hai việc: giám sát xem Finality Provider có tạo ra khối bị double-sign hay không; nếu phát hiện hành vi gian lận thì dùng EOTS hai chữ ký để suy ra khóa riêng, rồi phát tán giao dịch phạt. Việc suy ra khóa riêng là tính toán thuần mật mã, không phụ thuộc vào lịch sử của full node, nên light client cũng làm được. Nhưng nó không thể tự mình xác minh “một UTXO nào đó có thật sự được khóa vào script của Babylon hay không” — chuyện này cần full node hoặc indexer phối hợp; light client chỉ tin vào chuỗi header.
Hướng dẫn cài đặt Vigilante trong tài liệu chính thức yêu cầu “một synced Bitcoin full node”. Nhưng trong thực tế, dùng Bitcoin Core ở chế độ nhẹ (prune=1) chạy cùng với script của sentinel qua thử nghiệm, sau khi khóa 0.05 testnet BTC thì sentinel đã báo FP skip chữ ký một lần, nhưng không bị bỏ sót.
Nếu mainnet xuất hiện deep reorg ( >6 khối), light client có thể tạm thời hiểu sai vị trí theo timestamp; còn full node sẽ nhận ra trước. Light client tiết kiệm dung lượng (khoảng 80MB/năm), đổi lại khi nguồn header bị ô nhiễm thì có thể bị dẫn đi. Cá nhân chạy sentinel bằng light client là đủ dùng, với điều kiện tin vào nguồn header mà mình chọn. Còn kiểu người cẩn thận thì chạy full node kèm indexer, tự xác minh mọi thứ.
Không phải lựa chọn một trong hai: đó là sự đánh đổi giữa chi phí và mức độ tự quản lý.
#baby $BABY @BabylonLabs_io