Trình xác thực chuỗi Beacon: Rủi ro dự phòng và chuyển đổi dự phòng
Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Những người đam mê Ethereum (ID: ethfans)
Những người đam mê Ethereum (ID: ethfans)
, Tác giả: Aditya Asgaonkar, bản dịch: A Jian, được ủy quyền in lại bởi Odaily.
tiêu đề cấp đầu tiên
Trình xác thực và ứng dụng khách của Trình xác thực
Người xác minh là một khái niệm liên quan đến chuỗi đèn hiệu và người xác minh là người tham gia vào quá trình đồng thuận của chuỗi đèn hiệu. Trình xác minh được xác định bằng các khóa công khai và mỗi trình xác minh sẽ được giao nhiệm vụ xác minh chuỗi đèn hiệu vào các thời điểm khác nhau. Nếu hoàn thành xuất sắc các nhiệm vụ này thì sẽ được khen thưởng, ngược lại nếu chểnh mảng nhiệm vụ thì không những không được khen thưởng mà còn bị nghiêm trị. Trong Giai đoạn 0, những cáo buộc này chỉ giới hạn trong việc đề xuất các khối và gửi chứng thực trên chuỗi đèn hiệu.
Người xác thực cần sử dụng một phần mềm được gọi là ứng dụng khách của người xác thực (VC) để thực hiện nhiệm vụ của mình1. Tất cả các nhóm khách hàng của chuỗi đèn hiệu đều sử dụng VC làm một trong các gói phần mềm máy khách của họ.
- Không cần phải nói, những người xác nhận muốn khách hàng của họ trực tuyến 24/7 để họ có thể thu được lợi ích tối đa và tránh mọi hình phạt. Một cách phổ biến để đạt được tính sẵn sàng cao là thiết lập các cơ chế dự phòng và chuyển đổi dự phòng. Bài viết này giải thích sự nguy hiểm của dự phòng đối với trình xác thực và đề xuất chuyển đổi dự phòng hợp lý cho các VC trong chuỗi đèn hiệu.
- Loại thua/phạt
- Trình xác thực phải đối mặt với ba loại tổn thất, theo thứ tự mức độ nghiêm trọng tăng dần:
(Ghi chú của người dịch: Tác giả đã bỏ qua một mất mát ở đây: khi chuỗi đèn hiệu không thể đạt được mục đích cuối cùng, không chỉ những người xác minh không gửi tin nhắn nhân chứng sẽ bị trừng phạt vì chậm trễ, mà những người làm chứng đã gửi tin nhắn cũng sẽ bị thiệt hại. , nhưng tổn thất nhỏ hơn so với trước đây, tuy nhiên trong bài viết này tác giả chủ yếu bàn về tổn thất liên quan đến offline của verifier nên cũng có thể hiểu được.)
Hai loại tổn thất đầu tiên có thể xảy ra với những người xác thực có VC đang ngoại tuyến, nhưng loại thứ ba, chỉ những người xác thực đã thiết lập VC không chính xác gặp phải (hoặc khi chuỗi báo hiệu bị tấn công rõ ràng).Sự nguy hiểm của các cơ sở VC dư thừaMột số người đặt cược có thể tin rằng việc chạy các VC dự phòng là bảo hiểm chống lại một VC ngoại tuyến. Nhưng trên thực tế, các cơ sở VC dư thừa không an toàn và rất có khả năng những người xác nhận cuối cùng sẽ bị phạt!
Hãy xem một ví dụ thực tế:Mô tả hình ảnh
- VC thừa dẫn ra chém! -Giao thức chuyển đổi dự phòng của VCLưu ý: Khi tôi nói "chuyển đổi dự phòng", ý tôi là khởi động lại phiên bản VC mới theo cách thủ công hoặc tự động sau khi một VC bị dừng, tuy nhiên, tôi không khuyên bạn nên sử dụng cơ chế chuyển đổi dự phòng tự động, vì nếu triển khai kém, nó có thể khiến bạn có hai VC treo trên dây!
Điểm rút ra từ phần trước là các trình xác thực chỉ nên triển khai một phiên bản VC trực tiếp tại một thời điểm. Tuy nhiên, các VC luôn mắc sai lầm, làm thế nào để đối phó với rủi ro này? Người đặt cược nên xác định trước giao thức chuyển đổi dự phòng của riêng họ (xác định mục đích sử dụng sẽ khởi động lại phiên bản máy khách trình xác thực mới) trước để xử lý tình huống này. Trước khi phát triển một giao thức chuyển đổi dự phòng an toàn và đáng tin cậy, trước tiên chúng ta hãy xem xét một tính năng bảo mật được tích hợp trong các ứng dụng khách của trình xác thực: bảo vệ cắt giảm.Mô tả hình ảnh- - Cơ chế chống sét -
- Cơ chế bảo vệ dấu gạch chéo: Tất cả phần mềm VC do nhóm khách hàng beacon chain phát triển đều có cơ chế bảo vệ dấu gạch chéo như một thiết bị tự động an toàn cho các sự kiện không mong muốn. Theo quy định gạch chéo, chỉ có các cặp thông báo chứng thực mới bị gạch chéo, chỉ cần kiểm tra cặp thông báo này để phán đoán kết quả. Sau đó, VC có thể lưu trữ tất cả các thông báo và khối do chính nó ký trong cơ sở dữ liệu bảo vệ dấu gạch chéo cục bộ. Khi ký bất kỳ thông báo/khối chứng thực mới nào, VC chỉ cần kiểm tra xem thông báo mới có xung đột với thông báo cũ trong cơ sở dữ liệu hay không (liệu nó có tạo thành một cặp thông báo gạch chéo hay không) và chỉ ký thông báo mới không xung đột.
- Do đó, VC cần ba cơ chế để đảm bảo hoạt động chính xác và an toàn:
Một giao thức chuyển đổi dự phòng tốt phải tính đến lỗi của một trong hai cơ chế. Hai điều đầu tiên rất dễ đảm bảo - một BN dự phòng có thể được duy trì cho các kết nối VC mới và khóa ký cũng có thể được sao chép từ thư mục sao lưu dưới dạng tệp chỉ đọc.
Lưu ý: Thẻ SD không phải là thiết bị lưu trữ đáng tin cậy, vì vậy những người đặt cọc chạy VC trên Raspberry Pi đặc biệt dễ bị mất cơ sở dữ liệu được bảo vệ bằng dấu gạch chéo!Giải pháp chuyển đổi dự phòng được đề xuất của tôi
Một giải pháp đơn giản nhưng hữu ích là duy trì một BN dự phòng và đảm bảo rằng các khóa xác minh dự phòng có thể truy cập dễ dàng.- Mô tả hình ảnh
- - Cài đặt VC ban đầu và các giao thức chuyển đổi dự phòng đa kịch bản -
- Trong cài đặt này, nhiều lỗi có phân phối tương ứng với sơ đồ xử lý:


