Mange af de koncepter, som vi promoverer i Ethereum-land kan til tider virke utrolig futuristisk og måske endda skræmmende. Vi taler om såkaldte “smarte kontrakter”, der udfører sig selv uden behov eller nogen mulighed for menneskelig indblanding eller involvering, mennesker, der danner Skynet-lignende “decentraliserede autonome organisationer”, der lever udelukkende i skyen og alligevel styrer stærke økonomiske ressourcer og kan tilskynde folk til at gøre meget rigtige ting i den fysiske verden, decentraliseret “matematikbaseret lov” og en tilsyneladende utopisk søgen efter at skabe en form for fuldt tillidsfrit samfund. For den uinformerede bruger og især dem, der ikke engang har hørt om almindelig gammel Bitcoin, kan det være svært at se, hvordan denne slags ting er mulige, og om det er grunden til, at de muligvis kan være ønskelige. Formålet med denne serie vil være at dissekere disse ideer i detaljer og vise nøjagtigt, hvad vi mener med hver enkelt, diskutere dens egenskaber, fordele og begrænsninger.

Den første del af serien vil tale om såkaldte “smarte kontrakter”. Smarte kontrakter er en idé, der har eksisteret i flere årtier, men fik sit nuværende navn og først væsentligt bragt til den (kryptografisk tilbøjelige) offentlighedens opmærksomhed af Nick Szabo i 2005. Definitionen af ​​en smart kontrakt er i det væsentlige enkel: en smart kontrakt er en kontrakt, der håndhæver sig selv. Det vil sige, hvorimod en almindelig kontrakt er et stykke papir (eller for nylig PDF-dokument), der indeholder tekst, der implicit beder en dommer om at beordre en part til at sende penge (eller anden ejendom) til en anden part under visse betingelser, en smart kontrakt er et computerprogram, der kan køres på hardware, der automatisk udfører disse betingelser. Nick Szabo bruger eksemplet på en automat:

Et kanonisk eksempel fra det virkelige liv, som vi måske anser for at være den primitive forfader til smarte kontrakter, er den ydmyge automat. Inden for en begrænset mængde potentielt tab (beløbet i kassaskabet skal være mindre end omkostningerne ved at overtræde mekanismen) tager maskinen mønter ind og via en simpel mekanisme, der gør et nybegynder datalogisk problem i design med endelig automat, dispenseringsændring og produkt i henhold til den viste pris. Automaten er en kontrakt med indehaveren: Enhver med mønter kan deltage i en udveksling med sælgeren. Låsekassen og andre sikkerhedsmekanismer beskytter de gemte mønter og indhold mod angribere, tilstrækkeligt til at muliggøre lønsom anvendelse af automater i en lang række områder.

Smarte kontrakter er anvendelsen af ​​dette koncept på, ja, mange ting. Vi kan have smarte finansielle kontrakter, der automatisk blander penge ud fra visse formler og betingelser, smarte domænenavns salgsordrer, der giver domænet til den, der først sender $ 200, måske endda smarte forsikringskontrakter, der styrer bankkonti og automatisk udbetaler baseret på nogle betroet kilde (eller kombination af kilder), der leverer data om begivenheder i den virkelige verden.

Smart ejendom

På dette tidspunkt opstår der dog et indlysende spørgsmål: hvordan skal disse kontrakter håndhæves? Ligesom traditionelle kontrakter, som ikke er værd at papiret, de er skrevet på, medmindre der er en egentlig dommer bakket op af juridisk magt, der håndhæver dem, skal smarte kontrakter “sættes i” noget system for faktisk at have magt til at gøre noget. Den mest oplagte og ældste løsning er hardware, en idé, der også går under navnet “smart property”. Nick Szabos salgsautomat er det kanoniske eksempel her. Inde i automaten er der en slags proto-smart-kontrakt, der indeholder et sæt computerkode, der ser sådan ud:

hvis knap_trykt == "Coca Cola" og penge_indsat >= 1,75: frigivelse ("Coca Cola") return_change (money_inserted – 1.75) ellers hvis button_pressed == "Aquafina vand" og penge_indsat >= 1,25: frigivelse ("Aquafina vand") return_change (money_inserted – 1.25) ellers hvis…

Kontrakten har fire “kroge” ind i omverdenen: de knap_trykte og penge-indsatte variabler som input, og frigivelse og return_change-kommandoer som output. Alle disse fire afhænger af hardware, selvom vi fokuserer på de sidste tre, fordi menneskelig input generelt betragtes som et trivielt problem. Hvis kontrakten kørte på en Android-telefon fra 2007, ville den være ubrugelig; Android-telefonen har ingen måde at vide, hvor mange penge der blev indsat i en slot, og kan bestemt ikke frigive Coca Cola-flasker eller returnere ændringer. På en salgsautomat på den anden side bærer kontrakten en eller anden “kraft”, bakket op af automatens interne Coca Cola-beholdninger og dens fysiske sikkerhed, der forhindrer folk i at tage Coca Cola uden at følge kontraktens regler.

En anden, mere futuristisk anvendelse af smart ejendom er udlejningsbiler: forestil dig en verden, hvor alle har deres egen private nøgle på en smartphone, og der er en sådan bil, at når du betaler $ 100 til en bestemt adresse, begynder bilen automatisk at svare på kommandoer underskrevet af din private nøgle i en dag. Det samme princip kan også anvendes på huse. Hvis det lyder langtrukket, skal du huske på, at kontorbygninger i det store og hele allerede er en smart ejendom: adgang styres af adgangskort, og spørgsmålet om, hvilke (hvis nogen) døre, hvert kort er gyldigt til, bestemmes af et stykke kode, der er knyttet til en database. Og hvis virksomheden har et HR-system, der automatisk behandler ansættelseskontrakter og aktiverer nye medarbejderes adgangskort, så er den ansættelseskontrakt i en mindre grad en smart kontrakt.

Smart Money and Factum Society

Imidlertid er fysisk ejendom meget begrænset i, hvad den kan gøre. Fysisk ejendom har en begrænset sikkerhed, så du kan praktisk talt ikke gøre noget interessant med mere end et par titusindvis af dollars med en opsætning af smart-ejendom. Og i sidste ende involverer de mest interessante kontrakter overførsel af penge. Men hvordan kan vi faktisk få det til at fungere? Lige nu kan vi stort set ikke. Vi kan teoretisk give kontrakter loginoplysningerne til vores bankkonti og derefter få kontrakten til at sende penge under visse betingelser, men problemet er, at denne form for kontrakt ikke rigtig er “selvforvaltende”. Den part, der indgår kontrakten, kan altid bare slå kontrakten fra lige før betaling forfalder, eller dræne deres bankkonto eller endda blot ændre adgangskoden til kontoen. I sidste ende, uanset hvordan kontrakten er integreret i systemet, har nogen evnen til at lukke den.

Hvordan kan vi løse problemet? I sidste ende er svaret et, der er radikalt i sammenhæng med vores bredere samfund, men allerede meget gamle nyheder i Bitcoins verden: vi har brug for en ny type penge. Indtil videre har udviklingen af ​​penge fulgt tre faser: råvarepenge, handelsstøttede penge og fiat-penge. Råvarepenge er enkle: det er penge, der er værdifulde, fordi de også samtidig er en vare, der har en vis “iboende” brugsværdi. Sølv og guld er perfekte eksempler, og i mere traditionelle samfund har vi også te, salt (etymologi bemærkning: det er her ordet “løn” kommer fra), muslingeskaller og lignende. Derefter kom varestøttede penge – banker, der udsteder certifikater, der er værdifulde, fordi de kan indløses til guld. Endelig har vi fiat-penge. “Fiat” i “fiat money” er ligesom i “fiat money”fiat lux“, Undtagen i stedet for at Gud siger” lad der være lys “, er det den føderale regering, der siger” lad der være penge “. Pengene har værdi i vid udstrækning, fordi regeringen, der udsteder dem, accepterer disse penge, og kun disse penge, som betaling for skatter og afgifter sammen med flere andre juridiske privilegier.

Med Bitcoin har vi dog en ny type penge: faktum penge. Forskellen mellem fiat-penge og factum-penge er denne: mens fiat-penge oprettes og vedligeholdes af en regering (eller teoretisk en anden form for agentur), der producerer dem, er faktiske penge bare. Faktapenge er simpelthen en balance med et par regler for, hvordan denne balance kan opdateres, og at pengene er gyldige blandt det sæt brugere, der beslutter at acceptere det. Bitcoin er det første eksempel, men der er flere. For eksempel kan man have en alternativ regel, der siger, at kun bitcoins, der kommer ud af en bestemt “genese-transaktion”, tæller som en del af balancen; dette kaldes “farvede mønter”, og er også en slags factum-penge (medmindre disse farvede mønter er fiat- eller varestøttede).

Faktisk er det vigtigste løfte om faktapenge netop det faktum, at de passer så godt sammen med smarte kontrakter. Hovedproblemet med smarte kontrakter er håndhævelse: Hvis en kontrakt siger at sende $ 200 til Bob, hvis X sker, og X sker, hvordan kan vi sikre, at $ 200 faktisk bliver sendt til Bob. Løsningen med faktapenge er utrolig elegant: definitionen af ​​pengene eller mere præcist definitionen af ​​den nuværende balance er resultatet af gennemførelsen af ​​alle kontrakterne. Således, hvis X sker, så er alle enige om, at Bob har de ekstra $ 200, og hvis X ikke sker, er alle enige om, at Bob har, hvad Bob havde før.

Dette er faktisk en meget mere revolutionerende udvikling, end du måske tror i starten; med faktapenge har vi skabt en måde for kontrakter og måske endda lov generelt til at arbejde og være effektive uden at stole på nogen form for mekanisme overhovedet til at håndhæve dem. Ønsker du en bøde på $ 100 til affald? Definer derefter en valuta, så du har 100 enheder mindre, hvis du affald, og overbevis folk om at acceptere den. Det specifikke eksempel er nu meget fjernet og sandsynligvis upraktisk uden nogle få store forbehold, som vi vil diskutere nedenfor, men det viser det generelle princip, og der er mange mere moderate eksempler på denne slags princip, der helt sikkert kan sættes til arbejde.

Hvor smart er smarte kontrakter?

Smarte kontrakter er naturligvis meget effektive til enhver form for økonomiske applikationer eller mere generelt enhver form for swaps mellem to forskellige faktumaktiver. Et eksempel er et salg af domænenavne; et domæne, som google.com, er et factum-aktiv, da det understøttes af en database på en server, der kun har nogen vægt, fordi vi accepterer det, og penge kan naturligvis også være factum. Lige nu er salg af et domæne en kompliceret proces, der ofte kræver specialiserede tjenester; i fremtiden kan du muligvis pakke et salgstilbud ind i en smart kontrakt og lægge det på blockchain, og hvis nogen tager det, vil begge sider af handlen ske automatisk – ingen mulighed for bedrageri involveret. Når man går tilbage til en verden af ​​valutaer, er decentral udveksling et andet eksempel, og vi kan også lave finansielle kontrakter såsom afdækning og gearing.

Der er dog steder, hvor smarte kontrakter ikke er så gode. Overvej for eksempel tilfældet med en ansættelseskontrakt: A accepterer at udføre en bestemt opgave for B til gengæld for betaling af X-enheder i valuta C. Betalingsdelen er let at smart-kontrakt-ify. Der er dog en del, der ikke er så let: at kontrollere, at arbejdet faktisk fandt sted. Hvis arbejdet er i den fysiske verden, er dette stort set umuligt, da blockchains ikke har nogen måde at få adgang til den fysiske verden på. Selvom det er et websted, er der stadig spørgsmålet om kvalitetsvurdering, og selvom computerprogrammer i visse tilfælde kan bruge maskinindlæringsalgoritmer til at bedømme sådanne egenskaber ganske effektivt, er det utroligt svært at gøre det i en offentlig kontrakt uden at åbne døren for medarbejdere “spiller systemet”. Nogle gange er et samfund styret af algoritmer bare ikke helt godt nok.

Heldigvis er der en moderat løsning, der kan fange det bedste fra begge verdener: dommere. En dommer i en almindelig domstol har i det væsentlige ubegrænset magt til at gøre, hvad de vil, og dømmeprocessen har ikke en særlig god grænseflade; folk er nødt til at indgive en sag, vente et betydeligt stykke tid på en retssag, og dommeren træffer til sidst en beslutning, der håndhæves af det juridiske system – i sig selv ikke et eksempel på lynhurtig effektivitet. Privat voldgift formår ofte at være billigere og hurtigere end domstole, men selv der er problemerne stadig de samme. Dommere i en faktumverden er derimod meget forskellige. En smart kontrakt for ansættelse kan se sådan ud:

hvis siger (B,"A gjorde jobbet") eller siger (J,"A gjorde jobbet"): send (200, A) ellers hvis siger (A.,"A gjorde ikke jobbet") eller siger (J,"A gjorde ikke jobbet"): send (200, B)

siger er en signaturverifikationsalgoritme; siger (P, T) kontrollerer grundlæggende, om nogen havde sendt en besked med teksten T og en digital signatur, der verificerer ved hjælp af P’s offentlige nøgle. Så hvordan fungerer denne kontrakt? For det første ville arbejdsgiveren sende 200 valutaenheder ind i kontrakten, hvor de sad i deponering. I de fleste tilfælde er arbejdsgiveren og medarbejderen ærlige, så enten A afslutter og frigiver midlerne tilbage til B ved at underskrive en besked, der siger “A gjorde ikke jobbet” eller A gør jobbet, B verificerer, at A gjorde jobbet, og kontrakten frigiver midlerne til A. Men hvis A gør jobbet, og B er uenig, er det op til at dømme J at sige, at enten A gjorde jobbet eller A ikke gjorde jobbet.

Bemærk, at Js magt er meget omhyggeligt afgrænset; alt, hvad J har ret til, er at sige, at enten A gjorde jobbet eller A ikke gjorde jobbet. En mere sofistikeret kontrakt kan også give J ret til at afsige domme inden for området mellem de to ekstremer. J har ikke ret til at sige, at A faktisk fortjener 600 valutaenheder, eller at forresten hele forholdet er ulovligt, og J skulle få de 200 enheder eller noget andet uden for de klart definerede grænser. Og J’s magt håndhæves af factum – kontrakten indeholder Js offentlige nøgle, og dermed går midlerne automatisk til A eller B baseret på grænserne. Kontrakten kan endda kræve beskeder fra 2 ud af 3 dommere, eller den kan have separate dommere til at bedømme separate aspekter af arbejdet og få kontrakten automatisk til at give B’s arbejde en kvalitetsscore baseret på disse vurderinger. Enhver kontrakt kan simpelthen tilslutte en hvilken som helst dommer på nøjagtigt den måde, de ønsker, hvad enten det er at bedømme sandheden eller usandheden ved en bestemt kendsgerning, give en måling af en variabel eller være en af ​​parterne, der letter arrangementet.

Hvordan vil dette være bedre end det nuværende system? Kort sagt, hvad dette introducerer er “dommere som en tjeneste”. For at blive en “dommer” skal du nu ansættes hos et privat voldgiftsfirma eller en regeringsret eller starte din egen. I et kryptografisk aktiveret faktumretssystem kræver det at være dommer blot at have en offentlig nøgle og en computer med internetadgang. Så kontraintuitivt som det lyder, behøver ikke alle dommere at være fortrolige med loven. Nogle dommere kan specialisere sig i for eksempel at afgøre, om et produkt blev sendt korrekt eller ej (ideelt set ville postsystemet gøre dette). Andre dommere kan kontrollere gennemførelsen af ​​ansættelseskontrakter. Andre ville vurdere skader i forbindelse med forsikringskontrakter. Det ville være op til kontraktforfatteren at tilslutte dommere af hver type på de relevante steder i kontrakten, og den del af kontrakten, der kan defineres rent i computerkode, vil være.

Og det er alt der er ved det.

Den næste del af denne serie vil tale om begrebet tillid, og hvad kryptografer og Bitcoin-fortalere virkelig betyder, når de taler om at opbygge et “tillidsfrit” samfund.