423 kết nối đồng thời trên hub riêng XRPL, chỉ số lạm dụng gần 0

Số kết nối đồng thời trên một hub riêng của XRP Ledger (XRPL) đã đạt mức cao nhất là 423, trong khi chỉ số lưu lượng mang tính lạm dụng "Abuse" giảm xuống gần mức 0. Đây được xem là dấu hiệu cho thấy trạng thái kết nối của hub đã ổn định trở lại sau sự cố tràn manifest (manifest flood) trước đó.

David Schwartz, người giữ chức Giám đốc công nghệ danh dự của Ripple (XRP), đã công bố dữ liệu đo lường từ hub riêng nói trên trong khoảng thời gian từ ngày 25/8 đến ngày 8/9. Theo đó, hub này duy trì trung bình khoảng 400 kết nối đồng thời, với số lượng kết nối tối đa ghi nhận được là 423.

Số liệu lần này phản ánh tình trạng hạ tầng mạng lưới sau sự cố tràn manifest xảy ra trên XRP Ledger vào cuối tháng 7. Tuy nhiên, đây chỉ là số liệu quan sát từ một hub riêng lẻ, nên không thể đại diện cho toàn bộ trạng thái của mạng XRP Ledger.

Manifest là thông tin liên kết danh tính của validator với khóa ký (signing key). Báo cáo lỗ hổng chính thức của XRP Ledger cho biết vào khoảng ngày 31/7 (giờ Hàn Quốc), các thông điệp manifest đã lan truyền ồ ạt trên mạng ngang hàng (peer-to-peer), khiến kết nối của nhiều node bị ngắt.

Quá trình đồng thuận sổ cái và xử lý giao dịch không bị gián đoạn. Cũng không ghi nhận trường hợp mất tài sản, rò rỉ khóa riêng tư hay tổn hại đến tính toàn vẹn của sổ cái.

Nguyên nhân do cạn kiệt tài nguyên ở lớp peer

Vấn đề cốt lõi lần này không nằm ở việc đồng thuận thất bại, mà ở việc tài nguyên tại lớp peer (peer layer) bị cạn kiệt. Lớp peer là tầng mạng giúp các node duy trì kết nối và trao đổi thông tin với nhau. Khi mức sử dụng tài nguyên ở tầng này tăng đột biến, độ ổn định kết nối của một số node có thể suy giảm, dù quá trình đồng thuận sổ cái vẫn diễn ra bình thường.

Báo cáo chính thức đưa ra một số khả năng, bao gồm việc số lượng node phiên bản cũ tăng đột ngột cùng lúc, bộ nhớ đệm (cache) chứa manifest cũ vẫn còn tồn đọng, hoặc một phiên bản "xrpld" đã bị chỉnh sửa có liên quan. Nguyên nhân cụ thể và chủ thể gây ra sự cố vẫn chưa được xác định.

Báo cáo cũng chưa khẳng định liệu sự cố tràn manifest là hành vi cố ý hay chỉ là lỗi phát sinh trong quá trình thử nghiệm. Do đó, chưa thể kết luận đây là hành động của một kẻ tấn công cụ thể nào.

Bản vá xrpld 3.2.1 và các điều chỉnh tiếp theo

Đội ngũ phát triển đã phát hành phiên bản "xrpld 3.2.1" vào ngày 31/7. Ghi chú phát hành cho biết phiên bản này đã khắc phục lỗi khiến bộ nhớ và tài nguyên xử lý có thể bị tiêu tốn quá mức trong quá trình lan truyền manifest của validator.

Các đơn vị vận hành node cũng được hướng dẫn thực hiện một lần khởi động lại bình thường sau khi nâng cấp. Theo báo cáo hậu sự cố, biện pháp xử lý bao gồm giới hạn dung lượng lưu trữ manifest từ các validator chưa được tin cậy, đồng thời đặt giới hạn cho kích thước từng manifest, số lượng mục trong mỗi thông điệp và quy mô bộ nhớ đệm.

Phiên bản "xrpld 3.3.0" được phát hành sau đó đã bổ sung thêm các điều chỉnh liên quan đến những giới hạn này. TokenPost trước đó từng đề cập đến quy trình kiểm chứng bản sửa lỗi của XRP Ledger phiên bản 3.3.0.

Số liệu về hub mà Schwartz công bố cho thấy trạng thái kết nối của hub này đã ổn định trở lại sau khi bản vá được áp dụng. Chỉ số "Abuse" giảm xuống gần mức 0 cũng là thay đổi được ghi nhận trong cùng giai đoạn.

Tuy nhiên, không thể diễn giải rộng số liệu này thành kết luận rằng toàn bộ XRP Ledger đã trở lại trạng thái hoàn toàn bình thường, do phạm vi đo lường của một hub đơn lẻ khác với trạng thái của toàn mạng lưới.

Trường hợp lần này cho thấy dù quá trình đồng thuận sổ cái và xử lý giao dịch vẫn được duy trì, các lớp hạ tầng như kết nối peer hay xử lý manifest vẫn có thể ảnh hưởng đến khả năng sẵn sàng của mạng lưới. Trong thời gian tới, vấn đề cần theo dõi là liệu bản vá và các giới hạn xử lý manifest có được duy trì đúng cách trên môi trường vận hành của từng node hay không.