Оригинал — https://www.blocknative.com/blog/mev-and-creating-a-basic-arbitrage-bot-on-ethereum-mainnet

Канал — https://t.me/jetix37eth

MEV, или Максимальная Извлекаемая Ценность— это максимальное значение, которое может быть извлечено из блока. Хотя традиционно это была возможность, в которой могли участвовать только майнеры — именно поэтому ее иногда называли Miner Extractable Value, — демократизация мемпула предоставила трейдерам больше возможностей извлекать ценность, влияя на то, что попадает в блок.

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

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

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

Арбитраж в MEV

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

Допустим, Вы начали с актива A и продали его за актив B на бирже, где актив B дешевле. Затем вы бы взяли актив и продали его за актив А на другой бирже, получив взамен больше актива А, чем когда вы начинали.

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

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

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

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

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

Давайте разберем это на совершенно нереалистичном, но, надеюсь, проливающем свет примере.

Предположим, вы отслеживаете мемпул и обнаруживаете транзакцию, которая повлияет на пул ликвидности в Uniswap V2 для токенов A и B. Поскольку вы знаете, что пулы ликвидности регулируются уравнением x * y = k, тогда вы знаете, когда видите, что кто-то отправляет обмен 2 токена A на как можно большее количество токена B, вы можете рассчитать (основываясь на резервах этих токенов в пуле ликвидности, которые в данном случае равны 10 и 10), что он получат взамен 1,7 токена B.

Ключевым моментом является то, что вы знаете, что эта транзакция повлияет на цену между токенами A и B на Uniswap V2, но не на другой DEX, такой как Sushiswap… по крайней мере, до тех пор, пока кто-нибудь не воспользуется возможностью арбитража.

В тот момент, когда эта транзакция будет добыта, токен A будет дешевле на Uniswap, чем на Sushiswap, поэтому тот, кто может продать токен A на Sushiswap за токен B, а затем продать эти токены B на Uniswap за токен A, должен в конечном итоге получить больше токена A, чем они начали. И это именно то, что иллюстрирует этот пример.

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

Поиск возможностей для арбитража

Проводя некоторое исследование различных возможностей в MEV, я наткнулся на готовый смарт-контракт в этом потрясающем репозитории github, который расскажет вам, как оптимально рассчитать правильную сумму, необходимую для арбитража между двумя Uniswap V2 дексами — например, Uniswap V2 и Sushiswap.

Ключевой момент этого смарт-контракта заключается в том, что вы можете предоставить ему два пула — один пул Uniswap и один пул Sushiswap —и сообщить, есть ли какая-либо прибыль от арбитража между двумя пулами. Однако расчет выполняется путем анализа резервов этих двух пулов в их текущем состоянии (т.е. последнего состояния блока).

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

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

Пишем базовый скрипт

Этот пост не предназначен для того, чтобы узнать о Solidity. Существует множество отличных постов и руководств, но для того, чтобы по-настоящему конкурировать за возможности MEV (по крайней мере, в мире EVM), вам нужно знать Solidity.

Тем не менее, я использовал свои ограниченные знания о Solidity, чтобы обновить смарт-контракт в соответствии с моими потребностями. Чтобы рассчитать прибыль от арбитражной возможности в реальном времени, мне нужно было бы каким-то образом снабдить мою функцию getProfit корректировкой пула ликвидности. Эта корректировка происходит, когда я вижу транзакцию обмена в мемпуле, которая повлияет на пул ликвидности Uniswap или Sushiswap.

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

Заметьте, что getProfit полагается на getOrderedReserves для расчета резервов каждого пула и правильного направления сделок. Поэтому я добавил некоторую логику в getOrderedReserves, которая принимала бы данные мемпула при обмене токенами в Uniswap или Sushiswap, а затем корректировала резервы токенов этой пары, чтобы при вызове getProfit он включал данные мемпула, а не только последнее состояние цепочки.

Теперь, когда я настроил смарт-контракт так, чтобы он мог включать данные мемпула в реальном времени, я могу завершить свой скрипт, используя mempool API от Blocknative и flashbots private relay.

Используя Simulation Platform, каждое моделирование выполняется изолированно от текущего состояния блока, что означает, что существует некоторая степень вероятности, связанная с полезными нагрузками "ожидающего моделирования". Однако, если транзакция находится в верхней части блока, то это фактически означает, что она выполняется в отношении текущего состояния блока, поскольку между текущим состоянием блока и этим не будет никаких транзакций.

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

Для этого проекта я просмотрел ожидающие события моделирования на маршрутизаторах Uniswap V2 и Sushiswap, используя Javascript SDK от Blocknative. Ожидающие загрузки моделирования включают изменения чистого баланса по всем задействованным адресам (например, пул ликвидности), что позволяет мне сделать две вещи:

• Проверить, существует ли эта пара на другой бирже
• Использовать изменения баланса в качестве входных данных в качестве "корректировок" в моей функции getProfit в моем смарт-контракте

Когда я получаю эти события, я перебираю список netBalanceChange в нашей полезной нагрузке Simulation Platform и пропускаю, когда адрес равен самому фактическому маршрутизатору (потому что я ищу только адреса пула ликвидности) или если netBalanceChange[index].address не содержит 2 элементов (если у него есть только 1 элемент, то это не может быть пул, потому что пул будет иметь 2 или более резервов токенов с изменениями чистого баланса).

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

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

Аналогично, если у другого DEX действительно есть пул ликвидности с той же парой токенов, то я могу осуществлять арбитраж между ними. Используя мой скрипт, это означает, что я обнаружил отложенный обмен либо на Uniswap, либо на Sushiswap в мемпуле, и я обнаружил тот же пул ликвидности на другом DEX. Теперь у меня есть вся информация, необходимая для предоставления моего смарт-контракта, чтобы увидеть, есть ли возможность получения прибыли.

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

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

Если чистый расчет больше 0, я успешно нашел возможность арбитража, где я получу чистый 5% и отдам майнеру 95%!

Создаем flashbots-пакет для арбитража

Затем мне нужно было создать свой пакет flashbots для отправки на ретранслятор. Поскольку обнаруженная транзакция мемпула может быть транзакцией типа 0 или типа 2, у меня должны быть сценарии для обоих.

Я использовал свой модифицированный смарт-контракт для построения своей транзакции, которая включала бы либо две внутренние транзакции, либо два обмена между двумя DEX.

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

Оригинал — https://noahliechti.hashnode.dev/an-effective-way-to-build-your-own-oracle-with-solidity

Канал — https://t.me/jetix37eth

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

Как работают Оракулы?

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

Важно понимать, что ваш контракт просит оракула выполнить вызов API. Он не выполняет вызов самостоятельно.

Есть две причины использовать оракулов:

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

Идея

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

Реализация

Архитектура

Смарт-контракты

Моя реализация состоит из двух контрактов и одного интерфейса. Контракт, который взаимодействует с оракулом, называется CardsClient, а ончейн компонент, предоставляющий эту услугу, называется CardsOracle. Контракты были скомпилированы с версией 0.8.7 и также должны работать до версии 0.8.15.

CardsClient

Чтобы получить общее представление, я покажу вам переменные состояния и конструктор контракта CardsClient:

Owner — это адрес, который создал контракт. Таких контрактов может быть несколько, поскольку всем разрешено использовать нашего оракула.

Адрес оракула должен быть payable, потому что мы платим оракулу 0.001 ETH за каждый сделанный нами запрос. Причина взимания платы заключается в том, что оракул должен совершить вторичную транзакцию к контракту CardsClient, которая стоит некоторое количество ETH.

Результаты нашего запроса будут сохранены в массиве переменных bytes2. Каждая карта может быть эффективно представлена в двух байтах памяти (Туз пик -> AS -> 0x4153). Наконец, мы будем использовать uint32 для хранения идентификатора последнего ожидающего запроса. Эта реализация предотвращает несколько одновременных запросов. Вы также можете разрешить несколько одновременных запросов.

Далее нам надо определить функции, с которыми могут взаимодействовать кошельки или контракты:

Есть две public функции, называемые drawNCardsWithShuffle и drawNCardsWithoutShuffle. Первая функция вытягивает карту из перетасованной колоды и перетасовывает ее перед любым последующим розыгрышем карт. Вероятность вытянуть определенную карту останется 1/52. Последняя функция позволяет извлекать карты из одной и той же колоды без последующей повторной вставки карт. Обе функции начинаются с новой и перетасованной колоды при каждом запросе.

Функции drawNCardsWithShuffle и drawNCardsWithoutShuffle создаю уровень абстракции. Пользователь никогда не вызовет функцию drawNCards напрямую. Вот почему они internal.

Все функции используют uint8 в качестве типа данных для параметра _nrOfCards, поскольку это наименьший тип данных, способный хранить число 52.

Чтобы использовать функциональность между CardsClient и CardsOracle, мы создадим интерфейс, в котором есть структура Request:

Эта структура действует как новый тип данных. Он группирует несколько атрибутов в один "объект". С полями nrOfCards и shuffle мы уже знакомы.

В cbClient мы сохраним адрес контакта, который вызывает оракула. Вместе с cbSelector оракул может использовать функцию вызова низкого уровня для передачи результатов API обратно в наш контракт CardsClient.

Чтобы предотвратить злонамеренную перезапись уже выполненных запросов, мы можем отслеживать состояние с помощью поля fulfilled.

drawNCards отвечает за передачу эфира и Request оракулу.

После того, как мы убедимся, что ожидающего запроса нет, мы можем создать запрос и инициализировать его. address(this) — это cbClient, а this.fulfill.selector — cbSelector. Если вы присмотритесь повнимательнее, я добавил сигнатуру функции fulfill. Это функция, которую вызовет оракул и передаст результаты запроса оффчейн API. this.fulfill.selector возвращает первые левые четыре байта хэша Keccak-256 (SHA-3) сигнатуре функции fulfill.

Теперь, когда запрос сформирован, пришло время передать его CardsOracle. Чтобы успешно выполнить транзакцию, функция call пересылает все, что контракт получил либо через drawNCardsWithShuffle, либо через drawNCardsWithoutShuffle.

Получателем средств и структуры от оракула является функция receiveRequest . В первом аргументе функции abi.encodeWithSignature обязательно использовать две открывающие и закрывающие круглые скобки, поскольку мы используем структуру. В противном случае аргумент не будет закодирован правильно.

Транзакция receiveRequest контракта CardsOracle вызовет событие, которое сообщит бекенду, что она должна запросить API. Следовательно, переменная data не будет включать результат вызова API. Только fallback-функция (в нашем случае fulfill) получает доступ к результатам. Она будет вызвана из оракула транзакцией, которая инициируется бекендом.

Если call не успешен, транзакция отменяется. Если успешен, идентификатор запроса извлекается из data, сохраняется в pendingRequest и затем возвращается.

fulfill — это callback-функция, которая получает результат из оффчейн-сервиса:

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

Наша функция также проверяет, что переданный _requestID совпадает с pendingRequestId. Я использую оператор assert, поскольку это условие, которое всегда должно быть истинным.

Мы также запускаем событие под названием ClientFulfillment. На самом деле это не обязательно, но полезно для отслеживания и тестирования нашего контракта.

В нашем случае функция просто сохраняет результат в переменной cards. Но это также может вызвать внутреннюю логику в зависимости от requestId. Все это зависит от варианта использования.

CardsOracle

Как и в случае с CardsClient, я показываю вам переменные состояния и конструктор.

Owner'ом является разработчик контракта. fee — это сумма, которую запрашивающий должен заплатить оракулу за использование его сервиса. Это должно, по крайней мере, покрывать плату за газ для вторичной транзакции.

Каждый запрос имеет свой собственный идентификатор. requestId увеличивается на единицу при каждом запросе. В экстренном случае, когда API будет взломан, нам нужно запретить пользователям отправлять запросы. С помощью stopped мы можем временно приостановить действие контракта.

Меппинг idToRequest кэширует запросы. На это есть две причины. Во-первых, нам нужно сохранить адрес и сигнатуру callback-функции, во-вторых, должен быть механизм, позволяющий не выполнять запрос несколько раз. Для этого мы используем поле fulfilled.

Функция receiveRequest получает запросы вместе с fee и запускает событие.

receiveRequest получает Request в качестве параметра. Функция проверяет, не остановлен ли контракт и правильно ли заполнены все поля. Если нет, то все возвращается. Также количество эфира, отправляемое пользователем, должно быть больше или равно указанной нами комиссии. Возврат средств не производится, если пользователь платит слишком много. Все запросы хранятся в нашем меппинге idToRequest. К запросам можно получить доступ по requestId.

Далее мы генерируем событие OracleRequest. Наш бекенд слышит это событие и запрашивает данные из API. Важно, чтобы событие было отправлено из контракта CardsOracle. Если бы мы разрешили какому-либо контракту отправлять событие, оракул был бы уязвим для спама, поскольку мы не можем гарантировать, что пользователь заплатил за услугу.

Функция заканчивается оператором return, который возвращает текущий requestId и увеличивает ID. Это полезно, поскольку CardsClient может захотеть связать входящие вызовы по их идентификатору.

Следующая функция может быть вызвана только беком. Его задача заключается в передаче извлеченных данных callback-функции контракта CardsClient.

С помощью _requestId, который мы получаем в качестве параметра, мы можем получить доступ к кэшированным запросам. Параметр _cards сохраняет разыгранные карты. Для того, чтобы успешно передать _cards клиенту, необходимо выполнить несколько условий:

• Контракт не остановлен
• Запрос должен быть в idToRequest
• Запрос должен быть выполнен
• Количество запрошенных карт должно быть равно количеству кард, которые функция получила

После этого мы можем снова использовать функцию call. В этом случае мы передаем закодированные данные и _requestId.

Тестирование

Я написал несколько скриптов на Hardhat чтобы запустить проект:

• 1_deploy-contracts.js
• 2_listen-to-client-fulfillments.js
• 2_listen-to-oracle-requests.js
• 3_draw-cards.js
• helper-functions.js

Хотя все части важны для работы проекта, только 2_listen-to-oracle-requests.js необходим для прослушивания события OracleRequest и извлечения данных.

cardsOracle ссылается на контракт CardsOracle, который развернут в блокчейне. Метод on контракта позволяет нам определить событие, которое мы хотим прослушать, и действие, которое должно быть выполнено при запуске события.

Мы используем событие OracleRequest, поскольку это событие мы определили в функции receiveRequest контракта CardsOracle. Когда происходит событие, скрипт получает доступ ко всем параметрам, которые были определены в контракте.

Чтобы извлечь соответствующие данные, нам нужно передать nrOfCards и shuffle в функцию getCards. Эта функция выполняет вызов API deckofcardsapi.com и в результате возвращает массив карт в шестнадцатеричном формате. Этот массив (allCardsCoresHex) затем передается вместе с requestId обратно в контракт. Затем данные будут перенаправлены в fullback-функцию клиентского контракта.

Оригинал — https://sjkelleyjr.medium.com/zk-snark-concepts-explained-like-youre-15-54755f87c6d1

Канал — https://t.me/jetix37eth

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

Я решил написать гайд по жаргону zk-SNARK для самых маленьких, поскольку во время учебы мне еще не приходилось сталкиваться с чем-то подобным.

Обратите внимание, что целевая аудитория этого поста — это те, кто не знаком с zk-SNARK'ами, поэтому многие определения будут математически неточными (см., например, определение конечного поля ниже).

R1CS

R1CS расшифровывается как “Система ограничений ранга 1”. Ранг 1 взят из линейной алгебры и подразумевает, что система ограничений использует матрицы. Это было распространенное промежуточное представление для арифметических схем на всем пути от вычислений до zk-SNARK, пока в 2019 году не появился PLONK.

У Виталика есть пост в блоге, объясняющий, как перейти от вычислений к zk-SNARK, который содержит изображение, которое я счел полезным, когда думал об этом пути.

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

Оригинал — https://github.com/kadenzipfel/smart-contract-vulnerabilities

Канал — https://t.me/jetix37eth

1. Неправильное имя конструктора
2. Переопределение переменных
3. Слабые источники случайности
4. Отсутствие защиты от атак с повторным воспроизведением подписей
5. Нарушение требований
6. Запись в произвольное место хранения
7. Неправильный порядок наследования
8. Произвольный переход функциональной переменной
9. Наличие неиспользуемых переменных
10. Неожиданный баланс эфира
11. Незашифрованные секреты
12. Обнаружение неисправного контракта
13. Очищенная зависимость от блокчейна
14. Несоответствие стандартам
15. Незащищенный Callback
16. Определение типа адреса на основе размера кода
17. Зависимость от очереди транзакций
18. DoS с ограничением расхода газа в блоке
19. DoS с (неожиданным) возвратом

Переопределение переменных

Можно дважды использовать одну и ту же переменную в Solidity, но это может привести к непреднамеренным побочным эффектам. Это особенно сложно при работе с несколькими контрактами. Например:

Здесь мы можем видеть, что SubContract наследует SuperContract, а переменная a определяется дважды с разными значениями. Теперь предположим, что мы используем a для выполнения некоторой функции в SubContract, функциональность, унаследованная от SuperContract, больше не будет работать, поскольку значение a было изменено.

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

Незащищенный Callback

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

Давайте посмотрим на функцию ERC721._safeMint от OpenZeppelin:

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

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

Поскольку у нас есть доступ к незащищенному callback, мы можем повторно войти в mint после того, как будет отчеканен только один токен, и отчеканить дополнительные MAX_PER_USER - 1 токенов следующим образом:

Чтобы устранить уязвимость, мы можем использовать функцию ERC721._mint или защиту от повторного входа.

Определение типа адреса на основе размера кода

Распространенным методом определения того, является ли отправитель контрактом или кошельком, была проверка размера кода отправителя. Эта проверка утверждает, что если отправитель имеет размер кода > 0, то это должен быть контракт, а если нет, то это должен быть кошелек. Например:

Однако недавно было обнаружено, что это утверждение неверно и может быть игнорировано. По этой причине важно, чтобы логика вашего смарт-контракта не утверждала, что адрес отправителя является кошельком просто потому, что размер кода равен 0.

DoS с ограничением расхода газа в блоке

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

Неограниченные операции

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

Эта ситуация также может привести к атаке. Допустим, плохой человек решает создать значительное количество адресов, при этом каждому адресу выплачивается небольшая сумма средств из смарт-контракта. Если все сделано эффективно, транзакция может быть заблокирована на неопределенный срок, возможно, даже предотвратив проведение дальнейших транзакций.

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

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

Набивание блока

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

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

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

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

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

DoS с (неожиданным) возвратом

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

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

Например:

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

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

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

Оригинал — https://github.com/kadenzipfel/smart-contract-vulnerabilities

Канал — https://t.me/jetix37eth

1. Принудительная отправка ETH в контракт
2. Недостаточное выделение газа
3. Reentrancy
4. Переполнение и недополнение целых чисел
5. Зависимость от временной метки
6. Авторизация через tx.origin
7. Плавающая pragma
8. Видимость функции по умолчанию
9. Устаревшая версия компилятора
10. Непроверенное возвращаемое значение вызова
11. Незащищенный вывод эфира
12. Незащищенная инструкция Selfdestruct
13. Видимость переменной состояния по умолчанию
14. Неинициализированный указатель хранилища
15. Нарушение assert
16. Использование устаревших функций
17. delegateCall ненадежному вызываемому абоненту
18. Податливость подписи

Принудительная отправка ETH в контракт

Иногда пользователям нежелательно иметь возможность отправлять эфир в смарт-контракт. К сожалению, есть возможность обойти функцию fallback() контракта и принудительно отправить эфир.

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

Первый метод заключается в вызове метода selfdestruct для контракта с адресом уязвимого контракта, установленным в качестве получателя. Это работает, потому что selfdestruct не вызовет функцию fallback().

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

Недостаточное выделение газа

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

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

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

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

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

Reentrancy

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

Внутри функции

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

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

Между функциями

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

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

Предотвращение reentrancy

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

Другим надежным методом предотвращения является пометка ненадежных функций.

Кроме того, для оптимальной безопасности используйте шаблон checks-effects-interactions. Это простое эмпирическое правило для создания функций смарт-контракта.

Функция должна начинаться с проверок, например, операторов require и assert.

Далее должны быть выполнены последствия контракта, т.е. внесены изменения в состояние.

Наконец, мы можем выполнять взаимодействия с другими смарт-контрактами, например, вызовы внешних функций.

Эта структура эффективна против повторного входа, поскольку измененное состояние контракта предотвратит выполнение злоумышленниками вредоносных взаимодействий.

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

Авторизация через tx.origin

tx.origin — это глобальная переменная в Solidity, которая возвращает адрес, с которого была отправлена транзакция. Важно, чтобы вы никогда не использовали tx.origin для авторизации, поскольку другой контракт может использовать fallback функцию для вызова вашего контракта и получения авторизации, поскольку авторизованный адрес хранится в tx.origin.

Рассмотрим этот пример:

Здесь мы можем видеть, что контракт TxUserWallet проводит функцию transferTo() с помощью tx.origin.

Теперь, если кто-то обманом заставит вас отправить эфир на адрес контракта TxAttackWallet, они могут украсть ваши средства, проверив tx.origin, чтобы найти адрес, с которого была отправлена транзакция.

Чтобы предотвратить такого рода атаки, используйте msg.sender для авторизации.

Использование устаревших функций

С течением времени функции в Solidity устаревают и часто заменяются более совершенными функциями. Важно не использовать устаревшие функции, так как это может привести к неожиданным эффектам и ошибкам компиляции.

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

Оригинал — https://blog.trustlook.com/understand-evm-bytecode-part-4/

Канал — https://t.me/jetix37eth

В прошлых частях мы говорили о том, как различные типы данных Solidity реализуются в хранилище. Сегодня мы поговорим о памяти более подробно, о ее использовании во внешних вызовах.

Мы узнали некоторые основы о памяти из предыдущих разделов. Мы знаем, что память предназначена для вычисления хэша или взаимодействия с внешними вызовами или возвратами. Структура памяти зарезервировала 0x0 и 0x20 для вычисления хэша. По адресу 0x40 он сохранит указатель свободной памяти для использования в будущем.

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

Давайте посмотрим на все коды операций, которые зависят от памяти, кроме MLOAD и MSTORE:

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

Сначала давайте посмотрим на код операции CALLDATACOPY. В документации Solidity “calldatacopy(t, f, s)” определяется как “копировать s байт из calldata в позиции f в mem в позиции t”. Если у вас есть опыт анализа контрактов на уровне байт-кода, вы можете заметить, что другой аналогичный код операции CALLDATALOAD более популярен, чем этот.

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

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

Дешифрованный байт-код выглядит так:

temp0 = mload(0x40);

mstore(0x40,(0x40 + temp0));

calldatacopy(temp0,0x4,0x40);

По-видимому, на этот раз CALLDATACOPY используется для копирования всего аргумента в память для дальнейшего использования. Это не просто фиксированный размер массивов. Для любого параметра, который имеет фиксированный размер, например struct, CALLDATACOPY будет тем, кто выполнит эту работу.

Однако все может быть еще сложнее, когда есть динамические массивы. Например:

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

Давайте все-таки заглянем в байт-код в поисках истины. Вот фрагмент кода перед вызовом функции test():

temp0 = mload(0x40);

temp1 = msg.data(0x4);

mstore(0x40,(0x20 + (temp0 + (msg.data((0x4 + temp1)) * 0x20))));

mstore(temp0,msg.data((0x4 + temp1)));

calldatacopy((temp0 + 0x20),(0x24 + temp1),(msg.data((0x4 + temp1)) * 0x20));

var1 = test(temp0);

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

Первая строка “temp0 = mload(0x40);” очень популярна. Она получает указатель свободной памяти из адреса памяти 0x40 в переменную temp0. Затем temp1 будет присвоено значение, полученное из полезной нагрузки данных со смещением 0x4, которое регулярно содержит первый параметр, когда тип является integer. Однако, по-видимому, в данном случае это еще не закончено. Это значение в temp1 будет использоваться в качестве смещения для определения местоположения данных, начиная с 0x4.

Это значение может быть показано как “msg.data((0x4 + temp1))”. Из приведенного выше фрагмента кода это значение представляет собой длину массива. Размер каждого элемента в массиве равен 0x20. Таким образом, “mstore(0x40,(0x20 + (temp0 + (msg.data((0x4 + temp1)) * 0x20))));” изменит указатель свободной памяти, чтобы сохранить часть памяти для этого аргумента. Затем длина массива будет скопирована в старый указатель свободной памяти, и элементы массива также будут скопированы CALLDATACOPY. Наконец, указатель памяти будет передан функции test() для работы.

После того, как у есть некоторое базовое представление о том, как была организована полезная нагрузка данных EVM, мы сможем увидеть, как работают коды операций, связанные с CALL, и как задействована память. В документации Solidity указано: “call (g, a, v, in, insize, out, outsize) – вызов контракта по адресу a с входной памятью[in..(in+insize)), обеспечивающий подачу газа g и v wei, а также память выходной области[out..(out+outsize)), возвращающий 0 при ошибке (например. кончился газ) и 1 на успех”.

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

Здесь мы определили 2 смарт-контракта. Функция getA() в контракте Exisitng вызовет внешнюю функцию a() в Deployed. Вот скомпилированный байт-код:

Как всегда, указатель свободной памяти был загружен в переменную temp0. Затем хэш функции 0xDBE671F сохраняется в свободной памяти. Тогда var11 будет содержать первую переменную хранилища, которая в данном случае является dc. Строка require проверит, содержит ли адрес в var11 адрес контракта.

Наконец, этот адрес будет использоваться для выполнения внешнего вызова “var11.gas(gasleft).value(0).call(temp0,4,temp0,0x20)”. Параметры (temp0 и 4) в этом вызове — это полезная нагрузка данных, которую он хочет отправить внешнему контракту. В этом случае он отправляет 4 байта с адреса temp0. Из раннего кода мы знаем, что 4 байта - это хэш-значение подписи функции для a(). Поскольку в функции нет других аргументов, для выполнения этого вызова требуется всего 4 байта хэша функции. Если функция, которую вы хотите вызвать, действительно имеет аргументы, то компилятор расположит память так, как мы обсуждали ранее для вызова.

Параметры (temp0 и 0x20) будут содержать возвращаемые данные из внешнего вызова. EVM получит данные, возвращенные из внешнего вызова, и поместит их в указанный вызов кода операции адреса памяти.

Есть одна вещь, которую стоит упомянуть о внешнем вызове — это то, что в Solidity есть некоторый жестко закодированный адрес для встроенной функции. Если вы посмотрите на какой-нибудь байт-код, вы всегда найдете некоторые внешние вызовы, использующие адреса 1,2,3 и 4. По-видимому, это не обычные адреса смарт-контрактов. Я поискал в Интернете, и не так много информации о них можно найти. Но я нахожу некоторую подсказку в документации Solidity:

Выражения, которые могут иметь побочный эффект на распределение памяти, разрешены, но те, которые могут иметь побочный эффект на другие объекты памяти, - нет. Разрешены встроенные функции keccak256, sha256, ripemd160, ecrecover, addmod и mulmode (даже если они вызывают внешние контракты).

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

1 - ecrecover

2 - sha256

3 - ripemd160

4 - sha3

Для последней версии компилятора Solidity SHA3 имеет свой собственный код операции, поэтому для этого вычисления не требуется внешнего вызова. Но вы все еще можете видеть, что некоторые смарт-контракты используют 0x4 для отправки внешнего вызова для этой функции.

До сих пор мы обсуждали, какую важную роль играет память EVM, особенно при выполнении внешних вызовов к другим смарт-контрактам. Это будет последняя статья в этой серии. Мы рассмотрели большинство вещей, с которыми вы можете столкнуться, когда захотите проанализировать байт-код виртуальной машины. Надеюсь, это поможет вам немного понять, как это работает.

Оригинал — https://blog.trustlook.com/understand-evm-bytecode-part-3/

Канал — https://t.me/jetix37eth

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

Однако хранилище спроектировано в виде словаря или хэш-таблицы. Оно будет содержать все данные по парам ключ-значение. Для каждого адресного ключа он может хранить 32-байтовое целое число. Итак, как он может реализовать сложные структуры данных, struct, mapping, массивы переменной длины и т.д.? Давайте подробнее разберемся в их реализации.

Давайте начнем с относительно простого: типы данных фиксированного размера. Мы уже знаем, что EVM поддерживает целые числа разной длины, от 1 байта до 32 байт. Если вы определили только несколько 32-байтовых целочисленных переменных в своих смарт-контрактах, компилятор просто назначит переменным последовательность адресов, начинающихся с 0x0. Например:

Если вы скомпилировали приведенный выше код и проверили байт-код EVM, вы обнаружите, что весь код, считывающий или записывающий 3 переменные balance1, balance2 и balance3, будет сопоставляться операциям SLOAD или SSTORE по адресам 0x0, 0x1 и 0x2 соответственно.

Однако все мы знаем, что использование хранилища обходится дорого. Если вы понятия не имеете, что такое газ в EVM, я рекомендую вам провести небольшое исследование по этому вопросу. Есть тонны статей, в которых говорится об этом. По сути, это стоимость выполнения вашего кода.

Таким образом, чтобы оптимизировать затраты на газ при использовании хранилища, когда у вас есть несколько целых чисел небольшой длины, они будут оптимизированы для использования 1 слота хранения. Например:

Когда у вас есть две переменные, определенные как uint128, они могут быть помещены в один слот памяти по адресу 0x0, а третьей переменной balance3 будет присвоен собственный адрес 0x1. Когда вы ссылаетесь на переменную balance1, первое 16-байтовое значение будет извлечено после SLOAD или SSTORE. Давайте посмотрим на какой-нибудь реальный пример этого:

Байт-код:

6080604052600436106100615763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166340441eec81146100665780634f2be91f146100a0578063c45c4f58146100c7578063f24a0faa146100dc575b600080fd5b34801561007257600080fd5b5061007b6100f1565b604080516fffffffffffffffffffffffffffffffff9092168252519081900360200190f35b3480156100ac57600080fd5b506100b561011d565b60408051918252519081900360200190f35b3480156100d357600080fd5b5061007b610158565b3480156100e857600080fd5b506100b5610170565b60005470010000000000000000000000000000000090046fffffffffffffffffffffffffffffffff1681565b6000546fffffffffffffffffffffffffffffffff80821670010000000000000000000000000000000090920481169190910116600181905590565b6000546fffffffffffffffffffffffffffffffff1681565b600154815600a165627a7a72305820fa0e623e455a9cc0439ea393dff5b50cc571150034eb57658dd9718e3982b1590029

По соображениям экономии времени мы не будем рассматривать их все, давайте просто посмотрим на строку вычисления add внутри функции add():

Эквивалентный код:

sstore(0x1,uint128((uint128((sload(0x0) / 0x100000000000000000000000000000000)) + uint128(sload(0x0)))));

Логика использования слотов хранения 0x0 и 0x1 четко показана в приведенной выше строке, которая является строкой balance3 = balance1 + balance2;

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

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

Мы говорили о самом базовом типе данных, Integer, в EVM. Теперь давайте посмотрим на struct в Solidity:

Эквивалентный код ассемблера для функции deposit() выглядит так:

sstore(0x0,uint160(arg0));

sstore(0x1,arg1);

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

Теперь давайте поговорим об очень популярном типе данных — mapping.

Если вы знакомы с разработкой смарт-контрактов, вы, вероятно, увидите, что многие приложения аналогично используют отображение для записи баланса учетной записи. Давайте скомпилируем код и проверим ассемблерный код переменной balanceOf:

mstore(0x20,0x0);

mstore(0x0,msg.data(0x04) & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF);

temp0 = keccak256(0x0,0x40);

return(sload(temp0));

Мы можем увидеть msg.data(0х04) & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFffffffffff получит параметр из данных полезной нагрузки в качестве значения адреса. Затем этот аргумент будет помещен в адрес памяти 0x0. Кроме того, для адреса 0x20 в памяти задано значение 0x0. Этот 0x0 на самом деле является индексом объявления переменных хранилища. Это только потому, что balanceOf является первой объявленной переменной в смарт-контакте.

После настройки памяти вызывается код операции SHA3 для вычисления хэш-значения входных данных, и результаты будут использоваться в качестве ключа хранения для mapping-переменной. Из приведенного выше кода мы можем видеть, что когда вы объявляете mapping-переменную одного уровня, компилятор фактически принимает ее как функцию с одним аргументом и возвращает одно значение. По соображениям удобочитаемости давайте использовать arg0 для значения, установленного в адресе 0x0 в памяти вычисления сопоставления.

Давайте взглянем на двухуровневый mapping:

mapping (address => mapping (address => uint256)) public tokens;

Возможно, вы видели некоторые похожие mapping-переменные, подобные приведенным выше. Когда вы скомпилируете код и сгенерируете байт-код, его ассемблерный код будет выглядеть следующим образом:

mstore(0x20,0x0);

mstore(0x0,arg0);

temp0 = keccak256(0x0,0x40);

mstore(0x20,temp0);

mstore(0x0,arg1);

temp1 = keccak256(0x0,0x40);

return(sload(temp1));

По-видимому, для двухуровневой mapping-переменной это фактически функция с двумя аргументами и возвращающая одно значение. Для этой tokens он сначала настроил память с 0x0 по адресу 0x20 (мы знаем, что 0x0 - это индекс объявления переменной), arg0 по адресу 0x0. Затем первое HASH-значение было вычислено с использованием кода операции SHA3.

Однако это вычисленное значение снова будет помещено в адрес памяти 0x20, а второй аргумент arg1 на этот раз будет помещен по адресу 0x0 для другого вычисления SHA3. Затем результат будет использоваться в качестве ключа хранения для переменной. В той же логике вы можете продолжать добавлять уровни для ваших mapping-переменных, и ключом для хранилища всегда будет последний вычисленный результат SHA3.

До сих пор вы, возможно, лучше понимали, почему указатель на свободную память всегда сохраняется в 0x40, а не в 0x0 или 0x20. Это происходит только потому, что эти адреса зарезервированы для вычисления хэша.

Ранее мы изучили несколько структур данных в Solidity. Что, если мы соберем некоторые из них вместе? Например, что делать, если у нас есть mapping-переменная, которая возвращает значение struct:

Давайте взглянем на декомпилированный код для balanceOf:

function balanceOf( address arg0) public return (var0,var1) {

mstore(0x20,0x0);

mstore(0x0,arg0);

temp0 = keccak256(0x0,0x40);

return(sload(temp0),sload((temp0 + 0x1)));

}

Мы можем видеть, что вычислительная часть SHA3 такая же, как и обычная одноуровневая mapping-переменная. Единственное отличие заключается в том, что обычный тип данных, такой как integer, будет просто использовать результат хэша в качестве ключа хранения. Но элемент-член внутри структуры применит индекс объявления элемента к этому хэш-значению для ключа хранения.

Таким образом, в этом случае два элемента-члена в struct Funder добавят 0x0 и 0x01 к хэш-значению temp0 для ключа хранения.

Далее мы рассмотрим структуры данных с переменной длиной. Например, у нас есть вот такой смарт-контракт:

Мы определили массив переменной длины senders. Давайте посмотрим, как EVM реализует эту переменную в хранилище:

function senders( uint256 arg0) public return (var0) {

assert((arg0 < sload(0x0)));

mstore(0x0,0x0);

temp0 = keccak256(0x0,0x20);

return(uint160(sload((temp0 + arg0))));

}

Из приведенного выше ассемблерного кода мы можем заметить, что переменная реализована как функция с одним аргументом index, возвращающаяэлемент из массива. В Solidity мы определили только одну переменную массива senders.

Как мы обсуждали ранее, хранилище назначит индекс адреса для каждой переменной, а поскольку существует только одна, ей присваивается 0x0. Однако адреса 0x0 недостаточно для хранения всех данных массива. Вместо этого он будет содержать длину массива.

Для данных массива хранилище использует значение SHA3 своего адресного индекса (в данном случае 0x0) в качестве начала данных массива. Индекс массива будет добавлен к этому хэш-значению в качестве ключа хранения для соответствующего элемента.

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

До сих пор мы обсуждали struct, mapping и array. Есть еще один тип данных, который может вас заинтересовать — строки. String и bytes - это один и тот же тип данных для хранения байтов переменной длины. Давайте посмотрим, как это будет выглядеть, когда мы объявим строковую переменную в хранилище:

Этот смарт-контракт ничего не делает, кроме как просто возвращает строку вызывающему. Давайте посмотрим, как строка сохраняется в хранилище. Даже при наличии одной строки скомпилированный код на ассемблере немного сложен:

Код на ассемблере немного сложен, давайте рассмотрим его логику.

Сначала давайте разберемся с логикой “((((0x100 * ((0x1 & sload(0x0)) == 0)) – 0x1) & sload(0x0)) / 0x2)”. По-видимому, поскольку в контракте определена только одна переменная hello, для этой переменной зарезервирован адрес хранилища 0x0. Но, похоже, дело не только в длине, поданной как массивы.

Из этого сравнения “((0x1 & sload(0x0)) == 0))” мы знаем, что последний бит этого поля является флагом. Если бит установлен в 1, то это сравнение равно False (0x0), поэтому вся строка будет “(uint256(sload(0x0)) / 0x2)”. Если бит установлен в 0, то вся строка будет “(uint8(sload(0x0)) / 0x2)”. Это значение присвоено var7 в приведенном выше коде.

Затем это значение сравнивается с 0x1F. Если оно меньше 0x1F, эта строка “mstore(var5,((sload(0x0) / 0x100) * 0x100));” скопирует первые байты 0x1F из хранилища 0x0 в память. Если оно больше 0x1F, то результатом будет некоторая аналогичная операция, которую мы видели в массиве переменной длины.

Основываясь на том, что мы видели из кода на ассемблере, мы можем понять основную логику строк. Максимально использовать хранилище, если строка меньше 0x1F — значит она может быть сохранена в одном слоте хранилища.

Таким образом, последний бит поля установлен в 0, а последний байт имеет длину строки, умноженную на 2. И строка сохраняется в первых 31 байте в слоте. Однако, если длина строки больше 31, то один слот для хранения не может вместить все данные. Таким образом, слот поля будет содержать только поле длины (последний бит установлен равным 1), а данные сохраняются в виде массива переменной длины.

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

Оригинал — https://blog.trustlook.com/understand-evm-bytecode-part-2/

Канал — https://t.me/jetix37eth

В первой части мы изучили часть создания контракта в байт-коде виртуальной машины. В этом разделе мы проанализируем рантайм байт-кода виртуальной машины. Мы по-прежнему будем использовать пример кода из предыдущей статьи.

Весь байткод выглядит так:

608060405234801561001057600080fd5b5060fd8061001f6000396000f3006080604052600436106049576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680631003e2d214604e578063b69ef8a814608c575b600080fd5b348015605957600080fd5b5060766004803603810190808035906020019092919050505060b4565b6040518082815260200191505060405180910390f35b348015609757600080fd5b50609e60cb565b6040518082815260200191505060405180910390f35b600081600054016000819055506000549050919050565b600054815600a165627a7a723058208c866a01e15ad0e4316f01fc7c7615f3c4b5f6a8845103d2c1ed587a07f9886b0029

Эта часть байт-кода кажется намного длиннее, чем часть создания. Но давайте разделим это на части и проанализируем их одну за другой.

Эти инструкции фактически сохраняют адрес 0x80 со смещением 0x40 в памяти в качестве указателя свободной памяти для использования в будущем.

Существует новый код операции CALLDATASIZE, который мы раньше не встречали в 0x07. Он получит размер полезной нагрузки данных из этой транзакции. LT — это код операции для сравнения двух элементов в стеке, он вернет значение TRUE, если сравнение выполнено.

Итак, собрав все части вместе, мы можем получить эквивалентный ассемблерный код Solidity следующим образом:

mstore(0x40,0x80);

if(msg.data.length < 0x04) { revert(0,0); }

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

Это 4-байтовое значение будет использоваться контрактом для выбора функции для доставки остальных данных, которые являются параметрами для этой функции. Например, если вы вызовете функцию withdraw(0xABCD) в смарт-контракте, полезная нагрузка данных для этого вызова будет выглядеть следующим образом:

0x3823D66C000000000000000000000000000000000000000000000000000000000000ABCD

В этом примере первое 4-байтовое значение равно 0x3823D66C, что является хэш-значением SHA3 для “withdrawn(bytes32)”. Следующее 32-байтовое целое число является параметром вызова функции 0xABCD. Это простой пример параметров целочисленной функции. При обработке параметров переменного размера все усложнится. Мы поговорим о них позже.

А пока давайте вернемся к инструкциям, которые мы обсуждали. Размер полезной нагрузки данных должен составлять не менее 4 байт. Если нет, то все вернется на круги своя. Но будет ли это справедливо для всех смарт-контрактов? Что, если мы просто отправим эфир в этот смарт-контракт без вызова какой-либо функции?

Возможно, вы уже помните некоторые функциональные возможности в программах Solidity. Да, именно там реализована функция fallback. Чтобы подтвердить это, вы можете получить образец с реализованной функцией fallback, а затем проверить ветвь инструкции после кода проверки msg.data.length.

Продолжая разбор кода, мы видим следующие команды:

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

Сначала код помещает 0xFFFFFFFF в стек. Это значение будет использоваться в качестве одного из операндов кода операции AND в 0x33. Затем код добавит еще одно огромное постоянное значение, которое будет использоваться в качестве разделителя DIV в 0x32. Для инструкций в 0x2F, 0x31 код получит первое 32-байтовое значение из полезной нагрузки данных, используя CALLDATALOAD(0x0).

В сочетании с набором команд более поздних DIV и AND мы можем видеть, что эти инструкции фактически получают первое 4-байтовое значение полезной нагрузки данных, которое является хэш-значением подписи функции. Вычисленный результат помещается в стек. Затем значение сравнивается с 0x1003e2d2, используя код операции EQ в 0x3A. Если это было правдой, выполнение будет переведено на адрес 0x4D с помощью JUMPI. В противном случае код продолжит работу, и результат будет сравнен с другим хэш-значением 0xb69ef8a8.

Теперь логика этого фрагмента кода довольно ясна. Он получает первое 4-байтовое значение из полезной нагрузки данных и решает, какая функция будет выбрана для запуска. Для кодовых адресов 0x4D и 0x74 они являются входом для каждой public функции, к которой вызывающий может получить доступ к смарт-контрактам. Если ни одно из хэш-значений в коде не удовлетворяется, то это приведет к срабатыванию fallback функции смарт-контрактов. Если он не был определен, он просто вернется.

До сих пор мы знали, как public функции могут получить доступ к внешним функциям. Теперь давайте подробнее рассмотрим конкретные функции. Адрес 0x4D является входом функции add():

На входе в функцию add() находится код операции JUMPDEST. Это специальный код операции, который помечает только адрес, на который можно перейти. Похоже, что это не играет важной роли для реализации EVM. Однако вы увидите, что это действительно помогает определить график потока управления (CFG) для байт-кода. Мы обсудим это в следующем разделе.

Инструкции, установленные в 0x4F-0x57, были просмотрены в предыдущем разделе. Они были введены компилятором для функции, не принимающей средства. После этого кода проверки код операции PUSH1 по адресу 0x5A легко проигнорировать. Однако это PUSH1 очень важно для того, чтобы код мог вернуться позже.

Давайте просто запомним, что адрес 0x62 пока помещен в стек. Затем вызывается CALLDATALOAD(0x04) для загрузки параметра из полезной нагрузки данных, который расположен со смещением 0x04. После получения параметра код перейдет к 0x86 для выполнения:

В приведенном выше фрагменте кода значение 0x0 в хранилище загружается с помощью SLOAD(0x0). Затем это значение будет добавлено к параметру, загруженному из полезной нагрузки данных, и сохранено обратно в то же место 0x0 в хранилище. Наконец, мы видим код, который мы поместили внутри функции add():

balance = balance + value;

Мы использовали только одну целочисленную переменную balance внутри смарт-контракта. Компилятор присваивает этой переменной смещение 0x0. Таким образом, любая операция чтения или записи с этой переменной баланса будет помещена в смещение 0x0 в хранилище.

В конце фрагмента кода используется JUMP для возврата к 0x62. Если вы все еще помните, где это значение 0x62 было помещено в стек. Эта операция может напомнить вам что-то об архитектуре X86. Да, это на самом деле call и ret для вызовов функций. Поскольку EVM не поддерживает вызовы функций на уровне байт-кода, он может использовать только коды операций PUSH и JUMP для вызовов функций. Таким образом, возникнет много проблем с созданием CFG из байт-кода.

Давайте вернемся к адресу 0x62, чтобы посмотреть, что произойдет дальше:

Этот фрагмент кода содержит несколько настроек элементов в стеке с помощью кодов операций DUP и SWAP. Для эквивалентного кода на ассемблере приведенный выше код выглядит следующим образом:

mstore(mload(0x40), value);

return(mload(0x40), 0x20);

Value внутри кода было вычисленным результатом предыдущей операции add(), которое является новым значением balance. Наконец, мы просмотрели весь байт-код внутри функции add().

Теперь давайте вернемся к фрагменту кода отправки функции для второй функции HASH 0xb69ef8a8. Вход для этой функции находится в 0x74:

Мы видим, что первая часть кода действительно похожа на предыдущую функцию, за исключением того, что параметр не был загружен. Затем функция вызовет фрагмент кода с 0x95. Инструкции в 0x95-0x98 просто загружают значение в 0x0 в хранилище и возвращают. Мы отметили, что фрагмент кода в 0x62 был повторно использован для обеих функций. Это связано с тем, что обе функции вернут переменную balance обратно.

Вы можете задаться вопросом, почему внутри кода отправки функции присутствует функция HASH 0xb69ef8a8? Разве внутри смарт-контракта нет только одной функции add()? Если вы используете базу данных в 4 байта для проверки этого хэша, вы получите balance(). По-видимому, переменная хранилища распознается компилятором как public функция без параметров.

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

Как это будет выглядеть для сопоставлений или массивов переменной длины? Как будут представлены параметры в полезной нагрузке данных для строк? Мы поговорим обо всем этом в следующем разделе.

Оригинал — https://blog.trustlook.com/understand-evm-bytecode-part-1/

Канал — https://t.me/jetix37eth

Если Вы начали читать эту статью, я думаю, вы уже знаете, что означает EVM. Если Вам действительно нужны некоторые основы, пожалуйста, загуглите “Ethereum Virtual Machine”. Основная цель этой серии статей — помочь разобраться с байт-кодом EVM на случай, если вы будете вовлечены в какую-либо работу по аудиту контрактов на уровне байт-кода или разрабатывать декомпилятор байт-кода EVM.

Теперь давайте начнем с некоторых самых базовых элементов байт-кода EVM. EVM — это виртуальная машина на основе стека. Если у вас есть опыт работы с любой из подобных виртуальных машин (например, Java VM, DVM, .NET VM), вам не составит особого труда понять ее основную идею.

По сути, байт-код — это машинный язык для виртуальной машины. Этот код, безусловно, не предназначен для чтения человеком так же, как обычный человеческий код. Байт-код может быть скомпилирован с помощью высокоуровневых языков EVM.

На данный момент самым популярным из них является Solidity. Чтобы лучше понять байт-код виртуальной машины, я буду использовать несколько простых примеров для демонстрации. Итак, давайте начнем с самого простого примера:

Вы можете спросить, почему я не использовал HelloWorld в качестве стандартного примера. Это связано с тем, что обычно в примере HelloWorld используется строковая переменная, а для нашего байт-кода строковая переменная является динамической переменной длины, и позже мы поговорим об этом в другой статье.

После компиляции кода мы получаем следующий байт-код:

Мы подробно разберем, что означает эта строка.

Во-первых, если вы внимательно посмотрите на строку, вы поймете, что это строка шестнадцатеричного формата для представления фрагмента двоичного файла.

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

Код операции — это инструкция EVM. Каждый код операции сам по себе представляет собой 8-битное беззнаковое целое число. Например, 0x00 означает STOP, 0x01 означает ADD. Чтобы понять все значения кодов операций, можно подглядеть в желтую бумагу Ethereum.

На данный момент мы не будем рассматривать все коды операций, чтобы объяснить их значения. Нам просто нужно знать их основы и объяснить новые коды операций, когда с ними столкнемся. Итак, давайте начнем с первой части байткода EVM: 6080604052.

Если мы заглянем в желтую бумагу, то обнаружим там следующие коды:

Из приведенного выше фрагмента кода мы можем видеть 2 кода операции, PUSH1 и MSTORE. PUSH1 означает поместить 1-байтовое целое число в стек для дальнейшего использования. PUSHы могут быть вплоть до 32.

В EVM все целые числа имеют длину от 1 до 32 байт. Коды операций семейства PUSH — единственные, которые поставляются с операндами в байткоде виртуальной машины, потому что для остальных кодов операций они будут использовать значения в стеке.

В этом примере первые два PUSH1 поместят 0x80 и 0x40 в стек, затем MSTORE будет использовать 2 элемента в стеке для операции записи в память. Итак, приведенный выше фрагмент кода на самом деле является кодом EVM на ассемблере: mstore(0x40,0x80).

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

Таким образом, если вы продолжите просматривать весь байт-код, вы получите весь список кодов операций. Но прежде чем мы продолжим изучение дополнительных кодов операций, давайте поговорим еще о двух концепциях в среде EVM — memory и storage.

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

В предыдущем примере MSTORE сохранит указанное значение 0x80 в соответствующий адрес 0x40. Вы можете задаться вопросом о значении этого действия. На самом деле, адрес 0x40 в памяти EVM зарезервирован для “указателя свободной памяти”, поэтому, когда коду EVM потребуется использовать некоторую память, он получит указатель свободной памяти из 0x40. Кроме того, если вы не хотите, чтобы эта память была переполнена будущей операцией, вам необходимо обновить значение в 0x40, чтобы будущая операция больше не использовала ту же память.

Помимо memory и стека, storage-переменные — это те, которые содержат состояния. Таким образом, переменные storage не будут сбрасываться каждый раз при перезапуске EVM. Вы можете использовать storage как словарь или хэш-таблицу. Все, что изменилось в storage, будет записано в блокчейн Ethereum. Коды операций, связанные с хранением, - это SLOAD и SSTORE. Мы подробнее поговорим о storage-переменных при анализе более сложных структур, таких как mapping или array.

Основываясь на этой информации, давайте продолжим работу со строкой байткода:

Этот фрагмент кода немного длинный, но не беспокойтесь об этом. Давайте пройдемся по этому вопросу шаг за шагом.

CALLVALUE поместит msg.value в стек, затем DUP1 продублирует это значение в стеке и проверит, равно ли оно 0 или нет, используя ISZERO. Если значение ISZERO, полученное из стека, равно 0, этот код операции поместит значение TRUE в стек для следующих инструкций.

Следующий PUSH2 поместит кодовый адрес 0x0010 в стек для перехода. JUMP — это инструкция условного перехода, которая использует 2 элемента из стека. Один предназначен для результата условия, а другой - для адреса перехода. Если условие (в данном случае это значение ISZERO(msg.value)) выполнено, выполнение перейдет к 0x0010, в противном случае код завершится REVERT(0,0).

Таким образом, байт-код с адреса 0x05-0x0F можно перевести как: if(msg.value != 0) revert();

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

Если вы упорядочите стек вручную, вы можете увидеть, что существует инструкция CODECOPY(0x0,0x001F,0xC7).

Это означает, что он скопирует код 0xC7 байт из смещения 0x1F в память (0x0, 0xC7). Затем код вызовет RETURN(0x0,0xC7), чтобы передать скопированные данные обратно в EVM. До сих пор Вы, возможно, догадывались о логике этой операции и о том, какова функциональность этого фрагмента байт-кода.

Скорее всего, весь фрагмент байт-кода, сгенерированный компилятором Remix, состоит из нескольких частей. Набор из 0-0x1E является частью контракта для создания. Этот код будет вызываться только во время создания смарт-контракта. Он вызовет конструктор контракта, а также скопирует часть кода во время выполнения в EVM для создания.

После создания учетной записи контракта будет вызвана часть кода из 0x1F-(0x1F+0xC7) для будущих транзакций по этому контракту, и функция конструктора больше не будет вызываться. Кроме того, вы, возможно, обнаружили, что в части создания байт-кода нет никаких инструкций JUMP или JUMPI.

Чтобы доказать правильность наших предположений, давайте создадим другой код Solidity с функцией конструктора:

По-видимому, код длиннее предыдущего, так как мы определили там функцию конструктора. Итак, давайте разберем код операции на более читаемые коды:

Мы можем видеть некоторый аналогичный код, установленный в начале и в конце. Но код, установленный между 0x12 и 0x25, является новым. Итак, давайте сосредоточимся на этой новой части.

Сначала, в коде операции, установленном 0x12 и 0x14, была вызвана MLOAD(0x40) для получения значения из памяти по адресу 0x40. Из предыдущего раздела мы уже знали, что адрес 0x40 в памяти содержит указатель свободной памяти в EVM. В данном случае это 0x80.

Затем, после упорядочивания стека с помощью PUSH и DUP, он будет иметь [... 0x20, 0x00FA, 0x80] в стеке перед вызовом CODECOPY. Таким образом, код вызовет CODECOPY(0x80, 0x00FA, 0x20).

По-видимому, это действие не было показано в предыдущем демонстрационном байт-коде. Это как-то связано с новым кодом, который мы поместили внутри функции конструктора. Он копирует последние 32 байта данных из кода в адрес свободной памяти. Скорее всего, это значение параметра во время развертывания контракта. Давайте продолжим работу с более поздним байт-кодом.

В наборе инструкций 0x1D – 0x21 код добавил 0x20 к текущему указателю свободной памяти 0x80 и сохранил его обратно по адресу 0x40 с помощью MSTORE(0x40, 0x80+0x20).

Затем команда в 0x22 поместит значение, возвращаемое MLOAD(0x80), в стек, который представляет собой 32-байтовое значение, скопированное из кода. Более поздний код в 0x23, 0x25 сохранит значение в хранилище со смещением 0x0, используя SSTORE(0x0, LOAD(0x80)). Итак, вкратце, инструкции между 0x12 и 0x25 в основном выполняют некоторую операцию, подобную SSTORE(0x0,CODECOPY(0x80, 0x00FA, 0x20)).

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

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