Một bài viết để hiểu toàn bộ câu chuyện về sự kiện "sụp đổ" của testnet Medalla

nguồn|What’s New in Eth2

Tác giả|Ben Edgington

nguồn|Tác giả|Ben Edgington

Lưu ý của người dịch: Người dùng đang chạy ứng dụng khách Prysm nên nâng cấp lên

Vấn đề này là một bản cập nhật nằm ngoài kế hoạch của wnie2 và sẽ xem xét và phân tích các đợt xảy ra trên mạng thử nghiệm Eth2 Medalla vào cuối tuần qua.Kỳ trước。

Chúng tôi đã ra mắt Medalla gần hai tuần trước, ngày 4 tháng 8, với tư cách là một mạng thử nghiệm lớn, công khai, nhiều khách hàng chạy thông số mạng chính Eth2. Để biết giới thiệu về testnet Medalla, vui lòng tham khảo

Kỳ trước

Tuy nhiên, vào tối thứ Sáu, tôi đã thấy tỷ lệ tham gia của trình xác thực giảm xuống một vực trong bảng điều khiển. Trong vòng vài phút, số lượng trình xác nhận đang hoạt động đã giảm từ 22.000 xuống còn khoảng 5.000 và khoảng 80% trình xác nhận trong mạng đã biến mất.

Do đó, bài viết này sẽ xem xét vụ việc, bao gồm cả hậu quả và các bước tiếp theo.

tiêu đề cấp đầu tiên

Chuyện gì đã xảy ra thế?Chúng tôi phát hiện ra rằng mọi trình xác nhận đang chạy ứng dụng khách Prysm trong mạng đột nhiên biến mất. Vì Prysm là ứng dụng khách được sử dụng nhiều nhất nên hậu quả có thể tưởng tượng được.Nhóm Prysmatic đã mở ra một

báo cáo tài liệuRoughtime, nơi các chi tiết sự cố và phản ứng của nhóm được cập nhật liên tục. Dưới đây là một số điểm nổi bật với ghi chú của tôi.

Nguyên nhân của sự kiện là sự cố đồng bộ hóa đồng hồ. Ứng dụng khách Prysm được định cấu hình bằng Cloudflare's

để đếm thời gian. Lý do cho điều này (theo ý kiến ​​​​của tôi) không rõ ràng lắm, nhưng rõ ràng là Roughtime đã chuyển thời gian sang tương lai bốn giờ và nó kéo dài hơn một giờ. Trình xác thực ứng dụng khách Prysm đột nhiên nhận thấy thời gian của họ nhanh hơn bốn giờ và tiếp tục tạo các khối và bằng chứng cho một chuỗi khối chưa tồn tại.

Tự nó, không đủ để trở thành thảm họa. Ngay cả khi nhiều khối bị mất và phải đối mặt với một lượng lớn bằng chứng từ tương lai, những khách hàng còn lại vẫn có thể xây dựng trên chuỗi ban đầu. Dần dần, khi đồng hồ của các nút Prysm được điều chỉnh trở lại, chúng bắt đầu quay trở lại mạng và sự tham gia của trình xác thực bắt đầu tăng lên. Mạng dường như đang trở lại bình thường.

Nhưng vài giờ sau, tình hình trở nên tồi tệ hơn.

Bốn giờ sau thời gian ban đầu, hai điều nữa đã xảy ra. Đầu tiên, bằng chứng được tạo bởi tất cả các máy khách Prysm trong tương lai bắt đầu có hiệu lực. Thứ hai, các nút Prysm tham gia lại mạng lại bắt đầu biến mất do cơ chế bảo vệ dấu gạch chéo được kích hoạt để ngăn chúng tạo ra bất kỳ bằng chứng mâu thuẫn nào.

Hai điều đó xảy ra cùng một lúc, khiến mạng rơi vào tình trạng hỗn loạn. Những khách hàng còn lại vẫn đang vật lộn để xử lý thông tin họ nhận được và chuỗi đèn hiệu trở thành một khu rừng phân nhánh. (Raul từ nhóm Prysmatic nói với tôi rằng một lỗi trong bản sửa lỗi đầu tiên của Prysm khiến mọi thứ trở nên tồi tệ hơn)

Trong một khoảng thời gian, thông tin trong mạng vẫn được kiểm soát. Nhưng trong khoảng 24 giờ tới, bộ nhớ và CPU cần thiết để điều hướng các nhánh rẽ ngày càng phức tạp và hỗn loạn đã trở nên quá tải. Tôi thấy một ứng dụng khách Lighthouse sử dụng bộ nhớ 30 GB (gấp khoảng 100 lần so với bình thường) và đối với ứng dụng khách Teku, ngay cả với một đống bộ nhớ Java 12 GB và tối đa hóa bộ xử lý, tôi vẫn gặp sự cố. Eth2StatsLưu ý rằng tất cả điều này xảy ra vào cuối tuần. Cảm ơn tất cả các nhóm khách hàng đang chiến đấu ở tuyến đầu. Để các nút có thể đối phó với mạng hỗn loạn, chúng cần liên tục tối ưu hóa bộ nhớ và hiệu quả.

Đến nay, hệ thống mạng đang dần khôi phục. Các báo cáo của người dùng đã bị trộn lẫn, nhưng các phiên bản mới hơn của Prysm và Lighthouse tình cờ có thể tìm thấy tiêu đề chuỗi chính xác và tiếp tục xây dựng chuỗi đèn hiệu.

Một số nút hiện đang hiển thị đầu chuỗi hoặc các nút Ngọn hải đăng, Prysm và Teku gần đó. Chúng tôi sẽ tiếp tục tối ưu hóa Teku để giảm tài nguyên mà nó cần để đồng bộ hóa.

Không có lỗi đồng thuận nào xảy ra

Một điều cần rõ ràng là không có sự thất bại đồng thuận giữa các khách hàng, nghĩa là khi mạng được khôi phục, tất cả các khách hàng có thể đạt được sự đồng thuận về trạng thái của người đứng đầu chuỗi, điều đó có nghĩa là chuỗi đèn hiệu sẽ không bị lỗi về cơ bản , nó cũng sẽ không thất bại. Bất kỳ hard fork nào đều được yêu cầu.

Bài học kinh nghiệm

Chúng tôi sẽ dành nhiều thời gian hơn để phản ánh và tóm tắt đầy đủ về tình tiết này, sau đây là một số ý kiến ​​cá nhân của tôi.Tầm quan trọng của đồng bộ hóa thời gian。

Sự phụ thuộc nhiều vào các dịch vụ thời gian của bên thứ ba là một điểm chết người đối với mạng. Khi điều đó xảy ra, Alex Vlasov của nhóm nghiên cứu ConsenSys TX/RX trước đây đã viết một bài viết chi tiết giải thích về đồng bộ hóa thời gian và tầm quan trọng của nó trong mạng Ethereum 2.0. Công việc của anh tiến triển nhanh chóng, có lẽ đây cũng là cơ hội để mọi người chú ý đến phương diện này. đây là của anh ấy

Bài viết liên quan và bài đăng trên ethresear.ch

Tầm quan trọng của sự đa dạng khách hàng

Lý tưởng nhất là chúng ta sẽ có bốn máy khách độc lập trở lên, với mỗi nút máy khách chiếm không quá 30% mạng. Bằng cách đó, ngay cả khi một khách hàng gặp sự cố, nó sẽ không đủ tác động để thu hút sự chú ý của chúng tôi.

Ngay cả khi chúng ta không thể đạt được lý tưởng này, thì việc giảm mức độ sử dụng quá mức của các máy khách cá nhân sẽ giúp mạng trở nên mạnh mẽ hơn. Giả sử lần này chỉ có 50% người xác nhận ngoại tuyến thay vì 80%, mạng sẽ phục hồi dễ dàng hơn. Điều này là do khi xảy ra sự cố với máy khách, nó sẽ ảnh hưởng đến quá trình tạo khối, đóng gói bằng chứng, hiệu quả phát sóng, liên lạc điểm-điểm và đồng bộ hóa của mạng và những yếu tố này cũng sẽ có tác động dây chuyền đến phần còn lại trình xác nhận.

Hiệu quả của các phương án dự phòngMột số người đặt cược có thể chuyển khóa ký sang các nút dự phòng nóng của khách hàng khác. Điều này chắc chắn tạo nên một mạng lưới bảo mật tuyệt vời, mặc dù người ta cần phải cẩn thận để tránh chặt chém: những người xác nhận mới có thể không biết gì về lịch sử bỏ phiếu của những người xác nhận hiện tại và do đó có thể bỏ phiếu ngược lại.Trong tương lai, một khi chúng ta đã hoàn thành

API mới

, sẽ cho phép khả năng chuyển đổi ứng dụng khách trình xác thực giữa các nút báo hiệu khác nhau, không chỉ các khóa. Ví dụ: trình xác thực Prysm có thể dễ dàng tách khỏi nút báo hiệu Prysm và kết nối lại với nút báo hiệu Teku. Điều này có thể giải quyết vấn đề chặt chém đã đề cập ở trên.

Ý thức trách nhiệm của các bên liên quan

Việc tham gia vào Eth2 không phải là việc "một lần là xong" vào lúc này. Người đặt cược cần duy trì một lượng chú ý nhất định, lang thang giữa các diễn đàn, cung cấp phản hồi cho nhà phát triển và có thể cập nhật ứng dụng khách trong thời gian ngắn. Tôi rất ủng hộ những người chạy trình xác nhận cá nhân của riêng họ, nhưng chỉ khi họ nhận thức được trách nhiệm của mình.

Sự vội vàng gây lãng phíTại sao mọi thứ luôn đi sai hướng vào tối thứ Sáu?Ngay cả tại thời điểm này, phản hồi từ nhóm Prysmatic vẫn rất tuyệt vời. Để biết chi tiết, vui lòng tham khảo nhóm của

báo cáo sự cố

. Những gì tôi nói dưới đây không nhằm mục đích tiêu cực hóa nhóm Prysmatic, những người đã làm rất tốt công việc của mình, mà là để cung cấp kinh nghiệm cho nhóm Teku khi gặp tình huống tương tự.

Khi rất nhiều người dùng đang mất tài sản (ngay cả khi đó chỉ là một đồng tiền thử nghiệm) và mạng đang chịu áp lực cao, thì việc muốn phản ứng nhanh là điều tự nhiên, nhưng sự vội vàng đôi khi có thể phản tác dụng.

Hai điều có thể tránh được trong sự cố này. Đầu tiên, có một lỗi trong bản phát hành sửa lỗi ban đầu Alpha.21 yêu cầu người dùng quay lại sau 17 giờ.

Theo Raul của nhóm Prysmatic, lỗ hổng này là nguyên nhân gây ra sự hỗn loạn mạng sau đó. Thứ hai, nhóm đã vô tình xóa cơ sở dữ liệu gồm các bản ghi chống gạch chéo của 1024 trình xác thực trong khi xử lý tình huống, dẫn đến phần lớn các trình xác nhận bị gạch chéo.

Những tình huống tương tự có thể xảy ra với bất kỳ khách hàng nào. Vì vậy, ngay cả khi chịu áp lực cao, tất cả chúng ta, dù là nhà phát triển hay người dùng, đều phải đối phó với nó một cách bình tĩnh và không theo đuổi tốc độ một cách mù quáng. Vì vậy, khi chúng tôi cố gắng khôi phục mạng, chúng tôi đã làm theo cách tiếp cận chậm và cẩn thận.

Phơi bày các vấn đề để tránh những rắc rối trong tương lai

Cuối cùng, tình tiết này thực sự cần thiết. Điểm của testnet là gì nếu không có gì được kiểm tra? Rõ ràng là không thực tế để chạy trơn tru mọi lúc.Lần này là một thử nghiệm tuyệt vời! Đây có lẽ là loại sốc tồi tệ nhất mà một mạng có thể phải chịu và chúng tôi có lẽ sẽ không thể thiết kế một thử nghiệm như vậy nếu chúng tôi tự thiết kế nó. Để testnet tiếp xúc với mức độ tác động này chính xác là những gì chúng tôi cần để củng cố khách hàng.tuần trước

Khối trong bài viết

Trích dẫn tuyên bố của tôi:

Trong email, kỹ sư Ben Edgington của PegaSys đã viết rằng Medalla "là mạng thử nghiệm đầu tiên có quy mô và cấu hình của mạng chính."một cách trung thực,。

Cái gì tiếp theo?

Bạn đang mong chờ điều gì?

Cái gì tiếp theo?

Trang web: ethereum.cn

Để biết thêm thông tin về Ethereum, vui lòng chú ý đến:

Tài khoản công khai: Trang web ETH Trung Quốc

Trang web: ethereum.cn

Tuyên bố miễn trừ trách nhiệm: Công việc dịch thuật của ECN nhằm mục đích cung cấp thông tin và tài nguyên học tập chất lượng cao cho cộng đồng Ethereum Trung Quốc. Bản quyền của bài viết thuộc về tác giả gốc. Các bản in lại phải ghi rõ nguồn của văn bản gốc và ethereum.cn. Về lâu dài in lại, vui lòng liên hệethereumcn@gmail.comủy quyền.