Een gedetailleerde kijk op de niet-blockchain blockchain
Naarmate de tijd vordert, is de blockchain-wereld opgesplitst in twee verschillende delen. Aan de ene kant hebben openbare blockchains met hun bijbehorende cryptocurrencies een opmerkelijke recente comeback gemaakt, waarbij ze menig multimiljonair hebben geslagen. Aan de andere kant is het gebruik van geautoriseerde of zakelijke blockchains stil maar gestaag gegroeid, met het oog op hun eerste live implementaties in meerdere industrieën in 2017.
Een interessante vraag om te overwegen is de mate van gelijkenis tussen deze twee soorten ketens. Beiden implementeren een gedeelde database met behulp van peer-to-peer-netwerken, cryptografie van publiek-private sleutels, transactieregels en consensusmechanismen die kwaadwillende actoren kunnen overleven. Dat zijn veel overeenkomsten. Niettemin stellen publieke en private blockchains verschillende eisen op het gebied van vertrouwelijkheid, schaalbaarheid en governance. Misschien wijzen deze verschillen op de behoefte aan radicaal uiteenlopende ontwerpen.
De Corda platform, ontwikkeld door het R3 bankenconsortium, neemt een duidelijk standpunt in over deze kwestie. Hoewel sommige aspecten werden geïnspireerd door openbare blockchains, is Corda helemaal opnieuw ontworpen op basis van de behoeften van de leden van R3. Inderdaad, hoewel R3 nog steeds het woord 'blockchain' gebruikt uitgebreid Om hun product op de markt te brengen, heeft Corda helemaal geen blokketen. Meer dan enig ander "distributed ledger" -platform dat ik ken, wijkt Corda radicaal af van de architectuur van conventionele blockchains.
Mijn doel in dit stuk is om deze verschillen uit te leggen en hun implicaties te bespreken, voor goed en slecht. Eigenlijk is goed en slecht de verkeerde manier om het te zeggen, want de interessantere vraag is "Goed en slecht waarvoor?" Dit artikel is verre van kort. Maar tegen het einde hoop ik dat de lezers enig begrip krijgen van de verschillen in Corda en de daaruit voortvloeiende afwegingen. Corda is belangrijk omdat de ontwerpbeslissingen veel van de dilemma's van enterprise blockchains scherp aan het licht brengen.
Een laatste ding voordat we erin duiken. Als de CEO van het bedrijf erachter MultiChain, een populair blockchain-platform voor ondernemingen, waarom schrijf ik zo diepgaand over een zogenaamd concurrerend product? De standaard reden zou zijn om te pleiten voor de superioriteit van MultiChain, maar dat is hier niet mijn motivatie. In feite zie ik Corda en MultiChain niet als concurrenten, omdat ze fundamenteel verschillen qua design, architectuur en publiek. Corda en MultiChain concurreren op dezelfde manier als cruiseschepen en jetski's - terwijl beide mensen over zee vervoeren, zijn er bijna geen situaties in de echte wereld waarin beide kunnen worden gebruikt.
Op een meer persoonlijke noot: ik heb de afgelopen jaren veel geleerd van Córda's technische leiderschap, hetzij door bijeenkomsten, correspondentie of hun openbare geschriften, waarvan een groot deel plaatsvond voordat ze bij R3 kwamen. Een deel van mijn interesse in Corda komt voort uit het respect dat ik heb voor dit team, en alleen al daarom is Corda het bestuderen waard voor iedereen die op zoek is naar inzicht in het veld van gedistribueerde grootboeken.
Introductie van blockchains
Om Corda te begrijpen, is het handig om met conventionele blockchains te beginnen. Het doel van een blockchain is om een database of grootboek direct en veilig te laten delen door niet-vertrouwende partijen. Dit in tegenstelling tot gecentraliseerde databases, die worden opgeslagen en beheerd door één organisatie. Een blockchain heeft meerdere “nodes”, die elk een kopie van de database opslaan en tot een andere organisatie kunnen behoren. Knooppunten maken op een dichte peer-to-peer-manier verbinding met elkaar, met behulp van een "roddelprotocol" waarin elk knooppunt zijn collega's constant alles vertelt wat het leert. Als resultaat kan elk knooppunt snel een bericht naar het hele netwerk verzenden via vele alternatieve paden.
Een database, gecentraliseerd of blockchain-aangedreven, begint in een lege staat en wordt bijgewerkt via “transacties”. Een transactie wordt gedefinieerd als een reeks databasewijzigingen die "atomair" zijn, wat betekent dat ze slagen of mislukken als geheel. Stel je een database voor die een financieel grootboek vertegenwoordigt, met één rij per rekening. Een transactie waarbij Alice $ 10 aan Bob betaalt, bestaat uit drie stappen: (1) verifieer dat de rekening van Alice ten minste $ 10 bevat, (2) trek $ 10 af van de rekening van Alice en (3) voeg $ 10 toe aan de rekening van Bob. Als basisvereiste moet elk databaseplatform ervoor zorgen dat geen enkele transactie een andere verstoort. Deze "isolatie" wordt bereikt door de rijen voor zowel Alice als Bob te vergrendelen terwijl de betaling gaande is. Elke andere transactie waarbij deze rijen betrokken zijn, moet wachten tot deze is voltooid.
In een blockchain verwerkt elk knooppunt onafhankelijk elke transactie op zijn eigen kopie van de database. Transacties worden overal op het netwerk gemaakt en automatisch doorgegeven aan alle andere knooppunten. Aangezien de organisaties die knooppunten uitvoeren, verschillende (of zelfs tegenstrijdige) belangen kunnen hebben, kunnen ze elkaar niet vertrouwen om eerlijk te handelen. Blockchains hebben daarom regels nodig die bepalen of een bepaalde transactie al dan niet geldig is. In een gedeeld financieel grootboek voorkomen deze regels dat gebruikers elkaars geld uitgeven of geld uit de lucht toveren.
Naast de regels die de geldigheid van transacties bepalen, moeten blockchains ook bepalen hoe transacties worden besteld, aangezien deze volgorde in veel gevallen cruciaal is. Als Alice $ 15 heeft en probeert om $ 10 naar zowel Bob als Charlie te sturen in twee afzonderlijke transacties, kan slechts één van deze betalingen slagen. Hoewel we misschien willen zeggen dat de eerste transactie voorrang heeft, heeft een peer-to-peer-netwerk geen objectieve definitie van "eerste", aangezien berichten in verschillende volgorde op verschillende knooppunten kunnen aankomen.
Transactieregels
In algemene zin wordt de informatie in elke database gescheiden in records of "rijen", en een transactie kan drie verschillende dingen doen: rijen verwijderen, rijen maken en / of rijen wijzigen. Deze kunnen verder worden teruggebracht tot twee, aangezien het wijzigen van een rij gelijk staat aan het verwijderen van die rij en in plaats daarvan een nieuwe maken. Om terug te gaan naar de betaling van Alice aan Bob, wordt haar rij met $ 15 verwijderd en worden er twee nieuwe rijen gemaakt - een met $ 10 voor Bob en de andere met $ 5 in "wisselgeld" voor Alice.
Volgens de terminologie van bitcoin en Corda, duiden we de rijen die door een transactie zijn verwijderd aan als de "inputs" en de rijen die zijn gemaakt als de "outputs". Elke rij die door een transactie wordt verwijderd, moet zijn gemaakt door een eerdere transactie. Daarom verbruikt (of "besteedt") elke transactie-input de output van een eerdere transactie. De up-to-date inhoud van de database wordt bepaald door de reeks "niet-bestede transactie-outputs" of "UTXO's".
In een blockchain is een transactie geldig als deze aan de volgende drie voorwaarden voldoet:
- Juistheid. De transactie moet een legitieme transformatie van inputs naar outputs vertegenwoordigen. In een financieel grootboek moet bijvoorbeeld de totale hoeveelheid geld in de inputs overeenkomen met het totaal in de outputs, om te voorkomen dat geld op magische wijze verschijnt of verdwijnt. De enige uitzonderingen zijn speciale "uitgifte" of "pensioen" -transacties, waarbij fondsen expliciet worden toegevoegd of verwijderd.
- autorisatie. De transactie moet worden geautoriseerd door de eigenaar van elke output die door zijn inputs wordt verbruikt. In een financieel grootboek wordt hiermee voorkomen dat deelnemers elkaars geld zonder toestemming uitgeven. De transactie-autorisatie wordt beheerd met behulp van asymmetrische (of publiek-private sleutel) cryptografie. Elke rij heeft een eigenaar, geïdentificeerd door een openbare sleutel, waarvan de bijbehorende privésleutel geheim wordt gehouden. Om geautoriseerd te worden, moet een transactie digitaal worden ondertekend door de eigenaar van elk van zijn inputs. (Houd er rekening mee dat rijen ook complexere 'multisignature'-eigenaren kunnen hebben, bijvoorbeeld wanneer twee van de drie partijen het gebruik ervan kunnen autoriseren.)
- Uniciteit. Als een transactie een bepaalde output verbruikt, kan geen enkele andere transactie die output opnieuw gebruiken. Dit is hoe we voorkomen dat Alice tegenstrijdige betalingen doet aan zowel Bob als Charlie. Hoewel de transacties voor beide betalingen correct en geautoriseerd zouden kunnen zijn, zorgt de uniciteitsregel ervoor dat er slechts één door de database wordt verwerkt.
In een conventionele blockchain controleert elk knooppunt elke transactie op basis van deze drie regels. Later zullen we zien hoe Corda deze verantwoordelijkheid anders verdeelt.
Bouw blokken
Een blockchain is letterlijk een ketting van blokken, waarbij elk blok met het vorige linkt via een "hash" die de inhoud op unieke wijze identificeert. Elk blok bevat een geordende reeks transacties die niet met elkaar of met die in eerdere blokken mogen conflicteren, evenals een tijdstempel en wat andere informatie. Net als transacties verspreiden blokken zich snel over het netwerk en worden ze onafhankelijk geverifieerd door elk knooppunt. Zodra een transactie in een blok verschijnt, wordt deze "bevestigd", waardoor knooppunten elke conflicterende transactie weigeren.
Wie is verantwoordelijk voor het maken van deze blokken en hoe kunnen we er zeker van zijn dat alle knooppunten het eens zijn over de gezaghebbende keten? Deze kwestie van "consensusalgoritmen" is een enorm onderwerp op zich, gevuld met wonderlijke acroniemen zoals PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance) en DPoS (Delegated Proof of Stake). Daar gaan we hier niet op in. Het volstaat te zeggen dat geautoriseerde blockchains voor bedrijven een soort stemprogramma gebruiken, waarbij stemmen worden toegekend aan "validator nodes" die collectief verantwoordelijk zijn. Het schema zorgt ervoor dat, zolang een grote meerderheid van de validatorknooppunten correct en eerlijk functioneert, transacties in een (bijna) eerlijke volgorde de keten binnenkomen, tijdstempels (ongeveer) correct zijn en bevestigde transacties vervolgens niet kunnen worden teruggedraaid.
Voordat ik enkele van de uitdagingen van blockchains bespreek, wil ik graag drie aanvullende punten toelichten. Ten eerste, hoewel ik in dit stuk een financieel grootboek gebruik als voorbeeld, ondersteunt het input-output-model van transacties een veel bredere verscheidenheid aan use-cases. Elke rij kan een rijk data-object (denk JSON) bevatten dat veel verschillende soorten informatie bevat - inderdaad, Corda gebruikt om deze reden het woord "staat" in plaats van "rij". Rijkere staten veranderen niets fundamenteels aan transactieregels: correctheid wordt nog steeds gedefinieerd in termen van invoer en uitvoer, autorisatie is nog steeds vereist voor elke invoer en uniekheid zorgt ervoor dat elke uitvoer maar één keer kan worden uitgegeven.
Ten tweede zijn er veel blockchain-use-cases waarin rijen alleen in de database worden gemaakt en nooit worden verwijderd. Deze toepassingen hebben betrekking op algemene gegevensopslag, tijdstempels en notarisatie, in plaats van het bijhouden van een soort grootboek dat in beweging is. In deze data-only applicaties voegen transacties data toe aan hun output, maar verbruiken ze geen data in hun input, waardoor de regels voor correctheid, autorisatie en uniciteit kunnen worden vereenvoudigd. Hoewel data-only use cases een steeds grotere focus zijn van onze eigen ontwikkeling bij MultiChain, noem ik ze hier slechts terloops, aangezien Corda duidelijk niet met hen in gedachten is ontworpen.
Ten slotte is het vermeldenswaard dat sommige blockchain-platforms geen input-output-model gebruiken. Ethereum presenteert een alternatief paradigma, waarbij de keten een virtuele computer bestuurt met een globale staat die wordt beheerd door “contracten”, en transacties niet expliciet met elkaar verbinden. Een bespreking van het model van Ethereum in toegestane blockchains valt hier buiten ons bereik, maar zie dit artikel voor een gedetailleerde uitleg en kritiek. Een belangrijk voordeel van het input-output-paradigma is dat de meeste transacties parallel en onafhankelijk van elkaar kunnen worden verwerkt. Deze eigenschap is cruciaal voor Corda, zoals we later zullen zien.
Blockchain-uitdagingen
Laten we ons voorstellen dat de banken van de wereld een gedeeld grootboek hebben gecreëerd om de eigendom, overdracht en uitwisseling van een verscheidenheid aan financiële activa weer te geven. In theorie zou dit kunnen worden geïmplementeerd op een reguliere blockchain, zoals hierboven beschreven. Elke rij zou drie kolommen bevatten: een item-ID zoals GOOG of USD, de hoeveelheid waarvan het eigendom is en de openbare sleutel van de eigenaar. Elke transactie zou een of meer activa van de inputs naar de outputs overbrengen, met speciale gevallen voor uitgifte en pensionering.
Elke bank in het netwerk zou een of meer knooppunten hebben die verbinding maken met de andere en transacties verspreiden en verifiëren. Senior leden zouden optreden als validators, met de collectieve verantwoordelijkheid voor het bevestigen, bestellen en timestamping van transacties. Het wangedrag van elke validator zou zichtbaar zijn voor alle knooppunten in het netwerk, wat leidt tot afkeuring, verbanning en / of gerechtelijke procedures. Met dit alles op zijn plaats, kan elk financieel actief binnen enkele seconden over de wereld worden verplaatst, met de regels van correctheid, autorisatie en uniekheid die de integriteit van het grootboek garanderen.
Wat is er mis met deze foto? Eigenlijk zijn er drie problemen: schaalbaarheid, vertrouwelijkheid en interoperabiliteit. De kwestie van schaalbaarheid is eenvoudig genoeg. Onze voorgestelde interbancaire blockchain vereist dat elk lid elke transactie die door elke bank ter wereld wordt uitgevoerd, verifieert, verwerkt en opslaat. Zelfs als dit technisch haalbaar zou zijn voor de grootste financiële instellingen, zouden de kosten van berekening en opslag voor velen een aanzienlijke barrière vormen. Wij zouden toch liever een systeem hebben waarin deelnemers alleen die transacties zien waarbij ze direct betrokken zijn.
Maar laten we schaalbaarheid terzijde schuiven, want het kan uiteindelijk worden opgelost met dure computers en slimme engineering. Een meer fundamentele kwestie is vertrouwelijkheid. Hoewel het misschien utopisch klinkt als elke transactie overal zichtbaar is, is dergelijke radicale transparantie in de echte wereld een niet-starter in termen van concurrentie en regelgeving. Als JP Morgan en HSBC een paar activa ruilen, is het onwaarschijnlijk dat Citi en de Bank of China zien wat ze deden. Als de transactie werd uitgevoerd namens de klanten van deze banken, zou het voor hen illegaal kunnen zijn om deze op deze manier bloot te stellen.
Een voorgestelde oplossing voor het probleem van vertrouwelijkheid zijn "kanalen", zoals geïmplementeerd in Hyperledger Fabric. Elk kanaal heeft bepaalde leden, die een subset zijn van de knooppunten in het netwerk als geheel. De transacties van een kanaal zijn alleen zichtbaar voor zijn leden, zodat elk kanaal effectief als een afzonderlijke blockchain fungeert. Hoewel dit de vertrouwelijkheid ten goede komt, ondermijnt het ook het hele punt van de oefening. Activa kunnen niet van het ene kanaal naar het andere worden verplaatst zonder de hulp van een vertrouwde tussenpersoon die op beide actief is. De moeilijkheid van deze benadering werd onlangs benadrukt door SWIFT's verzoening proof-of-concept, die schatte dat er meer dan 100,000 kanalen nodig zouden zijn bij de productie. Dat zijn 100,000 eilanden waartussen activa niet rechtstreeks kunnen worden verplaatst.
In gevallen waarin alleen gegevens worden gebruikt, waarbij transacties geen gegevens in de invoer verbruiken, kan het vertrouwelijkheidsprobleem worden omzeild door de gegevens in de uitvoer te versleutelen of te hashen en de decoderingssleutel of niet-gehashte gegevens buiten de keten te leveren. Maar voor een transactie waarvan de invoer de uitvoer van andere transacties verbruikt, moet elk knooppunt die invoer en uitvoer zien om de transactie te valideren. Terwijl geavanceerde cryptografische technieken zoals vertrouwelijke activa en nul kennisbewijzen zijn ontwikkeld om dit probleem voor financiële grootboeken gedeeltelijk of volledig op te lossen, deze vormen een aanzienlijke prestatielast en / of kunnen niet worden gegeneraliseerd naar een correctheidsregel.
Laten we tot slot praten over interoperabiliteit. In een ideale wereld zou elke bank zich onmiddellijk aansluiten bij onze wereldwijde blockchain op de dag dat deze werd gelanceerd. In werkelijkheid zouden echter meerdere blockchains worden overgenomen door verschillende groepen banken, op basis van geografische ligging of reeds bestaande relaties. Na verloop van tijd kan een lid van de ene groep transacties willen aangaan met een lid van een andere groep door een activum tussen ketens over te dragen. Net als bij kanalen, kan dit alleen worden bereikt met de hulp van een vertrouwde tussenpersoon, die het doel van de blockchain verslaat.
Corda streeft ernaar deze onderling gerelateerde problemen van schaalbaarheid, vertrouwelijkheid en interoperabiliteit op te lossen door een radicale heroverweging van de manier waarop gedistribueerde grootboeken werken.
Corda's gedeeltelijk zicht
Het fundamentele verschil in Corda is gemakkelijk uit te leggen: elk knooppunt ziet slechts enkele, in plaats van alle, transacties die op het netwerk worden verwerkt. Hoewel een enkel logisch en conceptueel grootboek wordt gedefinieerd door al deze transacties, ziet geen enkel individueel knooppunt dat grootboek in zijn geheel. Om een vergelijking te maken: op elk moment in de tijd bevindt elk dollarbiljet ter wereld zich op een bepaalde plaats, maar niemand weet waar ze allemaal zijn.
Dus welke transacties ziet een Corda-knooppunt? Allereerst degenen waarbij het direct betrokken is, omdat het een van de inputs of outputs van die transactie bezit. In een financieel grootboek omvat dit elke transactie waarbij een knooppunt geld verzendt of ontvangt. Laten we zeggen dat Alice een transactie maakt die haar $ 15 aan invoer verbruikt en twee outputs heeft - een met $ 10 voor mij en de andere met $ 5 aan "wisselgeld" voor haar. Nadat Alice mij deze transactie heeft gestuurd, kan ik deze controleren op juistheid en autorisatie, om te controleren of de inputs en outputs in evenwicht zijn en dat Alice heeft getekend.
Deze transactie alleen is echter niet voldoende. Ik moet ook verifiëren dat de invoerstatus van $ 15 van Alice echt bestaat, en dat ze het niet alleen heeft verzonnen. Dat betekent dat ik de transactie moet zien die deze toestand heeft gecreëerd, en deze ook moet controleren op juistheid en autorisatie. Als deze vorige transactie, die Alice $ 15 heeft gestuurd, een input van $ 10 heeft van Denzel en nog eens $ 5 input van Eric, dan moet ik ook de transacties verifiëren die deze hebben gemaakt. En zo gaat het verder, helemaal terug naar de oorspronkelijke "uitgiftetransactie" waarin het actief werd gecreëerd. Het aantal transacties dat ik moet verifiëren, hangt af van het aantal keren dat de activa van eigenaar zijn veranderd en de mate van achterwaartse vertakking.
Aangezien Corda-knooppunten niet automatisch elke transactie zien, hoe kunnen ze dan de benodigde transacties verkrijgen? Het antwoord is van de afzender van elke nieuwe transactie. Voordat Alice een transactie maakt waarbij haar $ 15 wordt verbruikt, moet ze de transactie waarin ze deze heeft ontvangen, al geverifieerd hebben. En aangezien Alice de bovenstaande recursieve techniek moet hebben toegepast, zal ze een kopie hebben van elke transactie die nodig is voor deze verificatie. Bob vraagt deze transacties eenvoudigweg aan bij Alice als onderdeel van hun interactie. Als Alice niet op de juiste manier reageert, concludeert Bob dat Alice hem probeert te misleiden en weigert hij de binnenkomende betaling. In het geval dat Bob een nieuwe transactie ontvangt waarvan de invoer meerdere eigenaren heeft, kan hij van elk de nodige bewijzen verkrijgen.
Notarissen introduceren
Tot dusver hebben we uitgelegd hoe Bob de juistheid en autorisatie van een inkomende transactie kan verifiëren, inclusief het recursief achterhalen van de oorsprong van de invoer. Maar er is nog een regel waar we over na moeten denken: uniekheid. Laten we zeggen dat Alice kwaadaardig is. Ze kan één transactie genereren waarbij ze $ 10 aan Bob betaalt en een andere waarin ze dezelfde $ 10 aan Charlie betaalt. Ze kan deze transacties naar respectievelijk Bob en Charlie sturen, samen met een volledig bewijs van juistheid en autorisatie van elk. Hoewel beide transacties met elkaar in conflict zijn doordat ze dezelfde staat consumeren, kunnen Bob en Charlie dit niet weten.
Conventionele blockchains lossen dit probleem op doordat elk knooppunt elke transactie ziet, waardoor conflicten gemakkelijk kunnen worden opgespoord en afgewezen. Dus hoe pakt Corda, met zijn gedeeltelijke zichtbaarheid van transacties, hetzelfde probleem aan? Het antwoord is met de hulp van een "notaris". Een notaris is een vertrouwde partij (of partijen die samenwerken) die garandeert dat een bepaalde staat maar één keer wordt geconsumeerd. Elke staat heeft een specifieke notaris, die elke transactie moet ondertekenen waarin die staat wordt verbruikt. Zodra een notaris dit heeft gedaan, mag hij geen andere transactie voor dezelfde staat ondertekenen. Notarissen zijn de hoeders van de unieke transactie van het netwerk.
Hoewel elke staat een andere notaris kan hebben, moeten alle staten die door een bepaalde transactie worden gebruikt, aan dezelfde worden toegewezen. Dit vermijdt problemen met betrekking tot impasses en synchronisatie, die bekend zouden moeten zijn voor mensen met gedistribueerde database-ervaring. Laten we zeggen dat Alice en Bob overeenkomen om Alice's $ 10 in te wisselen voor Bob's £ 7. De transactie voor deze uitwisseling moet worden ondertekend door de notarissen van beide staten, maar welke gaat als eerste? Als de notaris van Alice tekent, maar die van Bob om de een of andere reden faalt, blijft Alice achter met een onvolledige transactie en kan ze haar $ 10 nooit meer gebruiken. Als de tekens van Bob eerst zijn, wordt hij op dezelfde manier blootgesteld. Hoewel we misschien graag willen dat notarissen gewoon samenwerken, vereist dit in de praktijk wederzijds vertrouwen en het gebruik van een consensusprotocol, complicaties die de ontwerpers van Corda wilden vermijden.
Als staten met verschillende notarissen nodig zijn als input voor een enkele transactie, voeren hun eigenaren eerst speciale “notariswisseltransacties” uit, die een staat van de ene notaris naar de andere verplaatsen en niets anders veranderen. Dus wanneer partijen een transactie met meerdere inputs bouwen, moeten ze eerst overeenkomen welke notaris wordt gebruikt en vervolgens de nodige notariswijzigingen uitvoeren. Hoewel de ontwikkelaar in mij een klein beetje pijn voelde bij het lezen van deze tijdelijke oplossing, is er geen reden waarom het niet werkt zolang notarissen meespelen.
Er moet ook worden verduidelijkt dat, hoewel elke notaris een enkele logische actor is wat betreft het ondertekenen van transacties, deze niet onder de controle van een enkele partij hoeft te staan. Een groep organisaties zou gezamenlijk een notaris kunnen runnen, met behulp van een geschikt consensusprotocol waarin een meerderheid van de deelnemers nodig is om een geldige handtekening te genereren. Dit zou voorkomen dat een enkele kwaadwillende partij het unieke karakter ondermijnt door transacties te ondertekenen die conflicteren. In theorie zouden we zelfs elk knooppunt in het netwerk kunnen laten deelnemen aan dit soort gedeelde notarisering, hoewel we in dat geval min of meer terug zouden zijn naar een conventionele blockchain.
Score maken
Laten we de belangrijkste verschillen tussen Corda en conventionele blockchains samenvatten. In Corda is er geen uniforme blockchain die alle bevestigde transacties bevat. Knooppunten zien alleen die transacties waarbij ze direct betrokken zijn, of waarvan ze historisch gezien afhankelijk zijn. Knooppunten zijn verantwoordelijk voor het controleren van de juistheid en autorisatie van transacties, maar vertrouwen op vertrouwde notarissen om de uniciteit te verifiëren.
Natuurlijk is Corda veel meer dan dit: het gebruik van digitale certificaten om identiteit te verifiëren, 'netwerkkaarten' om knooppunten te helpen elkaar te vinden en te vertrouwen, 'contracten' per staat die de juistheid definiëren vanuit het perspectief van elke staat, een deterministische versie van de Java Virtual Machine die deze contracten uitvoert, 'stromen' die transactieonderhandelingen automatiseren, 'tijdvensters' die transacties beperken tot de tijd, 'orakels' die getuigen van externe feiten en 'CorDapps' die veel dingen bundelen voor gemakkelijke distributie . Hoewel elk van deze functies interessant is, zijn equivalenten voor iedereen te vinden op andere blockchain-platforms. Mijn doel in dit artikel is om me te concentreren op dat wat Corda uniek maakt.
Dus maakt Corda zijn belofte waar? Lost het de schaalbaarheid, vertrouwelijkheid en interoperabiliteitsproblemen van blockchains op? En hoeveel van de prijs betaalt Corda bij het maken van zijn specifieke keuzes?
Soms beter schaalbaar
Laten we beginnen met schaalbaarheid. Hier lijkt het voordeel van Corda duidelijk, aangezien knooppunten slechts enkele van de transacties in een netwerk zien. In een gewone blockchain wordt de maximale doorvoer beperkt door de snelheid van het langzaamste knooppunt bij het verwerken van transacties. Een Corda-netwerk kan daarentegen wel een miljoen transacties per seconde verwerken, terwijl elk knooppunt daar slechts een fractie van ziet. Schaalbaarheid strekt zich ook uit tot notarissen, aangezien de taak van het ondertekenen van transacties op uniciteit kan worden verspreid over veel verschillende notarissen, die elk verantwoordelijk zijn voor een klein deel van de staten van het netwerk.
Dat gezegd hebbende, is er één situatie waarin Corda veel slechter presteert dan een blockchain. Dit gebeurt wanneer een knooppunt een nieuwe transactie ontvangt die afhankelijk is van vele andere transacties die het nog niet eerder heeft gezien. Stel u een zeer liquide activum voor dat tien jaar geleden werd uitgegeven en ongeveer elke vijf minuten van eigenaar wisselt. Het pad van een nieuwe transactie terug naar de uitgifte van dit actief zal meer dan een miljoen transacties lang zijn. Wanneer een knooppunt dit activum voor de eerste keer ontvangt, moet het deze miljoen transacties van de afzender ophalen en elk op zijn beurt verifiëren. Bij een (redelijk optimistisch) tempo van 10 transacties per seconde zou er een vertraging van 1000 minuten zijn voordat de ontvanger het activum kon doorsturen - duidelijk te lang voor zoiets liquide.
Waarom hebben blockchains geen last van dit probleem? Omdat knooppunten elke transactie zien en verifiëren terwijl deze plaatsvindt, werken ze voortdurend de status van het grootboek bij en weten ze precies wie op dit moment elk activum bezit. Zelfs als een knooppunt nog nooit een bepaald activum heeft gehad, kan het de transactie waarin het het ontvangt onmiddellijk verifiëren en het vervolgens onmiddellijk doorsturen. Anders gezegd, blockchain-knooppunten moeten transacties verifiëren die voor hen mogelijk niet relevant zijn, maar door dat te doen, betalen ze de kosten voor het controleren van toekomstige transacties die binnenkomen vooruit. Hoewel Corda-knooppunten over het algemeen minder druk zijn, voeren ze de het risico dat u in een oogwenk een enorme hoeveelheid werk moet verzetten. Daar is niets schaalbaars aan.
Iets vertrouwelijker
Laten we verder gaan met vertrouwelijkheid. In Corda zien knooppunten slechts een deel van de transacties van een netwerk, wat onmiskenbaar een betere privacy betekent dan conventionele blockchains. Desalniettemin lost Corda het vertrouwelijkheidsprobleem nog lang niet op, omdat knooppunten nog steeds enkele transacties zien die hun niets van doen. Om een eenvoudig voorbeeld te geven: als Alice Bob $ 10 betaalt, dan stuurt Bob die $ 10 door naar Charlie, Charlie's node moet de transactie tussen Alice en Bob te zien krijgen, ook al is hij er niet bij betrokken. Op het moment dat Alice Bob betaalde, kon ze niet weten wie deze transactie in de toekomst zou kunnen zien, en iedereen zou het op elk moment kunnen ontvangen.
Om eerlijk te zijn, de ontwikkelaars van Corda zijn zich bewust van dit probleem en bespreken het in hoofdstuk 15 van hun Technisch witboek. De paper stelt eenvoudige strategieën voor, zoals het gebruik van meerdere openbare sleutels per entiteit of het verminderen van de traceerbaarheid door activa terug te sturen naar emittenten voor heruitgifte (vergelijkbaar met “muntmixers” voor cryptovaluta). Het vermeldt ook meer geavanceerde toekomstige mogelijkheden, zoals het gebruik van Tor-achtige anonimiseringsnetwerken om de IP-adressen van deelnemers te verbergen en gebruik te maken van zero knowledge proofs of Intel's veilige enclaves om transacties te valideren zonder hun inhoud prijs te geven. Hoewel al deze suggesties geldig zijn, kunnen ze ook worden toegepast op reguliere blockchains met behulp van het input-output-model, en zijn ze inderdaad in cryptocurrencies zoals Dash, Zcash en Verge geweest. Het enige unieke voordeel van Corda in termen van vertrouwelijkheid blijft dus de verminderde zichtbaarheid van transacties - op zijn best een onvolledige oplossing.
Allemaal in de kweek
Om de schaalbaarheid en vertrouwelijkheidsvoordeel van Corda beter te begrijpen, moeten we opmerken hoe dit afhangt van de dichtheid en overlapping van de relaties tussen transacties. Stelt u zich een "stamboom" voor van de transacties die in een netwerk worden uitgevoerd, waarbij de ouders van elke transactie de voorgaande zijn waarvan ze onmiddellijk afhankelijk is. In het bijzonder, wanneer de output van een transactie wordt verbruikt door de input van een ander, tekenen we een pijl die de relatie tussen ouder en kind aangeeft. Transacties kunnen een willekeurig aantal ouders en kinderen hebben, hoewel we in de meeste gevallen er maar een paar verwachten.
Gezien deze stamboom definiëren we de voorouders van een transactie als de ouders, grootouders, overgrootouders, enzovoort. De “Adam en Eva” van onze boom zijn de uitgiftetransacties die activa hebben gecreëerd en geen eigen ouders hebben. Net als bij gewone stambomen kunnen twee transacties geen voorouders van elkaar zijn. In formele computerwetenschappelijke termen is dit een Gerichte acyclische grafiek of DAG, waarin afkomst wordt gedefinieerd als de transitieve sluiting van de ouderrelatie.
Bedenk dat wanneer een Corda-knooppunt een transactie verwerkt, het alle voorouders van die transactie moet downloaden en verifiëren, behalve degene die het eerder heeft gezien. Dus als de stamboom diep is, kunnen nieuwe inkomende transacties een groot aantal voorouders hebben die moeten worden geverifieerd, wat het schaalbaarheidsprobleem van Corda veroorzaakt. Bovendien, als de stamboom een hoge mate van kruising bevat, kunnen de voorouders van een nieuwe transactie veel of de meeste eerdere transacties in het netwerk bevatten. In dit geval levert Corda weinig voordeel op op het gebied van privacy.
Als de stamboom van transacties daarentegen oppervlakkig is en veel losgekoppelde eilanden bevat die geen interactie met elkaar hebben, komen de voordelen van Corda naar voren. Nodes hoeven nooit een groot aantal transacties tegelijk te verifiëren en kunnen in het duister worden gehouden over de meeste transacties die geen verband houden met hun eigen transacties. Als het wordt gebruikt als een financieel grootboek, zouden we kunnen zeggen dat Corda ideaal is voor zeer gefragmenteerde markten waarvan de activa zelden van eigenaar wisselen.
Interoperabiliteit voor de overwinning
Hier is een gebied waarin Corda echt schittert. Stelt u zich twee afzonderlijke Corda-netwerken voor, met verschillende sets activa en deelnemers. Op een gegeven moment wil een deelnemer in het ene netwerk een asset naar iemand in het andere sturen. In tegenstelling tot conventionele blockchains, is er geen verwachting dat een knooppunt alle eerdere transacties heeft geverifieerd, dus het knooppunt dat dit nieuwe activum ontvangt, zal niets ongewoons ervaren. Wanneer de transactie binnenkomt, vraagt en verifieert het eenvoudig de relevante geschiedenis, zonder zich ervan bewust te zijn dat dit afkomstig is van een “apart netwerk”. Om een cliché uit te rekken, zouden we kunnen zeggen dat er geen vreemden in Corda zijn - alleen vrienden die elkaar nog niet hebben ontmoet.
In werkelijkheid zijn de dingen niet zo eenvoudig. Elk Corda-knooppunt beslist expliciet welke notarissen te vertrouwen, aangezien een zich misdragende notaris kan leiden tot financiële chaos. Bovendien hebben knooppunten een "certificaat" nodig dat is verleend door een "portier" om verbinding te maken met andere knooppunten in een netwerk, aangezien we niet kunnen toestaan dat willekeurige leden van het publiek verbinding maken met knooppunten en hun bronnen verspillen. Dus voordat een knooppunt op het ene netwerk kan beginnen met het aanvragen en verifiëren van transacties van een ander netwerk, moet het worden toegevoegd aan de lijst met vertrouwde notarissen en het juiste certificaat verkrijgen. Hoewel dit enige handmatige configuratie en administratie met zich meebrengt, is dit het minimum dat kan worden verwacht voor een systeem van deze aard. Over het algemeen is het redelijk om te concluderen dat interoperabiliteit de grote overwinning van Corda is op conventionele blockchains.
Herbemiddeling
Het is tijd om te praten over desintermediatie, de olifant in Corda's kamer. In de context van blockchains betekent disintermediation dat elke deelnemer elke transactie voor zichzelf kan verifiëren, zonder afhankelijk te zijn van het goede gedrag van derden. In mijn meningis disintermediation het belangrijkste voordeel van blockchains ten opzichte van gecentraliseerde databases, waarin alle deelnemers volledig afhankelijk zijn van de eigenaar van die database. Als de deelnemers aan een netwerk een tussenpersoon hebben waarop ze kunnen vertrouwen, en er zijn geen zakelijke of regelgevende argumenten voor desintermediatie, dan is er geen punt bij het gebruik van een blockchain. Gecentraliseerde databases zijn sneller en efficiënter en voorkomen het probleem van vertrouwelijkheid van transacties.
Bereiken de deelnemers in een Corda-netwerk dus disintermediatie? Nou ja, ja en ja maar nee. Voor transactielevering vinkt Corda het vakje aan, aangezien de knooppunten die bij een transactie betrokken zijn, rechtstreeks met elkaar praten. Qua correctheid en autorisatie verkeert het ook in goede staat, aangezien elk knooppunt deze eigenschappen zelf kan controleren. Als het echter gaat om het verifiëren van de uniciteit van de transactie, slaagt Corda niet voor de desintermediatietest. Nodes kunnen de uniciteit voor zichzelf niet bevestigen, aangezien ze niet elke transactie in het netwerk zien en de taak wordt uitbesteed aan vertrouwde notarissen.
Corda-deelnemers zijn op een aantal manieren overgeleverd aan notarissen. Ten eerste kan een notaris weigeren een transactie te ondertekenen, zelfs als de input ervan output verbruikt die nog nooit eerder is gebruikt. In een financieel grootboek voorkomt dit dat iemand zijn activa verzendt of ruilt. Ten tweede kan een notaris twee tegenstrijdige transacties ondertekenen die dezelfde output verbruiken, waardoor twee partijen geloven dat ze hetzelfde hebben ontvangen. Aangezien beide ontvangers van het dubbele activum het verzenden of uitwisselen in verdere transacties, verspreidt de besmetting zich en kan de integriteit van het volledige grootboek snel worden ondermijnd. Ten slotte kan een notaris weigeren om een "notariswijzigingstransactie" te ondertekenen om een staat over te dragen aan een concurrent, waardoor de eigenaar van het vermogen in feite gegijzeld wordt. Voor een transactie waarbij staten bij verschillende notarissen betrokken zijn, is het ver te zeggen dat Corda deze introduceert meer bemiddeling dan een gecentraliseerde database, omdat verschillende derde partijen de touwtjes in handen hebben.
Om dit risico in perspectief te plaatsen, is het de moeite waard eraan te herinneren dat Corda-notarissen niet door één enkele organisatie hoeven te worden gecontroleerd. Ze kunnen ook bestaan uit een groep knooppunten met een consensusalgoritme dat slechte actoren kan tolereren. In dit geval werkt een notaris prima, zolang de meeste van zijn aangesloten knooppunten de regels volgen. Op het eerste gezicht klinkt dit eerder als een blockchain, die ervan afhangt dat een meerderheid van validators zich goed gedraagt. Bij Corda zijn de risico's echter aanzienlijk hoger. Het ergste dat een kliek van blockchain-validators kan doen, is voorkomen dat sommige transacties worden bevestigd. Een kwaadwillende Corda-notaris kan ook tegenstrijdige transacties ondertekenen, waardoor het grootboek in een inconsistente afgrond terechtkomt.
Een vreemd dier
Door schaalbaarheid, vertrouwelijkheid, interoperabiliteit en disintermediatie samen te brengen, is het moeilijk om een eenvoudig oordeel te vellen over het Corda-alternatief. Over het algemeen lijkt het, vanuit het perspectief van deze blockchain-platformontwikkelaar, nou… boeiend maar vreemd. Ontworpen om de belangrijkste problemen van schaalbaarheid en vertrouwelijkheid op te lossen, zijn de oplossingen van Corda onvolledig en sterk afhankelijk van de vorm van de transactiestamboom. Maar om deze gedeeltelijke overwinningen te behalen, verliest Corda een kerneigenschap van blockchains: het verwijderen van transactie-tussenpersonen. Hoewel Corda ongetwijfeld uitblinkt in interoperabiliteit, is dat echt genoeg?
Als we sceptisch willen zijn, zouden we kunnen zeggen dat het team van Corda een onmogelijke taak heeft gekregen: een soort blockchain ontwerpen die past bij de banken die R3 financieren. Maar het belangrijkste voordeel van blockchains ten opzichte van gecentraliseerde databases is disintermediatie, wat ten koste gaat van verminderde vertrouwelijkheid. Hoe zou deze afweging zinvol kunnen zijn voor financiële instellingen die geld verdienen door op te treden als tussenpersoon en zeer gevoelig zijn voor privacy? In dit licht bezien zou men Corda kunnen prijzen als een heroïsch maar uiteindelijk onbevredigend compromis tussen de wens van de leden van R3 om iets blockchainy te doen, en de commerciële en regelgevende beperkingen waaronder ze bestaan.
Bewaarder 2.0
Maar ik geef de voorkeur aan een positievere benadering. In plaats van ons te concentreren op de vergelijking met blockchains, kunnen we Corda zien als een grote technische upgrade naar de financiële status quo. Vervang gewoon het woord "notaris" door "custodian", en het valt allemaal vrij netjes op zijn plaats. (EEN bewaarder is een financiële instelling die activa houdt namens anderen.) Ja, notarissen zijn tussenpersonen, die zowel transacties kunnen blokkeren als conflicten kunnen laten ontstaan, maar dit geldt ook voor de huidige bewaarders. Een “notariswisseltransactie” kan worden gezien als de overdracht van activa van de ene bewaarder naar de andere. En Corda-transacties worden door slechts één notaris ondertekend om dezelfde reden waarom we graag activa uitwisselen op één plek - om te voorkomen dat een van de partijen uit eigen zak komt.
Als we op deze manier naar Corda kijken, kunnen we zien hoe het verbetert ten opzichte van het traditionele custodial model:
- Het definieert een standaard computationeel paradigma en formaat voor het uitdrukken van financiële activa en andere contractuele verplichtingen.
- Het biedt open source software voor het interpreteren en uitvoeren van deze toezeggingen, en garandeert dat de partijen en bewaarders het eens zijn over de uitkomst van elke transactie.
- Complexe bewaarnemers met meerdere partijen die bescherming bieden tegen misbruik kunnen worden gecreëerd (alleen met behulp van software!) Door gebruik te maken van fouttolerante consensusalgoritmen.
- Er is een standaardproces (“notariswijziging”) gedefinieerd voor de overdracht van activa tussen bewaarders, en geen enkele bewaarder mag weigeren.
- Bewaarnemers kunnen een actief dat ze in bewaring hebben niet gebruiken zonder toestemming van de eigenaar, aangezien transacties ook moeten worden ondertekend door de eigenaren van hun inputs.
Ik ben verre van bankier, maar voor mij klinkt dit allemaal nogal veelbelovend. En misschien zou Corda net zo goed kunnen worden toegepast op andere bedrijfstakken met complexe bewaarstructuren, zoals verzekeringen of scheepvaart. Hoewel het ontwerp van Corda misschien niet de volledige disintermediatie van een blockchain biedt, stelt het een krachtige transformatie voor voor industrieën waarin tussenpersonen een essentiële rol spelen.
Zodra we deze manier van denken hebben doorlopen, rijst onvermijdelijk de vraag: als we notarissen al vertrouwen met de taak van leven en dood om de uniciteit te verifiëren, waarom zou u dan ook niet op hen vertrouwen voor correctheid en autorisatie? Corda heeft al het idee van een "validerende notaris", die transacties volledig verifieert alvorens zijn handtekening te zetten. In plaats van dat gewone Corda-knooppunten de voorouders van hun transacties downloaden en controleren, waarom vraagt u het dan niet gewoon aan een notaris? Dit zou kunnen helpen bij de schaalbaarheid en vertrouwelijkheid, aangezien de meeste knooppunten geen andere transacties zouden zien dan hun eigen. We kunnen zelfs suggereren dat de notarissen van een netwerk elkaar volledig vertrouwen, zodat u zich geen zorgen hoeft te maken over voorouders. De notaris van elke staat kon instaan voor de geldigheid ervan, door alleen de transactie te verifiëren die deze creëerde met de hulp van andere notarissen.
Laat Corda Corda zijn
Dit alles brengt ons terug naar waar we begonnen: Corda is niet echt een concurrent voor conventionele blockchains, inclusief MultiChain. Corda is Corda - een interessant nieuw type gedistribueerd grootboek, dat is geoptimaliseerd voor de behoeften van degenen die het financieren. Ik heb geen idee of Corda uiteindelijk zal slagen of falen, omdat ik de werkelijke kosten en baten niet ken in vergelijking met de huidige manier van werken. Maar wat er ook gebeurt in de toekomst, het is zeker de moeite waard om te studeren in termen van filosofie en ontwerp.
Wat MultiChain betreft, kiezen we voor een andere aanpak. Om een lijn van te stelen The West Wing, we zijn vastbesloten om "blockchain blockchain te laten zijn". Blockchains zijn wat ze zijn, en we hebben geen plannen om er iets anders van te maken. Als data-infrastructuur voor een gedeelde applicatie vertegenwoordigt een blockchain een specifieke afweging in vergelijking met een gecentraliseerde database - een winst in desintermediatie ten koste van verminderde vertrouwelijkheid. En we werken er hard aan om MultiChain 2.0 zo goed mogelijk te maken blockchain platform dat applicatieontwikkelaars kunnen gebruiken.
Plaats eventuele opmerkingen op LinkedIn.
Bron: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/
- Account
- Acroniemen
- actieve
- Extra
- Voordeel
- algoritme
- algoritmen
- Aanvraag
- toepassingen
- architectuur
- GEBIED
- dit artikel
- aanwinst
- Activa
- gehoor
- machtiging
- Bank
- Bank of China
- Bankieren
- Banken
- BEST
- Bill
- blockchain
- Box camera's
- Gebouw
- Bundel
- bedrijfsdeskundigen
- gevallen
- Veroorzaken
- ceo
- certificaat
- certificaten
- verandering
- kanalen
- controleren
- Controles
- kind
- Kinderen
- China
- Citi
- sluiting
- opmerkingen
- commercieel
- Gemeen
- afstand
- concurrentie
- concurrenten
- Computer Science
- computers
- conflict
- Overeenstemming
- toestemming
- consumeren
- content
- inhoud
- contracten
- Corda
- Kosten
- Wij creëren
- cruise
- cryptocurrencies
- cryptogeld
- geheimschrift
- Actueel
- Hechtenis
- Klanten
- DAG
- Dash
- gegevens
- gegevensopslag
- Database
- databanken
- dag
- transactie
- vertraging
- het leveren van
- levering
- Design
- Ontwikkelaar
- ontwikkelaars
- Ontwikkeling
- DEED
- digitaal
- Gedistribueerd grootboek
- Dollar
- olifant
- Engineering
- Enterprise
- ethereum
- uitwisseling
- Exchanges
- Oefening
- stof
- eerlijk
- familie
- Mode
- Voordelen
- Tot slot
- financieel
- Financiële instellingen
- einde
- Voornaam*
- eerste keer
- Focus
- formaat
- vol
- financiering
- fondsen
- toekomst
- Algemeen
- Globaal
- wereldwijde blockchain
- goed
- bestuur
- groot
- Groep
- Groeiend
- hier
- Verbergen
- Hoge
- Gemarkeerd
- geschiedenis
- Hoe
- HTTPS
- reusachtig
- idee
- Identiteit
- Onwettig
- Inclusief
- industrieën
- informatie
- Infrastructuur
- Instelling
- instellingen
- verzekering
- wisselwerking
- belang
- Interoperabiliteit
- betrokken zijn
- IP
- uitgifte
- problemen
- IT
- Java
- Jobomschrijving:
- mee
- sleutel
- toetsen
- kennis
- Groot
- leiden
- Leadership
- leidend
- geleerd
- Grootboek
- Juridisch
- Niveau
- licht
- Lijn
- Vloeistof
- Lijst
- lang
- groot
- Meerderheid
- maken
- Markt
- Markten
- Match
- vergaderingen
- Leden
- vermeldt
- miljoen
- model
- geld
- beweging
- meerdere ketens
- netwerk
- netwerken
- netwerken
- knooppunten
- notie
- open
- open source
- bestellen
- orders
- Overige
- Overig
- eigenaar
- eigenaren
- Pijn
- Papier
- paradigma
- ouders
- Betaal
- betaling
- betalingen
- Mensen
- prestatie
- perspectief
- filosofie
- beeld
- platform
- platforms
- Populair
- presenteren
- prijs
- privacy
- privaat
- Product
- productie
- bewijs
- eigendom
- beschermen
- publiek
- R3
- lezers
- lezing
- Realiteit
- samenvatting
- archief
- Regulatie
- Relaties
- verlichting
- Voorwaarden
- Resources
- pensioen
- beoordelen
- Risico
- reglement
- lopen
- lopend
- Schaalbaarheid
- Wetenschap
- SEA
- ziet
- zin
- reeks
- gedeeld
- Verzending
- Bermuda's
- Signs
- Eenvoudig
- Klein
- So
- Software
- Oplossingen
- OPLOSSEN
- snelheid
- Uitgaven
- verspreiden
- inzet
- begin
- gestart
- Land
- Staten
- Status
- mediaopslag
- shop
- winkels
- steunen
- Oppervlak
- system
- Technisch
- proef
- De toekomst
- het denken
- derden
- niet de tijd of
- tolerantie
- Traceerbaarheid
- transactie
- Transacties
- Transformatie
- Transparantie
- vervoeren
- Trust
- Ongehasht
- us
- USD
- gebruikers
- berm
- Verificatie
- Bekijk
- Virtueel
- virtuele machine
- zichtbaarheid
- Stemming
- wachten
- West
- WIE
- Wikipedia
- winnen
- Mijn werk
- wereld
- waard
- het schrijven van
- jaar
- Zcash
- nul