Blockchain reorgs. Часть 1

Эту тему мне приходилось касаться только на аудитах. Ни у себя на канале, ни на других каналах я не встречал информации про такое событие как реорганизация блоков в блокчейне, и чем это может быть опасно. Возможно, материал и был, но мне он так и не встретился. Поэтому следующие несколько постов мы посвятим этой теме.

В Web3 мы часто слышим идиому «блокчейн неизменен», но бывают случаи, когда это не так, точнее, он становится практически неизменным (достигает окончательности) только по прошествии некоторого времени с момента майнинга блока, содержащего транзакции пользователей. Это связано с событиями, называемыми реорганизациями блокчейна, или сокращенно reorg.

Реорганизация - это событие, когда блок, который был частью канонической цепи, перестает быть частью канонической цепи, потому что его вытесняет конкурирующий блок.

Реорганизации происходят из-за более мягкого способа работы клиента проверки блокчейна. Алгоритм, определяющий, какая цепь является канонической (правило выбора форка), при определенных обстоятельствах может прийти к выводу, что текущая история цепей не является оптимальной, и выбрать другую цепь из тех, что предоставляют конкурирующие майнеры (цепочки форков), чтобы стать канонической цепью.

Когда происходит перестройка блока, то, будучи внешним наблюдателем цепочки, вы видите, что:

1. Несколько блоков были отброшены и заменены другими;

2. Это не означает, что все транзакции в исходных блоках были отброшены, большое количество транзакций, вероятно, все еще будет включено в новые блоки, возможно, даже все, но не в том же порядке;

Реорганизации появляются чаще, чем люди думают. Используя такие сканеры, как polygonscan.com/blocks_forked, для Polygon reorgs, вы можете увидеть, что они появляются часто.

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

Примечания и наблюдения

- Приведенные на скрине данные были собраны либо со сторонних агрегаторов, либо с сайтов, напрямую отображающих исходные данные. Они также взяты после любых крупных изменений в сети, например, для Ethereum после PoS и для BNB Chain после их последних крупных изменений в масштабируемости, которые резко снизили скорость реорганизации.

- При принятии решения о том, сколько блоков ждать перед подтверждением транзакции вне цепи в чувствительных системах (например, при переходе с криптовалюты на фиат), лучше всего подождать на несколько блоков больше, чем наибольшая глубина реорганизации на этой цепи, которая имела место в прошлом.

- Например, депозиты на CEX от Polygon могут ждать даже 200 блоков, прежде чем будут считаться окончательными.

Системы, основанные на случайной составляющей в сети

Протоколы, содержащие случайный компонент, естественным образом подвержены влиянию реорганизации блокчейна. Такими протоколами могут быть ставки, казино, игры со случайной системой вознаграждения, практически все, что вычисляет случайность с помощью оракула.

Пример ситуаций, которые могут возникнуть:

- игрок выигрывает хорошее вознаграждение в случайном розыгрыше, но из-за реорганизации блокчейна теряет его;

- азартный игрок проигрывает в игре в кости, но благодаря реорганизации блокчейна он теперь фактически выигрывает;

На практике для вычисления случайного числа часто используется VRF (Verifiable Random Function) от Chainlink. Этот API принимает время подтверждения блока, которое, если верить документации, представляет собой:

- сколько блоков служба VRF ждет, прежде чем записать выполнение в сеть, чтобы сделать потенциальные атаки на перезапись невыгодными в контексте вашего приложения и его стоимости под риском.

Для того, чтобы смягчить эту проблему, достаточно выбрать подходящее время подтверждения блока.

#reorg