Solidity 0.8.29

Вчера выпустили новую версию Solidity, вот несколько ключевых изменений, а также пара ссылок.

1. В версии 0.8.29 появилась экспериментальная поддержка EVM Object Format (EOF). Обратите внимание, что эта функция может быть включена только при компиляции для версии EVM Osaka, которая еще не была развернута в mainnet или testnets.

Чуть больше об этом можно узнать тут:

https://x.com/uttam_singhk/status/1830526179105001771

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

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

Чтобы опробовать ее на своем контракте, используйте --experimental-eof-version 1 в командной строке или settings.eofVersion: 1 в стандартном JSON и не забудьте выбрать версию EVM, которая ее поддерживает (--evm-version osaka/settings.evmVersion: «osaka»).

2. В этом выпуске появился синтаксис для перемещения переменных хранения контракта в произвольное место.

contract C layout at 2**255 - 42 {
    uint x;
}

Поддержка указания местоположения хранилища - один из самых старых и обсуждаемых запросов в трекере проблем Solidity, но множество вариантов использования и потенциально противоречивые требования до сих пор не позволяли прийти к какому-то конкретному решению. С включением EIP-7702: Set EOA account code в обновление Pectra, это стало критичным для безопасной реализации абстракции учетных записей, и разработчики решили сделать этот вариант использования приоритетным.

В настоящее время синтаксис очень ограничен: базовое местоположение может быть только буквальным выражением и применяется ко всему дереву наследования.

Чуть больше о EIP7702 можно прочитать тут:

https://cantina.xyz/introduction/pectra-competition-resources/eip-7702

3. Начальная поддержка ethdebug. Этот релиз также представляет первый экспериментальный шаг к поддержке ethdebug - формата отладочных данных, подходящего для смарт-контрактов.

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

Если вы хотите попробовать, вы можете включить вывод ethdebug в командной строке с помощью команды:

--ethdebug/--ethdebug-runtime. 

Чтобы запросить артефакты ethdebug в стандартном JSON, добавьте

evm.bytecode.ethdebug»/«evm.deployedBytecode.ethdebug 

в settings.outputSelection (обратите внимание, что символ «*» не включает его). Также не забывайте, что settings.viaIR: true/--via-ir необходим для работы функции.

4. Также были исправлены несколько проблем с SMTChecker, Error Reporting, Yul Optimizer, а также перешил с C++17 на C++20.

#solidity

Понимание метаданных смарт-контракта. Часть 1

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

Когда solidity генерирует байткод для развертываемого смарт-контракта, он добавляет метаданные о компиляции в конец байткода. Мы рассмотрим данные, содержащиеся в этом байткоде.

Давайте посмотрим на вывод компилятора простейшего смарт-контракта solidity:

//SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract Empty {
    constructor() payable {}
}

Контракт буквально ничего не делает. Мы можем скомпилировать его, чтобы увидеть код инициализации с помощью

solc --optimize-runs 1000 --bin contractFile.sol

Мы получим следующий вывод:

======= contractFile.sol:Empty =======

Binary:
6080604052603e80600 f5f395ff3fe60806040525f80fdfea26469706673582212203082dbb4f4db7e5d53b235f44d3e38f839dc82075e2cda9df05b88e6585bca8164736f6c63430008140033

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

Когда мы компилируем код с помощью

solc --optimize-runs 1000 --bin --no-cbor-metadata contractFile.sol

мы получаем следующий результат:

======= contractFile.sol:Empty =======

Binary:
6080604052600880600 f5f395ff3fe60806040525f80fd

Это гораздо меньше! Но что же это за дополнительная информация?

Метаданные Solidity

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

fea26469706673582212203082dbb4f4db7e5d53b235f44d3e38f839dc82075e2cda9df05b88e6585bca8164736f6c63430008140033

Последние два байта 0033 означают «посмотрите назад на 0x33 байта, это метаданные». Это относится ко всему коду между ведущим fe (который является операционным кодом INVALID) и конечным 0033. Мы можем проверить, что это действительно 0x33 байта.

# fe and 0033 are not included

>>>hex(len('a26469706673582212203082dbb4f4db7e5d53b235f44d3e38f839dc82075e2cda9df05b88e6585bca8164736f6c6343000814') // 2)

# '0x33'

Так что же это за строка 0x33 (51 decimal)?

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

//SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract Empty {
    // nothing
    constructor() payable {}
}

На скриншоте выше показаны результаты до и после.

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

#metadata

Понимание метаданных смарт-контракта. Часть 2

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

С прошлым постом я забыл дать прикрепить ссылку к оригинальной статье, поэтому исправляюсь и выделяю ее отдельно:

https://www.rareskills.io/post/solidity-metadata

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

А сейчас мы продолжаем разговор о metadata.

Расшифровка metadata

Давайте посмотрим на гекс в синей рамке скрина из предыдущего поста:

>>> bytes.fromhex("69706673").decode("ASCII")
'ipfs'

Далее рассмотрим код в красном поле:

>>> bytes.fromhex("736f6c63").decode("ASCII")
'solc'

Это дает нам подсказку о том, что содержат эти данные: хэш IPFS и версию компилятора solidity.

Хэш IPFS

Раздел, подчеркнутый желтым, вместе с бирюзовой рамкой можно поместить в следующий python-скрипт (обратите внимание, что мы используем версию кода с комментарием // nothing):

import base58
hex_ipfs_hash = "12206a68b6b8bcc01ba559ec3adf7a387b6c4210a5dc69a05d038e9d17cae3fa373b"
bytes_str = bytes.fromhex(hex_ipfs_hash)
print(base58.b58encode(bytes_str).decode("utf-8"))

# QmVW2XyafSxDtiSqirJRauuT5SaQtGnQYsxxyYHrFmRTEa

Qm...RTEa - это IPFS-хэш файла метаданных, созданного компилятором. Этот участок кода (бирюзовый и желтый) кодируется иначе, чем поля выше. В частности, IPFS-хэш (бирюзовый и желтый) представляет собой закодированную в base58 версию шестнадцатеричных данных «1220...RTEa».

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

Мы можем сохранить JSON-файл как реальный файл, а затем проверить, что хэш совпадает с тем, который мы создали в python выше. Вам понадобится установленный инструмент командной строки ipfs (как установить).

mkdir out
solc --optimize-runs 1000 --bin --metadata C.sol --output-dir out
# Compiler run successful. Artifact(s) can be found in directory "out".

ipfs add -qr --only-hash out/Empty_meta.json
# QmVW2XyafSxDtiSqirJRauuT5SaQtGnQYsxxyYHrFmRTEa

Это совпадает с хэшем, полученным ранее.

Не приведет ли это к коллизиям хэшей?

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

Получение версии solidity

Наконец, если мы преобразуем секцию в оранжевой рамке, то получим версию solidity.

>>> 0x00 # solidity is version 0
0
>>> 0x08 # major version
8
>>> 0x14 # minor version
20
# correct, we used solidity 0.8.20

Зачем нужны метаданные смарт-контракта?

Эти метаданные добавляют дополнительные 53 байта к стоимости развертывания, что означает дополнительные 10 600 газа (200 на байткод) + стоимость calldata (16 газа на ненулевой байт, 4 газа на нулевой байт). Это означает до 848 дополнительных газа к стоимости calldata.

Так зачем это включать?

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

Один странный трюк для снижения расхода газа через хэш IPFS

Один из очевидных способов оптимизировать затраты на газ во время развертывания - использовать опцию --no-cbor-metadata. Но если вам это нужно для проверки контракта, то вы все равно можете снизить стоимость газа, добывая хэши IPFS, в которых много нулевых байтов.

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

#metadata

Проект на виду. Часть 2. Нейросети

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

В последнее время я все чаще натыкался на посты/статьи/вопросы по нейросетям и редакторам кода на их основе. Очень долгое время я сопротивлялся этой технологии и специально игнорировал ее наличие...

И вот только две недели назад я установил свою первую нейросеть - DeepSeek. Во-первых, она была доступна для пользователей из РФ без ВПН, а во-вторых, не требовалась регистрация с телефоном.

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

На прошлой неделе я решил зайти еще чуть дальше и экспериментировал с остальными нейронками: ChatGPT, Claude, Grok 3, Gemini и даже скачивал редакторы кода: Cursor и Windsurf. Также смотрел много видео по этой теме: как писать промты, какие лимиты есть, для каких целей какие сети предназначены и т.д.

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

И после этого, первым вопросом в моей голове было:

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

Но это еще в процессе осознания...

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

Что бы вы понимали, в плане редакторов и кода я немного "динозавр" что ли... За все время, что я писал код (js, php) в своей карьере, я использовал Notepad++ - без плагинов и какой-никакой подсветки кода. Только за год-два до того как переключиться на Solidity, я писал проекты в VS Code.

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

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

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

Будем практиковаться!

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

Всем приятного дня!

Пара слов о Passkeys

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

Сейчас часто встречаю статьи про технологию регистрации и логина на сайтах web2, которую назвали passkeys. Примечательно то, что она также использует систему приватных/публичных ключей, как и кошельки web3. А теперь, чуть подробнее.

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

1. Публичный ключ: хранится на сервере сервиса и не является конфиденциальным.

2. Приватный ключ: хранится на устройстве пользователя и защищается биометрической аутентификацией (например, отпечаток пальца или распознавание лица).

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

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

Тут надо уточнить, что приватный ключ хранится в защищенных аппаратных компонентах, таких как Secure Enclave (Apple) или Trusted Platform Module (Windows), и может быть защищен биометрией. Именно поэтому потеря девайса - станет проблемой.

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

Как вообще происходит создание ключа и регистрация на сайте:

1. Когда пользователь регистрирует passkey на сайте или в приложении, сервис отправляет запрос на создание новой пары ключей через протокол WebAuthn (Web Authentication API).

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

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

5. Сервер связывает публичный ключ с учетной записью пользователя.

6. Теперь, когда пользователь пытается войти в систему, сервер отправляет запрос на аутентификацию через WebAuthn.

7. Устройство пользователя использует приватный ключ для подписания запроса. Этот процесс требует подтверждения пользователя (например, с помощью биометрии или PIN-кода).

8. Сервер проверяет подпись с помощью публичного ключа, сохраненного при регистрации. Если подпись верна, доступ предоставляется.

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

#passkeys

Перспективы для новичков в web3

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

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

Благодаря нейросейтям уже сейчас огромное количество web2 проектов пишутся в короткие сроки и с довольно хорошим кодом. Даже глава крупнейшего акселератора для стартапов YCombinator как-то в интервью говорил, что более 90% всех проектов у них в компании написаны с помощью нейронок.

Написать хороший web3 протокол с помощью промтов в ChatGPT можно будет уже в этом году. Из-за чего индустрия получит еще большее привлечение внимания: игры, биржи, обменники, стейкинги и т.д.

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

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

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

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

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

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

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

Такой вот понедельничный пост! Всем хорошей недели и приятного обучения!

#offtop

Все, что нужно знать об интеграции Chainlink. Часть 1

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

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

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

Мы рассмотрим три основных нюанса безопасности, которые необходимо учитывать каждый раз, когда вы интегрируете Chainlink в свой проект.

Вот официальный образец контракта (отредактированный для краткости):

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract DegenDeFi {
    AggregatorV3Interface internal constant dataFeed = 
        AggregatorV3Interface(
            0x1b44F3514812d835EB1BDB0acB33d3fA3351Ee43
        );    

    function getLatestData() public view returns (int256) {
        (
            /* uint80 roundId */,
            int256 answer,
            /* uint256 startedAt */,
            /* uint256 updatedAt */,
            /* uint80 answeredInRound */
        ) = dataFeed.latestRoundData();
        return answer;
    }
}

Он вызывает функцию latestRoundData() на dataFeed и возвращает ответ int256. Внимательные читатели заметят, что ответ технически может быть отрицательным.

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

Работа с отрицательными и нулевыми ответами

Поскольку большинство приложений DeFi предполагают неотрицательную цену, мы должны привести ответ к значению uint256 и вернуть его. Как реагировать на ответ <= 0, зависит от ситуации.

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

    function getLatestData() public view returns (uint256) {
        (
            /* uint80 roundId */,
            int256 answer,
            /* uint256 startedAt */,
            /* uint256 updatedAt */,
            /* uint80 answeredInRound */
        ) = dataFeed.latestRoundData();

        // ✨ added sanity check
        if (answer <= 0) {
            // Option 1 (Recommended): Assume something went wrong 
            revert InvalidAnswer(answer);

            // Option 2: Treat it as a 0
            // return 0;
        }

        return uint256(answer);
    }

Добавьте проверку на устаревшие данные

У Chainlink Feeds есть два параметра триггера, которые определяют, когда ответ должен быть обновлен. Они называются порог отклонения и сердцебиение - deviation threshold и heartbeat.

В приведенном выше на скрине примере, цены будут обновляться либо:

1. когда цена вне цепи изменяется более чем на ±0,5% по сравнению с последней опубликованной ценой, либо

2. если с момента последнего обновления прошло 24 часа.

Несмотря на эти правила, интеграторы не должны полагать, что сообщаемая цена находится в пределах 0,5% от цены off-chain или что она не более чем на 24 часа устарела.

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

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

    function getLatestData() public view returns (uint256) {
        (
            /* uint80 roundId */,
            int256 answer,
            /* uint256 startedAt */,
            uint256 updatedAt,
            /* uint80 answeredInRound */
        ) = dataFeed.latestRoundData();

        if (answer <= 0) {
            revert InvalidAnswer(answer);
        }

        // ✨ added staleness check
        uint256 staleness = block.timestamp - updatedAt;
        if (staleness >= MAX_STALENESS) {
            revert StaleAnswer(staleness);
        }

        return uint256(answer);
    }

Теперь функция отклоняет ответ feed, если она была обновлена более 24 часов назад.

В пятницу мы продолжим разбирать эту тему.

#chainlink

Все, что нужно знать об интеграции Chainlink. Часть 2

Продолжаем разбирать основные принцип работы с Chainlink.

Не думайте, что значение latestRoundData всегда будет получено

Большинство оракулов Chainlink могут быть с контролем доступа, например код агрегатора stETH / ETH. Вызовы view функций будут ревертиться, если вызывающий попал в черный список.

Есть вероятность, что в будущем доступ к оракулам Chainlink будет ограничен для платных клиентов (в настоящее время Chainlink субсидируется и не имеет модели монетизации для своих наиболее используемых фидов).

Если вы создаете неизменяемый протокол с резервным оракулом, имеет смысл окружить вызов latestRoundData() оператором try-catch, чтобы иметь возможность "варианта 2" на такой случай.

function getLatestData() public view returns (uint256) {
        try dataFeed.latestRoundData() returns (
            /* uint80 roundId */,
            int256 answer,
            /* uint256 startedAt */,
            uint256 updatedAt,
            /* uint80 answeredInRound */
        ) {
            // validate and return
        } catch {
            // use fallback oracle
        }
    }

Проверяйте качество Feed

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

Новые пары ценовых фидов будут иметь статус Provisional в течение первых 90 дней после их выпуска, в течение которых их параметры могут измениться. Monitored Feeds - это фиды, «находящиеся на рассмотрении команды Chainlink Labs для поддержки стабильности широкой экосистемы», что означает, что они недавно стали нестабильными или менее ликвидными, чем хотелось бы.

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

Категория Deprecating - это худшая категория, если вы создаете неизменяемый протокол, хотя ни один Chainlink Feed еще не был выведен из употребления.

Делайте форк осторожно

Если вы форкаете код, написанный в 2021 году или ранее, дважды проверьте, что в нем нет вызовов latestAnswer(). Этот метод уже устарел, и вам следует заменить вызовы latestAnswer() на latestRoundData().

Модель доверия

Всегда полезно проверить исходный код и состояние развернутых контрактов, связанных с фидом. Обычно это выглядит примерно так: EACAggregatorProxy (контракт, который вы вызываете через AggregatorV3Interface), принадлежащий мультисигу. Мультисиг может передавать право собственности и менять агрегатор. Агрегатор содержит такие интересные параметры, как:

1. transmitters - адреса, на которые разрешено отправлять ответы,

2. minAnswer и maxAnswer, определяющие, что считается правильным ответом,

3. decimals числа ответа.

Вот несколько выводов, которые я сделал во время написания этой статьи:

1. Фид цены Ethereum stETH / ETH считает допустимым ответ в диапазоне от 0,001ETH до 100ETH.

2. Мультисиг, используемый в фидах Optimism, имеет 20 подписантов, но порог выполнения составляет всего 3! У половины подписантов нет ETH и они никогда не совершали транзакций на Optimism. Такая же сомнительная система существует на нескольких альтернативных блокчейнах.

3. Цена LINK менее 0,1 доллара США считается недействительной благодаря фиду LINK / USD.

Убедитесь, что вы понимаете и принимаете предположения о доверии к фидам, прежде чем интегрировать их в свое приложение.

В понедельник разберем еще пару последних пунктов на эту тему.

#chainlink

Все, что нужно знать об интеграции Chainlink. Часть 3

Ну, и последний пост про интеграцию с Chainlink.

Убедитесь, что секвенсор L2 работает

Chainlink поддерживает специализированные каналы L2 Sequencer Uptime Feeds для Arbitrum, Optimism и Metis. Общим для этих цепочек является то, что они представляют собой оптимистичные роллапы, использующие контракт секвенсора для пакетной обработки и выполнения транзакций L2. Если секвенсор не функционирует, то входящие транзакции L2 остаются в очереди, ожидая выполнения, когда секвенсор снова станет доступен.

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

При получении данных Chainlink на Arbitrum, Optimism и Metis проверяют, что секвенсор работал в течение минимального времени. Например:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract DegenDeFi {
    AggregatorV3Interface internal dataFeed;
    AggregatorV3Interface internal sequencerUptimeFeed;

    uint256 private constant MIN_SEQUENCER_UPTIME = 3600;

    error SequencerDown();
    error SequencerPending();

    constructor() {
        dataFeed = AggregatorV3Interface(
            0x1b44F3514812d835EB1BDB0acB33d3fA3351Ee43
        );
        sequencerUptimeFeed = AggregatorV3Interface(
            0x4C4814aa04433e0FB31310379a4D6946D5e1D353
        );
    }

    function getLatestData() public view returns (int256) {
        // ✨ added uptime check
        (
            /* uint80 roundId */,
            int256 status,
            uint256 startedAt,
            /* uint256 updatedAt */,
            /* uint80 answeredInRound */
        ) = sequencerUptimeFeed.latestRoundData();

        if (status != 0) {
            revert SequencerDown();
        }

        // ✨ ensures the pending queue is cleared
        uint256 timeSinceUp = block.timestamp - startedAt;
        if (timeSinceUp < MIN_SEQUENCER_UPTIME) {
            revert SequencerPending();
        }

        // ... (get price feed data)
    }
}

Будьте осторожны с Wrapped и Bridged Tokens

Использование Chainlink feed для ценообразования деривативных токенов почти всегда является анти-паттерном.

Критическим подводным камнем, является ценообразование bridged ETH на менее ликвидных сетях с использованием feed ETH / USD. Хотя механизм выкупа 1:1 существует в обоих направлениях, предоставляя возможность привязать активы с помощью арбитража, этот механизм может сломаться в экстремальных экономических ситуациях.

Будь то уменьшение ликвидности в сети назначения или давление на продажу производного актива после крупного взлома, в результате чаще всего bridge актив становится дешевле своего базового актива. Это может стать проблемой для рынка кредитования, который рассматривает этот актив как 1:1 с ETH.

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

Подумайте о запасном варианте

Что должно произойти с вашим приложением, если ответ канала Chainlink будет признан недоверенным? Самый простой и, на мой взгляд, обычно правильный подход - просто отказать в обслуживании (т. е. выполнить откат), пока ответ фида не будет признан удовлетворительным.

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

Комбинируйте цены с осторожностью

И, наконец, будьте внимательны, комбинируя ответы фидов для получения цены. Если нам нужна цена APE в пересчете на ETH на Arbitrum, то мы не сможем получить ответ напрямую, поскольку не существует фида APE / ETH. Вместо этого мы можем разделить ответ фида APE / USD и фида ETH / USD, чтобы получить цену APE / USD.

Помните, что фиды, номинированные в долларах США, имеют 8 decimals, а фиды, номинированные в ETH, имеют 18 decimals. Если мы объединим два фида с точностью 8 decimals, то наши результаты будут иметь точность только 8 decimals, а остальное будет "ошибкой деления".

    function getLatestData() public view returns (uint256) {
        (, int256 apeUsd, , , ) = apeUsdFeed.latestRoundData();
        (, int256 ethUsd, , , ) = ethUsdFeed.latestRoundData();

        // ✨ this only really has 8 decimals of precision
        // this is usually sufficient
        int256 apeEth = (apeUsd * 1e18) / ethUsd;

        return uint256(apeEth);
    }

Надеюсь данный гайд был хоть немного, но полезен! Скоро поговорим о мультисигах!

#chainlnk

Проект на виду. Часть 3. Solidity и React все таки придется учить

Держу вас в курсе, как продвигаются мои эксперименты с нейронками и созданием web3 проекта.

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

Вот полная история.

В 20 числах марта я получил приглашение к новомодному агенту на основе множества ИИ - Manus. По заверениям разработчиков и огромному количеству твитов и видео о том, какой Манус классный и как он создает проекты, я решил попробовать дать задание на создание простого сайта именно ему.

Если кратко, то:

1. Manus должен был создать такой сайт:
- Одностраничник, где выводились бы новости в в виде карточек (пример карточки я приложил в виде картинки png и ссылки на сам сайт);
- Сайт должен выглядеть как чат DeepSeek - меню слева, карточки на главной, а когда заходишь на статью, то выглядит она как отправленные сообщения;
- Есть админский доступ к добавлению новых статей и разделов;
- Сложная часть: создание статьи, где текст, картинки и видео могут идти вперемешку;
- Все должно было подключаться к базе данных: получать инфу о статьях и добавлять новые статьи;

2. Стек также был достаточно распространенным: React, PHP, axios, mysql, tailwind. Ну, т.е. вообще база.

3. В качестве редактора кода я выбрал CursorAI с агентом Claude 3.7 Sonnet.

Повторюсь, что я не использовал ни правила для курсора, ни промты для задания. Мне было интересно поставить себя на место "новичка с идеей".

В общем Manus прислал довольно обширный набор файлов. Его структуру можно увидеть на скрине.

Что было дальше?

А все! Проект проблематично собрать.

1. Не хватает части файлов для сборки react приложения;
2. Предложенная mysql база отличается от запросов в базу реализованной в коде;
3. Backend также требует существенных доработок.

Если попробовать задавать вопрос в Claude, типа: "Вот ошибка:... Как ее исправить?", а затем просто бездумно принимать все варианты, то в какой-то момент поймешь, что двигаешься по кругу.

Спустя три дня таких "кликов", создания кучи новый файлов для дебагга и ловли ошибок, я просто удалил весь проект.

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

Если брать во внимание Solidity, то это будет вообще кошмар! Код контракта будет создан, но как весь проект будет работать сообща, и его околонулевой уровень безопасности будет внушать страх.

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

Нейросети в этом случае будут невероятным помощником!

Для моего личного проекта на днях с помощью Claude и DeepSeek был написан отличный код для генерации AST-паттерна. Хорошо оптимизирован, быстро работает, корректно отрабатывает все условия, просто сказка!

Разница только в одном: в первом случае - я просто принимал все правки и не заглядывал в код, во втором - я точно знал, за что отвечает каждый участок кода и какой результат его выполнения я должен получить.

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

#ai #code

Работа с мультисиг кошельками. Часть 1

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

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

Что такое мультисиг-кошелек?

Кошелек multisig (сокращение от multi-signature) - это тип криптовалютного кошелька, который требует более одной подписи (или закрытого ключа) для авторизации транзакции. В отличие от традиционных кошельков, которым обычно требуется только один приватный ключ для отправки или получения средств, мультисиговые кошельки распределяют контроль между несколькими сторонами, что делает их значительно более безопасными.

Принцип работы мультисиговых кошельков

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

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

1. 2-of-2 Multisig: Для авторизации транзакции требуется две подписи от двух разных закрытых ключей.
2. 2-of-3 Multisig: Для авторизации транзакции требуется две подписи из трех возможных.
3. 3-of-5 Multisig: Для авторизации транзакции требуется три из пяти возможных подписей.

Гибкость кошельков multisig позволяет пользователям настраивать уровень безопасности и контроля в зависимости от их конкретных потребностей.

Зачем использовать кошелек Multisig?

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

Совместный контроль и подотчетность

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

Резервное копирование и восстановление

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

Доверительные транзакции

Мультисиговые кошельки также могут способствовать проведению бездоверительных транзакций между сторонами, которые не обязательно доверяют друг другу. Например, в системе 2-of-3 multisig две стороны могут хранить по одному ключу, а третья сторона, которой доверяют (например, служба эскроу), хранит третий ключ. Таким образом, ни одна из сторон не может в одностороннем порядке завладеть средствами, что гарантирует защиту интересов обеих сторон.

Дальше больше!

#multisig

Работа с мультисиг кошельками. Часть 2

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

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

Шаг 1: Выберите провайдера

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

1. Electrum: Популярный биткойн-кошелек, поддерживающий multisig.
2. BitGo: Комплексный провайдер кошельков, обеспечивающий безопасность биткоина и других криптовалют с помощью multisig.
3. Armory: Биткойн-кошелек с расширенными функциями безопасности, включая multisig.
4. Coinbase: Известная криптовалютная биржа, предлагающая хранилища multisig для повышения безопасности.
5. Gnosis Safe: Мультисиг-кошелек, специально разработанный для Ethereum и токенов ERC-20.

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

Шаг 2: Настройте кошелек

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

Шаг 3: Сгенерируйте и распределите закрытые ключи

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

Шаг 4: Протестируйте кошелек

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

Шаг 5: Используйте его

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

Завтра поговорим о кейсах, где можно использовать такие кошельки.

#multisig

Работа с мультисиг кошельками. Часть 3

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

1. Использование в бизнесе и организациях

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

2. Совместные счета

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

3. Эскроу-сервисы

В сделках с большими суммами денег часто возникает вопрос доверия. Кошельки Multisig могут служить в качестве счетов условного депонирования, где средства надежно хранятся до тех пор, пока все стороны не согласятся их выдать. Например, в кошельке 2-of-3 покупатель, продавец и эскроу-агент имеют по одному ключу. Средства выдаются только тогда, когда покупатель и продавец удовлетворены, а эскроу-агент выступает в качестве нейтральной стороны.

4. Децентрализованные автономные организации (ДАО)

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

5. Наследование и планирование наследства

Мультисиговые кошельки также можно использовать для наследования и планирования наследства. Создав мультисиг-кошелек, люди могут гарантировать, что их активы будут распределены в соответствии с их пожеланиями после их смерти. Например, в мультисиг-кошельке 2-of-3 могут участвовать сам человек, доверенный член семьи и душеприказчик. После смерти человека доступ к средствам будет возможен только при наличии подписей членов семьи и душеприказчика, что гарантирует, что активы будут распределены по назначению.

Плюсы и минусы мультисиговых кошельков

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

Плюсы

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

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

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

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

Минусы

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

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

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

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

Далее пара слов о безопасности.

#multisig

Работа с мультисиг кошельками. Часть 4

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

1. Используйте надежных провайдеров кошельков

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

2. Безопасно распределяйте закрытые ключи

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

3. Реализуйте план резервного копирования

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

4. Регулярно пересматривайте настройки безопасности

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

5. Обучите владельцев ключей

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

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

#multisig

Проект на виду. Часть 4. Кто, кого учит и забавные нейронки

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

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

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

1. Творческий генератор новых форм аудита

Представь себе “поэзию уязвимостей” — берём баг, и описываем его в стиле хайку, рэпа, или театральной сценки:

Delegatecall зовёт —
контракт пуст, но наивен —
казна растворилась.

Это может быть способ объяснить баги людям, далеким от технарщины, например, для legal-команд или UX-дизайнеров. И в то же время — развлечь аудиторов.

2. Баговый оракул: "Гадание на смарт-контрактах"

Ты вводишь фрагмент кода или случайный вопрос.

Оракул возвращает одну из уязвимых функций с мистическим посланием:

"Ты доверяешь внешнему контракту... Но он не верит тебе."

Абсурдно? Да. Прикольно? Абсолютно.

3. “Контрактный Таро” — психологическая игра для аудитора

Вытягиваешь "карту": уязвимая функция.

Интерпретируешь — что она говорит тебе как разработчику или аудитору сегодня.

“Эта уязвимость говорит: не доверяй внешнему, пока не понял внутреннего.”

4. Web3-комикс “Багчейн Хроники”

Главные герои — баги. Прямо как в «Inside Out», только вместо эмоций — уязвимости.

Каждая серия — конкретный баг, который пытается саботировать мир Web3, а храбрый Dev пытается его остановить.

Имена типа: Reentrix, Underover, PhantomCaller, Unsafe Joe.

5. Баг-астрология: “ты — какой баг по знаку Зодиака?”

Весы? Ты — UnvalidatedInput.

Скорпион? Конечно же, ты delegatecall without restriction.

Козерог — unchecked math — всё по делу, без эмоций.

Бонус: можно делать гайды для Dev'ов по взаимодействию с другими “баг-знаками”.

6. Интерактивный квест “10000 багов до просветления”

Каждый найденный баг — шаг к просветлению.

Ты начинаешь как “Junior Padawan of Code”.

И далее все в этом духе, только менее абсурдное.

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

Ну, и в завершение немного о "Кто, кого учит?".

Практикуясь с запросами на написание кода на языке Python (его я не знаю совсем), а также связью файлов в тестовом проекте, я открыл для себя одну вещь.

Я намного лучше стал формировать свою мысль и то, что мне нужно.

Нейронки устроены так, что дают вам не то, что вы хотите, а что вы запрашиваете. Грубо говоря: Без четкого ТЗ, выполнение ХЗ!

Представьте, что вы подходите к случайному человеку на улице и такой: "А напиши-ка мне скрипт на анализ кода!", и человек: "Ну, на вот хрень какую-то. Может сработает может нет...". И ты потом начинаешь уточнять: "Да, нет! Мне нужно на Питоне...", и потом с каждым разом все больше и больше уточнений пока... не приходят лимиты! И тебе нужно ждать некоторое время, чтобы они обнулились.

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

И вот тут, кто кого обучил? Я научил нейронку выдавать мне нужный результат или она меня правильно формулировать запрос?

На самом деле, это офигенный скилл! Это помогает и с нейронками, и с любыми другими запросами. Четко, детально и с ожидаемым результатом.

А чему вы научились?

#offtop

Работа с мультисиг кошельками. Часть 5

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

Я потихоньку буду разворачивать весь код, чтобы вы успевали следить за мыслью. Итак, начнем.

Давайте рассуждать, что нам вообще потребуется:

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

2. Также нам потребуется наперёд знать, сколько человек будет одабривать действия, и проверка, что у пользователя действительно есть права на это.

За это, как раз, и будут отвечать эти переменные:

    address[] public owners;
    mapping(address => bool) public isOwner;
    uint256 public numConfirmationsRequired;

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

    struct Transaction {
        address to;
        uint256 value;
        bytes data;
        bool executed;
        uint256 numConfirmations;
    }

    Transaction[] public transactions;

4. Ну, и само собой, некоторый набор модификаторов для быстрой валидации владельцев и статуса транзакций:

    modifier onlyOwner() {
        require(isOwner[msg.sender], "not owner");
        _;
    }

    modifier txExists(uint256 _txIndex) {
        require(_txIndex < transactions.length, "tx does not exist");
        _;
    }

    modifier notExecuted(uint256 _txIndex) {
        require(!transactions[_txIndex].executed, "tx already executed");
        _;
    }

    modifier notConfirmed(uint256 _txIndex) {
        require(!isConfirmed[_txIndex][msg.sender], "tx already confirmed");
        _;
    }

5. И для того, чтобы можно было отслеживать, кто подписал транзакцию, а кто нет, мы введем маппинг:

mapping(uint256 => mapping(address => bool)) public isConfirmed;

6. И в конструкторе нам потребуется сделать несколько проверок и записать изначальные данные в переменные состояния:

    constructor(address[] memory _owners, uint256 _numConfirmationsRequired) {
        require(_owners.length > 0, "owners required");
        require(
            _numConfirmationsRequired > 0
                && _numConfirmationsRequired <= _owners.length,
            "invalid number of required confirmations"
        );

        for (uint256 i = 0; i < _owners.length; i++) {
            address owner = _owners[i];

            require(owner != address(0), "invalid owner");
            require(!isOwner[owner], "owner not unique");

            isOwner[owner] = true;
            owners.push(owner);
        }

        numConfirmationsRequired = _numConfirmationsRequired;
    }

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

В итоге мы получаем базовый набор контракта: