Блокчейн против технологических платформ распределенного реестра

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

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

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

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

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

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

I. Государство

Ethereum

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

Контрактные счета - счета, контролируемые кодом контракта
Внешние учетные записи - учетные записи, управляемые закрытым ключом

Ethereum использует концепцию World State, которая представляет собой отображение адресов учетных записей и состояний учетных записей. State_Root - это корень дерева Патрисии Меркл для объединения учетных записей в системе. И внутри учетных записей состояния контрактов также организованы в эту структуру данных Patricia Merkle trie. Корневой хэш состояния может использоваться для защиты идентичности данных в дереве Меркла, позволяя репликацию по всей сети, что в конечном итоге приводит к теоретической неизменности системы.

Комментарий

Функциональность, которую создает Ethereum World State, представляет собой систему без доверия, которая позволяет создавать экземпляры ценности в цифровом формате. Источники цифровой репрезентативной ценности, присущие экономике токенов, могут быть получены из состава учетных записей и структур суб-данных Ethereum; таким же образом, как логические вентили могут создавать функциональные алгоритмы в традиционной инженерии.

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

IBM Fabric

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

LevelDB создает базу данных ключ / значение
CouchDB будет содержать базу данных документа JSON

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

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

Комментарий

IBM Fabric создала процесс, который заменяет ключевые принципы системы цепочки блоков в обмен на достижение переходов между состояниями с высокой пропускной способностью. Использование текущей архитектуры позволяет легче изменять и отображать состояния в традиционной схеме программного обеспечения, что приводит к доступу для чтения / записи. Хотя организация состояния в среде Fabric является эффективной, ей не хватает возможности создавать экземпляры ценности в публичной децентрализованной экосистеме, точно так же, как это может сделать настоящий блокчейн, такой как Ethereum или Bitcoin. Перемещение данных в программной среде Fabric указывает на то, на что способна распределенная база данных.

R3 Корда

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

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

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

Выдача
Владелец
faceValue и Amount <Выпущено <Валюта>>
maturityDate

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

Комментарий

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

II. Сделки

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

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

Есть два типа транзакций:

Сообщения звонки
Создание контрактов.

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

Комментарий

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

Настоящая цифровая экономика
Цифровые товары и активы, контролируемые экономическими стимулами, в отличие от организационных / монополистических стимулов
Интерфейс взаимодействия между частными учреждениями и государственной цифровой экономикой

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

IBM Fabric

Все транзакции выполняются в многоканальной архитектуре Fabric для обеспечения высокой пропускной способности транзакций в доверенной среде. Транзакции добавляются в общую книгу, которая существует в среде выполнения. Благодаря этой архитектуре Fabric обеспечивает доступ для чтения / записи и возможность использования своей программной среды, обеспечивая функциональность и удобство использования, аналогичные мэйнфреймам. Известно, что базы данных SQL на несколько порядков более производительны, чем любой блокчейн, доступный в настоящее время, а конфигурация Fabric многое заимствует из парадигм, используемых в традиционных инструментах баз данных, что обеспечивает превосходную пропускную способность транзакций.

Есть два типа транзакций:

Развернуть транзакции - создать новый цепной код. Устанавливает цепной код в среду разработки программного обеспечения
Вызов транзакций - вызывает ранее созданный цепной код и соответствующие функции. Когда это успешно выполнено, цепной код выполняет функцию и вносит изменения в состояние
Вызов функций приводит к транзакциям "получить" или "установить"

Чтобы обеспечить максимальную эффективность обработки данных и высокую скорость, отдельные большие двоичные объекты транзакций AKA группируются службой заказов Apache Kafka и выводятся в виде «блоков» посредством события доставки . Транзакции ( большие двоичные объекты ) упорядочиваются службой заказа Apache Kafka и добавляются к разделам Kafka. Это означает, что архитектура Fabric жертвует целостностью и точностью данных настоящей системы блокчейна, чтобы получить более быструю обработку транзакций и пропускную способность в надежной среде потоковой передачи данных, что очевидно из использования Apache Kafka Ordering Service.

Как видно из документации Fabric, заказанные транзакции напрямую добавляются к разделам, связанным с Kafka Topics. Это приводит к транзакциям с высокой пропускной способностью, которые происходят в надежной среде потоковой передачи данных. (Источник: Apache Kafka)

Комментарий

Хотя в системе используется терминология в стиле блокчейн, это не блокчейн в традиционном смысле, поскольку в структуре данных дерева Патрисии Меркл нет сохранения состояния и дополнительных транзакций. IBM Fabric - это DLT, а не блокчейн. Архитектура Fabric была разработана для превосходной обработки транзакций, что видно из добавления больших двоичных объектов данных.в сервис заказа потоковой передачи данных Kafka. Поскольку это достигается в доверенной среде, выполнение может свободно происходить в системе. Использование этой конфигурации в системе передачи ценностей было бы неидеальным, учитывая, что все доверие должно быть отнесено непосредственно к одной программной архитектуре из одного объекта, а не к общей экосистеме или протоколу. Как видно из технических документов, Fabric архитектурно отказался от целостности данных и безопасности, достигнутых на платформах блокчейн, чтобы получить превосходную обработку между компонентами транзакции.

R3 Корда

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

Есть два основных типа транзакций:

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

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

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

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

Комментарий

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

Превосходное хранилище закрытых финансовых данных
Надежная установка для недоверчивых финансовых учреждений
Расширенный свод бизнес-взаимодействий

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

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

Ethereum

В Ethereum смарт-контракты написаны на языках программирования высокого уровня, таких как solidity, LLL или Viper, и скомпилированы в байт-код EVM, что позволяет исполнять двоичные файлы на виртуальной машине Ethereum (EVM). Узлы в сети Ethereum запускают собственную реализацию EVM, которая действует как среда выполнения для смарт-контрактов в экосистеме Ethereum. Состояние и транзакции, ведущие к переходам между состояниями, воплощаются в мировом состоянии блокчейна Ethereum посредством репликации EVM, в результате чего создается система, которая может реализовать неподкупное доверие в массиве спектров.

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

Состояние системы = глобальное состояние Ethereum
Состояние машины = бизнес-логика контрактных учетных записей и код, реплицированный во время выполнения EVM

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

Комментарий

Поскольку реализации EVM строго соответствуют спецификациям, указанным в Желтой книге Ethereum, различные экземпляры Ethereum (общедоступные, частные и консорциумные) способны к взаимодействию, как это определено из общей компиляции языков высокого уровня - в форме интеллектуальных контракты - в байт-код Ethereum с помощью EVM. Благодаря такому расположению Ethereum он может выступать в качестве промежуточного слоя между различными аспектами крупных институциональных частных объектов обработки данных и общедоступной экономикой цифровых товаров, которая в настоящее время развивается и реализуется благодаря недавнему созданию экономики токенов.

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

IBM Fabric

Chaincode - это не обязательно смарт-контракт, развернутый в блокчейне на основе учетной записи, а скорее программа, которая установлена и впоследствии реализует интерфейс через API. Интерфейс API требует инструкций на основе кода для управления бизнес-логикой и функциональностью всей системы, аналогично традиционной среде разработки программного обеспечения. Методы, связанные с API, включают:

Init - инициирование состояний приложения
Invoke - обработка предложений транзакций

Chaincode должен реализовывать интерфейсы из API:

Интерфейс цепного кода
ChaincodeStubInterface

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

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

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

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

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

Комментарий

Перемещение Chaincode через эту сетевую конфигурацию позволяет оптимизировать организацию системы. Архитектура программного обеспечения предназначена для работы в качестве очень эффективной структуры управления и контроля с точки зрения распределения данных и организации среды разработки программного обеспечения для определенных случаев использования на предприятии . Как видно из настроек пакета , установки , создания экземпляра и обновления , эта архитектура была разработана для оптимизации необходимых точек взаимодействия, необходимых для обработки кода. Необходимые интерфейсы API по мере обработки транзакций очень напоминают традиционный дизайн программного обеспечения. Примечания:

Монолитная архитектура для максимального контроля
Обеспеченное деловое взаимодействие между контрагентами
Централизованно координируемая обработка пропускной способности транзакций

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

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

R3 Корда

В Corda смарт-контракты считаются классами, реализующими интерфейс контракта. Смарт-контракты написаны на Java / Kotlin и компилируются с помощью виртуальной машины Java (JVM), которая представляет собой вычислительную машину, в которой выполняется код. Основная функция, используемая в контрактах, - это функция «проверки».

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

Компоненты смарт-контракта:

Исполняемый код
Проверяет изменения в транзакциях
Государственные объекты
Данные, хранящиеся в бухгалтерской книге
Текущее состояние контракта
Использует входы и выходы транзакций
Команды
Дополнительная информация
Используется для указания исполняемого кода контракта

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

Комментарий

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

IV. Заключение и оценка

Основываясь на нашем анализе, ключевыми отличительными факторами, которые Ethereum может реализовать помимо возможностей DLT, являются:

Экономика цифровых активов или токенов
Уровни криптоэкономических стимулов в протоколе
Взаимодействие между консорциумом и общедоступными блокчейнами

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

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

Этот анализ показывает не то, что одни системы лучше других, а то, что они полезны для разных целей. Способность платформ DLT действовать как частные распределенные базы данных с высокой пропускной способностью и функциональностью транзакций, позволяет им действовать как доверенные системы, которые могут взаимодействовать с платформой блокчейн, когда для оценки необходимы определенные аспекты частной информации, такие как банковские / финансовые данные или конфиденциальная информация, относящаяся к внутренней работе частного учреждения, которая не должна разглашаться общественности. Различные бизнес-модели использования этих источников частных данных, связанных с DLT, все еще находятся в разработке, и их следует повторять с учетом интерфейсов блокчейнов, поскольку для некоторых взаимодействий между блокчейнами и DLT необходима децентрализованная цифровая система ценностей. Дальнейшее понимание некоторых из этих интерфейсов взаимодействия будет более подробно рассмотрено в Части 3 серии статей «Блокчейн против DLT».