En detaljert titt på blokkjeden uten blokkjede
Etter hvert som tiden går, har blokkjedeverdenen delt seg i to forskjellige deler. På den ene siden har offentlige blokkjeder med tilhørende kryptovalutaer hatt et bemerkelsesverdig nylig comeback, og preget mange mange millionærer. På den annen side har bruken av tillatte blokkjeder eller bedriftsblokkjeder vokst stille, men jevnt og trutt, ettersom deres første live distribusjoner på tvers av flere bransjer i løpet av 2017.
Et interessant spørsmål å vurdere er det passende nivået av likhet mellom disse to typene kjeder. Begge implementerer en delt database ved hjelp av peer-to-peer-nettverk, offentlig-privat nøkkelkryptografi, transaksjonsregler og konsensusmekanismer som kan overleve ondsinnede aktører. Det er mye felles grunnlag. Ikke desto mindre har offentlige og private blokkjeder forskjellige krav når det gjelder konfidensialitet, skalerbarhet og styring. Kanskje disse forskjellene peker på behovet for radikalt divergerende design.
De Corda plattform, utviklet av R3 bankkonsortiet, inntar en klar holdning til dette spørsmålet. Mens noen aspekter var inspirert av offentlige blokkjeder, ble Corda designet fra bunnen av basert på behovene til R3s medlemmer. Faktisk, selv om R3 fortsatt bruker ordet "blockchain" omfattende for å hjelpe til med å markedsføre produktet deres, har Corda ingen blokkkjede i det hele tatt. Mer enn noen annen "distribuert hovedbok"-plattform jeg er klar over, avviker Corda radikalt fra arkitekturen til konvensjonelle blokkjeder.
Målet mitt med dette stykket er å forklare disse forskjellene og diskutere deres implikasjoner, på godt og vondt. Egentlig er godt og dårlig feil måte å si det på, fordi det mer interessante spørsmålet er "Godt og dårlig for hva?" Denne artikkelen er langt fra kort. Men mot slutten av det håper jeg at leserne vil få en viss forståelse av forskjellene i Corda og deres påfølgende avveininger. Corda er viktig fordi designbeslutningene bringer mange av dilemmaene til enterprise blockchains i skarp lindring.
En siste ting før vi dykker inn. Som administrerende direktør i selskapet bak multikate, en populær blokkjedeplattform for bedrifter, hvorfor skriver jeg så dyptgående om et antatt konkurrerende produkt? Standardgrunnen ville være å argumentere for MultiChains overlegenhet, men det er ikke min motivasjon her. Jeg ser faktisk ikke på Corda og MultiChain som konkurrenter, fordi de er fundamentalt forskjellige med tanke på design, arkitektur og publikum. Corda og MultiChain konkurrerer på samme måte som cruiseskip og jetski – mens begge transporterer mennesker til sjøs, er det nesten ingen virkelige situasjoner der begge kan brukes.
På en mer personlig måte har jeg lært mye av Cordas tekniske ledelse de siste årene, enten gjennom møter, korrespondanse eller deres offentlige skrifter, hvorav mye skjedde før de begynte i R3. Noe av interessen min for Corda stammer fra respekten jeg har for dette teamet, og alene av denne grunn er Corda verdt å studere for alle som søker en forståelse av det distribuerte hovedbokfeltet.
Vi introduserer blokkjeder
For å forstå Corda, er det nyttig å starte med konvensjonelle blokkjeder. Hensikten med en blokkjede er å gjøre det mulig for en database eller hovedbok å deles direkte og trygt av ikke-stolende parter. Dette står i kontrast til sentraliserte databaser, som er lagret og kontrollert av en enkelt organisasjon. En blokkjede har flere "noder", som hver lagrer en kopi av databasen og kan tilhøre en annen organisasjon. Noder kobles til hverandre på en tett peer-to-peer-måte, ved å bruke en "sladderprotokoll" der hver node hele tiden forteller sine jevnaldrende alt den lærer. Som et resultat kan enhver node raskt kringkaste en melding til hele nettverket via mange alternative veier.
En database, enten sentralisert eller blokkjededrevet, begynner i en tom tilstand og oppdateres via "transaksjoner". En transaksjon er definert som et sett med databaseendringer som er "atomiske", noe som betyr at de lykkes eller mislykkes som helhet. Se for deg en database som representerer en finansiell hovedbok, med én rad per konto. En transaksjon der Alice betaler $10 til Bob har tre trinn: (1) verifiser at Alices konto inneholder minst $10, (2) trekk $10 fra Alices konto, og (3) legg til $10 til Bobs konto. Som et grunnleggende krav må enhver databaseplattform sikre at ingen transaksjoner forstyrrer en annen. Denne "isolasjonen" oppnås ved å låse radene for både Alice og Bob mens betalingen pågår. Enhver annen transaksjon som involverer disse radene må vente til denne er fullført.
I en blokkjede behandler hver node hver transaksjon uavhengig av sin egen kopi av databasen. Transaksjoner opprettes hvor som helst på nettverket og overføres automatisk til alle andre noder. Siden organisasjonene som kjører noder kan ha forskjellige (eller til og med motstridende) interesser, kan de ikke stole på at hverandre handler rettferdig. Blokkjeder trenger derfor regler som definerer om en bestemt transaksjon er gyldig eller ikke. I en delt finansiell hovedbok forhindrer disse reglene brukere fra å bruke hverandres penger, eller trylle frem penger fra løse luften.
Sammen med reglene som bestemmer transaksjonens gyldighet, må blokkjeder også definere hvordan transaksjoner skal bestilles, siden denne rekkefølgen i mange tilfeller er kritisk. Hvis Alice har $15 og prøver å sende $10 til både Bob og Charlie i to separate transaksjoner, kan bare én av disse betalingene lykkes. Selv om vi kanskje vil si at den første transaksjonen har forrang, har et peer-to-peer-nettverk ingen objektiv definisjon av "først", siden meldinger kan komme til forskjellige noder i forskjellige rekkefølger.
Transaksjonsregler
I en generell forstand er informasjonen i enhver database delt inn i poster eller "rader", og en transaksjon kan gjøre tre forskjellige ting: slette rader, opprette rader og/eller endre rader. Disse kan reduseres ytterligere til to, siden å endre en rad tilsvarer å slette den raden og opprette en ny i stedet. For å gå tilbake til Alices betaling til Bob, slettes raden hennes som inneholder $15, og to nye rader opprettes – en inneholder $10 for Bob og den andre med $5 i "endring" for Alice.
Etter bitcoins og Cordas terminologi, betegner vi radene som er slettet av en transaksjon som dens "innganger", og de som er opprettet som dens "utganger". Enhver rad slettet av en transaksjon må ha blitt opprettet av en tidligere transaksjon. Derfor forbruker hver transaksjonsinngang (eller "bruker") en tidligere transaksjons utgang. Det oppdaterte innholdet i databasen er definert av settet med "ubrukte transaksjonsutganger" eller "UTXOs".
I en blokkjede er en transaksjon gyldig hvis den oppfyller følgende tre betingelser:
- Korrekthet. Transaksjonen må representere en legitim transformasjon fra input til output. For eksempel, i en finansiell hovedbok, må den totale mengden midler i inngangene samsvare med totalen i utgangene, for å forhindre at penger på magisk vis dukker opp eller forsvinner. De eneste unntakene er spesielle "utstedelses"- eller "pensjoneringstransaksjoner", der midler eksplisitt legges til eller fjernes.
- autorisasjon. Transaksjonen må godkjennes av eieren av hver utgang som forbrukes av dens innganger. I en finansiell hovedbok forhindrer dette deltakerne i å bruke hverandres penger uten tillatelse. Transaksjonsautorisasjon administreres ved hjelp av asymmetrisk (eller offentlig-privat nøkkel) kryptografi. Hver rad har en eier, identifisert av en offentlig nøkkel, hvis tilsvarende private nøkkel holdes hemmelig. For å bli autorisert, må en transaksjon signeres digitalt av eieren av hver av dens innganger. (Merk at rader også kan ha mer komplekse "multisignatur"-eiere, for eksempel der to av tre parter kan godkjenne bruken deres.)
- unikhet. Hvis en transaksjon forbruker en bestemt utgang, kan ingen annen transaksjon konsumere den utgangen igjen. Slik forhindrer vi at Alice foretar motstridende betalinger til både Bob og Charlie. Selv om transaksjonene for begge disse betalingene kan være korrekte og autoriserte, sikrer unikhetsregelen at kun én vil bli behandlet av databasen.
I en konvensjonell blokkjede sjekker hver node hver transaksjon i forhold til disse tre reglene. Senere skal vi se hvordan Corda deler opp dette ansvaret annerledes.
Byggeklosser
En blokkjede er bokstavelig talt en kjede av blokker, der hver blokk kobles til den forrige via en "hash" som unikt identifiserer innholdet. Hver blokk inneholder et ordnet sett med transaksjoner som ikke må komme i konflikt med hverandre eller med de i tidligere blokker, samt et tidsstempel og annen informasjon. Akkurat som transaksjoner, forplanter blokker seg raskt over nettverket og blir uavhengig verifisert av hver node. Når en transaksjon vises i en blokk, blir den "bekreftet", noe som fører til at noder avviser enhver motstridende transaksjon.
Hvem er ansvarlig for å lage disse blokkene, og hvordan kan vi være sikre på at alle noder blir enige om den autoritative kjeden? Dette spørsmålet om "konsensusalgoritmer" er et stort emne i seg selv, fylt med fantastiske akronymer som PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance) og DPoS (Delegated Proof of Stake). Vi kommer ikke inn på alt det her. Det er nok å si at tillatte blokkjeder for bedrifter bruker en slags stemmeordning, der stemmer gis til "validatornoder" som er kollektivt ansvarlige. Ordningen sikrer at så lenge et godt flertall av validatornodene fungerer korrekt og ærlig, vil transaksjoner komme inn i kjeden i en (nær) rettferdig rekkefølge, tidsstempler vil være (omtrent) korrekte, og bekreftede transaksjoner kan ikke reverseres senere.
Før jeg diskuterer noen av utfordringene med blokkjeder, vil jeg avklare ytterligere tre punkter. For det første, mens jeg bruker en finansiell hovedbok ved eksempel gjennom dette stykket, støtter input-output-modellen for transaksjoner et mye bredere utvalg av brukstilfeller. Hver rad kan inneholde et rikt dataobjekt (tenk JSON) som inneholder mange forskjellige typer informasjon - faktisk bruker Corda ordet "stat" i stedet for "rad" av denne grunn. Rikere stater endrer ingenting grunnleggende om transaksjonsregler: korrekthet er fortsatt definert i form av innganger og utdata, autorisasjon er fortsatt nødvendig for hver input, og unikhet sikrer at hver utgang bare kan brukes én gang.
For det andre er det mange blockchain-brukstilfeller der rader bare opprettes i databasen og aldri slettes. Disse applikasjonene er relatert til generell datalagring, tidsstempling og notarisering, i stedet for å opprettholde en slags hovedbok som er i endring. I disse bare dataapplikasjonene legger transaksjoner til data i utdataene, men forbruker ingen i inngangene, noe som gjør at reglene for korrekthet, autorisasjon og unikhet kan forenkles. Selv om brukstilfeller for kun data er et økende fokus i vår egen utvikling hos MultiChain, nevner jeg dem bare i forbifarten her, siden Corda tydeligvis ikke ble designet med dem i tankene.
Til slutt er det verdt å merke seg at noen blokkjedeplattformer ikke bruker en input-output-modell. Ethereum presenterer et alternativt paradigme, der kjeden kontrollerer en virtuell datamaskin med en global tilstand som administreres av "kontrakter", og transaksjoner kobles ikke eksplisitt til hverandre. En diskusjon av Ethereums modell i tillatte blokkjeder er utenfor vårt omfang her, men se denne artikkelen for en detaljert forklaring og kritikk. En viktig fordel med input-output-paradigmet er at de fleste transaksjoner kan behandles parallelt og uavhengig av hverandre. Denne egenskapen er avgjørende for Corda, som vi vil se senere.
Blockchain-utfordringer
La oss forestille oss at verdens banker opprettet en delt hovedbok for å representere eierskap, overføring og utveksling av en rekke finansielle eiendeler. I teorien kan dette implementeres på en vanlig blokkjede, som beskrevet ovenfor. Hver rad vil inneholde tre kolonner – en eiendelidentifikator som GOOG eller USD, mengden som eies og eierens offentlige nøkkel. Hver transaksjon vil overføre en eller flere eiendeler fra sine innganger til sine utganger, med spesielle tilfeller for utstedelse og pensjonering.
Hver bank i nettverket vil kjøre en eller flere noder som kobles til de andre, forplante og verifisere transaksjoner. Seniormedlemmer vil fungere som validatorer, med det kollektive ansvaret for å bekrefte, bestille og tidsstemple transaksjoner. Enhver validators feil oppførsel vil være synlig for alle nodene i nettverket, noe som fører til sensur, forvisning og/eller rettslige prosesser. Med alt dette på plass kan enhver finansiell eiendel flyttes over hele verden på sekunder, med reglene for korrekthet, autorisasjon og unikhet som garanterer hovedbokens integritet.
Hva er galt med dette bildet? Egentlig er det tre problemer: skalerbarhet, konfidensialitet og interoperabilitet. Spørsmålet om skalerbarhet er enkelt nok. Vår foreslåtte interbankblokkjede vil kreve at hvert medlem verifiserer, behandler og lagrer hver transaksjon utført av hver bank i verden. Selv om dette ville være teknisk gjennomførbart for de største finansinstitusjonene, vil kostnadene ved beregning og lagring skape en betydelig barriere for mange. Vi foretrekker selvfølgelig et system der deltakerne bare ser de transaksjonene de umiddelbart er involvert i.
Men la oss legge skalerbarheten til side, siden det til slutt kan løses ved hjelp av dyre datamaskiner og smart konstruksjon. Et mer grunnleggende spørsmål er konfidensialitet. Selv om det kan høres utopisk ut for hver transaksjon å være synlig overalt, er slik radikal åpenhet en ikke-starter i den virkelige verden når det gjelder konkurranse og regulering. Hvis J.P. Morgan og HSBC bytter ut et par eiendeler, vil de neppe ønske at Citi og Bank of China skal se hva de gjorde. Hvis transaksjonen ble utført på vegne av disse bankenes kunder, kan det være ulovlig for dem å avsløre den på denne måten.
En foreslått løsning på problemet med konfidensialitet er "kanaler", som implementert i Hyperledger Fabric. Hver kanal har visse medlemmer, som er en undergruppe av nodene i nettverket som helhet. En kanals transaksjoner er kun synlige for medlemmene, slik at hver kanal effektivt fungerer som en separat blokkjede. Selv om dette hjelper med konfidensialitet, undergraver det også hele poenget med øvelsen. Eiendeler kan ikke flyttes fra en kanal til en annen uten hjelp fra en pålitelig mellommann som er aktiv på begge. Vanskeligheten med denne tilnærmingen ble nylig fremhevet av SWIFTs avstemming proof-of-concept, som anslo at over 100,000 100,000 kanaler ville være nødvendig i produksjonen. Det er XNUMX XNUMX øyer som eiendeler ikke kan flyttes direkte mellom.
I tilfeller der kun data brukes, der transaksjoner ikke forbruker data i innganger, kan konfidensialitetsproblemet omgås ved å kryptere eller hashe dataene i utdataene, og levere dekrypteringsnøkkelen eller uhashed data utenfor kjeden. Men for en transaksjon hvis innganger forbruker andre transaksjoners utganger, må hver node se disse inngangene og utgangene for å validere transaksjonen. Mens avanserte kryptografiske teknikker som f.eks konfidensielle eiendeler og null kunnskapsbevis er utviklet for å delvis eller fullstendig løse dette problemet for finansreskontro, disse påfører en betydelig ytelsesbyrde og/eller kan ikke generaliseres til noen korrekthetsregel.
Til slutt, la oss snakke om interoperabilitet. I en ideell verden ville hver bank umiddelbart slutte seg til vår globale blokkjede den dagen den ble lansert. I virkeligheten vil imidlertid flere blokkjeder bli tatt i bruk av forskjellige grupper av banker, basert på geografi eller allerede eksisterende forhold. Over tid kan et medlem av en gruppe ønske å begynne å handle med et medlem av en annen, ved å overføre en eiendel mellom kjeder. Akkurat som med kanaler, kan dette bare oppnås ved hjelp av en pålitelig mellommann, som beseirer blokkjedens formål.
Corda har som mål å løse disse innbyrdes relaterte problemene med skalerbarhet, konfidensialitet og interoperabilitet via en radikal nytenkning av hvordan distribuerte hovedbøker fungerer.
Cordas delvise syn
Den grunnleggende forskjellen i Corda er lett å forklare: Hver node ser bare noen, i stedet for alle, av transaksjonene som behandles på nettverket. Mens en enkelt logisk og konseptuell hovedbok er definert av alle disse transaksjonene, ser ingen individuelle noder den hovedboken i sin helhet. For å gjøre en sammenligning, når som helst, er hver dollarseddel i verden på et bestemt sted, men ingen vet hvor de alle er.
Så hvilke transaksjoner ser en Corda-node? Først av alt, de som den er direkte involvert i, fordi den eier en av transaksjonens innganger eller utganger. I en finansiell hovedbok inkluderer dette hver transaksjon der en node sender eller mottar midler. La oss si at Alice oppretter en transaksjon som bruker hennes $15 i en inngang og har to utganger – en med $10 for meg, og den andre med $5 i "endring" for henne. Etter at Alice har sendt meg denne transaksjonen, kan jeg sjekke den for korrekthet og autorisasjon, og verifisere at inngangene og utgangene balanserer og at Alice har signert.
Denne transaksjonen i seg selv er imidlertid ikke nok. Jeg må også bekrefte at Alices $15-inndatatilstand virkelig eksisterer, og at hun ikke bare har funnet på det. Det betyr at jeg må se transaksjonen som opprettet denne tilstanden, og sjekke den for korrekthet og autorisasjon også. Hvis denne forrige transaksjonen, som sendte Alice $15, har en $10-inngang som tilhører Denzel og en annen $5-inngang fra Eric, så må jeg også bekrefte transaksjonene som skapte disse. Og så fortsetter det, helt tilbake til den opprinnelige "emisjons"-transaksjonen der eiendelen ble opprettet. Antall transaksjoner jeg må bekrefte vil avhenge av hvor mange ganger eiendelene har skiftet eier og omfanget av bakoverforgrening.
Siden Corda-noder ikke automatisk ser hver transaksjon, hvordan får de tak i de de trenger? Svaret kommer fra avsenderen av hver ny transaksjon. Før Alice oppretter en transaksjon som bruker hennes $15, må hun allerede ha bekreftet transaksjonen hun mottok den. Og siden Alice må ha brukt den rekursive teknikken ovenfor, vil hun ha en kopi av hver transaksjon som trengs for denne verifiseringen. Bob ber ganske enkelt om disse transaksjonene fra Alice som en del av deres interaksjon. Hvis Alice ikke svarer riktig, konkluderer Bob med at Alice prøver å lure ham, og avviser den innkommende betalingen. I tilfellet der Bob får tilsendt en ny transaksjon hvis inndata har flere eiere, kan han få de nødvendige bevisene fra hver.
Vi presenterer notarius publicus
Så langt har vi forklart hvordan Bob kan verifisere riktigheten og godkjenningen av en innkommende transaksjon, inkludert rekursivt sporing av inndataenes opprinnelse. Men det er en regel til vi må tenke på: unikhet. La oss si at Alice er ondsinnet. Hun kan generere en transaksjon der hun betaler $10 til Bob, og en annen der hun betaler de samme $10 til Charlie. Hun kan sende disse transaksjonene til henholdsvis Bob og Charlie, sammen med et fullstendig bevis på korrekthet og autorisasjon for hver. Mens begge transaksjonene er i konflikt med hverandre ved å konsumere samme tilstand, er det ingen måte for Bob og Charlie å vite dette.
Konvensjonelle blokkjeder løser dette problemet ved at hver node ser hver transaksjon, noe som gjør konflikter enkle å oppdage og avvise. Så hvordan løser Corda, med sin delvise transaksjonssynlighet, det samme problemet? Svaret er ved hjelp av en "notarius". En notarius er en betrodd part (eller parter som jobber sammen) som garanterer at en bestemt stat bare konsumeres én gang. Hver stat har en spesifikk notarius, som må signere enhver transaksjon der den staten blir konsumert. Når en notar har gjort dette, må den ikke signere en annen transaksjon for samme stat. Notarius publicus er nettverkets voktere av transaksjonens unikhet.
Mens hver stat kan ha en annen notar, må alle statene som forbrukes av en bestemt transaksjon tildeles den samme. Dette unngår problemer knyttet til vranglåser og synkronisering, som bør være kjent for de med distribuert databaseerfaring. La oss si at Alice og Bob blir enige om å bytte Alices $10 mot Bobs £7. Transaksjonen for denne utvekslingen må signeres av notarius publicus i begge stater, men hvilken går først? Hvis Alices notarius skriver under, men Bobs mislykkes av en eller annen grunn, vil Alice sitte igjen med en ufullstendig transaksjon og kan aldri bruke sine $10 igjen. Hvis Bobs tegn først, blir han på samme måte utsatt. Selv om vi kanskje vil at notarer bare jobber sammen, krever dette i praksis gjensidig tillit og bruk av en konsensusprotokoll, komplikasjoner som Cordas designere valgte å unngå.
Hvis stater med forskjellige notarer kreves som input til en enkelt transaksjon, utfører deres eiere først spesielle "notarskifte"-transaksjoner, som flytter en stat fra en notarius til en annen, uten å endre noe annet. Så når partene bygger en transaksjon med flere innganger, må de først bli enige om notarius publicus som skal brukes, og deretter utføre de notariske endringene som er nødvendige. Mens utvikleren i meg kjente et lite stikk av smerte når jeg leste om denne løsningen, er det ingen grunn til at det ikke vil fungere så lenge notarius publicus spiller med.
Det bør også presiseres at selv om hver notarius er en enkelt logisk aktør når det gjelder signering av transaksjoner, trenger den ikke være under kontroll av en enkelt part. En gruppe organisasjoner kan drive en notarius kollektiv ved å bruke en passende konsensusprotokoll der et flertall av deltakerne er nødvendig for å generere en gyldig signatur. Dette vil forhindre at en enkelt ondsinnet part undergraver det unike ved å signere transaksjoner som er i konflikt. I teorien kan vi til og med la hver node i nettverket delta i denne typen delt notarisering, selv om vi i så fall ville vært mer eller mindre tilbake til en konvensjonell blokkjede.
Tar poeng
La oss oppsummere de viktigste forskjellene mellom Corda og konvensjonelle blokkjeder. I Corda er det ingen enhetlig blokkjede som inneholder alle transaksjonene som er bekreftet. Noder ser bare de transaksjonene de er direkte involvert i, eller som de er avhengige av historisk. Noder er ansvarlige for å kontrollere transaksjonens korrekthet og autorisasjon, men er avhengige av pålitelige notarer for å bekrefte unikhet.
Selvfølgelig er det mye mer ved Corda enn dette: bruk av digitale sertifikater for å autentisere identitet, "nettverkskart" for å hjelpe noder med å finne og stole på hverandre, "kontrakter" per stat som definerer korrekthet fra hver stats perspektiv, en deterministisk versjon av Java Virtual Machine som utfører disse kontraktene, "flyter" som automatiserer transaksjonsforhandlinger, "tidsvinduer" som begrenser transaksjoner etter tid, "orakler" som attesterer eksterne fakta og "CorDapps" som samler mange ting sammen for enkel distribusjon . Selv om hver av disse funksjonene er interessante, kan ekvivalenter for alle finnes i andre blockchain-plattformer. Målet mitt i denne artikkelen er å fokusere på det som gjør Corda unik.
Så lever Corda opp til løftet? Løser det skalerbarhets-, konfidensialitets- og interoperabilitetsproblemene til blokkjeder? Og hvor mye av prisen betaler Corda når de tar sine spesielle valg?
Noen ganger mer skalerbar
La oss starte med skalerbarhet. Her fremstår Cordas fordel klar, siden noder bare ser noen av transaksjonene i et nettverk. I en vanlig blokkjede er maksimal gjennomstrømning begrenset av hastigheten til den tregeste noden i behandling av transaksjoner. Derimot kan et Corda-nettverk behandle en million transaksjoner per sekund, mens hver node ser bare en liten brøkdel av det. Skalerbarhet strekker seg også til notarer, siden oppgaven med å signere transaksjoner for unikhet kan spres mellom mange forskjellige notarer, som hver er ansvarlig for en liten andel av nettverkets stater.
Når det er sagt, er det én situasjon der Corda presterer langt dårligere enn en blokkjede. Dette skjer når en node mottar en ny transaksjon som avhenger av mange andre transaksjoner den ikke har sett før. Se for deg en svært likvid eiendel som ble utstedt for 10 år siden, og skifter hender omtrent hvert femte minutt. Veien fra enhver ny transaksjon tilbake til denne eiendelens utstedelse vil være over en million transaksjoner lang. Når en node mottar denne ressursen for første gang, må den hente disse millioner transaksjonene fra avsenderen og verifisere hver enkelt etter tur. Med en (ganske optimistisk) hastighet på 1000 transaksjoner per sekund, ville det være en 17 minutters forsinkelse før mottakeren kunne sende eiendelen videre – helt klart for lang for noe så flytende.
Hvorfor lider ikke blokkjeder av dette problemet? Fordi noder ser og verifiserer hver transaksjon når den skjer, oppdaterer de konstant statusen til hovedboken, og vet nøyaktig hvem som eier hver eiendel på det nåværende tidspunkt. Selv om en node aldri har hatt en bestemt eiendel før, kan den umiddelbart bekrefte transaksjonen den mottar den i, og deretter umiddelbart sende den videre. For å si det på en annen måte, må blockchain-noder verifisere transaksjoner som kanskje ikke er relevante for dem, men ved å gjøre det, betaler de på forhånd kostnadene for å sjekke eventuelle fremtidige transaksjoner som kan komme inn. Mens Corda-noder er mindre opptatt totalt sett, kjører de risiko for å måtte gjøre mye arbeid med et øyeblikks varsel. Det er ikke noe skalerbart med det.
Noe mer konfidensielt
La oss gå videre til konfidensialitet. I Corda ser noder bare noen av et nettverks transaksjoner, noe som unektelig betyr bedre personvern enn konvensjonelle blokkjeder. Ikke desto mindre er Corda langt fra å løse konfidensialitetsproblemet, fordi noder fortsatt ser noen transaksjoner som ikke er deres sak. For å ta et enkelt eksempel, hvis Alice betaler Bob $10, så sender Bob disse $10 videre til Charlie, Charlies node må vises transaksjonen mellom Alice og Bob, selv om den ikke involverer ham. På det tidspunktet da Alice betalte Bob, hadde hun ingen måte å vite hvem som kunne se denne transaksjonen i fremtiden, og hvem som helst kan få tilsendt den når som helst.
For å være rettferdig er Cordas utviklere klar over dette problemet, og diskuterer det i kapittel 15 i deres Teknisk stortingsmelding. Artikkelen foreslår enkle strategier som å bruke flere offentlige nøkler per enhet eller redusere sporbarheten ved å returnere eiendeler til utstedere for gjenutstedelse (ligner på kryptovaluta "myntmiksere"). Den nevner også mer avanserte fremtidige muligheter som å bruke Tor-lignende anonymiseringsnettverk for å skjule deltakernes IP-adresser og utnytte null kunnskapsbevis eller Intels sikre enklaver å validere transaksjoner uten å avsløre innholdet. Selv om alle disse forslagene er gyldige, kan de også brukes på vanlige blokkjeder ved å bruke input-output-modellen, og har faktisk vært i kryptovalutaer som Dash, Zcash og Verge. Så Cordas eneste unike fordel når det gjelder konfidensialitet er fortsatt dens reduserte transaksjonssynlighet – i beste fall en ufullstendig løsning.
Alt i avlen
For bedre å forstå Cordas skalerbarhet og konfidensialitetsfordeler, bør vi merke oss hvordan dette avhenger av tettheten og overlappingen av relasjonene mellom transaksjoner. Se for deg et "slektstre" av transaksjonene utført i et nettverk, der hver transaksjons foreldre er de forrige som den umiddelbart avhenger av. Nærmere bestemt, når en transaksjons utdata forbrukes av en annens input, tegner vi en pil som representerer forholdet fra forelder til barn. Transaksjoner kan ha et hvilket som helst antall foreldre og barn, selv om vi i de fleste tilfeller forventer bare noen få.
Gitt dette slektstreet, definerer vi forfedrene til en transaksjon som dens foreldre, besteforeldre, oldeforeldre og så videre. Treets "Adam og Eva" er utstedelsestransaksjonene som skapte eiendeler og har ingen egne foreldre. Som i vanlige slektstrær kan ikke to transaksjoner være forfedre til hverandre. I formelle datavitenskapelige termer er dette en rettet acyklisk graf eller DAG, der aner er definert som den transitive lukkingen av foreldrerelasjonen.
Husk at når en Corda-node behandler en transaksjon, må den laste ned og verifisere alle transaksjonens forfedre, bortsett fra de den har sett før. Så hvis slektstreet er dypt, kan nye innkommende transaksjoner ha et stort antall forfedre som må verifiseres, noe som utløser Cordas skalerbarhetsproblem. I tillegg, hvis slektstreet inneholder en høy grad av avling, kan en ny transaksjons forfedre inkludere mange eller de fleste tidligere transaksjoner i nettverket. I dette tilfellet vil Corda gi liten fordel når det gjelder personvern.
Derimot, hvis slektstreet med transaksjoner er grunt og inneholder mange frakoblede øyer som ikke samhandler med hverandre, kommer Cordas fordeler til syne. Noder vil aldri trenge å verifisere et stort antall transaksjoner på en gang, og kan holdes i mørket om de fleste transaksjoner som ikke er relatert til deres egne. Hvis den brukes som finansiell hovedbok, kan vi si at Corda er ideell for svært fragmenterte markeder hvis eiendeler sjelden bytter hender.
Interoperabilitet for å vinne
Her er ett område der Corda virkelig skinner. Se for deg to separate Corda-nettverk, med ulike sett med eiendeler og deltakere. På et tidspunkt ønsker en deltaker i det ene nettverket å sende en eiendel til noen i det andre. I motsetning til konvensjonelle blokkjeder, er det ingen forventning om at en node vil ha verifisert alle tidligere transaksjoner, så noden som mottar denne nye ressursen vil ikke oppleve noe uvanlig. Når transaksjonen kommer inn, ber den ganske enkelt om og verifiserer den relevante historikken, uten å være klar over at dette er fra et "separat nettverk". For å strekke en klisjé kan vi si at det ikke er noen fremmede i Corda – bare venner som ennå ikke har møtt hverandre.
I virkeligheten er ting ikke fullt så enkelt. Enhver Corda-node bestemmer eksplisitt hvilke notarer de skal stole på, siden en notar som ikke oppfører seg dårlig kan forårsake økonomisk kaos. I tillegg trenger noder et "sertifikat" gitt av en "dørvakt" for å koble til andre noder i et nettverk, siden vi ikke kan la tilfeldige medlemmer av publikum begynne å koble til noder og kaste bort ressursene deres. Så før en node på ett nettverk kan begynne å be om og verifisere transaksjoner fra et annet nettverk, må den legges til listen over pålitelige notarer og få det riktige sertifikatet. Selv om dette innebærer noe manuell konfigurasjon og administrasjon, er det minimum som kan forventes for et system av denne art. Totalt sett er det rimelig å konkludere med at interoperabilitet er Cordas store seier over konvensjonelle blokkjeder.
Reformidling
Det er på tide å snakke om disintermediation, elefanten på Cordas rom. I sammenheng med blokkjeder betyr disintermediation at hver deltaker kan verifisere hver transaksjon for seg selv, uten å være avhengig av god oppførsel til tredjeparter. I mitt syn, er disintermediation kjernefordelen med blokkjeder fremfor sentraliserte databaser, der alle deltakere er helt avhengige av databasens eier. Hvis deltakerne i et nettverk har en mellommann de kan stole på, og det ikke er noen forretningsmessig eller regulatorisk sak for disintermediation, så er det ikke noe poeng i bruk av blokkjede. Sentraliserte databaser er raskere og mer effektive, og unngår spørsmålet om transaksjonskonfidensialitet.
Så oppnår deltakerne i et Corda-nettverk disintermediation? Vel, ja, ja og ja men nei. For transaksjonslevering krysser Corda av i boksen, siden nodene som er involvert i en transaksjon snakker direkte med hverandre. Når det gjelder korrekthet og autorisasjon, er den også i god form, siden hver node er i stand til å sjekke disse egenskapene for seg selv. Når det gjelder å bekrefte transaksjonens unikhet, mislykkes imidlertid Corda i disintermediation-testen. Noder kan ikke bekrefte unikhet for seg selv, siden de ikke ser hver transaksjon i nettverket, og oppgaven er outsourcet til pålitelige notarer.
Corda-deltakere er prisgitt notarius på en rekke måter. For det første kan en notarius nekte å signere en transaksjon, selv om dens innganger bruker utganger som aldri har vært brukt før. I en finansiell hovedbok hindrer dette noen i å sende eller bytte eiendeler. For det andre kan en notarius signere to motstridende transaksjoner som bruker samme produksjon, noe som får to parter til å tro at de mottok det samme. Ettersom begge mottakerne av den dupliserte eiendelen sender eller utveksler den i ytterligere transaksjoner, sprer smitten seg, og integriteten til hele hovedboken kan snart bli undergravd. Til slutt kan en notar nekte å signere en "notar-endring"-transaksjon for å overføre en stat til en konkurrent, som faktisk holder eiendeler som gissel. For en transaksjon som involverer stater med forskjellige notarer, er det langt å si at Corda introduserer mer formidling enn en sentralisert database, fordi flere tredjeparter har kontroll.
For å sette denne risikoen i perspektiv, er det verdt å huske at Corda-notarer ikke trenger å bli kontrollert av en enkelt organisasjon. De kan også bestå av en gruppe noder som kjører en konsensusalgoritme som kan tolerere dårlige skuespillere. I dette tilfellet vil en notarius fungere fint så lenge de fleste av medlemsnodene følger reglene. På overflaten høres dette ganske ut som en blokkjede, som avhenger av at et flertall av validatorer oppfører seg bra. Men i Corda er risikoen betydelig høyere. Det verste en kabal av blokkjedevalidatorer kan gjøre er å forhindre at enkelte transaksjoner blir bekreftet. En ondsinnet Corda-notar kan også signere motstridende transaksjoner, og sende hovedboken inn i en inkonsekvent avgrunn.
Et merkelig dyr
Ved å sette skalerbarhet, konfidensialitet, interoperabilitet og disintermediation sammen, er det vanskelig å komme til en enkel dom om Corda-alternativet. Totalt sett, fra perspektivet til denne blockchain-plattformutvikleren, virker det, vel ... overbevisende, men rart. Designet for å løse nøkkelproblemene med skalerbarhet og konfidensialitet, er Cordas løsninger ufullstendige, og avhenger i stor grad av formen på transaksjonens "slektstre". Men for å oppnå disse delseirene, mister Corda en kjerneegenskap til blokkjeder – fjerning av transaksjonsformidlere. Selv om Corda utvilsomt utmerker seg med interoperabilitet, er det egentlig nok?
Hvis vi ønsket å være skeptiske, kan vi si at Cordas team ble satt til en umulig oppgave – å designe en smak av blokkjede som ville passe til bankene som finansierte R3. Men den viktigste fordelen med blokkjeder fremfor sentraliserte databaser er disintermediation, som kommer til prisen av redusert konfidensialitet. Hvordan kan denne avveiningen gi mening for finansinstitusjoner som tjener penger ved å opptre som mellommenn, og som er svært sensitive når det gjelder personvern? Sett i dette lyset kan man hylle Corda som et heroisk, men til slutt utilfredsstillende kompromiss mellom ønsket til R3s medlemmer om å gjøre noe blokkjedeaktig, og de kommersielle og regulatoriske begrensningene de eksisterer under.
Depot 2.0
Men jeg foretrekker å ha en mer positiv tilnærming. I stedet for å fokusere på sammenligningen med blokkjeder, kan vi se på Corda som en stor teknisk oppgradering til den økonomiske status quo. Bare bytt ut ordet "notarius" med "forvalter", og det hele faller på plass ganske pent. (EN vaktmester er en finansinstitusjon som innehar eiendeler på andres vegne.) Ja, notarer er mellommenn, som både kan blokkere transaksjoner og la konflikter oppstå, men dette gjelder også for dagens depotmottakere. En «notarskiftetransaksjon» kan sees på som overføring av eiendeler fra en depotmottaker til en annen. Og Corda-transaksjoner er signert av bare én notarius av samme grunn som vi liker at aktivautveksling skal skje på ett sted – for å forhindre at noen av partene er ute av egen lomme.
Når vi ser på Corda på denne måten, kan vi se hvordan den forbedrer seg på den tradisjonelle forvaringsmodellen:
- Den definerer et standard beregningsparadigme og format for å uttrykke finansielle eiendeler og andre kontraktsmessige forpliktelser.
- Den tilbyr åpen kildekode-programvare for å tolke og utføre disse forpliktelsene, og garanterer at transaksjonspartnere og depotmottakere er enige om utfallet av hver transaksjon.
- Komplekse flerpartsforvaltere som beskytter mot misbruk kan opprettes (kun ved bruk av programvare!) ved å utnytte feiltolerante konsensusalgoritmer.
- En standardprosess («notarskifte») er definert for overføring av eiendeler mellom depotmottakere, og ingen depotmottaker har lov til å nekte.
- Depotmottakere kan ikke bruke en eiendel under deres varetekt uten eierens samtykke, siden transaksjoner også må signeres av deres inndatas eiere.
Jeg er langt fra en bankmann, men for meg høres alt dette ganske lovende ut. Og kanskje kan Corda like godt brukes til andre bransjer med komplekse forvaringsstrukturer, som forsikring eller shipping. Selv om Cordas design kanskje ikke gir full disintermediation av en blokkjede, foreslår det en kraftig transformasjon for bransjer der mellommenn spiller en viktig rolle.
Når vi går ned i denne tankegangen, oppstår det uunngåelig et spørsmål: Hvis vi allerede stoler på notarius publicus med jobben på liv og død med å verifisere unikhet, hvorfor ikke stole på dem for korrekthet og autorisasjon også? Corda har allerede ideen om en "validerende notarius", som fullt ut verifiserer transaksjoner før den legger til signaturen. I stedet for at vanlige Corda-noder laster ned og sjekker transaksjonenes forfedre, hvorfor ikke bare spørre en notar i stedet? Dette kan hjelpe med skalerbarhet og konfidensialitet, siden de fleste noder ikke vil se andre transaksjoner enn sine egne. Vi kan til og med foreslå at et nettverks notarius stoler fullt ut på hverandre, så det er ingen grunn til å bekymre seg for forfedre. Hver stats notarius kan gå god for dens gyldighet, og verifisere bare transaksjonen som opprettet den med hjelp fra andre notarer.
La Corda være Corda
Alt dette tar oss tilbake til der vi startet: Corda er egentlig ikke en konkurrent for konvensjonelle blokkjeder, inkludert MultiChain. Corda er Corda – en interessant ny type distribuert hovedbok, som er optimert for behovene til de som finansierer den. Jeg aner ikke om Corda til slutt vil lykkes eller mislykkes, fordi jeg ikke kjenner kostnadene og fordelene i den virkelige verden sammenlignet med den nåværende måten å gjøre ting på. Men uansett hva som skjer i fremtiden, er det absolutt verdt å studere med tanke på filosofi og design.
Når det gjelder MultiChain, tar vi en annen tilnærming. Å stjele en linje fra The West Wing, er vi fast bestemt på å "la blokkjede være blokkjede". Blokkjeder er hva de er, og vi har ingen planer om å gjøre dem om til noe annerledes. Som datainfrastruktur for en delt applikasjon, representerer en blokkjede en spesifikk avveining sammenlignet med en sentralisert database – en gevinst i disintermediation på bekostning av redusert konfidensialitet. Og vi jobber hardt for å gjøre MultiChain 2.0 best mulig blockchain plattform for applikasjonsutviklere å bruke.
Legg inn kommentarer på Linkedin.
Kilde: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/
- Logg inn
- Akronymer
- aktiv
- Ytterligere
- Fordel
- algoritme
- algoritmer
- Søknad
- søknader
- arkitektur
- AREA
- Artikkel
- eiendel
- Eiendeler
- publikum
- autorisasjon
- Bank
- den kinesiske bank
- Banking
- Banker
- BEST
- Bill
- blockchain
- Eske
- Bygning
- XNUMX bunk
- virksomhet
- saker
- Årsak
- konsernsjef
- sertifikat
- sertifikater
- endring
- kanaler
- kontroll
- Sjekker
- barn
- Barn
- Kina
- Citi
- nedleggelse
- kommentarer
- kommersiell
- Felles
- Selskapet
- konkurranse
- konkurrenter
- informatikk
- datamaskiner
- konflikt
- Konsensus
- samtykke
- forbruke
- innhold
- innhold
- kontrakter
- Corda
- Kostnader
- Opprette
- cruise
- cryptocurrencies
- cryptocurrency
- kryptografi
- Gjeldende
- varetekt
- Kunder
- DAG
- Dash
- dato
- datalagring
- Database
- databaser
- dag
- avtale
- forsinkelse
- levere
- levering
- utforming
- Utvikler
- utviklere
- Utvikling
- gJORDE
- digitalt
- Distribuert Ledger
- Dollar
- elefant
- Ingeniørarbeid
- Enterprise
- ethereum
- utveksling
- Børser
- Øvelse
- stoff
- rettferdig
- familie
- Mote
- Egenskaper
- Endelig
- finansiell
- Finansinstitusjoner
- slutt
- Først
- første gang
- Fokus
- format
- fullt
- finansiering
- midler
- framtid
- general
- Global
- global blockchain
- god
- styresett
- flott
- Gruppe
- Økende
- her.
- Gjemme seg
- Høy
- Fremhevet
- historie
- Hvordan
- HTTPS
- stort
- Tanken
- Identitet
- ulovlig
- Inkludert
- bransjer
- informasjon
- Infrastruktur
- Institusjon
- institusjoner
- forsikring
- interaksjon
- interesse
- Interoperabilitet
- involvert
- IP
- utstedelse
- saker
- IT
- Java
- Jobb
- bli medlem
- nøkkel
- nøkler
- kunnskap
- stor
- føre
- Ledelse
- ledende
- lært
- Ledger
- Lovlig
- Nivå
- lett
- linje
- Flytende
- Liste
- Lang
- større
- Flertall
- Making
- marked
- Markets
- Match
- møter
- medlemmer
- nevner
- millioner
- modell
- penger
- flytte
- flerkjede
- nettverk
- nettverk
- nettverk
- noder
- Forestilling
- åpen
- åpen kildekode
- rekkefølge
- ordrer
- Annen
- andre
- eieren
- eiere
- Smerte
- Papir
- paradigmet
- foreldre
- Betale
- betaling
- betalinger
- Ansatte
- ytelse
- perspektiv
- filosofi
- bilde
- plattform
- Plattformer
- Populær
- presentere
- pris
- privatliv
- privat
- Produkt
- Produksjon
- bevis
- eiendom
- beskytte
- offentlig
- R3
- lesere
- Lesning
- Reality
- oppsummering
- poster
- Regulering
- Relasjoner
- lindring
- Krav
- Ressurser
- pensjonering
- anmeldelse
- Risiko
- regler
- Kjør
- rennende
- skalerbarhet
- Vitenskap
- SEA
- Sees
- forstand
- sett
- delt
- Levering
- Kort
- Skilt
- Enkelt
- liten
- So
- Software
- Solutions
- LØSE
- fart
- utgifter
- spre
- stake
- Begynn
- startet
- Tilstand
- Stater
- status
- lagring
- oppbevare
- butikker
- Støtter
- overflaten
- system
- Teknisk
- test
- Fremtiden
- tenker
- tredjeparter
- tid
- toleranse
- Sporbarhet
- Transaksjonen
- Transaksjoner
- Transformation
- Åpenhet
- transportere
- Stol
- Uhaget
- us
- USD
- Brukere
- rand
- Verifisering
- Se
- virtuelle
- virtuell maskin
- synlighet
- Stemmegivning
- vente
- Vest
- HVEM
- Wikipedia
- vinne
- Arbeid
- verden
- verdt
- skriving
- år
- Zcash
- null