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

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

Доступ к объемным файлам и различные внешние динамические данные часто являются очень важной частью децентрализованного приложения. При этом в самом по себе Ethereum механизма обращения наружу не предусмотрено — смарт контракты могут читать и писать только в рамках самого блокчейна. В этой статье рассмотрим Oraclize, который как раз дает возможность взаимодействия с внешним миром путем запросов к практически любым интернет-ресурсам. Смежной темой является IPFS, вкратце упомянем и о ней.

Наверняка многие из вас задумывались, зачем вообще понадобился блокчейн и Ethereum в частности. Кто-то возможно пошел дальше и нашел множество красивых характеристик: децентрализация, прозрачность, доверие без посредников, взломостойкость. Это же просто отлично, правда? Да, но…

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

Smart Contract & Gas

Если на пальцах, "умный контракт" — это некоторый код, живущий внутри блокчейна. Любой участник сети может его вызвать за небольшую плату. Эта плата и называется Gas, дословно "топливо". Зачем это нужно? Для защиты майнера от злоупотребления мошенником его ресурсов.

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

// Это псевдокод
foo = 0;
while (True) {
    foo++;
}

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

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

В предыдущей статье мы описали деплой контрактов и взаимодействие с ними через пользовательский интерфейс кошелька Mist, но это не подходит для реальной разработки. Нужна библиотека, которая позволит работать с блокчейном из кода пользовательского приложения. В этой статье мы кратко рассмотрим что представляет собой библиотека Web3.js, пощупав ее из консоли Geth. И еще одна важная тема, которая наверняка интересует не только разработчиков, но и потенциальных заказчиков — сколько стоят транзакции на блокчейне, ведь каждая из них требует газа, который покупается за эфир.

В августе я, неожиданно для себя, поучаствовал в bugbounty проекта Kickico. Я уже рассказал об этом на митапе Atlas Blockchain в прошлую пятницу. Статья — текстовая версия этого доклада с дополнением и небольшим пятничным конкурсом :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список:

1. Смарт-контракты: введение.
2. ICO и токен ERC20.
3. Создаем конструктор смарт-контрактов на платформе Smartz.
4. Техническая лекция по Solidity.
5. Смарт-контракты: тонкости разработки.
6. Компилятор solc, структура файла смарт-контракта, типы и структуры данных в Solidity.
7. Solidity: ссылочные типы.
8. Разрабатываем прототип децентрализованной Multi-blockchain биржи.

Всем привет! В этой статье я расскажу вам, как за 5 минут и несколько команд в терминале запустить смарт-контракт сбора денег для своего ICO на Ethereum. Этот очерк потенциально сэкономит вам десятки тысяч американских долларов, так как любой программист — да и не программист тоже — сможет запустить проаудированный и безопасный смарт-контракт (вместо того, чтобы платить $15,000 – $75,000 за разработку). Вкратце, на этот смарт-контракт можно будет отправить денег и получить за это ERC20 токены. Можно сказать, эта статья — сборник всего опыта, который я получил, запуская ICO для своего проекта.

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

«Программисты тратят огромное количество времени беспокоясь о скорости работы своих программ, и попытки достичь эффективности зачастую оказывают резко негативное влияние на возможность их отладки и поддержки. Необходимо забыть о маленьких оптимизациях, скажем, в 97% случаев. Преждевременная оптимизация это корень всех зол! Но мы не должны упускать из виду те 3%, где это действительно важно!».
Дональд Кнут.

Проводя аудиты смарт-контрактов, мы иногда задаём себе вопрос относится ли их разработка к тем 97%, где нет необходимости думать об оптимизации или мы имеем дело как раз с теми 3% случаев, где она важна. На наш взгляд, скорее второе. В отличие от других приложений, смарт-контракты не обновляемы, их невозможно оптимизировать «на ходу» (при условии, если в их алгоритм это не заложено, но это отдельная тема). Второй довод в пользу ранней оптимизации контрактов — то, что, в отличие от большинства систем, где неоптимальность проявляется только в масштабе, связана со спецификой железа и окружения, измеряется колоссальным количеством метрик, смарт-контракт обладает по сути единственной метрикой производительности — потребление газа.

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

В последнее время, мне пришлось немного поработать с блокчейном Ethereum. Идея, над которой я работал, требовала хранить прямо в блокчейне некоторое достаточно большое количество целых чисел, так, чтобы смарт-контракт имел к ним удобный доступ. Большинство уроков по разработке смарт-контрактов говорят нам «не храните много данных в блокчейне, это дорого!». Но сколько это «много», и с какого количества цена становится слишком высокой для практического использования? Это мне надо было выяснить, потому что нам наши данные выносить офф-чейн было никак нельзя, рушилась вся затея.

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

Для начала, я решил быстро прикинуть — получится ли у нас? Давайте возьмём стандартный, широко распространённый тип контракта — токен ERC20. По крайней мере, такой контракт хранит в блокчейне соответствие адресов людей, который купили токены, их балансам. В реальности, хранятся только балансы, каждый из которых занимает 32 байта (на деле здесь экономить не имеет смысла из-за особенностей Solidity и EVM). У более-менее успешного токена легко могут быть десятки тысяч обладателей, и таким образом получаем, что хранить в блокчейне около 320000 байт — вполне допустимо. А нам больше и не надо!

Наивный подход

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

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

Данным постом начинаю цикл статей на тему безопасности смарт-контрактов Ethereum. Считаю эту тему весьма актуальной, так-как количество разработчиков лавинообразно растет, а уберечь от «граблей» — некому. Пока — переводы…

1. Сканирование Live Ethereum контрактов на ошибку «Unchecked-Send»

Оригинал — Scanning Live Ethereum Contracts for the «Unchecked-Send...»

Авторы: Zikai Alex Wen и Andrew Miller

Программирование смарт-контрактов в Ethereum, как известно, подвержено ошибкам [1] . Недавно мы увидели, что несколько
высококлассных смарт-контрактов, таких как King of the Ether и The DAO-1.0, содержали уязвимости, вызванные ошибками программирования.

Начиная с марта 2015 года программисты смарт-контрактов были предупреждены о конкретных опасностях программирования, которые могут возникнуть, когда контракты отправляют сообщения друг другу [6]. 

В нескольких руководствах по программированию содержится рекомендация, как избежать распространенных ошибок (в официальных документах Ethereum [3] и в независимом руководстве от UMD [2] ). Хотя эти опасности достаточно понятны, чтобы избегать их, последствия такой ошибки являются ужасными: деньги могут быть заблокированы, потеряны или украдены.

Насколько распространены ошибки, возникающие в результате этих опасностей? Есть ли еще уязвимые, но живые контракты на block-chain Ethereum? В этой статье мы отвечаем на этот вопрос, анализируя контракты на живом block-chain Ethereum с помощью нового инструмента анализа, который мы разработали.

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