Блокчейн і технології розподіленого реєстру

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

Блокчейн Ethereum володіє як подібностями, так і відмінностями в порівнянні з такими технологіями розподіленого реєстру, як Hyperledger Fabric або R3 Corda. Для обґрунтованої оцінки блокчейнов і платформ розподіленого реєстру і їх цінності для підприємств корисно класифікувати платформи на підставі їх базового функціоналу і характеристик. Оскільки блокчейни побудовані на принципах криптографії та конфігурації даних, їхні функції можуть бути відтворені у координованих системах баз даних, тоді як інші можливі тільки в справжньому середовищі блокчейна.

Розмежування базових технологій

Зокрема, ми зосередимося на трьох ключових областях функціоналу:

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

Основні цілі блокчейна: чого бізнес хоче досягти за допомогою цієї технології?

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

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

Ефективна обробка і координування інформації

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

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

Початковий тезу про те, навіщо нам потрібні блокчейни, будувався на концепції дигіталізації довіри. Ендрю Кіс з ConsenSys просував наступний мотив: «Точно так само як інтернет привів до дигіталізації інформації, блокчейни ведуть до дигіталізації довіри і угод». Такий змістовний тезу уособлює ідеал того, чого сподіваються досягти блокчейни, в той же час готуючи грунт для подальшого шляху. Додатковою змінної можна вважати дигіталізацію вартості. Коли вартість прив’язана до довіри, впровадженому в систему, певні структури вирівнювання і механізми мотивації будуть стимулювати належну поведінку в системі, що призведе до життєздатної платформі.

Часто незмінюваність при проектуванні системи використовують синонімічно з довірою, т. Е. Якщо система незмінна, то можна довіряти, що погану поведінку не залишиться безкарним. Але в нашому аналізі платформних протоколів важливо також оцінити механізми реалізації довіреної системи, що забезпечують бізнес-модель, яка може бути вигідною для користувачів платформи (подальше дослідження за допомогою кріптоекономікі).

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

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

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

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

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

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

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

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

Координування даних: порівняння платформ

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

Архітектура Hyperledger 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

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, хоча можна також досліджувати комплементарні відносини між платформами. Головні чесноти може додатково прояснити аналіз чинників, про який ми поговоримо в наступній частині дослідження.

Переклад статті “Blockchain vs. Distributed Ledger Technologies“