REChain. Шардинг

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

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

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

Авторы блоков соревнуются за право создать следующий блок, но победителей может быть больше одного. В качестве доказательства работы майнеры получают право быть автором поверх заданного блока (примерно) , находя способ создания нового блока, который хэшируется до уникального случайного числа, которое не достигает какой-то сложной цели. Может потребоваться огромное количество попыток, прежде чем майнер найдет блок, удовлетворяющий этому условию в достаточно конкурентной среде. Для справки, кумулятивный хешрейт сети Биткойн составляет 162 экзахэша в секунду, а это означает, что майнеры Биткойн в совокупности пытаются 162 квинтиллиона раз в секунду заработать право внести свой следующий блок, а цель сложности установлена именно таким образом. В среднем только один хэш будет ниже целевого значения каждые 10 минут. Обратите внимание, что несколько майнеров могут примерно одновременно найти решение, которое создаст небольшую вилку в блокчейне. Будущим майнерам придется выбирать, какой из этих блоков будет добывать сверху, что может привести к удлинению вилок. Правило состоит в том, чтобы следовать самой длинной цепочке, и злоумышленнику, начиная с прошлого блока, становится все труднее догнать и подавить более длинную цепочку. Таким образом, блок, который находится достаточно глубоко в самой длинной цепочке, может считаться вероятностно окончательным.

Семейство протоколов проверки доли использует криптографическую технологию, известную как проверяемые случайные функции (VRF) , для имитации доказательства работы путем разделения времени на дискретные слоты и предоставления каждому валидатору из зарегистрированного и стейкингового набора валидаторов возможность создать одно поддающееся проверке случайное значение на каждый временной интервал, которое, если оно ниже порогового значения, служит в качестве учетных данных, позволяющих валидатору создать новый блок. Как и в случае с доказательством работы, несколько валидаторов могут создавать значения с помощью своих VRF, которые ниже порогового значения, и одновременно создавать блоки, что приводит к разветвлениям. Валидаторы лишены стимулов к введению преднамеренных форков, то есть использованию своих учетных данных для создания нескольких блоков в одном и том же слоте, путем сокращения своей доли в цепочке. Эти протоколы также обеспечивают вероятностную завершенность в соответствии с правилом выбора ответвления с самой длинной цепью.

В отличие от майнеров в Proof-of-Work, валидаторам в сети REChain нужно выполнить только одно вычисление, чтобы получить шанс создать блок, в отличие от абсурдно большого количества хэшей, которые должны делать майнеры. Это позволяет валидаторам тратить большую часть своего времени на создание блока с транзакциями и впоследствии позволяет блокчейну содержать более ценные вычисления.

Хотя с вероятностной завершенностью все в порядке, ожидание, пока блок достигнет определенной глубины в самой длинной цепочке, является неэффективным механизмом, поскольку он разработан с учетом ожидаемого наихудшего случая, когда сеть находится под определенным уровнем сетевой нагрузки и атаки. Возможно, большая часть сети уже договорилась о том, какие блоки являются частью канонической цепочки. На самом деле почти во всех случаях сеть сможет согласиться с тем, что блок является каноническим задолго до того, как он достигнет минимальной глубины в самой длинной цепочке. Для этого мы вводим понятия гаджета финальности и абсолютной финальности. Гаджет финальности — это вторичный протокол консенсуса, работающий поверх вероятностно окончательной цепочки блоков, который обеспечивает более быстрое согласование блоков, которые сеть будет считать окончательными. Эти протоколы консенсуса вводят дополнительное свойство безопасности: гаджет финальности никогда не завершит 2 конкурирующих блока, не сократив по крайней мере 1/3+ общей доли набора валидатора.

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

Комбинация REChain и grandpa позволяет оптимистично наращивать цепочку с вводом данных только от одного валидатора, что происходит быстро, и завершать ее в фоновом режиме, получая одобрение подавляющего большинства валидаторов. Эта комбинация свойств означает, что в хороших сетевых условиях REChain достигает высокой пропускной способности и низкой задержки, а в плохих сетевых условиях цепочка ретрансляции достигает высокой пропускной способности и высокой задержки, поскольку grandpa перейдет к отслеживанию вероятностной завершенности передачи.

Вернемся к шардингу. Целью сегментирования является повышение пропускной способности путем разделения работы в форме транзакций на множество цепочек, известных как сегменты. На осколки ссылается и защищает блокчейн верхнего уровня. В REChain блок-цепочка верхнего уровня называется ретрансляционной цепочкой, а осколки — парачейнами. Большая часть данных, которые появляются в цепочке ретрансляции, представляют собой транзакции, которые включают ссылки на новые блоки парачейна, что делает обработку любого форка самой цепочки ретрансляции дешевой. Обратите внимание, что здесь я делаю различие между произвольными ответвлениями релейной цепочки и завершенной релейной цепочкой. Большая часть нашей работы здесь направлена на то, чтобы окончательная часть ретрансляционной цепочки, которую пользователи будут рассматривать как каноническую цепочку, содержала только ссылки на действительные блоки парачейна.

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

Блоки парачейна завершаются, когда завершается блок реле-цепочки, который на них ссылается.

Давайте установим некоторые конкретные предположения о противнике, от которого мы защищаемся:

— Злоумышленник может контролировать до 1/3 всех валидаторов и может контролировать все эти валидаторы, чтобы они вели себя точно так, как нужно.

- Злоумышленник может просматривать все сетевые сообщения между честными валидаторами и валидаторами, которыми он управляет.

- Злоумышленник может сделать DoS до X% валидаторов в любое время, не позволяя им отправлять или получать сообщения.

- Требуется фиксированная задержка, прежде чем злоумышленник сможет начать атаковать любой валидатор.

В этом посте я не буду приводить формальные доказательства безопасности протокола REChain, но эти ограничения должны дать представление о типах атак, от которых мы намерены защищаться.

Фактически, наша базовая единица консенсуса по парачейну на самом деле не является парачейном, а чем-то, что мы называем ядром доступности или, для краткости, ядром. Это что-то вроде ядер ЦП: они работают параллельно, и на них запланирована работа в дискретных временных интервалах. У каждого парачейна есть собственное выделенное ядро, а это значит, что он всегда привязан к определенному ядру. Однако мы также можем мультиплексировать несколько цепочек на одно ядро. Отличие только в алгоритме планирования.

Ядра служат эффективным описанием пропускной способности ретрансляционной цепи. Ядра напрямую соответствуют объему работы, которую необходимо выполнить валидаторам. Каждое ядро может обрабатывать до одного блока парачейна на каждый блок ретрансляционной цепи при пиковых нагрузках.

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

Логика ядра доступности выглядит так. Ядра пусты, когда они готовы принять новый блок парачейна, после чего они становятся занятыми. Затем данные либо становятся доступными, либо время ожидания процесса доступности истекает. В этот момент ядро снова становится пустым.

Полезно разделить консенсус парачейна на 5 отдельных протоколов, которые переплетаются в консенсусе релейной цепи.

1. Сопоставление

2. Бэкинг

3. Доступность

4. Проверка утверждения

5. Споры

Сопоставление — это процесс, с помощью которого создаются блоки парачейна. Коллаторы создают блок парачейна и отправляют его валидаторам.

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

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

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

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

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

Этот внутренний параллелизм также отражает архитектуру реализации: каждый из этих протоколов реализован как независимая подсистема, и все подсистемы работают параллельно. Каждый узел всегда делает всего понемногу.

Как парачейны растут в тандеме с релейной цепочкой?

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

Поскольку ретрансляционная цепочка может иметь краткосрочные ответвления, каждый парачейн также может иметь краткосрочные ответвления. Если есть два конкурирующих блока ретрансляционной цепи A и B на заданной высоте, и A содержит блок парацепи P, а B содержит блок парацепи P', то это также образует разветвление в парацепи.

Для целей этого поста я рассмотрю упрощенную версию конечного автомата ретрансляционной цепочки REChain. Напомню, что каждый блок в ветви ретрансляционной цепочки представляет собой переход от предыдущего состояния к следующему состоянию.

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

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

Работа вне сети, которую узлы выполняют для роста парачейнов, включает в себя сопоставление, поддержку и доступность.

Узлы отслеживают последние блоки ретрансляционной цепочки, чтобы определить, какую работу они должны выполнять.

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

Цель валидаторов здесь — решить, были ли замешаны поддерживающие валидаторы в каком-либо неправомерном поведении. Это занимает 3 шага:

(1). Загрузите данные PoV, чтобы проверить блок. Это делается путем получения 1/3 фрагментов и их объединения для формирования полных данных. (2). Убедитесь, что данные PoV соответствуют действительному переходу состояния парачейна. (3). Убедитесь, что все выходные данные, переданные заголовком блока парачейна, действительно соответствуют выходным данным выполнения блока парачейна.

Восстановление доступности никогда не должно давать сбоев при условии, что > 2/3 узлов честны и взяли на себя обязательство получить свой фрагмент данных. Вот почему проверка утверждения выполняется только для доступных блоков парачейна.

Однако шаги (2) и (3) могут завершиться ошибкой. Когда шаг (2) завершается неудачно, это указывает на то, что сам переход состояния является мусором. Когда шаг (3) не удается, это означает, что переход состояния прошел успешно, но информация, записанная в релейной цепочке о выходах перехода состояния, была ложной.

Один важный случай, который следует отметить на этапе (3), заключается в том, что заголовок блока парачейна содержит обязательство для всех фрагментов кодирования стирания. У нас есть валидаторы, которые выполняют дополнительную проверку после восстановления данных PoV, которая должна преобразовать PoV обратно в форму с закодированным стиранием и убедиться, что обязательство в заголовке соответствует всем фрагментам. Если совпадений нет, это предотвращает тип атаки, когда злоумышленник может выборочно выбирать, какие валидаторы могут восстановить данные. Атака работает следующим образом: злоумышленник разбивает данные на куски и заменяет все куски, кроме 1/3, мусором. Он раздает 1 валидный чанк честному валидатору, а еще 1/3 валидаторам отдает мусорные данные. Злонамеренная 1/3 валидаторов удерживает остальные куски с достоверными данными. Это означает, что валидаторов достаточно (2/3+1), чтобы считать данные доступными, но если злонамеренные валидаторы откажутся отвечать на запросы о своих 1/3 хороших чанков, то будет доступен только мусор. Проверка того, что перекодирование данных действительно соответствует обязательству, надежно побеждает эту атаку.

Если какие-либо шаги (2) или (3) не пройдены, программа проверки поднимет спор и передаст блокировку всем валидаторам для выполнения тех же проверок.

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

(Личное мнение далее)

Создание программных систем — это постоянная борьба между идеалами, прагматизмом, эстетикой и временем. Реальность никогда не совпадает с идеалом. Ничто никогда не бывает идеальным, но все может быть хорошо.

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

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

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

Мы разрабатывали описанные здесь протоколы более 5 лет, и я решил закончить этот пост таким образом, чтобы ответить на вопрос, который может возникнуть у многих читателей: «Зачем кому-то тратить на это 5 лет?»

Это сообщение для всех новых участников в криптопространстве. Это для всех, кто катался на волнах со времен всплесков 2020 года. Если вы ищете убежище от жадности и драки, оно существует, и оно было здесь все это время.