Сегодня мне приснилось, что в Ruby появился цикл вида for ... of ....

https://www.youtube.com/watch?v=zs8UpY2YF3c

Помните такие? 😁

Можно ли в тестах для контрактов легко получить нужное событие? Вполне. К примеру, есть транзакция:

const tx = contract.doSomething();
const receipt = await tx.wait();

Тогда мы можем сделать функцию для поиска события

import type { ContractReceipt } from 'ethers';

  async function eventFor(receipt: ContractReceipt, name: string) {
    return receipt?.events?.find(function (e) {
      return e.event === name;
    });
  }

Ищем событие

const myEvent = await eventFor(receipt, "MyEvent");

И достаём из него нужное поле

myEvent?.args?.value

Вопросительные знаки тут потому, что наличие этих полей не гарантированно, то есть формально события может и не быть (другими словами, это атрибуты optional). Но так как мы делаем это в тестах и как раз ожидаем, что оно *должно быть* (если, конечно, все предварительные условия выполнены), то всё должно сработать корректно. А вот если события как раз нет, то вылетит ошибка, тест сломается и мы поймём, что где-то у нас проблема.

Немного backstage (начал готовить новый урок) 😄

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

Это довольно длинный урок, на запись которого ушло весьма приличное время, так что надеюсь, он вам понравится. https://www.youtube.com/watch?v=pz8NeV6bo3E

Планируется саммит по Rails в начале следующего года. Правда интересных докладов там пока как-то не очень много, и, похоже, послушать их можно только за деньги (пусть и не очень большие) https://events.geekle.us/ruby

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

Charges

Amount
Application dynos $ 6.34
Add-on services $ 8.16
Subtotal: $ 14.50
Total:

$ 14.50

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

В этом уроке по Ruby мы узнаем, как правильно тестировать ошибки, которые может вернуть сторонний сервис. Также мы добавим и настроим Rubocop для исправления стиля нашего кода и наконец-таки опубликуем финальную версию библиотеки на сайт rubygems, чтобы её могли использовать другие разработчики. https://www.youtube.com/watch?v=WLgSqsQCKHQ

У меня вот тоже уникальный вкус, только, наверное, в другом смысле. А у вас как? 😂

Ну, и последняя запись на сегодня. Нашёл забавное рекламное видео бородатых годов, где представлен всем известный "микроавтобус" RAF-977, что означает всего лишь Rīgas Autobusu Fabrika. Удивительно, снято ещё в шестидесятые, а места все знакомые - совсем не изменились. https://twitter.com/sovietvisuals/status/1588642492009824259

В следующий вторник у нас очередной выпуск нашей интеллектуальной игры, так что welcome - можно будет сыграть за команду зрителей 🤓 https://youtu.be/zmgjArEfXdw

В этом месяце состоялась годовщина нашего фотопроекта "Легенды Оссиании", которому исполнилось пять лет. В рамках проекта мы выпустили некоторое количество фотокомиксов - как серьёзных, так и смешных (сюжет всего этого безобразия писал ваш покорный слуга). К сожалению, политическая ситуация не позволяет нам продолжать работу (участники проекта живут в разных странах), но хотя бы есть, что вспомнить. Эта страница фотокомикса, пожалуй, наиболее любимая и в целом наиболее личная (как и вся эта и последующая части). На создание всей этой истории ушло какое-то легендарное количество времени, но результат получился вполне приличным. Ссылка здесь https://vk.com/ossiania_legends (постоянные читатели и так её уже видели). Ну, а мы с вами скоро увидимся, ибо в этом месяце планируется аж три стрима по разным темам. Берегите себя.

Культурные типажи (модель Льюиса)

Готовность 6-7 минут :) https://youtu.be/zmgjArEfXdw

Сегодня просто музыка. Спокойной ночи https://www.youtube.com/watch?v=4S8oMP-nxeQ

Друзья, предварительно: завтра вечером в районе 21-22 UTC+3 будет стрим по Solidity и байткоду. Посмотрим, как вызываются функции, какие там опкоды и особенности. Думаю, будет интересно 😄

Залетайте на стрим через три часа https://youtu.be/p2ZUQR-jCDA 😄

2 минуты до готовности https://youtu.be/p2ZUQR-jCDA

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

Отвечая на вопрос по следам двух прошлых уроков про байткод: что именно происходит при попытке использования delegatecall? Иными словами, что там в байткоде?

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

contract Target {
    uint a;

    function callMe(uint _a) external {
        a = _a;
    }
}

contract Demo {
    uint a;
    address to;
    
    constructor(address _to) {
        to = _to;
    }

    function doCall() external {
        (bool success,) = to.delegatecall(
            abi.encodeWithSignature("callMe(uint256)", 42)
        );
        require(success);
    }
}

В дебаггере там будет куча не сильно интересных инструкций, которые делают всякие проверки, кодируют сигнатуру и подготавливают стек, но главные инструкции имеют номера 240 и 241 (это с оптимизацией 2000):

GAS(0x5a)
DELEGATECALL (0xf4)

GAS - смотрит, что там по газу осталось, а DELEGATECALL использует значения из стека и определяет с их помощью байткод какого контракта надо выполнить, какой там селектор функции найти и какой аргумент в эту функцию передать. А дальше на DELEGATECALL можно просто нажать кнопку step into и guess what: вы прыгнете к байткоду другого контракта, где все инструкции начинаются опять с нуля, причём в начале будет уже знакомый набор

000 PUSH1 80 - LINE 5
002 PUSH1 40 - LINE 5
004 MSTORE - LINE 5

То есть пока крутится delegatecall, у него там своя атмосфера и своя память. В calldata же будет содержаться что-то такое

0xe73620c3000000000000000000000000000000000000000000000000000000000000002a

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

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

Ну, а дальше опкоды будут очень похожи на то, что мы видели. Например, мы увидим

026 CALLDATALOAD - LINE 5
027 PUSH1 e0 - LINE 5
029 SHR - LINE 5

Опять как в уроке - он читает calldata и вычленяет оттуда селектор.

А потом

031 PUSH4 e73620c3 - LINE 5
036 EQ - LINE 5

Ну то есть сравниваем селектор. А дальше там всё просто - он берёт из calldata аргумент и говорит

057 PUSH1 00 -
059 SSTORE - 

0 - это номер слота переменной a в контракте Target, тк она там на самой первой позиции (потому что в момент компиляции контракта Target он знает, какой слот был у a). Но тк это выполняется в нашем контексте, то по факту *мы имеем ввиду нулевой слот в Demo*. Именно поэтому переменные должны быть перечислены в правильном порядке.

Последняя инструкция в рамках delegatecall:

062 STOP - LINE 9

Дальше он возвращается к исходному байткоду, там меряет returndatasize (чтобы понять вернула ли что-нибудь функция), проверяет require и просто говорит STOP, то есть транзакция завершается.

Иными словами, никакой магии особо нет: он прямо берёт чужой байткод и начинает его прогонять с самого начала, но только для своего контекста.

В этом уроке по Solidity мы узнаем, как подписывать сообщения оффчейн с помощью закрытого ключа пользователя. Также мы узнаем, как с помощью ecrecover "восстанавливать" подписывающего из сообщения и с помощью этого механизма реализуем сценарий, когда за перевод денежных средств платит не отправитель, а получатель. https://www.youtube.com/watch?v=QODPMaUlrLw