En detaljerad titt på blockchainen som inte blockchain
Som tiden går har blockchainvärlden separerats i två distinkta delar. Å ena sidan har offentliga blockchains med tillhörande kryptokurser haft ett anmärkningsvärt nyligen comeback, som minskar många en miljonär. Å andra sidan har användningen av tillåtna blockeringar eller företagets blockchains ökat tyst men stadigt, sett deras första levande implementeringar över flera branscher under 2017.
En intressant fråga att överväga är lämplig nivå av likhet mellan dessa två kedjetyper. Båda implementerar en delad databas med peer-to-peer-nätverk, offentlig-privat nyckelkryptografi, transaktionsregler och konsensusmekanismer som kan överleva skadliga aktörer. Det är en hel del gemensam grund. Men offentliga och privata blockchains har olika krav när det gäller konfidentialitet, skalbarhet och styrning. Kanske pekar dessa skillnader på behovet av radikalt divergerande konstruktioner.
Smakämnen Corda plattform, utvecklad av R3 bankkonsortium antar en tydlig ståndpunkt i denna fråga. Medan vissa aspekter inspirerades av offentliga blockchains designades Corda från grunden utifrån R3: s medlemmars behov. Även om R3 fortfarande använder ordet "blockchain" extensivt För att hjälpa till att marknadsföra sin produkt har Corda ingen blockkedja alls. Mer än någon annan ”distribuerad storbok” -plattform som jag är medveten om avviker Corda radikalt från arkitekturen för konventionella blockchains.
Mitt mål i det här stycket är att förklara dessa skillnader och diskutera deras konsekvenser, på gott och dåligt. Egentligen är bra och dåligt fel sätt att uttrycka det, eftersom den mer intressanta frågan är "Bra och dåligt för vad?" Den här artikeln är långt ifrån kort. Men i slutet av det hoppas jag att läsarna kommer att få viss förståelse för skillnaderna i Corda och deras därmed förekommande avvägningar. Corda är viktigt eftersom dess designbeslut gör att många av dilemman i företagets blockchains blir skarpa lättnad.
En sista sak innan vi dyker in. Som VD för företaget bakom MultiKedja, en populär företags blockchainplattform, varför skriver jag så djup om en förment konkurrerande produkt? Det vanliga skälet skulle vara att argumentera för MultiChains överlägsenhet, men det är inte min motivation här. Faktum är att jag inte ser Corda och MultiChain som konkurrenter, eftersom de är grundläggande olika vad gäller design, arkitektur och publik. Corda och MultiChain tävlar på samma sätt som kryssningsfartyg och jet-skidor - medan båda transporterar människor till sjöss finns det nästan inga verkliga situationer där båda kan användas.
På en mer personlig anmärkning har jag lärt mig mycket av Cordas tekniska ledning under de senaste åren, vare sig det var genom möten, korrespondens eller deras offentliga skrifter, varav mycket inträffade innan de gick med i R3. En del av mitt intresse för Corda kommer från respekten jag har för detta team, och av denna anledning är Corda värt att studera för alla som söker förståelse för det distribuerade huvudfältet.
Vi introducerar blockchains
För att förstå Corda är det bra att börja med konventionella blockchains. Syftet med en blockchain är att möjliggöra att en databas eller storbok delas direkt och säkert av icke-förtroendeparter. Detta står i kontrast till centraliserade databaser, som lagras och kontrolleras av en enda organisation. En blockchain har flera "noder", som var och en lagrar en kopia av databasen och kan tillhöra en annan organisation. Noder ansluter till varandra på ett tätt peer-to-peer-sätt, med hjälp av ett "skvallerprotokoll" där varje nod ständigt berättar sina kamrater allt de lär sig. Som ett resultat kan vilken nod som helst snabbt sända ett meddelande till hela nätverket via många alternativa vägar.
En databas, antingen centraliserad eller blockchain-driven, börjar i tomt tillstånd och uppdateras via "transaktioner". En transaktion definieras som en uppsättning databasändringar som är "atomiska", vilket innebär att de lyckas eller misslyckas som en helhet. Föreställ dig en databas som representerar en finansiell bokbok, med en rad per konto. En transaktion där Alice betalar $ 10 till Bob har tre steg: (1) verifiera att Alice's konto innehåller minst $ 10, (2) subtraherar $ 10 från Alice's konto och (3) lägger till $ 10 till Bobs konto. Som ett grundläggande krav måste varje databasplattform se till att ingen transaktion stör någon annan. Denna "isolering" uppnås genom att låsa raderna för både Alice och Bob medan betalningen pågår. Alla andra transaktioner som involverar dessa rader måste vänta tills den här är klar.
I en blockchain behandlar varje nod oberoende varje transaktion på sin egen kopia av databasen. Transaktioner skapas var som helst i nätverket och sprids automatiskt till alla andra noder. Eftersom organisationer som driver noder kan ha olika (eller till och med motstridiga) intressen kan de inte lita på varandra för att handla rättvist. Blockchains behöver därför regler som definierar om en viss transaktion är giltig eller inte. I en delad ekonomisk huvudbok förhindrar dessa regler användarna att spendera varandras pengar, eller trolla in pengar från tunn luft.
Tillsammans med reglerna som bestämmer transaktionens giltighet måste blockchains också definiera hur transaktioner kommer att beställas, eftersom denna beställning i många fall är kritisk. Om Alice har $ 15 och försöker skicka $ 10 till både Bob och Charlie i två separata transaktioner, kan bara en av dessa betalningar lyckas. Även om vi kanske vill säga att den första transaktionen har företräde har ett peer-to-peer-nätverk ingen objektiv definition av "först", eftersom meddelanden kan komma till olika noder i olika beställningar.
Transaktionsregler
I allmän mening är informationen i valfri databas uppdelad i poster eller "rader", och en transaktion kan göra tre olika saker: radera rader, skapa rader och / eller ändra rader. Dessa kan minskas ytterligare till två, eftersom modifiering av en rad motsvarar att radera den raden och skapa en ny på sin plats. För att gå tillbaka till Alice's betalning till Bob raderas hennes rad som innehåller $ 15 och två nya rader skapas - en innehåller 10 $ för Bob och den andra med $ 5 i "ändring" för Alice.
Efter bitcoin och Cordas terminologi betecknar vi raderna som raderas av en transaktion som dess "ingångar" och de som skapas som dess "utgångar". Varje rad som raderas av en transaktion måste ha skapats av en tidigare transaktion. Därför förbrukar (eller "spenderar" varje transaktion) en tidigare transaktions utgång. Det aktuella innehållet i databasen definieras av uppsättningen "outspenderade transaktionsutgångar" eller "UTXOs".
I en blockchain är en transaktion giltig om den uppfyller följande tre villkor:
- korrekt~~POS=TRUNC. Transaktionen måste representera en legitim omvandling från input till output. Till exempel i en finansiell bok måste den totala mängden medel i insatsvarorna matcha summan i utgångarna, för att förhindra att pengar magiskt visas eller försvinner. De enda undantagen är speciella transaktioner med ”emission” eller ”pension”, där medel uttryckligen läggs till eller tas bort.
- Tillstånd. Transaktionen måste godkännas av ägaren av varje utgång som konsumeras av dess ingångar. I en finansiell huvudbok hindrar detta deltagarna från att spendera varandras pengar utan tillstånd. Transaktionstillstånd hanteras med hjälp av asymmetrisk (eller offentlig-privat nyckel) kryptografi. Varje rad har en ägare, identifierad med en offentlig nyckel, vars motsvarande privata nyckel hålls hemlig. För att bli godkänd måste en transaktion undertecknas digitalt av ägaren till var och en av sina ingångar. (Observera att rader också kan ha mer komplexa "multisignatur" -ägare, till exempel där två av tre parter kan godkänna deras användning.)
- unika. Om en transaktion förbrukar en viss utgång kan ingen annan transaktion konsumera den utgången igen. Så förhindrar vi Alice från att göra motstridiga betalningar till både Bob och Charlie. Även om transaktionerna för båda dessa betalningar kan vara korrekta och godkända, garanterar unikhetsregeln att endast en kommer att behandlas av databasen.
I en konventionell blockchain kontrollerar varje nod varje transaktion i enlighet med dessa tre regler. Senare kommer vi att se hur Corda delar upp detta ansvar annorlunda.
Byggblock
En blockchain är bokstavligen en kedja av block, där varje block länkar till den föregående via en "hash" som unikt identifierar dess innehåll. Varje block innehåller en ordnad uppsättning transaktioner som inte får komma i konflikt med varandra eller med de i tidigare block, samt en tidsstämpel och annan information. Precis som transaktioner sprids block snabbt över nätverket och verifieras oberoende av varje nod. När en transaktion visas i ett block "bekräftas", vilket leder till noder för att avvisa alla motstridiga transaktioner.
Vem ansvarar för att skapa dessa block, och hur kan vi vara säkra på att alla noder kommer överens om den auktoritativa kedjan? Denna fråga om "konsensusalgoritmer" är ett enormt ämne i sig, fylld med underbara akronymer som PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance) och DPoS (Delegated Proof of Stake). Vi kommer inte att gå in på allt det här. Det räcker med att säga att tillåtna blockchains för företag använder någon form av omröstningssystem, där röster beviljas till "valideringsnoder" som är kollektivt ansvariga. Systemet säkerställer att så länge en god majoritet av valideringsnoder fungerar korrekt och ärligt kommer transaktioner att komma in i kedjan i en (nära) rättvis ordning, tidsstämplarna kommer att vara (ungefär) korrekta och bekräftade transaktioner kan inte därefter omvändas.
Innan jag diskuterar några av utmaningarna med blockchains, skulle jag vilja klargöra ytterligare tre punkter. Först, medan jag använder en finansiell bokbok som exempel i hela detta stycke, stöder input-output-modellen för transaktioner en mycket bredare variation av användningsfall. Varje rad kan innehålla ett rikt dataobjekt (tänk JSON) som innehåller många olika typer av information - Corda använder faktiskt ordet "tillstånd" snarare än "rad" av detta skäl. Rikare stater ändrar inget grundläggande i transaktionsregler: korrekthet definieras fortfarande i termer av ingångar och utgångar, behörighet krävs fortfarande för varje ingång, och unikhet säkerställer att varje utgång endast kan användas en gång.
För det andra finns det många blockchain-användningsfall där rader endast skapas i databasen och aldrig tas bort. Dessa applikationer avser generell datalagring, tidsstämpling och notarisering, snarare än att upprätthålla någon slags huvudbok som är i ström. I dessa applikationer med endast data lägger transaktioner till data i sina utgångar men konsumerar ingen i sina ingångar, vilket gör det möjligt att förenkla reglerna för korrekthet, auktorisering och unikhet. Även om ärenden som endast använder data är ett ökande fokus för vår egen utveckling på MultiChain, nämner jag dem bara när de passerar här, eftersom Corda helt klart inte var designad med dem i åtanke.
Slutligen är det värt att notera att vissa blockchain-plattformar inte använder en input-output-modell. Ethereum presenterar ett alternativt paradigm, där kedjan styr en virtuell dator med en global stat som hanteras av "kontrakt", och transaktioner kopplas inte exakt till varandra. En diskussion av Ethereums modell i tillåtna blockchains ligger utanför vårt räckvidd här, men se den här artikeln för en detaljerad förklaring och kritik. En viktig fördel med input-output-paradigmet är att de flesta transaktioner kan behandlas parallellt och oberoende av varandra. Den här egenskapen är avgörande för Corda, som vi får se senare.
Blockchain-utmaningar
Låt oss föreställa oss att världens banker skapade en delad huvudbok för att representera ägande, överföring och utbyte av olika finansiella tillgångar. I teorin kan detta implementeras på en vanlig blockchain, som beskrivits ovan. Varje rad skulle innehålla tre kolumner - en tillgångsidentifierare som GOOG eller USD, den kvantitet som ägs och ägarens offentliga nyckel. Varje transaktion skulle överföra en eller flera tillgångar från sina insatser till sina utgångar, med speciella fall för emission och pension.
Varje bank i nätverket skulle ha en eller flera noder som ansluter till de andra, sprider och verifierar transaktioner. Äldre medlemmar skulle agera som validerare med det kollektiva ansvaret för att bekräfta, beställa och stämpla transaktioner. Varje validerares missuppträdande skulle vara synlig för alla noder i nätverket, vilket skulle leda till censur, förvisning och / eller rättsliga förfaranden. Med allt detta på plats kan alla finansiella tillgångar flyttas över hela världen på några sekunder, med reglerna för korrekthet, auktorisation och unikhet som garanterar huvudbokens integritet.
Vad är fel med den här bilden? Det finns faktiskt tre problem: skalbarhet, konfidentialitet och interoperabilitet. Frågan om skalbarhet är tillräckligt enkel. Vår föreslagna interbank blockchain kräver att varje medlem ska verifiera, bearbeta och lagra varje transaktion som utförs av varje bank i världen. Även om detta skulle vara tekniskt genomförbart för de största finansiella institutionerna skulle kostnaderna för beräkning och lagring skapa en betydande hinder för många. Vi föredrar verkligen ett system där deltagarna bara ser de transaktioner där de omedelbart är involverade.
Men låt oss lägga skalbarhet åt sidan, eftersom det i slutändan kan lösas med dyra datorer och smart teknik. En mer grundläggande fråga är konfidentialitet. Även om det kan låta utopiskt för varje transaktion att vara synlig överallt, i den verkliga världen är sådan radikal öppenhet en icke-startare när det gäller konkurrens och reglering. Om JP Morgan och HSBC byter ut ett par tillgångar är det troligt att de inte vill att Citi och Bank of China ska se vad de gjorde. Om transaktionen genomfördes på uppdrag av dessa bankers kunder kan det vara olagligt för dem att avslöja den på detta sätt.
En föreslagen lösning på konfidentialitetsproblemet är "kanaler", som implementerats i Hyperledger Fabric. Varje kanal har vissa medlemmar som är en delmängd av noderna i nätverket som helhet. En kanals transaktioner är endast synliga för medlemmarna, så att varje kanal fungerar effektivt som en separat blockchain. Även om detta hjälper till med sekretess, undergräver det också hela punkten på övningen. Tillgångar kan inte flyttas från en kanal till en annan utan hjälp av en betrodd mellanhand som är aktiv på båda. Svårigheten med denna strategi framhölls nyligen av SWIFT: s försoning proof-of-concept, som uppskattade att över 100,000 100,000 kanaler skulle behövas i produktionen. Det är XNUMX XNUMX öar mellan vilka tillgångar inte kan flyttas direkt.
I fall som endast används för data, där transaktioner inte konsumerar data i ingångar, kan konfidentialitetsproblemet undvikas genom att kryptera eller hashsa data i utgångar, och leverera dekrypteringsnyckeln eller ostörda data utanför kedjan. Men för en transaktion vars ingångar konsumerar andra transaktionsutgångar måste varje nod se dessa ingångar och utgångar för att validera transaktionen. Medan avancerade kryptografiska tekniker som konfidentiella tillgångar och noll kunskap bevis har utvecklats för att helt eller delvis lösa detta problem för finansiella bokar, dessa medför en betydande resultatbörda och / eller kan inte generaliseras till någon korrekthetsregel.
Slutligen, låt oss prata om interoperabilitet. I en idealvärld skulle varje bank omedelbart gå med i vår globala blockchain samma dag som den lanserades. I verkligheten skulle dock flera blockchains antas av olika bankgrupper, baserat på geografi eller befintliga relationer. Med tiden kanske en medlem i en grupp vill börja handla med en medlem av en annan genom att överföra en tillgång mellan kedjor. Precis som med kanaler kan detta bara uppnås med hjälp av en pålitlig mellanhand och besegra blockchains syfte.
Corda syftar till att lösa dessa sammanhängande problem med skalbarhet, konfidentialitet och interoperabilitet genom en radikal omprövning av hur distribuerade bokar fungerar.
Cordas partiella vy
Den grundläggande skillnaden i Corda är lätt att förklara: Varje nod ser bara några, snarare än alla, av de transaktioner som behandlas i nätverket. Även om en enda logisk och konceptuell huvudbok definieras av alla dessa transaktioner, ser ingen enskild nod denna huvudbok i sin helhet. För att göra en jämförelse, när som helst, är varje dollarräkning i världen på en viss plats, men ingen vet var de alla är.
Så vilka transaktioner ser en Corda-nod? Först och främst de som det är direkt involverat i, eftersom det äger en av transaktionens ingångar eller utgångar. I en finansiell bokbok inkluderar detta alla transaktioner där en nod skickar eller tar emot medel. Låt oss säga att Alice skapar en transaktion som förbrukar henne $ 15 i en ingång och har två utgångar - en med $ 10 för mig, och den andra med $ 5 i "förändring" för henne. Efter att Alice skickat mig den här transaktionen kan jag kontrollera att den är korrekt och behörig, verifiera att ingångarna och utgångarna balanserar och att Alice har undertecknat.
Den här transaktionen räcker dock inte på egen hand. Jag måste också verifiera att Alice's $ 15-inmatningstillstånd verkligen finns, och att hon inte bara gjorde det. Det betyder att jag måste se transaktionen som skapade detta tillstånd och kontrollera att det också är korrekthet och godkännande. Om denna tidigare transaktion, som skickade Alice $ 15, har en $ 10-ingång som tillhör Denzel och ytterligare $ 5-ingång från Eric, måste jag också verifiera transaktionerna som skapade dessa. Och så fortsätter det, hela vägen tillbaka till den ursprungliga ”emission” -transaktionen där tillgången skapades. Antalet transaktioner som jag behöver verifiera beror på hur många gånger tillgångarna har bytt hand och omfattningen av bakåtförgrening.
Eftersom Corda-noder inte automatiskt ser varje transaktion, hur får de de de behöver? Svaret kommer från avsändaren av varje ny transaktion. Innan Alice skapar en transaktion som konsumerar 15 dollar måste hon redan ha verifierat transaktionen där hon fick den. Och eftersom Alice måste ha använt rekursiv teknik ovan kommer hon att ha en kopia av varje transaktion som behövs för denna verifiering. Bob begär helt enkelt dessa transaktioner från Alice som en del av deras interaktion. Om Alice inte svarar på rätt sätt, drar Bob slutsatsen att Alice försöker lura honom och avvisar den inkommande betalningen. I fallet där Bob skickas en ny transaktion vars ingångar har flera ägare kan han få erforderliga bevis från var och en.
Vi presenterar notarier
Hittills har vi förklarat hur Bob kan verifiera riktigheten och auktorisationen för en inkommande transaktion, inklusive rekursivt återskapa sina insatsers ursprung. Men det finns ytterligare en regel som vi måste tänka på: unikhet. Låt oss säga att Alice är skadlig. Hon kan generera en transaktion där hon betalar $ 10 till Bob, och en annan där hon betalar samma $ 10 till Charlie. Hon kan skicka dessa transaktioner till Bob respektive Charlie, tillsammans med ett fullständigt bevis på riktighet och godkännande av var och en. Medan båda transaktionerna strider mot varandra genom att konsumera samma tillstånd, finns det inget sätt för Bob och Charlie att veta detta.
Konventionella blockchains löser detta problem genom att varje nod ser varje transaktion, vilket gör konflikter lätt att upptäcka och avvisa. Så hur hanterar Corda, med dess partiella transaktionssynlighet, samma problem? Svaret är med hjälp av en ”notar”. Notarius är en betrodd part (eller parter som arbetar tillsammans) som garanterar att en viss stat endast konsumeras en gång. Varje stat har en specifik notarie som måste underteckna alla transaktioner där staten konsumeras. När en notarie har gjort detta får den inte underteckna en annan transaktion för samma tillstånd. Notarier är nätverkets vårdare för transaktionens unika.
Samtidigt som varje stat kan ha en annan notarie måste alla tillstånd som konsumeras av en viss transaktion tilldelas samma. På så sätt undviks problem som rör dödlås och synkronisering, vilket bör vara bekant för dem med distribuerad databasupplevelse. Låt oss säga att Alice och Bob går med på att byta Alice's $ 10 mot Bob's £ 7. Transaktionen för detta utbyte måste undertecknas av notarierna i båda staterna, men vilken kommer först? Om Alice's notary skyltar men Bob misslyckas av någon anledning, kommer Alice att sitta kvar med en ofullständig transaktion och kan aldrig använda sina $ 10 igen. Om Bobs tecken först är han på samma sätt exponerad. Även om vi kanske gillar att notarier bara ska arbeta tillsammans, kräver detta i praktiken ömsesidigt förtroende och användning av ett konsensusprotokoll, komplikationer som Cordas designers valde att undvika.
Om stater med olika notarier krävs som input till en enda transaktion, utför deras ägare först särskilda ”notary Change” -transaktioner, som flyttar en stat från en notarie till en annan, och ändrar ingenting annat. Så när parterna bygger en transaktion med flera ingångar, måste de först komma överens om notarius som ska användas, och sedan utföra de notarieändringar som krävs. Medan utvecklaren i mig kände en liten snäv av smärta när han läste om denna lösning, finns det ingen anledning till att det inte kommer att fungera så länge som notarier spelar med.
Det bör också klargöras att även om varje notarie är en enda logisk aktör när det gäller att underteckna transaktioner, behöver den inte vara under kontroll av en enda part. En grupp organisationer kan driva en notarie kollektivt med ett lämpligt konsensusprotokoll där en majoritet av deltagarna behövs för att generera en giltig signatur. Detta skulle förhindra varje enskilt skadligt parti från att undergräva unikhet genom att underteckna transaktioner som konflikter. I teorin kan vi till och med låta varje nod i nätverket delta i den här typen av delad notarisering, även om vi i så fall skulle vara mer eller mindre tillbaka till en konventionell blockchain.
Tar poäng
Låt oss sammanfatta de viktigaste skillnaderna mellan Corda och konventionella blockchains. I Corda finns det ingen enhetlig blockchain som innehåller alla bekräftade transaktioner. Noder ser bara de transaktioner som de är direkt involverade i eller som de beror historiskt på. Noder är ansvariga för att kontrollera transaktionens korrekthet och auktorisation men förlitar sig på betrodda notarier för att verifiera unikhet.
Naturligtvis finns det mycket mer för Corda än detta: användningen av digitala certifikat för att autentisera identitet, "nätverkskartor" för att hjälpa noder att hitta och lita på varandra, per-stat "kontrakt" som definierar riktigheten ur varje stats perspektiv, en deterministisk version av Java Virtual Machine som utför dessa kontrakt, "flöden" som automatiserar transaktionsförhandlingar, "tidsfönster" som begränsar transaktioner vid tid, "orakel" som vittnar om externa fakta och "CorDapps" som buntar många saker för enkel distribution . Medan var och en av dessa funktioner är intressanta, kan ekvivalenter för alla hittas i andra blockchain-plattformar. Mitt mål i den här artikeln är att fokusera på det som gör Corda unik.
Så uppfyller Corda sitt löfte? Löser det problem med skalbarhet, konfidentialitet och interoperabilitet för blockchains? Och när jag gör sina särskilda val, hur mycket av ett pris betalar Corda?
Ibland mer skalbar
Låt oss börja med skalbarhet. Här ser Cordas fördel uppenbar, eftersom noder bara ser några av transaktionerna i ett nätverk. I en vanlig blockchain begränsas den maximala genomströmningen av hastigheten för den långsammaste noden vid bearbetningstransaktioner. Däremot kan ett Corda-nätverk behandla en miljon transaktioner per sekund, medan varje nod bara ser en liten bråkdel av det. Skalbarheten sträcker sig också till notarier, eftersom uppgiften att underteckna transaktioner för unikhet kan spridas mellan många olika notarier, som var och en ansvarar för en liten del av nätverkets stater.
Med det sagt finns det en situation där Corda klarar sig mycket sämre än en blockchain. Detta inträffar när en nod får en ny transaktion som beror på många andra transaktioner som den inte har sett tidigare. Föreställ dig en mycket likvida tillgång som utfärdades för tio år sedan och byter händer ungefär var femte minut. Vägen från alla nya transaktioner tillbaka till tillgångens emission kommer att vara över en miljon transaktioner lång. När en nod tar emot denna tillgång för första gången måste den hämta dessa miljoner transaktioner från avsändaren och verifiera var och en i sin tur. Med en (ganska optimistisk) hastighet på 10 transaktioner per sekund skulle det vara 1000 minuters försening innan mottagaren kunde skicka tillgången vidare - helt klart för länge för något så flytande.
Varför lider blockchains inte av det här problemet? Eftersom noder ser och verifierar varje transaktion när den inträffar, uppdaterar de ständigt huvudboken och vet exakt vem som äger varje tillgång för närvarande. Även om en nod aldrig har haft en viss tillgång förut kan den omedelbart verifiera transaktionen som den tar emot den och sedan omedelbart skicka den vidare. För att uttrycka det på ett annat sätt måste blockchain-noder verifiera transaktioner som kanske inte är relevanta för dem, men på så sätt betalar de ut kostnaden för att kontrollera eventuella framtida transaktioner som kan komma in. Medan Corda-noderna är mindre upptagna totalt sett kör de risk för att behöva göra en enorm mängd arbete med ett ögonblick. Det är inget skalbart med det.
Lite mer konfidentiellt
Låt oss gå vidare till sekretess. I Corda ser noder bara några av nätverkets transaktioner, vilket onekligen betyder bättre integritet än konventionella blockchains. Trots det är Corda långt ifrån att lösa konfidentitetsproblemet, eftersom noder fortfarande ser några transaktioner som inte är deras verksamhet. För att ta ett enkelt exempel, om Alice betalar Bob $ 10, skickar Bob de 10 $ till Charlie, Charlies nod måste visas transaktionen mellan Alice och Bob, även om det inte involverar honom. Vid den tidpunkt då Alice betalade Bob, hade hon inget sätt att veta vem som kan se denna transaktion i framtiden, och någon kan skickas den när som helst.
För att vara rättvis är Cordas utvecklare medvetna om detta problem och diskuterar det i kapitel 15 i deras Teknisk vitbok. Uppsatsen föreslår enkla strategier som att använda flera offentliga nycklar per enhet eller minska spårbarheten genom att återlämna tillgångar till emittenter för återutgivning (liknande cryptocurrency "myntblandare"). Den nämner också mer avancerade framtidsmöjligheter som att använda Tor-liknande anonymiseringsnätverk för att dölja deltagarnas IP-adresser och utnyttja noll kunskapssäkerhet eller Intels säkra enklaver att validera transaktioner utan att avslöja innehållet. Samtidigt som alla dessa förslag är giltiga kan de också tillämpas på vanliga blockchains med hjälp av input-output-modellen, och de har faktiskt varit i cryptocurrencies som Dash, Zcash och Verge. Så Cordas enda unika fördel när det gäller konfidentialitet är fortfarande den minskade transaktionens synlighet - i bästa fall en ofullständig lösning.
Allt i aveln
För att bättre förstå Cordas skalbarhets- och sekretessfördel bör vi notera hur detta beror på densiteten och överlappningen i förhållandena mellan transaktioner. Föreställ dig ett "släktträd" av transaktionerna som utförs i ett nätverk, där varje transaktions föräldrar är de tidigare som det omedelbart beror på. När en transaktions utgång konsumeras av en annans input drar vi en pil som representerar förhållandet från förälder till barn. Transaktioner kan ha valfritt antal föräldrar och barn, även om vi i de flesta fall förväntar oss bara några få.
Med tanke på detta släktträd definierar vi förfäderna till en transaktion som dess föräldrar, morföräldrar, morföräldrar och så vidare. Vårt träd "Adam och Eva" är emissionstransaktioner som skapade tillgångar och har inga egna föräldrar. Liksom i vanliga släktträd kan två transaktioner inte vara förfäder till varandra. I formella datavetenskapliga termer är detta en riktad acyklisk graf eller DAG, där förfäder definieras som den övergående stängningen av förälderrelationen.
Kom ihåg att när en Corda-nod bearbetar en transaktion måste den ladda ner och verifiera alla transaktionens förfäder, förutom de som den har sett tidigare. Så om släktträdet är djupt kan nya inkommande transaktioner ha ett stort antal förfäder som måste verifieras, vilket utlöser Cordas skalbarhetsproblem. Dessutom, om släktträdet innehåller en hög grad av förädling, kan en ny transaktions förfäder inkludera många eller mest tidigare transaktioner i nätverket. I det här fallet kommer Corda att ge liten fördel när det gäller integritet.
Däremot, om transaktionens släktträd är grunt och innehåller många frånkopplade öar som inte interagerar med varandra, kommer Cordas fördelar fram. Noder kommer aldrig att behöva verifiera ett stort antal transaktioner på en gång och kan hållas i mörker om de flesta transaktioner som inte är relaterade till sina egna. Om det används som en finansiell huvudbok, kan vi säga att Corda är idealisk för mycket fragmenterade marknader vars tillgångar sällan byter hand.
Interoperabilitet för vinsten
Här är ett område där Corda verkligen lyser. Föreställ dig två separata Corda-nätverk, med olika uppsättningar tillgångar och deltagare. Vid någon tidpunkt vill en deltagare i ett nätverk skicka en tillgång till någon i det andra. Till skillnad från konventionella blockchains förväntas det inte att en nod har verifierat alla tidigare transaktioner, så noden som tar emot den här nya tillgången kommer inte att uppleva något ovanligt. När transaktionen kommer in begär och verifierar den helt enkelt den relevanta historiken, utan medvetenhet om att detta kommer från ett "separat nätverk". För att sträcka en kliché kan vi säga att det inte finns några främlingar i Corda - bara vänner som ännu inte träffat.
I verkligheten är saker inte så enkla. Varje Corda-nod bestämmer uttryckligen vilka notarier att lita på, eftersom en noter som inte fungerar kan orsaka ekonomisk förödelse. Dessutom behöver noder ett "certifikat" beviljat av en "dörrvakt" för att ansluta till andra noder i ett nätverk, eftersom vi inte kan tillåta slumpmässiga medlemmar att börja ansluta till noder och slösa bort sina resurser. Så innan en nod i ett nätverk kan börja begära och verifiera transaktioner från ett annat nätverk, måste den lägga till sin lista över betrodda notarer och få rätt certifikat. Även om detta innebär viss manuell konfiguration och administration, är det det minimum som kan förväntas för ett sådant system. Sammantaget är det rättvist att dra slutsatsen att interoperabilitet är Cordas stora vinst över konventionella blockchains.
Återförmedling
Det är dags att prata om disintermediation, elefanten i Cordas rum. I samband med blockchains betyder disintermediering att varje deltagare kan verifiera varje transaktion för sig själv, utan att bero på tredje parts goda beteenden. I min åsikt, disintermediering är den centrala fördelen med blockchains jämfört med centraliserade databaser, där alla deltagare är helt beroende av databasens ägare. Om deltagarna i ett nätverk har en mellanhand som de kan lita på, och det inte finns något affärs- eller lagstiftningsärende för disintermediering, så finns det ingen idé i att använda en blockchain. Centraliserade databaser är snabbare och effektivare och undviker frågan om transaktionssekretess.
Så uppnår deltagarna i ett Corda-nätverk disintermediering? Tja, ja, ja och ja men nej. För transaktionsleverans kryssar Corda i rutan, eftersom noderna som är involverade i en transaktion pratar direkt med varandra. När det gäller korrekthet och behörighet är den också i god form, eftersom varje nod kan kontrollera dessa egenskaper för sig själv. När det gäller verifiering av transaktionens unika misslyckas emellertid Corda meddelningstestet. Noder kan inte bekräfta unikhet för sig själva, eftersom de inte ser alla transaktioner i nätverket, och uppgiften läggs ut till betrodda notarer.
Deltagarna i Corda är berömda av notarier på flera sätt. Först kan en notarie vägra att underteckna en transaktion, även om dess ingångar konsumerar utgångar som aldrig har använts tidigare. I en finansiell huvudbok hindrar detta någon från att skicka eller byta ut sina tillgångar. För det andra kan en notarie underteckna två motstridiga transaktioner som konsumerar samma produktion, vilket leder till att två parter tror att de fick samma sak. Eftersom båda mottagarna av den duplicerade tillgången skickar eller utbyter den i ytterligare transaktioner kan spridningen smittas och hela huvudbokens integritet snart undergrävs. Slutligen kan en notarie vägra att underteckna en "notary Change" -transaktion för att överföra ett tillstånd till en konkurrent och effektivt hålla tillgångarnas gisslan. För en transaktion som involverar stater med olika notarier är det långt att säga att Corda introducerar mer förmedling än en centraliserad databas, eftersom flera tredje parter har kontroll.
För att sätta denna risk i perspektiv är det värt att erinra sig om att notarius från Corda inte behöver kontrolleras av en enda organisation. De kan också bestå av en grupp noder som har en konsensusalgoritm som kan tolerera dåliga aktörer. I detta fall kommer en notarie att fungera bra så länge de flesta av sina medlemsnoder följer reglerna. På ytan låter det snarare som en blockchain, som beror på att en majoritet av validatorerna beter sig. Men i Corda är riskerna betydligt högre. Det värsta en kabal blockchain-validerare kan göra är att förhindra att vissa transaktioner bekräftas. En skadlig Corda-notarie kan också underteckna motstridiga transaktioner och skicka boken till en inkonsekvent avgrund.
Ett konstigt djur
Att sätta skalbarhet, konfidentialitet, interoperabilitet och disintermediering tillsammans är det svårt att nå en enkel dom om Corda-alternativet. Sammantaget verkar det, från denna blockchain-plattformsutvecklare, väl ... tvingande men konstigt. Cordas lösningar är utformade för att lösa de viktigaste problemen med skalbarhet och konfidentialitet och är ofullständiga och beror i hög grad på transaktionens "släktträd". Men för att uppnå dessa partiella segrar förlorar Corda en kärnegenskap av blockchains - borttagandet av transaktionsförmedlare. Medan Corda utan tvekan utmärker sig för driftskompatibilitet, är det verkligen tillräckligt?
Om vi ville vara skeptiska, kan vi säga att Cordas team var en omöjlig uppgift - att utforma en smak av blockchain som skulle passa bankerna som finansierar R3. Men den viktigaste fördelen med blockchains över centraliserade databaser är disintermediering, vilket kommer till priset av reducerad sekretess. Hur kan denna avvägning vara vettig för finansinstitut som tjänar pengar genom att agera som mellanhänder och är mycket känsliga för privatlivet? Sett i detta ljus kan man rensa Corda som en heroisk men i slutändan otillfredsställande kompromiss mellan R3: s medlemmars önskan att göra något blockchainy, och de kommersiella och reglerande begränsningar som de existerar under.
Förvaringsinstitut 2.0
Men jag föredrar att anta en mer positiv inställning. Istället för att fokusera på jämförelsen med blockchains kan vi se Corda som en viktig teknisk uppgradering till den finansiella status quo. Byt helt enkelt ut ordet "notarius" med "depå", och allt faller på plats ganska snyggt. (A väktare är ett finansiellt institut som innehar tillgångar för andras räkning.) Ja, notarier är förmedlare, som både kan blockera transaktioner och låta konflikter inträffa, men det gäller även dagens vårdnadshavare. En ”notary Change Transaction” kan ses som överföring av tillgångar från en depå till en annan. Och Corda-transaktioner undertecknas av bara en notarie av samma anledning som vi gillar att tillgångsutbyten sker på ett ställe - för att förhindra att någon av parterna blir ur fickan.
Om vi ser på Corda på detta sätt kan vi se hur det förbättras med den traditionella förvaringsmodellen:
- Den definierar ett standardberäkningsparadigm och ett format för att uttrycka finansiella tillgångar och andra avtalsenliga åtaganden.
- Den tillhandahåller programvara med öppen källkod för att tolka och fullfölja dessa åtaganden, vilket garanterar att transaktionsparter och vårdnadshavare är överens om resultatet av varje transaktion.
- Komplexa depåförvarare som skyddar mot missbruk kan skapas (endast med programvara!) Genom att utnyttja feltoleranta konsensusalgoritmer.
- En standardprocess (”notary ändring”) definieras för överföring av tillgångar mellan vårdnadshavare, och ingen vårdnadshavare får vägra.
- Förvaringsinstitut kan inte använda en tillgång under deras förvaring utan ägarens samtycke, eftersom transaktioner också måste undertecknas av deras insatsägare.
Jag är långt ifrån bankman, men för mig låter allt ganska lovande. Och kanske Corda lika väl kan tillämpas på andra industrier med komplexa depåstrukturer, såsom försäkring eller frakt. Även om Cordas design kanske inte ger full blockering av blockchain, föreslår den en kraftfull omvandling för industrier där mellanhänder spelar en viktig roll.
När vi väl har tappat denna tankegång uppstår oundvikligen en fråga: Om vi redan litar på notarier med livet och dödsjobbet att verifiera unikhet, varför inte lita på dem för korrekthet och auktorisation också? Corda har redan idén om en "validerande notarie", som fullständigt verifierar transaktioner innan du lägger till sin signatur. Istället för att vanliga Corda-noder laddar ner och kontrollerar sina transaktioner förfäder, varför inte bara fråga en notarie istället? Detta kan hjälpa till med skalbarhet och konfidentialitet, eftersom de flesta noder inte ser några andra transaktioner än sina egna. Vi kan till och med föreslå att ett nätverkets notarer helt litar på varandra, så det finns ingen anledning att oroa sig för förfäder. Varje stats notarius kunde garantera sin giltighet och kontrollera endast transaktionen som skapade den med andra notarier.
Låt Corda vara Corda
Allt detta tar oss tillbaka där vi började: Corda är inte en konkurrent för konventionella blockchains, inklusive MultiChain. Corda är Corda - en intressant ny typ av distribuerad huvudbok, som har optimerats för behoven hos dem som finansierar den. Jag har ingen aning om Corda i slutändan kommer att lyckas eller misslyckas, för jag känner inte till dess verkliga kostnader och fördelar jämfört med det nuvarande sättet att göra saker. Men oavsett vad som händer i framtiden, är det verkligen värt att studera när det gäller filosofi och design.
När det gäller MultiChain tar vi ett annat tillvägagångssätt. Att stjäla en linje från The West Wing, vi är fast beslutna att "låta blockchain vara blockchain". Blockchains är vad de är, och vi har inga planer på att förvandla dem till något annat. Som datainfrastruktur för en delad applikation representerar en blockchain en specifik avvägning jämfört med en centraliserad databas - en vinst i disintermediering till bekostnad av minskad sekretess. Och vi arbetar hårt för att göra MultiChain 2.0 så bra som möjligt blockchain plattform för applikationsutvecklare att använda.
Skicka eventuella kommentarer på Link.
Källa: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/
- Konto
- Förkortningar
- aktiv
- Annat
- Fördel
- algoritm
- algoritmer
- Ansökan
- tillämpningar
- arkitektur
- OMRÅDE
- Artikeln
- tillgång
- Tillgångar
- publik
- tillstånd
- Bank
- Kinesiska banken
- Banking
- Banker
- BÄST
- Bill
- blockchain
- Box
- Byggnad
- Bunt
- företag
- fall
- Orsak
- VD
- certifikat
- certifikat
- byta
- kanaler
- kontroll
- Kontroller
- barn
- Barn
- Kina
- Citi
- förslutning
- kommentarer
- kommersiella
- Gemensam
- företag
- konkurrens
- konkurrenter
- Datavetenskap
- datorer
- konflikt
- Konsensus
- samtycke
- konsumera
- innehåll
- innehåll
- kontrakt
- Corda
- Kostar
- Skapa
- kryssning
- cryptocurrencies
- kryptovaluta
- kryptografi
- Aktuella
- Vårdnad
- Kunder
- DAG
- Dash
- datum
- datalagring
- Databas
- databaser
- dag
- behandla
- fördröja
- leverera
- leverans
- Designa
- Utvecklare
- utvecklare
- Utveckling
- DID
- digital
- Distribuerad Ledger
- Dollar
- elefant
- Teknik
- Företag
- ethereum
- utbyta
- Utbyten
- Motionera
- tyg
- verkligt
- familj
- Mode
- Funktioner
- Slutligen
- finansiella
- Finansiella institut
- änden
- Förnamn
- första gången
- Fokus
- format
- full
- finansiering
- fonder
- framtida
- Allmänt
- Välgörenhet
- global blockchain
- god
- styrning
- stor
- Grupp
- Odling
- här.
- Dölja
- Hög
- Markerad
- historia
- Hur ser din drömresa ut
- HTTPS
- stor
- Tanken
- Identitet
- Olaglig
- Inklusive
- industrier
- informationen
- Infrastruktur
- Institution
- institutioner
- försäkring
- interaktion
- intresse
- Interoperabilitet
- involverade
- IP
- emission
- problem
- IT
- java
- Jobb
- delta
- Nyckel
- nycklar
- kunskap
- Large
- leda
- Ledarskap
- ledande
- lärt
- Ledger
- Adress
- Nivå
- ljus
- linje
- Flytande
- Lista
- Lång
- större
- Majoritet
- Framställning
- marknad
- Marknader
- Match
- möten
- Medlemmar
- nämner
- miljon
- modell
- pengar
- flytta
- multikedja
- nät
- nätverk
- nätverk
- noder
- Begrepp
- öppet
- öppen källkod
- beställa
- ordrar
- Övriga
- Övrigt
- ägaren
- ägare
- Smärta
- Papper
- paradigmet
- föräldrar
- Betala
- betalning
- betalningar
- Personer
- prestanda
- perspektiv
- Filosofin
- Bild
- plattform
- Plattformar
- Populära
- presentera
- pris
- privatpolicy
- privat
- Produkt
- Produktion
- bevis
- egenskapen
- skydda
- allmän
- R3
- läsare
- Läsning
- Verkligheten
- resumé
- register
- reglering
- Förhållanden
- lindring
- Krav
- Resurser
- pension
- översyn
- Risk
- regler
- Körning
- rinnande
- skalbarhet
- Vetenskap
- HAV
- ser
- känsla
- in
- delas
- Frakt & Leverans
- Kort
- Tecken
- Enkelt
- Small
- So
- Mjukvara
- Lösningar
- LÖSA
- fart
- Spendera
- spridning
- spel
- starta
- igång
- Ange
- Stater
- status
- förvaring
- lagra
- lagrar
- Stöder
- yta
- system
- Teknisk
- testa
- Framtiden
- Tänkande
- utomstående
- tid
- tolerans
- Spårbarhet
- transaktion
- Transaktioner
- Transformation
- Öppenhet
- transport
- Litar
- Oskadd
- us
- USD
- användare
- kanten
- Verifiering
- utsikt
- Virtuell
- virtuell maskin
- synlighet
- Röstning
- vänta
- väster
- VEM
- wikipedia
- vinna
- Arbete
- världen
- värt
- skrivning
- år
- Zcash
- noll-