Solidity *

Анализатор: Slither
Описание: Open-source static analysis framework for Solidity
githib: https://github.com/trailofbits/slither

Это статический анализатор кода, написанный на python. Он умеет следить за переменными, вызовами, и детектирует вот такой список уязвимостей. У каждой уязвимости есть ссылка с описанием, и, если вы новичок в Solidity, вам имеет смысл ознакомиться со всеми.

Slither может работать, как модуль python и предоставлять программисту интерфейс, для аудита по собственному плану. Простой и показательный пример того, что умеет делать slither можно увидеть тут.

Мы еще вернемся к сценариям анализа в конце статьи, а пока запустим Slither:

*многие называют это событие «hard fork»-ом, но «Виталик» против.

Долгожданный релиз Constantinople должен был состояться 17 января, в 4AM UTC, однако, в очередной раз жестоко обломав несметную армию разработчиков countdown счетчиков этому не суждено будет сбыться.

Используя протокол доказательства с нулевым разглашением из семейства SNARK, вы никогда не знаете правил игры. Эти правила устанавливают участники процедуры генерации доверенных параметров системы, однако после её завершения проверить эти правила не представляется возможным. Вы можете поверить в корректность генерации, но, если вы в ней не участвовали, стопроцентных гарантий у вас нет.

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

Продолжение статьи «Сканирование 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 таких компаний прогорают.

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