Blockchain reorgs. Часть 2

Продолжаем наш разговор про реорганизацию блокчейна.

Off-ramp системы

Под криптовалютным off-ramp понимается процесс обмена криптовалют на фиатную валюту. К системам, осуществляющим офф-рампинг криптовалют, относятся:

- централизованные биржи (CEX);

- провайдеры криптовалют в фиат;

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

В этой серии постов приведены некоторые конкретные требования к подтверждению блоков, которые существуют на известных CEX. Например, Coinbase требует 35 подтверждений блоков для депозитов ETH, в то время как Binance - только 12.

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

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

Наиболее заметные атаки 51% затрагивают токены Verge, Ethereum Classic, Bitcoin Gold, Feathercoin и Vertcoin.

Смягчить последствия этой формы атаки не так просто. Одним из компонентов решения является чрезмерное увеличение количества требуемых подтверждений. Однако в таких случаях этого недостаточно, поскольку захват сети может длиться неопределенное количество времени. Необходимо внедрить решение для мониторинга сети в сочетании с приостановкой снятия/пополнения средств.

Протоколы, которые требуют от пользователей создать что-то, а затем взаимодействовать с этим в два этапа

Этот тип проблем с реорганизацией наиболее часто встречается в данной категории уязвимостей. Они возникают, когда протокол требует от пользователей сначала создать или инициировать компонент, а затем, в другой транзакции, взаимодействовать с ним.

Еще одним важным и ключевым условием является то, что развернутые контракты используют ключевое слово в Solidity "new" для создания контракта (или опкод CREATE). Обе эти процедуры полагаются на nonce вызывающего контракта для определения адреса вновь развернутого контракта и не учитывают никаких пользовательских данных.

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

Примерный сценарий атаки в описанном выше случае:

1. Alice создает Vault через контракт фабрики (транзакция A);

2. затем Alice вносит в Vault токены (транзакция B);

3. происходит реорганизация блока, и транзакция A отбрасывается (транзакция B все еще существует);

4. обычно транзакция B возвращается, если выполняется;

5. Bob развертывает свой Vault, который первоначально сделала Alice (через фронтран), и из-за базовой проблемы оно= создается по тому же адресу, что и первоначальное хранилище

6. депозит Alice попадает в Bob Vault, и тот может его снять;

Для того, чтобы решить эту проблему, используйте опкод create2, а соль должна содержать элементы, характерные для вызывающей стороны (например, хэш на входы плюс msg.sender).

#reorg