Проект на виду. Часть 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;
    }

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

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

contract MultiSigWallet {
    event Deposit(address indexed sender, uint256 amount, uint256 balance);
    event SubmitTransaction(
        address indexed owner,
        uint256 indexed txIndex,
        address indexed to,
        uint256 value,
        bytes data
    );
    event ConfirmTransaction(address indexed owner, uint256 indexed txIndex);
    event RevokeConfirmation(address indexed owner, uint256 indexed txIndex);
    event ExecuteTransaction(address indexed owner, uint256 indexed txIndex);

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

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

    // mapping from tx index => owner => bool
    mapping(uint256 => mapping(address => bool)) public isConfirmed;

    Transaction[] public transactions;

    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");
        _;
    }

    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;
    }
}

Дальше поговорим о функциях в контракте.

#multisig

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

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

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

Итак, какие же функции нам потребуются?

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

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

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

4. Ну, и понятное дело, исполнять ее.

В итоге у нас получается:

function submitTransaction(...) public {...} 
function confirmTransaction(...) public {...}
function revokeConfirmation(...) public {...}
function executeTransaction(...) public {...}

Начнем с первой.

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

    function submitTransaction(address _to, uint256 _value, bytes memory _data) public onlyOwner {
        uint256 txIndex = transactions.length;

        transactions.push(
            Transaction({
                to: _to,
                value: _value,
                data: _data,
                executed: false,
                numConfirmations: 0
            })
        );

        emit SubmitTransaction(msg.sender, txIndex, _to, _value, _data);
    }

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

Далее функции ободрения и отзыва для владельцев мультисига.

    function confirmTransaction(uint256 _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
        notConfirmed(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];
        transaction.numConfirmations += 1;
        isConfirmed[_txIndex][msg.sender] = true;

        emit ConfirmTransaction(msg.sender, _txIndex);
    }

    function revokeConfirmation(uint256 _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];

        require(isConfirmed[_txIndex][msg.sender], "tx not confirmed");

        transaction.numConfirmations -= 1;
        isConfirmed[_txIndex][msg.sender] = false;

        emit RevokeConfirmation(msg.sender, _txIndex);
    }

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

Берем id транзакции, делаем проверки и изменяем numConfirmations в нужную сторону.

Далее исполнение транзакции.

    function executeTransaction(uint256 _txIndex)
        public
        onlyOwner
        txExists(_txIndex)
        notExecuted(_txIndex)
    {
        Transaction storage transaction = transactions[_txIndex];

        require(
            transaction.numConfirmations >= numConfirmationsRequired,
            "cannot execute tx"
        );

        transaction.executed = true;

        (bool success,) =
            transaction.to.call{value: transaction.value}(transaction.data);
        require(success, "tx failed");

        emit ExecuteTransaction(msg.sender, _txIndex);
    }

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

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

    receive() external payable {}

   function getOwners() public view returns (address[] memory) {
        return owners;
    }

    function getTransaction(uint256 _txIndex) public view
        returns (
            address to,
            uint256 value,
            bytes memory data,
            bool executed,
            uint256 numConfirmations
        )
    {...}

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

Далее поговорим о деплое кошелька, на примере Safe.

#multisig

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

Как развернуть (Gnosis) Safe Multisig локально с помощью anvil?

Safe Wallet - это один из самых популярных мультисиг кошельков на Ethereum и других EVM-совместимых блокчейнах. Он широко используется отдельными разработчиками, командами и DAO для безопасного управления криптоактивами.

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

1. Для начала нам потребуется скопировать кошелек с официального репо:

git clone https://github.com/safe-global/safe-smart-account.git

2. Далее установим его зависимости:

npm i 

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

npm run build

3. Теперь мы готовы запустить все тесты и проверить, готовы ли мы к развертыванию, для этого просто запустите:

npm run test

Выполнение всех тестов займет около 30 минут в зависимости от вашей машины.

Деплой в локальную сеть

4. Создайте файл .env в каталоге проекта со следующим содержимым:

MNEMONIC=”test test test test test test test test test test test junk”
NODE_URL="http://127.0.0.1:8545"

5. Запускаем Anvil:

anvil

6. Это не обязательно, но мы можем перекомпилировать контракты, если в них были внесены какие-либо изменения:

npm run build

7. Теперь, наконец, мы можем развернуть все контракты в локальной сети с помощью команды

npx hardhat --network custom deploy

В терминале появятся логи с контрактами и адресами Safe для дальнейшего взаимодействия.

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

#multisig

Проект на виду. Часть 5. ИИ вас не заменит

В какой-то рекламе в Твиттере встретил прекрасную фразу: ИИ вас не заменит, вас заменит человек, который умеет работать с ИИ.

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

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

В общем, для собственного эксперимента и практики, я выбрал стек React+Vite, Tailwind (стили), бек на Python + flask, mysql + php.

Из этого списка я никогда ранее не работал с Vite, Tailwind и Python. И если с Vite и стилями еще можно как-то разобраться, если ты знаешь реакт и css, то Python для меня идет с абсолютного нуля.

Для генерации скриптов я использую нейросети. И запросы отправляю практически всем: DeepSeek, ChatGPT, Grok, Claude, Gemini. И хочу поделиться, что я заметил.

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

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

В-третьих, пока что они плохо работают с большим объемом кода. Если файл содержит 1000+ строчек кода, нейронки будут выдавать вам ответ, который будет только портить изначальную идею скрипта.

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

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

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

И это при том, что я тестировал код на Python! Одном из самых популярных языков в мире, с огромной документацией, примерами и наработками.

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

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

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

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

Учите Solidity и учитесь формировать запросы с контекстом.

#offtop

Blockchain reorgs. Часть 1

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

В Web3 мы часто слышим идиому «блокчейн неизменен», но бывают случаи, когда это не так, точнее, он становится практически неизменным (достигает окончательности) только по прошествии некоторого времени с момента майнинга блока, содержащего транзакции пользователей. Это связано с событиями, называемыми реорганизациями блокчейна, или сокращенно reorg.

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

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

Когда происходит перестройка блока, то, будучи внешним наблюдателем цепочки, вы видите, что:

1. Несколько блоков были отброшены и заменены другими;

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

Реорганизации появляются чаще, чем люди думают. Используя такие сканеры, как polygonscan.com/blocks_forked, для Polygon reorgs, вы можете увидеть, что они появляются часто.

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

Примечания и наблюдения

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

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

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

Системы, основанные на случайной составляющей в сети

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

Пример ситуаций, которые могут возникнуть:

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

- азартный игрок проигрывает в игре в кости, но благодаря реорганизации блокчейна он теперь фактически выигрывает;

На практике для вычисления случайного числа часто используется VRF (Verifiable Random Function) от Chainlink. Этот API принимает время подтверждения блока, которое, если верить документации, представляет собой:

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

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

#reorg

Blockchain reorgs. Часть 2

Продолжаем наш разговор про реорганизацию блокчейна.

Off-ramp системы

Под криптовалютным off-ramp понимается процесс обмена криптовалют на фиатную валюту. К системам, осуществляющим офф-рампинг криптовалют, относятся:

- централизованные биржи (CEX);

- провайдеры криптовалют в фиат;

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

В этой серии постов приведены некоторые конкретные требования к подтверждению блоков, которые существуют на известных CEX. Например, Coinbase требует 35 подтверждений блоков для депозитов ETH, в то время как Binance - только 12.

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

Off-ramp системы, особенно CEX, являются привлекательной целью для атак 51%. В прошлом было несколько случаев, когда злоумышленники получали 51% ресурсов проверки сети (коэффициент хеширования) и инициировали вывод средств на нескольких биржах, а затем реорганизовывали цепочку, чтобы повторно инициировать вывод средств на других биржах.

Наиболее заметные атаки 51% затрагивают токены Verge, Ethereum Classic, Bitcoin Gold, Feathercoin и Vertcoin.

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

Протоколы, которые требуют от пользователей создать что-то, а затем взаимодействовать с этим в два этапа

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

Еще одним важным и ключевым условием является то, что развернутые контракты используют ключевое слово в Solidity "new" для создания контракта (или опкод CREATE). Обе эти процедуры полагаются на nonce вызывающего контракта для определения адреса вновь развернутого контракта и не учитывают никаких пользовательских данных.

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

Примерный сценарий атаки в описанном выше случае:

1. Alice создает Vault через контракт фабрики (транзакция A);

2. затем Alice вносит в Vault токены (транзакция B);

3. происходит реорганизация блока, и транзакция A отбрасывается (транзакция B все еще существует);

4. обычно транзакция B возвращается, если выполняется;

5. Bob развертывает свой Vault, который первоначально сделала Alice (через фронтран), и из-за базовой проблемы оно= создается по тому же адресу, что и первоначальное хранилище

6. депозит Alice попадает в Bob Vault, и тот может его снять;

Для того, чтобы решить эту проблему, используйте опкод create2, а соль должна содержать элементы, характерные для вызывающей стороны (например, хэш на входы плюс msg.sender).

#reorg

Содержание предыдущих постов

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

P.S. Также буду рад и признателен репостам.


Обучающие посты

1. Solidity hints. Часть 22

2. Solidity hints. Часть 23

3. Solidity hints. Часть 24

4. Solidity hints. Часть 25

5. Merkle-Patricia Trees. 14 постов

6. Низкоуровневый вызов и высокоуровневый вызов в Solidity. 2 поста

7. RSA алгоритмы. 4 поста

8. Самые популярные типы DAO. 3 поста

9. Обновляемые контракты (Transparent proxy). 5 постов

10. Calldata Encoding. 3 поста

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

12. Пара слов о Passkeys

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

14. Работа с мультисиг кошельками. 7 постов

15. Blockchain reorgs. 2 поста


Видео

16. Запись стрима "Подготовка протокола (dApp) к аудиту"

17. Запись стрима "ERC4626: проблемы и решения"

18. Пробы записи видео и разбор функций

19. Постфикс и префикс в Solidity

20. Взлом контракта через calldata

21. Опасный модификатор


Для начинающих аудиторов

22. Небольшая история о путешествии в мире аудита

23. Челлендж: 50 не валидных репортов

24. Нужно ли доводить аудит до конца?

25. Коротко о двойных стандартах в конкурсных аудитах

26. Роудмап: Как стать аудитором смарт контрактов. 3 поста

27. Конкурсные аудиты с пулом "по условию" - Conditional Pool

28. Упражнение для начинающих аудиторов

29. Про подготовку к аудиту

30. Ловушка аудитора и недостаток валидации


Остальное

31. Минимальные требования для работы

32. Тестирование != тестирование

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

34. Компилятор тоже умеет шутить


Приятного изучения и хорошего дня!

#offtop

🧨 Программа 1 модуля курса, 3 поток!

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

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

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

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

В-третьих, я понял, что вместе с базовыми знаниями Solidity нужно давать объяснение ученикам, как это происходит на уровне виртуальной машины Эфириум. Простыми словами с отсылками к Yellow Pages.

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

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

Итак, вот программа модуля:


Неделя 1

Урок 1. Введение в программирование: код и алгоритмы.
Урок 2. Web3 и его компоненты.
Урок 3. Блокчейн, сайдчейн и различные уровни сетей.
Урок 4. Что такое сеть Эфириум?
Урок 5. Архитектура Эфириум.

Дополнительно: Консенсус (общее);
Дополнительно: Состояния сети и Деревья;

+30 вопросов для самопроверки


Неделя 2

Урок 6. Введение в Solidity.
Дополнительно: Типы аккаунтов. Что такое транзакция?

Урок 7. Начало работ с Remix.
Дополнительно: Правила именований в контрактах;
Дополнительно: Процесс создания контрактов на уровне EVM;

Урок 8. Переменные в Solidity.
Дополнительно: Общий обзор всех типов данных.

Урок 9. Тип данных: bool.
Дополнительно: Какие операторы существуют?

Урок 10. Тип данных: string.
Дополнительно: История форков;

+30 вопросов для самопроверки


Неделя 3

Урок 11. Тип данных: uint/int.
Дополнительно. Условия в программировании;

Урок 12. Тип данных: bytes.
Дополнительно: Почему важен шардинг для EVM?

Урок 13. Тип данных: array.

Урок 14. Тип данных: enum.

Урок 15. Тип данных: mapping.

+30 вопросов для самопроверки


Неделя 4

Урок 16. Event и error в коде.
Дополнительно: Больше о событиях и логировании;

Урок 17. Функции.

Урок 18. Валидация ошибок в коде.

Урок 19. Циклы и итерации.

Урок 20. Модификаторы.
Дополнительно: Выполнение транзакции на уровне EVM;

+30 вопросов для самопроверки


Неделя 5

Урок 21. Структуры и вложенности

Урок 22. Глобальные переменные
Дополнительно: Память EVM.
Дополнительно: Работа с памятью EVM. Общее.

Урок 23. Наследования

Практикум 1

Урок 24. Интерфейсы
Дополнительно: Вызов между контрактами на уровне EVM;

+30 вопросов для самопроверки


Неделя 6

Урок 25. Библиотеки
Дополнительно. Знакомство с библиотеками Open Zeppelin;

Урок 26. Call, statickcallm
Дополнительно: Межсетевое взаимодействие: проблемы и решения;

Урок 27. Delegatecall

+15 вопросов для самопроверки

Практикум 2

Бонус: задачник для самостоятельной практики в Remix на 30 заданий!


Итого: 6 недель, 27 уроков, 17 дополнительных уроков по EVM, 165 вопросов для самопроверки, 30 практических заданий, 2 практикума!

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

Уверен, что этот модуль будет одним из самых "мясных" на рынке!

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

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

#курс #обучение

Про vibe coding и Solidity

Когда все вокруг говорят, что нейросети скоро заменят программистов, я решил проверить это на практике. Взял отчасти незнакомый стек — Python + React + MySQL — и поставил задачу: создать крипто мессенджер с end-to-end шифрованием. Не вникая в код, просто давая указания нейронке.

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

Это был фейл...

1. В самом начале я столкнулся с проблемой версий библиотек и Python, библиотек и React+Vite... Я использовал рекомендованный набор библиотек от нейронок и когда возникли ошибки, нейронки такие: "А ты не знал?! Как жаль... Вот так нужно все перенастроить...". Ок, пара часов возни и все установлено.

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

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

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

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

И это все в работе с популярными языками программирования. С Solidity дела обстоят куда серьезнее.

Нейронки плохо понимают контекст. Они не видят последствий. Они просто комбинируют куски кода из интернета.

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

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

P.S. Если вы разработчик и хотите попробовать реализовать задумку с крипто мессенджером, я могу дать технические описания, которые мы создавали с нейронками, и вы пройдете мои "страдания".

#курс