Solidity *

В прошлой статье мы рассмотрели разработанное приложение на 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.

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

В конце концов, есть официальная документация и stackoverflow.

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

Перед ежегодной конференцией ZeroNights 2017, помимо Hackquest 2017, мы решили организовать еще один конкурс, а именно — провести свое ICO (Initial coin offering). Но только не такое, как все привыкли видеть, а для хакеров. А как мы могли понять, что они хакеры? Они должны были взломать ICO! За подробностями прошу под кат.

В статье мы рассмотрим технические аспекты подготовки и проведения ICO. Это продолжение статьи моего коллеги «Технические особенности проведения ICO. Начало», и здесь мы поговорим подробнее о некоторых технических вопросах, связанных со смарт-контрактами сети Ethereum.

Почти перед каждым программистом, который пишет смарт-контракты Ethereum встают вопросы: «Что делать, если нужно будет расширить функционал контрактов? Как быть, если в контракте найдется баг, который повлечет за собой потерю средств? Что делать, если обнаружится уязвимость в компиляторе solidity (что бывало уже не раз)?» Ведь, контракты, которые мы загружаем в сеть, не могут быть изменены. Поначалу довольно сложно осознать: как это код нельзя обновить? Почему? Но в этом отчасти и сила смарт-контрактов Ethereum — пользователи, возможно, меньше бы стали доверять контрактам, которые можно менять.

Постараемся разобрать несколько подходов, которые все же позволяют менять смарт-контракты.

Привет, Хабр! Сегодня мой рассказ пойдёт о техническом опыте проведения ICO на платформе Ethereum перед и во время ICO. Я поучаствовал пока в небольшом количестве проектов, но уже успел собрать некоторый технический бэкграунд. Могу поспорить, технический roadmap по проведению ICO аудитории Хабра будет интересен. Прошу под кат всех заинтересованных.

Начну с того, что всем известно. ICO повсюду, все предлагают разные проекты, все продают токены. И у всех есть какая-то модель продаж со скидками, бонусами, сроками и т.п.
Как ни странно хоть область и достаточно экспериментальная, модель бонусов достаточно примитивна. Просто есть разные объемы или временные интервалы и проценты в них. Да и зачем усложнять? А я все таки попробую. Эксперимента ради. Новое всегда привлекает.

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

Solidity — язык, созданный для разработки умных контрактов, существует относительно недавно — его разработка началась только в 2014 году и, как следствие, местами он ''сыроват''. В этой статье я начну с более общего описания работы EVM и некоторых отличительных особенностей solidity, которые нужны для понимая более низко-уровневой работы.

P.s Статья предпологает наличие некоторых базовых знаний о написании смарт-контрактов, а также о блокчейне Ethereum'a в целом, так что если вы слышите об этом в первый раз, то рекомендую сначала ознакомиться с основами, например, здесь:

• Hello world на solidity и деплой контракта в сеть
• Подборка инструментов для разработки
• Описание работы Ethereum и его блокчейна

В предыдущих статьях (часть 1 и часть 2) мы описали как можно пользоваться децентрализованными приложениями на смарт-контрактах, если вы сами не против быть нодом. Но чем меньше пользователя заставляют совершать дополнительные действия — тем лучше. Для работы со смарт контрактами необходимо подписывать транзакции приватным ключом, поэтому совсем без дополнительный действий, к сожалению, не обойтись. В этой статье мы рассмотрим два подхода: первый — полноценное децентрализованное приложение (DApp) на javascript с использованием библиотеки Web3 и плагина MetaMask, второй — аналогичное приложение, но использующее Ruby on Rails API и гем Ethereum.rb для доступа к блокчейну.

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