Fyra äkta blockchain-fall

Där delade huvudböcker tillför verkligt värde i företagets IT

Nästan ett år efter första släppet MultiKedja, vi har lärt oss en hel del om hur blockkedjor, i privat bemärkelse och inte är kryptovaluta, kan och inte kan tillämpas på verkliga problem. Låt mig berätta vad vi hittills vet.

Till att börja med verkar den första tanken som vi (och många andra) började med vara fel. Denna idé, inspirerad av bitcoin direkt, var att privata blockchains (eller "delade huvudböcker") kunde användas för att direkt avveckla majoriteten av betalnings- och växlingstransaktioner i finanssektorn med hjälp av on-chain tokens för att representera kontanter, aktier, obligationer och Mer.

Detta fungerar perfekt på teknisk nivå, så vad är problemet? I ett ord, konfidentialitet. Om flera institutioner använder en delad huvudbok, ser alla institutioner varje transaktion på den huvudboken, även om de inte omedelbart känner till de berörda parternas verkliga identiteter. Detta visar sig vara en stor fråga, både när det gäller reglering och den kommersiella verkligheten i konkurrens mellan banker. Medan olika strategier är tillgängliga eller under utveckling för att mildra detta problem, kan ingen matcha enkelheten och effektiviteten hos en centraliserad databas som hanteras av en betrodd mellanhand, som upprätthåller full kontroll över vem som kan se vad. För närvarande verkar det åtminstone som stora finansinstitut föredrar att hålla de flesta transaktioner dolda i dessa mellanliggande databaser, trots kostnaderna.

Jag bygger denna slutsats inte bara på vår egen erfarenhet utan också på riktningen från flera framstående startups vars ursprungliga mål var att utveckla delade huvudböcker för banker. Till exempel arbetar både R3CEV och Digital Asset nu med "språk för språkbeskrivning", i Corda och DAML respektive (tidigare exempel inkluderar MLFi och Ricardian-avtal). Dessa språk gör det möjligt för villkoren för ett komplext finansiellt avtal att representeras formellt och otvetydigt i ett datorläsbart format, samtidigt som man undviker brister av beräkningar för allmänt ändamål i Ethereum-stil. Istället spelar blockkedjan bara en stödjande roll, lagrar eller notariserar kontrakten i krypterad form och utför någon grundläggande duplikatdetektion. Det faktiska genomförandet av kontraktet sker inte på blockchain utan snarare utförs det endast av kontraktets motparter, med sannolikt tillägg av revisorer och tillsynsmyndigheter.

På kort sikt är detta förmodligen det bästa som kan göras, men var lämnar det de bredare ambitionerna för tillåtna blockkedjor? Finns det andra applikationer som de kan utgöra en viktigare del av pusslet för?

Denna fråga kan tas upp både teoretiskt och empiriskt. Teoretiskt genom att fokusera på de viktigaste skillnaderna mellan blockkedjor och traditionella databaser, och hur dessa informerar uppsättningen av möjliga användningsfall. Och i vårt fall, empiriskt, genom att kategorisera de verkliga lösningarna som bygger på MultiChain idag. Inte överraskande, oavsett om vi fokuserar på teori eller praktik, uppstår samma klasser av användningsfall:

• Lätta finansiella system.
• Spårning av ursprung.
• Interorganisatoriskt registerföring.
• Flerpartsaggregering.

Innan vi förklarar dessa i detalj, låt oss sammanfatta teorin. Som jag har gjort diskuterade tidigare, de två viktigaste skillnaderna mellan blockkedjor och centraliserade databaser kan karakteriseras enligt följande:

1. disintermediering. Blockchains gör det möjligt för flera parter som inte helt litar på varandra att säkert och direkt dela en enda databas utan att kräva en betrodd mellanhand.
2. Sekretess: Alla deltagare i en blockchain ser alla transaktioner som äger rum. (Även om vi använder pseudonyma adresser och avancerad kryptografi för att dölja vissa aspekter av dessa transaktioner kommer en blockchain alltid att läcka ut mer information än en central databas.)

Med andra ord är blockkedjor perfekta för delade databaser där varje användare har möjlighet att läsa allt, men ingen enskild användare styr vem som kan skriva Vad. Däremot, i traditionella databaser, utövar en enda enhet kontroll över alla läs- och skrivoperationer, medan andra användare är helt föremål för den enhetens nycklar. För att sammanfatta det i en mening:

Blockchains representerar en avvägning där distinternation uppnås på bekostnad av konfidentialitet.

När vi undersöker de fyra typerna av användningsfall nedan kommer vi upprepade gånger tillbaka till denna grundavvägning och förklarar varför i varje fall fördelarna med disintermediation uppväger kostnaden för minskad konfidentialitet.

Lätta finansiella system

Låt oss börja med den klass av blockchain-applikationer som är mest bekanta, där en grupp enheter vill inrätta ett finansiellt system. Inom detta system överförs en eller flera knappa tillgångar och utbyts mellan dessa enheter.

För att vilken som helst om tillgången förblir knapp, måste två relaterade problem lösas. Först måste vi se till att samma enhet av tillgången inte kan skickas till mer än ett ställe (en "dubbel utgift"). För det andra måste det vara omöjligt för någon att skapa nya enheter av tillgången på ett infall ("förfalskning"). Varje enhet som kan göra någon av dessa saker kan stjäla obegränsat värde från systemet.

En vanlig lösning på dessa problem är fysiska tokens, såsom metallmynt eller säkert tryckt papper. Dessa tokens löser trivialt problemet med dubbla utgifter, eftersom fysikens regler (bokstavligen) förhindrar att en token befinner sig på två platser samtidigt. Problemet med förfalskning löses genom att göra token extremt svår att tillverka. Ändå lider fysiska tokens av flera brister som kan göra dem opraktiska:

• Som rena bärartillgångar kan fysiska tokens stulas utan spår eller användning.
• De är långsamma och kostsamma att flytta i stort antal eller över långa sträckor.
• Det är knepigt och dyrt att skapa fysiska tokens som inte kan förfalskas.

Dessa brister kan undvikas genom att lämna fysiska tokens och omdefiniera tillgångsägande i termer av en huvudbok som hanteras av en betrodd mellanhand. Tidigare baserades dessa huvudböcker på pappersregister, och idag tenderar de att köras på vanliga databaser. Hur som helst antar förmedlaren en överföring av äganderätt genom att ändra huvudbokens innehåll som svar på en autentiserad begäran. Till skillnad från avveckling med fysiska tokens kan tvivelaktiga transaktioner snabbt och enkelt återföras.

Så vad är problemet med ledgers? I ett nötskal, koncentration av kontroll. Genom att sätta så mycket kraft på ett ställe skapar vi en betydande säkerhetsutmaning, både tekniskt och mänskligt. Om någon extern kan hacka in i databasen kan de byta bokbok efter eget val, stjäla andras medel eller förstöra innehållet helt. Ännu värre, någon på insidan kan korrumpera huvudboken, och denna typ av attack är svår att upptäcka eller bevisa. Som ett resultat måste vi investera betydande tid och pengar i mekanismer för att upprätthålla den finansiella integriteten, oavsett var vi har en centraliserad storbok. Och i många fall kräver vi fortlöpande verifiering med hjälp av batchbaserad avstämning mellan huvudboken och de av alla transaktionsparter.

Ange blockchain (eller "delad huvudbok"). Detta ger fördelarna med storböcker utan att lida av koncentrationsproblemet. Istället kör varje enhet en “nod” som innehåller en kopia av huvudboken och upprätthåller full kontroll över sina egna tillgångar, som skyddas av privata nycklar. Transaktioner sprids mellan noder på ett peer-to-peer-sätt, med blockchain som säkerställer att konsensus upprätthålls. Denna arkitektur lämnar ingen central attackpunkt genom vilken en hackare eller insider kan förstöra storbokens innehåll. Som ett resultat kan ett digitalt finansiellt system implementeras snabbare och billigare, med den extra fördelen med automatisk avstämning i realtid.

Så vad är nackdelen? Som diskuterats tidigare ser alla deltagare i en delad huvudbok alla transaktioner som görs, vilket gör den oanvändbar i situationer där konfidentialitet krävs. Istället är blockchains lämpliga för vad jag kallar lättvikt finansiella system, nämligen de där den ekonomiska insatsen eller antalet deltagare är relativt lågt. I dessa fall tenderar konfidentialitet att vara mindre problem - även om deltagarna ägnar stor uppmärksamhet åt vad varandra gör kommer de inte att lära sig mycket av värde. Och det är exakt därför att insatserna är låga för att vi föredrar att undvika besväret och kostnaden för att skapa en mellanhand.

Några uppenbara exempel på lätta finansiella system inkluderar: crowdfunding, presentkort, lojalitetspoäng och lokala valutor - särskilt i fall där tillgångar kan lösas in på mer än ett ställe. Men vi ser också användningsfall i den vanliga finanssektorn, till exempel peer-to-peer-handel mellan kapitalförvaltare som inte är i direkt konkurrens. Blockchains testas även som inre redovisningssystem, i stora organisationer där varje avdelning eller plats måste ha kontroll över sina medel. I alla dessa fall ger den lägre kostnaden och friktionen av blockkedjor en omedelbar fördel, medan förlusten av konfidentialitet inte är ett problem.

Spårning av ursprung

Här är en andra klass av användningsfall som vi upprepade gånger hör från MultiChains användare: spårar ursprung och rörelse för högvärdiga artiklar över en leveranskedja, såsom lyxvaror, läkemedel, kosmetika och elektronik. Och på samma sätt kritiska dokumentation som lastbiljetter eller kreditkort. I försörjningskedjor som sträcker sig över tid och avstånd lider alla dessa föremål av förfalskning och stöld.

Problemet kan hanteras med hjälp av blockkedjor på följande sätt: när det högvärdiga objektet skapas, utfärdas en motsvarande digital token av en betrodd enhet, som agerar för att autentisera sin utgångspunkt. Varje gång det fysiska objektet byter händer flyttas den digitala token parallellt så att den verkliga vårdkedjan exakt speglas av en kedja av transaktioner på blockchain.

Om du vill fungerar token som ett virtuellt "äkthetsintyg", vilket är mycket svårare att stjäla eller smida än ett papper. Efter mottagandet av den digitala token kan den slutliga mottagaren av den fysiska artikeln, oavsett om en bank, distributör, återförsäljare eller kund, verifiera vårdkedjan hela vägen tillbaka till ursprungsorten. I själva verket, i fallet med dokumentation som konossement, kan vi helt ta bort det fysiska föremålet.

Även om allt detta är vettigt kommer den kloka läsaren att märka att en vanlig databas, som hanteras (säg) av tillverkaren av ett objekt, kan utföra samma uppgift. Denna databas lagrar ett register över den aktuella ägaren av varje artikel, accepterar signerade transaktioner som representerar varje ägarbyte och svarar på inkommande förfrågningar angående det aktuella läget.

Så varför använda en blockchain istället? Svaret är att för den här typen av applikationer finns det en fördel med distribuerat förtroende. Oavsett var en central databas finns, kommer det att finnas människor på den platsen som har förmågan (och kan mutas) att skada dess innehåll och markera förfalskade eller stulna föremål som legitima. Däremot, om härkomst spåras på en blockchain som tillhör kollektivt deltagarna i en försörjningskedja, kan ingen enskild enhet eller liten grupp av enheter förstöra vårdnadskedjan, och slutanvändare kan ha större förtroende för svaren de får. Som en bonus kan olika polletter (säg för vissa varor och motsvarande fraktbrev) säkert och direkt bytas ut med en tvåvägsbyte garanterat på lägsta blockchain-nivå.

Vad sägs om sekretessproblemet? Blockchains lämplighet för leveranskedjans härkomst är ett lyckligt resultat av applikationens enkla transaktionsmönster. Till skillnad från finansiella marknadsplatser rör sig de flesta symboler i en enda riktning, från ursprung till slutpunkt, utan att upprepade gånger handlas fram och tillbaka mellan blockkedjans deltagare. Om konkurrenter sällan handlar med varandra (t.ex. leksakstillverkare till leksakstillverkare eller återförsäljare till återförsäljare), kan de inte lära sig varandras blockchain-adresser och koppla dem till verkliga identiteter. Dessutom kan aktiviteten enkelt delas upp i flera huvudböcker, var och en representerar en annan ordning eller typ av varor.

Interorganisatoriskt registerföring

Båda de tidigare användningsfallen är baserade på tokeniserade tillgångar, dvs representationer i kedjan av ett värde som överförs mellan deltagarna. Det finns dock en andra grupp blockchain-användningsfall som inte är relaterade till tillgångar. Istället fungerar kedjan som en mekanism för kollektiv inspelning och notering vilken som helst typ av data vars betydelse kan vara ekonomisk eller på annat sätt.

Ett sådant exempel är ett granskningsspår av kritisk kommunikation mellan två eller flera organisationer, exempelvis inom hälso- och sjukvården. Ingen enskild organisation i gruppen kan lita på att underhålla detta arkiv med register, eftersom förfalskad eller raderad information skulle skada de andra betydligt. Ändå är det viktigt att alla är överens om arkivets innehåll för att förhindra tvister.

För att lösa detta problem behöver vi en delad databas där alla poster är skrivna, med varje post åtföljd av en tidsstämpel och ursprungsbevis. Standardlösningen skulle vara att skapa en pålitlig mellanhand, vars roll är att samla in och lagra posterna centralt. Men blockchains erbjuder ett annat tillvägagångssätt, vilket ger organisationerna ett sätt att gemensamt hantera detta arkiv, samtidigt som enskilda deltagare (eller små grupper därav) förhindras från att skada det.

Ett av de mest upplysande konversationerna jag haft de senaste två åren var med Michael Mainelli of Z / Yen. I 20 år har hans företag byggt system där flera enheter gemensamt hanterar ett gemensamt digitalt granskningsspår med tidsstämpling, digitala signaturer och ett round robin-konsensusprogram. När han förklarade de tekniska detaljerna i dessa system blev det klart att de är tillåtna blockkedjor i alla avseenden. Med andra ord finns det inget nytt med att använda en blockchain för interorganisatorisk rekordhantering - det är bara att världen äntligen har blivit medveten om möjligheten.

När det gäller den faktiska informationen som lagras i blockchain finns det tre populära alternativ:

• Okrypterad data. Detta kan läsas av alla deltagare i blockchain, vilket ger full kollektiv öppenhet och omedelbar lösning vid en tvist.
• Krypterad data. Detta kan endast läsas av deltagare med lämplig dekrypteringsnyckel. I händelse av en tvist kan vem som helst avslöja den här nyckeln till en betrodd myndighet som en domstol och använda blockchain för att bevisa att originaldata lades till av en viss part vid en viss tidpunkt.
• Hashade data. En “hash”Fungerar som ett kompakt digitalt fingeravtryck, vilket representerar ett åtagande om en viss datadel samtidigt som den håller informationen gömd. Med viss information kan alla parter enkelt bekräfta om de matchar en viss hash, men avläser data från dess hash är beräkningsmässigt omöjligt. Endast hashen placeras på blockkedjan, med originaldata lagrade off-chain av intresserade parter, som kan avslöja det i händelse av en tvist.

Som nämnts tidigare har R3CEVs Corda-produkt antagit detta tredje tillvägagångssätt, lagra hash på en blockchain för att notera avtal mellan motparter utan att avslöja deras innehåll. Denna metod kan användas både för datorläsbara kontraktsbeskrivningar, liksom PDF-filer som innehåller pappersdokumentation.

Naturligtvis är konfidentialitet inte ett problem för interorganisatorisk journalföring, eftersom hela syftet är att skapa ett delat arkiv som alla deltagare kan se (även om vissa data är krypterade eller hashade). I vissa fall kan en blockchain hjälpa till att hantera åtkomst till konfidentiell data utanför kedjan genom att tillhandahålla en oföränderlig post av digitalt signerade åtkomstförfrågningar. Hursomhelst är den enkla fördelen med disintermediation att ingen ytterligare enhet måste skapas och litas för att behålla denna post.

Flerpartsaggregering

Tekniskt sett liknar den här sista användningsfallet den tidigare, genom att flera parter skriver data till en kollektivt hanterad post. Men i detta fall är motivationen annorlunda - att övervinna den infrastrukturella svårigheten att kombinera information från ett stort antal separata källor.

Föreställ dig två banker med interna databaser med kundidentitetsverifiering. Vid någon tidpunkt märker de att de delar många kunder, så de går in i ett ömsesidigt delningsarrangemang där de utbyter verifieringsdata för att undvika duplicerat arbete. Tekniskt sett är avtalet implementerat enligt standard replikering av master-slavdata, där varje bank har en skrivskyddad kopia av den andras databas och kör frågor parallellt mot sin egen databas och repliken. Än så länge är allt bra.

Föreställ dig att dessa två banker bjuder in tre andra att delta i denna delningskrets. Var och en av de 5 bankerna driver sin egen huvuddatabas, tillsammans med 4 skrivskyddade repliker av de andra. Med 5 mästare och 20 repliker har vi totalt 25 databasinstanser. Även om det är genomförbart tar det tid och resurser i varje banks IT-avdelning.

Snabbspola fram till den punkt där 20 banker delar information på detta sätt, och vi tittar på totalt 400 databasinstanser. För 100 banker når vi 10,000 XNUMX instanser. I allmänhet, om varje part delar information med varandra, växer det totala antalet databasinstanser med kvadratet av antalet deltagare. Vid någon tidpunkt i denna process kommer systemet att gå sönder.

Så vad är lösningen? Ett uppenbart alternativ är att alla banker skickar sina uppgifter till en betrodd mellanhand, vars uppgift är att samla dessa data i en enda huvuddatabas. Varje bank kunde sedan fråga den här databasen på distans eller köra en lokal skrivskyddad replika inom sina egna fyra väggar. Även om det inte är något fel med detta tillvägagångssätt, erbjuder blockchains ett billigare alternativ där den delade databasen drivs direkt av de banker som använder den. Blockchains ger också den extra fördelen med redundans och failover för systemet som helhet.

Det är viktigt att klargöra att en blockchain inte fungerar som en distribuerad databas som Cassandra or Tänk om på DB. Till skillnad från dessa system tillämpar varje blockchain-nod en uppsättning regler som hindrar en deltagare från att modifiera eller radera data som läggs till av en annan. Faktum är att det fortfarande verkar finnas en viss förvirring om detta - en nyligen släppt blockchain-plattform kan brytas av en enda felaktig nod. I vilket fall som helst kommer en bra plattform också att göra det enkelt att hantera nätverk med tusentals noder, gå med och lämna efter eget val, om de får rätt behörighet.

Även om jag är lite skeptisk till den ofta citerade kopplingen mellan blockchains och Sakernas InternetJag tror att det här kan vara där en stark sådan synergi ligger. Naturligtvis skulle varje "sak" vara för liten för att lagra en fullständig kopia av blockkedjan lokalt. Snarare skulle det överföra databärande transaktioner till ett distribuerat nätverk av blockchain-noder, som skulle samla allt för ytterligare hämtning och analys.

Slutsats: Blockchains in Finance

Jag började den här biten med att ifrågasätta det ursprungliga användningsfallet för blockchains inom finanssektorn, nämligen bulkavvecklingen av betalnings- och växlingstransaktioner. Medan jag tror att denna slutsats blir vanlig visdom (med en anmärkningsvärt undantag), betyder det inte att blockchains inte har några andra applikationer i denna bransch. Faktum är att för var och en av de fyra användarklasserna som beskrivs ovan ser vi tydliga tillämpningar för banker och andra finansinstitut. Respektivt är dessa: små handelscirklar, härkomst för handelsfinansiering, bilateral kontraktsnotering och aggregering av AML / KYC-data.

Nyckeln till att förstå är att våra fyra användningsfall inte är arkitektoniskt sett specifik för att finansiera och är lika relevanta för andra sektorer som försäkring, vård, distribution, tillverkning och IT. I själva verket bör privata blockchains övervägas för alla situationer där två eller flera organisationer behöver en gemensam syn på verkligheten, och den uppfattningen kommer inte från en enda källa. I dessa fall erbjuder blockchains ett alternativ till behovet av en betrodd mellanhand, vilket leder till betydande besparingar i krångel och kostnad.

Skicka eventuella kommentarer på Link.

Källa: https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/