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

Блокчейн Ethereum обладает как сходствами, так и отличиями в сравнении с такими технологиями распределённого реестра, как Hyperledger Fabric или R3 Corda. Для обоснованной оценки блокчейнов и платформ распределённого реестра и их ценности для предприятий полезно классифицировать платформы на основании их базового функционала и характеристик. Поскольку блокчейны построены на принципах криптографии и конфигурации данных, некоторые их функции могут быть воспроизведены в координированных системах баз данных, тогда как другие осуществимы только в настоящей среде блокчейна.

Разграничение базовых технологий

Hyperledger Fabric R3 Corda Ethereum
Технология распределённого реестра Технология распределённого реестра Блокчейн

В частности, мы сосредоточимся на трёх ключевых областях функционала:

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

Основные цели блокчейна: чего бизнес хочет достичь с помощью этой технологии?

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

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

Эффективная обработка и координирование информации

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

Неизменяемая/доверенная запись продуктов и транзакций

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

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

Дигитализация активов

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

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

Оценка характеристик координирования баз данных

Координирование баз данных: характеристики

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

Для надлежащего координирования данных в распределённых системах изобретено и реализовано множество инструментов. Примером может служить сильный акцент на таких инструментах, как Hadoop и различные ансамбли в данной экосистеме, включая Spark, Hive и ZooKeeper. Использование этих продуктов свидетельствует об активной интеграции распределённых системных инструментов и протоколов. Дальнейшие параллели можно увидеть в таких протоколах, как Tendermint, консенсусная машина, решающая задачу византийских генералов, имеющая схожий функционал с такими инструментами, как Apache ZooKeeper. Проводились также исследования в направлении баз данных – источников событий (event sourcing), способных воспроизводить некоторые желаемые функции координированных систем обмена данными.

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

Координирование данных: сравнение платформ

IBM Fabric

Глубокое погружение в архитектуру Fabric позволяет определить, что платформа создала изощрённую среду разработки, фокусирующуюся на предоставлении улучшенной пропускной способности на основе детальной конфигурации программной архитектуры для оптимальной производительности в среде распределённых систем. Движение чейнкода (chaincode) между клиентом и сетью распределённых подтверждающих узлов, наряду с транзакционными механизмами и передачей свидетельств, удовлетворяющих политике подтверждения, реализовано в закрытой системе, тогда как gossip-протокол, распространяющий транзакции по приватным каналам, обеспечивает координирование крупных массивов данных. Хотя такая инфраструктура устойчива и действенна, необходимо уделить дополнительное внимание тому, как архитектура делает возможными многосторонние координационные структуры, где в конечном итоге в сети может оказаться множество каналов, которыми может быть сложно управлять.

Архитектура Hyperledger Fabric

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

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

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

Apache Kafka
Fabric действительно использует подструктуру реестрового типа, реализующую определённое хранение данных с хешированными связями, однако следует признать, что конфигурация хешей не наследует оригинальному архитектурному дизайну, связанному с блокчейновыми системами, производными от Bitcoin или Ethereum. Хотя блоки данных объединяются в пакеты и подвергаются событиям типа deliver для дальнейшего создания хешированной связи транзакций, необходимо понимать, что данный процесс не обязательно переводит данные в модификацию состояния системы. Скорее блоки конфигурированы так, что информация хранится в структуре типа базы данных с разными примерами хешей.

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

R3 Corda

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

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

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

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

Схема работы R3 Corda

Детали рисунка: Схема транзакций Corda, перемещения состояний входа и выхода в системе и добавления документов в процессе

Децентрализация Ethereum - миф или правда?Ethereum

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

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

Модифицированные архитектуры всё равно предусматривают согласованность с оригинальной EVM. В числе изменений в таких платформах, как Quorum, – изменение консенсусного механизма, модификация корней глобальных состояний для приспособления к частным и публичным состояниям, изменение префиксного дерева «Patricia» и дополнительные модули для управления приватными транзакциями. Архитектура позволяет этому ПО сохранить преемственность и структуры данных оригинальной конфигурации Ethereum, в то же время предлагая улучшенную транзакционную пропускную способность, возможную благодаря модификациям. В дополнение к предлагаемой Quorum оптимизации транзакций, возможность координирования и интеграции с публичной средой Ethereum посредством таких инструментов, как Plasma, TrueBit и Cosmos, даёт протоколу дополнительную широту

Из технической оценки таких инструментов, как Plasma и форматы достижения консенсуса в Casper, очевидно, что в Ethereum будут использоваться такие инструменты управления базами данных, как MapReduce и абстрактные системы переписывания. В Plasma MapReduce является неотъемлемой частью координирования учётной системы и структуры битовой карты UTXO в мультичейновой схеме.

Парадигма организованной обработки транзакций с использованием взаимодействия рутчейнов, Plasma-чейнов и чайлдчейнов посредством комбинации дизайнов механизмов с доказательством обмана и мотивационных структур на основе гарантийных обязательств помогает обеспечить динамику между поверхностями удержания блоков и массового выхода. Это также позволяет реализовать дополнительные криптоэкономические структуры, используя механизмы таких систем, как Casper или TrueBit, для отображения концепций удаляющего кодирования (erasure coding) в плане распространённой в данном пространстве проблемы доступности данных. Что касается мультичейновой архитектуры, то Ethereum должен быть способен комбинировать координирование баз данных и возможности пропускной способности распределённой системы баз данных с возможностями собственно блокчейна, совместимыми с публичной реализацией.

Координирование баз данных: заключение

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

Частные реализации Ethereum и дополнительные клиенты могут выступать архитектурными кирпичиками, на которых могут строиться более крупные системы на основе модульного дизайна, условно придерживающегося философии Unix. Связанные с Ethereum кодовые базы предназначены для того, чтобы составить конкуренцию возможностям по транзакционной пропускной способности таких платформ баз данных, как Fabric, в то же время делая возможным функционал, которого нет ни в Corda, ни в Fabric, хотя можно также исследовать комплементарные отношения между платформами. Главные отличительные качества может дополнительно прояснить анализ факторов, о котором мы поговорим в следующей части исследования.

На этом хотелось бы завершить первую часть статьи. Чтобы не пропустить продолжение, подписывайтесь на новости в telegram! Продолжение следует.

Источник: bitnovosti.com

Высказать свое мнение или задать вопрос по данной статье можно в общем чате
Так же заходите в чат посвященный Dex (Децентрализованным биржам)
Для удобства вы можете подписаться на наши новости в Telegram

 
ПОДЕЛИТЬСЯ:

ОСТАВЬТЕ ОТВЕТ

Введите ваш комментарий
Введите ваше имя