Binnen in een Universa Smart Contract

In de afgelopen weken heb je de introductie over de interne architectuur van de Universa blockchain kunnen lezen en ook meer over de revisies van de smart contracts. In dit artikel gaan we daar verder op in. Zoals je nu weet, worden transacties niet toegevoegd aan lineaire blokken in de ‘chain’, maar is elke transactie een revisie van een smart contract in een groep van heel veel Directed Acyclic Graphs (DAG).

Maar wat is een smart contract eigenlijk en hoe ziet de architectuur eruit?

Binnen in een Smart Contract

De term ‘Smart Contract’ wordt heel veel gebruikt maar ook vaak niet op de juiste manier toegepast. Het klinkt alsof het om een complex contract gaat dat op een slimme manier binnen de blockchain wordt uitgevoerd.

In de Universa Blockchain is elke transactie een (nieuw) smart contract. En het kan een contract zijn, maar het kan ook een document, digitaal proces of overeenkomst zijn. Daarom spreken we ook wel van ‘slimme documenten’ of ‘slimme processen’.

Als we een smart contract in de Universa Blockchain van wat dichter bij bekijken, kunnen we zien dat het uit drie onderdelen bestaat:

  1. Definitie (of: definition)
  2. Status (of: state)
  3. Transactional

Definitie (of: definition)

Het eerste deel van de structuurbevat gegevens die onveranderlijk moeten blijven bij elke herziening van dit contract. Als een transactie wordt uitgevoerd, moeten deze gegevens onveranderlijk zijn. Aanpassingen zijn hiervan niet mogelijk.

Als de gegevens worden gewijzigd, verbieden de Universa nodes de registratie van de transactie. De nodes vergelijken deze gegevens van de nieuwe revisie immers met de vorige.

Status (of: state)

De state bevat gegevens die mogen worden gewijzigd bij de herziening van dit contract. De specifieke details van wat en hoe het kan worden gewijzigd, kunnen worden gespecificeerd binnen definition.permissions. Parameters die zijn ingesteld in ‘de definitie’ of ‘de state’ zijn zaken als ‘creator’, ‘issuer’ of ‘owner’.

Transactional

Het derde deel van de structuur bevat gegevens die niet (noodzakelijkerwijs) in het contract worden bewaard, maar die alleen aan de specifieke transactie zijn gebonden. Bijvoorbeeld: als je een handelaar betaalt, kun je een record over de betalings/factuurcode in de transactional plaatsen.

Dit zijn de drie secties binnen een smart contract die alle gegevens bevatten over een specifieke transactie. We noemen dit allemaal simpelweg gewoon ‘data’, maar waar kunnen deze gegevens over gaan?

Universa Token contract

laten we het ‘origin’ smart contract van de Universa Token (UTN) als voorbeeld nemen. Deze kun je zelf bekijken in de universaexplorer. Het laat algemene gegevens / informatie zien over de ‘roles’ en de ‘owner’.

Je kunt ook de definition data zien (die tijdens de revisie ongewijzigd moeten blijven). Ongeacht welke revisie van het contract je hebt, je zult altijd deze data zien die erbij hoort:

Het tweede onderdeel is de state data, die de amount van de supply van UTN aangeeft. Dit kan verwarrend zijn, omdat je zou verwachten dat de supply een vast getal of onveranderlijk is.

Een transactie (of herziening van dit root contract) van een token gebruikt echter de split-join-functies. Dit is een van de use-cases van een smart contract. Split-join transacties van een contract wordt voornamelijk gebruikt voor ‘token’ contracten.

Simpel gezegd, het rootcontract van het UTN-token bestaat uit 4.997.891.952 tokens.

Vanwege de dynamisch en flexibele bedragen van de UTN-UTNP-swaps, weer Universa niet de exacte details van de hoeveelheid UTNP in omloop. Dit kan wel getracked worden, maar een tool om dit te volgen is nog niet gebouwd.

Als uit dit contract een betaling wordt uitgevoerd, wordt dit bedrag opgesplitst in bijvoorbeeld 1.997.891.952 en 3.000 000.000. Dit is mogelijk omdat dit de state datavan het contract is (en dus kan worden aangepast).

Nu hebben we twee contracten (revisies) van hetzelfde rootcontract, beide met hun eigen aantal tokens. Voor elke betaling of transactie met deze token wordt het bedrag gesplitst, verzonden en vervolgens samengevoegd (joined) aan de zijde van de ontvanger. Je kunt hierover meer lezen op de KB website.

Trouwens, de Origin ID (de ID van het rootcontract voor een token) is het belangrijkste in de ideologie voor tokens met vaste supply.

Zoals je misschien weet, zijn in de wereld van blockchain de termen ‘mutable’ en ‘immutable’ erg belangrijk. Denk alleen maar aan de maximale supply van een token, de eigenaar en de uitgever van een contract. Met beide secties definitieen statekan dit worden gegarandeerd voor elke specifieke use case.

Permissions en Roles

Er zijn ook methoden om te specificeren wie precies de rechten van een contract bezit. Dit kan een SimpleRole zijn (sgespecificeerd met slechts één private key), of RoleLink (verwijzend naar een andere rol, zoals ‘eigenaar’ of ListRole (die verwijst naar een lijst met meerdere andere rollen).

Dit is heel interessant omdat het bijvoorbeeld mogelijk is om een rol te maken zoals: Een lijst van 5 personen die ALLEMAAL het document moeten ondertekenen. Of een lijst van 6 personen waarbij er EEN het document moet ondertekenen Het is zelfs mogelijk om een 15-out-of-16 constructie te maken. Dit voegt extra veiligheid toe aan aanpassingen bij b.v. cold storage of besluitvorming door meerdere partijen.

In praktijk, kan er naast alleen de basisdefinitie van de rol, kan elke rol zelfs enkele extra referentiesbevatten om te controleren en om extra verificatielogica toe te voegen. Deze references kunnen worden ingesteld in zowel definition, state of de transactional. Het kan bijvoorbeeld een verwijzing zijn naar een name, transactional_id, fields of signed_by.

Er zijn veel manieren om de gegevens, rollen en rechten van een smart contract / document te specificeren. Zodra het is geregistreerd, kan het slimme contract worden gebruikt / geverifieerd / uitgevoerd en wordt het bij elke transactie herzien. Dit resulteert in verschillende Item States voor elke revisie die aan de DAG wordt toegevoegd.

Item State

Laten we als voorbeeld teruggaan naar het UTN-contract. De status hiervan is UNDEFINED.

Belangrijk: dit komt omdat de split-join-functie al is uitgevoerd en niet omdat de UTN-token ‘niet meer werkt of bestaat’.

Er zijn verschillende standaarden voor de smart contracts, gebaseerd op het consensus van het netwerk.

  1. APPROVED, de belangrijkste ‘succesvolle’ status voor het contract
  2. LOCKED, de consensus over de status is nog positief, maar het contract is al gesloten terwijl het gearchiveerd werd.

Het is ook mogelijk dat er een negatieve consensus bestaat tussen de nodes:

  1. DECLINED
  2. REVOKED

Tot slot zijn er ook vier opties voor smart contracts (of transacties) waarin de consensus niet wordt gevonden:

  1. UNDEFINED, omdat het contract bijvoorbeeld al lang geleden is ingetrokken.
  2. PENDING
  3. DISCARDED
  4. LOCKED_FOR_CREATION

Je kunt meer leze over deze statussen op de Knowledge Based site. In het volgende artikel gaan we verder in op de use cases van deze smart contracts. Stay tuned. Vertaald door Hans.

Help translating this post to Engels Duits Frans Italiaans Spaans Kroatisch Russisch. Contact @starnold to participate!

Related posts

Binnen in de Universa DAG

Arnold

The Digital Migration: Why Universa is the Rail Blazer

kobina

Wat maakt de Universa Blockchain zo goedkoop?

Arnold

Leave a Comment