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

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

  • автор:

Типы распределенных систем

Распределенные системы обычно относятся к одной из четырех различных моделей базовой архитектуры:

1.Клиент-сервер — клиент отправляет запрос серверу, сервер в свою очередь, получив этот запрос, выполняет его и отправляет ответ клиенту.

2. Многоуровневая (n -уровень) — в ней функции такие, как представление, обработка приложений и управление данными, физически разделены. Разделение приложений на уровни, делается для того, чтобы разработчики имели возможность изменить или добавить определенный слой вместо того, чтобы перерабатывать все приложение. Он предоставляет модель, с помощью которой разработчики могут создавать гибкие и повторно используемые приложения.

3. Трехуровневая — информация о клиенте хранится на среднем уровне, а не на самом клиенте, что упрощает развертывание приложений. Эта модель архитектуры наиболее распространена для веб-приложений.

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

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

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

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

Ключевые особенности распределенного реестра:

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

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

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

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

4. Алгоритм консенсуса — общая версия реестра, согласованная всеми участниками сети.

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

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

Классификация сетей распределенных реестров:

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

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

3. Гибридные сети — распределенных реестров сочетают в себе свойства как открытых, так и закрытых сетей.

Хотя внедрение DLT находится на ранней стадии, технология уже продемонстрировала свою способность во многих случаях приносить пользователям преимущества:

1. повышенная наглядность и прозрачность данных, внесенных в реестр;

2. снижены риски мошеннических действий, фальсификации и манипуляций;

3. более высокий уровень безопасности.

Технология распределенных реестров

Технология распределенных реестров

Распределенный реестр (distributed ledger technology) — это база данных, которая распределена между несколькими сетевыми узлами или вычислительными устройствами.

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

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

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

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

Блокчейн для распределенного реестра

Эта статья не о криптовалюте, а о блокчейне и совокупности технологий и идей, которые, на мой взгляд, помогут создать быстрый, масштабируемый и безопасный распределенный реестр (DLT). Простые DLT могут быть созданы с использованием возможностей смарт‑контрактов блокчейнов второго или третьего поколения, но более сложные реестры могут потребовать альтернативных решений. Примером достаточно сложного и специфического DLT может быть децентрализованная платежная система общего пользования, совместимая с государственной денежно‑кредитной политикой, то есть платформа для «цифровых денег». Реализация такого проекта на смарт‑контрактах едва ли возможна. Поэтому в статье предлагаю рассмотреть для этой роли AppChain — гибридную платформу приложения и блокчейна.

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

Приложение в этой комбинации является специфичным для области и, вероятно, потребует разработки с нуля. Блокчейн не является обычным, такой класс программного обеспечения называется «Application specific blockchain». Есть несколько хорошо известных проектов, которые можно использовать в качестве основы. Наиболее известным, вероятно, является Hyperledger Fabric. Но Tendermint показался мне более интересным с точки зрения интерфейса приложения и возможности расширения его функциональности.

Tendermint

Tendermint известен тем, что является основой для Cosmos SDK, с помощью которого создается одноименная блокчейн‑экосистема (монета ATOM) третьего поколения. Нижеприведенные рисунки иллюстрируют архитектуру фреймворка Cosmos SDK и AppChain. Они были взяты из статьи, в которой хорошо раскрыта тема экосистемы Cosmos.

Зеленым цветом выделен Tendermint. Другим цветом в первом случае — Cosmos SDK, во втором — AppChain.

Глядя на эти иллюстрации, возникает вопрос: а почему бы не использовать Cosmos SDK? Cosmos SDK — это уже смарт‑контракты, а нам нужен уровень пониже. Наше приложение будет взаимодействовать с Tendermint непосредственно по протоколу ABCI (Application BlockChain Interface). Физическая реализация этого протокола позволяет реализовать приложение разными методами. Оно может быть в виде модуля на Golang, который слинкуется с кодом Tendermint в один исполняемый файл. Либо это будет отдельное приложение, написанное на любом распространенном языке программирования, взаимодействующее с блокчейн‑нодой Tendermint через несколько сетевых подключений.

Tendermint предоставляет базовые возможности блокчейна, но они максимально обобщены и не накладывают на приложение ряд серьезных ограничений. Например, транзакция не специфицирована и может быть представлена любым байтовым массивом, структуру которого определяет логика приложения. Кроме того, механизм достижения консенсуса является очень гибким, и достигается через протокол Byzantine Fault Tolerant (BFT), с ограниченным списком валидаторов, заданным в генезис‑блоке и может быть изменен приложением.

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

Идентификация, Аутентификация, Авторизация

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

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

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

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

Для идентификации хорошо подходят отличительные имена (distinguished name), например: CN=Василий,STREET=Ферма Василия,L=Нижние Бубенцы,ST=Залесье,С=Наша страна. Думаю, многие сталкивались с ними в LDAP и в сертификатах x.509. Кстати, сертификаты — это один из механизмов, используемых для аутентификации отличительных имен. Учитывая, что стандарт x.509 третьей версии (Extended Key Usage) позволяет хранить в теле сертификата произвольные объекты, вопрос с простым решением для авторизации будет решен. Для чего-то более сложного можно будет задействовать атрибутные сертификаты.

Механизм консенсуса

Как уже упоминалось, Tendermint использует протокол Byzantine Fault Tolerant (BFT). Однако, для достижения консенсуса и определения состояния блокчейна, приложение должно определить список валидаторов, которые будут участвовать в этом процессе. Соответственно и алгоритм, используемый для составления этого списка, реализуется в приложении.

В нашем случае это алгоритм PoA (Proof of Authority). Вкратце, в PoA транзакции подтверждаются теми, кому это положено, а не тем, кто расходует больше вычислительной мощности (PoW) или у кого больше монет (PoS). Для определения того, кому именно положено, мы будем использовать сертификаты, анализируя в них отличительное имя и/или дополнительные атрибуты.

Инфраструктура открытого ключа

Уже понятно, что сертификаты X.509 могут упростить решение задачи. Однако, для их использования необходима инфраструктура открытого ключа (PKI). В основе PKI лежит криптографическая система с открытым ключом. А что лежит в основе безопасности блокчейна? Аналогичная криптографическая система с открытым ключом. Это означает, что пользователи, использующие распределенный реестр, будут иметь пару ключей. Остается только связать публичный ключ пользователя с его отличительным именем через выдачу сертификата. После чего, все его транзакции и записи в распределенном реестре, будут однозначно с ним связаны..

Минимально необходимыми компонентами PKI являются Центр Сертификации (CA) и репозиторий, хранящий два списка: «Выданные сертификаты» и «Отозванные сертификаты». Репозитории будут храниться в записях нашего распределенного реестра. Функции CA будет выполнять соответствующая подсистема в нашем приложении. На узлах, где будет присутствовать сертификат удостоверяющего центра, эта подсистема будет работать в режиме CA server, а на всех остальных — в режиме CA client. Таким образом, мы получим распределенную инфраструктуру открытого ключа (DPKI).

Иерархии

Отличительные имена могут состоять из компонентов нескольких иерархий. Чаще всего это:

  • Иерархия местоположения, представленная атрибутами «C» (страна), «ST» (регион) и «L» (город).
  • Иерархия организации, представленная атрибутами «O» (организация) и «OU» (организационная единица).
  • Иерархия сети, представленная атрибутом «DC» (компонент домена).

Рассмотрим отличительное имя: CN=First Wonderland CA+DC=node01,OU=Data center,L=Cheshire,C=WN+DC=wn,O=The Corporation+DC=thecorp. Оно достаточно однозначно, можно выделить все три иерархии:

  • CN=First Wonderland CA,L=Cheshire,C=WN
  • CN=First Wonderland CA,OU=Data center,O=The Corporation
  • DC=node01,DC=wn,DC=thecorp — легко преобразовывается в FQDN node01.wn.thecorp

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

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

Сегментация сети

Проблемой блокчейнов первого и второго поколений было и остается отсутствие масштабируемости, что негативно сказывается на скорости обработки транзакций и размерах хранилищ. Однако, в блокчейнах третьего поколения эта проблема частично решается путем использования вариаций на тему «sidechain». Сайдчейны — это проблемно-ориентированный блокчейн, имеющий канал взаимодействия с одним из базовых блокчейнов. Хорошим примером может быть блокчейн, используемый для хранения состояния сетевой игры. Большинство транзакций, определяющих изменения игрового мира, обслуживаются в его собственной сети. Лишь небольшая часть транзакций, отвечающих за ввод/вывод финансовых активов (например, ETH), попадают в сеть mainchain (Ethereum) и обслуживаются там.

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

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

Вернемся к рисунку выше. Области, очерченные пунктирными линиями, являются сайдчейнами. Вышестоящие уровни будут mainchain для нижестоящих, но одновременно будут sidechain для своих вышестоящих. Таким образом, будет получена иерархическая сегментация сети. Далее я буду называть их сегментами. Транзакции над объектами одного сегмента не будут выходить за его пределы и отправляться в другой сегмент того же уровня. Если архитектура иерархий будет спроектирована грамотно, такие транзакции будут преобладать. Межсегментные транзакции будут валидироваться более сложными алгоритмами. Очевидно, что в их подтверждении будут участвовать все валидаторы сегментов по восходящей и нисходящей ветке иерархий, логически соединяющих объекты, участвующие в транзакции.

Для примера рассмотрим ситуацию: фермер Василий вернул взятые в кредит миллион «цифровых рублей». Отделение банка, выдавшего кредит, находится в другом населенном пункте, но того же района. Часть прибыли отделения банка отправляется в головной офис, расположенный в другом районе. Схема сети детализирована ниже на рисунке. Красным крестом обозначено физическое отсутствие связи между сегментами.

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

Вторая транзакция же зависнет на уровне OU=Залесский филиал, ST=Залесье, O=Банк, С=Наша страна. Если связь будет восстановлена раньше, чем истечет таймаут обработки транзакций, транзакция будет проведена с опозданием. В противном случае возникнет ошибка, которую приложение должно будет обработать по соответствующим алгоритмам.

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

Сохранение работоспособности в отсутствии сети

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

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

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

Для возможности оплаты офлайн необходимо выполнить следующие действия онлайн:

  • Геннадий должен создать производные ключи и соответствующую запись в реестре на основе своей основной пары ключей. Этот объект/счет будет называться «Чековая книжка Геннадия».
  • Затем Геннадий переводит определенную сумму со своего основного счета на этот новый счет.
  • Основной счет Геннадия зашифрован, и наличие на нем необходимой суммы может проверить только банк.
  • Банк выдает подтверждение в виде сертификата на открытый ключ (адрес) «Чековая книжка Геннадия» с указанием суммы, которая была зачислена на него. Это может быть реализовано как расширение v3 для сертификата..

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

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

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

ГОСТ криптография

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

  • ГОСТ Р 34.11-2012 — Формирование хеша 256 и 512 бит.
  • ГОСТ Р 34.10-2012 — Цифровая подпись на основе эллиптических кривых; размер ключа 256 и 512 бит; функция хеширования ГОСТ Р 34.11-2012.
  • ГОСТ Р 34.12-2015 — Блочный шифр “Кузнечик”; размер ключа 256 бит; размер блока 128 бит.

Tendermint использует криптографические алгоритмы: sha256, ed25519. Также заявляется поддержка secp256k1. Все криптографические функции собраны в отдельный пакет. В Tendermint нет хорошо проработанного интерфейса, позволяющего использовать различные алгоритмы, как в Hyper Ledger Fabric. Поэтому его «гостофикация» будет сложнее, чем «гостофикация» HLF, но это вполне осуществимо.

В заключении

Тема очень интересная. Уже довольно продолжительное время, с паузами, но я изучаю это направление. “С паузами”, потому что деньги в семью не приносят себя сами. Можно попробовать совместить приятное с полезным, устроиться на работу в компанию, которая занимается разработкой распределенных реестров. Попробовать можно, но не факт, что её удастся найти. Компании, которые этим занимаются всерьез и продолжительное время, есть, но техническая информация о проектах практически отсутствует в публичном доступе. То, что удалось выяснить, указывает на то, что они разрабатывают свои распределенные реестры на базе смарт-контрактов на модифицированном Ethereum. Понятно, что если они начинали работу 4-5 лет назад, то и особых вариантов не было. Но это не то, уже не то.

Многие компании с успехом используют Hyperledger Fabric, но они применяют его для решения конкретных задач заказчиков. Но велик соблазн сделать свой Hyperledger Fabric с иерархической сегментацией и DPKI. О компаниях, которые гостофицируют что-то модное и объявляют это — национальной платформой для выпуска токенов и NFT, можно упомянуть только для галочки.

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

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

  • Модуль, который упрощает написание приложений ABCI на Python. Содержит асинхронную реализацию ABCI и минималистический фреймворк.
  • Прототип распределенной инфраструктуры открытых ключей DPKI, описанный в статье. Это еще не MVP, но уже можно посмотреть. Надеюсь довести до уровня MVP в скором времени.
  • Попытка гостофикации Tendermint, пока не полная. Сетевой уровень генерирует производные ключи и работает на ed25519. Уровень консенсуса проходит тесты с ГОСТ ключами, но решение не окончательное. Чтобы сделать это правильно, нужно создать хороший интерфейс криптопровайдера, как у HLF. Сейчас все это в Tendermint прибито гвоздями, и моя попытка по сути сводится к подмене этих гвоздей.

Разные типы распределенных реестров и принципы их работы

Здесь с самого начала нужно уточнить: хотя оба термина «технология распределенного реестра» (DLT) и «блокчейн» взаимозаменяемы, между ними есть разница, которую необходимо понимать.

Разные типы распределенных реестров и принципы их работы

До момента изобретения компьютеров и интернета повсеместно на протяжении 7 веков использовалась бумажная система двойного ввода (Дебет/Кредит), которая возникла в Италии. Хотя идея блокчейна получила актуальность и известность после запуска биткоина в 2008 году, сама идея была концептуализирована еще в 1991 году, когда Стюарт Хабер и У.Скотт Сторнетта представили свою работу по криптографически защищенной (с защитой от злонамеренного вмешательства) цепочке блоков данных с соответствующими метками времени.

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

БЛОКЧЕЙН

Самым простым и распространенным примером технологии DLT является блокчейн, в котором блоки данных соединены друг с другом через идентификаторы данных, которые начинаются с хэша. Здесь каждая транзакция проходит около 4 этапов, где кто-то должен инициировать транзакцию, которая должна быть проверена узлами в сети через соглашение (т.е. консенсус «доказательство работы» в Биткоине).

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

  1. Федеративный— самый жесткий в плане ограничений: ограниченный доступ, гораздо лучшая масштабируемость, прозрачность и конфиденциальность; например, Центральный банк или Консорциум R3
  2. Требующий разрешений/частный — доступ может быть открытым или закрытым, но разрешение на проверку или аудит дается только нескольким лицам; упрощенный процесс согласования и обработки данных; например, Bankchain
  3. Не требующий разрешений/публичный — публичная сеть с открытым исходным кодом; прозрачность и анонимность, поскольку не вовлечена третья сторона; минимальные затраты без необходимости в обслуживании. Из недостатков: длительное время обработки; например, Биткоин.
  4. Гибридный— комбинация публичной/частной сети с частично ограниченным участием; имеет гибкий подход в отношении того, что хранится в закрытом доступе, а что – в открытом. Улучшенная масштабируемость за счет того, что согласие не требуется от каждого узла сети; например, Hyperledger.

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

ХЭШГРАФ

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

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

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

Технология Хэшграфа – это изобретение Лиимона Бэрда, соучредителя и главного технического директора компании Swirlds, которое было в открытом доступе для использования с августа 2018 года. Другим заметным достижением является хэшграф-платформа Hedera, которая позволяет создавать масштабируемые и безопасные приложения по аналогии с Swirlds. В дорожной карте Hedera утверждается, что скорость транзакций варьируется от 200 000 до 500 000 TPS. Примеры практического использования этих платформ должны суметь подтвердить это утверждение: вы можете протестировать основную сеть Hedera, создав профиль на их веб-сайте.

DAG

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

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

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

NXT стала первой платформой для использования DAG с момента ее выхода в ноябре 2015 года. Другие две заметные реализации этой технологии – это IOTA Tangle и ByteBall.

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

HOLOCHAIN

Компания Holochain гордится тем, что открывает новые рубежи технологии цифрового реестра. Наиболее значимым изменением, которое привнесла платформа, является переход от ориентированного на данные подхода к агентурно-ориентированному подходу.

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

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

Эта истинная децентрализация сети на каждом уровне позволяет Holochain-DLT достигнуть скорость в миллион транзакций в секунду. Проверка на микроуровне полностью избавляет от перегрузки сети. Так как каждый узел имеет свой собственный реестр, он идентифицируется с помощью определенного идентификатора значения, называемого «ДНК». Если другие узлы получили сообщение, используя определенную ДНК узла, они передали бы его к остальной части сети, но если есть злонамеренная попытка добавить ложную информацию в сеть, транзакция будет отклонена и неудачная попытка будет сообщена остальной части сети, чтобы избежать этого в будущем.

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

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

RADIX (TEMPO)

Еще одним относительно новым участником пространства DLT является Radix. Это нововведение позволяет вам создавать распределенный реестр Tempo без блокчейна для открытых и частных сетей, что не требует никаких изменений. Реализация очень легкая, так как вам не нужны никакие аппаратные компоненты.

Radix-DLT также предлагает временные метки, помимо других функций, описанных ниже.

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

Проект все еще находится в зачаточном состоянии, но демонстрирует большой потенциал. На момент написания статьи платформа записывала 1700-1800 TPS с 20 узлами и временем завершения менее 5 секунд. Если резюмировать:

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *