Phân tích lỗi của AvalancheGo v1.9.12 trên X-Chain

Avalanche Primary Network đã trải qua 2 khoảng thời gian ngắn không ổn định (134 phút vào ngày 22/03/23 và 82 phút vào ngày 26/03/23) do một lỗi ở quá trình xác thực OperationTx được giới thiệu trong quá trình tái cấu trúc X-Chain. Subnets của Avalanche, chạy độc lập về mặt đồng thuận so với mạng chính, vẫn hoàn tất các khối như bình thường trong suốt 2 khoảng thời gian này.

Sự cố: Sửa đổi sai lầm của X-Chain để chuẩn bị cho Cortina (036e34)

Trước đó, thực hiện các chuyển đổi trạng thái của X-Chain được phân tán trên nhiều tệp với nhiều trừu tượng khác nhau:

• Giao diện UnsignedTx mong đợi các UTXO đã sử dụng: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/tx.go#L35
  – avax.BaseTx thường được chia sẻ cung cấp triển khai điều này chức năng cho hầu hết tất cả các giao dịch: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/components/avax/base_tx.go#L36
  – Phương thức này bị ImportTx và OperationTx ghi đè
  – ImportTx không thực sự giới thiệu mọi UTXO đã tiêu thụ bổ sung từ trạng thái chuỗi cục bộ. ImportTx chỉ giới thiệu các đầu vào tượng trưng được sử dụng để xác định xung đột trong phiên bản đồng thuận của Avalanche: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/import_tx.go#L33
  – OperationTx giới thiệu các UTXO được tiêu thụ bổ sung từ trạng thái cục bộ
• UTXO được tạo cho các sửa đổi trạng thái cục bộ được tính toán bởi cấu trúc Tx đã ký bằng cách sử dụng khách truy cập để truy cập các trường của cấu trúc UnsignedTx cơ bản: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/tx.go#L87
  – Bạn có thể tìm thấy việc triển khai trình truy cập xây dựng UTXO tại đây: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/visitor.go
  – Cấu trúc utxoGetter này là cấu trúc cơ sở để tạo cấu trúc Executor
• Các sửa đổi trạng thái cục bộ sau đó đã được thực hiện trong quá trình chấp nhận giao dịch: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/unique_tx.go#L155-L167
• Các thay đổi bộ nhớ dùng chung sau đó được áp dụng cho cơ sở dữ liệu trong cấu trúc khách truy cập execTx: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/tx_execute.go#L16

Trong nỗ lực thống nhất và đơn giản hóa các đường dẫn mã trước và sau tuyến tính hóa trước Cortina, tất cả logic chuyển đổi trạng thái này đã được di chuyển đến một vị trí duy nhất. Tuy nhiên, trường hợp đặc biệt xung quanh OperationTx UTXO bổ sung đã không được di chuyển đúng cách: https://github.com/ava-labs/avalanchego/commit/036e34f143836dada1409af104e150f4b22598be

Việc phát hành bộ tái cấu trúc này, được giới thiệu trong v1.9.12, có nghĩa là các node đang chạy v1.9.11 đã thực hiện các giao dịch OperationTx khác với các node đang chạy v1.9.12.

Khắc phục: Khôi phục Kiểm tra tính hợp lệ bị thiếu về trạng thái OperationTx và sửa chữa ( v1.9.12…v1.9.16 )

Để khắc phục hồi quy này, logic bị thiếu từ phiên bản 1.9.11 xử lý OperationTx đã được giới thiệu lại để bảo vệ chống lại việc thực hiện sai bất kỳ giao dịch nào khác. Bản vá này đã được xuất xưởng trong v1.9.14.

Vì một số ít giao dịch OperationTx đã được chấp nhận trên X-Chain trong khi phần lớn Mạng Avalanche đang chạy phiên bản 1.9.12, nên điều tiếp theo cần làm là căn chỉnh lại trạng thái chuẩn trên các node chạy phiên bản 1.9.11, v1.9.12, và v1.9.14. Điều này đã được hoàn thành khi trình xác thực nâng cấp lên v1.9.15. Không thể phát hành thay đổi này như một phần của phiên bản 1.9.14 vì cần phải ngăn chặn việc thực thi sai trước khi thực hiện căn chỉnh lại trạng thái (nếu không thì sẽ không thể tính toán trạng thái xác định để căn chỉnh lại).

Tuy nhiên, ngay sau khi v1.9.15 được phát hành, chúng tôi nhận thấy rằng số lượng đỉnh xử lý trên X-Chain vẫn ở mức 2 (thay vì trôi nổi trong phạm vi thông thường là ~0–3):

Sau khi nghiên cứu thêm, chúng tôi đã tìm thấy một mục còn lại được thêm vào trạng thái trước v1.9.14 không được căn chỉnh lại đúng cách trong v1.9.15. Lần căn chỉnh lại cuối cùng đã hoàn tất khi trình xác thực nâng cấp lên v1.9.16.

Tác động: 2 giai đoạn ngắn về sự mất ổn định của mạng trên C-Chain và P-Chain

Trong khoảng thời gian mà hành vi xác thực đã được sửa đổi trong v1.9.14 và khi trạng thái được căn chỉnh lại trong v1.9.16, việc chấp nhận khối bị trì hoãn trên cả C-Chain và P-Chain (X-Chain đã chấp nhận các giao dịch mới trong cả hai giai đoạn ):

• 7:24 PM ET đến 9:38 PM ET ngày 22/3/23 [134 phút]

• 6:36 AM ET đến 7:58 AM ET ngày 26/3/23 [82 phút]

Trong trường hợp đầu tiên, một số lượng đáng kể trình xác thực chưa được cập nhật lên phiên bản mới nhất hiện có của AvalancheGo và do đó đang chạy với các quy tắc thực thi khác. Trong trường hợp thứ hai, một số lượng đáng kể trình xác thực có trạng thái không liên kết. Sau khi có thêm nhiều trình xác nhận được cập nhật lên phiên bản AvalancheGo mới nhất mỗi lần, Mạng Avalanche sẽ lấy lại được sự ổn định.

Phần lớn các Subnet tiếp tục hoàn thiện các khối, như được thiết kế, ngay cả khi có sự tăng đột biến trong các khối chưa hoàn thiện trên Mạng chính (ảnh chụp màn hình vào ngày 22/3/23):

Tuy nhiên, một số API Subnet không thể truy cập được trong giai đoạn không ổn định này do các node trả về trạng thái không tốt và bị xóa khỏi bộ cân bằng tải được liên kết của chúng mặc dù chúng vẫn có thể phân phối lưu lượng truy cập và đang chấp nhận các khối mới (node sẽ trả về trạng thái không tốt nếu BẤT KỲ khía cạnh nào của node đều không lành mạnh, ngay cả khi một Subnet cụ thể vẫn ổn). Điều này dẫn đến việc giảm thông lượng giao dịch vì nhiều người dùng dựa vào các điểm cuối có thể truy cập công khai không thể phát hành giao dịch và các trình khám phá đọc dữ liệu từ các điểm cuối này không thể lập chỉ mục dữ liệu mới:

Nhìn về phía trước

Để thêm thử nghiệm hồi quy bổ sung vào X-Chain càng sớm càng tốt, lịch trình kích hoạt Cortina trên Fuji sẽ bị trì hoãn 1 tuần. Mã kích hoạt Fuji hiện sẽ được phát hành vào ngày 3/4/23 và Cortina sẽ kích hoạt trên Fuji vào ngày 6/4/23.

Chúng tôi đã khởi động nỗ lực đồng bộ hóa trạng thái X-Chain để bảo vệ chống lại sự khác biệt trong thực thi thầm lặng và để bỏ chặn Đồng bộ hóa trạng thái vài tháng trước. Sản phẩm đầu tiên của luồng công việc này là bản phát hành ALPHA của x/merkledb và nó tiếp tục ở Cortina với việc bổ sung trường gốc trạng thái chưa sử dụng ở định dạng khối X-Chain mới: https://github.com/ava-labs/avalanchego/blob/7d73b59cb4838d304387ea680b9cc4053b72620c/vms/avm/blocks/standard_block.go#L25. Sau khi x/merkledb sẵn sàng sản xuất, trường gốc trạng thái này sẽ được tính toán và xác minh trong quá trình thực thi khối X-Chain để đảm bảo bất kỳ phương sai nào trong quá trình thực hiện giao dịch đều nhanh chóng được phát hiện trong quá trình thử nghiệm và thời gian chạy. Chúng tôi đang kiểm tra căng thẳng x/merkledb trong HyperSDK và đã bắt đầu cuộc kiểm tra đầu tiên của mình.

Để cải thiện UX Subnet, AvalancheGo sẽ giới thiệu kiểm tra tình trạng trong phạm vi Subnet, cho phép các nhà tích hợp Subnet tiếp tục phục vụ các yêu cầu API phía sau bộ cân bằng tải nếu có sự không ổn định trên một Subnet khác chạy trên một node nhất định. Đây là một bước nữa trong hành trình tiếp tục để đảm bảo có sự cách ly lỗi lớn giữa các Subnet trên Avalanche.

Chúng tôi đánh giá cao sự háo hức của cộng đồng Avalanche trong việc chia sẻ nhật ký/số liệu của họ với nhau để giúp tìm ra nguyên nhân cốt lõi của quá trình hồi quy này và tốc độ (thường là 30–90 phút) mà tại đó họ đã cập nhật phần lớn cổ phần sau mỗi lần phát hành. Đóng góp của bạn để phục hồi là vô giá.