Radix DLT, 1 oktober 2020

In een eerder artikel beschreven we hoe Radix een nieuwe, doelgerichte ontwikkelingsomgeving bidet voor bouwers van gedecentraliseerde financiële applicaties – de Radix Engine. Voortbouwend op die fundering ontwierp Radix de componentencatalogus [Component Catalog]. De catalogus biedt met weinig code toegang tot algemene activumuitgifte en financiële primitieven, en een gedecentraliseerde on-ledger hub voor ontwikkelaars om modulaire tools te creëren, delen, uit te breiden en te combineren voor de versnelling van het bouwen van dApps. Samen maken deze instrumenten Radix het meest bouwbare en interoperationele platform voor DeFi.

De kracht van een on-ledger ontwikkelaarshub

Een waarlijk nuttig ontwikkelingsplatform omvat bibliotheken, raamwerken en andere instrumenten die ontwikkelaars in staat stellen om eenvoudige, algemene dingen snel te bouwen met een minimum aan leer-curve. Deze zelfde instrumenten versnellen ook complexere producten door het bieden van betrouwbare, voor-gebouwde oplossingen voor delen van het probleem dat andere ontwikkelaars zijn tegengekomen en al hebben opgelost. Het hebben van goede standaarden en direct beschikbare oplossingen moedigt ook sterk interoperationaliteit tussen dApps aan, wat in het bijzonder belangrijk is voor een DeFi-ecosysteem.

In DeFi komen algemene brokken van financiën-georiënteerde functionaliteiten telkens terug over veel applicaties: activa (inwisselbaar of uniek), aandelen, accounts, controle door meerdere partijen, liquiditeitspools, swaps, aankopen, en orakels, om maar een paar voorbeelden te noemen. Dit zijn de belangrijkste kandidaten voor stukjes functionaliteit die ontwikkelaars graag zien als al bestaande, bewezen en goed onderhouden oplossingen.

Traditionele open source-methoden en community-samenwerking zijn zeker goede plaatsen om te starten met het aanmoedigen van deze producten. Pakketk-managers helpen vaak bij het proces van het ontdekken en gebruiken van al bestaande instrumenten. Maar de Radix Engine geeft ons een opwindende nieuwe mogelijkheid: het direct op de ledger zetten van community-samenwerking en pakket-managerachtige functionaliteit.

Een on-ledger-mechanisme zodat componenten modulair kunnen worden gebruikt, geüpdate, geversioneerd, uitgebreid en gecombineerd is een krachtig instrument voor ontwikkelaars. Componenten die op deze manier op de ledger zijn geïnstalleerd dragen niet alleen bij aan het ecosysteem van de ontwikkelaars; ze breiden direct de effectieve functionaliteit uit van het Radix-platform.

Een ontwikkelaar hoeft geen volledig functionele alleenstaande dApp-component te bouwen om nuttig bij te dragen. Componenten die iets heel goed doen en gebouwd zijn om gemakkelijk herbruikt of gecombineerd te worden met andere componenten kunnen standaarden van het platform worden die bouw versnellen en interoperationaliteit voor iedereen aanmoedigen. 

Het idee van het “schrijven van programma’s om iets goed te doen” en het “schrijven van programma’s om samen te werken” was de leidende filosofie van de creëerders van UNIX in de jaren 1970. Het resultaat creëerde het fundament van open source-ontwikkeling en de spectaculair succesvolle familieboom van op UNIX gebaseerde besturingssystemen en applicaties sindsdien. We geloven dat het herbouwen van de financiële systemen van de wereld rond een gedecentraliseerd platform een vergelijkbare filosofie suggereert; het maximaliseren van interoperationaliteit, modulariteit en het potentieel voor iedereen om betekenisvolle bijdragen te maken, zowel groot als klein.

We hebben deze filosofie diep geïntegreerd in de manier waarop componenten worden geïnstalleerd en gebruikt op Radix met een platformeigenschap die we ‘componentencatalogus’ [‘Component Catalog’] noemen.

Hoe de Radix componentencatalogus werkt

Bij typische smart contract DLT’s schrijft een ontwikkelaar wat code (Solidity in het geval van Ethereum) en stuurt die dan naar het netwerk waar deze een actief smart contract wordt voor gebruikers van het netwerk om mee te interacteren. De componentencatalogus verandert dit model.

Wanneer een Scrypto-code van een component wordt verstuurd naar het netwerk wordt deze eerst automatisch toegevoegd aan een on-ledger register genaamd de ‘cmponentencatalogus’. Componenten in de catalogus zijn als inactieve sjablonen of blauwdrukken die iedereen kan gebruiken om meerdere actieve componenten te creëren volgens het patroon van het origineel in de catalogus.

Om de component uit de catalogus actief voor gebruik te maken concretiseert een ontwikkelaar deze met het creëren van zijn eigen geconcretiseerde component uit het blauwdruksjabloon. Een geconcretiseerd component heeft zijn eigen unieke identiteit op het Radix-netwerk en zijn acties worden beschikbaar voor gebruik door gebruikers (of andere componenten, zoals we eerder zagen). Dit betekent dat één component in de catalogus oneindig vaak kan worden gebruikt als sjabloon voor geconcretiseerde componenten die zich allemaal op dezelfde primaire manier gedragen.

Nieuwe componenten starten hun bestaan als Scrypto-code die wordt geïnstalleerd in de componentencatalogus op het Radix Netwerk zelf, waar ze gemakkelijk geconfigureerd en geconcretiseerd kunnen worden – of geïmporteerd in andere nieuwe componenten.

Concretisering is eenvoudig gedaan via API en vereist geen Scrypto-code. De meeste componenten in de catalogus zullen configuratie-parameters bevatten die het aanpassen van het geconcretiseerde component mogelijk maken. Bijvoorbeeld de eerder beschreven “token-definitie“-component zou iedereen zijn eigen token-definitie laten concretiseren met zijn eigen unieke naam, symbool, maximale voorraad, etc. – om dan te starten met het munten van de eigen tokens.

Bij het op deze  manier concretiseren van componenten uit een universele on-ledger catalogus maakt Radix het voor iedere ontwikkelaar heel snel, gemakkelijk en veilig om activa uit te geven en toegang te krijgen tot andere eenvoudige functionaliteiten die door anderen werden gecreëerd, zonder Scrypto-code te hoeven leren en schrijven.

Een andere manier om gebruik te maken van componenten in de catalogus is ze te importeren. Een ontwikkelaar wil misschien gebruik maken van de functionaliteit van een bestaande component in de catalogus – maar wat deze kan doen aanpassen of er iets aan toe voegen. Dit wordt gedaan door het creëren van een nieuwe component die een importeer-commando omvat voor de component die de gewenste kernfunctionaliteit biedt. De additionele functionaliteit wordt dan geïmplementeerd in de eigen Scrypto-code van de ontwikkelaar.

Importeren is geen kopiëren van de Scrypto-code van de originele component; het is een on-ledger link naar de originele component (en zijn versie). Een voorbeeld hiervan (boven getoond) kan een prijsorakel-component zijn die een ontwikkelaar wil aanpassen door een berekening toe te voegen van een bewegend prijsgemiddelde (en actie om ertoe togang te krijgen). De ontwikkelaar zou zijn eigen speciale prijsorakel-component kunnen creëren, de originele prijsorakel-component kunnen importeren door te refereren aan zijn ID in de catalogus, en de additionele Scrypto-code eraan toe kunnen voegen voor de prijsgemiddelde-berekening.

Zowel cataloguscomponenten als geconcretiseerde componenten hebben hun eigen unieke component-ID en worden geassocieerd met de eigen unieke ontwikkelaars-ID van de maker. Componenten worden geversioneerd waarbij iedere nieuwe installatie-update een revisie-omhoogplaatsing vereist. Het updaten van een component forceert niet automatisch een update aan andere componenten die ervan gebruik maken; eerdere revisies blijven onveranderlijk beschikbaar op de ledger en bestaande componenten zullen toegang blijven houden tot de eerdere revisie. Een ontwikkelaar kan kiezen om een nieuwe revisie in gebruik te namen door een eigen update te maken voor het component dat voorgenoemde gebruikt.

Standaard platform-componenten

De Radix Foundation is toegewijd aan het vullen van de catalogus met nuttige componenten die algemene elementen en gedragingen van DeFi als standaardeigenschappen van het platform modelleren. Dit omvat zaken als activa (inwisselbare of niet-inwisselbare tokens) en accounts (inclusief multi-sig-controle) en dit zal uitbreidentot het omvatten van functies die gewenst zijn door de community en die een hoger niveau van DeFi-primitieven zouden kunnen omvatten, zoals liquiditeitspools, inwisselsystemen, koopbare activa, data-orakels, en meer. Elk van de standaard cataloguscomponenten ontwikkeld door de Radix Foundation kunnen zoals ze zijn geconcretiseerd worden (bijvoorbeeld het creëren van een voorraad van aangepaste tokens via API-aanroep) of, zoals we boven zagen, ze kunnen modulair worden gecombineerd op verschillende manieren om meer complexe functionaliteit te creëren.

Met gebruik van deze standaard catalogus-componenten kunnen ontwikkelaars het zelf herimplementeren van algemene functionaliteiten overslaan, ontwikkelingstijd versnellend of deze reducerend tot nul voor heel eenvoudige dingen als het uitgeven van een token. Cataloguscomponenten gecreëerd door derde partijen kunnen ook gestandaardiseerde eigenschappen worden van het Radix-netwerk op precies dezelfde manier. Wie ze ook creëert; on-ledger cataloguscomponenten creëren natuurlijke compositionaliteit en interoperationaliteit voor het DeFi-ecosysteem.

Door de Foundation aangeboden componenten zijn niet het einde van het verhaal. Het Radix ontwikkelaars-royalty-systeem biedt prikkels op protocol-niveau voor iedereen om componenten bij te dragen – groot of klein – die “standaarden” van het platform kunnen worden.

Om meer te leren over hoe de Radix-technologie de problemen oplost die DeFi op ieder niveau terughouden ga je naar ons DeFi whitepaper.

Website (https://radixdlt.com)
Medium (https://medium.com/@radixdlt)
Telegram (https://t.me/radix_dlt)
Twitter (https://twitter.com/RadixDLT)