Jinjin Finance Blockchain, ngày 10 tháng 6 Một lỗi trong mã phân loại của Arbitrum trong tuần này đã khiến chức năng gửi giao dịch hàng loạt của mạng tạm thời bị gián đoạn và giao dịch không thể được xác nhận trên chuỗi chính. Lỗ hổng này đã được khắc phục và chức năng gửi lô giao dịch đã được khôi phục. Vào ngày 10 tháng 6, Tổ chức Arbitrum đã công bố báo cáo phân tích sau sự kiện về lỗi bộ sắp xếp Arbitrum. Tiếp theo, hãy xem xét trường hợp và xem tại sao sự kiện lỗi này không làm mất tiền của người dùng.
Tiến trình sự kiện lỗi Arbitrum Sorter
Vào lúc 06:04:53 ngày 7 tháng 6 năm 2023, nhà phát hành lô không thể cập nhật chế độ xem trạng thái L1 của mình do sự cố tạm thời với nút L1 của bộ đối chiếu Arbitrum. Do sự cố nguyên nhân gốc rễ, bộ sắp xếp Arbitrum tiếp tục cố gắng truy vấn trạng thái của số khối chế độ xem L1 trước đó. Điều này có nghĩa là ngay cả sau khi sự cố nút L1 tạm thời tự giải quyết, nhà xuất bản lô sẽ tiếp tục truy vấn trạng thái của số khối L1 cũ và nút L1 không còn trạng thái của nó nữa vì nó không phải là nút lưu trữ.
Vào lúc 09:38:28 ngày 7 tháng 6 năm 2023, người đăng lô của Arbitrum đã ngừng xuất bản các giao dịch vì đã đạt đến giới hạn giao dịch xếp hàng đợi tối đa được định cấu hình (256), bằng với giới hạn của mempool. Nếu không đạt đến giới hạn này, việc đăng hàng loạt sẽ tiếp tục như bình thường.
Vào lúc 11:09 sáng ngày 7 tháng 6 năm 2023, do các lô chưa được công bố, một cảnh báo đã được kích hoạt trên hợp đồng thông minh Hộp thư đến Sequencer để kiểm tra các lô mới và một cảnh báo đã được gửi đến kênh Slack.
Vào lúc 11:10 sáng, việc thiếu các bản phát hành hàng loạt gần đây đã kích hoạt cảnh báo dựa trên nhật ký và gửi cảnh báo mức độ quan trọng đến kênh Slack.
Vào lúc 11:13 sáng, một thành viên của nhóm cộng đồng đã khởi xướng PagerDuty cùng với một thành viên của nhóm SRE, người này đã nhanh chóng thừa nhận sự cố và bắt đầu phản hồi.
Vào lúc 11:19:02 sáng, nhóm SRE đã khởi động lại áp phích lô, nhưng do giới hạn giao dịch xếp hàng đợi tối đa đã đề cập trước đó, áp phích lô đã bị ngăn xuất bản giao dịch. Nhóm SRE nhận thấy sự cố này và bắt đầu chuyển sang nhà cung cấp L1 RPC bên thứ ba nhằm giảm thiểu sự cố.
Vào lúc 11:24:16 sáng, 5 phút sau khi áp phích lô bắt đầu, nó đã cập nhật chế độ xem trạng thái L1 và xuất bản lô giao dịch đầu tiên.
Vào lúc 11:25:09 sáng, cấu hình áp phích lô đã được thay đổi để sử dụng nhà cung cấp L1 RPC bên thứ ba và được khởi động lại vì nhóm SRE đã bắt đầu thực hiện thay đổi này và không nhận thấy việc xử lý theo lô. Sau khi khởi động lại, các giao dịch hàng loạt tiếp tục diễn ra.
Lúc 11:30:21 sáng, 5 phút sau khi áp phích lô bắt đầu, chế độ xem trạng thái L1 đã được cập nhật, khiến trạng thái L1 không đồng bộ, đây cũng là nguyên nhân gốc rễ của sự cố. Trạng thái L1 đã được cập nhật thành số khối cuối cùng 17428199, nhưng nó đã sử dụng nonce mới nhất 178078, tương ứng với khối mới nhất vào thời điểm đó, thay vì khối cuối cùng được lưu trữ ở trạng thái của nó, dẫn đến tất cả các giao dịch được xếp hàng trong Redis đều bị xóa ngoại trừ, bởi vì Redis coi các giao dịch này đã được xác nhận.
Lúc 11:30:26 sáng, poster đợt hàng đăng đợt hàng mới. Redis dựa vào chế độ xem trạng thái L1 để xác định nội dung sẽ xuất bản, nhưng tại thời điểm này, hàng đợi Redis trống, như đã nêu trước đó, trạng thái L1 không chính xác và một lô đã được xuất bản với một số ngẫu nhiên ở trạng thái 178078, nhưng để xác định lô được xuất bản, sử dụng số khối không liên quan 17428199, dẫn đến một lô cũ có số sê-ri 229209 được xuất bản, lô này thực sự được xuất bản lúc 11:24:16 trước đó và sau đó người đăng lô đã khởi động lại. Vì lô cũ 229209 đã được xuất bản nên giao dịch L1 do lô này gửi đã được khôi phục.
Vào lúc 11:36:35 sáng, địa chỉ của người đăng lô đã hết Ether do không hoàn trả phí gas nên đã ngừng xuất bản. Đây là một cơ chế có chủ ý để ngăn người đăng lô tiêu thụ hết lượng gas được lưu trữ trong địa chỉ chi phí lô phục hồi.
Lúc 11:46 sáng, một thành viên của nhóm Nitro nhận được cuộc gọi yêu cầu giải quyết sự cố phần mềm với khôi phục hàng loạt.
Khoảng 11:58 sáng, Arbitrum bắt đầu nhận được báo cáo rằng một số người dùng nhận thấy rằng có sự cố với bộ sắp xếp (phát các giao dịch mới được sắp xếp tới các nút RPC), vì ngày càng có nhiều giao dịch được đặt hàng là do sự cố của người đăng hàng loạt thay vì đăng đối với chuỗi, sự cố này chủ yếu ảnh hưởng đến các máy khách nguồn cấp dữ liệu có kết nối internet kém hoặc phân bổ bộ nhớ không đủ, vì chúng có nhiều khả năng bị rớt và gặp sự cố kết nối lại. Arbitrum khuyến nghị người dùng chạy nhiều nút RPC nên chạy rơle nguồn cấp dữ liệu cục bộ để giảm yêu cầu băng thông bên ngoài.
Vào lúc 12:03 chiều, Arbitrum đã loại bỏ giới hạn tốc độ nguồn cấp dữ liệu của Cloudflare để giảm bớt sự cố khách hàng đạt đến giới hạn tốc độ khi cố gắng kết nối lại sau khi bị ngắt kết nối do kết nối internet.
Vào lúc 12:05 chiều, Arbitrum đã xóa tất cả giới hạn tốc độ của Cloudflare để cho phép tăng mức sử dụng RPC công khai cho những người có nút gặp sự cố khi duy trì kết nối với nguồn cấp dữ liệu.
Vào lúc 12:12:09 chiều, áp phích lô bị lỗi đã bị tắt và cửa hàng hàng đợi Redis bị xóa để loại bỏ trạng thái xấu.
Lúc 12:12:40 chiều, poster đợt bắt đầu trên phiên bản cũ v2.0.14 và không có vấn đề về root.
Vào lúc 12:21:56 chiều, đợt áp phích mới mở đầu tiên đã thành công và chúng đã chạy liên tục kể từ đó.
Bài học về lỗi sự kiện sắp xếp Arbitrum đã học
Lỗi này là do một lỗi trong áp phích lô. Bản thân trình sắp xếp thứ tự không bị ảnh hưởng hoặc bị gián đoạn và tiếp tục xử lý các giao dịch trong suốt quá trình. Các báo cáo rằng trình sắp xếp thứ tự đã hết tiền là không chính xác. Cơ chế tài trợ của Arbitrum bao gồm hai ví, cụ thể là: ví "sequencer" và ví "gas-refund". Chỉ khi trình sắp xếp thứ tự có thể giải phóng lô thành công thì nó mới được hoàn trả. Mạng Arbitrum chưa hoàn trả cho trình sắp xếp thứ tự cho việc này thất bại.tiền và các vấn đề liên quan không phải do trình sắp xếp thứ tự hết tiền gây ra, vì vậy không có tiền của người dùng nào gặp rủi ro.
Arbitrum sẽ dọn sạch các tùy chọn cấu hình đã được thêm vào trong giải pháp tạm thời. Sau đó, nó có kế hoạch đánh giá lại các vấn đề về thời gian chờ của máy khách và máy chủ trình tự sắp xếp để cải thiện độ tin cậy của mạng trong trường hợp tồn đọng giao dịch. Một "v2.1.0-beta" mới Phiên bản thử nghiệm .2". Ngoài ra, Arbitrum sẽ tạo một trang trạng thái mạng công khai để giảm nhầm lẫn nếu có vấn đề với dịch vụ.
Bài viết được tham khảo từ website chính thức của Arbitrum Foundation
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Golden Observation | Đánh giá sự kiện lỗi bộ sắp xếp Arbitrum
Tác giả: Tài chính vàng Jason
Jinjin Finance Blockchain, ngày 10 tháng 6 Một lỗi trong mã phân loại của Arbitrum trong tuần này đã khiến chức năng gửi giao dịch hàng loạt của mạng tạm thời bị gián đoạn và giao dịch không thể được xác nhận trên chuỗi chính. Lỗ hổng này đã được khắc phục và chức năng gửi lô giao dịch đã được khôi phục. Vào ngày 10 tháng 6, Tổ chức Arbitrum đã công bố báo cáo phân tích sau sự kiện về lỗi bộ sắp xếp Arbitrum. Tiếp theo, hãy xem xét trường hợp và xem tại sao sự kiện lỗi này không làm mất tiền của người dùng.
Tiến trình sự kiện lỗi Arbitrum Sorter
Vào lúc 06:04:53 ngày 7 tháng 6 năm 2023, nhà phát hành lô không thể cập nhật chế độ xem trạng thái L1 của mình do sự cố tạm thời với nút L1 của bộ đối chiếu Arbitrum. Do sự cố nguyên nhân gốc rễ, bộ sắp xếp Arbitrum tiếp tục cố gắng truy vấn trạng thái của số khối chế độ xem L1 trước đó. Điều này có nghĩa là ngay cả sau khi sự cố nút L1 tạm thời tự giải quyết, nhà xuất bản lô sẽ tiếp tục truy vấn trạng thái của số khối L1 cũ và nút L1 không còn trạng thái của nó nữa vì nó không phải là nút lưu trữ.
Vào lúc 09:38:28 ngày 7 tháng 6 năm 2023, người đăng lô của Arbitrum đã ngừng xuất bản các giao dịch vì đã đạt đến giới hạn giao dịch xếp hàng đợi tối đa được định cấu hình (256), bằng với giới hạn của mempool. Nếu không đạt đến giới hạn này, việc đăng hàng loạt sẽ tiếp tục như bình thường.
Vào lúc 11:09 sáng ngày 7 tháng 6 năm 2023, do các lô chưa được công bố, một cảnh báo đã được kích hoạt trên hợp đồng thông minh Hộp thư đến Sequencer để kiểm tra các lô mới và một cảnh báo đã được gửi đến kênh Slack.
Vào lúc 11:10 sáng, việc thiếu các bản phát hành hàng loạt gần đây đã kích hoạt cảnh báo dựa trên nhật ký và gửi cảnh báo mức độ quan trọng đến kênh Slack.
Vào lúc 11:13 sáng, một thành viên của nhóm cộng đồng đã khởi xướng PagerDuty cùng với một thành viên của nhóm SRE, người này đã nhanh chóng thừa nhận sự cố và bắt đầu phản hồi.
Vào lúc 11:19:02 sáng, nhóm SRE đã khởi động lại áp phích lô, nhưng do giới hạn giao dịch xếp hàng đợi tối đa đã đề cập trước đó, áp phích lô đã bị ngăn xuất bản giao dịch. Nhóm SRE nhận thấy sự cố này và bắt đầu chuyển sang nhà cung cấp L1 RPC bên thứ ba nhằm giảm thiểu sự cố.
Vào lúc 11:24:16 sáng, 5 phút sau khi áp phích lô bắt đầu, nó đã cập nhật chế độ xem trạng thái L1 và xuất bản lô giao dịch đầu tiên.
Vào lúc 11:25:09 sáng, cấu hình áp phích lô đã được thay đổi để sử dụng nhà cung cấp L1 RPC bên thứ ba và được khởi động lại vì nhóm SRE đã bắt đầu thực hiện thay đổi này và không nhận thấy việc xử lý theo lô. Sau khi khởi động lại, các giao dịch hàng loạt tiếp tục diễn ra.
Lúc 11:30:21 sáng, 5 phút sau khi áp phích lô bắt đầu, chế độ xem trạng thái L1 đã được cập nhật, khiến trạng thái L1 không đồng bộ, đây cũng là nguyên nhân gốc rễ của sự cố. Trạng thái L1 đã được cập nhật thành số khối cuối cùng 17428199, nhưng nó đã sử dụng nonce mới nhất 178078, tương ứng với khối mới nhất vào thời điểm đó, thay vì khối cuối cùng được lưu trữ ở trạng thái của nó, dẫn đến tất cả các giao dịch được xếp hàng trong Redis đều bị xóa ngoại trừ, bởi vì Redis coi các giao dịch này đã được xác nhận.
Lúc 11:30:26 sáng, poster đợt hàng đăng đợt hàng mới. Redis dựa vào chế độ xem trạng thái L1 để xác định nội dung sẽ xuất bản, nhưng tại thời điểm này, hàng đợi Redis trống, như đã nêu trước đó, trạng thái L1 không chính xác và một lô đã được xuất bản với một số ngẫu nhiên ở trạng thái 178078, nhưng để xác định lô được xuất bản, sử dụng số khối không liên quan 17428199, dẫn đến một lô cũ có số sê-ri 229209 được xuất bản, lô này thực sự được xuất bản lúc 11:24:16 trước đó và sau đó người đăng lô đã khởi động lại. Vì lô cũ 229209 đã được xuất bản nên giao dịch L1 do lô này gửi đã được khôi phục.
Vào lúc 11:36:35 sáng, địa chỉ của người đăng lô đã hết Ether do không hoàn trả phí gas nên đã ngừng xuất bản. Đây là một cơ chế có chủ ý để ngăn người đăng lô tiêu thụ hết lượng gas được lưu trữ trong địa chỉ chi phí lô phục hồi.
Lúc 11:46 sáng, một thành viên của nhóm Nitro nhận được cuộc gọi yêu cầu giải quyết sự cố phần mềm với khôi phục hàng loạt.
Khoảng 11:58 sáng, Arbitrum bắt đầu nhận được báo cáo rằng một số người dùng nhận thấy rằng có sự cố với bộ sắp xếp (phát các giao dịch mới được sắp xếp tới các nút RPC), vì ngày càng có nhiều giao dịch được đặt hàng là do sự cố của người đăng hàng loạt thay vì đăng đối với chuỗi, sự cố này chủ yếu ảnh hưởng đến các máy khách nguồn cấp dữ liệu có kết nối internet kém hoặc phân bổ bộ nhớ không đủ, vì chúng có nhiều khả năng bị rớt và gặp sự cố kết nối lại. Arbitrum khuyến nghị người dùng chạy nhiều nút RPC nên chạy rơle nguồn cấp dữ liệu cục bộ để giảm yêu cầu băng thông bên ngoài.
Vào lúc 12:03 chiều, Arbitrum đã loại bỏ giới hạn tốc độ nguồn cấp dữ liệu của Cloudflare để giảm bớt sự cố khách hàng đạt đến giới hạn tốc độ khi cố gắng kết nối lại sau khi bị ngắt kết nối do kết nối internet.
Vào lúc 12:05 chiều, Arbitrum đã xóa tất cả giới hạn tốc độ của Cloudflare để cho phép tăng mức sử dụng RPC công khai cho những người có nút gặp sự cố khi duy trì kết nối với nguồn cấp dữ liệu.
Vào lúc 12:12:09 chiều, áp phích lô bị lỗi đã bị tắt và cửa hàng hàng đợi Redis bị xóa để loại bỏ trạng thái xấu.
Lúc 12:12:40 chiều, poster đợt bắt đầu trên phiên bản cũ v2.0.14 và không có vấn đề về root.
Vào lúc 12:21:56 chiều, đợt áp phích mới mở đầu tiên đã thành công và chúng đã chạy liên tục kể từ đó.
Bài học về lỗi sự kiện sắp xếp Arbitrum đã học
Lỗi này là do một lỗi trong áp phích lô. Bản thân trình sắp xếp thứ tự không bị ảnh hưởng hoặc bị gián đoạn và tiếp tục xử lý các giao dịch trong suốt quá trình. Các báo cáo rằng trình sắp xếp thứ tự đã hết tiền là không chính xác. Cơ chế tài trợ của Arbitrum bao gồm hai ví, cụ thể là: ví "sequencer" và ví "gas-refund". Chỉ khi trình sắp xếp thứ tự có thể giải phóng lô thành công thì nó mới được hoàn trả. Mạng Arbitrum chưa hoàn trả cho trình sắp xếp thứ tự cho việc này thất bại.tiền và các vấn đề liên quan không phải do trình sắp xếp thứ tự hết tiền gây ra, vì vậy không có tiền của người dùng nào gặp rủi ro.
Arbitrum sẽ dọn sạch các tùy chọn cấu hình đã được thêm vào trong giải pháp tạm thời. Sau đó, nó có kế hoạch đánh giá lại các vấn đề về thời gian chờ của máy khách và máy chủ trình tự sắp xếp để cải thiện độ tin cậy của mạng trong trường hợp tồn đọng giao dịch. Một "v2.1.0-beta" mới Phiên bản thử nghiệm .2". Ngoài ra, Arbitrum sẽ tạo một trang trạng thái mạng công khai để giảm nhầm lẫn nếu có vấn đề với dịch vụ.
Bài viết được tham khảo từ website chính thức của Arbitrum Foundation