Solidity и Ethereum, урок #38 | Разбор байткода, opcodes, деплой - идём на самый нижний уровень!

ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами: вы действительно узнаете ОЧЕНЬ много нового.

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

2. Выберите один из буткемпов
3. Примените промо-код: KRUK

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

Таймкоды:
00:00 Введение
02:20 Пару слов о стеке
04:10 Подготовка
07:10 Байткод и opcodes
10:00 Сохранение free memory pointer
13:00 Обработка денежных средств и аргументов конструктора
43:00 Сохраняем мэппинг в state
50:00 Возвращаем код runtime
59:00 Заключение

Аккаунт Ethereum (ETH), Arbitrum, Polygon, BNB, USDT, TRX, BUSD: 0x719C2d2bcC155c85190f20E1Cc3710F90FAFDa16

[usernamer]

Это прям очень сильно. Огромное спасибо!
После этого видео +100% к моему пониманию работы EVM

[cryptoYevgen]

Полезнейший контент, автор по-настоящему Мастер своего дела

[youngdjeday]

Спасибо большое, прекрасно все объясняете

[ZmicerVilenski]

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

[Velichkina_a]

Очень круто, спасибо вам!
Как раз вчера задалась вопросом декодирования, видео очень вовремя)

[ZmicerVilenski]

Илья, есть несколько вопросов по видео. Гран мерси и мучас грасиас, если найдете время ответить.
А). Если ли инструмент, похожий на дебагер ремикса, где можно было бы редактировать байткод и исполнять сразу же, а не по хэшу транзакции извлекать?
Б). Вопросы по байткоду из видео:
1. На позиции 015 (084...) использовался REVERT с 2мя нулями в стэке. Как я понял, это реверт без некой полезной инфы. Но если я инициирую эту ошибку при деплое Ремикс выдает текст: "The called function should be payable if you send value..." Откуда тогда данные об ошибке, если байткод возвращает (0, 0)?
2. Зачем на позиции 016 (047, 070, 088...) оппкод 5b JUMPDEST, если прыжок происходит по номеру инструкции? Неужели для лучшей читаемости кода :)
3. Почему используется DUP вместо PUSH? В случаях когда перед этим был пуш (012, 014), а не расчетное значение. Газа оба опкода потребляют 3 единицы. Два раза PUSH дал бы тот же результат. Или это на выбор компилятора? не предсказуемо.
4. Позиция 017 - POP (удаляет верхний элемент стэка). Но зачем эти данные вообще были в стэке? Они были помещены на позиции 006, дублируя позицию 005 CALLVALUE. Далее следовала инструкция ISZERO, которая первый элемент стека превратила в 1. Но второй (задублированный) так и лежал в стэке до команды POP после прыжка. Логично предположить, что это значение выводилось бы в случае ошибки, но в нашем примере return(0, 0) и специально в стэк помещались 2 нуля для Revert. Еще предположение, что в случае constructor() payable это значение было бы нужно, но тогда это был бы другой байткод. Мое предположение что это несовершенство компилятора? Или все так некий смысл держать это значение в стэке было? (время в видео 20:15)
5. Самые первые 3 операции записывали в память значение 0х80 по адресу 0х40. На 020 позиции эти данные читаются из памяти. Для чего эти маневры? Почему просто не положить в стэк значение 0х80 на текущей (020) позиции? Это опять особенности работы компилятора? Возможно существуют некие патерны работы компилятора и он иногда создает излишние операции, но это упрощает обработку исходного кода компилятором? Сделал лишних операций, но зато по одному шаблону можно обработать исходный код. Или причина этих передвижений 0х80 в другом?
Позже (позиция 030 и т.д) значение (0х80) дублируется в начало стэка, можно сказать дальше уже танцы вокруг 0х80 оправданы, т.к. значение будет несколько раз использоваться. Хотя тут тоже немного странно, если компилятор знает эту ячейку памяти (0х80) и она не меняется в процессе исполнения, можно было просто захардкодить ее. И всегда перед обращением делать PUSH1 80. Но тут уже хотя бы логика есть, а вот до позиции 020 вообще не понятна свистопляска вокруг 0х80.

[momotdmvi]

Илья, добрый день.
Можете сделать видео про ZK пруфы на Солидити?

[chelovak]

Вот это самый топ урок из всех, имхо!