Solidity *

В апреле 2018 года, внутри нашей компании пришла идея выпустить свою игру на cмарт контракте блокчейна Ethereum. Подумав несколько дней и перебрав несколько вариантов, мы остановились на хорошо известной всем нам с детства игре «Камень, ножницы, бумага».

Update: 13.11.2018 вышел релиз, вот подробное описание изменений. В статье рассказывается про состояние этой версии в мае (за пять месяцев до релиза).

Хочу рассказать об изменениях языка Solidity, которые ожидаются в версии 0.5.0. Сразу отмечу, что я ограничусь только языком — его грамматикой и семантикой.

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

Disclaimer: в статье описано текущее состояние проекта, к релизу многое может поменяться. Точную информацию можно получить из официального changelog'a.

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

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

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

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

Итак, взглянем на фронт работ.

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

Алексей Ермишкин (Scratch )

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

Blockchain – это далеко не только смарт-контракты и криптовалюты, которые вообще стали сокращать до слова «крипто». Мне, как человеку, занимающемуся криптографией, это особенно бьет по ушам.

Blockchain — не обязательно распределенные системы. Если посмотреть определение слова «Blockchain», это распределенная база данных с консенсусами и со всем остальным. Нет, это абсолютно не так.

Blockchain-технология существовала за 4 года до Bitcoin. Вы наверняка тоже ею пользуетесь, но не догадываетесь, что это блокчейн. Это Git, и я очень легко это докажу.

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

В случае с DeCenter TokenConf мы получили многообразие заявок о способах сбора крипты на самые замечательные цели, из которых можно было бы собрать ещё пять конференций, и все их отклонили…

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

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

В прошлой статье мы рассмотрели разработанное приложение на Ethereum. Но обошли стороной вопрос как происходит процесс разработки. Ясно, что это не просто написание кода, который сразу работает. Большую часть времени придется потратить на то, чтобы доводить код, который “почти готов”, до рабочего состояния. Деплой, тестирование, отладка — все это в той или иной мере уже затрагивалось здесь например в этих неплохих статьях: раз, два, три (список не полный). В этой статье мы дадим небольшой обзор и возможно в чем-то повторимся, но постараемся сфокусироваться на тех моментах, которые нам показались важными или недосказанными. Плюс за последнее время некоторые штуки изменились, и огромное количество инструкций оказалось устаревшим. Постараемся немного подправить ситуацию.

Всем привет! Вдохновившись r/place и желая реализовать наконец-то свой первый смарт-контракт на блокчейне, мы решили сделать всем доступное и веселое приложение в сети Ethereum, которое позволяет рисовать на холсте размером в 1000 x 1000 px, сохраняя каждый выбранный и раскрашенный пользователем пиксель в блокчейн. Вы можете рисовать также в реальном времени со своими друзьями и наблюдать, как в реальном времени меняется цвет выбранного пикселя по мере того, как в сети подтверждаются транзакции смарт-контракта.

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

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

В Ethereum для выполнения каждой транзакции требуется определённое количество газа — специальной сущности. Существуют разные пути для снижения затрат. Часть из них уже реализована. Хочу начать с обсуждения вопроса оптимизации стоимости создания смарт-контракта.

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

Представляем вторую часть цикла, посвященного типичным уязвимостям, атакам и проблемным местам, присущим смарт-контрактам на языке Solidity, и платформе Ethereum в целом. Здесь поговорим о некоторых особенностях EVM и о том, какими уязвимостями они могут обернуться.

Блокчейн Ethereum интересен своими смарт-контрактами, а также возможностью создания децентрализованных приложений DApp (Decentralized Application). Однако такому приложению необходимо децентрализованное хранилище данных.

Хранение данных большого объема в блокчейне может стоить немалых денег. На помощь приходят такие децентрализованные хранилища, как Ethereum Swarm («swarm» переводится как «рой», «куча»). Если кратко, то Ethereum Swarm представляет собой программный код, работающий на пиринговой сети Ethereum. Он обеспечивает децентрализованное хранение данных на дисках узлов, владельцы которых отдают свои ресурсы в общее пользование.

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

С этой статьи мы начинаем цикл, посвященный типичным уязвимостям, атакам и проблемным местам, присущим смарт-контрактам на языке Solidity, и платформе Ethereum в целом. В первой части мы поговорим вот о чем:

• почему сложно реализовать децентрализованную биржу на смарт-контрактах
• как сгенерировать случайное число
• как вывести из строя всю Proof-of-Authority сеть

Обычно когда мне нужно использовать какой-то новый сервис или технологию из скриптов Perl, я захожу на CPAN, и там уже есть один или несколько подходящих модулей. Однако в случае фреймворков для работы с узлами блокчейна Ethereum и контрактами Solidity, к сожалению, мне не удалось найти нужного модуля.

Мы планируем в ближайшее время использовать смарт-контракты Solidity сети Ethereum в нашем SAAS-сервисе интернет-магазинов, написанном на Perl. Поэтому мне ничего не оставалось, как написать свой модуль Net::Ethereum (этот модуль уже доступен на CPAN, хотя и в виде альфа-версии).

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

При разработке смарт-контрактов на Ethereum обычно считается что полагаться на хеш блока как источник рандомности ненадежно, так как майнер может влиять на результат, подбирая хеш блока (см. Private Information and Randomness, How do you get a random number in a contract?)

Насколько в действительности велика возможность для майнера увеличить свои шансы на выигрыш в игре в которой нужно угадать хеш блока c определенным номером (или некое число производимое от хеша блока)?

Мотивация

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

Популярные причины необходимости обновления

• Ошибки в коде
• Изменение бизнес требований
• Принятие предложений сообщества об изменении работы контракта

Описание технического решения

Реализация требуемого функционала — обновление кода, планируется через разделение кода на составляющие:

1. Данные — смарт-контракты без логики и предоставляющие исключительно пространство для хранения данных;
2. Бизнес-логика — смарт-контракты описывающие логику извлечения данных из хранилища и их изменения;
3. Входные точки — иммутабельные контракты ведут учет обновления бизнес-логики и предоставляют конечному пользователю ссылку на актуальный контракт бизнес-логики

Эта статья представляет собой небольшое практическое руководство, которое поможет вам быстро настроить среду разработки смарт-контрактов на языке Solidity для блокчейна Ethereum. Вы опубликуете первый контракт, сохраните его в тестовом блокчейне Rinkeby и научитесь вызывать методы контракта. Это будет ваш первый шаг на пути создания децентрализованных приложений DApp (Decentralized Application).

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

При погружении в эту тему я использовал приложение (браузер) Mist в среде Microsoft Windows, а также интерфейс командной строки Geth узла Ethereum в среде Ubuntu. В этой статье мы расскажем о работе с Geth, а также немного о том, как вызывать методы контрактов из Node.js.

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

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

Это происходит с подачи таких крупных компаний, как IBM и Comcast, а также небольших стартапов вроде MadHive и Rebel AI.