Et detaljeret kig på non-blockchain blockchain
Som tiden går, er blockchain-verdenen blevet adskilt i to adskilte dele. På den ene side har offentlige blockchains med deres tilknyttede kryptovalutaer nydt et bemærkelsesværdigt comeback for nylig, hvor de har præget mange multimillionærer. På den anden side er brugen af godkendte blockchains eller enterprise blockchains vokset stille og roligt, da deres første live-implementeringer på tværs af flere brancher i løbet af 2017.
Et interessant spørgsmål at overveje er det passende niveau af lighed mellem disse to typer kæder. Begge implementerer en delt database ved hjælp af peer-to-peer-netværk, offentlig-privat nøglekryptografi, transaktionsregler og konsensusmekanismer, der kan overleve ondsindede aktører. Det er meget fælles grundlag. Ikke desto mindre har offentlige og private blockchains forskellige krav med hensyn til fortrolighed, skalerbarhed og styring. Måske peger disse forskelle på behovet for radikalt divergerende designs.
corda platform, udviklet af R3 bankkonsortium, indtager en klar holdning til dette spørgsmål. Mens nogle aspekter var inspireret af offentlige blockchains, blev Corda designet fra bunden baseret på behovene hos R3's medlemmer. Faktisk, selvom R3 stadig bruger ordet "blockchain" ekstensivt for at hjælpe med at markedsføre deres produkt, har Corda ingen kæde af blokke overhovedet. Mere end nogen anden "distribueret hovedbog"-platform, jeg er bekendt med, afviger Corda radikalt fra arkitekturen i konventionelle blockchains.
Mit mål med dette stykke er at forklare disse forskelle og diskutere deres implikationer, på godt og ondt. Faktisk er godt og dårligt den forkerte måde at sige det på, fordi det mere interessante spørgsmål er "Godt og dårligt for hvad?" Denne artikel er langt fra kort. Men ved afslutningen af det håber jeg, at læserne vil få en vis forståelse for forskellene i Corda og deres deraf følgende afvejninger. Corda er vigtig, fordi dens designbeslutninger bringer mange af dilemmaerne ved virksomheds blockchains i skarp relief.
En sidste ting, før vi dykker ind. Som administrerende direktør for virksomheden bag multikæde, en populær virksomheds blockchain-platform, hvorfor skriver jeg så dybdegående om et angiveligt konkurrerende produkt? Standardårsagen ville være at argumentere for MultiChains overlegenhed, men det er ikke min motivation her. Faktisk ser jeg ikke Corda og MultiChain som konkurrenter, for de er fundamentalt forskellige med hensyn til design, arkitektur og publikum. Corda og MultiChain konkurrerer på samme måde som krydstogtskibe og jetski – mens begge transporterer mennesker ad søvejen, er der næsten ingen virkelige situationer, hvor begge kan bruges.
På en mere personlig bemærkning har jeg lært meget af Cordas tekniske ledelse i løbet af de sidste par år, hvad enten det er gennem møder, korrespondance eller deres offentlige skrifter, hvoraf meget fandt sted, før de kom til R3. Noget af min interesse for Corda stammer fra den respekt, jeg har for dette hold, og alene af denne grund er Corda værd at studere for alle, der søger en forståelse af det distribuerede hovedbogsfelt.
Introduktion af blockchains
For at forstå Corda er det nyttigt at starte med konventionelle blockchains. Formålet med en blockchain er at gøre det muligt for en database eller hovedbog at blive direkte og sikkert delt af ikke-tillidsfulde parter. Dette står i kontrast til centraliserede databaser, som er lagret og kontrolleret af en enkelt organisation. En blockchain har flere "noder", som hver gemmer en kopi af databasen og kan tilhøre en anden organisation. Noder forbinder sig med hinanden på en tæt peer-to-peer måde ved hjælp af en "sladderprotokol", hvor hver node konstant fortæller sine jævnaldrende alt, hvad den lærer. Som et resultat kan enhver node hurtigt udsende en besked til hele netværket via mange alternative veje.
En database, uanset om den er centraliseret eller blockchain-drevet, begynder i en tom tilstand og opdateres via "transaktioner". En transaktion er defineret som et sæt databaseændringer, der er "atomiske", hvilket betyder, at de lykkes eller mislykkes som helhed. Forestil dig en database, der repræsenterer en finansiel finans, med en række pr. konto. En transaktion, hvor Alice betaler $10 til Bob, har tre trin: (1) verificere, at Alices konto indeholder mindst $10, (2) trække $10 fra Alices konto, og (3) tilføje $10 til Bobs konto. Som et grundlæggende krav skal enhver databaseplatform sikre, at ingen transaktion forstyrrer en anden. Denne "isolation" opnås ved at låse rækkerne for både Alice og Bob, mens betalingen er i gang. Enhver anden transaktion, der involverer disse rækker, skal vente, indtil denne er afsluttet.
I en blockchain behandler hver node uafhængigt hver transaktion på sin egen kopi af databasen. Transaktioner oprettes hvor som helst på netværket og forplantes automatisk til alle andre noder. Da de organisationer, der kører noder, kan have forskellige (eller endda modstridende) interesser, kan de ikke stole på, at hinanden handler retfærdigt. Blockchains har derfor brug for regler, der definerer, om en bestemt transaktion er gyldig eller ej. I en delt finansiel hovedbog forhindrer disse regler brugere i at bruge hinandens penge eller fremtrylle penge fra den blå luft.
Sammen med reglerne, der bestemmer transaktionens gyldighed, skal blockchains også definere, hvordan transaktioner vil blive bestilt, da denne bestilling i mange tilfælde er kritisk. Hvis Alice har $15 og forsøger at sende $10 til både Bob og Charlie i to separate transaktioner, kan kun én af disse betalinger lykkes. Selvom vi måske gerne vil sige, at den første transaktion har forrang, har et peer-to-peer-netværk ingen objektiv definition af "først", da meddelelser kan ankomme til forskellige noder i forskellige rækkefølger.
Transaktionsregler
I en generel forstand er oplysningerne i enhver database opdelt i poster eller "rækker", og en transaktion kan gøre tre forskellige ting: slette rækker, oprette rækker og/eller ændre rækker. Disse kan reduceres yderligere til to, da ændring af en række svarer til at slette den række og oprette en ny i stedet for. For at gå tilbage til Alices betaling til Bob, slettes hendes række, der indeholder $15, og der oprettes to nye rækker – den ene indeholder $10 til Bob og den anden med $5 i "ændring" for Alice.
Efter bitcoins og Cordas terminologi betegner vi rækkerne, der er slettet af en transaktion, som dens "input", og dem, der er oprettet som dens "outputs". Enhver række, der er slettet af en transaktion, skal være oprettet af en tidligere transaktion. Derfor forbruger (eller "bruger") hver transaktionsinput en tidligere transaktions output. Det opdaterede indhold af databasen er defineret af sættet af "ubrugte transaktionsoutput" eller "UTXO'er".
I en blockchain er en transaktion gyldig, hvis den opfylder følgende tre betingelser:
- Korrekthed. Transaktionen skal repræsentere en legitim transformation fra input til output. For eksempel, i en finansiel hovedbog, skal den samlede mængde af midler i inputs matche totalen i output for at forhindre, at penge på magisk vis dukker op eller forsvinder. De eneste undtagelser er særlige "udstedelses"- eller "pensioneringstransaktioner", hvor midler eksplicit tilføjes eller fjernes.
- Tilladelse. Transaktionen skal godkendes af ejeren af hvert output, der forbruges af dets input. I en finansiel hovedbog forhindrer dette deltagere i at bruge hinandens penge uden tilladelse. Transaktionsautorisation administreres ved hjælp af asymmetrisk (eller offentlig-privat nøgle) kryptografi. Hver række har en ejer, identificeret ved en offentlig nøgle, hvis tilsvarende private nøgle holdes hemmelig. For at blive godkendt skal en transaktion være digitalt underskrevet af ejeren af hver af dens input. (Bemærk, at rækker også kan have mere komplekse "multisignatur"-ejere, for eksempel hvor to ud af tre parter kan godkende deres brug).
- Entydighed. Hvis en transaktion forbruger et bestemt output, så kan ingen anden transaktion forbruge det output igen. Sådan forhindrer vi Alice i at foretage modstridende betalinger til både Bob og Charlie. Mens transaktionerne for begge disse betalinger kunne være korrekte og godkendte, sikrer entydighedsreglen, at kun den ene vil blive behandlet af databasen.
I en konventionel blockchain tjekker hver node hver transaktion i forhold til disse tre regler. Senere vil vi se, hvordan Corda fordeler dette ansvar anderledes.
Byggesten
En blockchain er bogstaveligt talt en kæde af blokke, hvor hver blok linker til den forrige via en "hash", der unikt identificerer dens indhold. Hver blok indeholder et ordnet sæt af transaktioner, som ikke må være i konflikt med hinanden eller med dem i tidligere blokke, samt et tidsstempel og anden information. Ligesom transaktioner forplanter blokke sig hurtigt på tværs af netværket og verificeres uafhængigt af hver node. Når en transaktion dukker op i en blok, bliver den "bekræftet", hvilket får noder til at afvise enhver modstridende transaktion.
Hvem er ansvarlig for at skabe disse blokke, og hvordan kan vi være sikre på, at alle noder bliver enige om den autoritative kæde? Dette spørgsmål om "konsensusalgoritmer" er et stort emne i sig selv, fyldt med vidunderlige akronymer som PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance) og DPoS (Delegated Proof of Stake). Vi kommer ikke ind på alt det her. Det er tilstrækkeligt at sige, at godkendte blockchains til virksomheder bruger en form for afstemningsordning, hvor stemmer gives til "validator noder", som er kollektivt ansvarlige. Ordningen sikrer, at så længe et godt flertal af validatorknudepunkter fungerer korrekt og ærligt, vil transaktioner komme ind i kæden i en (tæt på) fair rækkefølge, tidsstempler vil være (ca.) korrekte, og bekræftede transaktioner kan ikke efterfølgende tilbageføres.
Før jeg diskuterer nogle af udfordringerne ved blockchains, vil jeg gerne præcisere tre yderligere punkter. For det første, mens jeg bruger en finansiel hovedbog som eksempel i hele dette stykke, understøtter input-output-modellen for transaktioner en meget bredere række af brugssager. Hver række kan indeholde et rigt dataobjekt (tænk JSON), der indeholder mange forskellige typer information - faktisk bruger Corda ordet "tilstand" i stedet for "række" af denne grund. Rigere stater ændrer intet grundlæggende ved transaktionsregler: korrekthed er stadig defineret i form af input og output, autorisation er stadig påkrævet for hvert input, og unikhed sikrer, at hvert output kun kan bruges én gang.
For det andet er der mange blockchain-brugstilfælde, hvor rækker kun oprettes i databasen og aldrig slettes. Disse applikationer vedrører generel datalagring, tidsstempling og notarisering, snarere end at vedligeholde en form for hovedbog, der er i forandring. I disse kun dataapplikationer tilføjer transaktioner data i deres output, men forbruger ingen i deres input, hvilket gør det muligt at forenkle reglerne for korrekthed, autorisation og unikhed. Selvom data-only use cases er et stigende fokus i vores egen udvikling hos MultiChain, nævner jeg dem kun i flæng her, da Corda tydeligvis ikke er designet med dem i tankerne.
Endelig er det værd at bemærke, at nogle blockchain-platforme ikke bruger en input-output-model. Ethereum præsenterer et alternativt paradigme, hvor kæden styrer en virtuel computer med en global tilstand, der styres af "kontrakter", og transaktioner ikke forbindes eksplicit med hinanden. En diskussion af Ethereums model i tilladte blockchains er uden for vores rækkevidde her, men se denne artikel for en detaljeret forklaring og kritik. En vigtig fordel ved input-output paradigmet er, at de fleste transaktioner kan behandles parallelt og uafhængigt af hinanden. Denne egenskab er afgørende for Corda, som vi vil se senere.
Blockchain udfordringer
Lad os forestille os, at verdens banker oprettede en delt hovedbog for at repræsentere ejerskab, overførsel og udveksling af en række finansielle aktiver. I teorien kunne dette implementeres på en almindelig blockchain, som beskrevet ovenfor. Hver række ville indeholde tre kolonner – et aktiv-id, såsom GOOG eller USD, den ejede mængde og ejerens offentlige nøgle. Hver transaktion ville overføre et eller flere aktiver fra dets input til dets output, med særlige tilfælde for udstedelse og tilbagetrækning.
Hver bank i netværket ville køre en eller flere noder, som forbinder til de andre, udbreder og verificerer transaktioner. Seniormedlemmer vil fungere som validatorer med det kollektive ansvar for at bekræfte, bestille og tidsstemple transaktioner. Enhver validators ukorrekte opførsel vil være synlig for alle noder i netværket, hvilket fører til mistillidsvotum, forvisning og/eller retssager. Med alt dette på plads, kunne ethvert finansielt aktiv flyttes over hele verden på få sekunder, med reglerne for korrekthed, autorisation og unikhed, der garanterer hovedbogens integritet.
Hvad er der galt med dette billede? Faktisk er der tre problemer: skalerbarhed, fortrolighed og interoperabilitet. Spørgsmålet om skalerbarhed er simpelt nok. Vores foreslåede interbank-blockchain vil kræve, at hvert medlem verificerer, behandler og opbevarer enhver transaktion, der udføres af alle banker i verden. Selv hvis dette ville være teknisk muligt for de største finansielle institutioner, ville omkostningerne ved beregning og opbevaring skabe en betydelig barriere for mange. Vi vil helt sikkert foretrække et system, hvor deltagerne kun ser de transaktioner, som de umiddelbart er involveret i.
Men lad os lægge skalerbarheden til side, da det i sidste ende kan løses ved hjælp af dyre computere og smart teknik. Et mere grundlæggende spørgsmål er fortrolighed. Selvom det kan lyde utopisk for enhver transaktion at være synlig overalt, er sådan radikal gennemsigtighed i den virkelige verden en ikke-starter med hensyn til konkurrence og regulering. Hvis JP Morgan og HSBC udveksler et par aktiver, er det usandsynligt, at de ønsker, at Citi og Bank of China skal se, hvad de gjorde. Hvis transaktionen blev gennemført på vegne af disse bankers kunder, kan det være ulovligt for dem at afsløre det på denne måde.
En foreslået løsning på problemet med fortrolighed er "kanaler", som implementeret i Hyperledger Fabric. Hver kanal har visse medlemmer, som er en delmængde af noderne i netværket som helhed. En kanals transaktioner er kun synlige for dens medlemmer, så hver kanal effektivt fungerer som en separat blockchain. Selvom dette hjælper med fortroligheden, underminerer det også hele pointen med øvelsen. Aktiver kan ikke flyttes fra en kanal til en anden uden hjælp fra en betroet mellemmand, som er aktiv på begge. Vanskeligheden ved denne tilgang blev for nylig fremhævet af SWIFT's afstemning proof-of-concept, som anslog, at der ville være behov for over 100,000 kanaler i produktionen. Det er 100,000 øer, hvor aktiver ikke kan flyttes direkte.
I tilfælde, hvor der kun bruges data, hvor transaktioner ikke forbruger data i input, kan fortrolighedsproblemet omgås ved at kryptere eller hash dataene i output og levere dekrypteringsnøglen eller uhashed data uden for kæden. Men for en transaktion, hvis input forbruger andre transaktioners output, skal hver node se disse input og output for at validere transaktionen. Mens avancerede kryptografiske teknikker som f.eks fortrolige aktiver , nul viden beviser er udviklet til delvist eller fuldstændigt at løse dette problem for finansregnskaber, pålægger disse en betydelig præstationsbyrde og/eller kan ikke generaliseres til nogen korrekthedsregel.
Lad os endelig tale om interoperabilitet. I en ideel verden ville enhver bank straks tilslutte sig vores globale blockchain den dag, den blev lanceret. I virkeligheden ville flere blockchains imidlertid blive vedtaget af forskellige grupper af banker, baseret på geografi eller allerede eksisterende forhold. Over tid vil et medlem af en gruppe måske ønske at begynde at handle med et medlem af en anden ved at overføre et aktiv mellem kæder. Ligesom med kanaler, kan dette kun opnås ved hjælp af en betroet mellemmand, der besejrer blockchains formål.
Corda sigter mod at løse disse indbyrdes forbundne problemer med skalerbarhed, fortrolighed og interoperabilitet via en radikal gentænkning af, hvordan distribuerede hovedbøger fungerer.
Cordas delvise syn
Den grundlæggende forskel i Corda er let at forklare: Hver node ser kun nogle, snarere end alle, af de transaktioner, der behandles på netværket. Mens en enkelt logisk og konceptuel hovedbog er defineret af alle disse transaktioner, ser ingen individuel node denne hovedbog i sin helhed. For at drage en sammenligning, på et hvilket som helst tidspunkt, er hver dollarseddel i verden et bestemt sted, men ingen ved, hvor de alle er.
Så hvilke transaktioner ser en Corda-node? Først og fremmest dem, som den er direkte involveret i, fordi den ejer en af transaktionens input eller output. I en finansiel hovedbog inkluderer dette hver transaktion, hvor en node sender eller modtager penge. Lad os sige, at Alice opretter en transaktion, som bruger hendes $15 i en input og har to output – en med $10 for mig, og den anden med $5 i "change" for hende. Efter at Alice har sendt mig denne transaktion, kan jeg kontrollere den for rigtighed og autorisation, og verificere, at input og output balancerer, og at Alice har underskrevet.
Denne transaktion i sig selv er dog ikke nok. Jeg er også nødt til at bekræfte, at Alices input-tilstand til $15 virkelig eksisterer, og at hun ikke bare fandt på det. Det betyder, at jeg skal se den transaktion, der skabte denne tilstand, og også kontrollere den for rigtighed og godkendelse. Hvis denne tidligere transaktion, som sendte Alice $15, har en $10 input tilhørende Denzel og en anden $5 input fra Eric, så skal jeg også verificere de transaktioner, der skabte disse. Og så fortsætter det, helt tilbage til den oprindelige "udstedelses"-transaktion, hvor aktivet blev oprettet. Antallet af transaktioner, jeg skal verificere, afhænger af, hvor mange gange aktiverne har skiftet hænder og omfanget af baglæns forgrening.
Da Corda-noder ikke automatisk ser hver transaktion, hvordan får de så dem, de har brug for? Svaret kommer fra afsenderen af hver ny transaktion. Før Alice opretter en transaktion, der bruger hendes $15, skal hun allerede have bekræftet transaktionen, hvor hun modtog den. Og da Alice må have anvendt den rekursive teknik ovenfor, vil hun have en kopi af hver transaktion, der er nødvendig for denne verifikation. Bob anmoder blot om disse transaktioner fra Alice som en del af deres interaktion. Hvis Alice ikke reagerer korrekt, konkluderer Bob, at Alice forsøger at narre ham, og afviser den indgående betaling. I det tilfælde, hvor Bob får tilsendt en ny transaktion, hvis input har flere ejere, kan han få de nødvendige beviser fra hver.
Introduktion til notarer
Indtil videre har vi forklaret, hvordan Bob kan verificere rigtigheden og godkendelsen af en indgående transaktion, herunder rekursivt spore dens inputs oprindelse. Men der er endnu en regel, vi skal tænke på: unikhed. Lad os sige, at Alice er ondsindet. Hun kan generere en transaktion, hvor hun betaler $10 til Bob, og en anden, hvor hun betaler de samme $10 til Charlie. Hun kan sende disse transaktioner til henholdsvis Bob og Charlie sammen med et fuldstændigt bevis for rigtigheden og autorisation af hver. Mens begge transaktioner er i konflikt med hinanden ved at forbruge den samme tilstand, er der ingen måde for Bob og Charlie at vide dette.
Konventionelle blockchains løser dette problem ved at hver node ser hver transaktion, hvilket gør konflikter nemme at opdage og afvise. Så hvordan løser Corda, med sin delvise transaktionssynlighed, det samme problem? Svaret er med hjælp fra en "notar". En notar er en betroet part (eller parter, der arbejder sammen), som garanterer, at en bestemt stat kun forbruges én gang. Hver stat har en specifik notar, som skal underskrive enhver transaktion, hvor denne stat forbruges. Når en notar har gjort dette, må den ikke underskrive en anden transaktion for samme stat. Notarer er netværkets vogtere af transaktionens unikke karakter.
Mens hver stat kan have en anden notar, skal alle de stater, der forbruges af en bestemt transaktion, tildeles den samme. Dette undgår problemer relateret til deadlocks og synkronisering, som bør være velkendte for dem med distribueret databaseerfaring. Lad os sige, at Alice og Bob bliver enige om at bytte Alices $10 til Bobs £7. Transaktionen for denne udveksling skal underskrives af notarerne i begge stater, men hvilken går først? Hvis Alices notar underskriver, men Bobs fejler af en eller anden grund, vil Alice stå tilbage med en ufuldstændig transaktion og kan aldrig bruge sine $10 igen. Hvis Bob tegner først, bliver han på samme måde eksponeret. Selvom vi måske gerne vil have notarer til blot at arbejde sammen, kræver dette i praksis gensidig tillid og brug af en konsensusprotokol, komplikationer som Cordas designere valgte at undgå.
Hvis stater med forskellige notarer er påkrævet som input til en enkelt transaktion, udfører deres ejere først særlige "notarskifte"-transaktioner, som flytter en stat fra en notar til en anden uden at ændre noget andet. Så når parter bygger en transaktion med flere input, skal de først blive enige om, hvilken notar der skal bruges, og derefter udføre de nødvendige notarændringer. Mens udvikleren i mig følte et lille stik af smerte, da han læste om denne løsning, er der ingen grund til, at det ikke vil virke, så længe notarerne spiller med.
Det bør også præciseres, at selv om hver notar er en enkelt logisk aktør med hensyn til at underskrive transaktioner, behøver den ikke at være under kontrol af en enkelt part. En gruppe af organisationer kunne drive en notar i fællesskab ved at bruge en passende konsensusprotokol, hvor et flertal af deltagerne er nødvendige for at generere en gyldig signatur. Dette ville forhindre en enkelt ondsindet part i at underminere unikhed ved at underskrive transaktioner, der er i konflikt. I teorien kunne vi endda tillade alle noder i netværket at deltage i denne form for delt notarisering, selvom vi i så fald ville være mere eller mindre tilbage til en konventionel blockchain.
Tager score
Lad os opsummere de vigtigste forskelle mellem Corda og konventionelle blockchains. I Corda er der ingen samlet blockchain, som indeholder alle de bekræftede transaktioner. Noder ser kun de transaktioner, som de er direkte involveret i, eller som de er afhængige af historisk. Noder er ansvarlige for at kontrollere transaktionernes rigtighed og autorisation, men er afhængige af betroede notarer til at verificere unikhed.
Selvfølgelig er der meget mere i Corda end dette: brugen af digitale certifikater til at autentificere identitet, "netværkskort" for at hjælpe noder med at finde og stole på hinanden, "kontrakter" pr. stat, som definerer korrekthed fra hver stats perspektiv, en deterministisk version af Java Virtual Machine, som udfører disse kontrakter, "flows", som automatiserer transaktionsforhandlinger, "tidsvinduer", som begrænser transaktioner efter tid, "orakler", der attesterer eksterne fakta og "CorDapps", som samler mange ting sammen for nem distribution . Selvom hver af disse funktioner er interessante, kan ækvivalenter for alle findes i andre blockchain-platforme. Mit mål i denne artikel er at fokusere på det, der gør Corda unik.
Så lever Corda op til sit løfte? Løser det skalerbarheden, fortroligheden og interoperabilitetsproblemerne for blockchains? Og hvor meget af en pris betaler Corda for at træffe sine særlige valg?
Nogle gange mere skalerbar
Lad os starte med skalerbarhed. Her fremstår Cordas fordel klar, da noder kun ser nogle af transaktionerne i et netværk. I en almindelig blockchain er den maksimale gennemstrømning begrænset af hastigheden af den langsomste node i behandlingen af transaktioner. I modsætning hertil kunne et Corda-netværk behandle en million transaktioner i sekundet, mens hver node kun ser en lille brøkdel af det. Skalerbarhed omfatter også notarer, da opgaven med at underskrive transaktioner for unikhed kan spredes mellem mange forskellige notarer, som hver især er ansvarlige for en lille del af netværkets stater.
Når det er sagt, er der én situation, hvor Corda klarer sig langt dårligere end en blockchain. Dette sker, når en node modtager en ny transaktion, som afhænger af mange andre transaktioner, den ikke har set før. Forestil dig et meget likvidt aktiv, der blev udstedt for 10 år siden, og som skifter hænder cirka hvert femte minut. Vejen fra enhver ny transaktion tilbage til dette aktivs udstedelse vil være over en million transaktioner lang. Når en node modtager dette aktiv for første gang, skal den hente disse millioner transaktioner fra afsenderen og bekræfte hver enkelt efter tur. Ved en (temmelig optimistisk) hastighed på 1000 transaktioner i sekundet ville der være 17 minutters forsinkelse, før modtageren kunne sende aktivet videre – klart for lang til noget så likvidt.
Hvorfor lider blockchains ikke af dette problem? Fordi noder ser og verificerer hver transaktion, efterhånden som den finder sted, opdaterer de konstant status for hovedbogen og ved præcis, hvem der ejer hvert aktiv på nuværende tidspunkt. Selvom en node aldrig har haft et bestemt aktiv før, kan den øjeblikkeligt bekræfte transaktionen, hvor den modtager det, og derefter straks sende den videre. For at sige det på en anden måde skal blockchain-noder verificere transaktioner, der måske ikke er relevante for dem, men ved at gøre det forudbetaler de omkostningerne ved at tjekke enhver fremtidig transaktion, der måtte komme ind. Selvom Corda-noder generelt er mindre travle, kører de risiko for at skulle udføre et enormt arbejde med et øjebliks varsel. Der er ikke noget skalerbart ved det.
Noget mere fortroligt
Lad os gå videre til fortrolighed. I Corda ser noder kun nogle af et netværks transaktioner, hvilket unægteligt betyder bedre privatliv end konventionelle blockchains. Ikke desto mindre er Corda langt fra at løse fortrolighedsproblemet, fordi noder stadig ser nogle transaktioner, der ikke er deres sag. For at tage et simpelt eksempel, hvis Alice betaler Bob $10, så sender Bob disse $10 videre til Charlie, Charlies node skal vises transaktionen mellem Alice og Bob, selvom det ikke involverer ham. På det tidspunkt, hvor Alice betalte Bob, havde hun ingen mulighed for at vide, hvem der kunne se denne transaktion i fremtiden, og enhver kunne få tilsendt den til enhver tid.
For at være retfærdig er Cordas udviklere opmærksomme på dette problem og diskuterer det i kapitel 15 i deres Teknisk hvidbog. Papiret foreslår enkle strategier såsom brug af flere offentlige nøgler pr. enhed eller reduktion af sporbarhed ved at returnere aktiver til udstedere til genudstedelse (svarende til kryptovaluta-"møntblandere"). Den nævner også mere avancerede fremtidige muligheder såsom at bruge Tor-lignende anonymiseringsnetværk til at skjule deltagernes IP-adresser og udnytte nul viden beviser eller Intels sikre enklaver at validere transaktioner uden at afsløre deres indhold. Selvom alle disse forslag er gyldige, kan de også anvendes på almindelige blockchains ved hjælp af input-output-modellen, og de har faktisk været i kryptovalutaer som Dash, Zcash og Verge. Så Cordas eneste unikke fordel med hensyn til fortrolighed forbliver dens reducerede transaktionssynlighed – i bedste fald en ufuldstændig løsning.
Alt sammen i avlen
For bedre at forstå Cordas skalerbarhed og fortrolighedsfordel bør vi bemærke, hvordan dette afhænger af tætheden og overlapningen af relationerne mellem transaktioner. Forestil dig et "slægtstræ" af de transaktioner, der udføres i et netværk, hvor hver transaktions forældre er de tidligere, som den umiddelbart afhænger af. Specifikt, når en transaktions output forbruges af en andens input, tegner vi en pil, der repræsenterer forholdet fra forælder til barn. Transaktioner kan have et hvilket som helst antal forældre og børn, selvom vi i de fleste tilfælde kun forventer nogle få.
På baggrund af dette stamtræ definerer vi forfædrene til en transaktion som dens forældre, bedsteforældre, oldeforældre og så videre. Vores træs "Adam og Eva" er de udstedelsestransaktioner, der skabte aktiver og ikke har deres egne forældre. Som i almindelige stamtræer kan to transaktioner ikke være forfædre til hinanden. I formelle datavidenskabelige termer er dette en rettet acyklisk graf eller DAG, hvor herkomst er defineret som den transitive lukning af forældrerelationen.
Husk, at når en Corda-node behandler en transaktion, skal den downloade og verificere alle transaktionens forfædre, bortset fra dem, den har set før. Så hvis stamtræet er dybt, kan nye indgående transaktioner have et stort antal forfædre, der skal verificeres, hvilket udløser Cordas skalerbarhedsproblem. Derudover, hvis stamtræet indeholder en høj grad af krydsning, kan en ny transaktions forfædre inkludere mange eller de fleste tidligere transaktioner i netværket. I dette tilfælde vil Corda kun give en lille fordel med hensyn til privatlivets fred.
I modsætning hertil, hvis stamtræet af transaktioner er lavvandet og indeholder mange afbrudte øer, der ikke interagerer med hinanden, kommer Cordas fordele til syne. Noder behøver aldrig at verificere et stort antal transaktioner på én gang, og de kan holdes i mørke om størstedelen af transaktioner, som ikke er relateret til deres egne. Hvis det bruges som finansiel hovedbog, kan vi sige, at Corda er ideel til stærkt fragmenterede markeder, hvis aktiver sjældent skifter hænder.
Interoperabilitet for at vinde
Her er et område, hvor Corda virkelig skinner. Forestil dig to separate Corda-netværk med forskellige sæt aktiver og deltagere. På et tidspunkt ønsker en deltager i det ene netværk at sende et aktiv til nogen i det andet. I modsætning til konventionelle blockchains er der ingen forventning om, at en node vil have verificeret alle tidligere transaktioner, så den node, der modtager dette nye aktiv, vil ikke opleve noget usædvanligt. Når transaktionen kommer ind, anmoder og verificerer den blot den relevante historie, uden at være klar over, at dette er fra et "separat netværk". For at strække en kliché kan vi sige, at der ikke er nogen fremmede i Corda – kun venner, der endnu ikke har mødt hinanden.
I virkeligheden er tingene ikke helt så enkle. Enhver Corda-knude bestemmer eksplicit, hvilke notarer der skal stole på, da en notar, der ikke opfører sig dårligt, kan forårsage økonomisk kaos. Derudover skal noder have et "certifikat" givet af en "dørmand" for at oprette forbindelse til andre noder i et netværk, da vi ikke kan tillade tilfældige medlemmer af offentligheden at begynde at oprette forbindelse til noder og spilde deres ressourcer. Så før en node på ét netværk kan begynde at anmode om og verificere transaktioner fra et andet netværk, skal den tilføjes til sin liste over betroede notarer og få det relevante certifikat. Selvom dette involverer en vis manuel konfiguration og administration, er det det minimum, der kan forventes for et system af denne art. Samlet set er det rimeligt at konkludere, at interoperabilitet er Cordas store sejr over konventionelle blockchains.
Genformidling
Det er tid til at tale om disintermediation, elefanten på Cordas værelse. I forbindelse med blockchains betyder disintermediation, at enhver deltager kan verificere hver transaktion for sig selv uden at være afhængig af tredjeparters gode opførsel. I min udsigt, er disintermediation kernefordelen ved blockchains i forhold til centraliserede databaser, hvor alle deltagere er helt afhængige af databasens ejer. Hvis deltagerne i et netværk har en mellemmand, de kan stole på, og der ikke er nogen forretningsmæssig eller lovgivningsmæssig begrundelse for disintermediation, så er der ingen pointe i at bruge en blockchain. Centraliserede databaser er hurtigere og mere effektive og undgår spørgsmålet om transaktionsfortrolighed.
Så opnår deltagerne i et Corda-netværk disintermediation? Nå, ja, ja og ja men nej. For transaktionslevering sætter Corda kryds i boksen, da de involverede knudepunkter i en transaktion taler direkte med hinanden. Med hensyn til korrekthed og autorisation er den også i god stand, da hver node er i stand til at kontrollere disse egenskaber for sig selv. Når det kommer til at verificere transaktionens unikke karakter, fejler Corda imidlertid disintermediation-testen. Noder kan ikke bekræfte det unikke for sig selv, da de ikke ser alle transaktioner i netværket, og opgaven er outsourcet til betroede notarer.
Corda-deltagere er prisgivet notarer på en række måder. For det første kan en notar nægte at underskrive en transaktion, selvom dens input forbruger output, der aldrig har været brugt før. I en finansiel hovedbog forhindrer dette nogen i at sende eller udveksle deres aktiver. For det andet kunne en notar underskrive to modstridende transaktioner, som forbruger det samme output, hvilket får to parter til at tro, at de modtog det samme. Da begge modtagere af duplikataktivet sender eller udveksler det i yderligere transaktioner, spredes smitten, og hele hovedbogens integritet kan snart blive undermineret. Endelig kan en notar nægte at underskrive en "notarændring"-transaktion for at overføre en stat til en konkurrent, der reelt holder aktivejeren som gidsel. For en transaktion, der involverer stater med forskellige notarer, er det langt at sige, at Corda introducerer mere formidling end en centraliseret database, fordi flere tredjeparter har kontrol.
For at sætte denne risiko i perspektiv, er det værd at huske på, at Corda-notarer ikke behøver at blive kontrolleret af en enkelt organisation. De kan også bestå af en gruppe af noder, der kører en konsensusalgoritme, der kan tolerere dårlige skuespillere. I dette tilfælde vil en notar fungere fint, så længe de fleste af dens medlemsknudepunkter følger reglerne. På overfladen lyder dette snarere som en blockchain, hvilket afhænger af, at et flertal af validatorer opfører sig godt. Men i Corda er risiciene betydeligt højere. Det værste en kabal af blockchain-validatorer kan gøre, er at forhindre nogle transaktioner i at blive bekræftet. En ondsindet Corda-notar kan også underskrive modstridende transaktioner og sende hovedbogen ned i en inkonsekvent afgrund.
Et mærkeligt dyr
Når man sætter skalerbarhed, fortrolighed, interoperabilitet og disintermediation sammen, er det svært at nå frem til en simpel dom om Corda-alternativet. Alt i alt, set fra denne blockchain-platformudviklers perspektiv, virker det, ja... overbevisende, men mærkeligt. Designet til at løse de vigtigste problemer med skalerbarhed og fortrolighed, er Cordas løsninger ufuldstændige og afhænger i høj grad af formen på transaktionens "slægtstræ". Men for at opnå disse delvise sejre mister Corda en kerneegenskab ved blockchains - fjernelse af transaktionsformidlere. Selvom Corda utvivlsomt udmærker sig ved interoperabilitet, er det virkelig nok?
Hvis vi ville være skeptiske, kunne vi sige, at Cordas team fik en umulig opgave – at designe en variant af blockchain, der ville passe til bankerne, der finansierede R3. Men den vigtigste fordel ved blockchains i forhold til centraliserede databaser er disintermediation, som kommer til prisen for reduceret fortrolighed. Hvordan kunne denne afvejning give mening for finansielle institutioner, der tjener penge ved at optræde som mellemmænd og er meget følsomme over for privatlivets fred? Set i dette lys kan man hylde Corda som et heroisk, men i sidste ende utilfredsstillende kompromis mellem R3's medlemmers ønske om at gøre noget blockchainy, og de kommercielle og regulatoriske begrænsninger, som de eksisterer under.
Depotmand 2.0
Men jeg foretrækker en mere positiv tilgang. I stedet for at fokusere på sammenligningen med blockchains, kan vi se Corda som en stor teknisk opgradering til den økonomiske status quo. Du skal blot udskifte ordet "notar" med "forvalter", og det hele falder ret pænt på plads. (EN kontoførende er et pengeinstitut, der besidder aktiver på andres vegne.) Ja, notarer er mellemmænd, som både kan blokere for transaktioner og tillade konflikter, men det gælder også for nutidens depoter. En "notarskiftetransaktion" kan ses som overførsel af aktiver fra en depotbank til en anden. Og Corda-transaktioner underskrives af kun én notar af samme grund, som vi gerne vil have, at udveksling af aktiver finder sted ét sted – for at forhindre, at begge parter er ude af lommen.
Ser vi på Corda på denne måde, kan vi se, hvordan den forbedres i forhold til den traditionelle frihedsberøvelsesmodel:
- Den definerer et standard beregningsparadigme og -format til at udtrykke finansielle aktiver og andre kontraktlige forpligtelser.
- Det leverer open source-software til at fortolke og udføre disse forpligtelser, hvilket garanterer, at transaktionsparter og depotforvaltere er enige om resultatet af hver transaktion.
- Komplekse flerpartsforvaltere, der beskytter mod misbrug, kan oprettes (kun ved hjælp af software!) ved at udnytte fejltolerante konsensusalgoritmer.
- En standardproces ("notarskifte") er defineret for overførsel af aktiver mellem depotbanker, og ingen depotbank må nægte.
- Depotselskaber kan ikke bruge et aktiv under deres varetægt uden ejerens samtykke, da transaktioner også skal underskrives af deres inputs ejere.
Jeg er langt fra en bankmand, men for mig lyder det hele ret lovende. Og måske kunne Corda lige så godt anvendes til andre industrier med komplekse depotstrukturer, såsom forsikring eller shipping. Selvom Cordas design muligvis ikke giver den fulde disintermediation af en blockchain, foreslår det en stærk transformation for industrier, hvor formidlere spiller en væsentlig rolle.
Når vi først går ned i denne tankegang, opstår der uundgåeligt et spørgsmål: Hvis vi allerede har tillid til notarer med arbejdet på liv og død med at verificere unikhed, hvorfor så ikke stole på dem for korrekthed og autorisation også? Corda har allerede ideen om en "validerende notar", som fuldt ud verificerer transaktioner, før den tilføjer sin underskrift. I stedet for at almindelige Corda-noder downloader og tjekker deres transaktioners forfædre, hvorfor så ikke bare spørge en notar i stedet for? Dette kunne hjælpe med skalerbarhed og fortrolighed, da de fleste noder ikke vil se andre transaktioner end deres egne. Vi kan endda foreslå, at et netværks notarer stoler fuldt ud på hinanden, så der er ingen grund til at bekymre sig om forfædre. Hver stats notar kunne stå inde for dens gyldighed og kun verificere den transaktion, der skabte den med andre notarers hjælp.
Lad Corda være Corda
Alt dette fører os tilbage til, hvor vi startede: Corda er ikke rigtig en konkurrent til konventionelle blockchains, inklusive MultiChain. Corda er Corda – en interessant ny type distribueret hovedbog, som er optimeret til behovene hos dem, der finansierer den. Jeg aner ikke, om Corda i sidste ende vil lykkes eller fejle, fordi jeg ikke kender dens faktiske omkostninger og fordele sammenlignet med den nuværende måde at gøre tingene på. Men uanset hvad der sker i fremtiden, er det bestemt værd at studere i forhold til filosofi og design.
Med hensyn til MultiChain har vi en anden tilgang. At stjæle en linje fra The West Wing, er vi fast besluttet på at "lade blockchain være blockchain". Blockchains er, hvad de er, og vi har ingen planer om at gøre dem til noget anderledes. Som datainfrastrukturen for en delt applikation repræsenterer en blockchain en specifik afvejning sammenlignet med en centraliseret database - en gevinst ved disintermediation på bekostning af reduceret fortrolighed. Og vi arbejder hårdt på at gøre MultiChain 2.0 bedst muligt blockchain platform for applikationsudviklere at bruge.
Skriv eventuelle kommentarer på LinkedIn.
Kilde: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/
- Konto
- Akronymer
- aktiv
- Yderligere
- Fordel
- algoritme
- algoritmer
- Anvendelse
- applikationer
- arkitektur
- OMRÅDE
- artikel
- aktiv
- Aktiver
- publikum
- tilladelse
- Bank
- Bank of China
- Bank
- Banker
- BEDSTE
- Bill
- blockchain
- Boks
- Bygning
- Bundle
- virksomhed
- tilfælde
- Årsag
- Direktør
- certifikat
- certifikater
- lave om
- kanaler
- kontrol
- Kontrol
- barn
- Børn
- Kina
- Citi
- lukning
- kommentarer
- kommerciel
- Fælles
- selskab
- konkurrence
- konkurrenter
- Datalogi
- computere
- konflikt
- Konsensus
- samtykke
- forbruge
- indhold
- indhold
- kontrakter
- corda
- Omkostninger
- Oprettelse af
- krydstogt
- cryptocurrencies
- cryptocurrency
- kryptografi
- Nuværende
- Custody
- Kunder
- DAG
- Dash
- data
- data opbevaring
- Database
- databaser
- dag
- deal
- forsinkelse
- leverer
- levering
- Design
- Udvikler
- udviklere
- Udvikling
- DID
- digital
- Distribueret Ledger
- Dollar
- elefant
- Engineering
- Enterprise
- ethereum
- udveksling
- Udvekslinger
- Dyrke motion
- stof
- retfærdig
- familie
- Mode
- Funktionalitet
- Endelig
- finansielle
- Finansielle institutioner
- ende
- Fornavn
- første gang
- Fokus
- format
- fuld
- finansiering
- fonde
- fremtiden
- Generelt
- Global
- global blockchain
- godt
- regeringsførelse
- stor
- gruppe
- Dyrkning
- link.
- Skjule
- Høj
- Fremhævet
- historie
- Hvordan
- HTTPS
- kæmpe
- idé
- Identity
- Ulovlig
- Herunder
- industrier
- oplysninger
- Infrastruktur
- Institution
- institutioner
- forsikring
- interaktion
- interesse
- Interoperabilitet
- involverede
- IP
- udstedelse
- spørgsmål
- IT
- Java
- Job
- deltage
- Nøgle
- nøgler
- viden
- stor
- føre
- Leadership" (virkelig menneskelig ledelse)
- førende
- lærte
- Ledger
- Politikker
- Niveau
- lys
- Line (linje)
- Flydende
- Liste
- Lang
- større
- Flertal
- Making
- Marked
- Markeder
- Match
- møder
- Medlemmer
- nævner
- million
- model
- penge
- bevæge sig
- multikæde
- netværk
- netværk
- net
- noder
- Begreb
- åbent
- open source
- ordrer
- ordrer
- Andet
- Andre
- ejer
- ejere
- Smerte
- Papir
- paradigme
- forældre
- Betal
- betaling
- betalinger
- Mennesker
- ydeevne
- perspektiv
- filosofi
- billede
- perron
- Platforme
- Populær
- præsentere
- pris
- Beskyttelse af personlige oplysninger
- private
- Produkt
- produktion
- bevis
- ejendom
- beskytte
- offentlige
- R3
- læsere
- Læsning
- Reality
- resumé
- optegnelser
- Regulering
- Relationer
- relief
- Krav
- Ressourcer
- pensionering
- gennemgå
- Risiko
- regler
- Kør
- kører
- Skalerbarhed
- Videnskab
- HAV
- Sees
- forstand
- sæt
- delt
- Levering
- Kort
- Skilte
- Simpelt
- lille
- So
- Software
- Løsninger
- SOLVE
- hastighed
- udgifterne
- spredes
- spil
- starte
- påbegyndt
- Tilstand
- Stater
- Status
- opbevaring
- butik
- forhandler
- Understøtter
- overflade
- systemet
- Teknisk
- prøve
- Fremtiden
- Tænker
- tredje partier
- tid
- tolerance
- Sporbarhed
- transaktion
- Transaktioner
- Transformation
- Gennemsigtighed
- transportere
- Stol
- Uhadet
- us
- USD
- brugere
- randen
- Verifikation
- Specifikation
- Virtual
- virtuel maskine
- synlighed
- Afstemningen
- vente
- Vest
- WHO
- Wikipedia
- vinde
- Arbejde
- world
- værd
- skrivning
- år
- Zcash
- nul