Bị bỏ lỡ một khung nhận phần thưởng co-staking tháng trước chỉ vì chậm 6 giờ. Thậm chí tôi còn không biết nó tồn tại cho đến khi đã quá hạn — tôi chỉ thấy khoản chi trả nhỏ hơn dự kiến và bắt đầu tìm hiểu.

Đây là những gì tôi phát hiện: Các nhà cung cấp Finality Providers của Babylon không thể xoay (rotate) khóa của họ. Khi một FP đăng ký khóa EOTS và khóa Genesis, danh tính đó là vĩnh viễn — không thể thay thế một khóa bị xâm phạm như bạn vẫn thường làm trên đa số mạng validator. Điều này gắn trực tiếp với thiết kế cắt phạt (slashing): nếu một nhà cung cấp ký hai lần (double-signs), cơ chế EOTS có thể lộ ra phần dữ liệu khóa cần thiết để cắt phạt họ. Danh tính vĩnh viễn chính là thứ khiến mối đe dọa trở nên hiện thực.

Tôi đã từng nghĩ rằng việc xoay khóa chỉ là thông lệ vệ sinh vận hành tiêu chuẩn ở mọi nơi. Nhưng ở đây lại ngược lại — giao thức cố tình loại bỏ sự linh hoạt đó để việc chịu trách nhiệm không thể được “reset” một cách âm thầm.

Vậy nên rủi ro thực sự đối với một FP không nằm ở mã hoá (cryptography), mà là khả năng tồn tại trong nhiều năm trước các sự cố phần cứng, thay đổi nhân sự, và các lần di chuyển hạ tầng mà không bao giờ phải đụng tới đúng một khóa đó.

Bạn sẽ uỷ quyền cho một nhà cung cấp vận hành dựa trên một khóa vĩnh viễn duy nhất trong nhiều năm, hay cấu hình đó khiến bạn muốn có bằng chứng về kế hoạch sao lưu/backup vận hành của họ trước?

@BabylonLabs_io $BABY #baby $BULLA $ON
Hầu hết các validator: xoay khóa khi bị xâm phạm. Babylon FPs: bị mắc kẹt với một khóa, mãi mãi. Bạn tin cách nào hơn?