#baby $BABY Làm thế nào để “slash” (phạt) một validator trên Bitcoin khi Bitcoin không có cơ chế slashing tích hợp sẵn?
Mình mất lâu hơn dự kiến mới thật sự hiểu vấn đề này, vì câu trả lời không phải là một smart contract mà là một sơ đồ chữ ký thực hiện điều gì đó khéo léo bằng toán học thay vì bằng code.
@BabylonLabs_io sử dụng cái được gọi là Chữ ký Một lần Có thể Trích xuất (Extractable One-Time Signature - EOTS), được xây dựng dựa trên chữ ký Schnorr gốc của Bitcoin. Mấu chốt ở đây: một nhà cung cấp finality tạo ra một cặp khóa duy nhất cho mỗi độ cao (block height) mà họ bỏ phiếu. Miễn là họ chỉ bao giờ ký đúng một khối cho mỗi độ cao, chữ ký sẽ an toàn hoàn toàn và không bị rò rỉ. Nhưng nếu họ ký hai khối xung đột tại cùng một độ cao, thì phần toán học sẽ “vỡ ra”. Việc tái sử dụng khóa theo từng độ cao đó để ký hai thông điệp khác nhau sẽ lộ trực tiếp khóa riêng của họ, bởi vì cách toán chữ ký Schnorr hoạt động khi nonce bị tái sử dụng.
Bản thân vòng finality yêu cầu chữ ký từ hơn hai phần ba tổng trọng lượng BTC được stake để một khối có thể được finalizing thực sự; vì vậy, bất kỳ vi phạm an toàn nào, theo định nghĩa, sẽ đòi hỏi hơn một phần ba số stake đã double-sign. Chính điều đó làm cho cam kết “fully slashable” (có thể phạt hoàn toàn) được đảm bảo bằng mặt toán học chứ không phải lời hứa chính sách: một khi khóa bị rò rỉ, bất kỳ ai—không chỉ Babylon, không chỉ validator—cũng có thể tự xây dựng và phát giao dịch slashing. Ở giai đoạn đó không cần biểu quyết của ủy ban, không có quy trình khiếu nại, chỉ là “toán lộ ra”.
Điều mình chưa thấy có câu trả lời rõ ràng: việc tạo khóa cho từng độ cao block có tạo ra gánh nặng vận hành đáng kể cho các nhà cung cấp finality khi chạy đồng thời trên nhiều BSN không, và liệu chính gánh nặng đó có thể trở thành bề mặt tấn công không—ví dụ nếu một nhà cung cấp đang quá tải mà vô tình tái sử dụng ngẫu nhiên/ randomness thay vì cố ý?
Bảo mật của EOTS chỉ thuần túy là một bảo đảm bằng toán học, hay nó còn “ngầm” phụ thuộc vào việc các nhà cung cấp finality có hạ tầng quản lý khóa (key-management) vững chắc hay không?
$BABY
Mình mất lâu hơn dự kiến mới thật sự hiểu vấn đề này, vì câu trả lời không phải là một smart contract mà là một sơ đồ chữ ký thực hiện điều gì đó khéo léo bằng toán học thay vì bằng code.
@BabylonLabs_io sử dụng cái được gọi là Chữ ký Một lần Có thể Trích xuất (Extractable One-Time Signature - EOTS), được xây dựng dựa trên chữ ký Schnorr gốc của Bitcoin. Mấu chốt ở đây: một nhà cung cấp finality tạo ra một cặp khóa duy nhất cho mỗi độ cao (block height) mà họ bỏ phiếu. Miễn là họ chỉ bao giờ ký đúng một khối cho mỗi độ cao, chữ ký sẽ an toàn hoàn toàn và không bị rò rỉ. Nhưng nếu họ ký hai khối xung đột tại cùng một độ cao, thì phần toán học sẽ “vỡ ra”. Việc tái sử dụng khóa theo từng độ cao đó để ký hai thông điệp khác nhau sẽ lộ trực tiếp khóa riêng của họ, bởi vì cách toán chữ ký Schnorr hoạt động khi nonce bị tái sử dụng.
Bản thân vòng finality yêu cầu chữ ký từ hơn hai phần ba tổng trọng lượng BTC được stake để một khối có thể được finalizing thực sự; vì vậy, bất kỳ vi phạm an toàn nào, theo định nghĩa, sẽ đòi hỏi hơn một phần ba số stake đã double-sign. Chính điều đó làm cho cam kết “fully slashable” (có thể phạt hoàn toàn) được đảm bảo bằng mặt toán học chứ không phải lời hứa chính sách: một khi khóa bị rò rỉ, bất kỳ ai—không chỉ Babylon, không chỉ validator—cũng có thể tự xây dựng và phát giao dịch slashing. Ở giai đoạn đó không cần biểu quyết của ủy ban, không có quy trình khiếu nại, chỉ là “toán lộ ra”.
Điều mình chưa thấy có câu trả lời rõ ràng: việc tạo khóa cho từng độ cao block có tạo ra gánh nặng vận hành đáng kể cho các nhà cung cấp finality khi chạy đồng thời trên nhiều BSN không, và liệu chính gánh nặng đó có thể trở thành bề mặt tấn công không—ví dụ nếu một nhà cung cấp đang quá tải mà vô tình tái sử dụng ngẫu nhiên/ randomness thay vì cố ý?
Bảo mật của EOTS chỉ thuần túy là một bảo đảm bằng toán học, hay nó còn “ngầm” phụ thuộc vào việc các nhà cung cấp finality có hạ tầng quản lý khóa (key-management) vững chắc hay không?
$BABY