DAML – Et open source-økosystem for å bygge smarte kontraktbaserte distribuerte applikasjoner

DAML er et åpen kildekode-økosystem for å bygge distribuerte applikasjoner med full stack-smarte kontraktsbaserte applikasjoner. Dens kjerne smarte kontraktspråk er et spesialbygget funksjonelt språk som er spesialisert på å beskrive komponiserbare distribuerte forretningsarbeidsflyter. DAMLs unike salgsargument er enkelt – fokuser helt på applikasjonslogikken uten å bekymre deg for den underliggende infrastrukturen, det være seg den distribuerte hovedboken, blockchain eller databasen. Før vi går inn i DAML, la oss få en rask forståelse av dens underliggende teknologi og smarte kontrakter.

Ledgers, Blockchain og Smart Contracts

En hovedbok er en tidsstemplet serie med uforanderlige dataposter. Blockchain er den mest kjente typen distribuert hovedbok, en som administreres av et konsortium av datamaskiner og ikke eies av en enkelt enhet. I en blokkjede pakkes hovedbokoppføringer i en sekvens av blokker, og hver blokk med oppføringer er sikret og bundet til den forrige via kryptografiske prinsipper. Tre egenskaper gjør blockchain veldig spesiell:

  • Distribuert: Blockchain er vert for et peer-to-peer-nettverk. Hver node i dette nettverket laster ned og vedlikeholder en kopi av blockchain i systemet. Dette sikrer at alle dataene som er lagret i blockchain deles av alle og ikke lagres av en enkelt, sentral enhet i systemet.
  • Åpenhet: Siden hver node i nettverket lagrer en versjon av blockchain, kan de alle se dataene som er lagret i dem. Som sådan er all data i blockchain gjennomsiktig.
  • Uforanderlighet: En annen spennende ting å huske her er at når noe er skrevet inn i blokken, kan det ikke tukles med det. Denne egenskapen til blockchain kalles “uforanderlighet.”

Som du kanskje allerede vet, ble blockchain-teknologi kjent som Bitcoin. Dette var en oppfinnelse som var så revolusjonerende at folk begynte å lure på om det finnes et sett med tilstøtende, bredere teknologier utover tillitsfull verdioverføring. Ethereum stormet til slutt inn i kryptomarkedet og introduserte verden for “smarte kontrakter” som var fleksible nok til å skrive hele distribuerte applikasjoner, eller dApps støttet av en blockchain. 

Smarte kontrakter – Å bringe blockchain til massene

Tenk på hva en kontrakt er og hvordan den fungerer i tradisjonell forstand. En kontrakt er et juridisk bindende dokument mellom to parter som også er rettskraftig. En smart kontrakt fungerer på samme måte, bortsett fra to modifiserende spillendringer – reglene som er definert i kontrakten er maskinlesbare og kjørbare, og de håndheves ved hjelp av et distribuert datasystem uten at noen av kontraktspartene har nok kontroll til å overstyre den alene.

For å gi deg en riktig definisjon – En smart kontrakt er en digital avtale som skal lette, verifisere eller håndheve forhandlingene eller gjennomføringen av en kontrakt. Det tillater flere parter å gjøre det ved å direkte samhandle med hverandre, uten å gå gjennom en tredjepart.

Begrepet “smart kontrakt” ble laget av kryptograf Nick Szabo tilbake på 90-tallet i sin artikkel “Smarte kontrakter: Byggesteiner for digitale markeder.”For å forstå filosofien bak hvordan de fungerer, la oss ta Szabos salgsautomateksempel.

Slik kommuniserer du vanligvis med en salgsautomat:

  • Du velger varen du vil ha.
  • Du legger inn litt penger inne i maskinen.
  • Maskinen gir deg varen.

Ganske greit, ikke sant? Imidlertid er det to ting du må merke deg under hele denne interaksjonen:

  • Hvert trinn kan ikke utføres før forrige trinn er oppfylt. F.eks. du kan ikke legge inn pengene før du velger hva du vil. Maskinen kan heller ikke gi deg en vare før du legger inn pengene.
  • I løpet av hele dette samspillet samhandler du og maskinen direkte med hverandre. Det er ingen tredjepart, som en butikkinnehaver, mellom dere to.

Dette er kjerneprinsippene bak smarte kontrakter:

  • De to partene som er bundet i en smart kontrakt, kan direkte samhandle med hverandre.
  • Hvert trinn i en smart kontrakt kan bare oppfylles etter utførelsen av forrige trinn.

Ved å innlemme denne enkle innovasjonen var Ethereum i stand til å lage en protokoll der brukere kunne samhandle direkte med dApps (distribuerte applikasjoner) uten å gå gjennom en tredjepart. Ethereum bruker et språk som heter “Solidity”, for å kode smarte kontrakter. Imidlertid er Ethereum, som de fleste andre populære smarte kontraktplattformer som EOS og TRON, en offentlig blockchain. En offentlig blokkjede har et åpent nettverk, og alle kan bli med uten forbehold. 

Hvis bedrifter skulle bruke blockchains, ville ikke offentlige blockchains alltid passe til brukssakene sine, spesielt hvis de ønsker eller krever at deres interaksjoner er fullt private. Bedrifter trenger en spesiell type blokkjeder kalt “tillatte blokkjeder”. Mer om dem nedenfor. 

Hva kreves av enterprise blockchains?

I motsetning til offentlige blokkjeder er en tillatt / privat blokkjede ikke åpen for alle. For å delta i nettverket, må du skaffe tillatelse til det fra nettverket. Det er noen funksjoner som disse bedriftsblokkjedene må oppfylle:

  • Høy ytelse: For det første vil bedrifter trenge en blockchain som kan behandle store mengder transaksjoner. De fleste offentlige blokkjeder kan ikke engang utføre 100 transaksjoner per sekund konsekvent.
  • Høy motstandskraft: Bedriftsblokkjeder må kunne komme tilbake fra nedetid og potensielle feilscenarier. For å sikre høy tilgjengelighet, må de kunne unngå problemer som kan føre til store avbrudd. For å ha det nivået av motstandsdyktighet, bør systemet anta at feil er nødt til å skje og må være forberedt på å holde systemet i gang i disse situasjonene.
  • Personvernfunksjoner: En offentlig blockchain er per definisjon ikke privat. Institusjoner må håndtere mange konfidensielle data og forskrifter, samt holde visse data klassifisert av konkurransefortrinn og immaterielle rettigheter (det er derfor de trenger et lukket / tillatt miljø i utgangspunktet).

Sammen med et bedriftsvennlig miljø, vil de også kreve spesialiserte smarte kontrakter. Ethereums offentlige smarte kontrakt går på soliditet, men det er spesifikke funksjoner som et bedriftssmart kontraktspråk skal ha. Vi vil diskutere disse egenskapene neste.

Egenskapene til bedriftens smarte kontraktsspråk

Hovedproblemet med vanlige smarte kontraktspråk er at de enten er designet eller inspirert av språk som ble bygget for å utføre mer tradisjonelle systemer. De har en tendens til å være lavt nivå og tett koblet til infrastrukturen de kjører på. Dette gjør dem vanskelige og sakte å programmere. Utviklere har konsekvent opprettet kontrakter med utnyttbare feil, som har forårsaket betydelig skade på kryptoøkosystemet. I 2016 opplevde Ethereum-samfunnet førstehånds hva disse suboptimalt kodede smarte kontraktene kunne gjøre. DAO skulle være den viktigste smarte kontrakten som noen gang er kodet på Ethereum. Imidlertid tillot en enkel bug en hacker å utnytte kontrakten og sippe bort mer enn 150 millioner dollar av Ether. Dette hacket var så ødeleggende at Ethereum-protokollen til slutt ble delt inn i Ethereum og Ethereum Classic.

Hva alt dette i utgangspunktet forteller oss, er at når koding med et språk som Solidity, vil en koder måtte vurdere følgende:

  • Vær forsiktig med angrep som reentrancy, over- og underflow, korte adresseangrep, etc..
  • Hver eneste delstat som kontrakten vil gjennomgå, bør vurderes. 
  • Den samme operasjonen kan bety forskjellige ting på forskjellige språk. For eksempel. mens soliditet låner sterkt fra JavaScript, kan de samme operasjonene virke forskjellig på hvert språk.

Lang historie kort, du kan ikke bare velge et språk tilfeldig og skrive kontraktene dine. Du må forstå alle potensielle konsekvenser du velger. Digital Asset brukte år på å studere smart kontraktsutførelse for å begrense de viktigste egenskapene som kreves av språkene for smarte kontraktsbedrifter:

  • Å inngå en kontrakt må være frivillig. Når alle partene inngår en kontrakt frivillig, blir de forpliktet til å utføre alle handlingene som kreves etter beste evne.
  • Bare partene som er berørt av en kontrakt skal kunne se konsekvensene som påvirker dem (og bare de).
  • Partene skal kunne forutsi med rimelighet hvordan kontrakten vil strekke seg fremover. De skal kunne forutsi alle stater som kontrakten muligens kan ta. 
  • Smarte kontraktutviklere skal kunne bruke et språk som lar dem fokusere helt på sin forretningslogikk, i stedet for detaljer på lavt nivå som hashing, kryptografi og konsensusprotokoller..

Hva er DAML?

DAML er et smart kontraktspråk som er bygget spesielt for distribuerte hovedbøker og muliggjør sikker, utvetydig og høyt nivå spesifisering av forretningslogikk i sanntid. Her er noen viktige ting om DAML som du må huske på:

  • DAML er lett å skrive og lese, slik at en person som forstår virksomheten som defineres, kan bekrefte at koden er justert med intensjonen.
  • DAML er raskt å bygge og distribuere, du kan gå fra null til en slutt-til-slutt-produksjonsapplikasjon ekstremt raskt.
  • Det er et språk for kontrakter, der avtaler og parter er innfødte konstruksjoner i språket.
  • Utviklere vil være i stand til å beskrive hvordan kontrakter blir dannet og hvilke parter som er direkte og indirekte involvert i den.
  • Utviklere trenger ikke å bekymre seg for konstruksjoner på lavt nivå og kan helt fokusere på å skape forretningslogikk.
  • DAML gir høye nivåer av personvern og abstraksjon. DAML-systemet vil automatisk spore partene som har lov til å se detaljene i hver kontrakt. Denne informasjonen vil også bli sendt til den underliggende hovedboken for å sikre at bare dataene en bestemt part er autorisert til å se, faktisk blir sendt til den..
  • Når et DAML-program er utført, skaper det et godt strukturert og menneskelig forståelig revisjonsspor som vil hjelpe deg med å forklare to ting: hvorfor hver handling ble utført og hver parts rolle i den smarte kontrakten.
  • I DAML er oppgraderingene definert i kode og kan utføres på en ikke-forstyrrende måte med null nedetid. Du kan enkelt legge til nye roller og arbeidsflyter i eksisterende løsninger uten å gå gjennom noen komplikasjoner.

DAML – Et funksjonelt språk

I motsetning til imperative språk er DAML et funksjonelt språk. I de kommende avsnittene ser vi på hva dette betyr.

Imperative programmeringsspråk

Tradisjonelle programmeringsspråk som C ++, Java og Solidity er viktige programmeringsspråk. I en viktig programmeringsspråk må utvikler skrive alle instruksjonene som datamaskinen må ta for å nå et mål. La oss ta et eksempel i C ++ på hva vi mener med det. 

Anta at vi vil skrive ut tallene fra 1 til 100 

int i = 0;

neste:

i ++;

printf (“% i”, i);

hvis jeg < 100) gå til neste;

int a = 5;

int b = 3;

int c;

c = a + b;

Som du ser, tar tilleggsprosessen over flere instruksjoner, og hver instruksjon endrer kontinuerlig programtilstanden ettersom de alle blir utført hver for seg..

En tilleggsprosess tok fire instruksjoner, og disse er:

  • Å erklære et heltall “a” og tildele verdien 5 til det.
  • Erklærer et helt tall “b” og tilordner verdien 3 til det.
  • Å erklære et heltall “c.”
  • Legge til verdiene til og b og lagre dem i c.

Funksjonelle programmeringsspråk

I denne programmeringsstilen er det viktigere enn instruksjoner. I stedet for å skrive instruksjoner om hvordan man beregner et resultat eller utfører en algoritme, beskrives ønsket oppførsel som i en vanlig matematisk funksjon, ved å kartlegge funksjonens innganger til utganger,  

Funksjonell programmering er spesielt egnet for smarte kontrakter fordi måten funksjoner er sammensatt på, ligner måten kontrakter samhandler på. En kontrakt som sier “Hvis Alice gir Bob $ 100, gir Bob Alice en billett”, er som en funksjon som tilordner $ 100 til en billett. Hvis det er en annen kontrakt som sier “Hvis Alice presenterer en billett til Bob, slipper Bob Alice gjennom døren”, er dette en andre funksjon som kartlegger en billett for å få tilgang. Akkurat som funksjoner, komponerer disse kontraktene naturlig: “Hvis Alice gir Bob $ 100, lar Bob Alice komme inn døren”.

Denne rene inngangs- og utgangsatferden som er uavhengig av en tilstand, gjør den funksjonelle tilnærmingen lettere å resonnere matematisk: ved å ha funksjoner som bare er avhengige av deres innganger for å beregne utgangene sine, kan utvikleren fokusere på riktigheten av den enkelte funksjonen og typesystemet muliggjør disse skal være trygt og forutsigbart sammensatt sammen. Dette er grunnen til at funksjonelle programmer anses å være en sikrere tilnærming til opprettelse av smarte kontrakter. DAML er et funksjonelt språk og lar utviklere innkapsle forretningsresonnement i sterkt typede matematiske funksjoner. “Sterkt skrevet” i denne sammenhengen betyr at måten hver funksjon fungerer på automatisk kan kontrolleres av DAMLs verktøy og kjøretid. Dette hjelper utviklere å resonnere nøyaktig hvordan hver komponent i programmet vil påvirke hovedbokens tilstand.

DAML-koden

For å prøve DAML kan du 1) installere Visual Studio-kode og DAML SDK eller bruk 2) webIDE (mer for læringsformål)

maltegning

  med

    eier: Fest

  hvor

    signatær eier

Det du ser ovenfor er en enkel DAML-mal. En mal definerer en type kontrakt som kan opprettes og hvem som har rett til det. Kontrakter er forekomster av maler. I eksemplet ovenfor er navnet på malen “Token”. Dataene i kontraktene kalles “argumenter”. Så, la oss se på argumentene som er erklært i denne kontrakten.

  • “With” -blokken definerer datatypen til argumentene i malen ved å føre opp feltnavn og deres typer. Malen ovenfor har et enkelt felt som heter “eier” av typen “Party”.
  • “Hvor” -blokken deklarerer feltets omfang. I vår mal erklærer “hvor” -blokken feltet “eier” som undertegner av kontrakten. Når det er erklært undertegner, vil et felt få myndighet til å opprette eller arkivere kontrakten. 

En typisk kontraktskode i DAML har fire komponenter:

  • Datamodell: Bruk DAML til å enkelt modellere komplekse dataskjemaer for applikasjonen din (hvilken type data som trengs for kontrakten)
  • Finkornet Tillatelser: Spesifiser tillatelsene i kontrakten (hvem kan opprette og arkivere kontrakten, hvem kan se visse gjennomføringstrinn osv.)
  • Forretningslogikk: Beskrive handlingene i kontrakten (hva gjør kontrakten egentlig og hva er trinnene for å utføre den)
  • Scenariobasert testing: Test forretningslogikken du spesifiserte og de forskjellige arbeidsflytene.

Nå som vi kjenner til de fire komponentene og malopprettingen, kan vi se på en fullverdig DAML-kode. 

mal Kontanter

  med

    utsteder: Part

    eier: Fest

    beløp: desimal

  hvor

    underskriver utsteder

    kontrolløren kan

      Overføring: ContractId Cash

        med

          newOwner: Party

        gjør dette med eier = newOwner

mal TicketAgreement

  med

    arrangør: Fest

    eier: Fest

  hvor

    underskriver arrangør, eier

mal TicketOffer

  med

    arrangør: Fest

    kjøper: Fest

    pris: Desimal

  hvor

    undertegner arrangør

    observatørkjøper

    kontroller kjøper kan

      Godta: ContractId TicketAgreement

        med

          cashId: ContractId Cash

        gjøre

          penger <- hente kontanter

          påstå (kontantbeløp == pris)

          utøve kontanterId overføring med

            newOwner = arrangør

          lage TicketAgreement med

            arrangør; eier = kjøper

validateTicketPurchase = scenario gjør

  utsteder <- getParty “Utsteder”

  arrangør <- getParty “Organizer”

  kjøper <- getParty “Kjøper”

  penger <- sende utsteder gjøre

    lage kontanter med

      utsteder; eier = kjøper; mengde = 20,0

  by på <- sende arrangør gjøre

    lage TicketOffer med

      arrangør; kjøper; pris = 20,0

  sende inn kjøper gjøre

    treningstilbud Godta med

      cashId = kontanter

Ok, så vi har en serie maler her som jobber sammen for å lage en kontrakt der en bruker kjøper en billett fra en arrangør. Så etter fargekoden har vi fire spesifikke blokker i koden ovenfor:

Datamodell – Rød 

Som nevnt tidligere har maler datafelt som er nødvendige for erklæringen og utførelsen. La oss se på TicketOffer-malen:

mal TicketOffer

  med

    arrangør: Fest

    kjøper: Fest

    pris: Desimal

Denne malen erklærer tre felt:

  • “Arrangør” og “kjøper” av typen “Party. Som navnet antyder, er disse to partene i denne kontrakten.
  • Så har vi “prisen” som er av desimal.

Finkornede tillatelser – grønn

  hvor

    undertegner arrangør

    observatørkjøper

    kontroller kjøper kan

      Godta: ContractId TicketAgreement

Etter å ha erklært feltene i malen, erklærer denne delen tillatelsene gitt til partiorgumenter. Så i denne malen er arrangøren den eneste som har signert og har makten til å starte eller arkivere kontrakten.

Kjøperen er både observatør og kontroller. En observatør er noen som kan se alle statene som kontrakten går gjennom. Som angitt i malen kan kjøperen også godta billettkontrakten, noe som vil føre til arkivering av den og opprette en ny “TicketAgreement” -kontrakt i stedet..

Forretningslogikk – Rosa

    gjøre

          penger <- hente kontanter

          påstå (kontantbeløp == pris)

          utøve cashId Transfer med

            newOwner = arrangør

          lage TicketAgreement med

            arrangør; eier = kjøper

Så vi erklærte feltene og tildelte dem synlighet i kontrakten. Nå er det på tide å erklære forretningslogikken og arbeidsflyten for denne malen. Kontrakten vil først sjekke om kontanter fra kjøper er lik billettprisen eller ikke. Hvis det er det, overføres eierskapet til billetten til kjøperen, mens pengene overføres til arrangøren.

Scenariobasert testing – blå

validateTicketPurchase = scenario gjør

  utsteder <- getParty “Utsteder”

  arrangør <- getParty “Organizer”

  kjøper <- getParty “Kjøper”

  penger <- sende utsteder gjøre

    lage kontanter med

      utsteder; eier = kjøper; mengde = 20,0

  by på <- sende arrangør gjøre

    lage TicketOffer med

      arrangør; kjøper; pris = 20,0

  sende inn kjøper gjøre

    treningstilbud Godta med

      cashId = kontanter

Til slutt kan du teste forretningslogikken og arbeidsflytene i denne delen for å sjekke i sanntid om koden din fungerer eller ikke. Denne sanntiden kommer til å være spesielt nyttig for utviklere. Du kan samhandle med hovedboken ved hjelp av flere parter og bekrefte effekten av transaksjonene dine umiddelbart. Scenarioresultater fra eksemplet ovenfor vil se slik ut

DAML - Et open source-økosystem for å bygge smarte kontraktbaserte distribuerte applikasjoner

Hvis du er interessert i å lære DAML, sjekk ut deres dokumentasjon.

Real World Use Case – Erstatter ASXs CHESS

DAML har allerede funnet en brukersak fra den virkelige verden. Australian Securities Exchange, (ASX), er en av verdens ledende børser for finansmarkeder. Det er en av de 10 største verdipapirbørser etter verdi og det største rentederivatmarkedet i Asia. Siden det er det første store finansmarkedet som åpner hver eneste dag, er det konsekvent blant de fem beste børsene i verden.

I dag er CHESS kjernesystemet som utfører prosesser for clearing, avregning, eiendomsregistrering og noen andre posthandel-tjenester som er avgjørende for at det australske markedet fungerer ordentlig. CHESS fortsetter å være stabilt og å levere disse tjenestene effektivt, noe som demonstreres av CHESSs gjennomsnittlige månedlige tjenestetilgjengelighet de siste fem årene på 99,99%. Selv om det ikke er noe som tyder på at CHESS ikke vil fortsette å tilby tjenester på dette servicenivået, har ASX besluttet å erstatte CHESS med distribuert hovedboksteknologi (DLT) som vil gi et bredere spekter av fordeler for et større tverrsnitt av markedet. ASX forklarer på sin nettsted de mange grunnene til at det valgte DAML:

  • Utstedere og sluttinvestorer vil få større åpenhet om sine markedsaktiviteter gjennom rettidig, sikker og forenklet tilgang til registeret over innehavere (for utstedere), finansielle eiendeler (sluttinvestorer) og tilhørende informasjon.
  • Nye nivåer av funksjonalitet og fleksibel teknologi vil hjelpe ASX til å svare mer effektivt på endrede markeder.
  • Enkel integrering med oppstrøms og nedstrøms forretningssystemer, effektivisering av funksjoner og arbeidsflyter.
  • Fjern behovet for dyre forsoningsprosesser, og bruk i stedet en enkelt kilde til sannhet.
  • Forsikre deg om at løsningen er tilgjengelig.
  • Sikre 100% tilgjengelighet for de som er autorisert til å bruke den uten diskriminering.
  • Gi et system som er sporbart og sikkert.

Konklusjon

Shaul Kfir, medstifter og CTO for Digital Asset, påpekte at fremveksten av blockchain og distribuert ledgerteknologi i dag har mange paralleller til fremveksten av nettet på 1990-tallet. Internett var en så radikalt ny plattform at det ikke kunne levere sitt fulle potensiale ved hjelp av tradisjonelle systemer. Det var først da nye arkitektoniske programmeringsstiler, som REST, ble utviklet for å matche egenskapene til nettet det virkelig tok av. Dette er akkurat hva DAML kan gjøre for blockchain-plattformer for bedrifter.

Fra og med nå har blockchain-plassen flere smarte kontraktspråk. Dette fører til forskjellige typer smarte kontrakter som hemmer interoperabilitet, og i tillegg utvidbarhet. DAML har egenskapene som kreves for at institusjoner skal ta det i bruk som hovedspråk mens de bygger den valgte plattformen. Digital Asset har kunngjort at DAML vil bli integrert med flere distribuerte ledgers og tradisjonelle databaseplattformer, inkludert VMWare Blockchain, Hyperledger Sawtooth og Fabric, Corda og Amazons QLDB og Aurora-databaser. 

Begynn å skrive smarte kontrakter med DAML og last ned DAML SDK her

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me