Smart Contracts Session 6 Transcript
Den næste casestudie vedrører forsikringskontrakter.
Hvorfor vælger vi forsikringskontrakter til denne casestudie?
Nå, de falder lige i spanden af den slags juridiske forhold, der har, hvis dette så
den egenskab.
Så hvis vi ser på et eksempel, forsikringskontrakter, kan det være noget, som en landmand ønsker
forsikre.
Hvis der mangler nedbør i en bestemt måned, kan det være skadeligt for udbyttet i en afgrøde.
Og landmanden kan derfor lide økonomisk tab, fordi afgrødeudbyttet ikke er, som de havde forventet.
Et forsikringsselskab er parat til at tage denne risiko.
De har data om mængden af nedbør på det sted i den periode og sporer tilbage over mange,
mange år.
Så de kan analysere denne risiko.
Landmanden er i stand til at udføre den samme analyse, men der køres så meget fra landmandens perspektiv
at landmanden ikke ønsker at tage risikoen for, at der vil være regn, ni år ud af 10
afgrøder vil vokse, og der vil være et godt udbytte.
Forsikringsselskabet har en stor portefølje med lignende risiko, så de skriver forsikring for landmænd i hele landet
hele landet.
Og de stoler på, at hvis der er mindre nedbør ét sted, vil det ikke være mindre nedbør
et andet sted.
Så de får præmier fra alle landmændene, og de udbetaler kun i et lille antal tilfælde.
Det kan automatiseres, fordi vi har et meget simpelt binært økonomisk forhold.
Forsikringsselskabet er enig.
Hvis det ikke regner i løbet af denne måned, foretager det en betaling.
Landmanden indvilliger i, at landmanden betaler en præmie for at købe forsikringen på forhånd.
Og hvis der ikke er regn i denne periode, modtager de en betaling i henhold til forsikringskontrakten
lig med der.
Og forsikringsselskaberne blev enige om et skøn over tabet.
Så vi har det.
Hvis dette, så hvis der ikke regner, så vil der være en betaling.
Og den måde, hvorpå disse nu fungerer gennem smarte kontrakter, er fordi felterne i området i
spørgsmål kan have sensorer og regnsamlere monteret i dem, og sensorerne bestemmer automatisk
hvis der er regn.
Så hvis de opdager nedbør, vil de sende en instruktion tilbage til forsikringsselskabet om at sige
ingen betaling krævet i henhold til denne kontrakt, hvis hele måneden går uden regn.
Derefter vil instruktionen i slutningen af måneden ikke være regn.
Foretag denne overførsel til landmandens konto med hensyn til den forsikrede risiko.
Så det er et godt eksempel på, hvor vi kan finde automatisering i almindelig kontraktlevetid.
Og det er generelt, hvor folk ser på smarte kontrakter og prøver at finde de brugssager, der
se ud, hvis dette så er der også transaktioner med et revisionsaspekt.
Så vi sagde, at vi stadig er nødt til, i dette tilfælde, en forsikringskontrakt, der hovedsagelig er skrevet.
Et af vilkårene for det er blevet konverteret til kode.
Hvis dette, så hvis der ikke er regn, skete overførslen, de næste faser i udviklingen af disse
slags smarte kontrakter er, at de bestemmelser, der siger, om dette, så vil de forsvinde fra
kontrakten og erstattes simpelthen med en henvisning til koden.
Så vi har i øjeblikket to ting, der sidder ved siden af hinanden.
Du har kontrakten, der siger, at hvis dette, så har du koden, der siger, hvis dette, så det.
Men de er adskilte.
Og hvis der er nogle menneskelige fejl, og de er skrevet i lidt forskellige termer, hvilken vinder,
hvilken der hersker?
I øjeblikket vil domstolene se på aftalen mellem parterne om at fortælle dem, hvad der hersker.
Siger aftalen følge skrivningen af en kontrakt?
Eller siger det, at vi udsætter koden i øjeblikket, for de fleste kontrakter gennemgås heller ikke af advokater
i advokatfirmaer eller inden i virksomheder?
Forsikringsselskaber siger, at den første kiggede på sproget, men en af de ting, vi ser
at udvikle sig gennem denne historie med smarte kontrakter er fordelene ved effektiviteten ved at stole på
kode bliver bedre forstået.
Domstolene anerkender, at de kan blive bedt om at støtte koden i skrivende stund og parterne
begynder at blive mere sikre på, at da de tidlige brugssager fungerer, hvorfor har vi teksten?
Skrivningen kan være en guide til, hvad parterne agter at blive enige om.
Men disse aftaler kan indbygges i selve koden.
Så intelligente kontrakter reviderer grunden til at hæve det, medmindre du er softwareudvikler, hvis du er
stole på koden og ikke kontrakten, koden er kontrakten.
Skrivningen er baggrunden for kontrakten.
Hvis du er udvikler, kan du læse det.
Du kan teste det.
Du kan kontrollere det, hvis vi er en normal kommerciel fest.
Du kan ikke sige, at du har et krav om, at en udvikler foretager en slags revision, ofte med en advokat,
for at sikre, at koden siger nøjagtigt, hvad kontrakten har til hensigt at sige.
Kontrakten her er simpelthen kort form for parternes hensigt.
Så vi skubber parternes intention ud af skrivning og interesse i koden.
Det er den kritiske udvikling, som vi ser i øjeblikket.
Og der er et åbent spørgsmål i det juridiske samfund.
Advokaterne skal lære at kode.
Nå, ikke rigtig, for der er mennesker, der lever det.
Men advokater har brug for at være i stand til at støtte disse smarte kontraktrevisioner og forstå, hvad det er, det er
bliver oversat fra at skrive til softwaren og være i stand til at kommunikere klart og uden
tvetydighed med softwareudviklerne.
Sig det punkt, at vi havde et par dias siden.
Vi har forskellige forståelser for, hvad en smart kontrakt er mellem advokater og kodere kan se her
ganske uheldigt det er.
Vi kommer til en position, hvor de to grupper skal arbejde hånd i hånd, virkelig forståelse
hinanden.
For kun kort tid siden kom vi fra en helt anden sag, hvor vi endda brugte de samme ord til
betyder forskellige ting.
Igen har stor udvikling fundet sted i løbet af de sidste et eller to år og vil fortsætte med at udvikle sig
at advokater og kodere bliver nødt til at arbejde sammen og overholde mennesker og risikostyrere
og revisorer og alle de mennesker, der er i dette samfund omkring økonomiske transaktioner.