Solidity *

Привет, Хабр! Меня зовут Рома Ярлыков, я разрабатываю смарт-контракты на Solidity в MetaLamp. В этой статье я расскажу, как реализован Account Abstraction в zkSync и чем такой подход отличается от уже популярного стандарта ERC-4337. Чтобы понять, что за блокчейн zkSync, рекомендую сначала прочитать эту статью. А чтобы разобраться с Account Abstraction можно прочитать вот эту.

В Ethereum существует два типа аккаунтов: внешние аккаунты (Externally Owned Accounts, EOA), которые могут инициировать транзакции, но не обладают программируемой логикой, и смарт-контракты, имеющие возможность выполнения произвольной логики, но неспособные инициировать транзакции самостоятельно. Это вызывает большое количество проблем при взаимодействии с экосистемой блокчейна и повышает порог входа для новых пользователей.

Бороздя просторы Твиттера/X, увидел сервис smolrefuel.com, (тви), который решает проблему получения газового токена на Эфир-сетях, если у вас его нет, а есть выведенный, например, на кошелек с биржи, стейблкоин. Интересный кейс! – подумал я.

Начал разбираться, как это работает. Если высокоуровнево, то алгоритм такой:

Привет всем! Меня зовут Паша, я web3 разработчик в команде MetaLamp, мой основной стек – Solidity. Последнее время я часто сталкивался с задачами, требующими применения технологии Account Abstraction, поэтому я решил собрать базовые знания о ней в одну статью. Эта статья поможет разработчикам получить общую картину что такое АА, для чего он нужен и куда углубиться в исследованиях дальше, чтобы овладеть навыками работы с АА в полной мере.

Технология АА вышла в свет под стандартом ERC-4337. Были, есть и появляются другие стандарты, где ведется разработка в направлении абстракции учетной записи, но мы погорим только про ERC-4337. Это стандарт Ethereum, который обеспечивает абстракцию учетной записи в протоколе без какого-либо изменения на уровне консенсуса.

Стандарт был предложен соучредителем Ethereum Виталиком Бутериным и другими разработчиками в 2021 году. В марте 2023 года он был развернут в основной сети Ethereum.

Привет, Хабр! Меня зовут Рома и я Solidity-разработчик. Вместе с коллегами мы создаем базу знаний по тематике блокчейна и web3-разработке. Меня заинтересовал блокчейн zkSync, т.к. он выделяется среди других Layer 2 решений, но сначала хочу немного рассказать, в чем суть проблемы масштабирования и какие есть особенности L2 в связке с ZK-Rollups. Эта статья будет интересна тем, кто хочет верхнеуровнево разобраться как работают такого рода решения и почему ZK-Rollups очень перспективное направление развития для блокчейнов в целом и Ethereum в частности.

Привет, Хабр! Меня зовут Рома Ярлыков и я Solidity-разработчик в компании MetaLamp. В этой статье я подробнее расскажу про различные приемы, подходы и паттерны в распределение токенов среди участников проекта, а также покажу несколько популярных решений, используемых для вестинга токенов, одно из которых я применял на проекте заказчика. В этой статье можно найти ответы на популярные вопросы, которые возникают у разработчиков в проекте при реализации вестинга.

Привет, Хабр! На связи участник профессионального сообщества NTA Незнанов Дмитрий.

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

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

Сегодня поговорим про общие теоретические аспекты формальной верификации, проблемы SAT и SMT и закрепим все это на простом примере с использованием хайпового инструмента для анализа смарт-контрактов Certora Prover со своим языком спецификаций.

Всем привет! Я из команды по анализу уязвимостей распределенных систем Positive Technologies. Мы занимаемся исследованием безопасности в области блокчейн-технологий и хотим поделиться обзором фреймворка для статического анализа кода, написанного на Solidity, — Slither. Он разработан компанией Trail of Bits, релиз состоялся в 2018 году. Slither написан на Python 3.

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

Проходя данный цикл статей, мы овладели инструментарием и возможностями Foundry на уровне, достаточном для поддержания и создания проектов простого и среднего уровней. Предлагаю сегодня изучить очень важные и полезные возможности Foundry углублённого уровня, а именно - команды cast для ручной отправки RPC-запросов и fuzz-тестирование!

За прошедшие две части мы освоили почти всю базу, которая нужна нам для тестирования и отладки контрактов в Foundry. Пришло время закрепить успех! В этой части мы рассмотрим тестирование простых прокси-контрактов (Proxy Upgradable Contracts, UUPS) и на их примере создадим скрипт для деплоя и вызова функции, поработаем с переменными среды (env), частично автоматизируем работу с запуском скриптов (Makefile), разберёмся в форк-тестировании и запустим наш проект в тестнете!

По нашим предыдущим статьям может сложиться впечатление, что писать и деплоить смарт-контракты для асинхронных сетей на Threaded Virtual Machine (TVM), таких как Everscale и Venom, сложно и долго. Код смарт-контракта необходимо преобразовывать в файл с расширением .boc, в котором будет лежать код, приведенный к типу древа ячеек, с которым работает TVM. Кроме того, компилятор создает .abi файл, описывающий интерфейс контракта, его переменные, функции их параметры и возвращаемые ими типы. Этот файл используется для дальнейшей типизации для Typescript. Однако, благодаря инструментам, созданным в помощь разработчикам, процесс теста и деплоя смарт-контрактов по большей части автоматизирован.

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

В прошлой части мы познакомились с Foundry, создали новый проект и освоили самые базовые команды для тестирования. Сегодня нам предстоит окунуться чуть поглубже, освоить автоматическое форматирование кода (forge fmt), научится отслеживать качество тестирования наших контрактов (forge coverage), выводить подробные логи (vvvv), управлять временем (warp, roll) и деньгами(deal, hoax).

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

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

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

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

У этого поста также есть видеоверсия.

В 2020 году написание смарт-контрактов для единственной существовавшей на тот момент децентрализованной сети, использовавшей TON Virtual Machine, а именно, Telegram Open Network (TON), требовало изучение языка Fift, написанного для создания и тестирования смарт-контрактов, исполняемых на этой виртуальной машине.

Позднее команды разработчиков разделились: одна из них начала совершенствовать TON Virtual Machine, и в результате доработок появилась Threaded Virtual Machine (TVM). Далее были запущены новые сети Everscale и Venom (последняя сегодня находится на этапе тестнета), в которых для исполнения смарт-контрактов используется уже Threaded Virtual Machine.

Был написан специальный компилятор Solidity кода в машинные инструкции TVM. Естественно, это добавило удобства разработке смарт-контрактов для блокчейнов Everscale и Venom, однако из-за существенных различий между Ethereum VM и Threaded VM, API компилятора серьезно расширяет стандартный Solidity.

В этой статье мы опишем характерные особенности написания смарт-контрактов для блокчейна на Threaded Virtual Machine (TVM). Для файлов смарт-контрактов в сетях Everscale и Venom используется расширение .tsol, что означает Threaded Solidity, благодаря которому асинхронные смарт-контракты дифференцируются от обычного синхронного солидити. Тем не менее, расширение .sol тоже используется.

Прочитав эту статью до конца вы поймете какими навыками вам нужно обладать для того, что бы стать smart-contract разработчиком!

В конце статьи прикреплен Solidity developer roadmap.

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

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

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

Всем привет! В предыдущих статьях (1 и 2) я рассказывал про концепцию индексирования данных смарт-контрактов на блокчейне в общем и в частности через средства The Graph, а также про то, как использовать готовые "сабграфы" на The Graph Hosted Service, чтобы, не написав ни строки кода, делать к ним GraphQL запросы и получать данные популярных децентрализованных приложений. Однако, если вы присматриваетесь к Web3 разработке, то вероятно вам и самим придется разрабатывать такие сабграфы для своего приложения. Эту тему (разработка собственных сабграфов стандарта The Graph) я бы и хотел осветить в данном материале. Чтобы пример был не сферический и в вакууме, будем рассматривать существующий смарт-контракт проекта TornadoCash.