Inteligentní smluvní platformy [hloubkové vyšetřování]

V této příručce projdeme některé chytré smluvní platformy a uvidíme, co je odlišuje. Některé z nich již fungují, zatímco některé jsou ve vývoji.

Žijeme v éře chytré smlouvy. Zatímco bitcoiny nám možná ukázaly, že platební systém může existovat v decentralizované atmosféře typu peer-to-peer. Avšak s příchodem Etherea se stavidla dobře a skutečně otevřela. Ethereum zahájilo éru blockchainu druhé generace a lidé konečně viděli skutečný potenciál Dapps a chytrá smlouvas.

Hlubší pohled na různé platformy inteligentních smluv

Než to však uděláme, položme si otázku.

Co přesně jsou inteligentní smlouvy?

Inteligentní smlouvy jsou automatizované smlouvy. Jsou samy provádějící s konkrétními pokyny napsanými na jeho kódu, které se provedou, když jsou splněny určité podmínky.

Hlubší pohled na různé platformy inteligentních smluv

Více o inteligentních kontraktech se můžete dozvědět v našem podrobném průvodci zde.

Jaké jsou tedy žádoucí vlastnosti, které chceme v naší inteligentní smlouvě?

Cokoli, co běží na blockchainu, musí být neměnné a musí mít schopnost běžet přes více uzlů, aniž by byla ohrožena jeho integrita. V důsledku toho musí být funkce inteligentního kontraktu tři věci:

  • Deterministický.
  • Terminable.
  • Izolovaný.

Funkce č. 1: Deterministická

Program je deterministický, pokud danému vstupu poskytuje vždy stejný výstup. Např. Pokud 3 + 1 = 4, pak 3 + 1 bude VŽDY 4 (za předpokladu stejné základny). Takže když program poskytuje stejný výstup stejné sadě vstupů v různých počítačích, program se nazývá deterministický.

Existují různé okamžiky, kdy program může jednat nedeterministickým způsobem:

  • Volání nedeterministických funkcí systému: Když programátor zavolá ve svém programu neurčitou funkci.
  • Un-deterministické zdroje dat: Pokud program získává data za běhu a tento zdroj dat je nedeterministický, stane se program nedeterministickým. Např. Předpokládejme program, který získává top 10 google vyhledávání konkrétního dotazu. Seznam se může stále měnit.
  • Dynamické hovory: Když program volá druhý program, nazývá se to dynamické volání. Protože cíl volání je určen pouze během provádění, je nedeterministické povahy.

Funkce č. 2: Ukončitelné

V matematické logice máme chybu zvanou „zastavení problému“. V zásadě uvádí, že není možné zjistit, zda daný program může nebo nemůže vykonat svou funkci v časovém limitu. V roce 1936 Alan Turing pomocí Cantorova úhlopříčného problému odvodil, že neexistuje způsob, jak zjistit, zda daný program může skončit v časovém limitu nebo ne.

To je zjevně problém s inteligentními smlouvami, protože smlouvy ze své podstaty musí být možné v daném časovém limitu ukončit. Byla přijata některá opatření k zajištění toho, aby existoval způsob, jak smlouvu externě „zabít“ a nevstupovat do nekonečné smyčky, která vyčerpá zdroje:

  • Turingova neúplnost: Turingův neúplný blockchain bude mít omezenou funkčnost a nebude schopen dělat skoky a / nebo smyčky. Proto nemohou vstoupit do nekonečné smyčky.
  • Měřič kroků a poplatků: Program může jednoduše sledovat počet „kroků“, které provedl, tj. Počet provedených instrukcí, a poté ukončit, jakmile je proveden určitý počet kroků. Další metodou je měřič poplatků. Zde se smlouvy provádějí s předem zaplaceným poplatkem. Každé provedení instrukce vyžaduje určitou částku poplatku. Pokud utracený poplatek přesáhne předplacený poplatek, je smlouva ukončena.
  • Časovač: Zde se udržuje předem určený časovač. Pokud plnění smlouvy překročí časový limit, je externě přerušeno.

Funkce č. 3: Izolované

V blockchainu může kdokoli a každý nahrát chytrou smlouvu. Z tohoto důvodu však smlouvy mohou vědomě i nevědomky obsahovat viry a chyby.

Pokud smlouva není izolovaná, může to bránit celému systému. Proto je zásadní, aby smlouva byla izolována v karanténě, aby se celý ekosystém uchránil před negativními dopady.

Nyní, když jsme viděli tyto funkce, je důležité vědět, jak jsou prováděny. Inteligentní smlouvy se obvykle spouštějí pomocí jednoho ze dvou systémů:

  • Virtuální stroje: Ethereum a Neo to používají
  • Přístavní dělník: Fabric to používá.

Pojďme si tyto dva porovnat a zjistit, co přispívá k lepšímu ekosystému. Pro zjednodušení budeme porovnávat Ethereum (Virtual Machine) s Fabric (Docker).

Hlubší pohled na různé platformy inteligentních smluv

Jak je tedy vidět, Virtual Machines poskytují lepší deterministické, ukončitelné a izolované prostředí pro smlouvy Smart.

Dobře, takže teď víme, co jsou inteligentní smlouvy, a skutečnost, že virtuální stroje jsou lepšími platformami pro inteligentní smlouvy. Podívejme se, co přesně Dapps vyžaduje, aby fungoval efektivně.

Co Dapps vyžaduje?

Nebo přesněji řečeno, co DAPP vyžaduje, aby byl úspěšný a hit u běžného publika? Jaké jsou jeho absolutní minimální požadavky?

Podpora pro miliony uživatelů

Mělo by to být dostatečně škálovatelné, aby jej mohly používat miliony uživatelů. To platí zejména pro DAPP, kteří hledají mainstreamové přijetí.

Zdarma použití

Platforma by měla vývojářům umožnit vytvářet Dappy, které mohou uživatelé používat zdarma. Žádný uživatel by neměl platit platformě, aby získal výhody Dapp.

Snadno upgradovatelné

Platforma by měla vývojářům umožnit svobodu upgradovat Dapp, kdykoli chtějí. Také pokud nějaká chyba ovlivní Dapp, vývojáři by měli být schopni opravit DAPP bez ovlivnění platformy.

Nízká latence

DAPP by měl běžet co nejplynuleji as nejnižší latencí.

Paralelní výkon

Platforma by měla umožnit paralelní zpracování jejich Dapps, aby se rozložilo pracovní vytížení a ušetřil čas.

Sekvenční výkon

Tímto způsobem by však neměly být prováděny všechny funkce na blockchainu. Přemýšlejte o samotném provedení transakce. Několik transakcí nelze provést paralelně; je třeba to dělat jeden po druhém, aby se zabránilo chybám, jako je dvojnásobné utrácení.

Jaké jsou tedy platformy, které máme k dispozici, pokud jde o vytvoření DAPP?

BitShares a Graphene mají dobrou propustnost, ale rozhodně nejsou vhodné pro chytré smlouvy.

Ethereum je jednoznačně nejzřejmější volbou na trhu. Má úžasné schopnosti inteligentního kontraktu, ale hlavním problémem je nízká rychlost transakce. Cena plynu může být navíc problematická.

Dobře, takže teď, když víme, co Dapps vyžaduje, pojďme projít několika chytrými smluvními platformami.

Podíváme se na:

  • Ethereum
  • EOS
  • Hvězdný
  • Cardano
  • Neo
  • Hyperledger Fabric

Hlubší pohled na různé platformy inteligentních smluv

Ethereum

Nejdůležitější je Ethereum, které to všechno začalo.

Takto to definuje web Ethereum:

„Ethereum je decentralizovaná platforma, která provozuje inteligentní smlouvy: aplikace, které běží přesně tak, jak je naprogramováno, bez možnosti odstávky, cenzury, podvodu nebo třetí strana rušení. Tyto aplikace běží na speciálně postaveném blockchainu, což je nesmírně výkonná sdílená globální infrastruktura, která může přesouvat hodnotu a představovat vlastnictví nemovitosti. “

Jednoduše řečeno, Ethereum plánuje být konečnou softwarovou platformou budoucnosti. Pokud je budoucnost decentralizovaná a Dapps se stane běžnou záležitostí, pak musí být ethereum jejím středem.

Virtuální stroj Ethereum nebo EVM je virtuální stroj, ve kterém fungují všechny inteligentní smlouvy v Ethereu. Jedná se o jednoduchý, ale výkonný 256bitový virtuální stroj Turing Complete. Turing Complete znamená, že s ohledem na zdroje a paměť může jakýkoli program spuštěný v EVM vyřešit jakýkoli problém.

Aby bylo možné kódovat inteligentní kontrakty v EVM, je třeba se naučit programovací jazyk Solidity.

Solidity je záměrně zúžený, volně psaný jazyk se syntaxí velmi podobnou ECMAScript (Javascript). Z dokumentu Ethereum Design Rationale si musíme pamatovat několik klíčových bodů, konkrétně to, že pracujeme v rámci modelu zásobníku a paměti s velikostí slova instrukce 32 bajtů, EVM (Ethereum Virtual Machine) nám umožňuje přístup k programu “ stack “, což je jako prostor registru, kde můžeme také nalepit adresy paměti, abychom vytvořili smyčku / skok čítače programu (pro sekvenční ovládání programu), rozšiřitelnou dočasnou„ paměť “a trvalejší„ úložiště “, které je ve skutečnosti zapsáno do permanentního blockchain, a co je nejdůležitější, EVM vyžaduje v rámci inteligentních smluv totální determinismus.

Než tedy pokračujeme, podívejme se na základní příklad smlouvy Solidity. (Kódy byly převzaty z github).

Pojďme spustit jednoduchou smyčku while v solidnosti:

smlouva BasicIterator

{

tvůrce adresy; // rezervovat jeden "adresa"-místo typu

uint8 [10] celá čísla; // rezervuje kus úložiště pro 10 8bitových celých čísel bez znaménka v poli

funkce BasicIterator ()

{

tvůrce = msg.sender;

uint8 x = 0;

// Část 1: Přiřazení hodnot

while (x < integers.length) {

celá čísla [x] = x;

x ++;

}}

funkce getSum () konstantní výnosy (uint) {

uint8 součet = 0;

uint8 x = 0;

// Sekce 2: Přidání celých čísel do pole.

while (x < integers.length) {

součet = součet + celá čísla [x];

x ++;

}

návratná částka;

}

// Část 3: Zabití smlouvy

funkce kill ()

{

if (msg.sender == tvůrce)

{

sebevražda (tvůrce);

}

}

}

Pojďme tedy analyzovat kód. Pro snazší pochopení jsme kód rozdělili do 3 sekcí.

Oddíl 1: Přiřazování hodnot

V prvním kroku vyplňujeme pole zvané „celá čísla“, které přijímá 10 8bitových celých čísel bez znaménka. Způsob, jakým to děláme, je pomocí while smyčky. Podívejme se, co se děje uvnitř smyčky while.

while (x < integers.length) {

celá čísla [x] = x;

x ++;

}

Pamatujte, že jsme již přiřadili hodnotu „0“ celému číslu x. Smyčka while přechází z 0 na integers.length. Integers.length je funkce, která vrací maximální kapacitu pole. Takže pokud jsme se rozhodli, že pole bude mít 10 celých čísel, arrayname.length vrátí hodnotu 10. Ve smyčce výše bude hodnota x 0-9 (<10) a přiřadí jeho hodnotu také celočíselnému poli. Takže na konci smyčky budou mít celá čísla následující hodnotu:

0,1,2,3,4,5,6,7,8,9.

Oddíl 2: Přidání obsahu pole

Uvnitř funkce getSum () přidáme obsah samotného pole. Způsob, jakým to uděláme, je opakováním stejné smyčky while, jak je uvedeno výše, a použitím proměnné „sum“ k přidání obsahu pole.

Část 3: Zabití smlouvy

Tato funkce zabije smlouvu a odešle zbývající prostředky ve smlouvě zpět tvůrci smlouvy.

Co je to plyn?

„Plyn“ je krví ekosystému Ethereum, neexistuje jiný způsob, jak to vyjádřit. Plyn je jednotka, která měří množství výpočetního úsilí, které bude zapotřebí k provedení určitých operací.

Každá jednotlivá operace, která se účastní Ethereum, ať už jde o jednoduchou transakci nebo inteligentní smlouvu, nebo dokonce ICO, vyžaduje určité množství plynu. Plyn se používá k výpočtu počtu poplatků, které je třeba zaplatit síti, aby bylo možné provést operaci.

Když někdo předloží chytrou smlouvu, má předem stanovenou hodnotu plynu. Když je smlouva uzavřena, každý její krok vyžaduje k provedení určité množství plynu.

To může vést ke dvěma scénářům:

  1. Potřebný plyn je vyšší než stanovený limit. V takovém případě se stav smlouvy vrátí zpět do původního stavu a spotřebuje se veškerý plyn.

        2. Potřebný plyn je menší než stanovený limit. V takovém případě je smlouva dokončena a zbývající plyn je předán zadavateli smlouvy.

Zatímco Ethereum možná vydláždilo cestu pro inteligentní smlouvy. Čelí některým problémům se škálovatelností. Inovace jako plazma, raiden, sharding atd. Však mohou tento problém vyřešit.

EOS

Hlubší pohled na různé platformy inteligentních smluv

Cílem společnosti EOS je stát se decentralizovaným operačním systémem, který může podporovat decentralizované aplikace v průmyslovém měřítku.

To zní docela úžasně, ale to, co ve skutečnosti zaujalo představivost veřejnosti, jsou následující dvě tvrzení:

  • Plánují úplné odstranění transakčních poplatků.
  • Tvrdí, že mají schopnost provádět miliony transakcí za sekundu.

Tyto dvě funkce jsou důvody, proč jsou vývojáři Dapp fascinováni EOS. Pojďme se podívat na to, jak EOS dosahuje obou těchto věcí.

Odstranění poplatků

EOS pracuje na vlastnickém modelu, kdy uživatelé vlastní a jsou oprávněni využívat prostředky úměrné svému podílu, místo aby museli platit za každou transakci. V podstatě tedy, pokud držíte N tokenů EOS, máte nárok na N * k transakce. To v podstatě vylučuje transakční poplatky.

Náklady na provoz a hostování aplikací na Ethereu mohou být vysoké pro vývojáře, který chce otestovat svou aplikaci na blockchainu. Cena plynu zahrnutá v raných fázích vývoje může stačit k vypnutí nových vývojářů.

Zásadním rozdílem mezi způsobem, jakým fungují Ethereum a EOS, je to, že zatímco Ethereum pronajímá svou výpočetní sílu vývojářům, EOS dává vlastnictví jejich zdrojů. V podstatě tedy, pokud vlastníte 1/1 000. podílu v EOS, pak budete vlastnit 1/1 000. celkové výpočetní síly a zdrojů v EOS.

Jak uvádí ico-reviews ve svém článku:

„Model vlastnictví společnosti EOS poskytuje vývojářům DAPP předvídatelné náklady na hostování, vyžaduje je pouze k udržení určitého procenta nebo úrovně podílu a umožňuje vytvářet bezplatné aplikace. Vzhledem k tomu, že držitelé tokenů EOS budou moci pronajmout / delegovat svůj podíl zdrojů na jiné vývojáře, model vlastnictví spojuje hodnotu tokenů EOS s nabídkou a poptávkou po šířce pásma a úložišti. “

Zvýšená škálovatelnost

EOS získává svoji škálovatelnost ze svého konsensuálního mechanismu DPOS. DPOS znamená delegovaný důkaz o sázce a funguje to takto:

Za prvé, každý, kdo drží tokeny na blockchainu integrovaném do softwaru EOS, si může vybrat výrobce bloků prostřednictvím systému průběžného hlasování o schválení. Volby producentů bloků se může účastnit kdokoli a bude jim poskytnuta příležitost vytvářet bloky úměrně k celkovému počtu hlasů, které obdrží ve srovnání se všemi ostatními producenty.

Jak to funguje?

  • Bloky se vyrábějí v kolech 21.
  • Na začátku každého kola je vybráno 21 blokových výrobců. Top 20 je automaticky vybráno, zatímco 21. je vybrán úměrně k počtu jejich hlasů ve vztahu k ostatním producentům.
  • Producenti jsou poté zamícháni pomocí pseudonáhodného čísla odvozeného od času bloku. Důvodem je zajištění udržení rovnováhy propojení se všemi ostatními výrobci.
  • Aby bylo zajištěno, že bude udržována pravidelná výroba bloků a že čas bloku bude udržován na 3 sekundy, budou producenti potrestáni za neúčast tím, že budou odstraněni z úvahy. Producent musí vyrábět alespoň jeden blok každých 24 hodin, aby byl vzat v úvahu.

Jelikož je na konsensu tak málo lidí, je to rychlejší a centralizovanější než Ethereum a Bitcoin, které ke konsensu využívá celou síť.

Jazyk WASM

EOS používá WebAssembly aka programovací jazyk WASM. Důvodem, proč ho používají, je jeho následující vlastnosti (převzato z webassembly.org):

  • Rychlost a účinnost: WebAssembly se spouští nativní rychlostí využitím výhod běžných hardwarových schopností dostupných na široké škále platforem.
  • Otevřený a laditelný: Je navržen tak, aby byl pěkně vytištěn v textovém formátu pro ruční ladění, testování, experimentování, optimalizaci, učení, výuku a psaní programů.
  • Bezpečný: WebAssembly popisuje paměťově bezpečné prostředí pro provádění v karanténě, které může být dokonce implementováno uvnitř stávajících virtuálních strojů JavaScriptu.

EOS je perfektní platforma pro vytváření Dapps v průmyslovém měřítku. Představme si, že vytváříte decentralizovaný Twitter. Pokud jste to vytvořili na Ethereu, pak by uživatel musel utratit nějaký benzín při provádění každého kroku tweetu.

Pokud jste udělali totéž v EOS, uživatelé nebudou muset utrácet benzín, protože transakční poplatky jsou 0! Jelikož však EOS není tak decentralizovaný jako Ethereum, nemusí se pro něj Dapps, který vyžaduje vysokou odolnost vůči cenzuře, hodit.

Hvězdný

Hlubší pohled na různé platformy inteligentních smluvStellar je duchovním dítětem Jed McCaleba a Joyce Kim byla založena v roce 2014, kdy to bylo viditelné z protokolu Ripple. Stellar, podle jejich webových stránek,

„Je platforma, která spojuje banky, platební systémy a lidi. Integrujte se, abyste mohli peníze přesouvat rychle, spolehlivě a téměř bez nákladů “.

Pomocí Stellar můžete rychle, spolehlivě a za zlomek penny přesouvat peníze přes hranice.

Na rozdíl od Etherea nejsou Stellar Smart Contracts (SSC) Turing kompletní. Následující tabulka poskytuje dobrou představu o rozdílech mezi inteligentními smlouvami Stellar a Ethereum:

Hlubší pohled na různé platformy inteligentních smluv

Uznání obrázku: Hackernoon

Některé statistiky se mohou objevit hned.

Nejpozoruhodnější je 5sekundový čas potvrzení a skutečnost, že jedna transakce v síti Stellar stojí pouze ~ 0,0000002 $!

$ stellarNetwork->buildTransaction ($ customerKeypair)

->addCreateAccountOp ($ escrowKeypair, 100.00006) // 100 XLM po poplatcích za nastavení + transakční transakce

->odeslat ($ customerKeypair);

}

tisk "Vytvořený účet úschovy: " . $ escrowKeypair->getPublicKey (). PHP_EOL;

/ *

* Abychom z tohoto účtu mohli učinit úschovu, musíme to pracovníkovi dokázat

* Nikdo z něj není schopen vybrat prostředky, když pracovník hledá

* marná adresa.

*

* Toho je dosaženo:

* – Vytvoření stejné váhy pro pracovníky a zákazníky (1)

* – Požadování, aby se oba signatáři dohodli na jakékoli transakci (prahové hodnoty jsou nastaveny na 2)

*

* Musíme však také řešit případ, kdy žádný pracovník nebere práci my a my

* je třeba získat zpět účet. Toho lze dosáhnout přidáním předem autorizovaného sloučení

* transakce, která není platná do 30 dnů od této chvíle.

*

* Díky tomu může pracovník vědět, že je zaručeno, že budou prostředky k dispozici

* po dobu 30 dnů.

* /

// Načtěte účet úschovy

$ account = $ stellarNetwork->getAccount ($ escrowKeypair);

// Předpočítejte některá pořadová čísla, protože jsou nezbytná pro transakce

$ startingSequenceNumber = $ účet->getSequence ();

// Sledujte, kolik transakcí je potřeba k založení účtu úschovy

// Potřebujeme to, abychom mohli správně vypočítat "reklamovat účet" pořadové číslo

$ numSetupTransactions = 5;

$ reclaimAccountOrPaySeqNum = $ startingSequenceNumber + $ numSetupTransactions + 1;

// Aktualizujte účet datovou hodnotou označující, jakou marnou adresu hledat

tisk "Přidání datového záznamu pro vyžádání marné adresy…";

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->setAccountData (‘request: generateVanityAddress’, ‘G * ZULU’)

->submit ($ escrowKeypair);

tisk "HOTOVO" . PHP_EOL;

// Záložní transakce: získejte zpět účet úschovy, pokud žádný zaměstnanec nevygeneruje

// marná adresa do 30 dnů

$ reclaimTx = $ stellarNetwork->buildTransaction ($ escrowKeypair)

->setSequenceNumber (nový BigInteger ($ reclaimAccountOrPaySeqNum))

// todo: odkomentujte to ve skutečné implementaci

//->setLowerTimebound (nový \ DateTime (‘+ 30 dní’))

->setAccountData (‘požadavek: generateVanityAddress’)

->addMergeOperation ($ customerKeypair)

->getTransactionEnvelope ();

// Přidejte hash $ reclaimTx jako signatáře účtu

// Viz: https://www.stellar.org/developers/guides/concepts/multi-sig.html#pre-authorized-transaction

$ txHashSigner = nový podepisovatel (

SignerKey :: fromPreauthorizedHash ($ reclaimTx->getHash ()),

2 // váha musí stačit, takže nejsou potřeba žádní další signatáři

);

$ addReclaimTxSignerOp = nový SetOptionsOp ();

$ addReclaimTxSignerOp->updateSigner ($ txHashSigner);

tisk "Přidání předem autorizované transakce reklamace jako podepisující… ";

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addReclaimTxSignerOp)

->submit ($ escrowKeypair);

tisk "HOTOVO" . PHP_EOL;

tisk "Přidána transakce zpětného získání před autorizací platná v pořadí " . $ reclaimAccountOrPaySeqNum. PHP_EOL;

tisk "Chcete-li získat zpět účet úschovy, spusťte soubor 90-reclaim-escrow.php" . PHP_EOL;

// Přidat pracovní účet jako signatáře váhy 1

$ workerSigner = nový podepisovatel (

SignerKey :: fromKeypair ($ workerKeypair),

1 // vyžaduje dalšího podepisujícího

);

$ addSignerOp = nový SetOptionsOp ();

$ addSignerOp->updateSigner ($ workerSigner);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addSignerOp)

->submit ($ escrowKeypair);

// Přidat zákaznický účet jako druhého signatáře váhy 1

$ workerSigner = nový podepisovatel (

SignerKey :: fromKeypair ($ customerKeypair),

1 // vyžaduje dalšího podepisujícího

);

$ addSignerOp = nový SetOptionsOp ();

$ addSignerOp->updateSigner ($ workerSigner);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addSignerOp)

->submit ($ escrowKeypair);

// Zvyšte prahové hodnoty a nastavte hlavní hmotnost na 0

// Všechny operace nyní vyžadují prahovou hodnotu 2

$ thresholdsOp = nový SetOptionsOp ();

$ prahyOp->setLowThreshold (2);

$ prahyOp->setMediumThreshold (2);

$ prahyOp->setHighThreshold (2);

$ prahyOp->setMasterWeight (0);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ thresholdsOp)

->submit ($ escrowKeypair);

tisknout PHP_EOL;

tisk "Konfigurace úschovy účtu byla dokončena" . PHP_EOL;

Cardano

Hlubší pohled na různé platformy inteligentních smluv

Jedním z nejzajímavějších projektů, který vyšel, je Cardano. Podobně jako Ethereum, Cardano je chytrá smluvní platforma, nicméně Cardano nabízí škálovatelnost a zabezpečení prostřednictvím vrstvené architektury. Cardanův přístup je v samotném prostoru jedinečný, protože je postaven na vědecké filozofii a recenzovaném akademickém výzkumu

Cardano si klade za cíl zvýšit škálovatelnost prostřednictvím jejich mechanismu konsensu sázek na důkaz Ouroboros. Abyste mohli kódovat inteligentní smlouvy v Cardanu, budete muset použít Plutus, který je založen na Haskellu, jazyce používaném pro kódování Cardana.

Zatímco C ++ a většina tradičních jazyků jsou imperativní programovací jazyky, Plutus a Haskell jsou funkční programovací jazyky.

Jak tedy funkční programování funguje?

Předpokládejme, že existuje funkce f (x), kterou chceme použít k výpočtu funkce g (x), a potom ji chceme použít k práci s funkcí h (x). Místo toho, abychom vyřešili všechny v pořadí, můžeme je všechny jednoduše spojit do jediné funkce, jako je tato:

h (g (f (x)))

Díky tomu je funkční přístup matematicky jednodušší. To je důvod, proč mají být funkční programy bezpečnějším přístupem k vytváření inteligentních smluv. To také pomáhá v jednodušším formálním ověření, což do značné míry znamená, že je snazší matematicky dokázat, co program dělá a jak funguje. To dává společnosti Cardano vlastnost „High Assurance Code“.

Pojďme si vzít příklad z reálného života a podívejme se, proč se to za určitých podmínek může stát extrémně kritickým a dokonce život zachraňujícím.

Předpokládejme, že kódujeme program, který řídí letový provoz.

Jak si dokážete představit, kódování takového systému vyžaduje vysokou míru přesnosti a přesnosti. Nemůžeme jen slepě něco kódovat a doufat v to nejlepší, když jsou ohroženy životy lidí. V takových situacích potřebujeme kód, u kterého lze prokázat vysokou míru matematické jistoty.

Právě proto je funkční přístup tak žádoucí.

A to je přesně to, co Cardano používá Haskell k kódování svého ekosystému a Plutus pro své chytré smlouvy. Haskell i Plutus jsou funkční jazyky.

Následující tabulka porovnává imperativní přístup s funkčním přístupem.

Hlubší pohled na různé platformy inteligentních smluv

Image Credit: Docs.Microsoft.com

Pojďme se tedy podívat na výhody funkčního přístupu:

  • Pomáhá s vytvářením vysoce zabezpečeného kódu, protože je snazší matematicky dokázat, jak se bude kód chovat.
  • Zvyšuje čitelnost a udržovatelnost, protože každá funkce je navržena tak, aby splnila konkrétní úkol. Funkce jsou také nezávislé na stavu.
  • Kód je snazší refraktor a jakékoli změny v kódu se snáze implementují. To usnadňuje opakovaný vývoj.
  • Jednotlivé funkce lze snadno izolovat, což usnadňuje jejich testování a ladění.

Neo

Hlubší pohled na různé platformy inteligentních smluv

Neo, dříve známý jako Antshares, je často známý jako „ethereum v Číně“.

Podle jejich webových stránek je Neo „neziskový komunitní blockchainový projekt, který využívá technologii blockchain a digitální identitu k digitalizaci aktiv, automatizaci správy digitálních aktiv pomocí inteligentních smluv a k realizaci„ inteligentní ekonomiky “s distribuovaným síť.”

Hlavním cílem společnosti Neo je být distribuovanou sítí pro „inteligentní ekonomiku“. Jak uvádí jejich web:

Digitální aktiva + digitální identita + inteligentní smlouva = inteligentní ekonomika.

Neo bylo vyvinuto blockchainem R. založeným na Šanghaji&D společnost „OnChain“. Onchain založili CEO Da Hongfei a CTO Erik Zhang. Výzkum společnosti Neo byl zahájen kolem roku 2014. V roce 2016 byla společnost Onchain zařazena do top 50 fintech společnosti v Číně společností KPMG.

Společnost Neo chtěla vytvořit inteligentní smluvní platformu, která má všechny výhody virtuálního stroje Ethereum, aniž by ochromila jejich vývojáře jazykovými bariérami. V ethereum se budete muset naučit solidnost při kódování chytrých kontraktů, zatímco v Neo můžete dokonce použít Javascript ke kódování chytrých kontraktů.

Neo Smart Contract 2.0

Inteligentní kontrakční systém Neo aka Inteligentní smlouva 2.0 má tři části:

  • NeoVM.
  • InteropService
  • DevPack

NeoVm

Toto je obrazové znázornění virtuálního stroje Neo:

Hlubší pohled na různé platformy inteligentních smluv

Uznání: Neo Whitepaper

Jak uvádí Neo Whitepaper, NeoVM nebo Neo Virtual Machine je lehký univerzální virtuální počítač, jehož architektura se velmi podobá JVM a .NET Runtime. Je to podobné jako virtuální CPU, které čte a provádí instrukce ve smlouvě v pořadí, provádí řízení procesu na základě funkčnosti operací instrukcí, logických operací atd. Je univerzální s dobrou počáteční rychlostí, což z něj dělá skvělé prostředí pro provádění inteligentních smluv.

InteropService

InteropService zvyšuje užitečnost inteligentních smluv. Umožňuje smlouvám přístup k datům mimo NeoVM, aniž by byla ohrožena celková stabilita a účinnost systému.

V současné době poskytuje interoperabilní servisní vrstva některá rozhraní API pro přístup k datům řetězového řetězce inteligentní smlouvy. Data, ke kterým má přístup, jsou:

  • Blokovat informace.
  • Informace o transakci
  • Informace o smlouvě.
  • Informace o díle

….mezi ostatními.

Poskytuje také úložný prostor pro inteligentní smlouvy.

DevPack

DevPack obsahuje kompilátor jazyků na vysoké úrovni a doplněk IDE. Vzhledem k tomu, že architektura NeoVM je velmi podobná JVM a .NET Runtime, umožňuje kódování kontraktů v jiných jazycích. Jak si dokážete představit, výrazně to zkrátilo čas, který vývojářům trvalo, než se naučili vytvářet inteligentní smlouvy.

Hyperledger Fabric

Hlubší pohled na různé platformy inteligentních smluv

Podle jejich webových stránek „Hyperledger je otevřené úsilí o spolupráci vytvořené za účelem prosazení mezioborových blockchainových technologií. Jedná se o globální spolupráci, kterou pořádá The Linux Foundation, včetně lídrů v oblasti financí, bankovnictví, internetu věcí, dodavatelských řetězců, výroby a technologií. “

Možná nejzajímavějším projektem v rodině Hyperledger je IBM Fabric. Spíše než jeden blockchain Fabric je základem pro vývoj řešení založených na blockchainu s modulární architekturou.

S Fabric se mohou různé komponenty Blockchainů, jako je konsenzus a členské služby, stát plug-and-play. Fabric je navržen tak, aby poskytoval rámec, s nímž mohou podniky sestavit svou vlastní individuální blockchainovou síť, která se může rychle škálovat na více než 1 000 transakcí za sekundu.

Hlubší pohled na různé platformy inteligentních smluv

Co je to Fabric a jak to funguje? Rámec je implementován v Go. Je vyroben pro povolení blockchainů konsorcia s různým stupněm oprávnění. Fabric silně spoléhá na inteligentní kontrakční systém s názvem Chaincode, který každý rovnocenný partner v sítích běží v kontejnerech Docker.

Abyste mohli psát Chaincode, musíte se dobře orientovat ve čtyřech funkcích:

  • PutState: Vytvořte nové dílo nebo aktualizujte stávající.
  • GetState: Načíst aktivum.
  • GetHistoryForKey: Načíst historii změn.
  • DelState: „Odstranit“ dílo.

Následuje příklad Chaincode:

// Definujte strukturu inteligentní smlouvy

zadejte strukturu SmartContract {}

// Definujte strukturu vozu se 4 vlastnostmi.

typ struktura vozu {

Vytvořit řetězec `json:"udělat"`

Řetězec modelu `json:"Modelka"`

Barevný řetězec `json:"barva"`

Vlastnický řetězec `json:"majitel"`

}

/ *

* Metoda Invoke je volána jako výsledek žádosti aplikace o spuštění inteligentní smlouvy "fabcar"

* Volající aplikační program také specifikoval konkrétní funkci smart contract, která má být volána, s argumenty

* /

func (s * SmartContract) Invoke (APIstub shim.ChaincodeStubInterface) sc.Response {

// Načte požadovanou funkci a argumenty Smart Contract

funkce, args: = APIstub.GetFunctionAndParameters ()

// Přesměrujte na příslušnou funkci obslužné rutiny, abyste správně komunikovali s hlavní knihou

pokud funkce == "initLedger" {

vrátit s.initLedger (APIstub)

} else if function == "createCar" {

vrátit s.createCar (APIstub, args)

}

vrátit podložku. Chyba ("Neplatný název funkce Smart Contract.")

}

func (s * SmartContract) initLedger (APIstub shim.ChaincodeStubInterface) sc.Response {

return shim.Success ([] byte ("Ledger nyní běží, úspěch!"))

}

// Přidat nové auto do databáze se získanými argumenty

func (s * SmartContract) createCar (APIstub shim.ChaincodeStubInterface, řetězec args []) sc.Response {

if len (args)! = 5 {

vrátit podložku. Chyba ("Nesprávný počet argumentů. Očekává se 5")

}

var car = Auto {Značka: args [1], Model: args [2], Barva: args [3], Vlastník: args [4]}

carAsBytes, _: = json.Marshal (auto)

APIstub.PutState (args [0], carAsBytes)

zpětná vložka. Úspěch (nula)

}

func main () {

// Vytvořte novou chytrou smlouvu

err: = shim.Start (nový (SmartContract))

if err! = nil {

fmt.Printf ("Chyba při vytváření nové inteligentní smlouvy:% s", chybovat)

}

}

Závěr

Takže, tady to máte. Některé z inteligentních smluvních platforem a různé vlastnosti, díky nimž jsou jedinečné. Aspoň prozatím neexistuje „univerzální řešení“. Budete si muset vybrat platformu, která nejlépe vyhovuje funkcím požadovaným pro váš Dapp.

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