#MultiversXPlansHardForkRecovery A Một lỗ hổng về tính nguyên tử ở cấp VM (VM-level atomicity) đã khiến MultiversX bị dừng mạng hoàn toàn — hiện tại bản nâng cấp hard fork đang được thử nghiệm như một hướng khôi phục.
• MultiversX xác định nguyên nhân gốc là một vấn đề về tính nguyên tử ở cấp VM, liên quan đến lỗi sắp xếp trong một trường hợp biên cụ thể.
• Các trình xác thực đã dừng tiến trình mạng để khống chế sự cố và ngăn tác động lan rộng hơn.
• Nhóm đã chuẩn bị các thay đổi mã và đang thử nghiệm quy trình khôi phục.
• Kế hoạch khôi phục là một hard fork phối hợp từ một checkpoint đã được xác minh là “đã hoạt động tốt” (known-good).
• Các trình xác thực dự kiến sẽ diễn tập quy trình trên Testnet và Devnet trước khi thực hiện khôi phục trên mainnet.
• Người dùng được yêu cầu không gửi hoặc phát lại (rebroadcast) giao dịch, và tránh nạp/rút EGLD/ESDT thông qua các sàn giao dịch và cầu nối (bridges) cho đến khi có thông báo “đã an toàn” chính thức.
Đây là chỗ tôi nghĩ câu chuyện trở nên thú vị hơn.
Bản thân hard fork không phải phần mà tôi theo dõi sát nhất. Thử thách thực sự là liệu MultiversX có thể khôi phục mạng một cách sạch sẽ hay không, đồng thời vẫn bảo toàn trạng thái hợp lệ và loại bỏ những thay đổi không hợp lệ do lỗ hổng khai thác (exploit) tạo ra.
Nghe có vẻ đơn giản trên giấy. Nhưng không phải vậy.
Một quy trình khôi phục như thế này phải đồng bộ các trình xác thực, các sàn giao dịch, cầu nối, nhà cung cấp hạ tầng và người dùng cùng thống nhất một trạng thái chuỗi. Chỉ cần một mắt xích yếu cũng có thể biến một cách khôi phục mang tính kỹ thuật thành một “mớ hỗn độn” về mặt vận hành.
Vì vậy tôi ít quan tâm đến tiêu đề “hard fork sắp tới” và quan tâm nhiều hơn đến việc liệu quy trình khôi phục có thực sự hoạt động dưới những điều kiện thực tế được phối hợp hay không.
Điều đó cho tôi biết nhiều hơn về khả năng phục hồi (resilience) của mạng so với thông báo khởi động lại (restart) ngay chính nó.
Tuy vậy, tôi vẫn đang cố tìm xem chính xác việc này thay đổi điều gì.
• MultiversX xác định nguyên nhân gốc là một vấn đề về tính nguyên tử ở cấp VM, liên quan đến lỗi sắp xếp trong một trường hợp biên cụ thể.
• Các trình xác thực đã dừng tiến trình mạng để khống chế sự cố và ngăn tác động lan rộng hơn.
• Nhóm đã chuẩn bị các thay đổi mã và đang thử nghiệm quy trình khôi phục.
• Kế hoạch khôi phục là một hard fork phối hợp từ một checkpoint đã được xác minh là “đã hoạt động tốt” (known-good).
• Các trình xác thực dự kiến sẽ diễn tập quy trình trên Testnet và Devnet trước khi thực hiện khôi phục trên mainnet.
• Người dùng được yêu cầu không gửi hoặc phát lại (rebroadcast) giao dịch, và tránh nạp/rút EGLD/ESDT thông qua các sàn giao dịch và cầu nối (bridges) cho đến khi có thông báo “đã an toàn” chính thức.
Đây là chỗ tôi nghĩ câu chuyện trở nên thú vị hơn.
Bản thân hard fork không phải phần mà tôi theo dõi sát nhất. Thử thách thực sự là liệu MultiversX có thể khôi phục mạng một cách sạch sẽ hay không, đồng thời vẫn bảo toàn trạng thái hợp lệ và loại bỏ những thay đổi không hợp lệ do lỗ hổng khai thác (exploit) tạo ra.
Nghe có vẻ đơn giản trên giấy. Nhưng không phải vậy.
Một quy trình khôi phục như thế này phải đồng bộ các trình xác thực, các sàn giao dịch, cầu nối, nhà cung cấp hạ tầng và người dùng cùng thống nhất một trạng thái chuỗi. Chỉ cần một mắt xích yếu cũng có thể biến một cách khôi phục mang tính kỹ thuật thành một “mớ hỗn độn” về mặt vận hành.
Vì vậy tôi ít quan tâm đến tiêu đề “hard fork sắp tới” và quan tâm nhiều hơn đến việc liệu quy trình khôi phục có thực sự hoạt động dưới những điều kiện thực tế được phối hợp hay không.
Điều đó cho tôi biết nhiều hơn về khả năng phục hồi (resilience) của mạng so với thông báo khởi động lại (restart) ngay chính nó.
Tuy vậy, tôi vẫn đang cố tìm xem chính xác việc này thay đổi điều gì.