Solidity *

Привет, Хабр! Меня зовут Рома и я 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.

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

Мы в CyberOK в ходе пентестов очень любим “взламывать” разнообразные инновационные и необычные вещи. Смарт-контракты на блокчейне давно появились на наших радарах, так как они не только предлагают прозрачность, надежность и автоматизацию, но и легко могут стать объектом атак и уязвимостей. В рамках кибербитвы Standoff 10 мы решили объединить наш опыт по анализу защищенности и расследованию инцидентов в блокчейне и представить его в игровой форме — в виде открытой платформы для проведения соревнований Capture The Flag (CTF). Мы развернули собственную блокчейн-сеть с помощью ganache, чтобы дать участникам возможность взаимодействовать со смарт-контрактами в наиболее реалистичной атмосфере.

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

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

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