Эволюция Kadena, первого настоящего частного блокчейна

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

Здесь Сэмман объясняет, как алгоритм консенсуса, достигнутый Raft, был окончательно исправлен его дальним родственником, Kadena.

В этой статье рассматривается блокчейн Kadena. Он использует ScalableBFT для обеспечения высокой производительности (8000–12000 транзакций в секунду) с полной репликацией и распределением в ранее невозможных масштабах (емкость для более чем 500 участвующих узлов).

Это, наряду с многоуровневой моделью безопасности и инкрементальным хешированием, позволяет создать действительно надежный блокчейн. На основе Raft и Juno, Kadena встраивает в свой блокчейн полноценный язык смарт-контрактов (Pact), который может быть запущен как публичный (обычный текст), так и приватный (шифрование с двойным храповым механизмом) транзакции.

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

Подобно Bitcoin, блокчейн Kadena тесно интегрирован, и понимание того, на что он способен и что эти возможности подразумевают, требует изучения значительного объема материала. Поэтому я разбил статью на три части: 1) Введение и Плот, 2) Предшественники Кадены –Тангароа&Юнонаи 3) Блокчейн Кадены – ScalableBFT, Pact и всепроникающий детерминизм.

Часть 1: Введение и алгоритм консенсуса Raft

История Kadena представляет собой интересный пример из новой области алгоритмов консенсуса на основе блокчейна и распределенных вычислений.

Kadena является «дальним родственником» Алгоритм консенсуса Raft. Механизм консенсуса Raft был реализованТангароа(плот византийской отказоустойчивости (BFT)) и проект JP MorganЮнона(ответвление Тангароа), ни один из которых больше не находится в стадии активного развития.

Новый блокчейн Quorum от JP Morgan

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

Kadena — это «следующее поколение Juno». Он использует новый, но связанный протокол ScalableBFT, который был создан из открытого исходного кода проекта Juno и был создан двумя ключевыми разработчиками, создавшими Juno. Прежде чем углубляться в Kadena, необходимо обсудить краткую историю и описание Raft и предшественников Kadena .

Плот консенсуса

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

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

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

Если за этот период времени ведомый не получает никаких сообщений, он становится кандидатом и инициирует выборы. Кандидат, который получает голоса от большинства полного кластера (узлов в сети), становится новым лидером. Лидеры обычно работают до тех пор, пока не потерпят неудачу. Heartbeat посылаются, чтобы убедиться, что лидер все еще там; если ничего не получено, происходят новые выборы.

Рафт приходит к консенсусу в следующие этапы:

• Кластер серверов узлов Raft запускается, и каждый узел запускается как «Последователь». В конце концов, ONE узел истечет время ожидания, станет кандидатом, получит большинство голосов и станет лидером.
• Каждый узел хранит журнал, содержащий команды. Задача Лидера — принимать новые команды, строго упорядочивать команды в своем журнале, реплицировать свой журнал своим последователям и, наконец, информировать последователей о том, когда следует фиксировать журналы, которые они реплицировали. Таким образом, алгоритм консенсуса гарантирует, что журналы каждого сервера имеют одинаковый порядок.
• Журналы «коммитируются», когда они были реплицированы на большинство узлов. Лидер собирает количество репликаций и, после того как большинство увидено, коммитит свои собственные новые записи журнала и информирует своих последователей сделать то же самое.
• При «коммите» команда в каждой записи журнала оценивается машиной состояний. Поскольку Raft безразличен к телу команды, любая машина состояний может обрабатывать зафиксированные записи. Более того, консенсус гарантирует, что выполнение команды всегда происходит в том же порядке, в котором команды поступают из журнала, который строго упорядочен.
• Конечные автоматы будут оставаться согласованными до тех пор, пока выполнение команд будет детерминированным.
• Когда клиент отправляет команду ONE из серверов, этот сервер либо пересылает команду лидеру, либо является лидером. Лидер собирает новую команду, назначает ей индекс журнала, инкапсулирует ее в запись журнала и добавляет команду в незафиксированную часть своего журнала.
• Всякий раз, когда у лидера есть неподтвержденные записи, он реплицирует эту часть журнала своим последователям. Когда лидер получает информацию об успешной репликации от большинства кластера, он фиксирует новые записи и приказывает своим последователям сделать то же самое.
• Всякий раз, когда фиксируется новая запись журнала, консенсус относительно этой записи достигнут. Затем она оценивается конечным автоматом на каждом сервере.
• С этого момента Raft завершен, и разработчики могут решить, как обрабатывать ответы: отвечать клиенту или ждать, пока клиент запросит результат.

Ответы клиенту обычно асинхронны.

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

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

Часть 2: Предшественники Кадены – Тангароа и Юнона

Тангароа: первый шаг к плоту BFT

Tangaroa — это вариант алгоритма консенсуса Raft с византийской отказоустойчивостью (BFT), созданный на основе оригинального алгоритма Raft и алгоритма практической византийской отказоустойчивости (PBFT).

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

В стандартном Raft вам необходимо реплицировать запись журнала на большинство узлов в кластере перед ее фиксацией. Для алгоритмов консенсуса BFT, включая Tangaroa, требуемый размер кластера составляет не менее 2f + 1, где f — количество отказов, которые вы хотите допустить (включая как вышедшие из строя узлы, так и скомпрометированные узлы). Консенсус достигается большинством голосов кластера; если f <= 3, то размер кластера = 7, а невизантийские узлы = 4. Некоторые протоколы BFT могут даже требовать 3f + 1.

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

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

Выборы лидера и этапы

Tangaroa использует Raft как основу для консенсуса; таким образом, есть один лидер. В Tangaroa, как и в Raft, каждый узел находится в ONE из трех состояний: лидер, последователь или кандидат.

Подобно Raft, каждый узел начинает как последователь, ONE из которых в конечном итоге выйдет из строя и назначит выборы. Победитель выборов становится лидером на оставшийся срок; сроки заканчиваются, когда избирается новый лидер. Иногда выборы приводят к разделению голосов, и срок заканчивается без лидера. В этом случае последователь снова выйдет из строя (тайм-ауты сбрасываются, когда подается голос или объявляются выборы) и начнет процесс голосования заново.

Чтобы начать выборы, последователь увеличивает свой текущий срок и отправляет RequestVote (RV)Удаленный вызов процедур (RPC)параллельно каждому из других узлов в кластере, запрашивая их голос. RPC, которые использует Tangaroa, похожи на RPC Raft, за исключением того, что каждый RPC подписывается и проверяется с помощью подписей PPK.

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

Когда узел Tangaroa получает RV RPC с действительной подписью, он немедленно предоставляет голос, только если у него в данный момент нет лидера (происходит только при запуске). В противном случае он начинает процесс, который Tangaroa называет «LazyVote».

Целью LazyVote является защита невизантийских последователей от выбора нового лидера, когда лидер не является неисправным; без ленивого голосования византийский узел может инициировать повторные выборы в любое время и истощить систему. Когда новый RV получен последователем, он сохраняет RV и ждет, пока не будут выполнены все следующие условия:

a) Истечение тайм-аута выборов последователя срабатывает до того, как он обработает heartbeat от своего текущего лидера. Если heartbeat получен, LazyVote очищается.

б) Новый срок службы автофургона больше текущего срока.

c) Отправитель Request является подходящим кандидатом (действительная подпись PPK и клиент T забанил узел).

г) Узел, получающий RV, не голосовал за другого лидера на предлагаемый срок.

e) Кандидат разделяет префикс журнала с узлом, содержащим все зафиксированные записи. Узел всегда отклоняет Request , если он все еще получает сообщения heartbeat от текущего лидера, и игнорирует RequestVote RPC, если предложенный срок уже начался.

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

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

Узлы ждут, пока не посчитают, что выборы должны состояться, прежде чем голосовать. После отправки голоса узел обновит свой номер термина. Однако он не предполагает, что узел, за который он проголосовал, выиграл выборы, и он все равно отклонит RPC AppendEntries (AE) от кандидата, если ни один из них не содержит набора голосов, подтверждающих победу кандидата на выборах. AE выполняют двойную функцию: тактовых импульсов и переносчиков новых записей журнала, которые требуют репликации. Кандидат остается в состоянии кандидата, пока не произойдет ONE из трех событий:

a) Он выигрывает выборы, получив большинство голосов от кластера. Кандидат должен сохранить эти голоса — RequestVoteResponse (RVR) RPC — для будущего распределения.

б) Другой узел устанавливает себя в качестве лидера

в) Проходит период времени, в течение которого победитель не определяется (т.е. наступает очередной тайм-аут выборов)

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

Управление

Как и Raft, Tangaroa использует рандомизированные тайм-ауты для запуска выборов лидера. Лидер каждого срока периодически отправляет сообщения heartbeat (пустые AE RPC) для поддержания своего авторитета. Если последователь не получает сообщения от лидера в течение случайно выбранного периода времени, тайм-аута выборов, то он становится кандидатом и инициирует новые выборы.

В дополнение к спонтанным выборам, инициируемым последователями, Tangaroa также позволяет клиенту вмешиваться: когда клиент не замечает прогресса с лидером в течение определенного периода времени, называемого тайм-аутом прогресса, он рассылает UpdateLeader RPC всем узлам, сообщая им о необходимости игнорировать будущие тактовые импульсы от того, кого клиент считает текущим лидером в текущем сроке. Эти последователи будут игнорировать сообщения тактовых импульсов в текущем сроке и выходить из строя, как если бы текущий лидер потерпел неудачу, начиная новые выборы.

Данные получены

Данные (новые команды) поступают от клиентов кластера Raft, которые отправляют запросы лидеру. Лидер реплицирует эти запросы в кластер и отвечает клиенту, когда в кластере достигается кворум по этому Request.

Что составляет «Request» зависит от системы. То, как хранятся данные, зависит от системы. Важно, чтобы состояние сохранялось на диске, чтобы узлы могли восстанавливать и запоминать информацию, которую они передали (за какие узлы они голосовали, какие записи журнала они передали и ETC.). Без этого протокол не будет работать.

Тангароа добавляет BFT в эволюцию Raft

Юнона

Проект JP Morgan Juno является форком Tangoroa и представляет собой доказательство концепции, которая позволила масштабировать Tangaroa, включив в нее до 50 узлов и повысив скорость транзакций до 5000 транзакций в секунду.

Команда JPM, стоящая за Juno, увидела потенциал, который представляет подход, подобный Tangaroa, — высокопроизводительный частный блокчейн. Они работали над этой идеей в течение года и открыли исходный код проекта в феврале 2016 года. Они добавили язык смарт-контрактов, исправили некоторые ошибки проектирования и добились 10-кратного увеличения производительности, что позволило изменять количество голосующих узлов во время работы системы. Juno позволяла добавлять и удалять узлы и была разрешенной распределенной системой, в которой все узлы в сети были известны.

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

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

Часть 3: Блокчейн Кадены – ScalableBFT, Pact и всепроникающий детерминизм

Криптография

В отличие от Raft, каждая реплика в системе BFT Raft (семейство алгоритмов, включающее Tangaroa, Juno и ScalableBFT Кадеана) вычисляет криптографический хэш каждый раз, когда добавляет новую запись в свой журнал. Хэш вычисляется по предыдущему хешу и новой добавленной записи журнала.

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

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

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

Консенсус

В Raft Лидер избирается с помощью рандомизированных тайм-аутов, которые заставляют Последователя предлагать себя в качестве Кандидата и Request голоса. ScalableBFT также делает это, но криптографически защищенным способом. Например, если Лидер становится недоступным, тайм-аут вызовет новые выборы, но процесс выборов устойчив к византийским узлам, объявляющим выборы. ScalableBFT устраняет проблемы, с которыми столкнулись Juno и Tangaroa в отношении ленивого голосования.

Единственными уникальными возможностями Лидера являются: 1) упорядочивание новых транзакций до репликации и 2) репликация новых транзакций на узлы Последователя. С этого момента все узлы независимо друг от друга доказывают как достоверность консенсуса, так и целостность отдельных транзакций.

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

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

По сути, он работает, проводя голосование большинства по вопросу о том, что фиксировать. Фиксация транзакции T означает, что она будет выполнена, а означает, что она была навсегда реплицирована большинством кластера. Плохие транзакции, те, которые содержат ошибки или имеют плохие подписи, реплицируются, а задача консенсуса — обеспечить идеальную упорядоченную репликацию.

Фиксация транзакции позволяет каждому узлу затем независимо оценивать (анализировать/расшифровывать/проверять Криптo/выполнять/ и ETC.) каждую транзакцию идентичным образом. Каждая транзакция связывается с выходом, который может варьироваться от «плохой Криптo» до выхода уровня смарт-контракта (который также может быть ошибкой).

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

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

Вот почему Kadena потребовалось так много конвейеризации: команда выяснила, как совершать 8000 транзакций с той же скоростью, что и совершать одну транзакцию.

ScalableBFT представляет собой прорыв в области консенсуса BFT, поскольку это первый и единственный детерминированный механизм консенсуса BFT, который может масштабироваться за пределы сотен узлов с полной репликацией и шифрованием. ScalableBFT также предоставляет уникальную модель безопасности, известную как всепроникающий детерминизм, которая обеспечивает безопасность не только на уровне транзакций, но и на уровне консенсуса, одновременно шифруя каждую транзакцию с помощью протокола Noise (см. ниже).

Kadena использует детерминированный консенсус

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

ScalableBFT является детерминированным и защищенным, поэтому:

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

Kadena специально разработана для разрешенных сетей, и как таковая она предполагает, что определенные атаки (например, DoS) маловероятны и находятся вне ее контроля. Если бы ONE произошла, система бы либо заблокировалась (все узлы в конечном итоге вышли бы из строя, но выборы никогда бы не были успешными), либо простаивала бы.

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

Выборы лидера очень похожи на Raft в том, что любой узел может быть избран лидером, каждый узел получает ONE голос за срок, а выборы объявляются, когда срабатывает случайный тайм-аут ONE из узлов (таймер сбрасывается каждый раз, когда узел получает сигнал от лидера).

Самое большое отличие заключается в том, что в Raft узел, набравший достаточное количество голосов, берет на себя лидерство, тогда как в ScalableBFT узел, набравший большинство голосов, распределяет эти голоса между всеми остальными узлами, чтобы продемонстрировать (в стиле BFT), что он был избран лидером кластера.

Механизм ScalableBFT устраняет проблемы, обнаруженные в Juno и Tangaroa, такие как «вышедший из строя кандидат», когда невизантийский узел отключается из-за разделения сети, но, поскольку его срок был увеличен, он T может вернуться к консенсусу и вместо этого продолжает отключаться, а затем увеличивает свой срок («Вышедший из строя кандидат»).

Консенсус Raft гарантирует строгий порядок и репликацию сообщений; T, что находится в каждом сообщении, и может варьироваться от случайных чисел до зашифрованного текста и текстовых смарт-контрактов. Kadena использует уровень журнала как службу обмена сообщениями при работе в зашифрованном контексте; подобно тому, как Signal может запускать шифрование протокола Noise через SMS. ScalableBFT запускает Noise через блокчейн.

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

Модель безопасности/всепроникающий детерминизм

Kadena использует термин «всепроникающий детерминизм» для описания «идеи блокчейна, который использует криптографию на основе PPK-Sig для гарантий авторства (как Bitcoin) и состоит из полностью детерминированного консенсусного слоя в дополнение к неполному по Тьюрингу слою смарт-контрактов с одним назначением».

Последствия «полностью детерминированного» блокчейна довольно значительны, поскольку он позволяет расширить класс контролируемости реестра биткойнов до уровня консенсуса, объединив несколько уровней криптографического доверия.

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

• Кто подписал транзакцию, по которой были загружены «платежи»
• Какие консенсусные узлы были в кластере на момент загрузки?
• Какие консенсусные узлы согласились с тем, что транзакция действительна?
• Какие узлы проголосовали за текущего лидера на момент загрузки
• Кто был лидером?
• Кто был предыдущим лидером?
• И ETC. д .

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

Это обеспечивает BFT не только для уровня консенсуса, но и для уровня транзакций (Bitcoin уже делает это). Это отличается, скажем, от PBFT, который предполагает, что транзакции, отправленные с сервера клиента, являются действительными, что оставляет их возможность быть скомпрометированными. Более того, BFT, не относящиеся к Raft, обычно доверяют клиенту возможность отстранять/банить узлы. Всепроникающий детерминизм принимает альтернативную точку зрения: ничему не доверять, все проверять.

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

Я попросил Уилла Мартино (соучредителя Kadena) рассказать подробнее, как это работает для каждого слоя:

Какова ваша модель безопасности на уровне консенсуса?

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

Мы используем хэши blake2 и номер Term для определения уникальности, позволяя клиентам системы не беспокоиться о случайной отправке дубликатов или о повторном отправке команд вредоносным узлом/человеком посередине (MITM). Мы используем постоянную безопасность, подход на основе PPK-sig для проверки авторства (или любой другой подход, который можно сохранить на диске), который очень похож на то, как Bitcoin проверяет транзакции, но на уровне консенсуса (в дополнение к уровню транзакции).

Это противоположно эфемерной безопасности, которая использует защищенные каналы (TLS) для проверки авторства — гораздо более слабый подход, при котором ответ на вопрос «кто отправил транзакцию X?» дается не с помощью криптографии PPK, а с помощью запроса на уровне консенсуса, поскольку ни один отдельный узел не способен предоставить ответ BFT.

Какова ваша модель безопасности на уровне транзакций?

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

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

С другой стороны, постоянная безопасность имеет много ключей для отдельных ролей в данной организации, поэтому злоумышленнику необходимо получить доступ к отдельным ключам; кроме того, при постоянной безопасности транзакции генерального директора подписываются другим ключом, чем транзакции почтового клерка, в отличие от эфемерной, где «кто отправляет эту транзакцию» определяется полем «от: X».

Если одно и то же соединение TLS используется для отправки транзакций как генерального директора, так и клерка, то логика авторизации и авторизации представляет собой модель «потому что я так сказал/доверьтесь мне» по сравнению с подходом PPK-sig, где вы проверяете по соответствующему ключу перед выполнением. Блокчейн Kadena разработан так, чтобы доверять как можно меньше; если бы мы знали о более параноидальном или мелкозернистом подходе, чем подписи PPK на уровне строк, мы бы использовали его.

Какова ваша модель конфиденциальных транзакций?

Мы используем протокол Double-Ratchet (который Signal, WhatsApp и ETC. используют для зашифрованных сообщений), встроенный в блокчейн (зашифрованные тела транзакций) для многосторонних вариантов использования с сохранением Политика конфиденциальности . Мы работаем с понятием непересекающихся баз данных через примитив «pact» в Pact – они описывают многофазный рабочий процесс фиксации по непересекающимся базам данных через зашифрованные сообщения.

Смарт-контракты

Pact — это полноценный язык смарт-контрактов, интерпретатор которого построен на Haskell. В Kadena каждая транзакция является смарт-контрактом, а язык смарт-контрактов Pact имеет открытый исходный код. Pact ориентирован на базу данных, транзакционный, неполный по Тьюрингу, с одним присваиванием (переменные не могут быть изменены в течение их жизни), и, таким образом, хорошо поддается статической верификации.

Pact также интерпретируется — код, который вы пишете, выполняется в цепочке — тогда как Solidity компилируется, что затрудняет проверку кода, а также делает невозможным исправление проблем безопасности в старых языковых версиях после компиляции. Pact поставляется со своим собственным интерпретатором, но может работать в любом блокчейне с детерминированным входом и может поддерживать различные бэкэнды, включая коммерческие СУРБД. В блокчейне ScalableBFT он работает с быстрым слоем хранения SQLite.

Блокчейн Kadena содержит все эти функции:

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

Эта статья была ранее опубликована наБлог Саммантикии было воспроизведено здесь с разрешения. Некоторые правки были сделаны для стиля и краткости.

Изображение шестеренокчерез Shutterstock