Het zinloze blockchain-project vermijden

Hoe u kunt bepalen of u een echte blockchain-use case heeft gevonden

Blockchains zijn overhyped. Daar zei ik het. Van SIBOS naar moneyxnumx / 20 om verhalen van te behandelen The Economist en Euromoneylijkt iedereen aan boord van de blockchain-wagen te klimmen. En ongetwijfeld zien we, net als anderen in de ruimte, een snel toenemend aantal bedrijven die proofs of concept bouwen ons platform en / of om onze hulp te vragen.

Als jonge startup zou je denken dat we in de wolken zouden zijn. Nu is het zeker tijd om een ​​hoop geld in te zamelen en dat hoogwaardige blockchain-platform van de volgende generatie te bouwen dat we al hebben ontworpen. Waar wachten we in vredesnaam op?

Ik zal je wat vertellen. We wachten op een beter begrip van waar blockchains echt waarde toevoegen in enterprise IT. U ziet, een groot deel van deze inkomende projecten heeft helemaal niets met blockchains te maken. Hier is hoe het zich afspeelt. Een groot bedrijf hoort dat blockchains de next big thing zijn. Big company vindt intern een aantal mensen die geïnteresseerd zijn in het onderwerp. Een groot bedrijf geeft ze een budget en zegt dat ze iets blockchainy moeten gaan doen. Al snel komen ze bij ons aan de deur, zwaaiend met dollarbiljetten, vragend us om aan hen bedenk een use case. Zeg wat nu?

Wat is het probleem voor degenen die wel een project in gedachten hebben? In veel gevallen kan het project perfect worden uitgevoerd met behulp van een reguliere relationele database. Weet je, grote ijzeren kolossen houden van Oracle en SQL Server, of voor de meer ruimdenkende mensen, MySQL en postgres. Dus laat ik beginnen met de zaken recht te zetten:

Als aan uw vereisten wordt voldaan door de huidige relationele databases, zou u gek zijn om een ​​blockchain te gebruiken.

Waarom? Omdat producten zoals Oracle en MySQL decennia van ontwikkeling achter de rug hebben. Ze zijn geïmplementeerd op miljoenen servers met triljoenen zoekopdrachten. Ze bevatten een aantal van de meest grondig geteste, debugged en geoptimaliseerde code ter wereld en verwerken duizenden transacties per seconde zonder zweten.

En hoe zit het met blockchains? Goed, ons product was een van de eersten die op de markt kwam en is nu precies 5 maanden beschikbaar, met een paar duizend downloads. Eigenlijk is het extreem stabiel, omdat we het hebben opgebouwd Bitcoin Core, de software die bitcoin aandrijft. Maar toch, deze hele productcategorie zit nog in de luiers.

Dus zeg ik dat blockchains nutteloos zijn? Absoluut niet. Maar voordat je aan dat glanzende blockchain-project begint, moet je een heel duidelijk idee hebben van waarom je een blockchain gebruikt. Er zijn een aantal voorwaarden waaraan moet worden voldaan. En als ze dat niet zijn, ga dan terug naar de tekentafel. Misschien kunt u het project beter definiëren. Of misschien kun je iedereen een hoop tijd en geld besparen, omdat je helemaal geen blockchain nodig hebt.

1. De database

Hier is de eerste regel. Blockchains zijn een technologie voor gedeelde databases. U moet dus beginnen met te weten waarom u een database gebruikt, waarmee ik bedoel een gestructureerde opslagplaats van informatie. Dit kan een traditioneel zijn relationele database, die een of meer spreadsheetachtige tabellen bevat. Of het kan de meest trendy zijn NoSQL variëteit, die meer werkt als een bestandssysteem of woordenboek. (Op theoretisch niveau zijn NoSQL-databases sowieso slechts een subset van relationele databases.)

Een grootboek voor financiële activa kan natuurlijk worden uitgedrukt als een databasetabel waarin elke rij een activatype vertegenwoordigt dat eigendom is van een bepaalde entiteit. Elke rij heeft drie kolommen met daarin: (a) de identificatie van de eigenaar, zoals een rekeningnummer, (b) een identificatie voor het activatype, zoals 'USD' of 'AAPL', en (c) de hoeveelheid van dat activum die door dat eigenaar.

Databases worden gewijzigd via "transacties" die een reeks wijzigingen in de database vertegenwoordigen die als geheel moeten worden geaccepteerd of afgewezen. In het geval van een activumadministratie wordt een betaling van de ene gebruiker aan de andere bijvoorbeeld vertegenwoordigd door een transactie die de juiste hoeveelheid van de ene rij aftrekt en aan een andere toevoegt.

2. Meerdere schrijvers

Dit is gemakkelijk. Blockchains zijn een technologie voor databases met meerdere schrijvers. Met andere woorden, er moet meer dan één entiteit zijn die de transacties genereert die de database wijzigen. Weet je wie deze schrijvers zijn?

In de meeste gevallen zullen de schrijvers ook "knooppunten" uitvoeren die een kopie van de database bevatten en transacties doorgeven aan andere knooppunten in een peer-to-peer mode. Transacties kunnen echter ook worden gemaakt door gebruikers die zelf geen node draaien. Denk bijvoorbeeld aan een betalingssysteem dat collectief wordt onderhouden door een kleine groep banken, maar miljoenen eindgebruikers op mobiele apparaten heeft en alleen communiceert met de systemen van hun eigen bank.

3. Gebrek aan vertrouwen

En nu voor de derde regel. Als meerdere entiteiten naar de database schrijven, moet er ook een zekere mate van wantrouwen tussen die entiteiten. Met andere woorden, blockchains zijn een technologie voor databases met meerdere niet-vertrouwende schrijvers.

Je zou kunnen denken dat wantrouwen alleen ontstaat tussen afzonderlijke organisaties, zoals de banken die handelen op een markt of de bedrijven die betrokken zijn bij een toeleveringsketen. Maar het kan ook bestaan binnen één grote organisatiebijvoorbeeld tussen afdelingen of de operaties in verschillende landen.

Wat bedoel ik specifiek met wantrouwen? Ik bedoel dat de ene gebruiker niet bereid is een andere database-items te laten wijzigen waarvan hij “eigenaar” is. Op dezelfde manier zal de ene gebruiker, als het gaat om het lezen van de inhoud van de database, de “waarheid” zoals gerapporteerd door een andere gebruiker niet als evangelie aanvaarden, omdat elk andere economische of politieke prikkels heeft.

4. Disintermediatie

Dus het probleem, zoals tot nu toe gedefinieerd, is het mogelijk maken van een database met meerdere niet-vertrouwende schrijvers. En er is al een bekende oplossing voor dit probleem: de vertrouwde tussenpersoon. Dat wil zeggen, iemand die alle schrijvers vertrouwen, zelfs als ze elkaar niet volledig vertrouwen. Inderdaad, de wereld is gevuld met dergelijke databases, zoals het grootboek van rekeningen bij een bank. Je bank beheert de database en zorgt ervoor dat elke transactie geldig en geautoriseerd is door de klant wiens geld het verplaatst. Hoe beleefd u het ook vraagt, uw bank zal u nooit hun database rechtstreeks laten wijzigen.

Blockchains nemen de behoefte aan vertrouwde tussenpersonen weg door databases met meerdere niet-vertrouwende schrijvers die rechtstreeks moeten worden gewijzigd. Er is geen centrale poortwachter nodig om transacties te verifiëren en hun bron te verifiëren. In plaats daarvan wordt de definitie van een transactie uitgebreid met een bewijs van autorisatie en een bewijs van geldigheid. Transacties kunnen dus zijn onafhankelijk geverifieerd en verwerkt door elk knooppunt die een kopie van de database bijhoudt.

Maar de vraag die u moet stellen is: Wilt of heeft u deze disintermediatie nodig? Is er, gegeven uw use case, iets mis met het hebben van een centrale partij die een gezaghebbende database onderhoudt en optreedt als transactiegatekeeper? Goede redenen om de voorkeur te geven aan een op blockchain gebaseerde database boven een vertrouwde tussenpersoon, zijn bijvoorbeeld lagere kosten, snellere transacties en automatisch verzoening, nieuwe regelgeving of het simpelweg onvermogen om een ​​geschikte tussenpersoon te vinden.

5. Transactie-interactie

Blockchains zijn dus zinvol voor databases die worden gedeeld door meerdere schrijvers die elkaar niet volledig vertrouwen en die die database rechtstreeks wijzigen. Maar dat is nog niet genoeg. Blockchains schitteren echt waar er wat is interactie tussen de transacties gemaakt door deze schrijvers.

Wat bedoel ik met interactie? In de ruimste zin betekent dit dat transacties die door verschillende schrijvers worden gemaakt, vaak van elkaar afhankelijk zijn. Laten we bijvoorbeeld zeggen dat Alice wat geld naar Bob stuurt en dan stuurt Bob wat naar Charlie. In dit geval is de transactie van Bob afhankelijk van die van Alice en is er geen manier om de transactie van Bob te verifiëren zonder eerst die van Alice te controleren. Door deze afhankelijkheid horen de transacties natuurlijk bij elkaar in een enkele gedeelde database.

Als we dit verder gaan, is een leuke functie van blockchains dat transacties kunnen worden gemaakt gezamenlijk door meerdere schrijvers, zonder dat een van de partijen zichzelf aan risico's blootstelt. Dit is wat het toelaat levering versus betaling afwikkeling veilig over een blockchain uit te voeren, zonder tussenkomst van een vertrouwde tussenpersoon.

Een goede zaak kan ook worden gedaan voor situaties waarin transacties van verschillende schrijvers onderling gecorreleerd zijn, zelfs als ze onafhankelijk blijven. Een voorbeeld hiervan is een gedeelde identiteitsdatabase waarin meerdere entiteiten verschillende aspecten van de identiteit van consumenten valideren. Hoewel elk van deze certificeringen op zichzelf staat, biedt de blockchain een handige manier om alles op een uniforme manier samen te brengen.

6. Bepaal de regels

Dit is niet echt een voorwaarde, maar eerder een onvermijdelijk gevolg van de voorgaande punten. Als we een database rechtstreeks door meerdere schrijvers hebben aangepast, en die schrijvers vertrouwen elkaar niet volledig, dan moet de database ingesloten regels bevatten het beperken van de uitgevoerde transacties.

Deze regels verschillen fundamenteel van de beperkingen die in traditionele databases voorkomen, omdat ze betrekking hebben op het legitimiteit van transformaties in plaats van de toestand van de database op een bepaald moment. Elke transactie wordt door elk knooppunt in het netwerk gecontroleerd aan de hand van deze regels, en degene die mislukken, worden afgewezen en niet doorgestuurd.

Asset ledgers bevatten een eenvoudig voorbeeld van dit soort regels, om te voorkomen dat transacties activa uit het niets creëren. De regel stelt dat de totale hoeveelheid van elk activum in het grootboek voor en na elke transactie hetzelfde moet zijn.

7. Kies uw validators

Tot dusverre hebben we een gedistribueerde database beschreven waarin transacties op veel plaatsen kunnen ontstaan, zich peer-to-peer tussen knooppunten kunnen verspreiden en onafhankelijk door elk knooppunt kunnen worden geverifieerd. Dus waar komt een "blockchain" binnen? Nou, het is de taak van een blockchain om de gezaghebbend definitief transactielogboek, over wiens inhoud alle knooppunten het aantoonbaar eens zijn.

Waarom hebben we dit logboek nodig? Ten eerste stelt het nieuw toegevoegde knooppunten in staat om de inhoud van de database helemaal opnieuw te berekenen, zonder dat u een ander knooppunt hoeft te vertrouwen. Ten tweede gaat het in op de mogelijkheid dat sommige knooppunten sommige transacties missen als gevolg van systeemuitval of een communicatiestoring. Zonder een transactielogboek zou dit ertoe leiden dat de database van een knooppunt afwijkt van die van de andere, waardoor het doel van een gedeelde database wordt ondermijnd.

Ten derde is het mogelijk dat twee transacties met elkaar in conflict zijn, zodat er maar één kan worden geaccepteerd. Een klassiek voorbeeld is een dubbele uitgave waarin hetzelfde activum naar twee verschillende ontvangers wordt verzonden. In een peer-to-peer-database zonder centrale autoriteit kunnen knooppunten verschillende meningen hebben over welke transactie ze moeten accepteren, omdat er geen objectief juist antwoord. Door te eisen dat transacties in een blockchain worden "bevestigd", zorgen we ervoor dat alle knooppunten bij dezelfde beslissing samenkomen.

Eindelijk in Ethereum-stijl blockchains, precies bestellen van transacties speelt een cruciale rol, want elke transactie kan beïnvloeden wat er gebeurt in elke volgende. In dit geval fungeert de blockchain om de gezaghebbende chronologie te definiëren, zonder welke transacties helemaal niet kunnen worden verwerkt.

Een blockchain is letterlijk een ketting van blokken, waarbij elk blok een set transacties bevat die als een groep worden bevestigd. Maar wie is verantwoordelijk voor het kiezen van de transacties die naar elk blok gaan? In het soort “private blockchain” dat geschikt is voor bedrijfstoepassingen, is het antwoord een gesloten groep validators (“miners”) die de blokken die ze maken digitaal ondertekenen. Deze whitelisting wordt gecombineerd met een of andere vorm van gedistribueerde consensus om te voorkomen dat een minderheid van validators de controle over de keten overneemt. MultiChain gebruikt bijvoorbeeld een schema met de naam mijnbouw diversiteit, waarin de toegestane miners werken in een ronde robin mode, met een zekere mate van clementie om niet-functionerende knooppunten toe te staan.

Ongeacht welk consensusschema wordt gebruikt, de validatieknooppunten hebben veel minder macht dan de eigenaar van een traditionele gecentraliseerde database. Validators kunnen geen transacties vervalsen of de database wijzigen in strijd met de regels. In een asset ledger betekent dit dat ze het geld van anderen niet kunnen uitgeven, noch de totale hoeveelheid vertegenwoordigde activa kunnen veranderen. Desalniettemin zijn er nog twee manieren waarop validators de inhoud van een database onrechtmatig kunnen beïnvloeden:

• Transactiecensuur. Als genoeg validators kwaadwillig samenspannen, kunnen ze voorkomen dat een bepaalde transactie wordt bevestigd in de blockchain, waardoor deze permanent in het ongewisse blijft.
• Vooringenomen conflictoplossing. Als twee transacties conflicteren, beslist de validator die het volgende blok maakt welke transactie op de blockchain wordt bevestigd, waardoor de andere wordt geweigerd. De eerlijke keuze zou de transactie zijn die als eerste werd gezien, maar validators kunnen kiezen op basis van andere factoren zonder dit te onthullen.

Vanwege deze problemen moet u bij het implementeren van een op blockchain gebaseerde database een duidelijk idee hebben van wie uw validators zijn en waarom u ze vertrouwt, collectief, zo niet alleen. Afhankelijk van de use case kunnen de validators worden gekozen als: (a) een of meer knooppunten die worden beheerd door één organisatie, (b) een kerngroep van organisaties die de keten onderhouden, of (c) elk knooppunt op het netwerk.

8. Ondersteun uw vermogen

Als je zover bent gekomen, is het je misschien opgevallen dat ik de neiging heb om blockchains gedeelde databases te noemen, in plaats van de meer gebruikelijke "gedeelde grootboeken". Waarom? Omdat blockchains als technologie kunnen worden toegepast op problemen die veel verder gaan dan het volgen van eigendom van activa. Elke database met meerdere niet-vertrouwende schrijvers kan via een blockchain worden geïmplementeerd, zonder dat een centrale tussenpersoon nodig is. Voorbeelden zijn onder meer gedeelde agenda's, samenwerking in wiki-stijl en discussieforums.

Dat gezegd hebbende, lijkt het erop dat blockchains voorlopig vooral interessant zijn voor degenen die de beweging en uitwisseling van financiële activa volgen. Ik kan hiervoor twee redenen bedenken: (a) de financiële sector reageert op de (achteraf gezien minuscule) dreiging van cryptocurrencies zoals bitcoin, en (b) een asset ledger is het meest eenvoudige en natuurlijke voorbeeld van een gedeelde database met onderling afhankelijke transacties gemaakt door meerdere niet-vertrouwende entiteiten.

Als u een blockchain als een asset ledger wilt gebruiken, moet u nog een cruciale vraag beantwoorden: wat is de aard van de activa die worden verplaatst? Hiermee bedoel ik niet alleen contant geld of obligaties of cognossementen, hoewel dat natuurlijk ook belangrijk is. De vraag is eerder: Wie staat er achter de activa die op de blockchain worden weergegeven? Als de database zegt dat ik 10 eenheden van iets bezit, wie zal me dan toestaan ​​om die 10 eenheden te claimen in de echte wereld? Wie klaag ik aan als ik wat in de blockchain is geschreven niet kan omzetten in traditionele fysieke activa? (Zie dit activa overeenkomst bijvoorbeeld.)

Het antwoord hangt natuurlijk af van het gebruik. Voor monetaire activa kan men zich voorstellen dat bewaarbanken contant geld in traditionele vorm accepteren en vervolgens de rekeningen van spaarders crediteren in een blockchain-aangedreven gedistribueerd grootboek. Bij handelsfinanciering zouden kredietbrieven en connossementen worden ondersteund door respectievelijk de bank van de importeur en de rederij. En verder in de toekomst kunnen we ons een tijd voorstellen waarin de primaire uitgifte van bedrijfsobligaties vindt rechtstreeks plaats op een blockchain door het bedrijf dat fondsen wil werven.

Conclusie

Zoals ik in de inleiding al zei, als uw project niet voldoet elk van deze voorwaarden, zou je geen blockchain moeten gebruiken. Als een van de eerste vijf ontbreekt, moet u een van de volgende overwegen: (a) regelmatige bestandsopslag, (b) een gecentraliseerde database, (c) master-slave databasereplicatie, of (d) meerdere databases waarnaar gebruikers kunnen abonneren.

En als je aan de eerste vijf voldoet, is er nog werk aan de winkel. U moet de regels van uw applicatie kunnen uitdrukken in termen van de transacties die een database toelaat. U moet er zeker van zijn wie u als validator kunt vertrouwen en hoe u gedistribueerde consensus definieert. En tot slot, als u een gedeeld grootboek wilt maken, moet u weten wie de activa ondersteunt die dat grootboek vertegenwoordigt.

Heb je alle antwoorden? Gefeliciteerd, je hebt een echte blockchain-use case. En We zouden graag van je horen.

Plaats eventuele opmerkingen op LinkedIn. Zie ook deze follow-up: Vier echte use-cases voor blockchain.