Smart kontrakt showdown: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Der er mere end én måde at sætte kode på en blockchain

I de fleste diskussioner om blockchains tager det ikke lang tid, før begrebet "smarte kontrakter" kommer op. I den populære fantasi automatiserer smarte kontrakter udførelsen af ​​interpartsinteraktioner uden at kræve en betroet mellemmand. Ved at udtrykke juridiske forhold i kode frem for ord lover de at gøre det muligt for transaktioner at finde sted direkte og uden fejl, uanset om de er bevidste eller ej.

Fra et teknisk synspunkt er en smart kontrakt noget mere specifikt: computerkode, der lever på en blockchain og definerer reglerne for den pågældende kædes transaktioner. Denne beskrivelse lyder simpel nok, men bag den ligger en stor variation i, hvordan disse regler udtrykkes, udføres og valideres. Når du vælger en blockchain-platform til en ny applikation, er spørgsmålet "Understøtter denne platform smarte kontrakter?" er ikke den rigtige at spørge. I stedet er vi nødt til at spørge: "Hvilken type smarte kontrakter understøtter denne platform?"

I denne artikel er mit mål at undersøge nogle af de store forskelle mellem intelligente kontrakttilgange og de afvejninger, de repræsenterer. Jeg vil gøre dette ved at se på fire populære enterprise blockchain-platforme, som understøtter en form for tilpasset on-chain-kode. Først IBM's Hyperledger Fabric, som kalder sine kontrakter "kædekode". For det andet vores MultiChain platform, som introducerer smarte filtre i version 2.0. Tredje, Ethereum (og det er tilladt Beslutningsdygtighed , Burrow spin-offs), som populariserede navnet "smart contract". Og endelig, R3 Corda, som henviser til "kontrakter" i sine transaktioner. På trods af alle de forskellige terminologier, refererer alle disse i sidste ende til den samme ting - applikationsspecifik kode, der definerer reglerne for en kæde.

Inden jeg går videre, bør jeg advare læseren om, at meget af det følgende indhold er af teknisk karakter og forudsætter en vis fortrolighed med generelle programmerings- og databasekoncepter. På godt og ondt kan dette ikke undgås – uden at komme ind i detaljerne er det umuligt at træffe en informeret beslutning om, hvorvidt man skal bruge en blockchain til et bestemt projekt, og (hvis ja) den rigtige type blockchain at bruge.

Grundlæggende om blockchain

Lad os begynde med noget kontekst. Forestil dig en applikation, der deles af flere organisationer, som er baseret på en underliggende database. I en traditionel centraliseret arkitektur hostes og administreres denne database af en enkelt part, som alle deltagerne har tillid til, selvom de ikke har tillid til hinanden. Transaktioner, der ændrer databasen, initieres kun af applikationer på denne centrale parts systemer, ofte som svar på beskeder modtaget fra deltagerne. Databasen gør simpelthen, hvad den bliver fortalt, fordi applikationen er implicit betroet til kun at sende den transaktioner, der giver mening.

Blockchains giver en alternativ måde at administrere en delt database på, uden en betroet mellemmand. I en blockchain kører hver deltager en "node", der har en kopi af databasen og uafhængigt behandler de transaktioner, der ændrer den. Deltagere identificeres ved hjælp af offentlige nøgler eller "adresser", som hver har en tilsvarende privat nøgle, som kun er kendt af identitetsejeren. Mens transaktioner kan oprettes af enhver node, er de "digitalt signeret" af deres initiativtagers private nøgle for at bevise deres oprindelse.

Noder forbinder sig med hinanden på en peer-to-peer-måde, og udbreder hurtigt transaktioner og de "blokke", hvor de er tidsstemplet og bekræftet på tværs af netværket. Selve blockchainen er bogstaveligt talt en kæde af disse blokke, som danner en ordnet log over hver historisk transaktion. En "konsensusalgoritme" bruges til at sikre, at alle noder når til enighed om indholdet af blockchain, uden at kræve centraliseret kontrol. (Bemærk, at noget af denne beskrivelse ikke gælder for Corda, hvor hver node kun har en delvis kopi af databasen, og der ikke er nogen global blockchain. Det vil vi tale mere om senere).

I princippet kan enhver delt databaseapplikation bygges ved at bruge en blockchain i sin kerne. Men at gøre det skaber en række tekniske udfordringer, som ikke eksisterer i et centraliseret scenarie:

• Transaktionsregler. Hvis en deltager direkte kan ændre databasen, hvordan sikrer vi så, at de følger applikationens regler? Hvad forhindrer en bruger i at ødelægge databasens indhold på en selvbetjent måde?
• determinisme. Når disse regler er defineret, vil de blive anvendt flere gange af flere noder, når de behandler transaktioner for deres egen kopi af databasen. Hvordan sikrer vi, at hver node opnår nøjagtigt det samme resultat?
• Konfliktforebyggelse. Uden central koordinering, hvordan håndterer vi to transaktioner, der hver især følger applikationens regler, men ikke desto mindre er i konflikt med hinanden? Konflikter kan stamme fra et bevidst forsøg på at spille systemet, eller være det uskyldige resultat af uheld og timing.

Så hvor kommer smarte kontrakter, smarte filtre og kædekode ind? Deres kerneformål er at arbejde med en blockchains underliggende infrastruktur for at løse disse udfordringer. Smarte kontrakter er den decentraliserede ækvivalent af applikationskode – i stedet for at køre ét centralt sted, kører de på flere noder i blockchainen, og skaber eller validerer de transaktioner, der ændrer databasens indhold.

Lad os begynde med transaktionsregler, den første af disse udfordringer, og se hvordan de kommer til udtryk i henholdsvis Fabric, MultiChain, Ethereum og Corda.

Transaktionsregler

Transaktionsregler udfører en specifik funktion i blockchain-drevne databaser - begrænser transformationer der kan udføres på den pågældende databases tilstand. Dette er nødvendigt, fordi en blockchains transaktioner kan initieres af enhver af dens deltagere, og disse deltagere har ikke tillid til hinanden tilstrækkeligt til at tillade dem at ændre databasen efter behag.

Lad os se to eksempler på, hvorfor transaktionsregler er nødvendige. Forestil dig først en blockchain designet til at samle og tidsstemple PDF-dokumenter, der udgives af dens deltagere. I dette tilfælde bør ingen have ret til at fjerne eller ændre dokumenter, da det ville underminere hele formålet med systemet - dokumentpersistens. For det andet, overvej en blockchain, der repræsenterer en delt finansiel hovedbog, som holder styr på sine brugeres saldi. Vi kan ikke tillade en deltager vilkårligt at puste deres egen saldo op eller tage andres penge væk.

Indgange og udgange

Vores blockchain-platforme er afhængige af to brede tilgange til at udtrykke transaktionsregler. Den første, som jeg kalder "input-output modellen", bruges i MultiChain og Corda. Her angiver transaktioner eksplicit de databaserækker eller "tilstande", som de sletter og opretter, og danner et sæt af henholdsvis "input" og "output". Ændring af en række udtrykkes som den ækvivalente handling med at slette den række og oprette en ny i stedet for.

Da databaserækker kun slettes i input og kun oprettes i output, skal hver input "bruge" en tidligere transaktions output. Databasens aktuelle tilstand er defineret som sættet af "ubrugte transaktionsoutput" eller "UTXOs", dvs. output fra tidligere transaktioner, som endnu ikke er blevet brugt. Transaktioner kan også indeholde yderligere information, kaldet "metadata", "kommandoer" eller "vedhæftede filer", som ikke bliver en del af databasen, men hjælper med at definere deres betydning eller formål.

Givet disse tre sæt af input, output og metadata, er gyldigheden af ​​en transaktion i MultiChain eller Corda defineret af en eller anden kode, som kan udføre vilkårlige beregninger på disse sæt. Denne kode kan validere transaktionen eller returnere en fejl med en tilsvarende forklaring. Du kan tænke på input-output-modellen som en automatiseret "inspektør", der holder en tjekliste, der sikrer, at transaktioner følger hver eneste regel. Hvis transaktionen mislykkes i en af ​​disse kontroller, vil den automatisk blive afvist af alle noderne i netværket.

Det skal bemærkes, at på trods af at de deler input-output-modellen, implementerer MultiChain og Corda den meget forskelligt. I MultiChain kan output indeholde aktiver og/eller data i JSON, tekst eller binært format. Reglerne er defineret i "transaktionsfiltre" eller "streamfiltre", som kan indstilles til at kontrollere alle transaktioner, eller kun dem, der involverer bestemte aktiver eller grupperinger af data. I modsætning hertil er en Corda output "tilstand" repræsenteret af et objekt i programmeringssproget Java eller Kotlin med definerede datafelter. Cordas regler er defineret i "kontrakter", som er knyttet til specifikke stater, og en stats kontrakt anvendes kun på transaktioner, som indeholder denne stat i dens input eller output. Dette vedrører Cordas usædvanlig synlighedsmodel, hvor transaktioner kun kan ses af deres modparter eller dem, hvis efterfølgende transaktioner de påvirker.

Kontrakter og meddelelser

Den anden tilgang, som jeg kalder "kontrakt-budskabsmodellen", bruges i Hyperledger Fabric og Ethereum. Her kan der oprettes flere "smarte kontrakter" eller "kædekoder" på blockchainen, og hver har sin egen database og tilhørende kode. En kontrakts database kan kun ændres af dens kode, snarere end direkte af blockchain-transaktioner. Dette designmønster ligner "indkapslingen" af kode og data i objektorienteret programmering.

Med denne model begynder en blockchain-transaktion som en besked sendt til en kontrakt med nogle valgfrie parametre eller data. Kontraktens kode udføres som reaktion på beskeden og parametrene og er fri til at læse og skrive sin egen database som en del af denne reaktion. Kontrakter kan også sende beskeder til andre kontrakter, men kan ikke få direkte adgang til hinandens databaser. I relationsdatabasers sprog fungerer kontrakter som håndhæves "lagrede procedurer", hvor al adgang til databasen går via en eller anden foruddefineret kode.

Både Fabric og Quorum, en variation af Ethereum, komplicerer dette billede ved at tillade et netværk at definere flere "kanaler" eller "private stater". Målet er at afbøde problemet med blockchain-fortrolighed ved at skabe separate miljøer, som hver især kun er synlige for en bestemt undergruppe af deltagere. Selvom dette lyder lovende i teorien, er kontrakterne og dataene i hver kanal eller private stat i virkeligheden isoleret fra dem i de andre. Som et resultat, hvad angår smarte kontrakter, svarer disse miljøer til separate blockchains.

Eksempel på regler

Lad os se, hvordan du implementerer transaktionsreglerne for en finansiel hovedbog med et enkelt aktiv med disse to modeller. Hver række i vores hovedbogs database har to kolonner, der indeholder ejerens adresse og mængden af ​​det ejede aktiv. I input-output-modellen skal transaktioner opfylde to betingelser:

1. Den samlede mængde af aktiver i en transaktions output skal matche totalen i dens input. Dette forhindrer brugere i at oprette eller slette penge vilkårligt.
2. Hver transaktion skal underskrives af ejeren af ​​hver af dens inputs. Dette forhindrer brugere i at bruge hinandens penge uden tilladelse.

Tilsammen er disse to forhold alt, der skal til for at skabe et enkelt, men levedygtigt finansielt system.

I kontrakt-besked-modellen understøtter aktivets kontrakt en "send betaling"-meddelelse, som tager tre parametre: afsenderens adresse, modtagerens adresse og mængden, der skal sendes. Som svar udfører kontrakten følgende fire trin:

1. Bekræft, at transaktionen blev underskrevet af afsenderen.
2. Tjek, at afsenderen har tilstrækkelige midler.
3. Træk den ønskede mængde fra afsenderens række.
4. Tilføj denne mængde til modtagerens række.

Hvis en af ​​kontrollerne i de første to trin mislykkes, vil kontrakten afbrydes, og der vil ikke blive foretaget nogen betaling.

Så både input-output- og kontrakt-beskedmodellerne er effektive måder at definere transaktionsregler og holde en delt database sikker. Faktisk kan hver af disse modeller på et teoretisk niveau bruges til at simulere den anden. I praksis vil den mest passende model dog afhænge af den applikation, der bygges. Påvirker hver transaktion få eller mange oplysninger? Skal vi kunne garantere transaktionsuafhængighed? Har hvert stykke data en klar ejer, eller er der en global stat, der skal deles?

Det ligger uden for vores rækkevidde her at udforske, hvordan svarene bør påvirke et valg mellem disse to modeller. Men som en generel retningslinje, når man udvikler en ny blockchain-applikation, er det værd at prøve at udtrykke sine transaktionsregler i begge former og se, hvilken der passer mere naturligt. Forskellen kommer til udtryk i form af: (a) nem programmering, (b) lagringskrav og gennemløb og (c) hastighed af konfliktdetektering. Vi vil tale mere om dette sidste spørgsmål senere.

Indbyggede regler

Når det kommer til transaktionsregler, er der én måde, hvorpå MultiChain specifikt adskiller sig fra Fabric, Ethereum og Corda. I modsætning til disse andre platforme har MultiChain flere indbyggede abstraktioner, der giver nogle grundlæggende byggesten til blockchain-drevne applikationer, uden kræver udviklere til at skrive deres egen kode. Disse abstraktioner dækker tre områder, der almindeligvis er nødvendige: (a) dynamiske tilladelser, (b) overførbare aktiver og (c) datalagring.

For eksempel administrerer MultiChain tilladelser til at oprette forbindelse til netværket, sende og modtage transaktioner, oprette aktiver eller streams eller kontrollere andre brugeres tilladelser. Flere fungible aktiver kan udstedes, overføres, trækkes tilbage eller udveksles sikkert og atomært. Et hvilket som helst antal "streams" kan oprettes på en kæde til publicering, indeksering og hentning af on-chain eller off-chain data i JSON, tekst eller binære formater. Alle transaktionsreglerne for disse abstraktioner er tilgængelige direkte fra kassen.

Når du udvikler en applikation på MultiChain, er det muligt at ignorere denne indbyggede funktionalitet og udtrykke transaktionsregler udelukkende ved hjælp af smarte filtre. Men smarte filtre er designet til at arbejde sammen med dets indbyggede abstraktioner ved at aktivere deres standardadfærd begrænset på skræddersyede måder. For eksempel kan tilladelsen til visse aktiviteter være kontrolleret af specifikke administratorer, snarere end standardadfærden, hvor enhver administrator vil gøre. Overførslen af ​​visse aktiver kan være tidsbegrænset eller kræve yderligere godkendelse over et vist beløb. Dataene i en bestemt strøm kan valideres for at sikre, at de kun består af JSON-strukturer med påkrævede felter og værdier.

I alle disse tilfælde skaber smarte filtre yderligere krav til transaktioner, der skal valideres, men gør det ikke Fjern de simple regler, der er indbygget. Dette kan hjælpe med at løse en af ​​de vigtigste udfordringer i blockchain-applikationer: det faktum, at en fejl i en eller anden on-chain-kode kan føre til katastrofale konsekvenser. Vi har set uendelige eksempler på dette problem i den offentlige Ethereum blockchain, mest berømt i DAO's død og Paritet multisignatur fejl. Bredere undersøgelser har fundet et stort antal almindelige sårbarheder i Ethereums smarte kontrakter, der gør det muligt for angribere at stjæle eller fryse andres penge.

Selvfølgelig kan MultiChain smarte filtre også indeholde fejl, men deres konsekvenser er mere begrænsede i omfang. For eksempel forhindrer de indbyggede aktivregler en bruger i at bruge en andens penge eller ved et uheld få deres egne penge til at forsvinde, uanset hvilken anden logik et smart filter indeholder. Hvis der findes en fejl i et smart filter, kan den deaktiveres og erstattes med en rettet version, mens hovedbogens grundlæggende integritet er beskyttet. Filosofisk er MultiChain tættere på traditionelle databasearkitekturer, hvor databaseplatformen giver en række indbyggede abstraktioner, såsom kolonner, tabeller, indekser og begrænsninger. Mere kraftfulde funktioner såsom triggere og lagrede procedurer kan valgfrit kodes af applikationsudviklere, i tilfælde hvor de faktisk er nødvendige.

Transaktionsregler	Stof	multikæde	Ethereum	corda
Model	Kontrakt-meddelelse	Input-output	Kontrakt-meddelelse	Input-output
Indbygget ins	Ingen	Tilladelser + aktiver + vandløb	Ingen	Ingen

determinisme

Lad os gå videre til næste del af vores opgør. Uanset hvilken tilgang vi vælger, er de tilpassede transaktionsregler for en blockchain-applikation udtrykt som computerkode skrevet af applikationsudviklere. Og i modsætning til centraliserede applikationer vil denne kode blive udført mere end én gang og mere end ét sted for hver transaktion. Dette skyldes, at flere blockchain-noder, der tilhører forskellige deltagere, hver især skal verificere og/eller udføre denne transaktion for sig selv.

Denne gentagne og redundante kodekørsel introducerer et nyt krav, som sjældent findes i centraliserede applikationer: determinisme. I forbindelse med beregning betyder determinisme, at et stykke kode altid vil give det samme svar for de samme parametre, uanset hvor og hvornår det køres. Dette er helt afgørende for kode, der interagerer med en blockchain, fordi uden determinisme kan konsensus mellem noderne på den kæde katastrofalt bryde sammen.

Lad os se, hvordan dette ser ud i praksis, først i input-output-modellen. Hvis to noder har en forskellig mening om, hvorvidt en transaktion er gyldig, vil den ene acceptere en blok, der indeholder den pågældende transaktion, og den anden vil ikke. Da hver blok eksplicit linker tilbage til en tidligere blok, vil dette skabe en permanent "fork" i netværket, hvor en eller flere noder ikke accepterer flertallets mening om hele blockchains indhold fra det tidspunkt af. Noderne i mindretallet vil blive afskåret fra databasens udviklingstilstand og vil ikke længere være i stand til effektivt at bruge applikationen.

Lad os nu se, hvad der sker, hvis konsensus bryder sammen i kontrakt-budskabsmodellen. Hvis to noder har en forskellig mening om, hvordan en kontrakt skal reagere på en bestemt besked, kan dette føre til en forskel i deres databasers indhold. Dette kan igen påvirke kontraktens svar på fremtidige beskeder, herunder beskeder, den sender til andre kontrakter. Slutresultatet er en stigende divergens mellem forskellige noders syn på databasens tilstand. ("State root"-feltet i Ethereum-blokke sikrer, at enhver forskel i kontrakternes svar umiddelbart fører til en fuldstændig katastrofal blockchain-gaffel, snarere end at risikere at forblive skjult i en periode.)

Kilder til ikke-determinisme

Så ikke-determinisme i blockchain-kode er klart et problem. Men hvis de grundlæggende byggesten i beregning, såsom aritmetik, er deterministiske, hvad skal vi så bekymre os om? Nå, det viser sig, at der er en del ting:

• Mest åbenlyst, tilfældige tal generatorer, da disse per definition er designet til at producere et andet resultat hver gang.
• Kontrollerer det aktuelle klokkeslæt, da noder ikke behandler transaktioner nøjagtigt på samme tid, og under alle omstændigheder kan deres ure være ude af synkronisering. (Det er stadig muligt at implementere tidsafhængige regler ved at henvise til tidsstempler i selve blockchainen.)
• Forespørgsel efter eksterne ressourcer såsom internettet, diskfiler eller andre programmer, der kører på en computer. Disse ressourcer kan ikke garanteres til altid at give det samme svar og kan blive utilgængelige.
• At køre flere stykker kode i parallelle "tråde", da dette fører til en "løbstilstand", hvor rækkefølgen, hvori disse processer slutter, ikke kan forudsiges.
• Udførelse af flydende kommaberegninger, som kan give selv minutiøst forskellige svar på forskellige computerprocessorarkitekturer.

Vores fire blockchain-platforme anvender flere forskellige tilgange til at undgå disse faldgruber.

Deterministisk udførelse

Lad os starte med Ethereum, da dens tilgang er den mest "rene". Ethereum-kontrakter er udtrykt i et specialformat kaldet "Ethereum bytecode", som udføres af Ethereum Virtual Machine ("EVM"). Programmører skriver ikke bytekode direkte, men genererer eller "kompilerer" den fra et JavaScript-lignende programmeringssprog kaldet Solidity. (Andre sprog plejede at være tilgængelige, men er siden blevet forældet.) Determinisme er garanteret af det faktum, at Solidity og Ethereum bytecode ikke kan kode nogen ikke-deterministiske operationer – så enkelt er det.

MultiChain-filtre og Corda-kontrakter vælger en anden tilgang ved at tilpasse eksisterende programmeringssprog og runtime-miljøer. MultiChain bruger JavaScript, der kører i Googles V8 motor, som også udgør kernen i Chrome-browseren og Node.js-platformen, men med kilder til ikke-determinisme deaktiveret. På samme måde bruger Corda Java eller Kotlin, som begge er kompileret til "Java bytecode", som udføres i en Java Virtual Machine ("JVM"). Indtil videre bruger Corda Oracles standard ikke-deterministiske JVM, men der arbejdes på at integrere en deterministisk version. I mellemtiden skal Corda-kontraktudviklere passe på ikke at tillade non-determinisme i deres kode.

Hvordan er Ethereums purisme sammenlignet med MultiChain og Cordas evolutionære tilgang? Den største fordel for Ethereum er risikominimering - en bygget til formål virtuel maskine er mindre tilbøjelig til at indeholde en utilsigtet kilde til ikke-determinisme. Selvom et sådant tilsyn kunne rettes ved en softwareopdatering, ville det være forstyrrende for enhver kæde, der var uheldig nok til at støde på det. Ethereums problem er imidlertid, at Solidity og EVM udgør et lillebitte og begyndende økosystem i den bredere kontekst af programmeringssprog og runtime-miljøer. Til sammenligning er JavaScript og Java top to sprog på Github, kører på milliarder af digitale enheder og har køretider, der er blevet optimeret gennem årtier. Det er formentlig derfor, den offentlige Ethereum blockchain overvejer en overgang til eWASM, en deterministisk forgrening af den nye WebAssembly-standard.

Determinisme ved påtegning

Når det kommer til determinisme, anvender Hyperledger Fabric en helt anden tilgang. I Fabric, når en "klient" node ønsker at sende en besked til en eller anden kædekode, sender den først den besked til nogle "endosser" noder. Hver af disse noder udfører kædekoden uafhængigt og danner en mening om meddelelsens effekt på den kædekodes database. Disse udtalelser sendes tilbage til klienten sammen med en digital signatur, som udgør en formel "påtegning". Hvis klienten modtager nok påtegninger af det tilsigtede resultat, opretter den en transaktion, der indeholder disse påtegninger, og udsender den til inklusion i kæden.

For at garantere determinisme har hvert stykke kædekode en "godkendelsespolitik", som præcist definerer, hvilket niveau af godkendelse der kræves for at gøre dets transaktioner gyldige. For eksempel kan en kædekodes politik angive, at der kræves godkendelser fra mindst halvdelen af ​​blockchains noder. En anden kan kræve en godkendelse fra en af ​​tre betroede parter. Uanset hvad, kan hver node uafhængigt kontrollere, om de nødvendige påtegninger blev modtaget.

For at tydeliggøre forskellen er determinisme i de fleste blockchain-platforme baseret på spørgsmålet: "Hvad er resultatet af at køre denne kode på disse data?" – og vi skal være helt sikre på, at hver knude vil besvare dette spørgsmål identisk. I modsætning hertil er determinisme i Fabric baseret på et andet spørgsmål: "Er nok støttespillere enige om resultatet af at køre denne kode på disse data?" At svare på det er et ret simpelt spørgsmål om at tælle, og der er ikke plads til, at ikke-determinisme kan snige sig ind.

Fabrics determinisme-ved-godkendelse har en række interessante konsekvenser. For det første kan kædekode skrives på mange forskellige programmeringssprog, da disse ikke behøver at være tilpasset til determinisme (Go, Java og JavaScript er i øjeblikket understøttet). For det andet kan kædekode skjules for nogle af en blockchains deltagere, da den kun skal udføres af klienter og endorsers (selve databasen er globalt synlig). Endelig og mest bemærkelsesværdigt kan Fabric chaincode gøre ting, der er forbudt i andre blockchain-miljøer, såsom at tjekke vejret ved hjælp af en online web-API. I værste fald, hvor hver endorser får et andet svar fra denne API, vil klienten ikke opnå nok påtegninger til et bestemt resultat, og ingen transaktion vil finde sted. (Det skal bemærkes, at Fabric-teammedlemmer stadig anbefaler ved at bruge deterministisk logik inde i kædekoden for at undgå overraskelser.)

Hvilken pris betaler Fabric for denne fleksibilitet? Hvis formålet med en blockchain er at fjerne mellemmænd fra en delt databasedrevet applikation, så tager Fabrics afhængighed af endorsers et stort skridt væk fra det mål. For deltagerne i kæden er det ikke længere nok at følge kædekodens regler – de skal også have visse andre noder til at acceptere, at de har gjort det. Endnu værre, en ondsindet undergruppe af godkendere kunne godkende databaseændringer, der slet ikke følger kædekoden. Dette giver endorsers meget mere magt end validatorerne i almindelige blockchains, som kan censurere transaktioner, men ikke kan overtræde blockchains regler. Blockchain-applikationsudviklere skal beslutte, om denne afvejning giver mening i deres særlige tilfælde.

determinisme	Stof	multikæde	Ethereum	corda
Model	Påtegninger	Tilpasset køretid	Specialbygget VM	Tilpasset køretid
Sprog	Gå + Java + JavaScript	JavaScript	soliditet	Java + Kotlin
Kode synlighed	Modparter + påtegnere	Blockchain	Blockchain	Modparter + pårørende
tvungen	Ingen	Ja	Ja	Nej (for nu)

Konfliktforebyggelse

Indtil videre har vi diskuteret, hvordan forskellige blockchain-platforme udtrykker transaktionsregler i kode, og hvordan de deterministisk sikrer, at hver node anvender disse regler identisk. Nu er det tid til at tale om et tredje aspekt af vores showdown: Hvordan håndterer hver platform muligheden for, at to transaktioner, som er gyldige i sig selv, er i konflikt med hinanden? I det enkleste eksempel, forestil dig, at Alice har $10 i en finansiel bog og udsender to transaktioner - den ene sender $8 til Bob, og den anden sender $7 til Charlie. Det er klart, at kun én af disse transaktioner kan få lov til at lykkes.

To modeller

Vi kan begynde med at gruppere MultiChains og Cordas tilgang til dette problem. Som beskrevet tidligere bruger begge disse en input-output-model til at repræsentere transaktioner og deres regler, hvor hver transaktionsinput bruger et tidligere transaktionsoutput. Dette fører til et simpelt princip til at forebygge konflikter: Hvert output kan kun bruges én gang. MultiChain-filtre og Corda-kontrakter kan stole på deres respektive platforme til at håndhæve denne begrænsning absolut. Da Alices $10 er repræsenteret af en tidligere transaktionsoutput, stopper denne enkelt-forbrugsregel automatisk, at hun sender det til både Bob og Charlie.

På trods af denne lighed er det vigtigt at påpege en vigtig forskel i, hvordan MultiChain og Corda forhindrer konflikter. I MultiChain ser hver node hver transaktion og kan derfor uafhængigt verificere, at hvert output kun bruges én gang. Enhver transaktion, der udfører et dobbeltforbrug i forhold til en tidligere bekræftet transaktion, vil øjeblikkeligt og automatisk blive afvist. I modsætning hertil er der ingen global blockchain i Corda, så "notarer" er forpligtet til at forhindre disse dobbelte udgifter. Hver Corda-outputstatus er tildelt en notar, som skal underskrive enhver transaktion, der bruger det output, hvilket bekræfter, at det ikke er blevet brugt før. En blockchains deltagere skal stole på, at notarer følger denne regel ærligt, og ondsindede notarer kan forårsage kaos efter behag. Som med påtegninger i Fabric er denne "enkelt-forbrug som en serviceDesign har fordele med hensyn til fortrolighed, men genintroducerer mellemled, der går imod blockchain-kornet. (Det er vigtigt at præcisere, at Corda-notarer kan drives af grupper af deltagere ved hjælp af en konsensusalgoritme, så hovedbogens integritet stadig kan beskyttes mod individuelle dårlige aktører).

Lad os gå videre til Ethereum. For at huske bruger Ethereum kontrakter og beskeder i stedet for input og output. Som følge heraf er transaktionskonflikter som Alices to betalinger ikke umiddelbart synlige for blockchain-motoren. I stedet bliver de opdaget og blokeret af kontrakt som behandler transaktionerne, efter deres ordre er bekræftet på kæden. Når du behandler hver af Alices betalinger, verificerer kontrakten, om hendes saldo er tilstrækkelig. Hvis transaktionen, der betaler $8 til Bob, kommer først, vil den blive behandlet som normalt, hvilket efterlader Alice med $2 på sin konto. Som et resultat, når kontrakten behandler den anden transaktion, der betaler $7 til Charlie, ser den, at Alice mangler de nødvendige midler, og transaktionen afbrydes.

Output vs kontrakter

Indtil videre har vi set to forskellige teknikker til at forhindre modstridende transaktioner – enkeltforbrugsoutput i MultiChain og Corda og kontraktbaseret verifikation i Ethereum. Så hvad er bedre?

For at hjælpe med at besvare dette spørgsmål, lad os overveje et eksempel på en "1-af-2 multisignatur"-konto, som rummer $100 på vegne af Gavin og Helen, og som tillader en af ​​dem at bruge disse penge uafhængigt. Gavin instruerer sin ansøgning om at betale $80 til Donna, og et par sekunder senere vil Helen sende $40 til Edward. Da der ikke er tilstrækkelige midler til begge betalinger, ville disse transaktioner uundgåeligt komme i konflikt. I tilfælde af at begge transaktioner udsendes, vil resultatet blive bestemt af den, der kommer først ind i kæden. Bemærk, at i modsætning til Alices eksempel er denne konflikt utilsigtet, da ingen forsøger at bryde applikationens regler – de havde simpelthen uheldig timing.

Når man overvejer sandsynligheden for, at denne konflikt opstår, er nøglespørgsmålet dette: Efter Gavin har sendt sin transaktion ud, hvor lang tid vil det tage Helens node at vide, at hendes betaling muligvis mislykkes? Jo kortere denne periode er, jo større sandsynlighed er der for, at Helen bliver forhindret i at forsøge at betale, hvilket sparer hende og hendes ansøgning fra en efterfølgende overraskelse.

Med input-output-modellen er enhver konflikt mellem transaktioner direkte synlig for blockchain-platformen, da de to transaktioner eksplicit vil forsøge at bruge det samme tidligere output. I MultiChain sker dette, så snart Gavins transaktion har forplantet sig til Helens node, normalt på et sekund eller mindre. I Corda vil outputets notar afvise anmodningen om at underskrive Helens transaktion, da den allerede har underskrevet Gavins, så Helen vil øjeblikkeligt vide, at hendes betaling vil mislykkes. (Selvom Corda-notaren selv er distribueret, skal hun muligvis vente et par sekunder på et svar.) Uanset hvad er der ingen grund til at vente på, at en transaktion bliver bekræftet og bestilt i blockchain.

Hvad med Ethereums model? I dette tilfælde er der ingen umiddelbar måde for blockchain-platformen at vide, at der vil opstå en konflikt. Selvom Helens node kan se Gavins transaktion på netværket, kan den ikke vide, hvordan dette vil påvirke Helens egen transaktion, da disse fra dens perspektiv blot er to beskeder, der sendes til den samme kontrakt. Måske ti sekunder senere, når den endelige bestilling af de modstridende transaktioner er bekræftet på blockchain, vil Helens node genberegne det faktiske i stedet for det forventede resultat, og hendes applikation vil opdatere sin visning i overensstemmelse hermed. I mellemtiden vil både Gavin og Helen blive efterladt i mørket.

Men vi skal ikke slutte heraf, at input-output-modellen altid fungerer bedst. Overvej en variation af vores eksempelscenarie, hvor både Gavin og Helen anmoder om mindre $40-betalinger fra den oprindelige saldo på $100, på nøjagtig samme tid. I input-output-modellen ville disse transaktioner være i konflikt, da de begge bruger den samme databaserække, der indeholder de $100, og kun en af ​​betalingerne ville lykkes. Men i Ethereum vil begge transaktioner blive behandlet med succes, uanset deres endelige rækkefølge, da kontoen indeholder tilstrækkelige midler til begge. I dette tilfælde opfylder Ethereum mere trofast Gavins og Helens intentioner.

Læse-skrive sæt

Lad os endelig tale om Fabric, hvis godkendelsesbaserede tilgang er en hybrid af disse to teknikker. Som forklaret tidligere, når en Fabric "klient" node ønsker at sende en besked til en kontrakt, beder den først nogle godkende noder om at udføre denne besked på dens vegne. De godkendende noder gør det på samme måde som Ethereum - kører kontrakten mod deres lokale database - men denne proces overholdes snarere end umiddelbart anvendt. Hver endorser registrerer det sæt af rækker, der ville blive læst og skrevet, og noterer også den nøjagtige version af disse rækker på det tidspunkt. Dette "læse-skrivesæt" af versionerede rækker er eksplicit refereret i påtegningen og inkluderet i den transaktion, som klienten udsender.

Konflikter mellem stoftransaktioner er løst, når deres ordre er afsluttet i kæden. Hver node behandler hver transaktion uafhængigt, kontrollerer godkendelsespolitikker og anvender de specificerede databaseændringer. Men hvis en transaktion læser eller skriver en databaserækkeversion, der allerede er blevet ændret af en tidligere transaktion, ignoreres den anden transaktion. For at gå tilbage til Alices modstridende betalinger til Bob og Charlie, vil begge disse transaktioner læse og ændre den samme rækkeversion, der indeholder de $10, som Alice startede med. Så den anden transaktion bliver sikkert og automatisk afbrudt.

Fabrics tilgang til konfliktløsning fungerer fint, men med hensyn til ydeevne og fleksibilitet kombinerer den det værste af de to foregående modeller. Fordi påtegninger konverterer transaktioner til specifikke læse-skrivesæt, ville Gavin og Helens samtidige, men kompatible $40-betalinger føre til en konflikt, som Ethereum undgår. Fabric opnår dog ikke hastighedsfordelen ved input-output-modellen, da endossører udfører kontrakter mod den seneste version af databasen bekræftet af blockchain og ignorerer ubekræftede transaktioner. Så hvis Helen starter sin betaling et par sekunder efter Gavin, men før Gavins er blevet bekræftet på blockchain, vil Fabric skabe modstridende transaktioner, som en ren input-output model undgår.

Konfliktforebyggelse	Stof	multikæde	Ethereum	corda
Model	Læse-skrive sæt	Enkeltforbrug	Kontrakttjek	Enkeltforbrug
Verifikation	Independent	Independent	Independent	Betroede notarer
Speed	~10s (bekræftelse)	~1s (udbredelse)	~10s (bekræftelse)	0~5s (notar)

Et komplekst valg

I dette stykke gennemgik vi mange af de forskellige måder, hvorpå Corda, Ethereum, Fabric og MultiChain adresserer de vigtigste udfordringer ved "smarte kontrakter", eller applikationskode, der er indlejret i en blockchain. Og hver platform har forskellige svar på vores tre kernespørgsmål: Hvordan er transaktionsregler repræsenteret? Hvordan udføres kode deterministisk? Og hvordan forebygger vi konflikter?

Så hvem er vinderen af ​​vores smarte kontraktopgør? Det burde være indlysende nu, at der ikke er noget enkelt svar. Hver platform repræsenterer en kompleks multi-vejs afvejning mellem fleksibilitet, enkelhed, ydeevne, disintermediation, sikkerhed og fortrolighed. Så valget af platform for en bestemt applikation skal begynde med en detaljeret forståelse af den pågældende applikations tillidsmodel, de typer transaktioner, den involverer, og deres sandsynlige konfliktmønstre. Hvis du finder nogen, der skubber en specifik smart kontraktløsning, før de kender svarene på disse spørgsmål, foreslår jeg høfligt, men bestemt at insistere på, at de anlægger en "smartere" tilgang.

Skriv eventuelle kommentarer på LinkedIn.