Sự khởi đầu và kết thúc của cuộc hỗn loạn mạng lưới thử nghiệm Huy chương, Phần 3
Tiêu đề gốc: "Giới thiệu | Mạng lưới thử nghiệm Huy chương hỗn loạn từ đầu đến cuối, Phần 3"
Tác giả gốc: Raul Jordan
Bản tổng hợp gốc:Zeng Mi, Min Min& A Jian, người đam mê Ethereum
Cuối tuần trước, mạng thử nghiệm công cộng Eth2, Huân chương, đã gặp phải một loạt lỗi xếp tầng. Những thất bại này đã bộc lộ một số lỗ hổng nghiêm trọng và cách chúng ta xử lý sai các tình huống nghiêm trọng. Chuỗi ngừng hoạt động bắt đầu khi một nút chạy ứng dụng khách Prysm nhận được phản hồi không chính xác từ 6 máy chủ đồng hồ khác nhau, khiến phần lớn các nút chạy ứng dụng khách Prysm đồng thời ngoại tuyến. Nhóm của chúng tôi đã gấp rút đưa ra bản sửa lỗi, trong đó có một lỗ hổng lớn - nó loại bỏ tất cả các tính năng cần thiết để nút hoạt động. Sự cố này dẫn đến phân vùng mạng, trong đó mỗi nút cố gắng đồng bộ hóa chuỗi khối nhưng không thể tìm thấy một nút ngang hàng hoạt động tốt. Huy chương đã trải qua một ngày cuối tuần đáng tiếc và đã cung cấp cho chúng tôi kinh nghiệm học hỏi rất quý giá để ngăn chặn sự cố kiểu này xảy ra lần nữa, đặc biệt là trên mạng chính. Bài viết này sẽ trình bày bản tóm tắt đầy đủ về sự cố, hậu quả của nó, bài học kinh nghiệm và các kế hoạch hành động cụ thể hơn nữa của chúng tôi trước khi ra mắt mạng chính eth2.
Tất nhiên là không. Chúng tôi sử dụng máy chủ đám mây thời gian thô để thông báo cho người dùng rằng thời gian hệ thống của họ có thể sai lệch và tự động điều chỉnh thời gian của họ dựa trên phản hồi của các máy chủ này. Chúng tôi cho rằng đây là một phương pháp hay nhưng trên thực tế, nó hoàn toàn không cần thiết và sẽ gây ra một số vấn đề. Nếu chúng tôi có một điểm lỗi đối với một thứ quan trọng như dấu thời gian trong eth2, thì đó là một rủi ro bảo mật và hoàn toàn không cần thiết. Sau sự cố này, chúng tôi sẽ chỉ dựa vào thời gian của hệ thống. Nếu thời gian trên hệ thống của người xác thực thực sự sai, chúng tôi sẽ cảnh báo họ nhưng sẽ không bao giờ buộc họ phải thay đổi thời gian. Chúng tôi sẽ chỉ sử dụng thời gian của hệ thống giống như các triển khai ứng dụng khách eth2 khác.
Không. Miễn là các nút vẫn có thể chạy và người xác thực vẫn có thể xác minh, mạng thử nghiệm luôn có thể trở về trạng thái có thể kiểm soát hoàn toàn. Hiện tại, nhóm triển khai khách hàng đã cải tiến mã đồng bộ hóa chuỗi của họ để giúp các nút chạy trơn tru hơn, điều này sẽ làm tăng sự tham gia của người xác thực và khiến blockchain trở lại như cũ. Vẫn còn hy vọng. Tỷ lệ tham gia của những người xác nhận đã tăng từ 0-5% lên 40% và khi đạt trên 66%, toàn bộ chuỗi có thể lấy lại được tính hữu hạn. .
Chúng tôi tin rằng sự cố này sẽ không ảnh hưởng đến việc ra mắt mạng chính. Nhóm Prysmatic Labs khuyến nghị ETH2 nên duy trì lịch ra mắt ban đầu và không trì hoãn nữa. Đối với nhiều khách hàng, sự cố cuối tuần này là một bài kiểm tra căng thẳng tốt và thực sự đưa một số yêu cầu trong danh sách ra mắt vào thử nghiệm. Mặc dù ngày ra mắt mainnet vẫn chưa được xác định nhưng chúng tôi tin rằng việc đặt thời gian ra mắt mục tiêu là 2 đến 3 tháng sau khi tạo ra Huy chương vẫn là một thời gian lý tưởng. Sẽ có một danh sách công khai các yêu cầu đối với việc ra mắt Eth2 và sự cố trên Huy chương chắc chắn sẽ dẫn đến nhiều mục mới được thêm vào danh sách, bao gồm những thứ như khả năng phục hồi máy khách, bảo mật và kiểm soát phiên bản phù hợp. Đó là tất cả những gì chúng ta biết cho đến nay.
Dấu hiệu thất bại ban đầu
Gần như ngay lập tức sau sự cố, người dùng nhận thấy rằng các nút Prysm của họ đang báo cáo độ lệch đồng hồ và nhìn thấy các khối nâng cao. Vào thời điểm đó, Prysm đã sử dụng giao thức thời gian thô để tự động điều chỉnh đồng hồ máy khách bằng cách truy vấn một tập hợp các máy chủ thời gian thô để xác định độ lệch đồng hồ thích hợp. Giao thức Roughtime hoạt động bằng cách truy vấn tuần tự một nhóm máy chủ để tìm một loạt yêu cầu/phản hồi đã ký và sau đó khách hàng lấy mức trung bình của các phản hồi này để điều chỉnh đồng hồ của họ.
| điểm giữa | Tên máy chủ |
|---|---|
| Ngày 15 tháng 8 năm 2020 2:20:23 sáng | ;Google-Sandbox -Thời gian thô |
| Ngày 15 tháng 8 năm 2020 2:20:23 sáng | Caesium |
| Ngày 15 tháng 8 năm 2020 2:20:23 sáng | Chainpoint -Roughtime |
| Ngày 15 tháng 8 năm 2020 2:20:23 sáng | Cloudflare-Roughtime |
| Tháng 8 Ngày 15 tháng 1 năm 2020 2:20:23 sáng | int08h-Roughtime |
| Ngày 16 tháng 8 năm 2020 2:20:23 sáng | ticktock |
Bạn có nhận thấy điều gì không? Máy chủ 6 trong bảng trên báo cáo thời gian nhanh hơn 24 giờ so với 5 máy chủ còn lại. Vì vậy, khi khách hàng trong thời gian thô tính trung bình các kết quả này, nó sẽ coi ngày 15 tháng 8 năm 2020 6:20:23 sáng là thời gian chính xác. Một thành phần quan trọng của Thỏa thuận Roughtime là trách nhiệm giải trình. Với một chuỗi đồng hồ đã được ký trong giao thức, chúng tôi có thể chứng minh rằng chính máy chủ tích tắc đã phản hồi không chính xác và báo cáo sự cố một cách hiệu quả. Thật không may, Prysm không ghi lại chuỗi đồng hồ như vậy và chúng tôi không có thông tin được lưu trữ ở bất kỳ đâu vào thời điểm xảy ra sự cố. Sau khi truy vấn nhanh nhật ký, chúng tôi phát hiện ra rằng các máy chủ TickTock đã được bù giờ 24 giờ, điều này giải thích tại sao 6 máy chủ có thời gian chênh lệch đồng hồ là 4 giờ. Chúng tôi đã liên hệ với những người duy trì dự án thời gian khó khăn tại cloudflare và họ đã quyết định cải thiện độ mạnh mẽ của khách hàng trong trường hợp máy chủ bị lỗi:
Câu hỏi số 22 : Dành cho sự mạnh mẽ của Máy khách đối với các máy chủ bị lỗi
Mặc dù chúng tôi không biết rằng một trong những máy chủ thời gian thô đang báo cáo thời gian trước 24 giờ, nhưng chúng tôi biết rằng có đang có vấn đề với máy chủ thời gian thô nên phải đóng nó ngay lập tức. Chúng tôi không loại bỏ hoàn toàn mã thời gian thô mà sửa đổi nó để yêu cầu bật cờ thời gian chạy để điều chỉnh đồng hồ, thay vì tự động điều chỉnh đồng hồ theo mặc định. Testnet đang gặp khó khăn và chúng tôi muốn tiến hành nhanh chóng nên chúng tôi quyết định tung ra "phiên bản khẩn cấp" và yêu cầu mọi người cập nhật mã mới ngay lập tức. Tuy nhiên, trước khi chúng tôi có thể thực hiện việc này, máy chủ thời gian thô đã hoạt động trở lại bình thường.
Trước khi vụ tai nạn xảy ra, lẽ ra chúng ta phải lường trước điều đó, nhưng khi nó xảy ra, nó vẫn khiến mọi người bàng hoàng. Vào khoảng 10 giờ sáng (giờ Bắc Kinh), mọi người xác thực đang hoạt động trong thời điểm khó khăn bắt đầu tích cực gửi tin nhắn nhân chứng có thể khiến họ bị chém. Điều này đã trở thành một cuộc tắm máu, với hơn 3000 nhát chém xảy ra trong một khoảng thời gian rất ngắn và không một người xác nhận nội bộ nào của chúng tôi được tha. Vào thời điểm đó, chúng tôi đang bận cải thiện trải nghiệm người dùng trên mạng thử nghiệm và do đó đã không định cấu hình kịp thời tính năng bảo vệ cắt giảm gốc cho trình xác thực nội bộ của chúng tôi.
Vì quá háo hức khắc phục sự cố ban đầu, chúng tôi đã không xem xét toàn bộ tác động của các bản sửa lỗi tiềm năng và tập trung nhiều hơn vào việc nhanh chóng phát hành một phiên bản mới thay vì kiểm tra cẩn thận xem phiên bản mới có phá vỡ những thứ khác trong nút của chúng tôi hay không. Đồng đội Nishant của chúng tôi là người đầu tiên chỉ ra một lỗ hổng nghiêm trọng trong phiên bản alpha.21 mà chúng tôi phát hành. Mạng có thể tự phục hồi nếu chúng tôi không làm gì cả.
Trong khi phát hành bản sửa lỗi này, chúng tôi đã vô tình xóa đèn hiệu Eth2 Phần khởi tạo của tất cả các tính năng chính để nút chuỗi hoạt động bình thường, do đó khiến vấn đề trở nên vượt quá tầm kiểm soát. Sau khi chúng tôi công bố phiên bản mới này cho mọi người trên máy chủ discord và twitter của mình, người dùng đặt cược bắt đầu nhanh chóng nâng cấp các nút của họ và đó là lúc chúng tôi nhận ra vấn đề nghiêm trọng đến mức nào. Tệ hơn nữa là hiện tại lỗi thời gian thô đã được khắc phục hoàn toàn, nếu không có sự can thiệp khẩn cấp của chúng tôi thì mạng có thể đã bình thường.
Sau khi nhận ra phạm vi của lỗi, chúng tôi ngay lập tức khuyên người dùng nên khôi phục ứng dụng khách về phiên bản trước vì vấn đề về thời gian thô hiện đã được giải quyết. Tuy nhiên, động thái này cuối cùng gặp khó khăn vì mạng bị phân vùng và người dùng bối rối trước quá nhiều bản cập nhật trong một khoảng thời gian ngắn. Vì phần lớn các nút đã ngừng hoạt động trong một thời gian nên người dùng thường xuyên khởi động lại các nút của họ để nhận bản cập nhật và có vẻ như hầu hết mọi người trong mạng đang cố gắng đồng bộ hóa chuỗi khối, khiến việc tải các khối mới nhất là không thể. Ngoài ra, các nút rất khó giải quyết các nhánh. Nói cách khác, mạng chứa vô số nút xấu và việc cố gắng tìm một nút tốt cũng giống như mò kim đáy bể. Hơn nữa, mức tiêu thụ tài nguyên của các nút cũng ngày càng tăng. Việc triển khai máy khách khác đang gặp phải tình trạng chiếm dụng bộ nhớ lớn và các nút Prysm cũng bị ảnh hưởng do mức sử dụng CPU cao, điều này không giúp ích gì khi giải quyết các nhánh.
Sự cố này đã phơi bày một số giả định quan trọng, thiếu sót mà các nút của chúng tôi đưa ra khi xử lý các khối phân nhánh trong một sự cố blockchain có phân vùng cao. Chúng tôi đã không xử lý nhiều đường dẫn mã có thể tồn tại cho nhiều khối trong một vùng, điều này khiến các nút của chúng tôi thường xuyên bị kẹt. Hơn nữa, ngay cả khi chúng tôi giải quyết được vấn đề này, nếu một nút bị tụt lại phía sau, nó vẫn không thể đồng bộ lại với tiêu đề khối. Thật dễ dàng để viết mã dựa trên giả định rằng blockchain ổn định, nhưng làm cho mã đó hoạt động khi nó chứa đầy các nút, nhánh và phân vùng mạng xấu lại là một chuyện hoàn toàn khác. Sau khi thay đổi các giả định, logic đồng bộ hóa của chúng tôi đã trở nên đủ mạnh để xử lý loại tình huống này và đồng đội của chúng tôi, Victor Farazdagi, đã có thể nhanh chóng giải quyết vấn đề. Kể từ đó, chúng tôi đã triển khai bản cập nhật sửa lỗi giúp khởi động các nút Prysm để đồng bộ hóa với đầu chuỗi khối và luôn đồng bộ hóa! Tại thời điểm viết bài, phần lớn các nút đang được cập nhật lên phiên bản này. Tại thời điểm này, chúng tôi chỉ cần thêm người xác thực trực tuyến và sử dụng các nút chuỗi đèn hiệu đã được đồng bộ hóa của họ để bắt đầu chứng kiến và đề xuất các khối. Tiếp theo, chúng tôi sẽ theo dõi sự tham gia trên chuỗi và liên hệ với càng nhiều cá nhân chạy trình xác thực càng tốt để biết liệu họ có còn gặp sự cố hay không.
Nếu bạn đang chạy Prysm, bạn có thể truy cập trang phát hành của chúng tôi https://github.com/ prysmaticlabs/prysm/release Tải xuống phiên bản mới nhất hoặc làm theo hướng dẫn chi tiết được xuất bản trong trung tâm tài liệu của chúng tôi https://docs.prylabs.network/docs/install/install-with-script. Chúng tôi sẽ tiếp tục cập nhật trạng thái thông qua Discord khi tình hình tiến triển.
Toàn bộ sự việc có thể đã tránh được nếu chúng tôi không vội vàng khắc phục vấn đề đồng bộ hóa đồng hồ vào thời gian thô. Sự cố này trở nên trầm trọng hơn do chúng tôi đã hợp nhất một PR sai khiến xóa sạch tất cả chức năng quan trọng cần thiết để nút chạy. Vì háo hức khắc phục sự cố ban đầu, chúng tôi đã không nghĩ đến tất cả các phân nhánh của bản sửa lỗi và quá tập trung vào việc phát hành nó càng nhanh càng tốt nên chúng tôi đã không kiểm tra kỹ xem bản sửa lỗi có làm hỏng các tính năng khác của nút hay không . Nishant từ nhóm của chúng tôi là người đầu tiên chỉ ra những sai sót nghiêm trọng trong phiên bản alpha 21. Testnet có thể tự phục hồi nếu chúng tôi không thực hiện bất kỳ hành động nào.
Nhận thấy tất cả các nút chạy ứng dụng khách Prylabs trên toàn bộ mạng đều không hoạt động, chúng tôi rất lo lắng và tập trung vào việc giảm bớt mối lo ngại của người dùng càng sớm càng tốt. Mặc dù bản sửa lỗi này ban đầu được tạo bởi một người đóng góp bên ngoài nhưng đó là lỗi của chúng tôi khi nó không được xem xét cẩn thận. Có một dòng mã trong bản sửa lỗi này giúp khôi phục tất cả các nút chạy ứng dụng khách Prylabs về cấu hình mặc định chung. Xem https://github.com/prysmaticlabs/prysm/pull/6898/files#diff-fb86a5d3c2b85d3e68cad741d5957c29L263. Từ nay trở đi, khi có thất bại hoặc khủng hoảng, mọi phiên bản được phát hành đều phải
1. Được đánh giá bởi toàn bộ nhóm và một người ngoài cuộc (ví dụ: nhà nghiên cứu Ethereum)
2. Thử nghiệm đầu tiên trong môi trường mô phỏng trong một khoảng thời gian, có thể là Prysm ETH 2.0 mạng tấn công hoặc mạng thử nghiệm cục bộ có cùng lỗ hổng.
Nhóm của chúng tôi thường sử dụng phương pháp triển khai canary: triển khai PR mới được hợp nhất vào môi trường sản xuất để hiểu hiệu suất của PR (so với đường cơ sở) theo thời gian. Tuy nhiên, do mọi nút đều có vấn đề (bao gồm cả những nút chúng tôi chạy nội bộ), nên không có đường cơ sở và do đó không có quá trình triển khai canary. Chúng tôi háo hức khắc phục sự cố và phát hành phiên bản mới cho người dùng ngay khi nó ra mắt mà không nhận ra rằng có một lỗ hổng rất lớn trong đó. Vấn đề tương tự sẽ không xảy ra nữa và chúng ta đã học được một bài học lớn từ nó. Nếu tình huống tương tự xảy ra lần nữa trong tương lai, ngay cả khi số dư của trình xác thực đang giảm và blockchain vẫn không chắc chắn, chúng tôi sẽ phải tự tin 100% trước khi đưa ra bản sửa lỗi.
Một sai lầm khác mà chúng tôi mắc phải là không truyền đạt cẩn thận khi thông báo các bản cập nhật . Khi hơn 90% nút gặp sự cố nghiêm trọng và không thể đồng bộ hóa với các khối mới nhất, chúng tôi chỉ thông báo cho mọi người “cập nhật nút nhanh chóng!”, điều này đã gây ra sự nhầm lẫn lớn. Theo cài đặt mặc định, số lượng ngang hàng tối đa mà mỗi nút có thể kết nối là 30. Đối với những người không biết cách sửa đổi giới hạn này, điều này có nghĩa là các đồng nghiệp của họ hầu như luôn cố gắng đồng bộ hóa, gây ra tải trọng liên lạc nặng nề. Không phải ai cũng bật thông báo về các thông báo bất hòa và những người ở các múi giờ khác có thể đang ngủ trong khi chúng tôi thông báo cho mọi người về các bản cập nhật nút. Bài học chính mà chúng tôi học được từ sự cố này là duy trì liên lạc rõ ràng, hiểu trạng thái của mạng và tác động của việc yêu cầu mọi người cập nhật các nút.
Một tính năng chính của ETH 2.0 là sự phát triển phi tập trung. Có 5 nhóm riêng biệt xây dựng triển khai ứng dụng khách cho ETH 2.0. Năm khách hàng này đều tham gia vào việc tạo ra mạng thử nghiệm công khai Huân chương. Mặc dù trạng thái sẵn sàng của chúng khác nhau nhưng một số trong số chúng đã được cải thiện đáng kể kể từ thử nghiệm testnet cuối cùng. Vào thời điểm xảy ra lỗi, 65% nút trong mạng đang chạy trên ứng dụng khách Prysm của chúng tôi. Một khi tất cả các nút Prysm bị lỗi, toàn bộ mạng sẽ bị ảnh hưởng. Từ góc độ khả năng phục hồi của mạng, người xác thực phải có khả năng dễ dàng di chuyển sang các máy khách khác nếu xảy ra lỗ hổng nghiêm trọng ở một máy khách. Thật không may, khi mạng thử nghiệm Huy chương ra mắt, nhóm khách hàng đang nghiên cứu cách chuẩn hóa cách khách hàng quản lý khóa xác thực. Điều đó có nghĩa là chúng tôi chưa hoàn thiện 100% tài liệu về cách di chuyển giữa Prysm và Lighthouse. Tiếp theo, điều này sẽ trở thành ưu tiên trong công việc của chúng tôi và được áp dụng cho cổng tài liệu công cộng của chúng tôi. Chúng tôi giúp người dùng dễ dàng chuyển đổi giữa các máy khách bất kỳ lúc nào, đồng thời tuân thủ các phương pháp hay nhất về bảo mật đã công bố của chúng tôi.
Nếu mạng thử nghiệm công khai của Huy chương chạy trơn tru, nó sẽ được khởi chạy trên mạng chính. đã hoạt động tốt trước đó, nhưng lỗ hổng này không bị lộ cho đến khi mạng chính ETH 2.0 ra mắt. Đây thực sự là điều đáng sợ. Trường hợp xấu nhất đối với blockchain là hầu hết các nút đang chạy trên cùng một máy khách và máy khách đó có chứa lỗ hổng khiến tất cả các nút ngoại tuyến. Huy chương đã cho thấy tình hình này có thể nghiêm trọng đến mức nào. Điều quan trọng là tất cả người dùng đặt cược phải biết phải làm gì trong tình huống này và có thể chuyển sang khách hàng khác nếu có nhu cầu.
ETH 2.0 Giai đoạn 0 là một dự án có những mục tiêu đầy tham vọng sẽ mang lại lợi ích cho những người tham gia vào thời điểm đó Người dùng đặt cọc mang lại rủi ro kỹ thuật. Đây là một cải tiến hoàn chỉnh cho giao thức Ethereum, giới thiệu bằng chứng cổ phần. Đây là lần triển khai đầu tiên kể từ nhiều năm nghiên cứu về Casper FFG (Tiện ích Finistic). Mặc dù việc triển khai ứng dụng khách đã rất hoàn thiện và sẽ mạnh mẽ hơn trước sau sự cố này, ETH 2.0 là một thử nghiệm có hậu quả nghiêm trọng đối với những người dùng đặt cọc không hiểu rõ rủi ro. Nếu lỗi này xảy ra trên mainnet, khiến mainnet không thể hoàn thiện các khối trong nhiều ngày liên tiếp, tổng thiệt hại của những người xác nhận bị cắt sẽ là hàng triệu, nếu không muốn nói là hàng chục triệu đô la, đây sẽ là một tổn thất lớn cho mọi người ( kể cả những người có nhiều nhất. Đó là điều vô cùng đau đớn đối với những người ủng hộ tích cực). Điều chúng ta cần làm rõ là những rủi ro này là có thật và rủi ro kỹ thuật không thể loại bỏ được. Những rủi ro khi nổ súng đã được làm rõ trong bệ phóng ETH 2.0 và lời khuyên của chúng tôi là hãy cân nhắc cẩn thận xem có nên đặt cược vào ETH 2.0 hay không.
Tại thời điểm viết bài này, hơn 78% nút chuỗi đèn hiệu công khai ETH 2.0 đang chạy trên ứng dụng khách Prysm của chúng tôi.
Trước khi xảy ra lỗi, tỷ lệ này cao tới khoảng 62%. Sự phát triển của ETH 2.0 tập trung vào nhiều triển khai độc lập, cho phép người dùng chuyển đổi theo ý muốn trong thời điểm khủng hoảng hoặc khi xảy ra lỗ hổng trong quá trình triển khai. Các vấn đề hiện tại với mạng thử nghiệm Huy chương là do nó phụ thuộc quá nhiều vào một khách hàng duy nhất và chúng tôi tin rằng điều này sẽ thay đổi. Các nhóm khách hàng khác đang nỗ lực cập nhật tài liệu, cải thiện khả năng phục hồi và làm cho hoạt động triển khai của họ kém hiệu quả hơn. Nhiều người dùng đặt cược chọn ứng dụng khách Prysm của chúng tôi vì họ dễ dàng thiết lập ứng dụng khách Prysm trong cài đặt cá nhân hoặc đám mây và chúng tôi sẽ tiếp tục nghiên cứu vấn đề đó. Tuy nhiên, bạn nên thử các cách triển khai khác và chuyển đổi nếu cần, đặc biệt đối với những người dùng đặt cược đang chạy nhiều nút xác thực.
Đối với tất cả các nhóm triển khai ứng dụng khách, việc thuyết phục người dùng cập nhật nút là một vấn đề muôn thuở. Khi mạng trở nên phi tập trung hơn, chúng tôi thiếu kênh liên lạc để thông báo cho tất cả các nhà khai thác nút cập nhật các nút của họ nhằm khắc phục các lỗ hổng quan trọng. Điều tốt nhất mà một nhóm có thể làm là dựa vào phương thức liên lạc của riêng họ, chẳng hạn như kênh Discord, trang phát hành Github hoặc thậm chí là tài khoản Twitter. Mặc dù chúng tôi đã thông báo cho mọi người "cập nhật nút nhanh chóng!", nhưng các nhà khai thác nút ở các múi giờ khác nhau có thể không trực tuyến và một số nhà khai thác có thể không sử dụng các công cụ truyền thông xã hội. Yêu cầu mọi người cập nhật cùng lúc có thể dẫn đến thảm họa: sau khi một nút ngoại tuyến trong một thời gian dài, mọi người bắt đầu cập nhật cùng lúc, khiến các nút ngang hàng trong mạng đồng bộ hóa cùng lúc, gây ra lưu lượng mạng quá mức . Vì vậy, điều quan trọng là phải có chiến lược phát hành chi tiết hơn và đảm bảo rằng tất cả người dùng đều biết về các kênh liên lạc “chính thức”. Ngoài ra, chúng tôi muốn đảm bảo rằng những người nắm giữ ETH lớn và người vận hành nhiều nút có thể dễ dàng liên hệ với nhóm phát triển của chúng tôi. Chúng tôi muốn duy trì mối liên hệ chặt chẽ hơn với những người vận hành nút, đảm bảo rằng họ biết khi nào các nút nên được cập nhật và cho họ biết nhật ký thay đổi nào có liên quan đến họ trong mỗi lần cập nhật.
Không cần phải nói, đây sẽ là một trong những tình huống xấu nhất nếu nó xảy ra trên mạng chính. Mặc dù tốt nhất là chuỗi sự kiện này nên diễn ra trên testnet, điều này cho phép chúng tôi xem trước cách xử lý trước các tình huống khủng hoảng, nhưng các tình huống khác có thể phát sinh sau khi mạng chính trực tuyến. Mặc dù chúng tôi có thể thực hiện các biện pháp như kiểm tra bảo mật, kiểm tra mã và môi trường mô phỏng, nhưng trên thực tế, mạng chính ETH 2.0 vẫn có thể bị tấn công DDoS như ETH 1.0 nhiều năm trước và chúng tôi cần chuẩn bị cho điều này. Đội ngũ đằng sau ETH 1.0 đã trải qua nhiều cuộc chiến và tích lũy được nhiều kinh nghiệm về cách xử lý khủng hoảng. Sự thất bại của mạng thử nghiệm Huy chương này cũng để lại cho chúng tôi một số kinh nghiệm. Với tư cách là nhóm phát triển khách hàng, chúng tôi phải chú ý đến những điểm sau khi triển khai khách hàng trên mạng chính:
Có Danh sách kiểm tra đầy đủ bao gồm các ứng cử viên phát hành, môi trường mô phỏng, liên lạc và giám sát bên ngoài. Cung cấp cho người dùng hướng dẫn chi tiết để di chuyển giữa các máy khách ETH 2.0 khác nhau. Hướng dẫn từng bước được Nhóm khẩn cấp khách hàng ETH 2.0 phát triển và triển khai. Prysmatic Labs có sổ tay hướng dẫn nội bộ riêng, nhưng việc có một hướng dẫn tổng thể điều phối tất cả các máy khách ETH 2.0 sẽ giúp bạn bớt đau đầu hơn rất nhiều. Lập kế hoạch chi tiết về cách thông báo cho các bên liên quan, nhà điều hành nút và người dùng thông thường để cập nhật các nút vào những thời điểm quan trọng.
Sự cố này đã thực sự thay đổi cách chúng tôi phát triển ETH 2.0. Chúng tôi biết rằng dự án này tiềm ẩn rủi ro cao, nhưng giờ đây chúng tôi biết rõ hơn cách đối phó với khủng hoảng, cách đối phó với những thay đổi mà không hoảng sợ và những điều cấm nghiêm ngặt khi nhiều người dùng tin tưởng vào khách hàng của chúng tôi.
Tóm lại, do việc đưa ra quyết định kém cỏi của chúng tôi trong việc khắc phục các lỗi toàn cầu, mạng thử nghiệm Huy chương của ETH 2.0 đã gặp phải lỗi xếp tầng. Lý do khiến mạng thử nghiệm gặp phải tình trạng ngừng hoạt động nghiêm trọng như vậy không chỉ vì chênh lệch đồng hồ thời gian thô và lỗi một điểm mà còn vì một loạt sự cố do các phân vùng mạng khác nhau gây ra. May mắn thay, tất cả điều này đã xảy ra trên mạng thử nghiệm và tất cả các nhóm khách hàng ETH 2.0 hiện đã chuẩn bị đầy đủ trong trường hợp các sự cố tương tự xảy ra trên mạng chính. Chúng tôi sẽ tập trung vào cách tăng khả năng phục hồi của ETH 2.0 thông qua các quy trình, bảo mật và các biện pháp dự phòng thích hợp, đồng thời làm việc với tất cả các nhóm phát triển khách hàng để đạt được những mục tiêu này.
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
Bài viết liên quan
