Как решить уязвимость опережения в смарт-контрактах
5 марта 2023 г.Даже если очереди в супермаркете или в торговых точках, где вы оплачиваете счета за коммунальные услуги, ушли в прошлое, некоторые из нас знают, каково это, когда кто-то вскакивает в очередь.
То есть в начало очереди. В частности, если это по той причине, что их счет намного дороже, чем у других, стоящих в очереди. Понятно, что это не должно быть критерием оперативности обслуживания.
Теперь этот бизнес перемещения на передний план происходит и в смарт-контрактах Ethereum. Также известная как ошибка опережения, чье название было получено из-за аналогичного явления на фондовом рынке, транзакции смарт-контрактов, которые оплачивают более высокую плату за газ, как правило, более предпочтительны, чем те, которые не платят.
Устранение основной уязвимости
С самого начала эта уязвимость возникает не из-за неправильного программирования, а из-за того, что транзакции упорядочиваются и добавляются в блок из «мемпула».
Помимо обычных пользователей, стремящихся быстро заработать, майнеры, как правило, выигрывают от такой транзакции, и именно поэтому они, скорее всего, отслеживают такие транзакции, прежде чем они будут добавлены в блок. На самом деле, как только они это сделают, они отправят собственную транзакцию за несправедливое финансовое вознаграждение, которое в конечном итоге будет добавлено в блок, а не в тот, который был отправлен первым.
Здесь следует иметь в виду, что транзакции, которые были совершены с более высокой ценой на газ, как правило, обрабатываются первыми по сравнению с другими. Помня об этом, злоумышленник может изменить исход таких событий, как аукционы, торги или первичное размещение монет, в свою пользу, просто заплатив более высокую комиссию за газ.
Давайте рассмотрим этот распространенный пример, чтобы понять, как работает опережающая уязвимость:
В этом примере у нас есть три актера: Наман, Каавья и Айшвария. Наман сначала развертывает задачу хеширования как смарт-контракт, которую должны решить две другие. Тот, кто решит эту головоломку, получит в награду 10 эфиров.
Теперь Каавья сначала находит решение для хеширования и отправляет его с 10 Gwei в качестве платы за газ из своего смарт-контракта:
С другой стороны, Айшвария находит ответ немного позже и передает правильный ответ в свой смарт-контракт со 100 Gwei в качестве платы за газ.
Из-за более высокой платы за газ вместо Каавьи 10 Эфира получает вознаграждение Айшвария, как показано ниже:
Проще говоря, это опережающая ошибка или ошибка заказа транзакции, поскольку она обрабатывает транзакции на основе стоимости газа.
Другими словами, даже если Каавья отправит свой ответ раньше Айшварии, она ничего не получит за свои усилия, как показано ниже:
Поскольку этот «прыжок в очередь» Айшварии не устроит Каавью или кого-либо еще, необходимо рассмотреть несколько превентивных мер для нашего кода смарт-контракта.
3 способа справиться с уязвимостью переднего плана
Теперь есть исправления, которые могут предотвратить такую потерю. Другими словами, мы должны иметь возможность зафиксировать одну транзакцию как ту, которая должна получить 10 эфиров.
Способ 1. Счетчик транзакций
Использование счетчика транзакций — один из самых простых способов удержать кого-либо от получения вознаграждения любым другим способом.
Как видно из кода, добавленного ниже, был добавлен счетчик транзакций, который блокирует транзакцию, совершенную человеком, который первым выполнил вызов хеширования. Поскольку награду должен получить только тот, кто сделает это первым, мы просим всех участников добавить значение 0 вместе с их решением.
Поскольку текущее значение txCounter будет равно нулю для первого представленного решения, оно будет заблокировано. Другими словами, как и в приведенном выше примере, Каавья введет свое решение, а также нулевое значение, чтобы получить свою награду. 10 Эфира.
Если это сделает кто-то еще, решение не будет принято, так как счетчик транзакций был увеличен до значения, превышающего единицу. К тому времени вся награда в 10 эфиров, которая должна достаться Каавье, будет передана ей по праву.
Способ 2. Установка лимитов газа
Теперь при использовании этого метода основное внимание уделяется установке лимита газа для всех транзакций. И нижний, и верхний предел, если необходимо.
Как вы, возможно, помните, транзакции упорядочиваются в зависимости от того, сколько газа было уплачено за указанную транзакцию. Хотя это не может полностью устранить этот порядок, это, безусловно, в значительной степени уменьшает его.
Если вы посмотрите на приведенный ниже код, все транзакции, которые оплачивают газ на сумму 1 или меньше, пройдут, но те, кто попытается перепрыгнуть через линию, заплатив больше газа, не пройдут благодаря модификатору gasThrottle. В этом случае 1 Wei или Gwei может быть стандартной стоимостью обработки такой транзакции, и это все, что будет разрешено.
Таким образом, если все транзакции не будут сильно различаться по газу благодаря этому дросселю, проблема предпочтения определенных транзакций не возникнет. Хотя у такого подхода есть свои преимущества, плата за газ обязательно изменится в будущем.
То, что сегодня высоко, через пару лет будет низко, поэтому Наман должен постоянно следить за этим. Или же Айш сможет воспользоваться этими изменяющимися ценностями, просто подождав некоторое время.
Метод 3: Подводная отправка
Теперь, несмотря на то, что предыдущие два подхода могут работать в более простых ситуациях, они никогда не устраняют первопричину первопричины уязвимости: полное раскрытие информации о транзакциях как майнерам, так и другим злоумышленникам.
Должно быть очевидно, что до тех пор, пока эти две стороны имеют доступ к информации о каждой транзакции, сохраняется шанс обмана системы. Ясно, что необходим метод, с помощью которого должна быть скрыта эта чувствительная ко времени информация, и который приводит нас к подходу отправки подводной лодки, реализованному как часть LibSubmarine библиотека смарт-контрактов.
При использовании этого подхода информация о транзакциях скрывается таким образом, что майнеры или обычные пользователи не могут воспользоваться преимуществами. Шифрование играет большую роль в защите этой информации, которая, по усмотрению владельца, может быть раскрыта после ее добавления в блок.
Тем не менее, даже если этот подход не идеален, уровень защиты, который он предлагает, намного выше, чем у других методов, благодаря его готовности устранить реальную причину, по которой имеет место опережение — как на реальном мире и на блокчейне.
Другие стратегии обхода уязвимости передового плана
Конечно, стратегии, рассмотренные в предыдущем разделе, — не единственные, которые защищают смарт-контракты от «упреждающей» уязвимости.
С боковыми цепями заказ происходит вне сети, в то время как расчет происходит на ней. Поскольку эти два шага выполняются на разных платформах, это не только повышает пропускную способность, но и мешает майнерам или обычным пользователям получать информацию, необходимую для использования опережающей уязвимости.
Другая стратегия, хотя и теоретическая по своей природе, включает в себя рандомизацию порядка транзакций для определенного раунда, который был зафиксирован в схеме фиксации-раскрытия. Это обеспечивается с помощью логики смарт-контракта. При таком подходе лидеры не окажутся в первых рядах, поскольку порядок определяется вышеупомянутым смарт-контрактом.
Наконец, еще один подход включает в себя реализацию Injective Protocol, где пользователи решают поддающиеся проверке функции задержки для этого крайне важного t-значения, которое определяет, кто получит заказ. . В результате, благодаря возможности отказаться от системы случайного упорядочения, которая используется в большинстве блокчейнов, также снижается вероятность опережающих атак.
Оригинал