Follow Us
Facebooktwitteryoutube
YouTube
Promo
banner
Promo
banner

Блокчейн срещу разпределени леджър технологии (DLT): Част 2

блог 1NewsDevelopersEnterpriseBlockchain ExplainedEvent and ConferencesPressБюлетини

Абонирайте се за нашия бюлетин.

Имейл адрес

Ние уважаваме вашата поверителност

HomeBlogEnterprise Blockchain

Блокчейн срещу разпределени леджър технологии (DLT): Част 2

Сравнителен анализ на архитектурите и управление на динамиката на Ethereum, Hyperledger Fabric и R3 Corda. От ConsenSys 23 май 2018 г. Публикувано на 23 май 2018 г.

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

Това е част 2 от сравнителен анализ на две части на Ethereum, Hyperledger Fabric и R3 Corda. Прочетете част 1 от Blockchain срещу DLT. 

Blockchain срещу разпределени Ledger технологични платформи

Трябва да се признае, че ако координацията на базата данни и по-ефективното разпределение на кода е желаната функционалност на системата, тогава блокчейнът не е задължително да бъде решението, за което търси организацията. Системите с разпределена книга (DLT), като Hyperledger Fabric или R3 Corda, са способни на подобни функции като системите на блокчейн, но трябва да се има предвид, че блокчейнът е отделна подгрупа от разпределени книги, които имат допълнителна функционалност извън координацията на кода. Blockchains са способни на функции, които разпределените книги не са от гледна точка на инстанциране на цифрова стойност въз основа на състава на системата.

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

Фигура 1 Важно е да се правят разграничения между технологичните стекове и как те се сравняват по отношение на функционалността и случаите на употреба Докато технологията на разпределената книга е била силно повлияна от технологията на блокчейн, ние трябва да разграничаваме архитектурните съображения на технологичните платформиВажно е да се правят разграничения между технологичните стекове и как се сравняват по отношение на функционалността и случаите на използване. Докато технологията на разпределената книга беше силно повлияна от технологията на блокчейн, ние трябва да разграничим архитектурните съображения на технологичните платформи.

Ще бъдат направени сравнения въз основа на няколко ключови отличителни характеристики, които съществуват в рамките на софтуерните платформи. Основните области, които ще бъдат разгледани в този документ, включват:

  • Щат: Състоянието се отнася до основната логическа единица, от която може да се състои кодът, за да се улесни представянето на информация в изчислителна среда. Докато състоянието може да има различни значения в различен контекст, използването на състояние в средата на блокчейн и разпределената книга се състои от текущата конфигурация на онтологичната характеристика на структурата от данни.
  • Транзакции: В рамките на блокчейн среда транзакциите се считат за изчислителни събития, които могат да доведат до генериране на състояние или държавни преходи, които се случват в екосистемата за развитие. Сделките могат да инициират договори или да се позовават на вече съществуващи договори.
  • Интелигентни договори: При оценката на блокчейн платформа от архитектурна гледна точка е важно да се определи структурата на кода на интелигентния договор и как той функционира спрямо действителната топология на блокчейн мрежата. Интелигентните договори се считат за отделни единици код, които изпълняват действия в рамките на екосистемата на платформата.

Следващата таблица показва кратък преглед на основните разлики между различните технологични характеристики на съответните платформи.

функции на платформатаПреглед на технологичните характеристики на Ethereum, Hyperledger Fabric и R3 Corda.

I. Държава

Ethereum


Като екосистема със споделени разпределени конфигурации, Ethereum създава концепцията за „състояние“ чрез конфигурация на обекти, наречена „Акаунти“. Има два вида акаунти в Ethereum:

  • Договорни сметки – сметки, контролирани от договорния код
  • Външно притежавани акаунти – акаунти, контролирани от частен ключ

Ethereum използва концепцията за World State, която представлява картографиране на адреси на акаунти и състояния на акаунти. State_Root е корен на дървото на Patricia Merkle от обединяването на акаунти в системата. И в рамките на сметките, състоянията на договора също са организирани в тази структура от данни на Patricia Merkle Tree. Коренният хеш на състоянието може да се използва за осигуряване на идентичността на данните в дървото merkle, позволявайки репликация в цялата мрежа, което в крайна сметка води до теоретичната неизменност на системата.

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

Коментар

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

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

Плат Hyperledger

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

  • LevelDB създава база данни ключ / стойност
  • CouchDB ще държи базата данни Document JSON

архитектура на платВ архитектурата Fabric форматът на базата данни за това как са организирани всички процеси е в състояние да увеличи обработката на транзакциите и да максимизира изчислителната ефективност в екосистемата.

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

Коментар

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

R3 Corda

В R3 Corda, държавата се основава на последователността и версирането на различни набори от данни в рамките на архитектурата на платформата. В системата Мрежата поддържа Сейф, който представлява база данни, която съхранява историческите състояния, които се проследяват в системата. В Corda се счита, че състоянието включва непрозрачни данни, които са сравними с дисков файл, който не е непременно актуализиран, макар и по-скоро използван за генериране на нови наследници. Тази система действа като поредица от модифицирани и възстановени актуализации на състоянието в среда, контролирана и споделяна от потребителите.

Фигура 5 Книгата се разглежда като набор от всички текущи състояния, които са активирани. Това заема от биткойн UTXO модела, макар и да не прилага същите характеристики за запазване на състоянието на Patricia Merkle Trees, които съществуват в блокчейн технологията, въпреки че по-скоро използва част от технологията в подраздели на платформата, за разлика от ядрото, докато състоянията действат като екземпляри на класове, съхранявани в хранилището, последователността и версирането на данните осигуряват жизнеспособно средство за съхраняване на даннитеКнигата се разглежда като набор от всички текущи състояния, които са активирани. Това заимства от биткойн UTXO модела, въпреки че не прилага същите характеристики за запазване на състоянието на Patricia Merkle Trees, които съществуват в блокчейн технологията, но по-скоро използва някои от технологиите в подраздели на платформата, за разлика от ядрото. Докато състоянията действат като екземпляри на класове, съхранявани в хранилището, последователността и версирането на данните осигуряват жизнеспособно средство за съхраняване на данните.

В Corda щатите се считат за класове, които съхраняват данни. Класовете са реализации на интерфейса “ContractState”, който действа като слой на оперативна съвместимост в рамките на платформата. Определените полета с данни „Държава“ могат да включват:

  • Издаване
  • Собственик
  • faceValue и Количество>
  • дата на падеж

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

Коментар

Тази архитектурна настройка може по същия начин да обработва споделени данни в полу-доверена среда, където контрагентите не трябва да се доверяват напълно един на друг. Данните могат да бъдат успешно обработени и добавени в това, което Corda счита за състояние, въпреки че на платформата липсват компонентите на блокчейн система, които могат да разкрият недвусмислена стойност. В Corda състоянието не е логическа конструкция, а по-скоро части от информация, добавени в книга, подобна на база данни. Докато активите могат да бъдат цифровизирани и съхранявани в изразходван и неизразходван държавен формат, активите няма да могат да бъдат отделни стойности, подобни на това как Bitcoin, Ethereum и токен икономиката създават нови пазари, въпреки че банковият софтуер може да бъде надежден настройка, която може да помогне да действа като център за атестиране на защитена непублична информация, подобно на това, което банковата система работи в момента.

II. Транзакции

Ethereum е машинна екосистема, базирана на транзакции, където глобалното състояние на транзакциите се съхранява в блоковете. Когато се случват транзакции, състоянието преминава в ново състояние на системата. Този процес жертва скоростта на бърза обработка на транзакции на база данни за целостта на система, която емблематизира състоянието, както и транзакцията, довела до това състояние в конфигурацията на структурата от данни на блокчейн Patricia Merkle Tree.

Фигура 6 В това състояние на архитектурата, заедно с транзакциите, които водят до преходи на състоянието, се запазват в софтуерна парадигма, която използва Patricia Merkle Trees за заключване на данни в историческа реалност, която се реализира в блоковетеВ рамките на тази архитектура състоянието, заедно с транзакциите, които водят до преходи на състоянието, се запазват в софтуерна парадигма, която използва Patricia Merkle Trees за заключване на данни в историческа реалност, която се реализира в блоковете.

Има два вида транзакции:

  • Обаждания за съобщения
  • Създаване на договори.

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

Коментар

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

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

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

Плат Hyperledger

Всички транзакции се изпълняват в многоканалната архитектура Fabric, за да се осигури висока пропускателна способност на транзакциите в доверената среда. Транзакциите се добавят към споделена книга, която съществува в средата на изпълнение. С тази архитектура Fabric позволява достъп за четене / запис и приспособимост към тяхната софтуерна среда, позволявайки подобна на мейнфрейм функционалност и използваемост. Известно е, че SQL базите данни са с няколко порядъка по-ефективни от която и да е налична в момента блокчейн, а конфигурацията на Fabric заимства много от парадигмите, използвани в традиционните инструменти за бази данни, позволяващи превъзходната пропускателна способност на транзакциите.

Има два вида транзакции:

  • Внедряване на транзакции – създайте нов верижен код. Инсталира верижен код в средата за разработка на софтуер
  • Invoke транзакции – извиква предварително създаден верижен код и съответните функции. Когато това се изпълни успешно, верижният код изпълнява функция и въвежда промени в състоянието
  • Функциите за извикване водят до транзакции „get“ или „set“

За да се постигне максимална ефективна обработка на данни и превъзходни скорости, отделните AKA blobs транзакции се групират от Apache Kafka Ordering Service и се извеждат като „блокове“ чрез събитие за доставка. Транзакциите (blobs) се подреждат от Службата за поръчки на Apache Kafka и се добавят към дяловете на Kafka. Това означава, че архитектурата Fabric жертва целостта и верността на данните на истинска блокчейн система, за да получи по-бърза обработка на транзакции и пропускателна способност в надеждна среда за поточно предаване на данни, както е видно от използването на услугата за поръчки на Apache Kafka.

Фигура 7 Както може да се оцени от документацията на Fabric, наредените транзакции се добавят директно към дяловете, свързани с темите на Kafka. Това води до транзакции с висока производителност, които се случват в надеждна среда за поточно предаване на данни Източник Apache KafkaКакто може да се оцени от документацията на Fabric, наредените транзакции се добавят директно към дяловете, свързани с темите на Kafka. Това води до транзакции с висока производителност, които се случват в надеждна среда за поточно предаване на данни. (Източник: Apache Kafka)

Коментар

Въпреки че системата използва терминология, приличаща на блокчейн, това не е блокчейн в традиционния смисъл, тъй като в структурата от данни на Patricia Merkle Tree няма запазване на състоянието и допълнителни транзакции. Hyperledger Fabric е DLT, а не блокчейн. Архитектурата на Fabric е проектирана за превъзходна обработка на транзакции, както се вижда от добавянето на петна от данни в услугата за нареждане на поточно предаване на данни на Kafka. Тъй като това се постига в надеждна среда, екзекуциите могат свободно да се случват в системата. Използването на тази конфигурация в система за трансфер на стойност не би било идеално, като се има предвид, че цялото доверие ще трябва да бъде приписано директно на една софтуерна архитектура от едно цяло, за разлика от споделена екосистема или протокол. Както се вижда от техническите документи, Fabric архитектурно се е отказал от целостта и сигурността на данните, постигнати в блокчейн платформите, за да постигне превъзходна обработка между компонентите на транзакцията.

R3 Corda

В R3 Corda транзакциите се считат за предложения за актуализиране на хранилището на базата данни, което може да се нарича книга. Сделките трябва да се извършват в среда, в която нотариусите могат да потвърдят, че не са изразходвани двойно и че са подписани от необходимите страни. Това е подобно на концепцията, използвана в биткойн екосистемата, въпреки че избягването на двойни разходи се улеснява от доверена система.

Има два основни типа транзакции:

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

крайно състояние

Транзакциите са предложени актуализации на състоянието на средата на базата данни, които изискват подписите да бъдат валидирани от други страни в системата. За да бъде транзакцията валидна, тя трябва:

  1. Да бъде подписан от участващите страни
  2. Потвърдете се от кода на договора, който определя транзакцията

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

Използването на модела, подобен на UTXO, в среда на споделена база данни позволява на платформата Corda да контролира състоянието, както и преходите. Използването на нотариуса и различни взаимодействия между потоци и 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, различни инстанции на Ethereum (публични, частни и консорциум) са способни на оперативна съвместимост, определена от общата компилация от езици на високо ниво – под формата на интелигентни договори – в байт код на Ethereum от EVM. От това разположение на Ethereum той е в състояние да действа като посреднически слой между различни аспекти на големи институционални съоръжения за частни данни и публичната икономика на цифровите стоки, която в момента се развива и идва в резултат от неотдавнашното създаване на символичната икономика.

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

Плат Hyperledger

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

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

Chaincode трябва да реализира интерфейси от API:

  • Chaincode интерфейс
  • ChaincodeStubInterface

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

Chaincode първоначално се инсталира на връстници, след което се инстанцира в канали. Процесът е подробно описан в следните диаграми:

По време на целия процес на верижен код възникват различни взаимодействия със системния верижен код, който се изпълнява в изпълним процес на връстници спрямо изолиран контейнер. Това се използва за реализиране на системно поведение без правила за одобрение или процеси на жизнен цикъл. Системният верижен код не преминава през жизнения цикъл на кода на нормалния верижен кодПо време на целия процес на верижен код възникват различни взаимодействия със системния верижен код, който се изпълнява в изпълнение на изпълним процес на равнопоставено устройство спрямо изолиран контейнер. Това се използва за внедряване на системно поведение без политики за одобрение или процеси на жизнен цикъл. Системният верижен код не преминава през жизнения цикъл на кода на нормалния верижен код. Внедряват се две функции от API на Shim на интерфейса на верижния код. Кодът се компилира и поддържа от партньорската верига. Кодът не е свързан с канали или поръчки, докато разработчикът не реши, че желае допълнително да инсталира програмата.Внедряват се две функции от API на Shim на интерфейса на верижния код. Кодът се компилира и поддържа от партньора. Chaincode не е свързан с канали или поръчватели, докато разработчикът не реши, че желае да инсталира допълнително програмата.

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

Коментар

Движението на Chaincode през тази мрежова конфигурация позволява рационализирана организация на системата. Софтуерната архитектура е подготвена да действа като много ефективна структура за управление и управление по отношение на разпространението на данни и организирането на среда за разработка на софтуер за определени случаи на използване в предприятието. Както може да се различи от пакета, инсталирането, екземпляра и настройката за надстройка, тази архитектура е създадена, за да оптимизира необходимите допирни точки, необходими за обработка на кода. Необходимите API интерфейси, когато транзакциите се обработват, напомнят силно на традиционния софтуерен дизайн. Области на бележка:

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

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

Когато Fabric печели във функционалност по отношение на своята система, която е донякъде емблематична за системи, проектирани около големи мейнфреймове и центрове за данни, тя губи в други аспекти по отношение на разпределената връзка с икономическите фактори на изчисленията, до които може да се стигне в присъщата децентрализирана цифрова токен икономика . Ако Fabric трябваше да се интегрира в истинска блокчейн среда, тя би се вписала добре като защитена среда на разпределена база данни, която проверява информацията преди взаимодействие с публична блокчейн екосистема.

R3 Corda

В Corda интелигентните договори се считат за класове, които прилагат интерфейса Contract. Интелигентните договори се пишат на Java / Kotlin и се компилират чрез Java Virtual Machine (JVM), която е изчислителната машина, в която се изпълнява кодът. Основната функция, използвана в договорите, е функцията „проверка“.

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

държавен обект

Компоненти за интелигентен договор:

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

Кодът на Java и Kotlin се компилира в идентичен байт код чрез JVM. Командите предават допълнителни данни, които не съществуват в щата, в кода на договора. Командите действат като структури от данни с прикачени публични ключове, използвани за подписване на транзакции, въпреки че трябва да се признае, че договорите не работят директно с цифровите подписи. Договорите в тази среда се възпроизвеждат в цялата система в контекста на това как Flows са готови да координират между доверени страни.

Коментар

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

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

Въз основа на нашия анализ, ключовите отличителни фактори, които Ethereum е в състояние да внедри извън възможностите на DLT, са:

  • Икономика на цифрови активи или символи
  • Криптоикономически стимулиращи слоеве в протокола
  • Оперативна съвместимост между консорциум и публични блокчейни

Докато DLT като R3 Corda и Hyperledger Fabric са в състояние да постигнат функционалност на споделеното управление на базата данни и жизнения цикъл на обработка на транзакции, не е гарантирано, че те ще могат да постигнат ключовите функции, както е описано по-горе. Тези платформи не са дефектни, а по-скоро ограничени в своята архитектурна конфигурация, за да покажат някои от чистите случаи на употреба, които само истинските блокчейн могат да отстояват.

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

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

Свържете се с нашите експерти по блокчейн

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

Пълно ръководство за бизнес мрежи на Blockchain

Въведение в токенизациятаУебинар

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

Бъдещето на финансите Digital Assets и DeFiУебинар

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

Какво е Enterprise EthereumУебинар

Какво е Enterprise Ethereum?

Централни банки и бъдещето на паритеБяла хартия

Централни банки и бъдещето на парите

Komgo Blockchain за търговия със стокиДело Stud

Komgo: Блокчейн за търговия със стоки

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Adblock
detector