Solidity *

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

Продолжение статьи «Сканирование Live Ethereum контрактов на ошибку «Unchecked-Send». Часть 1».

Почти год назад (в то время как Ethereum был в своем «пограничном» выпуске), популярный лотерейный контракт EtherPot [9] также пострадал от той же ошибки. Более ранняя версия BTCRelay также показала эту ошибку [7]. Несмотря на то, что в предыдущем аудите безопасности была обнаружена опасность, сначала было применено неправильное исправление [8].

Данным постом начинаю цикл статей на тему безопасности смарт-контрактов 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 с помощью нового инструмента анализа, который мы разработали.

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

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

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

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

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

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

Сеть Ethereum, широко известная в узком кругу блокчейн-разработчиков, уже зарекомендовала себя как удобная и стабильная платформа для разработки смарт-контрактов. Мы стараемся сделать смарт-контракты доступными для неподготовленных пользователей, предлагая простые, но практически полезные контракты. Недавно мы разработали смарт-контракт спора Bet Me. В основе контракта лежит пари (спор) двух оппонентов. Они подкрепляют уверенность в собственной правоте денежной ставкой. Проигравший теряет деньги, а победитель забирает всё. Подробнее о нём я расскажу в этой статье.

Для тех, кто интересуется темой смарт-контрактов, ответ на вопрос, заданный в заголовке, лежит на поверхности: на сегодняшний день контракты не имеют достоверного и полного источника информации о происходящем в реальном мире. Вследствие этого складывается прескверная ситуация: мы можем описать в смарт-контракте сложную логику, а блокчейн обеспечит нам её безоговорочное исполнение. И вот, казалось бы, мы в шаге от того, чтобы избавиться от необходимости в третьей стороне при заключении договоров — именно это имелось в виду под словами «изменить мир» в заголовке. Однако любой логике, описывающей процессы реального мира, нужно знать, что в этом мире происходит. Таким образом, от «революции доверия» нас отделяет последняя преграда в виде отсутствия поставщиков информации или оракулов, как их называют в мире смарт-контрактов. Решение этой задачи дало бы колоссальный импульс распространённости и применимости смарт-контрактов. В противном случае эта технология рискует навсегда остаться лишь площадкой для реализации ICO.



Способности, не находящие применения, превращаются в ничто.
Стен Надольный

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

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

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

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

11 и 12 мая 2018 года команда 8base в лице Евгения Семушина, Гейба Келли и меня решила испытать свои силы и побороться за приз AlphaPoint на хакатоне Consensus 2018, который проходил в Нью-Йорке. Всего в хакатоне участвовало 33 команды, а среди его спонсоров были такие гиганты, как CoinDesk, Microsoft, IBM, Hyperledger и Quorum.



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

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

Под катом нюансы реализации этого проекта.

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

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

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

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

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

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

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

Список:

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

Эта статья — отчет о моем участии во втором этапе хакатоне, организованного компанией karma.red. Подробнее о хакатоне можно почитать на специальной страничке.

Для тех, кто любит читать код, а не статьи — репозиторий проекта.

Любители видео тоже не обижены :) В этом видео можно послушать краткое содержание статьи, посмотреть, как реализуется биржа шаг за шагом и увидеть вживую ее работу.

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

Но как и в истории с систематической ошибкой выжившего, нужно обращать внимание не только на истории успеха, которые постоянно приводят в пример, но и на истории, где люди потеряли кучу времени и денег, пытаясь развивать свой проект, написали тонны кода, а в итоге не получили ничего. Причем довольно часто потерянные деньги принадлежат инвесторам. Конечно, всем хотелось бы заработать на ранних инвестициях в компании типа facebook, но к сожалению 9 из 10 таких компаний прогорают.

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

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

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

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

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

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

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