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

Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление DoS атак на сеть и многое другое. Давайте рассмотрим основные из них. Let’s dive in.

Итак, ваша команда закончила alpha-версию вашего блокчейна, и пришло время запускать testnet, а затем и mainnet. У вас настоящий блокчейн, с независимыми участниками, хорошей экономической моделью, безопасностью, вы спроектировали governance и теперь пора бы попробовать все это в деле. В идеальном криптоанархическом мире, вы выкладываете в сеть genesis block, окончательный код ноды и валидаторы сами все запускают, поднимают все вспомогательные сервисы и все случается само собой. Но это в выдуманном мире, а в реальном, команда должна подготовить довольно много вспомогательного софта и различных манипуляций чтобы помочь валидаторам запустить устойчивую сеть. Об этом данная статья.

Любимым вопросом о любой распределенной системе от нетехнического специалиста является “Сколько tps в вашем блокчейне?”. Однако, названное в ответ число обычно имеет мало общего с тем, что хотел бы услышать вопрошающий. На деле, он хотел спросить “подойдет ли ваш блокчейн под мои бизнес требования”, и эти требования — это не одно число, а множество условий — здесь и отказоустойчивость сети, и требования к финальности, размеры, характер транзакций и множество других параметров. Так что ответ на вопрос “сколько tps” вряд ли будет простым, и почти никогда не будет полным. Распределенная система с десятками и сотнями узлов, выполняющих довольно сложные вычисления, может находиться в огромном количестве различных состояний, связанных с состоянием сети, содержимым блокчейна, техническими сбоями, экономическими проблемами, атаками на сеть и множеством других причин. Этапы, на которых возможны проблемы с производительностью отличаются от традиционных сервисов, а сервер блокчейн-сети — это сетевой сервис, сочетающий в себе функционал базы данных, web-сервера и torrent-клиента, что делает его крайне сложным в плане профиля нагрузки на все подсистемы: процессор, память, сеть, storage

Так получилось, что децентрализованные сети и блокчейны являются довольно специфическим и непривычным софтом для разработчиков централизованного ПО. Поэтому я хотел бы осветить важные аспекты производительности и устойчивости децентрализованных сетей, подходы к их измерению и нахождению bottlenecks. Мы рассмотрим различные проблемы производительности, ограничивающие скорость предоставления сервиса пользователям блокчейнов и отметим особенности, характерные для этого вида софта.

Введение

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Как и в случае с концепцией абсолютно стойкого шифра из криптографии, реальные протоколы “Publicly Verifiable Random Beacon” (далее PVRB) лишь пытаются максимально приблизиться к идеальной схеме, т.к. в реальных сетях в чистом виде она неприменима: договариваться надо строго об одном бите, раундов должно быть много, а все сообщения должны быть идеально быстрыми и всегда доставляться. Разумеется, в реальных сетях это не так. Поэтому, при проектировании PVRB под конкретные задачи в современных блокчейнах, помимо невозможности контроля получаемого рандома и криптографической стойкости, возникает еще много чисто архитектурных и технических проблем.

Введение

«Генерация случайных чисел слишком важна, чтобы оставлять её на волю случая»
Роберт Кавью, 1970

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

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

Warning

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

Цель статьи — дать читателю понимание того, как работают методы анализа кода в разных анализаторах и умение их правильно использовать, а не "определиться с выбором". Разумный выбор — использовать сразу несколько инструментов, делая акцент на наиболее подходящем для анализируемого контракта.

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

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

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

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

Введение

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

Multisig-контракты в современных децентрализованных сетях — это мощный инструмент, который позволяет просто и надёжно защищать средства на коллективных счетах, а также проводить сделки с несколькими участниками. Если вам интересно, как использовать такие адреса, то вы попросту обязаны понимать механику владения ими и прекрасно представлять себе порядок транзакций. Для работы с такими адресами требуется участие нескольких аккаунтов.

Несмотря на одинаковое название и схожую логику работы, внутренние алгоритмы и способы взаимодействия с адресами, защищёнными мультиподписью, довольно сильно различаются в Bitcoin и Ethereum. Именно об этом внутреннем устройстве и пойдёт речь в данной статье.

Мы будем говорить о двух сетях: Bitcoin и Ethereum. В других блокчейнах multisig-доступ к криптоактивам может быть реализован совершенно иначе.

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

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

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

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

Как и обещал в прошлой части, продолжим рассмотрение вирусных движков. На этот раз речь пойдет о полиморфизме исполняемого кода. Полиморфизм для компьютерных вирусов означает, что каждый новый зараженный файл содержит в себе новый код вируса-потомка. Чисто теоретически, для антивируса это должно было бы означать настоящий кошмар. Если бы существовал вирус, который в каждом новом поколении на 100% менял бы свой код, причем по настоящему случайным образом, никакой сигнатурный анализ не смог бы его детектировать.

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

Поговорим о компьютерных вирусах? Нет, не о том, что вчера поймал ваш антивирус. Не о том, что вы скачали под видом инсталлятора очередного Photoshop. Не о rootkit-e, который стоит на вашем сервере, маскируясь под системный процесс. Не о поисковых барах, downloader-ах и другой малвари. Не о коде, который делает плохие вещи от вашего имени и хочет ваши деньги. Нет, всё это коммерция, никакой романтики…

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

Миллион статей написано об организации рабочего процесса, редакторах кода, удобстве и стабильности работы. Я, не претендуя на «самый расчудесный способ», хочу рассказать, как организована среда web-разработки у нескольких человек из нашей команды. Сразу оговорюсь, если вы используете только локальные GUI-шные редакторы кода, Notepad++, Eclipse и т.п., то эта статья не для вас. Мы очень много работаем в консоли, и поэтому, в результате многолетнего естественного отбора, многие пришли к VIM, а консоль является практически отдельным табом в среде разработки, т.к. в процессе работы надо смотреть логи, писать запросы к базе, перезапускать сервисы и т.п. Поэтому, я хочу поделиться конкретным практическим рецептом организации среды web-разработки для программиста или админа, который много времени работает в стандартной удаленной консоли.