Sự cố xử lý giao dịch chậm trên XRP Ledger (XRPL) đã phơi bày một điểm yếu vận hành của mạng blockchain này: khi tải tăng mạnh, hệ thống giám sát nội bộ và khả năng ghi log chẩn đoán có thể bị suy giảm đáng kể.

Theo U.Today ngày 21/10 (giờ địa phương), David Schwartz, giám đốc công nghệ của Ripple và đồng phát triển XRPL, đã công khai chia sẻ về những điểm dễ tổn thương bộc lộ sau đợt chậm trễ vừa qua.

Vấn đề được phát hiện khi đội ngũ vận hành nhận thấy tốc độ đóng sổ cái của XRPL chậm bất thường. Trong quá trình truy tìm nguyên nhân, cộng đồng bắt đầu đặt câu hỏi về độ tin cậy của hệ thống phân tán, đặc biệt là khả năng một số hub quan trọng bị quá tải có thể ảnh hưởng đến toàn mạng.

Schwartz cho biết XRPL được thiết kế với nhiều lớp bảo vệ độc lập. Theo ông, chỉ có hai kịch bản thực sự có thể làm tê liệt toàn bộ mạng.

Kịch bản thứ nhất là sự cố hạ tầng quy mô lớn, khiến nhiều máy chủ xác thực trên toàn cầu đồng thời ngừng hoạt động. Ông nhận định để xảy ra tình huống này gần như phải có một thảm họa thiên nhiên ở quy mô toàn cầu. Kịch bản thứ hai là thuật toán đồng thuận giữa các nút gặp trục trặc, hoặc xuất hiện lỗi mã nguồn làm hỏng một chức năng trọng yếu của giao thức lõi.

Dù vậy, Schwartz cho rằng đợt suy giảm tốc độ lần này là tín hiệu cho thấy dư địa an toàn của hệ thống đã bị thu hẹp trong thời gian ngắn. Theo ông, đây có thể là dấu hiệu của một cuộc tấn công nhắm vào XRPL, hoặc một lỗi tiềm ẩn trong mã nguồn vừa bị kích hoạt.

Ông cũng bác bỏ lo ngại về “điểm lỗi đơn”. Schwartz khẳng định việc hub của ông hay bất kỳ hub nào khác gặp sự cố hoặc quá tải cũng không thể khiến XRPL ngừng hoạt động. Theo ông, mạng được phân tán hoàn toàn, vì vậy trục trặc ở một nút riêng lẻ sẽ không làm tê liệt toàn hệ thống.

Điểm đáng lo ngại hơn nằm ở khâu giám sát. Khi các vòng đồng thuận chậm lại, máy chủ xác thực bị đẩy lên mức tải tối đa, trong khi hệ thống giám sát nội bộ không thể ghi nhận đầy đủ dữ liệu phục vụ chẩn đoán.

Schwartz cho biết ông đã phải khởi động lại máy chủ dù khi đó vẫn chưa xác định được nguyên nhân chính xác. Các trao đổi sau đó cũng cho thấy hub của ông đang gửi log tới một máy chủ thử nghiệm cũ của XRP Ledger Foundation (XRPLF). Chính cách cấu hình và vận hành này đã làm lộ rõ lỗ hổng trong hệ thống chẩn đoán.

Hiện các kỹ sư và quản trị viên trong cộng đồng đang phân tích thủ công phần log còn lại để xác định nguyên nhân và khắc phục lỗi. Schwartz thừa nhận mức an toàn của hệ thống đã giảm trong thời gian ngắn, nhưng cho rằng tình hình chưa đến mức đáng báo động. Ông nói nhóm phát triển vẫn kiểm soát được diễn biến và cấu trúc mã hiện tại vẫn còn đủ dư địa để duy trì hoạt động của mạng.

Theo Schwartz, thách thức lớn hơn của XRPL không nằm ở bản thân kiến trúc phân tán, mà ở khả năng duy trì dữ liệu chẩn đoán và năng lực quan sát vận hành khi hệ thống chịu tải cao. Vì vậy, các bước điều tra tiếp theo sẽ không chỉ tập trung vào nguyên nhân trực tiếp gây ra độ trễ, mà còn xem xét cách duy trì việc thu thập log và giám sát hệ thống khi các máy chủ xác thực rơi vào tình trạng quá tải.

Ông nói thêm rằng hub của mình có thể vẫn hoạt động bình thường trong thời điểm xảy ra sự cố, nhưng rất khó đưa ra kết luận chắc chắn vì chính sự cố đã làm ảnh hưởng đến hệ thống giám sát. Schwartz nhắc lại rằng XRPL không bị tác động chỉ vì một hub riêng lẻ ngừng hoạt động. Theo ông, rủi ro thực sự đối với sự ổn định của toàn mạng chỉ xuất hiện khi nhiều máy chủ đồng loạt gặp lỗi, hoặc khi phát sinh trục trặc ở cấp độ đồng thuận hay một chức năng cốt lõi của giao thức. Ông nhấn mạnh phần mềm XRPL có nhiều tầng bảo vệ độc lập để tạo ra dư địa an toàn lớn; nếu xuất hiện dấu hiệu cho thấy dư địa này suy giảm, nhóm phát triển sẽ truy vết và khắc phục. Các vòng đồng thuận chậm lại có thể là dấu hiệu của tấn công hoặc lỗi kỹ thuật, nhưng theo ông, nếu các nhà phát triển chủ chốt chưa hoảng loạn thì nhiều khả năng mức an toàn của hệ thống vẫn còn khá lớn.