Pas op voor het onmogelijke slimme contract

De drie meest voorkomende misvattingen over slimme contracten

Als ontwikkelaars van een populair blockchain-platform krijgen we wel eens de vraag of Ethereum-achtige slimme contracten op de MultiChain routekaart. Het antwoord dat ik altijd geef is: nee, of in ieder geval nog niet.

Maar in de met hype gevulde wereld van blockchains zijn slimme contracten een ware rage, dus waarom niet? Welnu, het probleem is dat, hoewel we nu drie sterke use-cases kennen voor toegestane blockchains in Bitcoin-stijl (herkomst, records tussen bedrijven en lichtgewicht financiën), we nog geen equivalent moeten vinden voor slimme contracten in Ethereum-stijl.

Het is niet zo dat mensen geen idee hebben wat ze willen dat slimme contracten doen. Het zijn eerder zo veel van deze ideeën zijn gewoonweg onmogelijk. Weet je, als slimme mensen de term 'slimme contracten' horen, heeft hun fantasie de neiging om op hol te slaan. Ze roepen dromen op van autonome intelligente software die de wereld intrekt en de gegevens meeneemt voor de rit.

Helaas is de realiteit van slimme contracten veel alledaagser dan dat alles:

Een smart contract is een stukje code dat wordt opgeslagen op een blockchain, geactiveerd wordt door blockchain-transacties, en dat gegevens leest en schrijft in de database van die blockchain.

Dat is het. Werkelijk. Een slim contract is slechts een mooie naam voor code die op een blockchain draait en in wisselwerking staat met de staat van die blockchain. En wat is code? Het is Pascal, het is Python, het is PHP. Het is Java, het is Fortran, het is C ++. Als we het hebben over databases, is dat zo opgeslagen procedures geschreven in een extensie van SQL. Al deze talen zijn fundamenteel equivalent en lossen dezelfde soorten problemen op dezelfde soort manieren op. Elk heeft natuurlijk zijn sterke en zwakke punten - je zou gek zijn om een ​​website in C te bouwen of HD-video te comprimeren in Ruby. Maar in principe zou je dat kunnen als je zou willen. Je zou gewoon een hoge prijs betalen in termen van gemak, prestaties en waarschijnlijk je haar.

Het probleem met slimme contracten is niet alleen dat de verwachtingen van mensen overdreven zijn. Het is dat deze verwachtingen ertoe leiden dat velen tijd en geld besteden aan ideeën die onmogelijk kunnen worden geïmplementeerd. Het lijkt erop dat grote bedrijven over voldoende middelen beschikken om een ​​lang pad af te leggen - vanaf het moment waarop het senior management een nieuwe technologie tegenkomt, tot het moment waarop de voordelen en beperkingen van die technologie echt worden begrepen. Misschien kan onze eigen ervaring deze tijd helpen verkorten.

In de afgelopen negen maanden hebben we veel slimme contractgebruiksvoorbeelden gekregen en hebben we keer op keer gereageerd dat ze gewoon niet kunnen worden gedaan. Als resultaat hebben we de drie meest voorkomende misvattingen over slimme contracten geïdentificeerd. Deze ideeën zijn niet verkeerd omdat de technologie onvolwassen is of de tools nog niet beschikbaar zijn. In plaats daarvan begrijpen ze het fundamentele eigenschappen van code die in een database leeft en op een gedecentraliseerde manier draait.

Contact opnemen met externe diensten

Vaak is de eerste voorgestelde use-case een slim contract dat zijn gedrag verandert als reactie op een externe gebeurtenis. Bijvoorbeeld een landbouwverzekering die voorwaardelijk uitkeert op basis van de hoeveelheid neerslag in een bepaalde maand. Het ingebeelde proces verloopt ongeveer als volgt: het slimme contract wacht tot de vooraf bepaalde tijd, haalt het weerbericht op van een externe dienst en gedraagt ​​zich op de juiste manier op basis van de ontvangen gegevens.

Dit klinkt allemaal eenvoudig genoeg, maar het is ook onmogelijk. Waarom? Omdat een blockchain een op consensus gebaseerd systeem is, wat betekent dat het alleen werkt als elk knooppunt een identieke status bereikt na het verwerken van elke transactie en blok. Alles wat er op een blockchain plaatsvindt, moet volledig deterministisch zijn, zonder dat er verschillen kunnen binnensluipen. Op het moment dat twee eerlijke knooppunten het oneens zijn over de toestand van de keten, wordt het hele systeem waardeloos.

Bedenk nu dat slimme contracten onafhankelijk worden uitgevoerd door elk knooppunt in een ketting. Daarom, als een smart contract bepaalde informatie uit een externe bron haalt, wordt dit ophalen herhaaldelijk en afzonderlijk door elk knooppunt uitgevoerd. Maar omdat deze bron buiten de blockchain valt, er is geen garantie dat elk knooppunt hetzelfde antwoord krijgt. Misschien verandert de bron zijn antwoord in de tijd tussen verzoeken van verschillende knooppunten in, of wordt het tijdelijk niet beschikbaar. Hoe dan ook, de consensus wordt verbroken en de hele blockchain sterft.

Dus wat is de tijdelijke oplossing? Eigenlijk is het vrij simpel. In plaats van een slim contract dat het ophalen van externe gegevens initieert, creëren een of meer vertrouwde partijen ("orakels") een transactie die die gegevens in de keten verankert. Elk knooppunt heeft een identieke kopie van deze gegevens, zodat deze veilig kan worden gebruikt in een slimme contractberekening. Met andere woorden, een orakel duwt de gegevens op de blockchain in plaats van een slim contract trekken het in.

Als het gaat om slimme contracten die gebeurtenissen in de buitenwereld veroorzaken, doet zich een soortgelijk probleem voor. Velen houden bijvoorbeeld van het idee van een slim contract dat de API van een bank aanroept om geld over te maken. Maar als elk knooppunt onafhankelijk de code in de keten uitvoert, wie is dan verantwoordelijk voor het aanroepen van deze API? Als het antwoord slechts één knooppunt is, wat gebeurt er dan als dat specifieke knooppunt niet goed functioneert, opzettelijk of niet? En als het antwoord elk knooppunt is, kunnen we dan elk knooppunt met het wachtwoord van die API vertrouwen? En willen we echt dat de API honderden keren wordt gebeld? Erger nog, als het slimme contract moet weten of de API-oproep succesvol was, zijn we meteen weer terug bij het probleem om afhankelijk te zijn van externe gegevens.

Net als voorheen is er een eenvoudige oplossing beschikbaar. In plaats van het slimme contract dat een externe API aanroept, gebruiken we een vertrouwde service die de status van de blockchain bewaakt en als reactie daarop bepaalde acties uitvoert. Een bank zou bijvoorbeeld proactief naar een blockchain kunnen kijken en geldoverdrachten kunnen uitvoeren die de on-chain transacties weerspiegelen. Dit vormt geen risico voor de consensus van de blockchain, omdat de keten een geheel passieve rol speelt.

Als we naar deze twee oplossingen kijken, kunnen we enkele opmerkingen maken. Ten eerste hebben ze allebei een vertrouwde entiteit nodig om de interacties tussen de blockchain en de buitenwereld te beheren. Hoewel dit technisch mogelijk is, ondermijnt het het doel van een gedecentraliseerd systeem. Ten tweede zijn de mechanismen die in deze tijdelijke oplossingen worden gebruikt, duidelijke voorbeelden van een database lezen en schrijven. Een orakel dat externe informatie levert, is simpelweg die informatie in de ketting schrijven. En een dienst die de status van de blockchain in de echte wereld weerspiegelt, doet niets anders dan lezen uit die ketting. Met andere woorden, elke interactie tussen een blockchain en de buitenwereld is beperkt tot reguliere databasebewerkingen. We zullen later meer over dit feit praten.

On-chain betalingen afdwingen

Hier is nog een voorstel dat we vaak horen: een slim contract gebruiken om de betaling van kortingsbonnen voor een zogenaamde "slimme obligatie" te automatiseren. Het idee is dat de slimme contractcode automatisch de betalingen op de juiste momenten start, handmatige processen vermijdt en garandeert dat de uitgever niet in gebreke kan blijven.

Om dit te laten werken, moeten de fondsen die worden gebruikt om de betalingen te doen natuurlijk ook binnen de blockchain leven, anders kan een smart contract onmogelijk hun betaling garanderen. Bedenk nu dat een blockchain slechts een database is, in dit geval een financieel grootboek met de uitgegeven obligatie en wat geld. Dus als we het hebben over couponbetalingen, hebben we het eigenlijk over databasebewerkingen die automatisch op een afgesproken tijdstip plaatsvinden.

Hoewel deze automatisering technisch haalbaar is, kampt ze met financiële moeilijkheden. Als het geld dat voor couponbetalingen wordt gebruikt, wordt beheerd door het slimme contract van de obligatie, kunnen die betalingen inderdaad worden gegarandeerd. Maar dit betekent ook die fondsen kan door de emittent van de obligatie voor niets anders worden gebruikt. En als die fondsen niet onder de controle van het slimme contract, dan er is geen manier waarop de betaling kan worden gegarandeerd.

Met andere woorden, een slimme obligatie is ofwel zinloos voor de uitgevende instelling, ofwel zinloos voor de belegger. En als je erover nadenkt, is dit een volkomen voor de hand liggend resultaat. Vanuit het perspectief van een belegger is het hele punt van een obligatie het aantrekkelijke rendement, ten koste van enig risico op wanbetaling. En voor de emittent is het doel van een obligatie om geld in te zamelen voor een productieve maar enigszins risicovolle activiteit, zoals het bouwen van een nieuwe fabriek. De emittent van de obligatie kan op geen enkele manier gebruik maken van het opgehaalde geld en tegelijkertijd garanderen dat de belegger wordt terugbetaald. Dat hoeft niet te verbazen de verbinding tussen risico en rendement is geen probleem dat blockchains kunnen oplossen.

Vertrouwelijke gegevens verbergen

Zoals ik heb gedaan eerder geschrevenis de grootste uitdaging bij het inzetten van blockchains de radicale transparantie die ze bieden. Als bijvoorbeeld tien banken samen een blockchain opzetten en twee een bilaterale transactie uitvoeren, is dit direct zichtbaar voor de andere acht. Hoewel er verschillende strategieën zijn om dit probleem te verminderen, is er geen beter dan de eenvoud en efficiëntie van een gecentraliseerde database, waarin een vertrouwde beheerder de volledige controle heeft over wie wat kan zien.

Sommige mensen denken dat slimme contracten dit probleem kunnen oplossen. Ze beginnen met het feit dat elk smart contract zijn eigen miniatuurdatabase bevat, waarover het de volledige controle heeft. Alle lees- en schrijfbewerkingen in deze database worden gemedieerd door de contractcode, waardoor het voor het ene contract onmogelijk is om de gegevens van een ander rechtstreeks te lezen. (Deze nauwe koppeling tussen gegevens en code wordt inkapseling genoemd en vormt de basis van de populaire object georiënteerd programmeren paradigma.)

Dus als een smart contract geen toegang heeft tot de gegevens van een ander, hebben we dan het probleem van de vertrouwelijkheid van blockchain opgelost? Heeft het zin om te praten over het verbergen van informatie in een slim contract? Helaas is het antwoord nee. Want zelfs als een smart contract de gegevens van een ander niet kan lezen, worden die gegevens nog steeds op elk afzonderlijk knooppunt in de keten opgeslagen. Voor elke blockchain-deelnemer staat het in het geheugen of op de schijf van een systeem dat die deelnemer volledig beheert. En niets houdt hen tegen om de informatie uit hun eigen systeem te lezen, als en wanneer ze daarvoor kiezen.

Het verbergen van gegevens in een smart contract is ongeveer net zo veilig als het verbergen in de HTML-code van een webpagina. Natuurlijk zullen gewone internetgebruikers het niet zien, omdat het niet in hun browservenster wordt weergegeven. Maar het enige dat nodig is, is dat een webbrowser een 'View Source'-functie toevoegt (zoals ze allemaal hebben), en de verborgen informatie wordt universeel zichtbaar. Evenzo, voor gegevens die zijn verborgen in slimme contracten, is het voldoende dat iemand zijn blockchain-software aanpast om de volledige staat van het contract weer te geven, en alle schijn van geheimhouding is verloren. Een halfwaardige programmeur zou dat binnen een uur of zo kunnen doen.

Waar slimme contracten voor zijn

Met zoveel dingen die slimme contracten niet kunnen, zou je kunnen vragen waar ze eigenlijk voor zijn. Maar om deze vraag te beantwoorden, moeten we teruggaan naar de fundamenten van blockchains zelf. Samengevat: een blockchain maakt het mogelijk dat een database direct en veilig wordt gedeeld door entiteiten die elkaar niet vertrouwen, zonder dat een centrale beheerder nodig is. Blockchains maken data-disintermediatie mogelijk, en dit kan leiden tot aanzienlijke besparingen in complexiteit en kosten.

Elke database wordt gewijzigd via "transacties", die een reeks wijzigingen aan die database bevatten die als geheel moeten slagen of mislukken. In een financieel grootboek wordt een betaling van Alice aan Bob bijvoorbeeld vertegenwoordigd door een transactie die (a) controleert of Alice voldoende saldo heeft, (b) een hoeveelheid aftrekt van Alice's rekening en (c) dezelfde hoeveelheid toevoegt aan die van Bob. .

In een reguliere gecentraliseerde database worden deze transacties aangemaakt door een enkele vertrouwde autoriteit. Daarentegen kunnen in een blockchain-gestuurde gedeelde database transacties worden gemaakt door elk van de gebruikers van die blockchain. En aangezien deze gebruikers elkaar niet volledig vertrouwen, moet de database regels bevatten die de uitgevoerde transacties beperken. In een peer-to-peer financieel grootboek moet elke transactie bijvoorbeeld de totale hoeveelheid geld behouden, anders kunnen deelnemers zichzelf vrijelijk zoveel geld geven als ze willen.

Men kan zich verschillende manieren voorstellen om deze regels uit te drukken, maar voor nu zijn er twee dominante paradigma's, geïnspireerd door respectievelijk Bitcoin en Ethereum. De Bitcoin-methode, die we “transactiebeperkingen” zouden kunnen noemen, evalueert elke transactie in termen van: (a) de database-items die door die transactie zijn verwijderd, en (b) de gecreëerde items. In een financieel grootboek stelt de regel dat de totale hoeveelheid fondsen in de verwijderde posten overeen moet komen met het totaal in de gemaakte posten. (We beschouwen het wijzigen van een bestaand item als het verwijderen van dat item en het maken van een nieuw item in plaats daarvan.)

Het tweede paradigma, dat afkomstig is van Ethereum, zijn slimme contracten. Hierin staat dat alle wijzigingen aan de gegevens van een contract moeten worden uitgevoerd door middel van de code. (In de context van traditionele databases kunnen we dit zien als een afgedwongen opgeslagen procedure.) Om de gegevens van een contract te wijzigen, sturen blockchain-gebruikers verzoeken aan de code, die bepaalt of en hoe aan die verzoeken moet worden voldaan. Als in dit voorbeeld, voert het slimme contract voor een financieel grootboek dezelfde drie taken uit als de beheerder van een gecentraliseerde database: controleren of er voldoende geld is, aftrekken van de ene rekening en toevoegen aan een andere.

Beide paradigma's zijn effectief, en elk heeft zijn voor- en nadelen, zoals ik heb gedaan eerder uitvoerig besproken. Samenvattend bieden transactiebeperkingen in Bitcoin-stijl superieure gelijktijdigheid en prestaties, terwijl slimme contracten in Ethereum-stijl meer flexibiliteit bieden. Dus om terug te keren naar de vraag waar slimme contracten voor zijn:

Slimme contracten zijn bedoeld voor blockchain-use-cases die niet kunnen worden geïmplementeerd met transactiebeperkingen.

Gezien dit criterium voor het gebruik van slimme contracten, moet ik nog een sterke use-case zien voor toegestane blockchains die in aanmerking komen. Alle boeiende blockchaintoepassingen die ik ken, kunnen worden geïmplementeerd met transacties in Bitcoin-stijl, die kunnen omgaan met toestemming en algemene gegevensopslag, evenals het maken, overdragen, escrowen, uitwisselen en vernietigen van activa. Desalniettemin verschijnen er nog steeds nieuwe use-cases, en het zou me niet verbazen als sommige do vereisen de kracht van slimme contracten. Of op zijn minst een uitbreiding van het Bitcoin-paradigma.

Wat het antwoord ook blijkt te zijn, de sleutel om te onthouden is dat slimme contracten slechts één methode zijn om de transacties die in een database worden uitgevoerd, te beperken. Dit is ongetwijfeld nuttig en essentieel om die database veilig te maken om te delen. Maar slimme contracten kunnen niets anders, en ze kunnen zeker niet ontsnappen aan de grenzen van de database waarin ze zich bevinden.

Plaats eventuele opmerkingen op LinkedIn.