Smart contracts: welke afspraken moet je naast de code verduidelijken?

Een programma dat automatisch een handeling uitvoert zodra aan bepaalde voorwaarden is voldaan, klinkt overzichtelijk. Toch begint een goed gesprek over smart contracts bij meer dan de code. Partijen moeten ook begrijpen welke situatie wordt bedoeld, welke gegevens worden gebruikt en wat er gebeurt als de werkelijkheid afwijkt van het verwachte verloop. Wie een toepassing laat bouwen of beoordelen, heeft daarom baat bij een duidelijke beschrijving van zowel de normale werking als de mogelijke uitzonderingen.

Beschrijf eerst wat het programma werkelijk uitvoert

Een smart contract op Ethereum is een programma op de blockchain. Het voert de regels uit die daarin zijn vastgelegd wanneer het op de betreffende manier wordt aangeroepen. Dat zegt nog niets over alle bedoelingen die partijen tijdens een gesprek hebben uitgesproken. Een begrijpelijke beschrijving van het gewenste proces blijft daarom belangrijk.

Neem een fictief voorbeeld waarin een digitale tegoedbon onder bepaalde voorwaarden wordt overgedragen. Welke adressen mogen een handeling starten, welk bedrag of recht wordt in het systeem bijgehouden en wanneer verandert de registratie? Door zulke vragen eerst in gewone taal te beantwoorden, kunnen een ontwikkelaar en een adviseur gerichter bespreken wat de code wel en niet moet uitvoeren.

Een gegeven uit de buitenwereld vraagt een eigen oplossing

Een blockchainprogramma weet niet vanzelf of een pakket is aangekomen, een sleutel is ingeleverd of een dienst naar tevredenheid is uitgevoerd. Voor informatie van buiten het netwerk zijn aanvullende mechanismen nodig. Daarbij kan bijvoorbeeld een oracle worden gebruikt: een systeem dat externe gegevens voor een blockchain beschikbaar maakt.

Daarmee ontstaat een nieuwe vraag: waar komen die gegevens vandaan en waarom zouden partijen daarop vertrouwen? Beschrijf wie een gebeurtenis vaststelt, hoe een fout wordt ontdekt en welke informatie wordt bewaard. Automatische uitvoering maakt de kwaliteit van de invoer niet minder belangrijk. Wanneer een gegeven bepalend is voor een handeling, verdient de herkomst ervan evenveel aandacht als de verwerking in de code.

Houd de munt en de toepassing uit elkaar

Ethereum is het netwerk waarop een toepassing kan functioneren; ether is de bijbehorende cryptomunt. Voor algemene informatie over ethereum kun je de uitleg van Finst bekijken. Het bezit van ETH en het gebruik van een specifiek smart contract zijn echter verschillende onderwerpen. Een aankoop zegt niets over de inhoud of kwaliteit van een afzonderlijke toepassing.

Maak daarom duidelijk welke vraag je wilt laten beoordelen. Gaat het om de technische uitvoering van een overdracht, de afspraken tussen betrokken partijen of de dienstverlening van een aanbieder? Door die onderwerpen afzonderlijk te benoemen, voorkom je dat een algemene uitleg over blockchain wordt aangezien voor een beoordeling van een concrete situatie met eigen belangen en voorwaarden.

Werk afwijkende situaties vooraf uit

Een ontwerp wordt duidelijker wanneer je niet alleen de ideale route beschrijft. Wat gebeurt er bij een verkeerd ingevoerd adres, een onjuist extern gegeven of een verschil van mening over de geleverde prestatie? Is een handeling te pauzeren en wie heeft daarvoor bevoegdheden? De antwoorden hangen af van de inrichting van de toepassing.

Vraag daarnaast hoe wijzigingen worden behandeld. Sommige systemen hebben mogelijkheden om onderdelen aan te passen, terwijl andere bewust weinig wijzigingsruimte bieden. Beide keuzes roepen vragen op over beheer en verantwoordelijkheid. Laat daarom uitleggen welke mogelijkheden werkelijk bestaan, in plaats van te vertrouwen op algemene uitspraken dat blockchaininformatie altijd onveranderbaar is of dat een beheerder alles eenvoudig kan herstellen.

Bereid een gesprek met een specialist concreet voor

Een overzicht van deelnemers, gegevensstromen en mogelijke uitzonderingen maakt een adviesgesprek gerichter. Voeg een beschrijving van de normale handeling toe en verzamel de documenten die daarover al bestaan. Geef ook aan welke onderdelen nog een voorstel zijn en welke al in gebruik zijn. Zo hoeft een specialist niet eerst uit losse berichten te reconstrueren hoe het systeem bedoeld is.

Vraag bij het inschakelen van hulp welke expertise nodig is en welke werkzaamheden worden begroot. Technisch onderzoek van code en juridische beoordeling van afspraken kunnen verschillende taken zijn. Een helder afgebakende vraag helpt om die werkzaamheden te bespreken. Het doel is dat alle betrokkenen begrijpen wat er automatisch gebeurt, welke verwachtingen daarbuiten bestaan en welke punten nog een afzonderlijke beoordeling nodig hebben.