Pass på den umulige smarte kontrakten

De tre vanligste misforståelsene for smarte kontrakter

Som utviklere av en populær blockchain-plattform blir vi noen ganger spurt om Ethereum-lignende smarte kontrakter er på multikate veikart. Svaret jeg alltid gir er: nei, eller i det minste ikke ennå.

Men i den hypefylte verdenen av blokkjeder er smarte kontrakter raseri, så hvorfor ikke? Vel, problemet er at mens vi nå vet om tre sterke bruksområder for tillatte Bitcoin-stil blokkjeder (herkomst, virksomhetsregistreringer og lettvektsfinansiering), har vi ennå ikke funnet tilsvarende for smarte kontrakter i Ethereum-stil.

Det er ikke slik at folk mangler ideer om hva de vil at smarte kontrakter skal gjøre. Snarere er det så mange av disse ideene er rett og slett umulig. Ser du, når smarte mennesker hører begrepet "smarte kontrakter", har fantasien deres en tendens til å løpe vilt. De fremkaller drømmer om autonom intelligent programvare, som går ut i verden og tar med seg dataene på turen.

Dessverre er virkeligheten av smarte kontrakter langt mer verdslig enn alt det:

En smart kontrakt er et stykke kode som er lagret på en blockchain, utløst av blockchain-transaksjoner, og som leser og skriver data i blockchain-databasen.

Det er det. Egentlig. En smart kontrakt er bare et fancy navn for kode som kjører på en blockchain, og samhandler med blockchainens tilstand. Og hva is kode? Det er Pascal, det er Python, det er PHP. Det er Java, det er Fortran, det er C ++. Hvis vi snakker databaser, er det det lagrede prosedyrer skrevet i en utvidelse av SQL. Alle disse språkene er i utgangspunktet likeverdige, og løser de samme slags problemer på samme slags måter. Selvfølgelig har hver sin styrke og svakhet - du vil være gal for å bygge et nettsted i C eller komprimere HD-video i Ruby. Men i prinsippet i det minste kunne du det hvis du ville. Du vil bare betale en høy pris når det gjelder bekvemmelighet, ytelse og sannsynligvis håret ditt.

Problemet med smarte kontrakter er ikke bare at folks forventninger er overblåst. Det er at disse forventningene fører til at mange bruker tid og penger på ideer som umulig kan implementeres. Det ser ut til at store selskaper har tilstrekkelige ressurser til å reise en lang vei - fra øyeblikket når toppledelsen møter en ny teknologi, til når teknologiens fordeler og begrensninger virkelig er forstått. Kanskje vår egen erfaring kan bidra til å forkorte denne gangen.

I løpet av de siste ni månedene har vi hatt mange smarte kontraktsbrukstilfeller, og vi har svart på oss om og om igjen, at de rett og slett ikke kan gjøres. Som et resultat har vi identifisert de tre misforståelsene om smarte kontrakter som oftest holdes. Disse ideene er ikke feil fordi teknologien er umoden, eller verktøyene ennå ikke er tilgjengelige. Snarere misforstår de grunnleggende egenskaper til kode som lever i en database og kjører på en desentralisert måte.

Kontakt eksterne tjenester

Ofte er den første brukssaken som er foreslått, en smart kontrakt som endrer oppførselen som svar på noen eksterne hendelser. For eksempel en landbruksforsikring som betaler ut betinget basert på mengden nedbør i en gitt måned. Den forestilte prosessen går omtrent slik: den smarte kontrakten venter til den forutbestemte tiden, henter værmeldingen fra en ekstern tjeneste og oppfører seg hensiktsmessig basert på mottatte data.

Alt dette høres enkelt nok ut, men det er også umulig. Hvorfor? Fordi en blockchain er et konsensusbasert system, noe som betyr at det bare fungerer hvis hver node når en identisk tilstand etter å ha behandlet hver transaksjon og blokk. Alt som foregår på en blockchain må være helt deterministisk, uten mulig måte for forskjeller å krype inn i. I det øyeblikket to ærlige noder er uenige om kjedens tilstand, blir hele systemet verdiløst.

Husk nå at smarte kontrakter utføres uavhengig av hver node i en kjede. Derfor, hvis en smart kontrakt henter noe informasjon fra en ekstern kilde, blir denne hentingen utført gjentatte ganger og separat av hver node. Men fordi denne kilden er utenfor blockchain, det er ingen garanti for at hver node vil motta det samme svaret. Kanskje vil kilden endre svaret i tiden mellom forespørsler fra forskjellige noder, eller kanskje blir det midlertidig utilgjengelig. Uansett brytes konsensus og hele blockchain dør.

Så hva er løsningen? Egentlig er det ganske enkelt. I stedet for en smart kontrakt som innleder henting av eksterne data, oppretter en eller flere pålitelige parter (“orakler”) en transaksjon som innebærer disse dataene i kjeden. Hver node vil ha en identisk kopi av disse dataene, slik at de kan brukes trygt i en smart kontraktberegning. Med andre ord et orakel skyver dataene på blockchain i stedet for en smart kontrakt trekke det i.

Når det gjelder smarte kontrakter som forårsaker hendelser i omverdenen, vises et lignende problem. For eksempel liker mange ideen om en smart kontrakt som kaller en banks API for å overføre penger. Men hvis hver node uavhengig kjører koden i kjeden, hvem er da ansvarlig for å kalle dette API? Hvis svaret bare er en node, hva skjer hvis den aktuelle noden ikke fungerer som den skal, bevisst eller ikke? Og hvis svaret er hver node, kan vi stole på hver node med API-passordet? Og vil vi virkelig at API-et kalles hundrevis av ganger? Enda verre, hvis den smarte kontrakten trenger å vite om API-samtalen var vellykket, er vi tilbake til problemet med avhengig av eksterne data.

Som før er en enkel løsning tilgjengelig. I stedet for at den smarte kontrakten kaller et eksternt API, bruker vi en pålitelig tjeneste som overvåker blockchain-tilstanden og utfører visse handlinger som svar. For eksempel kan en bank proaktivt se på en blockchain og utføre pengeoverføringer som speiler transaksjonene i kjeden. Dette gir ingen risiko for blockchain-konsensus fordi kjeden spiller en helt passiv rolle.

Når vi ser på disse to løsningene, kan vi gjøre noen observasjoner. For det første krever de begge en pålitelig enhet for å administrere samspillet mellom blockchain og omverdenen. Selv om dette er teknisk mulig, undergraver det målet om et desentralisert system. For det andre er mekanismene som brukes i disse løsningene, enkle eksempler på lese og skrive en database. Et orakel som gir ekstern informasjon er ganske enkelt å skrive informasjonen inn i kjeden. Og en tjeneste som speiler blockchain-tilstanden i den virkelige verden, gjør ingenting mer enn å lese fra den kjeden. Med andre ord er enhver interaksjon mellom en blockchain og omverdenen begrenset til vanlig databasedrift. Vi vil snakke mer om dette faktum senere.

Håndheve betalinger via kjeden

Her er et annet forslag som vi pleier å høre mye om: ved hjelp av en smart kontrakt for å automatisere betaling av kuponger for en såkalt “smart bond”. Tanken er at den smarte kontraktskoden automatisk starter betalingene til passende tidspunkter, og man unngår manuelle prosesser og garanterer at utsteder ikke kan misligholde.

Selvfølgelig, for at dette skal fungere, må midlene som brukes til å utføre betalingene også bo i blockchain, ellers kan en smart kontrakt umulig garantere betalingen deres. Husk nå at en blockchain bare er en database, i dette tilfellet en finansiell reskontro som inneholder den utstedte obligasjonen og litt kontanter. Så når vi snakker om kupongbetalinger, er det vi faktisk snakker om, databaseoperasjoner som foregår automatisk til et avtalt tidspunkt.

Selv om denne automatiseringen er teknisk gjennomførbar, lider den av økonomiske vanskeligheter. Hvis midlene som brukes til kupongbetalinger kontrolleres av obligasjonens smarte kontrakt, kan disse betalingene faktisk garanteres. Men dette betyr også disse midlene kan ikke brukes av obligasjonsutstederen til noe annet. Og hvis disse midlene ikke er under kontroll av den smarte kontrakten, da det er ingen måte betalingen kan garanteres på.

Med andre ord er en smart obligasjon enten meningsløs for utstederen, eller meningsløs for investoren. Og hvis du tenker på det, er dette et helt åpenbart resultat. Fra en investors perspektiv er hele poenget med en obligasjon dens attraktive avkastning, på bekostning av en viss risiko for mislighold. Og for utstederen er obligasjonens formål å skaffe midler til en produktiv, men noe risikabel aktivitet, for eksempel å bygge en ny fabrikk. Det er ingen måte for obligasjonsutstederen å bruke de innsamlede midlene, samtidig som det garanteres at investoren blir tilbakebetalt. Det skal ikke komme som en overraskelse at sammenhengen mellom risiko og avkastning er ikke et problem som blokkjeder kan løse.

Skjuler konfidensielle data

Som jeg har skrevet om tidligere, den største utfordringen i å distribuere blockchains er den radikale gjennomsiktigheten de gir. For eksempel, hvis ti banker oppretter en blockchain sammen, og to gjennomfører en bilateral transaksjon, vil dette umiddelbart være synlig for de andre åtte. Selv om det er forskjellige strategier for å redusere dette problemet, slår ingen enkelheten og effektiviteten til en sentralisert database, der en pålitelig administrator har full kontroll over hvem som kan se hva.

Noen mennesker tror at smarte kontrakter kan løse dette problemet. De starter med det faktum at hver smarte kontrakt inneholder sin egen miniatyrdatabase, som den har full kontroll over. Alle lese- og skriveoperasjoner i denne databasen formidles av kontraktens kode, noe som gjør det umulig for en kontrakt å lese en andres data direkte. (Denne stramme koblingen mellom data og kode kalles innkapsling, og er grunnlaget for det populære Objektorientert programmering paradigme.)

Så hvis en smart kontrakt ikke får tilgang til andres data, har vi løst problemet med blockchain-konfidensialitet? Er det fornuftig å snakke om å skjule informasjon i en smart kontrakt? Dessverre er svaret nei. For selv om en smart kontrakt ikke kan lese andres data, lagres disse dataene fortsatt på hver eneste node i kjeden. For hver blockchain-deltaker er den i minnet eller disken til en systemet som deltakeren fullstendig kontrollerer. Og det er ingenting som hindrer dem i å lese informasjonen fra sitt eget system, hvis og når de velger å gjøre det.

Å skjule data i en smart kontrakt er omtrent like sikker som å skjule dem i HTML-koden til en webside. Visst, vanlige nettbrukere vil ikke se det, fordi det ikke vises i nettleservinduet. Men alt som trengs er at en nettleser legger til en 'View Source' -funksjon (som de alle har), og den skjulte informasjonen blir synlig overalt. På samme måte, for data som er skjult i smarte kontrakter, er alt som trengs for noen å modifisere blockchain-programvaren for å vise kontraktens fulle tilstand, og all skinn av hemmelighold går tapt. En halvt anstendig programmerer kan gjøre det om en time eller så.

Hva smarte kontrakter er for

Med så mange ting som smarte kontrakter ikke kan gjøre, kan man spørre hva de egentlig er for. Men for å svare på dette spørsmålet, må vi gå tilbake til det grunnleggende ved selve blokkjedene. For å oppsummere, gjør en blockchain det mulig å dele en database direkte og trygt av enheter som ikke stoler på hverandre uten å kreve en sentral administrator. Blokkjeder muliggjør disintermediering av data, og dette kan føre til betydelige besparelser i kompleksitet og kostnader.

Enhver database endres via "transaksjoner", som inneholder et sett med endringer i databasen som må lykkes eller mislykkes som en helhet. For eksempel, i en finansregnskap, er en betaling fra Alice til Bob representert av en transaksjon som (a) sjekker om Alice har tilstrekkelige midler, (b) trekker et beløp fra Alice sin konto, og (c) legger til samme mengde til Bobs .

I en vanlig sentralisert database opprettes disse transaksjonene av en pålitelig autoritet. I kontrast, i en blockchain-drevet delt database, kan transaksjoner opprettes av noen av blockchain-brukerne. Og siden disse brukerne ikke helt stoler på hverandre, må databasen inneholde regler som begrenser transaksjonene som utføres. For eksempel, i en peer-to-peer finanshovedbok, må hver transaksjon bevare den totale mengden midler, ellers kunne deltakerne fritt gi seg så mye penger de ønsket.

Man kan forestille seg forskjellige måter å uttrykke disse reglene på, men foreløpig er det to dominerende paradigmer, inspirert av henholdsvis Bitcoin og Ethereum. Bitcoin-metoden, som vi kan kalle "transaksjonsbegrensninger", evaluerer hver transaksjon i form av: (a) databaseoppføringene slettet av den transaksjonen, og (b) oppføringene. I en finansregister angir regelen at den totale mengden midler i de slettede oppføringene må samsvare med summen i de opprettet. (Vi anser endringen av en eksisterende oppføring som å slette den oppføringen og opprette en ny i stedet.)

Det andre paradigmet, som kommer fra Ethereum, er smarte kontrakter. Dette sier at alle modifikasjoner av kontraktsdataene må utføres av koden. (I sammenheng med tradisjonelle databaser kan vi tenke på dette som en håndheves lagret prosedyre.) For å endre dataene til en kontrakt, sender blockchain-brukere forespørsler til koden, som bestemmer om og hvordan du skal oppfylle disse forespørslene. Som i dette eksemplet, den smarte kontrakten for en finansiell hovedbok utfører de samme tre oppgavene som administratoren av en sentralisert database: å sjekke tilstrekkelig med midler, trekke fra en konto og legge til en annen.

Begge disse paradigmene er effektive, og hver har sine fordeler og ulemper, som jeg har gjort diskutert i dybden tidligere. For å oppsummere gir transaksjonsbegrensninger i Bitcoin-stil overlegen samtidighet og ytelse, mens smarte kontrakter i Ethereum-stil gir større fleksibilitet. Så for å gå tilbake til spørsmålet om hva smarte kontrakter er for:

Smarte kontrakter er for blockchain-brukstilfeller som ikke kan implementeres med transaksjonsbegrensninger.

Gitt dette kriteriet for bruk av smarte kontrakter, har jeg ennå ikke sett en sterk brukstilfelle for tillatte blokkjeder som kvalifiserer. Alle de overbevisende blockchain-applikasjonene jeg kjenner, kan implementeres med Bitcoin-stil-transaksjoner, som kan håndtere tillatelse og generell datalagring, samt oppretting av eiendeler, overføring, sperring, utveksling og ødeleggelse. Likevel dukker det fortsatt opp nye brukssaker, og jeg vil ikke bli overrasket om noen do krever kraften til smarte kontrakter. Eller i det minste en utvidelse av Bitcoin-paradigmet.

Uansett hva svaret viser seg å være, er nøkkelen til å huske at smarte kontrakter bare er en metode for å begrense transaksjonene som utføres i en database. Dette er utvilsomt en nyttig ting, og er viktig for å gjøre databasen trygg for deling. Men smarte kontrakter kan ikke gjøre noe annet, og de kan absolutt ikke unnslippe grensene for databasen der de ligger.

Legg inn kommentarer på LinkedIn.