BTC
ETH
HTX
SOL
BNB
Xem thị trường
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Trình xác thực chuỗi Beacon: Rủi ro dự phòng và chuyển đổi dự phòng

以太坊爱好者
特邀专栏作者
Bài viết này có khoảng 2694 từ, đọc toàn bộ bài viết mất khoảng 4 phút
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.
Tóm tắt AI
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.

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:

Sự thất vọng về phần thưởng: Khi người xác thực không thực hiện khi được giao một nhiệm vụ, TA không thể nhận được phần thưởng tương ứng với nhiệm vụ đó. Vốn chủ sở hữu của người xác thực (tiền gốc) sẽ không giảm mà chỉ mất cơ hội nhận phần thưởng.Hình phạt làm chậm: Nếu người xác minh không gửi thông báo nhân chứng và chuỗi đèn hiệu không thể hoàn thành khối 2 tại thời điểm đó, vốn chủ sở hữu của người xác minh sẽ bị giảm một lượng nhỏ (tất nhiên, sẽ không nhận được phần thưởng liên quan).Chém hình phạt: Nếu người xác thực gửi thông báo nhân chứng vi phạm các quy tắc của Casper FFG, thì người xác nhận sẽ bị cắt ngay lập tức - vốn chủ sở hữu của người xác nhận sẽ bị giảm theo một tỷ lệ nhất định 3 và người xác thực sẽ bị loại và không thể sử dụng lại Tham gia vào sự đồng thuận (và do đó cũng bị cắt khỏi phần thưởng trong tương lai). Ngoài ra, vì beacon chain không thể chuyển và lấy ETH đã cam kết, nên tất cả số tiền còn lại của người xác minh sẽ bị khóa trên beacon chain và không thể sử dụng được (cho đến khi beacon chain kích hoạt các chức năng liên quan).

(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ừa

Mộ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 VC

Lư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:

Các Nút chuỗi Beacon (BN) được đồng bộ hóa hoàn toàn để lấy thông tin về Chuỗi BeaconNgười xác minh ký khóa riêng để thực sự ký tin nhắnChém kịp thời bảo vệ cơ sở dữ liệu dưới dạng dự phòng

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ý:

Lỗi BN - sau đó chuyển sang BN dự phòng

Tệp khóa trình xác thực bị thiếu - được sao chép từ tệp khóa sao lưu lưu trữ lạnhMất cơ sở dữ liệu được bảo vệ bằng dấu gạch chéo - xây dựng lại cơ sở dữ liệu hoặc khôi phục từ bản sao lưu trực tiếphttps://youtu.be/awBX1SrXOhk。trình xác minh tách khóa(nghĩa là: cách chính xác để triển khai cơ sở xác thực có khả năng phục hồi)Cơ sở hạ tầng phục hồi tối ưu yêu cầu các kỹ thuật tách khóa -- đó là một bài viết khác. Thông tin thêm có thể được tìm thấy trong video nói chuyện này:
ETH
开发者
Chào mừng tham gia cộng đồng chính thức của Odaily
Nhóm đăng ký:
https://t.me/Odaily_News
Nhóm trò chuyện:
https://t.me/Odaily_GoldenApe
Tài khoản chính thức:
https://twitter.com/OdailyChina
Mục lục bài viết
Thư viện tác giả
Tải ứng dụng Odaily Nhật Báo Hành Tinh
Hãy để một số người hiểu Web3.0 trước
IOS
Android