Вопросы на собеседовании: Блокчейн-разработчик

При reentrancy внутри одной функции повторно вызывается та же точка входа, а при reentrancy между функциями вызывается другая функция, зависящая от того же незавершенного состояния.

• В первом случае callback повторно вызывает, например, withdraw до завершения обновления баланса.
• Во втором случае callback входит в другую точку, например transfer или borrow, которая читает тот же баланс или лимит.
• Блокировка только withdraw не защищает transfer, если обе функции зависят от инварианта, который первый вызов еще не восстановил.
• Границей анализа безопасности служит общий инвариант всех внешних точек входа, а не тело одной функции отдельно.

При cross-contract reentrancy callback переходит в другой контракт, а при read-only reentrancy наружу попадает временное значение без прямой записи в уязвимое состояние.

• В cross-contract пути контракт A вызывает внешний контракт, тот вызывает контракт B, а B читает или меняет состояние, связанное с A.
• Мьютекс в A не защищает B автоматически, потому что у контрактов разное хранилище и общий инвариант может контролироваться по-разному.
• При read-only reentrancy callback запрашивает view-функцию вроде getPrice, когда одно поле учета уже обновлено, а другое еще содержит старое значение.
• Модификатор view запрещает записи в состояние через эту функцию, но не гарантирует, что возвращаемое значение соответствует согласованному моменту транзакции.

Checks-effects-interactions сокращает окно для callback, а ReentrancyGuard блокирует повторный вход в защищенные пути, но ни один из механизмов не доказывает безопасность целиком.

• CEI сначала проверяет входные данные, затем фиксирует все связанные изменения учета и только после восстановления инварианта делает внешние вызовы.
• ReentrancyGuard использует мьютекс в хранилище и отклоняет второй вход в функцию с тем же guard во время первого вызова.
• CEI применен не полностью, если одно поле обновлено, а связанные поля или состояние другого контракта перед взаимодействием остаются несогласованными.
• Guard не покрывает незащищенные точки входа, хранилище другого контракта или несогласованные значения, доступные через view-функции.

Перевод ERC-777 может выполнить код хука отправителя или получателя, поэтому операция с токеном также передает управление наружу.

• Хук tokensToSend запускается до изменения токен-балансов, а tokensReceived после него, поэтому хуки получают разные точки для callback.
• Хук получателя может снова вызвать интегрирующий протокол до завершения его собственного учета депозита, вывода или награды.
• Контракт, принимающий произвольные ERC-20-совместимые активы, не может считать, что transfer или transferFrom никогда не вызывает callback.
• SafeERC20 обрабатывает совместимость вызовов и возвращаемых значений, но не блокирует хуки, поэтому по-прежнему нужны CEI и подходящие по области действия reentrancy guards.

Спотовая цена DEX отражает текущие резервы пула, которые атакующий может временно исказить ликвидностью, занятой на одну транзакцию.

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

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

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

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

• Атакующий видит swap жертвы в публичном mempool и отправляет перед ним сделку в том же направлении, чтобы сдвинуть цену пула.
• Затем сделка жертвы исполняется по худшей цене, пока результат удовлетворяет minAmountOut или maxAmountIn.
• После жертвы атакующий совершает обратную сделку и оставляет себе разницу цен за вычетом комиссий пула и стоимости транзакций.
• Более свободный slippage дает больше пространства для извлечения, строгие лимиты могут вызвать revert, а приватная отправка скрывает транзакцию от публичных поисковиков.

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

• В OpenZeppelin AccessControl роль DEFAULT_ADMIN_ROLE по умолчанию администрирует все роли и сама является своим администратором.
• Поэтому компрометация одного ключа default admin позволяет выдать роли для минта, апгрейда, паузы или управления казначейством, даже если соответствующие рабочие ключи не пострадали.
• Самоуправляемые роли, циклы администрирования и отсутствие пути отзыва могут неожиданно усложнить удаление привилегий или восстановление доступа.
• Отделение рабочих ролей от администратора под multisig или timelock и двухэтапная передача администрирования снижают риск эскалации через один ключ.

delegatecall исполняет байткод другого контракта с адресом, балансом и хранилищем вызывающего контракта, сохраняя его текущие msg.sender и msg.value.

• Чтение и запись хранилища идут по сырым слотам вызывающего контракта, поэтому layout прокси и имплементации должен оставаться совместимым.
• address(this) указывает на вызывающий контракт, а внешние вызовы из делегированного кода исходят от него с его полномочиями и активами.
• Недоверенный или некорректно обновленный код может перезаписать слоты владельца или имплементации, изменить произвольное состояние или перевести активы вызывающего контракта.
• delegatecall дает переиспользование кода, а не изоляцию, поэтому проверка имплементации и защита инициализации и апгрейдов входят в его границу безопасности.

Подпись можно использовать повторно, если контракт проверяет подписанные данные, но не привязывает их к одному использованию и одному домену исполнения.

• Replay в том же контракте возникает, когда принятые данные можно отправлять многократно из-за отсутствия nonce или проверки уже использованного digest.
• Cross-chain replay возникает, когда та же подпись действительна в другом деплое, потому что подписанный домен не содержит идентификатор сети.
• Контракт должен проверить и использовать signer-specific nonce или digest до внешних вызовов, а для ограниченного по времени разрешения также проверять deadline.
• Домен EIP-712 с chainId и verifyingContract разделяет сети и контракты, а подписанная структура привязывает разрешение к конкретному действию, получателю и сумме.

Прокси перенаправляет вызов через delegatecall, поэтому код реализации работает с состоянием прокси.

• Fallback-функция прокси передаёт исходный calldata по адресу реализации и не делает обычный внешний вызов.
• Во время выполнения address(this), хранилище и баланс ETH принадлежат прокси, поэтому запись состояния меняет слоты прокси.
• delegatecall сохраняет исходные msg.sender и msg.value, поэтому контроль доступа в реализации видит настоящего вызывающего.
• Прокси возвращает returndata реализации или передаёт вызывающему данные её revert без изменений.

EIP-1967 задаёт для метаданных прокси стандартные слоты хранения, которые почти не могут пересечься с переменными реализации.

• Слот реализации вычисляется как bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1), и OpenZeppelin использует именно эту константу.
• Стандарт аналогично задаёт отдельные слоты для администратора прокси и beacon, хотя конкретный паттерн может использовать не все три.
• Блокчейн-обозреватели и клиенты могут читать известные слоты через eth_getStorageAt без getter-функции прокси.

Transparent-прокси выбирает между обработкой обновления и fallback-вызовом реализации по адресу вызывающего.

• Любой вызов не от администратора делегируется реализации, даже если его селектор совпадает с upgradeToAndCall.
• Администратор может вызвать только upgradeToAndCall; любой другой его вызов завершается ошибкой ProxyDeniedAdminAccess и не доходит до реализации.
• В OpenZeppelin 5.x каждый прокси разворачивает отдельный ProxyAdmin, начальный владелец которого передаётся в конструктор прокси.

UUPS размещает логику обновления в реализации и использует proxiableUUID, чтобы отклонять реализации с несовместимым слотом хранения.

• upgradeToAndCall выполняется через прокси с модификатором onlyProxy, который проверяет контекст delegatecall и то, что прокси сейчас указывает на эту реализацию.
• Переопределённая в реализации функция _authorizeUpgrade должна разрешить вызывающего до изменения слота реализации.
• Обновление вызывает proxiableUUID у новой реализации и требует слот реализации EIP-1967; сам proxiableUUID использует notDelegated, чтобы запретить вызовы через прокси.

Transparent-прокси размещает диспетчеризацию обновления в прокси, а UUPS размещает её в каждой обновляемой реализации.

• TransparentUpgradeableProxy разворачивает отдельный ProxyAdmin и содержит диспетчеризацию по отправителю, поэтому его развёртывание дороже, чем у обычного ERC1967Proxy.
• В UUPS прокси остаётся небольшим, но каждая новая реализация должна сохранять правильную авторизацию обновления и совместимость с ERC-1822.
• Transparent-диспетчеризация не даёт администратору случайно вызвать функцию реализации, а в UUPS нет отдельного правила fallback для администратора.

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

• Инициализатор использует версию 1 и обычно выполняется в контексте хранилища прокси только один раз.
• Передача закодированного вызова инициализатора в конструктор прокси объединяет развёртывание и инициализацию в одну атомарную транзакцию.
• Reinitializer с более высокой версией настраивает состояние, добавленное последующим обновлением, причём каждую версию можно использовать лишь один раз.
• Reinitializer нельзя вкладывать друг в друга, а порядок вызовов унаследованных инициализаторов нужно задавать вручную, чтобы не инициализировать родителя дважды.

_disableInitializers навсегда блокирует состояние инициализации реализации, чтобы никто не мог захватить этот отдельно развёрнутый контракт.

• OpenZeppelin устанавливает версию инициализации в максимальное значение uint64, поэтому последующие вызовы initializer и reinitializer завершаются ошибкой.
• Обычно функция вызывается в конструкторе реализации, поэтому меняет хранилище реализации, а не хранилище прокси.
• Прокси остаётся доступным для инициализации, поскольку delegatecall читает и меняет его отдельный слот инициализации.
• Такая блокировка не заменяет быструю инициализацию прокси, которую лучше выполнить через calldata конструктора в той же транзакции развёртывания.

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

• Нельзя менять порядок, удалять или менять тип существующих переменных состояния; новые переменные добавляют только после совместимого существующего layout.
• Линеаризация наследования Solidity влияет на порядок слотов, поэтому перестановка базовых контрактов или вставка переменных в базовый контракт может сдвинуть хранилище потомков.
• Зарезервированные слоты __gap позволяют позже добавлять переменные в унаследованный контракт, уменьшая gap на то же число занятых слотов.
• Обновляемые контракты OpenZeppelin 5.x используют изолированное хранилище ERC-7201, чтобы снизить риск коллизий при наследовании, но layout каждого namespace всё равно должен оставаться совместимым и проходить проверку.

Паттерн Transparent разрешает коллизии селекторов прокси и реализации по сочетанию селектора и статуса администратора у вызывающего.

• Селектор состоит только из первых четырёх байтов хеша сигнатуры функции, поэтому разные сигнатуры могут иметь одинаковый селектор.
• Вызов не от администратора всегда делегируется, включая вызов с селектором upgradeToAndCall, поэтому функция реализации остаётся доступной пользователям.
• Вызов администратора попадает только в обработчик обновления прокси, а с любым другим селектором завершается ошибкой без fallback в реализацию.
• OpenZeppelin не рекомендует добавлять внешние функции в TransparentUpgradeableProxy, поскольку новая функция может перекрыть неявный селектор обновления и сделать обновления недоступными.

Паттерн прокси определяет место проверки авторизации, а timelock может заставить разрешённое обновление ждать в течение публично известной задержки.

• В UUPS авторизация делегируется функции _authorizeUpgrade, которую обычно защищают onlyOwner или отдельной ролью.
• Обновления Transparent авторизует владелец ProxyAdmin, поэтому владельцем может быть governance-контракт, а не отдельный аккаунт.
• TimelockController разделяет роли proposer, executor и canceller и требует, чтобы запланированная операция выдержала минимальную задержку до исполнения.
• Timelock ограничивает, кто и когда может обновлять контракт, но не доказывает совместимость хранилища или корректность реализации, для которых всё равно нужна техническая проверка.