Ban đầu tôi cho rằng thứ duy nhất có thể khiến một Finality Provider mất vị thế của mình chỉ có thể là hành vi độc ác trắng trợn: ký hai khối xung đột, bị bắt quả tang, bị phạt cắt (slashed) — kiểu phân đôi “trung thực hay gian dối” kinh điển. Khi đọc tài liệu về module Finality của Babylon, tôi nhận ra có một đường hỏng hóc thứ hai, yên lặng hơn, hoàn toàn không liên quan gì đến sự trung thực. Trước khi một Finality Provider thậm chí có thể bỏ phiếu cho một khối, họ phải chủ động cam kết nguồn ngẫu nhiên công khai của EOTS cho đúng cao độ (future height) trong tương lai đó — trước khi khối được đề xuất, và làm trước từ trước. Hệ thống của Babylon theo dõi riêng hai nhóm nhà cung cấp gặp vấn đề: những kẻ gian dối bằng cách tạo bản nháp (equivocating) rồi bị phát hiện vì ký các thông điệp xung đột, và những kẻ chậm chạp (sluggish) chỉ đơn giản là không xuất hiện kịp thời. Chậm không phải là cùng một vi phạm như gian dối, nhưng nó vẫn được ghi nhận và bị trừng phạt như một nhóm riêng. Điều này có nghĩa trong thực tế là một nhà cung cấp có thể hoàn toàn trung thực: không bao giờ ký bất cứ thứ gì xung đột, không hề thực hiện hành động mang tính đối kháng, và vẫn có thể mất khả năng bỏ phiếu cho một height nhất định chỉ vì cam kết ngẫu nhiên của họ không theo kịp “đầu mút” (tip) của chuỗi. Việc cam kết ngẫu nhiên không phải là một bước thiết lập một lần; đó là một công việc dự báo liên tục, luôn bám trước một chuỗi luôn tiến lên cho dù bạn đã sẵn sàng hay chưa. Vì vậy, mô hình bảo mật thực sự đang được mô tả không chỉ là “trung thực so với độc ác”. Mà là “trung thực-và-đúng giờ” so với tất cả những người còn lại, bao gồm cả các nhà cung cấp trung thực nhưng chỉ vì tụt lại phía sau một yêu cầu lịch trình mà phần lớn người đang staking tới họ có lẽ cũng chẳng bao giờ nghĩ đến việc tự kiểm tra.
@BabylonLabs_io #baby $BABY