Pas på den umulige smarte kontrakt

De tre mest almindelige misforståelser om smart kontrakt

Som udviklere af en populær blockchain-platform bliver vi nogle gange spurgt, om Ethereum-lignende smarte kontrakter er på multikæde køreplan. Det svar jeg altid giver er: nej eller i hvert fald ikke endnu.

Men i den hypefyldte verden af ​​blockchains er smarte kontrakter i højsædet, så hvorfor nogensinde ikke? Nå, problemet er, at selvom vi nu kender til tre stærke use cases for tilladte Bitcoin-stil blockchains (herkomst, inter-company records og letvægts finansiering), mangler vi endnu at finde ækvivalenten til Ethereum-stil smarte kontrakter.

Det er ikke sådan, at folk mangler ideer om, hvad de vil have smarte kontrakter til at gøre. Det er snarere, at så mange af disse ideer er simpelthen umulige. Du kan se, når smarte mennesker hører udtrykket "smarte kontrakter", har deres fantasi en tendens til at løbe løbsk. De fremtryller drømme om autonom intelligent software, der skal ud i verden og tage sine data med på turen.

Desværre er virkeligheden med smarte kontrakter langt mere banal end alt det:

En smart kontrakt er et stykke kode, som er lagret på en blockchain, udløst af blockchain-transaktioner, og som læser og skriver data i den pågældende blockchains database.

Det er det. Virkelig. En smart kontrakt er bare et fancy navn for kode, der kører på en blockchain og interagerer med den blokchains tilstand. Og hvad is kode? Det er Pascal, det er Python, det er PHP. Det er Java, det er Fortran, det er C++. Hvis vi taler databaser, er det det lagrede procedurer skrevet i en udvidelse af SQL. Alle disse sprog er grundlæggende ækvivalente og løser de samme slags problemer på de samme måder. Selvfølgelig har hver deres styrker og svagheder – du ville være skør af at bygge et websted i C eller komprimere HD-video i Ruby. Men i princippet kunne man i hvert fald, hvis man ville. Du ville bare betale en høj pris i form af bekvemmelighed, ydeevne og sandsynligvis dit hår.

Problemet med smarte kontrakter er ikke kun, at folks forventninger er overdrevne. Det er, at disse forventninger får mange til at bruge tid og penge på ideer, som umuligt kan gennemføres. Det ser ud til, at store virksomheder har tilstrækkelige ressourcer til at rejse en lang vej – fra det øjeblik, hvor den øverste ledelse møder en ny teknologi, til når den teknologis fordele og begrænsninger virkelig bliver forstået. Måske kan vores egen erfaring være med til at forkorte denne tid.

I løbet af de sidste ni måneder er vi blevet præsenteret for mange smarte kontraktbrugssager og har fundet os selv at svare igen og igen, at de simpelthen ikke kan lade sig gøre. Som et resultat heraf har vi identificeret de tre smarte kontrakt misforståelser, der er mest almindelige. Disse ideer er ikke forkerte, fordi teknologien er umoden, eller værktøjerne er endnu ikke tilgængelige. Tværtimod misforstår de grundlæggende egenskaber ved kode, som lever i en database og kører på en decentral måde.

Kontakt til eksterne tjenester

Ofte er den første foreslåede use case en smart kontrakt, som ændrer sin adfærd som reaktion på en ekstern begivenhed. For eksempel en landbrugsforsikring, der udbetaler betinget ud fra mængden af ​​nedbør i en given måned. Den forestillede proces går nogenlunde sådan her: Den smarte kontrakt venter til det forudbestemte tidspunkt, henter vejrudsigten fra en ekstern tjeneste og opfører sig hensigtsmæssigt baseret på de modtagne data.

Det hele lyder simpelt nok, men det er også umuligt. Hvorfor? Fordi en blockchain er et konsensusbaseret system, hvilket betyder, at det kun virker, hvis hver knude når en identisk tilstand efter at have behandlet hver transaktion og blok. Alt, hvad der foregår på en blockchain, skal være fuldstændig deterministisk, uden nogen mulig måde for forskelle at snige sig ind på. I det øjeblik, to ærlige noder er uenige om kædens tilstand, bliver hele systemet værdiløst.

Husk nu, at smarte kontrakter udføres uafhængigt af hver node i en kæde. Derfor, hvis en smart kontrakt henter nogle oplysninger fra en ekstern kilde, udføres denne hentning gentagne gange og separat af hver node. Men fordi denne kilde er uden for blockchain, der er ingen garanti for, at hver node vil modtage det samme svar. Måske vil kilden ændre sit svar i tiden mellem anmodninger fra forskellige noder, eller måske bliver den midlertidigt utilgængelig. Uanset hvad, er konsensus brudt, og hele blockchain dør.

Så hvad er løsningen? Faktisk er det ret simpelt. I stedet for en smart kontrakt, der starter hentning af eksterne data, opretter en eller flere betroede parter ("orakler") en transaktion, som indlejrer disse data i kæden. Hver knude vil have en identisk kopi af disse data, så de sikkert kan bruges i en smart kontraktberegning. Med andre ord et orakel skubber dataene på blockchain frem for en smart kontrakt trækker det ind.

Når det kommer til smarte kontrakter, der forårsager begivenheder i omverdenen, dukker et lignende problem op. For eksempel kan mange godt lide ideen om en smart kontrakt, som kalder en banks API for at overføre penge. Men hvis hver node uafhængigt udfører koden i kæden, hvem er så ansvarlig for at kalde denne API? Hvis svaret kun er én knude, hvad sker der så, hvis den pågældende knude ikke fungerer korrekt, bevidst eller ej? Og hvis svaret er hver knude, kan vi så betro hver knude med den API's adgangskode? Og vil vi virkelig have API'et kaldt hundredvis af gange? Endnu værre, hvis den smarte kontrakt skal vide, om API-kaldet var vellykket, er vi lige tilbage til problemet med at være afhængige af eksterne data.

Som før er en enkel løsning tilgængelig. I stedet for at den smarte kontrakt kalder en ekstern API, bruger vi en betroet service, som overvåger blockchains tilstand og udfører visse handlinger som svar. For eksempel kunne en bank proaktivt se en blockchain og udføre pengeoverførsler, som afspejler on-chain-transaktionerne. Dette udgør ingen risiko for blockchains konsensus, fordi kæden spiller en fuldstændig passiv rolle.

Ser vi på disse to løsninger, kan vi gøre nogle observationer. For det første kræver de begge en betroet enhed til at styre interaktionerne mellem blockchain og omverdenen. Selvom dette er teknisk muligt, underminerer det målet om et decentraliseret system. For det andet er de mekanismer, der bruges i disse løsninger, ligetil eksempler på læse og skrive en database. Et orakel, der leverer ekstern information, skriver simpelthen denne information ind i kæden. Og en tjeneste, der afspejler blockchains tilstand i den virkelige verden, gør ikke andet end at læse fra den kæde. Med andre ord er enhver interaktion mellem en blockchain og omverdenen begrænset til almindelige databaseoperationer. Vi vil tale mere om dette faktum senere.

Håndhævelse af on-chain betalinger

Her er et andet forslag, som vi plejer at høre meget: Brug af en smart kontrakt til at automatisere betalingen af ​​kuponer for en såkaldt "smart obligation". Ideen er, at den smarte kontraktkode automatisk starter betalingerne på de passende tidspunkter, undgår manuelle processer og garanterer, at udstederen ikke kan misligholde.

For at dette kan fungere, skal de midler, der bruges til at foretage betalingerne, også leve inde i blockchain, ellers kan en smart kontrakt umuligt garantere deres betaling. Husk nu, at en blockchain kun er en database, i dette tilfælde en finansiel hovedbog, der indeholder den udstedte obligation og nogle kontanter. Så når vi taler om kuponbetalinger, er det, vi faktisk taler om, databaseoperationer, som foregår automatisk på et aftalt tidspunkt.

Selvom denne automatisering er teknisk mulig, lider den af ​​økonomiske vanskeligheder. Hvis de midler, der bruges til kuponbetalinger, er kontrolleret af obligationens smarte kontrakt, så kan disse betalinger faktisk garanteres. Men det betyder også disse midler kan ikke bruges af obligationsudsteder til andet. Og hvis disse midler er ikke under kontrol af den smarte kontrakt, altså der er ingen måde, hvorpå betaling kan garanteres.

Med andre ord er en smart obligation enten meningsløs for udstederen eller meningsløs for investoren. Og hvis man tænker over det, er dette et helt åbenlyst resultat. Fra en investors perspektiv er hele pointen med en obligation dens attraktive afkast, på bekostning af en vis risiko for misligholdelse. Og for udstederen er formålet med en obligation at rejse midler til en produktiv, men noget risikabel aktivitet, såsom at bygge en ny fabrik. Der er ingen måde for obligationsudstederen at gøre brug af de rejste midler og samtidig garantere, at investoren vil blive tilbagebetalt. Det burde ikke komme som en overraskelse sammenhængen mellem risiko og afkast er ikke et problem, som blockchains kan løse.

Skjuler fortrolige data

Som jeg har skrevet om tidligere, er den største udfordring ved at implementere blockchains den radikale gennemsigtighed, som de giver. Hvis for eksempel ti banker opretter en blockchain sammen, og to udfører en bilateral transaktion, vil dette umiddelbart være synligt for de andre otte. Selvom der er forskellige strategier til at afhjælpe dette problem, er der ingen, der slår enkeltheden og effektiviteten af ​​en centraliseret database, hvor en betroet administrator har fuld kontrol over, hvem der kan se hvad.

Nogle mennesker tror, ​​at smarte kontrakter kan løse dette problem. De starter med, at hver smart kontrakt indeholder sin egen miniaturedatabase, som den har fuld kontrol over. Alle læse- og skriveoperationer på denne database formidles af kontraktens kode, hvilket gør det umuligt for en kontrakt at læse en andens data direkte. (Denne tætte kobling mellem data og kode kaldes indkapsling og er grundlaget for det populære objektorienteret programmering paradigme.)

Så hvis en smart kontrakt ikke kan få adgang til en andens data, har vi så løst problemet med blockchain-fortrolighed? Giver det mening at tale om at skjule information i en smart kontrakt? Desværre er svaret nej. For selvom en smart kontrakt ikke kan læse en andens data, så er disse data stadig gemt på hver eneste knude i kæden. For hver blockchain-deltager er den i hukommelsen eller disken på en system, som den pågældende deltager fuldstændigt kontrollerer. Og der er intet til hinder for, at de læser informationen fra deres eget system, hvis og når de vælger at gøre det.

At skjule data i en smart kontrakt er omtrent lige så sikkert som at skjule dem i HTML-koden på en webside. Sikker på, almindelige webbrugere vil ikke se det, fordi det ikke vises i deres browservindue. Men det eneste, der skal til, er for en webbrowser at tilføje en 'View Source'-funktion (som de alle har), og den skjulte information bliver universelt synlig. På samme måde, for data skjult i smarte kontrakter, er det eneste, der skal til, at nogen ændrer deres blockchain-software til at vise kontraktens fulde tilstand, og al antydning af hemmeligholdelse går tabt. En halvt anstændig programmør kunne gøre det på en time eller deromkring.

Hvad er smarte kontrakter til

Med så mange ting, som smarte kontrakter ikke kan, kan man spørge, hvad de egentlig er til for. Men for at besvare dette spørgsmål er vi nødt til at gå tilbage til det grundlæggende i selve blockchains. For at opsummere gør en blockchain det muligt for en database at blive direkte og sikkert delt af enheder, der ikke har tillid til hinanden, uden at kræve en central administrator. Blockchains muliggør datadisintermediation, og dette kan føre til betydelige besparelser i kompleksitet og omkostninger.

Enhver database ændres via "transaktioner", som indeholder et sæt ændringer til den database, som skal lykkes eller mislykkes som helhed. For eksempel i en finansiel finansiel bog er en betaling fra Alice til Bob repræsenteret af en transaktion, der (a) kontrollerer, om Alice har tilstrækkelige midler, (b) trækker en mængde fra Alices konto og (c) tilføjer den samme mængde til Bobs .

I en almindelig centraliseret database oprettes disse transaktioner af en enkelt betroet myndighed. I modsætning hertil, i en blockchain-drevet delt database, kan transaktioner oprettes af enhver af blockchains brugere. Og da disse brugere ikke har fuld tillid til hinanden, skal databasen indeholde regler, som begrænser de udførte transaktioner. For eksempel i en peer-to-peer finansiel hovedbog skal hver transaktion bevare den samlede mængde midler, ellers kan deltagerne frit give sig selv lige så mange penge, som de vil.

Man kan forestille sig forskellige måder at udtrykke disse regler på, men indtil videre er der to dominerende paradigmer, inspireret af henholdsvis Bitcoin og Ethereum. Bitcoin-metoden, som vi kan kalde "transaktionsbegrænsninger", evaluerer hver transaktion i form af: (a) databaseposter slettet af den transaktion, og (b) oprettede posteringer. I en finansiel finansbog siger reglen, at den samlede mængde midler i de slettede poster skal svare til totalen i de oprettede. (Vi anser ændringen af ​​en eksisterende post for at svare til at slette denne post og oprette en ny i stedet for).

Det andet paradigme, som kommer fra Ethereum, er smarte kontrakter. Dette angiver, at alle ændringer af en kontrakts data skal udføres af dens kode. (I sammenhæng med traditionelle databaser kan vi tænke på dette som en håndhæves lagret procedure.) For at ændre en kontrakts data sender blockchain-brugere anmodninger til sin kode, som bestemmer, om og hvordan disse anmodninger skal opfyldes. Som i dette eksempel, den smarte kontrakt for en finansiel finansiel bog udfører de samme tre opgaver som administratoren af ​​en centraliseret database: kontrollere for tilstrækkelige midler, trække fra én konto og tilføje til en anden.

Begge disse paradigmer er effektive, og hver har sine fordele og ulemper, som jeg har diskuteret i dybden tidligere. For at opsummere giver Bitcoin-stil transaktionsbegrænsninger overlegen samtidighed og ydeevne, mens Ethereum-stil smarte kontrakter giver større fleksibilitet. Så for at vende tilbage til spørgsmålet om, hvad smarte kontrakter er til:

Smarte kontrakter er til blockchain-brugssager, som ikke kan implementeres med transaktionsbegrænsninger.

I betragtning af dette kriterium for brug af smarte kontrakter, har jeg endnu ikke set en stærk brugssag for tilladte blockchains, som kvalificerer. Alle de overbevisende blockchain-applikationer, jeg kender, kan implementeres med Bitcoin-lignende transaktioner, som kan håndtere tilladelser og generel datalagring, samt oprettelse, overførsel, deponering, udveksling og ødelæggelse af aktiver. Ikke desto mindre dukker der stadig nye use cases op, og jeg ville ikke blive overrasket, hvis nogle do kræver kraften i smarte kontrakter. Eller i det mindste en udvidelse af Bitcoin-paradigmet.

Uanset hvad svaret viser sig at være, er nøglen til at huske, at smarte kontrakter simpelthen er en metode til at begrænse de transaktioner, der udføres i en database. Dette er uden tvivl en nyttig ting og er afgørende for at gøre databasen sikker til deling. Men smarte kontrakter kan ikke andet, og de kan bestemt ikke undslippe grænserne for den database, de ligger i.

Skriv eventuelle kommentarer hos LinkedIn.