Toàn cảnh sự cố “sập” testnet Medella

Nguồn: Trang web ETH Trung Quốc

Tác giả: Ben Edgington

Ghi chú của người dịch:

Người dùng chạy ứng dụng khách Prysm được yêu cầu nâng cấp lên phiên bản Alpha.23 càng sớm càng tốt:

https://github.com/prysmaticlabs/prysm/releases

Sự cố này là bản cập nhật ngoài kế hoạch của wnie2. Nó sẽ xem xét và phân tích tình tiết xảy ra trên mạng thử nghiệm Eth2 Huy chương vào cuối tuần. .

Chúng tôi đã ra mắt Huy chương gần hai tuần trước, vào ngày 4 tháng 8, một mạng thử nghiệm lớn, công khai, nhiều khách hàng chạy đặc tả mạng chính Eth2.

Mạng thử nghiệm chạy trơn tru trong 10 ngày, mặc dù tỷ lệ tham gia của người xác thực thấp hơn chúng tôi mong đợi (70%-80% người xác thực vẫn trực tuyến lâu dài). Nhưng không sao cả, testnet có thể xử lý nó một cách hoàn hảo.

Tuy nhiên, vào tối thứ Sáu, tôi đã chứng kiến tỷ lệ tham gia của người xác thực trên bảng điều khiển giảm đột ngột. Trong vòng vài phút, số lượng trình xác thực đ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 thực của mạng đã biến mất.

Vì vậy, bài viết này sẽ tập trung vào sự kiện này Tiến hành đánh giá, bao gồm cả hậu quả và các bước tiếp theo.

Chuyện gì đã xảy ra?

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

Nhóm Prysmatic đã mở một tài liệu báo cáo về sự cố này và tiếp tục cập nhật chi tiết sự cố cũng như phản hồi của nhóm. Dưới đây là một số điểm nổi bật và ghi chú của tôi.

Nguyên nhân của sự cố là do sự cố đồng bộ hóa đồng hồ  Ứng dụng khách Prysm được định cấu hình để sử dụng Roughtime của Cloudflare để tính toán thời gian. Nguyên nhân của điều này không hoàn toàn rõ ràng (theo ý kiến của tôi), nhưng rõ ràng là Roughtime đã chuyển sang tương lai bốn giờ và kéo dài hơn một giờ. Những người xác thực ứng dụng khách Prysm đột nhiên nhận thấy thời gian của họ đã tăng lên bốn giờ và tiếp tục tạo các khối và bằng chứng cho một blockchain chưa tồn tại.

Bản thân nó chưa đủ để gây ra hậu quả thảm khốc. Ngay cả khi nhiều khối bị mất và phải đối mặt với số lượng lớn bằng chứng trong tương lai, các 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à tỷ lệ tham gia của người xác thực bắt đầu tăng lên. Mạng có vẻ đã trở lại bình thường.

Nhưng vài giờ sau, tình hình lại thay đổi. Nó lại trở nên tồi tệ hơn.

Bốn giờ sau sự kiện đầu tiên, hai điều nữa đã xảy ra. Đầu tiên, tất cả các bằng chứng trong tương lai do ứng dụng khách Prysm tạo ra sẽ bắt đầu có hiệu lực. Thứ hai, các nút Prysm tham gia lại mạng bắt đầu biến mất trở lại do cơ chế bảo vệ cắt giảm đượ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 chuyện này xảy ra cùng lúc khiến mạng lưới trở nên hỗn loạn. Những khách hàng còn lại vẫn đang gặp khó khăn trong việc xử lý thông tin họ nhận được và chuỗi đèn hiệu trở thành một khu rừng không ngừ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 tình hình trở nên tồi tệ hơn)

Trong một khoảng thời gian, thông tin trên mạng vẫn nằm trong tầm kiểm soát. Nhưng trong khoảng 24 giờ tiếp theo, bộ nhớ và CPU cần thiết để điều hướng các nhánh ngày càng phức tạp và khó hiểu đã trở nên quá tải. Tôi thấy một ứng dụng khách Lighthouse sử dụng 30GB bộ nhớ (gấp khoảng 100 lần so với bình thường) và ứng dụng khách Teku gặp sự cố ngay cả với vùng nhớ Java 12GB và sử dụng tối đa bộ xử lý.

Xin lư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 làm việc ở tuyến đầu. Để các nút có thể đối phó với mạng hỗn loạn, họ cần liên tục tối ưu hóa bộ nhớ và hiệu quả.

Cho đến nay mạng đang dần hồi phục. Báo cáo của người dùng khác nhau, nhưng các phiên bản mới của Prysm và Lighthouse gần như có thể tìm thấy đầu chuỗi chính xác và tiếp tục xây dựng chuỗi đèn hiệu.  Eth2Stats hiện hiển thị một số nút tại hoặc gần đầu chuỗi của các nút Lighthouse, Prysm và Teku. Chúng tôi sẽ tiếp tục tối ưu hóa Teku để giảm tài nguyên mà nó yêu cầu trong quá trình đồng bộ hóa.

Không xảy ra lỗi đồng thuận

Một điều cần phải làm rõ là không có sự đồng thuận thất bại giữa các client, có nghĩa là khi mạng phục hồi, tất cả khách hàng đều 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à về cơ bản, chuỗi beacon sẽ không thất bại và không yêu cầu bất kỳ hard fork nào.

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ập này. Dưới đây là một số ý kiến cá nhân của tôi.

Tầm quan trọng của việc đồng bộ hóa thời gian

Sự phụ thuộc quá nhiều vào các dịch vụ thời gian của bên thứ ba là một điểm nguy hiểm đối với Internet. Khi điều đó xảy ra, Alex Vlasov của nhóm nghiên cứu ConsenSys TX/RX trước đây đã viết chi tiết 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 đang tiến triển nhanh chóng, có lẽ đây là cơ hội để mọi người chú ý đến khía cạnh này. Dưới đây là các bài viết liên quan của anh ấy và các bài đăng trên ethresear.ch.

Khách hàng Ý nghĩa của sự đa dạng

Lý tưởng nhất là chúng tôi 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 này, ngay cả khi có vấn đề với một khách hàng, tác động cũng không đủ để thu hút sự chú ý của chúng tôi.

Ngay cả khi chúng tôi không thể đạt được tình huống lý tưởng này, việc giảm mức sử dụng cực cao của khách hàng cá nhân có thể khiến mạng trở nên mạnh mẽ hơn. Giả sử rằng lần này chỉ có 50% trình xác thực ngoại tuyến thay vì 80% thì mạng sẽ dễ phục hồi hơn. Điều này là do khi sự cố xảy ra ở phía máy khách, nó sẽ ảnh hưởng đến việc 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, đồng thời các yếu tố này cũng sẽ có tác động xếp tầng đối với các trình xác thực còn lại.

Hiệu quả của các giải pháp thay thế

Một số người đặt cược có thể chuyển khóa ký sang các nút dự phòng nóng trên các máy khách khác. Điều này chắc chắn tạo nên một mạng lưới rất an toàn, mặc dù cần phải cẩn thận để tránh bị cắt giả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 không nhất quán.

Trong tương lai, khi chúng tôi hoàn thiện API mới, chúng tôi có thể triển khai khả năng chuyển đổi ứng dụng khách 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 ngắt kết nối 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ém được đề cập ở trên.

Cam kết

Tham gia vào Eth2 hiện tại không phải là việc “một lần và mãi mãi”. Các bên liên quan cần duy trì mức độ chú ý nhất định, dạo quanh 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 một khoảng thời gian ngắn. Tôi đặc biệt ủng hộ mọi người đang chạy trình xác thực cá nhân của riêng mình, nhưng chỉ khi họ nhận thức được trách nhiệm của mình.

Vội vàng tạo ra sự lãng phí

Tại sao mọi thứ luôn không ổn vào tối thứ Sáu?

Phản hồi từ nhóm Prysmatic thật tuyệt vời, kể cả vào thời điểm này. Vui lòng xem báo cáo sự cố của nhóm để biết chi tiết. Những gì tôi nói dưới đây không nhằm mục đích phản ánh sự kém cỏi của đội Prysmatic, những người đang làm rất tốt công việc, mà là để cung cấp kinh nghiệm cho đội Teku khi gặp tình huống tương tự.

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

Có hai điều có thể tránh được trong vụ việc này. Đầu tiên, có một lỗ hổng trong bản sửa lỗi ban đầu, Alpha.21, khiến người dùng phải quay lại sau 17 giờ.

Theo Raul từ nhóm Prysmatic , Lỗ hổng này là nguyên nhân gây ra sự hỗn loạn mạng xảy ra sau đó. Thứ hai, nhóm đã vô tình xóa cơ sở dữ liệu bản ghi chống gạch chéo gồm 1.024 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 thực bị chém.

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 bình tĩnh giải quyết và không thể theo đuổi tốc độ một cách mù quáng. Vì vậy, khi cố gắng khôi phục mạng, chúng tôi đã thực hiện một cách tiếp cận chậm rãi và cẩn thận.

Trình bày vấn đề để tránh rắc rối về sau

Cuối cùng, tập này thực sự cần thiết. Testnet có ích gì nếu không có gì được kiểm tra? Rõ ràng là không thực tế nếu lúc nào cũng hoạt động trơn tru.

Lần này là một bài kiểm tra tuyệt vời! Đây có lẽ là loại tác động nghiêm trọng nhất mà mạng có thể phải gánh chịu và ngay cả khi chúng tôi tự thiết kế nó, chúng tôi cũng không thể thiết kế được một thử nghiệm như vậy. Việc đưa mạng thử nghiệm tớ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 The Block đã trích dẫn phát biểu của tôi trong một bài viết:

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

"Đây là cuộc thử nghiệm quy mô lớn đầu tiên, trước đó chỉ là thông số kỹ thuật trên màn hình, hay mạng đồ chơi. Có rất nhiều khía cạnh trong mạng ngang hàng cần được thử nghiệm và tối ưu hóa. Cho đến nay, mọi thứ đều có đang hoạt động bình thường, nhưng cho đến khi chúng tôi có thể đảm bảo. Sẽ mất nhiều thời gian hơn, quy mô rộng hơn và áp lực mạng lớn hơn trước khi nó chính xác.”

Thành thật mà nói, tôi thực sự mong chờ những gì sắp xảy ra.

Tiếp theo là gì?

Hiện tại, tất cả các nhóm khách hàng đang nỗ lực củng cố ứng dụng khách để nó có thể đối phó với các điều kiện mạng khắc nghiệt. Không phải là vấn đề lớn, chúng tôi sẽ có thể đưa Huân chương trở lại bình thường trong vài ngày tới, điều này có thể ảnh hưởng đến tất cả số dư của người xác thực và một số người xác thực đang phải đối mặt với việc cắt giảm.

Nếu sau đó, ngay cả khi mạng có thể hoạt động bình thường, tỷ lệ tham gia của người xác thực vẫn không thể tăng trở lại thì chúng tôi có thể xem xét bắt đầu lại từ đầu và triển khai lại hợp đồng tiền gửi (tạo lại cũng có thể là một lựa chọn tốt). Nhưng đây chỉ là một giải pháp thay thế ở giai đoạn này.

Huy chương muôn năm!

Link gốc: https://hackmd.io/@benjaminion/wnie2_200817

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia