AvalancheGo v1.9.12 и регрессия X-Chain

В основной сети Avalanche было 2 коротких периода нестабильности (134 минуты 22.03.23 и 82 минуты 26.03.23) из-за регрессии в проверке OperationTx, появившейся во время рефакторинга X-Chain. Подсети Avalanche, которые используют консенсус независимо от основной сети, по-прежнему завершали блоки, как обычно, в течение этих двух периодов.

Проблема: ошибочный рефакторинг X-Chain при подготовке к Cortina ( 036e34 )

Раньше выполнение переходов состояний X-Chain распределялось по нескольким файлам с несколькими абстракциями:

• Потребление UTXO ожидалось интерфейсом UnsignedTx: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/tx.go#L35
  - Общедоступный avax.BaseTx обеспечивает реализацию этого почти для всех транзакций: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/components/avax/base_tx.go#L36
  - Этот метод переопределяется ImportTx и OperationTx
  - ImportTx фактически не вводит любые дополнительные потребляемые UTXO из состояния локальной цепочки. ImportTx вводит только символические входные данные, которые используются для определения конфликтов в экземпляре консенсуса Avalanche: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/import_tx.go#L33
  - OperationTx действительно вводит дополнительные потребляемые UTXO из локального состояния.
• Произведенные UTXO для модификаций локального состояния были рассчитаны подписанной структурой Tx с использованием посетителя для доступа к полям базовых структур UnsignedTx: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/tx.go#L87
  - Реализацию visitor конструкции UTXO можно найти здесь: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/txs/visitor.go
  - Эта структура utxoGetter была основой для создания структуры Executor
• Затем во время принятия транзакции были выполнены локальные изменения состояния: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/unique_tx.go#L155-L167
• Затем изменения общей памяти применялись к базе данных в структуре Visitor executeTx: https://github.com/ava-labs/avalanchego/blob/161fe7533a513086acf5d601375d1aea9f8f0545/vms/avm/tx_execute.go#L16

Чтобы унифицировать и упростить пути кода до и после линеаризации до Cortina, вся эта логика перехода состояний была перенесена в одно место. Однако особый случай, связанный с дополнительными UTXO OperationTx, не был перенесен должным образом: https://github.com/ava-labs/avalanchego/commit/036e34f143836dada1409af104e150f4b22598be .

Выпуск этого рефакторинга, представленный в версии 1.9.12, означал, что ноды, которые работали на версии 1.9.11, выполняли транзакции OperationTx иначе, чем те, которые работали на версии 1.9.12.

Исправление: восстановление отсутствующих проверок достоверности в OperationTx и состояние восстановления ( v1.9.12…v1.9.16 )

Чтобы исправить эту регрессию, отсутствующая логика обработки OperationTx v1.9.11 была повторно введена для защиты от неправильного выполнения любых дальнейших транзакций. Этот патч был отправлен в версии 1.9.14.

Поскольку в X-Chain было принято несколько транзакций OperationTx, в то время как подавляющее большинство Avalanche Network работало с версией 1.9.12, следующим шагом было повторное согласование канонического состояния между нодами, работающими с версиями 1.9.11, 1.9.12, и v1.9.14. Это было прекращено после того, как валидаторы обновились до версии 1.9.15. Это изменение не может быть выпущено как часть версии 1.9.14, поскольку необходимо предотвратить неправильное выполнение, прежде чем можно будет выполнить повторное выравнивание состояния (в противном случае было бы невозможно вычислить детерминированное состояние для повторного выравнивания).

Однако вскоре после выпуска версии 1.9.15 мы заметили, что количество обрабатываемых вершин в X-chain осталось равным 2 (вместо обычного диапазона ~0–3):

В ходе дальнейших исследований мы обнаружили один оставшийся элемент, добавленный в состояние до версии 1.9.14, который не был правильно выровнен в версии 1.9.15. Последняя перестройка была завершена, когда валидаторы обновились до версии 1.9.16.

Impact: 2 коротких периода нестабильности сети в C-Chain и P-Chain

Примерно в то время, когда поведение проверки было изменено в версии 1.9.14, и когда состояние было повторно выровнено в версии 1.9.16, принятие блоков было задержано как в C-цепочке, так и в P-цепочке (X-цепочка принимала новые транзакции в течение обоих периодов). ):

• с 7:24 PM ET до 9:38 PM ET (с 14:24 до 16:38 GMT+3) 22.03.23 [134 минуты]

• 6:36 ET до 7:58 ET (с 13:36 до 14:58 GMT+3) 26.03.23 [82 минуты]

В первом случае значительное количество валидаторов еще не обновились до последней доступной версии AvalancheGo и поэтому работали с разными правилами выполнения. Во втором случае у значительного числа валидаторов были не присоединившиеся к новому состоянию блокчейна данные. Как только валидаторы обновились до последней доступной версии AvalancheGo, сеть Avalanche снова стала стабильной.

Большинство подсетей продолжали завершать блоки, как и планировалось, даже когда в основной сети наблюдались всплески незавершенных блоков (снимок экрана сделан 22.03.23):

Тем не менее, ряд API-интерфейсов подсети стал недоступным в течение этого периода нестабильности, поскольку ноды выдавали статус, сообщающий об их неработоспособности и были удалены из связанных с ними балансировщиков нагрузки, хотя они все еще могли обслуживать трафик и принимали новые блоки (стоит учитывать, что нода сообщает о статусе неработоспособности, если ЛЮБОЙ аспект узла неисправен, даже если конкретная подсеть в порядке). Это привело к падению пропускной способности транзакций, поскольку многие пользователи, которые полагались на общедоступные конечные точки (RPC), не могли выполнять транзакции, а эксплореры, которые считывали данные с этих конечных точек, не могли индексировать новые данные:

Дальнейшие планы

Чтобы как можно скорее добавить дополнительное регрессионное тестирование в X-Chain, график активации Cortina на Fuji будет отложен на 1 неделю. Код для активации Fuji теперь будет выпущен 4/3/23, а обновление Cortina будет активировано в тестнете Fuji 4/6/23.

Несколько месяцев назад мы начали работу по мерклизации состояния X-Chain, чтобы защититься от расхождений в автоматическом выполнении и разблокировать State Sync. Первым продуктом этого рабочего потока стал АЛЬФА-релиз x/merkledb , и он продолжается в Cortina с добавлением неиспользуемого корневого поля состояния в новом формате блока X-Chain: https://github.com/ava-labs/avalanchego/blob/7d73b59cb4838d304387ea680b9cc4053b72620c/vms/avm/blocks/standard_block.go#L25. Как только x/merkledb будет готов к работе, это корневое поле состояния будет вычислено и проверено во время выполнения блока X-Chain, чтобы обеспечить быстрое обнаружение любых отклонений в выполнении транзакции во время тестирования и во время выполнения. Мы проводим стресс-тестирование x/merkledb в HyperSDK и приступили к первому аудиту.

Чтобы улучшить UX подсети, AvalancheGo представит проверку работоспособности на уровне подсети, которая позволит интеграторам подсети продолжать обслуживать запросы API за балансировщиками нагрузки, если в другой подсети, запущенной на данном узле, возникнет нестабильность. Это еще один шаг на пути к обеспечению надежной изоляции сбоев между подсетями в Avalanche.

Мы ценим стремление сообщества Avalanche, участники которого делились друг с другом своими журналами/метриками, чтобы помочь найти основную причину этой регрессии, а также скорость (обычно 30–90 минут), с которой они обновляют подавляющее большинство нод после каждого выпуска обновления. Ваш вклад в восстановление сети был неоценим.