Блокчейн против технологий распределенной книги (DLT): Часть 2

блог 1НовостиДля разработчиковПредприятиеБлокчейн РазъяснениеМероприятия и конференцииПрессаИнформационные бюллетени

Contents

Подписывайтесь на нашу новостную рассылку.

Адрес электронной почты

Мы уважаем вашу конфиденциальность

ГлавнаяБлогБлокчейн для предприятий

Блокчейн против технологий распределенной книги (DLT): Часть 2

Сравнительный анализ архитектур и управляющей динамики Ethereum, Hyperledger Fabric и R3 Corda.by ConsenSysMay 23, 2018Posted on May 23, 2018

блокчейн dlt 2 герой

Это вторая часть сравнительного анализа Ethereum, Hyperledger Fabric и R3 Corda, состоящего из двух частей. Прочтите часть 1 статьи «Блокчейн против DLT». 

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

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

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

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

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

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

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

особенности платформыОбзор технологических возможностей Ethereum, Hyperledger Fabric и R3 Corda.

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

Ethereum

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

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

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

Истинные блокчейны отличаются от DLT на основе их зависимости от структуры данных Patricia Merkle Tree и их согласованности между блоками, которая используется для создания экземпляра состояния системы. Эта концепция является неотъемлемой частью достоверности целостности данных и точности архитектуры системы блокчейн.Истинные блокчейны отличаются от DLT на основе их зависимости от структуры данных Patricia Merkle Tree и их согласованности между блоками, которая используется для создания экземпляра состояния системы. Эта концепция является неотъемлемой частью целостности, достоверности и точности данных архитектуры системы блокчейн..

Комментарий

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

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

Hyperledger Fabric

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

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

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

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

Комментарий

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

R3 Корда

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

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

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

  • Выдача
  • Владелец
  • faceValue и Amount>
  • maturityDate

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

Комментарий

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

II. Сделки

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

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

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

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

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

Комментарий

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

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

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

Hyperledger Fabric

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

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

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

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

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

Комментарий

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

R3 Корда

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

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

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

конечное состояние

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

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

клиентская архитектура

Использование модели, подобной 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 1

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

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

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

Комментарий

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

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

Hyperledger Fabric

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

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

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

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

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

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

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

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

Комментарий

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

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

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

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

R3 Корда

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

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

государственный объект

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

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

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

Комментарий

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

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

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

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

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

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

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

Свяжитесь с нашими экспертами по блокчейну

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

Полное руководство по бизнес-сетям с блокчейном

Введение в токенизациюВебинар

Введение в токенизацию

Будущее финансовых цифровых активов и DeFiВебинар

Будущее финансов: цифровые активы и DeFi

Что такое Enterprise EthereumВебинар

Что такое Enterprise Ethereum?

Центральные банки и будущее денегБелая бумага

Центральные банки и будущее денег

Komgo Blockchain для финансирования торговли сырьевыми товарамиДело Шпилька

Komgo: Блокчейн для финансирования торговли сырьевыми товарами

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map