blog 1AktualnościDevelopersEnterpriseBlockchain ExplainedWydarzenia i konferencjePrasaBiuletyny

Zapisz się do naszego newslettera.

Adres e-mail

Szanujemy twoją prywatność

HomeBlogEnterprise Blockchain

Blockchain vs. Distributed Ledger Technologies (DLT): Część 2

Analiza porównawcza architektur i rządzącej dynamiki Ethereum, Hyperledger Fabric i R3 Corda. Autorstwa ConsenSys 23 maja 2018 Opublikowane 23 maja 2018

blockchain dlt 2 hero

To jest część 2 dwuczęściowej analizy porównawczej Ethereum, Hyperledger Fabric i R3 Corda. Przeczytaj część 1 relacji Blockchain kontra DLT. 

Platformy technologiczne Blockchain vs. Distributed Ledger

Należy przyznać, że jeśli koordynacja bazy danych i wydajniejsza alokacja kodu jest pożądaną funkcjonalnością systemu, to blockchain niekoniecznie musi być rozwiązaniem, którego szuka organizacja. Systemy z technologią rozproszonej księgi (DLT), takie jak Hyperledger Fabric lub R3 Corda, mogą mieć podobne funkcje jak systemy blockchain, ale należy wziąć pod uwagę, że łańcuchy bloków są oddzielnym podzbiorem rozproszonych rejestrów, które mają dodatkową funkcjonalność poza koordynacją kodu. Blockchainy są zdolne do wykonywania funkcji, których rozproszone księgi nie są w zakresie tworzenia instancji wartości cyfrowej w oparciu o skład systemu.

W tym dokumencie zostaną zbadane kwestie architektoniczne, które identyfikują aspekty, które przyczyniają się do funkcjonalności łańcucha bloków. Badanie polegałoby na tym, że być może istnieje kompromis między tym, co są w stanie osiągnąć łańcuchy bloków, a tym, co zapewnia DLT. DLT było przeznaczone do przetwarzania transakcji we współdzielonym zaufanym środowisku, podczas gdy prawdziwe łańcuchy bloków zostały zaprojektowane tak, aby poświęcić potrzebę zaufanej konfiguracji w celu osiągnięcia wysokiej wierności i niezmienności kont. Aspekty wysokiej wierności i niezmienności są integralną częścią sukcesu prawidłowej digitalizacji zasobów. Analiza z tego dokumentu nakłada komponenty architektoniczne na procesy biznesowe w celu dalszego wyjaśnienia tych niuansów technologicznych na różnych platformach.

Rysunek 1 Ważne jest, aby dokonać rozróżnienia między stosami technologii i ich porównaniem pod względem funkcjonalności i przypadków użycia Podczas gdy technologia blockchain miała duży wpływ na technologię rozproszonej księgi, należy rozróżnić kwestie architektoniczne dotyczące platformWażne jest, aby rozróżnić stosy technologii i ich porównanie pod względem funkcjonalności i przypadków użycia. Chociaż na technologię rozproszonych ksiąg rachunkowych duży wpływ miała technologia blockchain, powinniśmy rozróżnić architektoniczne uwarunkowania platform technologicznych.

Porównania będą dokonywane w oparciu o kilka kluczowych wyróżniających cech istniejących w platformach oprogramowania. Główne obszary, które zostaną omówione w tym dokumencie, obejmują:

  • Stan: Stan odnosi się do głównej jednostki logicznej, z której może się składać kod w celu ułatwienia reprezentacji informacji w środowisku obliczeniowym. Chociaż stan może mieć różne znaczenia w różnych kontekstach, użycie stanu w środowisku blockchain i rozproszonej księgi składa się z bieżącej konfiguracji cech ontologicznych struktury danych.
  • Transakcje: W środowisku blockchain transakcje są uważane za zdarzenia obliczeniowe, które mogą prowadzić do generowania stanów lub przejść stanów, które mają miejsce w ekosystemie programistycznym. Transakcje mogą inicjować kontrakty lub odwoływać się do wcześniej istniejących kontraktów.
  • Inteligentne kontrakty: Oceniając platformę blockchain z perspektywy architektonicznej, ważne jest, aby określić strukturę kodu inteligentnego kontraktu i jak on działa w odniesieniu do faktycznej topologii sieci blockchain. Inteligentne kontrakty są uważane za poszczególne jednostki kodu, które wykonują działania w ekosystemie platformy.

Poniższa tabela przedstawia krótki przegląd głównych różnic między różnymi cechami technologicznymi odpowiednich platform.

funkcje platformyPrzegląd cech technologicznych Ethereum, Hyperledger Fabric i R3 Corda.

Oświadczam

Ethereum


Jako ekosystem ze współdzielonymi konfiguracjami rozproszonymi, Ethereum tworzy instancję pojęcia „stanu” poprzez konfigurację obiektów zwanych „kontami”. W Ethereum istnieją dwa rodzaje kont:

  • Konta kontraktowe – konta kontrolowane kodem kontraktu
  • Konta posiadane zewnętrznie – konta kontrolowane za pomocą klucza prywatnego

Ethereum wykorzystuje koncepcję stanu świata, która polega na mapowaniu adresów i stanów kont. State_Root to katalog główny Patricia Merkle Tree, będący połączeniem kont w systemie. W ramach kont, stany kontraktów są również zorganizowane w tej strukturze danych Patricia Merkle Tree. Skrót główny stanu można wykorzystać do zabezpieczenia tożsamości danych w drzewie Merkle, umożliwiając replikację w całej sieci, co ostatecznie skutkuje teoretyczną niezmiennością systemu.

Prawdziwe łańcuchy bloków różnią się od DLT na podstawie ich polegania na tej strukturze danych Patricia Merkle Tree i ich orkiestracji między blokami, które są używane do tworzenia instancji stanu systemu.Ta koncepcja jest integralna dla poprawności integralności danych i wierności architektury systemu blockchainPrawdziwe łańcuchy bloków różnią się od DLT na podstawie ich polegania na strukturze danych Patricia Merkle Tree i ich orkiestracji między blokami, która służy do tworzenia instancji stanu systemu. Ta koncepcja jest integralną częścią integralności danych, ważności i wierności architektury systemu blockchain.

Komentarz

Funkcjonalność, którą tworzy Ethereum World State, to system bez zaufania, który umożliwia tworzenie wartości w formacie cyfrowym. Źródła cyfrowej wartości reprezentacyjnej, która jest natywna dla gospodarki tokenów, można uzyskać ze składu kont i struktur danych podrzędnych Ethereum; w ten sam sposób, w jaki bramki logiczne są w stanie tworzyć instancje algorytmów funkcjonalnych w tradycyjnej inżynierii.

Platformy wywodzące się z Ethereum, w tym klienci Ethereum i prywatne implementacje, są w stanie czerpać korzyści z tego określenia wartości przez przekonania o tych standardach w odniesieniu do zachowania stanu i implementacji logiki. Platformy, które nie utworzą instancji jednej z tych funkcji opartych na wartości logicznej, nie będą w stanie ułatwić tworzenia prawdziwych zdecentralizowanych wartości aktywów cyfrowych.

Tkanina Hyperledger

W Hyperledger Fabric stan jest zachowywany w strukturze bazy danych z zależnością od magazynów kluczy / wartości dla stanu. Interakcja między programami Chaincode i sposób ich instalacji w topologii platformy umożliwia wydawanie poleceń i działań w systemie. Te akcje powodują aktualizacje magazynów danych, ponieważ transakcje skutkują aktualizacjami stanu znanego jako księga. Księga została sformułowana jako współużytkowana rozproszona baza danych, która zapewnia użytkownikom lepszy dostęp do informacji i transakcji, które mają miejsce w rozproszonym środowisku komputerowym. Stan jest zagnieżdżony w środowisku bazy danych za pośrednictwem tradycyjnych narzędzi programistycznych:

  • LevelDB tworzy bazę danych kluczy / wartości
  • CouchDB będzie przechowywać bazę danych Document JSON

architektura tkaninyW architekturze Fabric format bazy danych przedstawiający sposób organizacji wszystkich procesów może zwiększyć przetwarzanie transakcji i zmaksymalizować wydajność obliczeniową w ekosystemie.

W bazie danych stanu najnowsze wartości wersji kluczy w dzienniku transakcji łańcuchowych są przechowywane jako pary klucz / wartość. Kluczowe wartości znane jako stan świata są indeksowane w celu wyświetlenia w dziennikach transakcji, które istnieją w architekturze kanału. CouchDB działa jako oddzielny proces bazy danych, który otrzymuje aktualizacje z interfejsów API z kodem łańcucha.

Komentarz

Hyperledger Fabric stworzył proces, który zastępuje kluczowe założenia systemu blockchain w zamian za osiągnięcie wysokiej przepustowości przejść między stanami. Zastosowanie obecnej architektury pozwala na łatwiejszą modyfikację stanów i ich manifestację w ramach tradycyjnego schematu oprogramowania, co skutkuje dostępem do odczytu / zapisu. Chociaż układ stanu w środowisku Fabric jest wydajny, brakuje mu możliwości tworzenia instancji wartości w publicznym zdecentralizowanym ekosystemie, w taki sam sposób, w jaki mógłby to zrobić prawdziwy łańcuch bloków, taki jak Ethereum lub Bitcoin. Ruch danych w środowisku oprogramowania Fabric wskazuje na możliwości rozproszonej bazy danych. Tworzenie zasobów cyfrowych w Fabric byłoby zasadniczo informacją cyfrową przechowywaną w bazie danych, która jest kontrolowana przez strony kontrolujące lub grupy w ramach konsorcjum, bez przestrzegania struktury ekonomicznej dóbr cyfrowych.

R3 Corda

W R3 Corda State opiera się na sekwencjonowaniu i wersjonowaniu różnych zestawów danych w architekturze platformy. W systemie sieć utrzymuje repozytorium, czyli bazę danych przechowującą historyczne stany śledzone w systemie. W Corda stan uważa się za obejmujący nieprzezroczyste dane, które są porównywalne z plikiem na dysku, który niekoniecznie jest aktualizowany, ale jest raczej używany do generowania nowych następców. Ten system działa jako seria zmodyfikowanych i ponownie wprowadzonych aktualizacji stanu w środowisku kontrolowanym i udostępnianym przez użytkowników.

Rysunek 5 Księga jest uważana za zbiór wszystkich bieżących stanów, które są aktywowane. Zapożycza się z modelu bitcoin UTXO, chociaż nie implementuje tych samych właściwości zachowania stanu, co Patricia Merkle Trees, które istnieją w technologii blockchain, chociaż raczej wykorzystuje część technologii w podsekcje platformy w przeciwieństwie do rdzenia Podczas gdy stany działają jako instancje klas przechowywanych w skarbcu, sekwencjonowanie i wersjonowanie danych zapewnia realne środki do przechowywania danychKsięga jest uważana za zbiór wszystkich bieżących stanów, które są aktywowane. To zapożycza się z modelu bitcoin UTXO, chociaż nie implementuje tych samych właściwości zachowania stanu co Patricia Merkle Trees, które istnieją w technologii blockchain, chociaż raczej wykorzystuje część technologii w podsekcjach platformy, w przeciwieństwie do rdzenia. Podczas gdy stany działają jako instancje klas przechowywanych w skarbcu, sekwencjonowanie i wersjonowanie danych zapewniają realne środki do przechowywania danych.

W Korda stany są uważane za klasy przechowujące dane. Klasy są implementacjami interfejsu „ContractState”, który działa jako warstwa interoperacyjności w ramach platformy. Niektóre pola danych „Stan” mogą obejmować:

  • Wydanie
  • Właściciel
  • faceValue and Amount>
  • Data waznosci

Format tego projektu miał umożliwić dołączanie danych w łańcuchu zdarzeń, umożliwiając śledzenie pochodzenia danych w kontrolowanym środowisku. Pochodzenie jest kontrolowane przez członków konsorcjum, którzy mają pewną kontrolę dostępu do platformy oprogramowania. Korzystając z tej konfiguracji, banki i instytucje finansowe będą w stanie zmaksymalizować wydajność w zakresie przetwarzania informacji we wspólnym ekosystemie księgi. Dane można lepiej przenosić i przetwarzać między organizacjami, jednocześnie zmniejszając potrzebę zaufania między niezaufanymi kontrahentami.

Komentarz

Ta konfiguracja architektoniczna jest podobnie w stanie przetwarzać udostępnione dane w częściowo zaufanym środowisku, w którym kontrahenci nie muszą w pełni sobie ufać. Dane mogą być z powodzeniem przetwarzane i dołączane do tego, co Corda uważa za stan, chociaż na platformie brakuje elementów systemu blockchain, które mogą ujawniać jednoznaczną wartość. W Korda stan nie jest konstrukcją logiczną, ale raczej fragmentami informacji dołączanymi do księgi podobnej do bazy danych. Chociaż aktywa można zdigitalizować i przechowywać w formacie stanu wydanego i niewydanego, aktywa nie będą mogły być odrębnymi jednostkami wartości podobnymi do tego, w jaki sposób Bitcoin, Ethereum i gospodarka tokenów tworzą nowe rynki, chociaż oprogramowanie bankowe może być godne zaufania konfiguracja, która może pomóc działać jako centrum poświadczania bezpiecznych informacji niepublicznych, podobnie jak obecnie działa system bankowy.

II. Transakcje

Ethereum to ekosystem maszynowy oparty na transakcjach, w którym globalny stan transakcji jest przechowywany w blokach. Kiedy dochodzi do transakcji, przejścia stanów prowadzą do nowych stanów systemu. Ten proces poświęca szybkość szybkiego przetwarzania transakcji w bazie danych dla integralności systemu, który emblematuje stan, a także transakcję, która doprowadziła do tego stanu w ramach konfiguracji struktury danych w łańcuchu bloków Patricia Merkle Tree.

Rysunek 6 W tej architekturze stan wraz z transakcjami prowadzącymi do przejść między stanami są zachowane w paradygmacie oprogramowania, który wykorzystuje Patricia Merkle Trees do blokowania danych w rzeczywistości historycznej realizowanej w blokachW ramach tej architektury stan wraz z transakcjami prowadzącymi do przejść między stanami są zachowane w paradygmacie oprogramowania, który wykorzystuje Patricia Merkle Trees do blokowania danych w rzeczywistości historycznej realizowanej w blokach.

Istnieją dwa rodzaje transakcji:

  • Połączenia wiadomości
  • Kreacje kontraktowe.

Transakcje zawierają wewnętrzny mechanizm transferu wartości. Przeniesienie wartości w ramach kont kontraktowych powoduje zmianę stanu. Ponieważ system opiera się na transferze wartości między inteligentnymi kontraktami, które istnieją między zdarzeniami wykonania transakcji, różne podzielone na segmenty stany mogą służyć do tworzenia instancji logiki biznesowej i umów o wysokiej wierności.

Komentarz

Kluczową cechą wyróżniającą Ethereum jest to, że transakcje są używane jako indywidualne jednostki procesu w środowisku blockchain Ethereum, a dzięki tej konfiguracji przechowują trwały zapis stanów transakcji w systemie. Ethereum jest w stanie wykorzystać zarówno tradycyjne możliwości technologiczne związane z bazą danych księgi rozproszonej, jak i połączyć pożądane zaufanie z wartością cyfrową. Technologie wywodzące się z łańcucha bloków Ethereum są w stanie grupować transakcje i logikę biznesową w bloki łańcucha blokowego. Funkcje biznesowe pochodzące z tej konfiguracji obejmują:

  • Prawdziwa gospodarka cyfrowa
  • Towary i aktywa cyfrowe kontrolowane przez zachęty ekonomiczne w przeciwieństwie do zachęt organizacyjnych / monopolistycznych
  • Interfejs interakcji między instytucjami prywatnymi a publiczną gospodarką cyfrową

Architektura Ethereum umożliwia powiązanym platformom tworzenie instancji kryptoekonomicznych warstw motywacyjnych w systemie. Oznacza to, że można tworzyć różne warstwy motywacyjne i projekty mechanizmów, aby zabezpieczyć całą sieć, w przeciwieństwie do korzystania z centralnie sterowanych usług świadczonych przez tradycyjne projekty oprogramowania. Ta kryptoekonomiczna warstwa motywacyjna może być zastosowana zarówno do gospodarki dóbr cyfrowych, jak i warstwy interfejsu między prywatną i publiczną wersją platformy blockchain.

Tkanina Hyperledger

Wszystkie transakcje są wykonywane w wielokanałowej architekturze Fabric, aby zapewnić wysoką przepustowość transakcji w zaufanym środowisku. Transakcje są dołączane do udostępnionej księgi, która istnieje w środowisku wykonawczym. Dzięki tej architekturze Fabric zapewnia dostęp do odczytu / zapisu i możliwość korzystania ze środowiska oprogramowania, zapewniając funkcjonalność i użyteczność podobną do komputerów mainframe. Wiadomo, że bazy danych SQL są o kilka rzędów wielkości bardziej wydajne niż jakikolwiek obecnie dostępny łańcuch bloków, a konfiguracja Fabric zapożycza wiele z paradygmatów stosowanych w tradycyjnych narzędziach bazodanowych, co pozwala na lepszą przepustowość transakcji.

Istnieją dwa rodzaje transakcji:

  • Wdrażaj transakcje – utwórz nowy kod łańcucha. Instaluje kod łańcucha w środowisku programistycznym
  • Wywołaj transakcje – wywołuje wcześniej utworzony kod łańcucha i odpowiadające mu funkcje. Po pomyślnym wykonaniu kod łańcucha spełnia funkcję i wprowadza zmiany do stanu
  • Wywołanie funkcji powoduje „pobranie” lub „ustawienie” transakcji

Aby zmaksymalizować wydajne przetwarzanie danych i najwyższą prędkość, poszczególne transakcje typu blob AKA są grupowane przez usługę zamawiania Apache Kafka i wysyłane jako „bloki” za pośrednictwem zdarzenia dostawy. Transakcje (obiekty blob) są porządkowane przez usługę zamawiania Apache Kafka i dołączane do partycji platformy Kafka. Oznacza to, że architektura Fabric poświęca integralność i wierność danych prawdziwego systemu blockchain w celu uzyskania szybszego przetwarzania transakcji i przepustowości w zaufanym środowisku przesyłania strumieniowego danych, co wynika z korzystania z usługi zamawiania Apache Kafka..

Rysunek 7 Jak można ocenić na podstawie dokumentacji Fabric, zamówione transakcje są bezpośrednio dołączane do partycji powiązanych z tematami Kafka. Powoduje to transakcje o wysokiej przepustowości, które występują w zaufanym środowisku strumieniowego przesyłania danych. Źródło Apache KafkaJak można ocenić na podstawie dokumentacji Fabric, zamówione transakcje są bezpośrednio dołączane do partycji powiązanych z tematami Kafki. Powoduje to transakcje o wysokiej przepustowości, które występują w zaufanym środowisku przesyłania strumieniowego danych. (Źródło: Apache Kafka)

Komentarz

Chociaż system wykorzystuje terminologię typu blockchain, nie jest to łańcuch blokowy w tradycyjnym sensie, ponieważ w strukturze danych Patricia Merkle Tree nie ma zachowania stanu i transakcji uzupełniających. Hyperledger Fabric to DLT, a nie blockchain. Architektura Fabric została zaprojektowana z myślą o lepszym przetwarzaniu transakcji, co widać po dołączaniu obiektów blob do usługi zamawiania strumieniowego przesyłania danych Kafka. Ponieważ osiąga się to w zaufanym środowisku, wykonywanie może odbywać się swobodnie w systemie. Zastosowanie tej konfiguracji w systemie transferu wartości nie byłoby idealne, biorąc pod uwagę, że całe zaufanie musiałoby być przypisane bezpośrednio do jednej architektury oprogramowania z jednej jednostki, w przeciwieństwie do wspólnego ekosystemu lub protokołu. Jak widać z dokumentów technicznych, Fabric zrezygnował architektonicznie z integralności danych i bezpieczeństwa osiągniętego na platformach blockchain, aby uzyskać lepsze przetwarzanie między komponentami transakcji.

R3 Corda

W R3 Corda transakcje są traktowane jako propozycje aktualizacji bazy danych Vault, którą można nazwać księgą. Transakcje muszą być przeprowadzane w środowisku, w którym notariusze mogą potwierdzić, że nie są one podwójnie wydawane i że są podpisane przez niezbędne strony. Jest to podobne do koncepcji używanej w ekosystemie bitcoinów, chociaż unikanie podwójnych wydatków jest ułatwione dzięki zaufanemu systemowi.

Istnieją dwa podstawowe typy transakcji:

  • Transakcje zmiany notarialnej – są wykonywane w celu przechodzenia między notariuszami w systemie. Notariusze będą zapobiegać podwójnemu wydatkowaniu i mogą weryfikować transakcje
  • Zapewnij konsensus dotyczący wyjątkowości
  • Transakcje ogólne – używane do wszystkiego innego

stan końcowy

Transakcje są proponowanymi aktualizacjami stanu środowiska bazy danych, które wymagają weryfikacji podpisów innych stron w systemie. Aby transakcja była ważna, musi:

  1. Być podpisane przez zaangażowane strony
  2. Uzyskaj walidację za pomocą kodu umowy, który określa transakcję

architektura klienta

Zastosowanie modelu podobnego do UTXO w środowisku współdzielonej bazy danych pozwala platformie Corda na kontrolowanie stanu oraz przejść. Korzystanie z Notariusza i różne interakcje między przepływami i Cordapps w konfiguracji sieci pokazują współdzielone rozproszone środowisko, w którym stan jest zachowywany w formacie danych integralnym z architekturą systemu. Wykorzystanie transakcji do poruszania się po instancjach stanów w środowisku opartym na węzłach między przepływami, a także Cordapps, które są programowane w węzłach, wskazuje realne środki do wykonywania zmian stanu w księdze.

Komentarz

Tworząc zasoby cyfrowe, użytkownicy i kontrahenci zależą od zaufania całej platformy Corda. Działając jako silny, zaufany, współdzielony rozproszony system księgowy do przechowywania wrażliwych danych finansowych, system działa zgodnie z różnymi standardami istniejącymi w ekosystemie bankowym. Platforma zapewnia:

  • Doskonałe przechowywanie niepublicznych danych finansowych
  • Zaufana konfiguracja dla niezaufanych instytucji finansowych
  • Zaawansowane przechowywanie interakcji biznesowych

Diagramy architektoniczne obejmujące przepływy i środowiska wykonawcze między węzłami pokazują, że Corda została zaprojektowana w celu podzielenia dostępu między zaufanymi członkami platformy konsorcjum. Chociaż R3 Corda jest zdolny do pewnych aspektów użyteczności, nie ma funkcjonalności, która jest nieodłącznym elementem tego, że jest uniwersalnym podłożem dla ekonomicznego, społecznego i politycznego transferu wartości, ze względu na brak kryptoekonomicznej warstwy motywacyjnej, a także publicznego środowiska zasobów cyfrowych. Ponieważ system jest zamknięty, brakuje mu szyn i cech technologicznych niezbędnych do zbudowania wokół ekosystemu opartego na bodźcach ekonomicznych. R3 Corda jest najprawdopodobniej najlepiej używany do niektórych aspektów tradycyjnej infrastruktury bankowej, ale nie do tworzenia aktywów cyfrowych.

III. Inteligentne kontrakty

Ethereum

W Ethereum inteligentne kontrakty są pisane w językach programowania wysokiego poziomu, takich jak solidity, LLL lub Viper i kompilowane do kodu bajtowego EVM, umożliwiając wykonywanie plików binarnych przez maszynę wirtualną Ethereum (EVM). Węzły w sieci Ethereum uruchamiają własną implementację EVM, która działa jako środowisko wykonawcze dla inteligentnych kontraktów w ekosystemie Ethereum. Stan i transakcje prowadzące do przejścia między stanami są symbolizowane w światowy stan łańcucha blokowego Ethereum poprzez replikację przez EVM, co skutkuje systemem, który może wdrożyć nieprzekupne zaufanie w szeregu widm.

EVM 1

EVM działa jako środowisko uruchomieniowe do rekurencyjnego wykonywania przejść stanu w celu obliczenia stanu systemu i stanu maszyny w trakcie pętli transakcji.

  • Stan systemu = stan globalny Ethereum
  • Stan maszyny = logika biznesowa kont kontraktowych & kod replikowany w środowisku wykonawczym EVM

Ponieważ cały kod inteligentnego kontraktu jest replikowany przez wszystkie węzły w EVM, łańcuch bloków Ethereum i powiązane instancje są w stanie zachować ważność kodu, aby zapewnić spójność kontraktów. Spójność umów przyczynia się do praktycznej niezmienności łańcucha blokowego Ethereum i powiązanych z nim klientów oraz wdrożeń. Inteligentne kontrakty w Ethereum wiążą ze sobą cały ekosystem poprzez tworzenie instancji transakcji, które ostatecznie skutkują przejściem do nowych stanów w całym środowisku maszyny wirtualnej.

Komentarz

Ponieważ implementacje EVM są ściśle zgodne ze specyfikacjami określonymi w żółtej księdze Ethereum, różne instancje Ethereum (publiczne, prywatne i konsorcjum) są zdolne do interoperacyjności, jak określono na podstawie wspólnej kompilacji języków wysokiego poziomu – w postaci inteligentnych kontrakty – do kodu bajtowego Ethereum przez EVM. Dzięki tej dyspozycji Ethereum jest w stanie działać jako warstwa pośrednicząca między różnymi aspektami dużych instytucjonalnych prywatnych obiektów danych a publiczną gospodarką dóbr cyfrowych, która obecnie ewoluuje i zaczyna przynosić efekty dzięki niedawnemu utworzeniu gospodarki tokenów.

Umożliwiając tę ​​funkcjonalność między łańcuchami Ethereum, można budować całe interoperacyjne systemy, które przypisują ekonomiczną ostateczność między systemami koordynacji i przetwarzania danych na prywatnych platformach Ethereum na towary cyfrowe w łańcuchu publicznym. Inteligentne kontrakty w Ethereum obejmują programowalną logikę w tych systemach i umożliwiają programistom interakcję z maszyną wirtualną Ethereum poprzez transakcje, które tworzą nowe środowiska stanowe w ramach infrastruktury technologicznej. W miarę rozwoju wszechstronnych przypadków użycia w ramach interoperacyjnych środowisk łańcucha publicznego, łańcucha prywatnego i łańcucha konsorcjum, inteligentne kontrakty używane w Ethereum będą mogły łączyć systemy w ramach wspólnego logicznego interfejsu.

Tkanina Hyperledger

Chaincode niekoniecznie jest inteligentną umową wdrożoną w łańcuchu blokowym opartym na kontach, ale raczej programem, który jest instalowany, a następnie implementuje interfejs za pośrednictwem interfejsu API. Interfejs API wymaga instrukcji opartych na kodzie, aby kierować logiką biznesową i funkcjonalnością w całym systemie, podobnie jak w tradycyjnym środowisku programistycznym. Metody powiązane z API obejmują:

  • Init – inicjacja stanów aplikacji
  • Invoke – przetwarzanie propozycji transakcji

Chaincode musi implementować interfejsy z API:

  • Interfejs z kodem łańcucha
  • ChaincodeStubInterface

W Hyperledger Fabric kod łańcucha jest uruchamiany w zabezpieczonych kontenerach Docker, gdzie jest izolowany od procesów wykonywanych przez zatwierdzającego partnera. Kod jest zwykle napisany w Go lub Node.js, co umożliwia interakcję obsługującą logikę biznesową. Niuansem, o którym należy pamiętać, jest to, że kod łańcucha Fabric nie jest replikowany przez węzły w ekosystemie w taki sam sposób, jak oczekuje się go od prawdziwej architektury blockchain.

Chaincode jest początkowo instalowany na peerach, a następnie tworzony w kanałach. Przebieg procesu jest szczegółowo przedstawiony na poniższych diagramach:

W całym przebiegu procesu Chaincode zachodzą różne interakcje z kodem łańcuchowym systemu, który działa w ramach wykonywalnego procesu równorzędnego w porównaniu z izolowanym kontenerem. Służy do implementacji zachowań systemu bez zasad poparcia lub procesów cyklu życia Kod łańcucha systemu nie przechodzi przez cykl życia normalnego kodu łańcuchaW całym przebiegu procesu Chaincode zachodzą różne interakcje z kodem łańcucha systemu, który działa w ramach wykonywalnego procesu równorzędnego, a nie w izolowanym kontenerze. Służy do wdrażania zachowań systemowych bez zasad zatwierdzania lub procesów cyklu życia. System Chaincode nie przechodzi przez cykl życia normalnego Chaincode. Wdrożenie dwóch funkcji z Shim API interfejsu chaincode Kod jest kompilowany i utrzymywany przez równorzędnego Chaincode nie jest powiązany z kanałami ani zleceniodawcami dopóki programista nie ustali, że chcą dalej instalować programZaimplementowano dwie funkcje z Shim API interfejsu łańcucha. Kod jest kompilowany i obsługiwany przez partnera. Chaincode nie jest powiązany z kanałami ani zleceniodawcami, dopóki programista nie ustali, że chcą dalej instalować program.

Chaincode można skonfigurować w celu tworzenia zasobów, które ostatecznie działają jako pary klucz-wartość, które są przechowywane w bazie danych księgi. Przebieg wysyłania poleceń inicjujących i wywoływania transakcji jest szczegółowo przedstawiony na powyższym schemacie pod kątem sposobu, w jaki polecenia są przenoszone w systemie. Logika biznesowa jest kodowana w ramach reguł sieci i wywoływana przez aplikacje po stronie klienta. Rodzaj koordynacji kodu i interakcji bardzo wskazuje na tradycyjny rozwój oprogramowania poprzez poleganie na tradycyjnych funkcjach i interfejsach inicjacji.

Komentarz

Przenoszenie Chaincode przez tę konfigurację sieci pozwala na sprawną organizację systemu. Architektura oprogramowania jest przygotowana do działania jako bardzo wydajna struktura dowodzenia i kontroli w zakresie dystrybucji danych i organizowania środowiska programistycznego dla określonych przypadków użycia w przedsiębiorstwie. Jak można wywnioskować z pakietu, instalacji, tworzenia instancji i aktualizacji, ta architektura została zaprojektowana w celu optymalizacji niezbędnych punktów styku wymaganych do przetwarzania kodu. Niezbędne interfejsy API podczas przetwarzania transakcji bardzo przypominają tradycyjny projekt oprogramowania. Obszary warte uwagi:

  • Architektura monolityczna zapewniająca maksymalną kontrolę
  • Zabezpieczona interakcja biznesowa między kontrahentami
  • Centralnie koordynowane przetwarzanie przepustowości transakcji

Chaincode jest bardziej systemem poleceń niż inteligentnym językiem kontraktowym, który jest replikowany przez łańcuch bloków. Ponieważ ekosystem Hyperledger Fabric ma żywy zestaw silnych cech pod względem funkcjonalności i projektu jako rozproszona księga, w rzeczywistości systemowi brakuje wrodzonych właściwości prawdziwego systemu blockchain. Jako narzędzie, które można wykorzystać do integracji ze starszą infrastrukturą i paradygmatami, Fabric jest skuteczny dzięki zgodności z wcześniej istniejącymi standardami oprogramowania, co można wywnioskować z projektu architektonicznego opisanego powyżej.

Tam, gdzie Fabric zyskuje na funkcjonalności pod względem swojego systemu, który jest w pewnym stopniu charakterystyczny dla systemów zaprojektowanych wokół dużych komputerów typu mainframe i centrów danych, traci w innych aspektach pod względem rozproszonego połączenia z ekonomicznymi czynnikami obliczeniowymi, do których można uzyskać dostęp w z natury zdecentralizowanej gospodarce tokenami cyfrowymi . Gdyby Fabric miał zintegrować się z prawdziwym środowiskiem blockchain, pasowałby dobrze jako bezpieczne środowisko rozproszonej bazy danych, które weryfikuje informacje przed interakcją z publicznym ekosystemem blockchain.

R3 Corda

W programie Corda kontrakty inteligentne są uznawane za klasy, które implementują interfejs kontraktu. Inteligentne kontrakty są napisane w języku Java / Kotlin i są kompilowane za pośrednictwem wirtualnej maszyny języka Java (JVM), która jest maszyną obliczeniową, na której wykonywany jest kod. Główną funkcją używaną w kontraktach jest funkcja „weryfikacji”.

Kod działa w JVM, gdzie transakcje są przetwarzane przez system notarialny, a logika biznesowa jest ograniczona w przepływach, które mogą pomieścić i izolować proces biznesowy między różnymi kontrahentami.

obiekt stanu

Elementy inteligentnego kontraktu:

  • Kod wykonywalny
  • Weryfikuje zmiany w transakcjach
  • State Objects
  • Dane przechowywane w księdze
  • Aktualny stan umowy
  • Wykorzystuje dane wejściowe i wyjściowe transakcji
  • Polecenia
  • Dodatkowe dane
  • Służy do instruowania wykonywalnego kodu kontraktu

Kod Java i Kotlin jest kompilowany do identycznego kodu bajtowego za pośrednictwem maszyny JVM. Polecenia przekazują dodatkowe dane, które nie istnieją w stanie, do kodu kontraktu. Polecenia działają jak struktury danych z dołączonymi kluczami publicznymi używanymi do podpisywania transakcji, chociaż należy pamiętać, że umowy nie działają bezpośrednio z podpisami cyfrowymi. Kontrakty w tym środowisku są replikowane w całym systemie w kontekście tego, jak przepływy chcą koordynować między zaufanymi stronami.

Komentarz

Kod kontraktu odpowiada potrzebom przypadków użycia w środowisku Corda i jest w stanie realizować niezbędne funkcje przepustowości transakcji. Ograniczenia obejmują interoperacyjność z innymi ekosystemami. Aby systemy współpracowały z Cordą, musiałyby korzystać ze struktury kodu kontraktowego Corda zaprojektowanej wokół zamkniętego DLT. W przeciwieństwie do prawdziwej platformy blockchain, takiej jak Ethereum, która może działać jako warstwa interoperacyjności między procesami gospodarczymi i funkcjami między prywatnymi instancjami a publicznymi instancjami, Corda ogranicza się, koncentrując się bardziej na procesach w systemie zamkniętym. Zastosowanie wirtualnej maszyny wirtualnej jest innowacyjne, chociaż instancja jest izolowana w ekosystemie Corda. W tym scenariuszu Corda zyskuje przetwarzanie transakcji w bezpiecznym środowisku, poświęcając jednocześnie zdolność do współdziałania i koordynowania między różnymi środowiskami blockchain, tak jak byłby w stanie to zrobić system interoperacyjny.

IV. Wnioski i ocena

Bazując na naszej analizie, kluczowymi wyróżniającymi czynnikami, które Ethereum jest w stanie wdrożyć poza możliwościami DLT, są:

  • Gospodarka zasobami cyfrowymi lub tokenami
  • Kryptoekonomiczne warstwy motywacyjne w protokole
  • Interoperacyjność między konsorcjum a publicznymi łańcuchami bloków

Chociaż DLT, takie jak R3 Corda i Hyperledger Fabric, są w stanie osiągnąć funkcjonalność w zakresie zarządzania współdzieloną bazą danych i cyklu życia przetwarzania transakcji, nie ma gwarancji, że będą w stanie osiągnąć kluczowe funkcje opisane powyżej. Platformy te nie są wadliwe, ale mają raczej ograniczoną konfigurację architektoniczną, aby pokazać niektóre z czystych przypadków użycia, które są w stanie zapewnić tylko prawdziwe łańcuchy bloków.

Technologie Blockchain są zaprojektowane tak, aby połączyć zaufanie, które jest w nich oparte, z namacalną wartością, która jest tworzona z tego zaufania. Tylko dzięki prawdziwej platformie zbudowanej z podstawowych podstaw łańcucha blokowego systemy społeczne, polityczne i ekonomiczne będą mogły być fundamentalnie konsekrowane w ramach infrastruktury protokołu oprogramowania. Podczas gdy platformy zarządzania bazami danych skoncentrowane na DLT mogą integrować się i współdziałać z platformą blockchain, szyny, na których zostaną zbudowane transfery wartości i koordynacja tego zaufania, muszą być łańcuchem bloków, który ucieleśnia podstawowe zasady zaufania, niezmienności, integralności i wierności informacyjnej.

Analiza ta ujawnia nie to, że pewne systemy są lepsze od innych, ale raczej są przydatne w różnych sytuacjach. Zdolność platform DLT do działania jako prywatne rozproszone bazy danych o dużej przepustowości i funkcjonalności transakcji, pozwalają im działać jako zaufane systemy, które mogą współpracować w ramach platformy blockchain, gdy do oceny niezbędne są pewne aspekty prywatnych informacji, takie jak dane bankowe / finansowe lub wrażliwe informacje dotyczące wewnętrznego funkcjonowania instytucji prywatnej, które nie powinny być ujawniane opinii publicznej. Różne modele biznesowe dotyczące wykorzystania tych źródeł prywatnych danych powiązanych z DLT są nadal w fazie rozwoju i powinny być iterowane z uwzględnieniem interfejsów blockchain, ponieważ zdecentralizowany cyfrowy system wartości jest niezbędny dla niektórych interakcji między łańcuchami bloków i DLT.

Połącz się z naszymi ekspertami w dziedzinie technologii blockchain

Nasz zespół ds. Rozwiązań globalnych oferuje szkolenia z zakresu technologii blockchain, doradztwo strategiczne, usługi wdrożeniowe i możliwości partnerstwa. Skontaktuj się z nami Newsletter Zapisz się do naszego newslettera, aby otrzymywać najnowsze wiadomości dotyczące Ethereum, rozwiązania dla przedsiębiorstw, zasoby dla programistów i nie tylko.Kompletny przewodnik po sieciach biznesowych BlockchainPrzewodnik

Kompletny przewodnik po sieciach biznesowych Blockchain

Wprowadzenie do tokenizacjiWebinar

Wprowadzenie do tokenizacji

Przyszłość finansów, aktywów cyfrowych i DeFiWebinar

Przyszłość finansów: aktywa cyfrowe i DeFi

Co to jest Enterprise EthereumWebinar

Co to jest Enterprise Ethereum?

Banki centralne i przyszłość pieniądzaBiały papier

Banki centralne i przyszłość pieniądza

Komgo Blockchain dla finansowania handlu towaramiCase Stud

Komgo: Blockchain dla finansowania handlu towarami

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