Эта статья про один из новых, серьезных вызовов для DeFi проектов - MEV. Его аналоги в предыдущей финансовой реальности, волнуют лишь малое число узких специалистов, имещих закрытый, приоритетный доступ к серверам бирж. В DeFi доступ к "финансовым API" есть у любого пользователя. На обычных биржах это высокоскростные линии связи, привилегированный доступ за большие деньги, специализированный софт. В DeFi доступ алгоритмически одинаков для любого, у кого есть хотя бы 1 wei, спецификация API полностью открыта и всем можно свободно пользоваться. Так что теперь, в блокчейн-мире, те же вопросы ордеринга касаются всех пользователей, а огромное число возможных видов финансовых инструментов в виде смарт-контрактов дают множество возможностей эксплоитинга на разных уровнях.

Предлагаю познакомиться с MEV поближе.

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

Сегодня решения для тестирования и бенчмаркинга блокчейнов заточены под определенный блокчейн или его форки. Но есть и несколько более общих решений, которые отличаются функционалом: некоторые из них — опенсорсные проекты, другие предоставляются как 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 аудитории Хабра будет интересен. Прошу под кат всех заинтересованных.