er en distribuert Ledger for lagring, administrasjon og synkronisering av økonomiske forpliktelser mellom ulike finansielle organisasjoner.
Corda har ganske god dokumentasjon med videoforelesninger som kan finnes . Jeg skal prøve å kort beskrive hvordan Corda fungerer innvendig.
La oss se på hovedtrekkene til Corda og dens unikhet blant andre blokkjeder:
- Corda har ikke sin egen kryptovaluta.
- Corda bruker ikke konseptet gruvedrift og Proof-of-Work-systemet.
- Dataoverføring skjer kun mellom parter i transaksjonen/kontrakten. Det er ingen global kringkasting til alle nettverksnoder.
- Det er ingen sentral kontroller som administrerer alle transaksjoner.
- Corda støtter ulike konsensusmekanismer.
- Konsensus oppnås mellom deltakerne på nivå med en individuell avtale/kontrakt, og ikke på nivå for hele systemet.
- En transaksjon bekreftes kun av deltakerne knyttet til den.
- Corda tilbyr en direkte forbindelse mellom formelt menneskelig juridisk språk og smart kontraktskode.
Hovedboken
Konseptet med hovedbok i Corda er subjektivt. Det finnes ikke et enkelt sentralt datalager. I stedet opprettholder hver node en egen database med fakta kjent for den.
Tenk deg for eksempel et nettverk av 5 noder, der en sirkel er et faktum kjent for noden.
Som vi kan se, vet Ed, Carl og Demi om fakta 3, men Alice og Bob er ikke engang klar over det. Corda garanterer at vanlige fakta lagres i databasen til hver node, og dataene vil være identiske.
Stater
Staten er uforanderlig et objekt som representerer et faktum kjent for en eller flere nettverksnoder på et bestemt tidspunkt.
Stater kan lagre vilkårlige data, for eksempel aksjer, obligasjoner, lån, identifikasjonsinformasjon.
For eksempel representerer følgende stat en IOU – en avtale om at Alice skylder Bob et beløp på X:
Et faktums livssyklus over tid representeres av en sekvens av tilstander. Når det er nødvendig å oppdatere den nåværende tilstanden, oppretter vi en ny og merker den nåværende som historisk.
Transaksjonen
Transaksjoner er forslag for å oppdatere reskontroen. De sendes ikke til alle hovedbokdeltakere og er kun tilgjengelige for de nettverksdeltakerne som har juridisk rett til å se og administrere dem.
En transaksjon vil bli lagt til reskontro hvis den:
- kontraktsmessig gyldig
- signert av alle nødvendige deltakere
- inneholder ikke dobbeltforbruk
Corda bruker UTXO-modellen (ubrukt transaksjonsutgang), der hver hovedboktilstand er uforanderlig.
Når en transaksjon er opprettet, overføres utdatatilstanden til den forrige transaksjonen (ved hash og indeks) til inngangen.
Transaksjonens livssyklus:
- Oppretting (for øyeblikket er transaksjonen bare et forslag om å oppdatere hovedboken)
- Samle underskrifter (påkrevde parter i transaksjonen godkjenner oppdateringsforslaget ved å legge til en signatur i transaksjonen)
- Forplikte transaksjonen til reskontro
Når en transaksjon er lagt til i reskontroen, er inngangstilstandene merket som historiske og kan ikke brukes i fremtidige transaksjoner.
I tillegg til inngangs- og utdatatilstander kan en transaksjon inneholde:
- Kommandoer (transaksjonsparameter som indikerer formålet med transaksjonen)
- Vedlegg (feriekalender, valutaomregner)
- Tidsvinduer (gyldighetsperiode)
- Notarius (notarius, spesielle nettverksdeltakere som validerer transaksjoner)
kontrakter
Når vi snakker om transaksjonsgyldighet, mener vi ikke bare tilstedeværelsen av nødvendige signaturer, men også kontraktsmessig gyldighet. Hver transaksjon er knyttet til en kontrakt som aksepterer den og validerer inngangs- og utgangstilstandene. En transaksjon anses bare som gyldig hvis alle dens tilstander er gyldige.
Kontrakter i Corda er skrevet på et hvilket som helst JVM-språk (for eksempel Java, Kotlin).
class CommercialPaper : Contract {
override fun verify(tx: LedgerTransaction) {
TODO()
}
}
Det er nødvendig å arve fra en klasse Kontrakt og overstyre metoden verifisere. Hvis transaksjonen er ugyldig, vil et unntak bli kastet.
Transaksjonsvalidering må være deterministisk, dvs. kontrakten må alltid enten akseptere eller avvise transaksjonen. I forbindelse med dette kan ikke gyldigheten av transaksjonen avhenge av tid, tilfeldige tall, vertsfiler osv.
I Corda utføres kontrakter i en såkalt sandkasse – en lett modifisert JVM som garanterer deterministisk utførelse av kontrakter.
Strømmer
For å automatisere kommunikasjonen mellom nettverksnoder ble det lagt til tråder.
En flyt er en sekvens av trinn som forteller en node hvordan den skal utføre en spesifikk reskontrooppdatering og på hvilket tidspunkt transaksjonen må signeres og valideres.
Noen ganger tar det timer, dager før transaksjonen er signert av alle parter og kommer inn i hovedboken. Hva skjer hvis du kobler fra en node som deltar i en transaksjon? Tråder har sjekkpunkter, hvor tilstanden til tråden skrives til nodens database. Når en node gjenopprettes til nettverket, vil den fortsette der den slapp.
Konsensus
For å komme inn i hovedboken, må en transaksjon nå to konsensuser: gyldighet og unikhet.
Beslutningen om gyldigheten av en transaksjon tas kun av partene som er direkte involvert i den.
Notarnoder sjekker transaksjonen for unikhet og forhindrer dobbeltforbruk.
La oss forestille oss at Bob har $100 og ønsker å overføre $80 til Charlie og $70 til Dan ved å bruke samme inndatatilstand.
Corda vil ikke tillate deg å utføre et slikt triks. Selv om transaksjonen vil bestå gyldighetskontrollen, vil unikhetskontrollen mislykkes.
Konklusjon
Corda-plattformen, utviklet av R3 blockchain-konsortiet, er ikke et rent bruksområde for blokkjedeteknologi. Corda er et høyt spesialisert verktøy for finansinstitusjoner.
Kilde: www.habr.com