Se upp för det omöjliga smarta kontraktet

De tre vanligaste smarta kontraktuppfattningarna

Som utvecklare av en populär blockchain-plattform får vi ibland frågan om Ethereum-liknande smarta kontrakt finns på MultiKedja färdplan. Svaret jag alltid ger är: nej, eller åtminstone ännu inte.

Men i den hypefyllda världen av blockchains är smarta kontrakt allt rasande, så varför inte? Problemet är att även om vi nu känner till tre starka användningsfall för tillåtna block-kedjor i Bitcoin-stil (härkomst, mellanföretagsposter och lättviktsfinansiering) så hittar vi ännu motsvarigheten för smarta kontrakt i Ethereum-stil.

Det är inte så att människor saknar idéer om vad de vill ha smarta kontrakt. Snarare är det så många av dessa idéer är helt enkelt omöjliga. Du ser, när smarta människor hör ordet ”smarta kontrakt”, tenderar deras fantasi att bli löst. De trycker fram drömmar om autonom intelligent programvara, går ut i världen och tar med sig dess data för resan.

Tyvärr är verkligheten i smarta kontrakt mycket mer vardagliga än allt detta:

Ett smart kontrakt är ett kodstycke som lagras på en blockchain, utlöst av blockchain-transaktioner, och som läser och skriver data i blockchains databas.

Det är allt. Verkligen. Ett smart kontrakt är bara ett fint namn på kod som körs på en blockchain och interagerar med den blockchains tillstånd. Och vad is koda? Det är Pascal, det är Python, det är PHP. Det är Java, det är Fortran, det är C ++. Om vi ​​pratar databaser är det det Lagrade procedurer skriven i en förlängning av SQL. Alla dessa språk är i grunden likvärdiga och löser samma slags problem på samma sätt. Naturligtvis har var och en sina styrkor och svagheter - du skulle bli galen att bygga en webbplats i C eller komprimera HD-video i Ruby. Men i princip åtminstone kan du göra det om du ville. Du skulle bara betala ett tungt pris när det gäller bekvämlighet, prestanda och förmodligen ditt hår.

Problemet med smarta kontrakt är inte bara att människors förväntningar är överdrivna. Det är att dessa förväntningar leder till att många spenderar tid och pengar på idéer som omöjligt kan genomföras. Det verkar som att stora företag har tillräckliga resurser för att resa en lång väg - från det ögonblick då den högsta ledningen möter en ny teknik, till när den teknologins fördelar och begränsningar verkligen förstås. Kanske vår egen erfarenhet kan hjälpa till att förkorta den här gången.

Under de senaste nio månaderna har vi fått många smarta kontraktsanvändningsfall och har befunnit oss reagera gång på gång att de helt enkelt inte kan göras. Som ett resultat har vi identifierat de tre smarta uppfattningar om missuppfattningar som oftast hålls. Dessa idéer är inte fel eftersom tekniken är omogen eller om verktygen ännu inte finns tillgängliga. Snarare missförstår de grundläggande egenskaper hos kod som lever i en databas och körs på ett decentraliserat sätt.

Kontakta externa tjänster

Ofta är det första användningsfallet som föreslås ett smart kontrakt som ändrar dess beteende som svar på någon extern händelse. Till exempel en jordbruksförsäkring som betalar villkorat utifrån mängden nederbörd i en given månad. Den tänkta processen går något så här: det smarta kontraktet väntar tills den förutbestämda tiden, hämtar väderrapporten från en extern tjänst och uppför sig på lämpligt sätt baserat på de mottagna uppgifterna.

Allt låter helt enkelt, men det är också omöjligt. Varför? Eftersom en blockchain är ett konsensusbaserat system, vilket innebär att det bara fungerar om varje nod når ett identiskt tillstånd efter bearbetning av varje transaktion och block. Allt som äger rum på en blockchain måste vara helt deterministisk, och det är inte möjligt att skillnader kryper in. I det ögonblick som två ärliga noder inte håller med om kedjans tillstånd blir hela systemet värdelöst.

Kom ihåg att smarta kontrakt genomförs oberoende av varje nod i en kedja. Därför, om ett smart kontrakt hämtar viss information från en extern källa, utförs denna hämtning upprepade gånger och separat av varje nod. Men eftersom denna källa är utanför blockchainen, det finns ingen garanti för att varje nod får samma svar. Kanske kommer källan att ändra sitt svar under tiden mellan förfrågningar från olika noder, eller kanske kommer den tillfälligt att vara tillgänglig. I vilket fall som helst bryts konsensus och hela blockchainen dör.

Så vad är lösningen? Egentligen är det ganska enkelt. I stället för ett smart kontrakt som initierar hämtning av externa data skapar en eller flera betrodda parter (“oracle”) en transaktion som inbäddar informationen i kedjan. Varje nod har en identisk kopia av dessa data, så att de kan användas säkert i en smart kontraktsberäkning. Med andra ord ett orakel skjuter data på blockchain snarare än ett smart kontrakt dra det i.

När det gäller smarta kontrakt som orsakar händelser i omvärlden uppträder ett liknande problem. Många gillar till exempel idén om ett smart kontrakt som kallar en banks API för att överföra pengar. Men om varje nod självständigt kör koden i kedjan, vem ansvarar för att kalla detta API? Om svaret bara är en nod, vad händer om den specifika nodfunktionen, medvetet eller inte? Och om svaret är varje nod, kan vi lita på varje nod med API: s lösenord? Och vill vi verkligen att API heter hundratals gånger? Ännu värre är det, om det smarta kontraktet behöver veta om API-samtalet lyckades, är vi tillbaka till problemet med beroende på externa data.

Som tidigare är en enkel lösning tillgänglig. Istället för att det smarta kontraktet kallar ett externt API använder vi en pålitlig tjänst som övervakar blockchains tillstånd och utför vissa åtgärder som svar. Till exempel kan en bank proaktivt titta på en blockchain och utföra pengaröverföringar som speglar transaktionerna på kedjan. Detta utgör ingen risk för blockchains konsensus eftersom kedjan spelar en helt passiv roll.

Om vi ​​tittar på dessa två lösningar kan vi göra några observationer. Först kräver de båda en betrodd enhet för att hantera interaktioner mellan blockchain och omvärlden. Även om detta är tekniskt möjligt undergräver det målet för ett decentraliserat system. För det andra är mekanismerna som används i dessa lösningar enkla exempel på läsa och skriva en databas. Ett orakel som tillhandahåller extern information är att helt enkelt skriva in den informationen i kedjan. Och en tjänst som speglar blockchains tillstånd i den verkliga världen gör ingenting annat än att läsa från den kedjan. Med andra ord, varje interaktion mellan en blockchain och omvärlden är begränsad till vanliga databasoperationer. Vi kommer att prata mer om detta faktum senare.

Verkställa betalningar via kedjan

Här är ett annat förslag som vi tenderar att höra mycket: att använda ett smart kontrakt för att automatisera betalningen av kuponger för en så kallad "smart bond". Tanken är att den smarta avtalskoden automatiskt ska initiera betalningarna vid lämpliga tidpunkter, undvika manuella processer och garantera att emittenten inte kan standardisera.

Naturligtvis, för att detta ska fungera, måste de medel som används för att göra betalningarna också leva inuti blockchainen, annars kan ett smart avtal inte möjligen garantera deras betalning. Kom ihåg att en blockchain bara är en databas, i detta fall en finansiell bok som innehåller det emitterade obligationen och lite kontanter. Så när vi pratar om kupongbetalningar, det vi faktiskt pratar om är databasoperationer som sker automatiskt vid en överenskommen tidpunkt.

Även om denna automatisering är tekniskt genomförbar, lider den av ekonomiska svårigheter. Om de medel som används för kupongbetalningar styrs av obligationens smarta avtal kan dessa betalningar verkligen garanteras. Men detta betyder också dessa fonder kan inte användas av obligationsutgivaren för något annat. Och om dessa medel inte under kontrollen av det smarta kontraktet det finns inget sätt på vilket betalning kan garanteras.

Med andra ord, en smart obligation är antingen meningslös för emittenten eller meningslös för investeraren. Och om du tänker på det är detta ett helt uppenbart resultat. Ur en investerares perspektiv är hela obligationens poäng dess attraktiva avkastningskostnad, till en kostnad av viss risk för fallissemang. Och för emittenten är en obligations syfte att samla in medel för en produktiv men lite riskfylld aktivitet, till exempel att bygga en ny fabrik. Det finns inget sätt för obligationsutgivaren att använda de insamlade medlen, samtidigt som man garanterar att investeraren kommer att återbetalas. Det borde inte överraska det sambandet mellan risk och avkastning är inte ett problem som blockchains kan lösa.

Gömmer konfidentiella uppgifter

Som jag har skriven om tidigare, den största utmaningen när det gäller att distribuera blockchains är den radikala transparensen som de ger. Till exempel, om tio banker skapar en blockchain tillsammans, och två genomför en bilateral transaktion, kommer detta att vara omedelbart synligt för de andra åtta. Även om det finns olika strategier för att mildra detta problem, slår ingen enkelheten och effektiviteten i en centraliserad databas, där en betrodd administratör har full kontroll över vem som kan se vad.

Vissa tror att smarta kontrakt kan lösa detta problem. De börjar med det faktum att varje smart kontrakt innehåller sin egen miniatyrdatabas, över vilken det har full kontroll. Alla läs- och skrivoperationer i denna databas medieras av kontraktets kod, vilket gör det omöjligt för ett avtal att läsa en annans data direkt. (Denna snäva koppling mellan data och kod kallas inkapsling och är grunden till den populära objektorienterad programmering paradigm.)

Så om ett smart kontrakt inte kan få åtkomst till en annans data, har vi löst problemet med blockchain-konfidentialitet? Är det vettigt att prata om att dölja information i ett smart kontrakt? Tyvärr är svaret nej. För även om ett smart kontrakt inte kan läsa en annans data, lagras dessa data fortfarande på varje enskild nod i kedjan. För varje blockchain-deltagare finns det i minnet eller disken på en system som den deltagaren helt kontrollerar. Och det finns inget som hindrar dem att läsa informationen från sitt eget system, om och när de väljer att göra det.

Dölja data i ett smart kontrakt är ungefär lika säkert som att dölja dem i HTML-koden på en webbsida. Visst kommer vanliga webbanvändare inte att se det, eftersom det inte visas i deras webbläsarfönster. Men allt som krävs är att en webbläsare lägger till en "View Source" -funktion (som de alla har), och den dolda informationen blir allmänt synlig. På samma sätt, för data som är dolda i smarta kontrakt, krävs det bara att någon modifierar sin blockchain-programvara för att visa kontraktets fulla tillstånd, och all sekretess försvinner. En halv anständig programmerare skulle kunna göra det på en timme eller så.

Vad smarta kontrakt är för

Med så många saker som smarta kontrakt inte kan göra, kan man fråga vad de faktiskt är till för. Men för att besvara den här frågan måste vi gå tillbaka till grundläggande blockchains själva. För att sammanfatta, blockchain gör det möjligt att dela en databas direkt och säkert av enheter som inte litar på varandra utan att behöva en central administratör. Blockchains möjliggör datadistribution, och detta kan leda till betydande besparingar i komplexitet och kostnader.

Varje databas modifieras via "transaktioner", som innehåller en uppsättning ändringar i den databasen som måste lyckas eller misslyckas som helhet. Till exempel, i en finansiell huvudbok, representeras en betalning från Alice till Bob av en transaktion som (a) kontrollerar om Alice har tillräckliga medel, (b) drar en kvantitet från Alice's konto och (c) lägger till samma kvantitet till Bob's .

I en regelbunden centraliserad databas skapas dessa transaktioner av en enda betrodd myndighet. I en blockchaindriven delad databas kan transaktioner däremot skapas av vilken som helst av den blockchains användare. Och eftersom dessa användare inte helt litar på varandra måste databasen innehålla regler som begränsar de genomförda transaktionerna. Till exempel i en jämställd ekonomisk bok måste varje transaktion bevara den totala mängden medel, annars kan deltagarna fritt ge sig själva så mycket pengar som de ville.

Man kan föreställa sig olika sätt att uttrycka dessa regler, men för tillfället finns det två dominerande paradigmer, inspirerade av Bitcoin respektive Ethereum. Bitcoin-metoden, som vi kan kalla "transaktionsbegränsningar", utvärderar varje transaktion i termer av: (a) databasposter som raderas av den transaktionen och (b) poster som skapats. I en finansiell huvudbok anger regeln att den totala mängden medel i de raderade posterna måste matcha summan i de skapade. (Vi anser att modifieringen av en befintlig post är likvärdig med att ta bort den posten och skapa en ny på sin plats.)

Det andra paradigmet, som kommer från Ethereum, är smarta kontrakt. Här anges att alla ändringar av ett kontraktsuppgifter måste utföras med dess kod. (I samband med traditionella databaser kan vi tänka på detta som en verkställas lagrad procedur.) För att ändra ett avtalsdata skickar blockchain-användare förfrågningar till dess kod, som avgör om och hur man ska uppfylla dessa förfrågningar. Som i detta exempel, det smarta kontraktet för en finansiell huvudbok utför samma tre uppgifter som administratören för en centraliserad databas: kontrollera om det finns tillräckliga medel, dra av från ett konto och lägga till ett annat.

Båda dessa paradigmer är effektiva, och var och en har sina fördelar och nackdelar, som jag har diskuterat ingående tidigare. Sammanfattningsvis ger transaktionsbegränsningar i Bitcoin-stil överlägsen samtidighet och prestanda, medan smarta kontrakt i Ethereum-stil erbjuder större flexibilitet. Så för att återgå till frågan om vad smarta kontrakt är för:

Smarta kontrakt är för blockchain-användningsfall som inte kan implementeras med transaktionsbegränsningar.

Med tanke på detta kriterium för att använda smarta kontrakt ser jag ännu inte ett starkt användningsfall för tillåtna blockchains som är kvalificerade. Alla övertygande blockchain-applikationer som jag känner kan implementeras med transaktioner i Bitcoin-stil, som kan hantera tillstånd och allmän datalagring, samt tillgångsskapande, överföring, escrow, utbyte och förstörelse. Icke desto mindre dyker det upp nya fall, och jag skulle inte bli förvånad om några do kräver kraften i smarta kontrakt. Eller åtminstone en förlängning av Bitcoin-paradigmet.

Oavsett vad svaret visar sig vara, är nyckeln att komma ihåg att smarta kontrakt helt enkelt är en metod för att begränsa transaktionerna som utförs i en databas. Detta är utan tvekan en användbar sak och är avgörande för att göra databasen säker för delning. Men smarta kontrakt kan inte göra något annat, och de kan säkert inte undgå gränserna för databasen där de är bosatta.

Skicka eventuella kommentarer på LinkedIn.