Перед разработкой собственного блокчейна ваша команда должна четко понимать, для чего необходим блокчейн и какой бюджет вы сможете выделить на его содержание.
Проектирование и запуск блокчейна имеют свои нюансы. Их можно легко упустить при планировании, если вы неверно оценили объем и сложность задачи.
Чтобы помочь проектам избежать таких ошибок, руководитель отдела исследований MixBytes Сергей Прилуцкий подготовил пошаговое руководство по запуску блокчейна.
Данная статья поможет вам определиться с выбором алгоритма консенсуса для построения собственного блокчейна, исходя из его технических свойств и ограничений.
***
Я буду исходить из того, что блокчейн предназначен для достаточно сложных сделок. Все рассматриваемые решения подходят для работы с кодом, размещенным в блокчейне.
Я намеренно не включил в перечень решения, которые находятся на ранних этапах развития, неизвестны широкому кругу программистов или не имеют важных механизмов, обеспечивающих безопасную работу блокчейна: неустойчивы к византийскому поведению нод (non-BFT) или могут быть успешно атакованы с единственного аккаунта. Без этих свойств блокчейн не имеет ценности и превращается в медленную, дорогую и неудобную в использовании базу данных.
Чтобы определиться, строить ли новую систему или использовать готовое решение, в первую очередь необходимо определиться с консенсусом — главным алгоритмом, обеспечивающим блокчейну BFT-свойства.
Консесусы: proof-of-work, proof-of-stake, proof-of-authority
Для начала рассмотрим разные типы консенсуса с точки зрения запуска и эксплуатации сети. Любой BFT-консенсус в блокчейнах должен удовлетворять как минимум два важных свойства распределенных систем: safety и liveness.
Safety гарантирует, что алгоритм никогда не придет к неверному консенсусу, если большинство узлов честно следуют протоколу, а liveness — что алгоритм никогда не «застрянет», не имея возможности выбора пути.
Эти свойства должны гарантированно выполняться при наличии в сети byzantine-участников, намеренно действующих наихудшим образом.
Proof-of-work (PoW)
Преимущество этого типа консенсуса — отсутствие необходимости регистрировать в сети валидаторов. Принимается любой блок, удовлетворяющий требования, без подтверждения других участников. Это позволяет оставить лишь часть логики, отвечающую за изменение сложности майнинга.
В теории этот вид консенсуса допускает любое число валидаторов — ведь соревноваться за блок может сколько угодно валидаторов. В реальных сетях, если валидаторов (майнеров) много, а сложность сети высока, то шансов получить награду за блок у отдельного майнера крайне мало. Для такого консенсуса необходимо сразу планировать работу майнинговых пулов, объединяющих майнинговые мощности, и соответствующее ПО.
При старте сети валидаторы должны сразу же установить серьезные вычислительные мощности. Это часто упускают из вида, надеясь на постепенное увеличение сложности сети и количества майнеров. Невысокий хешрейт открывает двери для недорогих атак 51%, когда атакующий на очень короткое время арендует много серверов, чтобы получить 51% хешрейта сети, и проводит атаку двойной траты.
Поэтому для PoW-сети придется планировать более сложную процедуру запуска. Сначала команда запускает сеть с собственными валидаторами, а потом постепенно «уступает» производство блоков майнерам, которые в этом случае могут плавно наращивать мощности.
Proof-of-authority (PoA)
PoA-консенсусы — это алгоритмы, использующие заранее назначенный набор аккаунтов, которые могут производить блоки и голосовать за принятие и исключение новых членов. Этот вид консенсуса — естественный выбор для корпоративных блокчейнов и тестовых сетей. Здесь может вообще не быть внутреннего токена, а при голосованиях за блоки и при выборах валидаторов 1 валидатор = 1 голос.
Это семейство алгоритмов представлено фундаментальным алгоритмом pBFT. В измененном виде он является базой для большого числа консенсусов, позволяя договориться о любых данных со всеми гарантиями безопасности.
Ранее я уже говорил о том, что не существует гарантированно безопасных консенсусов, в которых требуется менее, чем 2/3 + 1 сообщений от валидаторов. pBFT это доказывает математически. В разных консенсусах эти сообщения, подтверждающие, что валидатор принимает блок, собираются в разные моменты времени.
Процесс сбора подтверждений и в дальнейшем признание блока окончательным получил отдельное название финализации. Блоки, на которых достигнут общий консенсус называются финальными. Для уменьшения числа сообщений в части алгоритмов финальность достигается не на всех блоках, а только на некоторых, «заверяющих» сразу несколько блоков. Таким образом сильно уменьшается число сообщений между валидаторами и существенно ускоряется консенсус.
Из-за разделения процедур валидации блоков и финализации присутствует некоторая путаница, из-за которой оценивать скорость консенсуса становится непросто.
Например, алгоритм pBFT, используемый в консенсусе Tendermint (Cosmos), требует консенсуса на каждый блок, т.е. мгновенно финализирует его, а алгоритм EOS финализирует лишь один из множества блоков, финализируя сразу цепочку.
Aura — популярный алгоритм для POA-сетей на базе Ethereum — использует псевдослучайный выбор валидатора для каждого блока и параллельно договаривается о финализированных блоках с использованием алгоритма GRANDPA, ожидая > 2/3 подписей-подтверждений от других валидаторов. Такой параллельно работающий алгоритм финализации получил название finality gadget.
Похожим образом работает консенсус EOS, создающий «расписание» для валидаторов на некоторый период времени (epoch) и требуя финализации блоков в конце каждой epoch.
Proof-of-stake (PoS)
Почти все существующие реализации этих алгоритмов включают в себя алгоритмы из POA-консенсусов, что добавляет путаницы. Современные PoS-алгоритмы работают следующим образом: при помощи балансов участвующих в выборах валидаторов (стейков) формируется список валидаторов (например, голосованиями, заморозкой депозитов и т.д.). В течение некоторого времени, до момента изменения списка валидаторов, сеть работает, используя PoA-алгоритм, например pBFT.
Наиболее распространенными стали алгоритмы, названные Delegated Proof-of-Stake (DPoS), где аккаунты в сети различными способами голосуют своими балансами за валидаторов, формируя топ из N валидаторов.
Выбирая консенсус для своего блокчейна, стоит в первую очередь рассмотреть процесс финализации блоков. От нее будет зависеть время, через которое клиент получит подтверждение своих транзакций. Токеномику, процедуру «выборов» валидаторов и получение наград за блоки лучше рассматривать отдельно. В этой части может быть применено большое число разных экономических механизмов.
Отмечу, что корпоративным сетям не стоит пренебрегать экономическими механизмами и PoS-алгоритмами, даже если в сети нет никакой экономики и токена. Любые бесплатные транзакции — это почти всегда вектор атаки на систему с единственного аккаунта. Наличие баланса «технического» токена на аккаунте может служить удобным ограничителем, когда у атакующего просто не хватит средств на полномасштабную атаку, а также позволит более гибко регулировать доступ и нагрузку на сеть.
Варианты имплементации
Планируя свой блокчейн, надо понять, можно ли использовать готовое решение или стоит создать все с нуля, полностью контролируя код.
Блокчейн — это мир открытого ПО. Закрытый код в нем практически невозможен — криптографические протоколы давно создаются на открытых международных конкурсах, а реализациям с закрытым кодом мало кто доверяет из-за больших рисков.
Используйте то, что создали программисты до вас. Крайне велика вероятность, что ваши задачи уже решали, обсуждали и проверяли, поэтому не стоит тратить на них лишние усилия.
Если же вы решили делать свой консенсус, связанный с сетевым взаимодействием, или вы используете новые криптографические концепции, которые архитектурно не укладываются в традиционный дизайн блокчейнов; если вы собираетесь обойти все существующие решения по производительности, экономя каждый бит; если транзакции в вашем блокчейне настолько специфические, что ничего подобного в мире не существует… Тогда ваш путь — блокчейн с нуля.
