#xrpledgerpatchesxrpcreationbug
Nếu một lỗi phần mềm có thể tạo ra XRP từ hư không mà không ai phát hiện trong khoảng một thập kỷ thì sao? Đó là câu hỏi đằng sau thông báo mới nhất của XRPL. 🔍
Ngày 9 tháng 10, XRP Ledger công bố một lỗ hổng nghiêm trọng trong bộ xử lý thanh toán, vốn đã được khắc phục từ vài tuần trước. Dưới đây là dòng thời gian:
Ngày 22 tháng 9: Các nhà nghiên cứu Cayden Liao và Veria AI báo cáo lỗi tràn số nguyên thông qua chương trình săn lỗi.
Ngày 25 tháng 9: xrpld 3.4.1 được phát hành kèm các bước kiểm tra tràn số, như một bản vá khẩn cấp mà không cần cuộc bỏ phiếu sửa đổi của các validator như thường lệ, nhằm tránh để lỗ hổng bị phơi bày trong thời gian bỏ phiếu công khai.
Cùng ngày: Theo thông tin được đưa ra, hơn 80% validator mặc định đã chạy phiên bản được vá.
Theo thông báo, kẻ tấn công sẽ cần hàng trăm lệnh chào mua/bán được định giá cẩn thận và một giao dịch thanh toán duy nhất để có khả năng tạo ra lượng XRP có thể sử dụng vượt quá tổng cung 100 tỷ. RippleX đã tái hiện sự cố trên một máy chủ độc lập và cho biết không tìm thấy bằng chứng nào cho thấy lỗ hổng bị khai thác. Một lỗi thứ hai, có mức độ nghiêm trọng thấp hơn, ảnh hưởng đến tính năng Batch, vốn chưa được kích hoạt trên mainnet.
Vì sao điều này quan trọng: XRP có nguồn cung cố định được phát hành trước, nên bất kỳ lượng XRP nào được tạo ra ngoài dự kiến cũng sẽ đụng đến một giả định cốt lõi. Phản ứng nhanh chóng và việc phát hiện lỗi nhờ chương trình săn lỗi là những dấu hiệu đáng khích lệ đối với bảo mật mạng lưới, trong khi quyết định bỏ qua quy trình bỏ phiếu thông thường có thể làm dấy lên những câu hỏi về quản trị.
Tuy vậy, “không có bằng chứng” không đồng nghĩa với bằng chứng rằng việc đó chưa xảy ra, và thông báo được đưa ra sau khi lỗi đã được khắc phục. Trong những tình huống như thế này, các mạng lưới nên minh bạch đến mức nào, và vào thời điểm nào?
$MAGIC $LUMIA $XRP
Nếu một lỗi phần mềm có thể tạo ra XRP từ hư không mà không ai phát hiện trong khoảng một thập kỷ thì sao? Đó là câu hỏi đằng sau thông báo mới nhất của XRPL. 🔍
Ngày 9 tháng 10, XRP Ledger công bố một lỗ hổng nghiêm trọng trong bộ xử lý thanh toán, vốn đã được khắc phục từ vài tuần trước. Dưới đây là dòng thời gian:
Ngày 22 tháng 9: Các nhà nghiên cứu Cayden Liao và Veria AI báo cáo lỗi tràn số nguyên thông qua chương trình săn lỗi.
Ngày 25 tháng 9: xrpld 3.4.1 được phát hành kèm các bước kiểm tra tràn số, như một bản vá khẩn cấp mà không cần cuộc bỏ phiếu sửa đổi của các validator như thường lệ, nhằm tránh để lỗ hổng bị phơi bày trong thời gian bỏ phiếu công khai.
Cùng ngày: Theo thông tin được đưa ra, hơn 80% validator mặc định đã chạy phiên bản được vá.
Theo thông báo, kẻ tấn công sẽ cần hàng trăm lệnh chào mua/bán được định giá cẩn thận và một giao dịch thanh toán duy nhất để có khả năng tạo ra lượng XRP có thể sử dụng vượt quá tổng cung 100 tỷ. RippleX đã tái hiện sự cố trên một máy chủ độc lập và cho biết không tìm thấy bằng chứng nào cho thấy lỗ hổng bị khai thác. Một lỗi thứ hai, có mức độ nghiêm trọng thấp hơn, ảnh hưởng đến tính năng Batch, vốn chưa được kích hoạt trên mainnet.
Vì sao điều này quan trọng: XRP có nguồn cung cố định được phát hành trước, nên bất kỳ lượng XRP nào được tạo ra ngoài dự kiến cũng sẽ đụng đến một giả định cốt lõi. Phản ứng nhanh chóng và việc phát hiện lỗi nhờ chương trình săn lỗi là những dấu hiệu đáng khích lệ đối với bảo mật mạng lưới, trong khi quyết định bỏ qua quy trình bỏ phiếu thông thường có thể làm dấy lên những câu hỏi về quản trị.
Tuy vậy, “không có bằng chứng” không đồng nghĩa với bằng chứng rằng việc đó chưa xảy ra, và thông báo được đưa ra sau khi lỗi đã được khắc phục. Trong những tình huống như thế này, các mạng lưới nên minh bạch đến mức nào, và vào thời điểm nào?
$MAGIC $LUMIA $XRP