Radix DLT, 19 augustus 2020
De DeFi-industrie is groeiende. Hij wordt volwassen. Hij heeft op het moment $6.4mlj aan activa in het systeem (toename van $2.5mlj in de laatste 30 dagen).
Maar met iedere stap voorwaarts komt er meer spanning op het Ethereum-netwerk. Transactiekosten worden zelfs meer onhoudbaar, en met iedere nieuwe DeFi-applicatie zijn er nieuwe veiligheidsrisico’s, controlevereisten, en zelfs hogere barrières om in te stappen voor nieuwe ontwikkelaars.
Dit is niemands schuld; Ethereum was gewoon nooit ontworpen om de noden te ledigen van DeFi, en als resultaat houdt het de groei van de industrie tegen. Dit is de reden dat Radix een laag-1-protocol bouwt die speciaal gebouwd is voor DeFi — DeFi is de toekomst van financiën, en Radix zal de toekomst van DeFi zijn.
Echter Radix is niet het enige protocol dat werkt aan dit doel, er zijn diverse benaderingen om verschillende problemen waarvoor DeFi staat op te lossen. Terwijl elk zijn voordelen heeft gaan we in dit artikel kijken naar hoe Radix vergeleken kan worden in de twee belangrijkste gebieden waar DeFi op het moment zijn meeste groeipijnen op Ethereum kent; schaalbaarheid en ecosysteemontwikkeling (veiligheid).
Schaalbaarheid en compositionaliteit
Als je recent een DeFi-applicaite hebt proberen te gebruiken (of het Ethereum-netwerk in zijn algemeenheid) kan het je opgevallen zijn dat de gasprijs van transacties is toegenomen… in hoge mate!
Een plotselingen toename in gas heft veel transacties te duur gemaakt om levensvatbaar te zijn. Als je een vlugge kijk neemt op de sociale media zie je veel voorbeelden van $30+ gasprijzen, alleen maar om in te wisselen op Uniswap. Dit is duidelijk geen duurzaam niveau en maakt alles behalve transacties van hoge waarde onmogelijk.
Schaalbaarheid is de oplossing en sharding is een algemene methode die wordt voorgesteld om dit te bereiken. Er is echter een klein probleem…
Ethereum 2.0, Polkadot, Avalanche, Near, Cosmos breken de DeFi-compositionaliteit af!
Een boude claim, maar in een poging om slechts één van de belangrijke problemen waarvoor DeFi staat (schaalbaarheid) op te lossen gebruiken al deze alternatieven sharding als oplossing voor schaling, wat een sleutelmogelijkheid van DeFi afbreekt: atomische compositionaliteit. De mogelijkheid om meerdere functies samen te voegen van meerdere dApps binnen een enkele atomische transactie is essentieel voor DeFi. Een goed voorbeeld kan simultaan inlenen van één dApp zijn, terwijl in een andere wordt uitgeleend. Terwijl dit proces gemakkelijk is zonder sharding (en al gebruikt wordt) breken de meeste sharding-benaderingen deze functionaliteit af door applicaties te scheiden op shards die niet kunnen samenwerken in een enkele stap.
Radix is het enige protocol dat sharding gebruikt om lineaire schaalbaarheid te leveren — zonder compositionaliteit af te breken. Dit betekent dat Radix aan de doorvoervereisten kan voldoen van elk aantal dApps wanneer het netwerk groeit, en al die dApps kunnen doorgaan met samen te werken zonder beperking.
Zoals je in onderstaande tabel kunt zien is Radix (met gebruik van ons Cerberus gesharde consensusprotocol) de enige oplossing die de schaalbaalbaarheid biedt die DeFi nodig heeft terwijl onbeperkte atomische compositionaliteit behouden blijft. Andere voorgestelde protocollen die verbeterde schaalbaarheid bieden, bieden ofwel beperkte compositionaliteit over specifieke applicaties, ofwel breken ze compositionaliteit volledig af door het scheiden van elke applicatie op zijn eigen zij-chain.
Radix voordeel: Cerberus
Als je meer wilt lezen over hoe Radix onbeperkte atomische compositionaliteit behoudt bij het schalen dan gaat ons Cerberus-whitepaper hier in volledige details op in.
Geloof ons echter niet op ons woord. Het Radix-team heeft samengewerkt met Professor Mohammed Sadoghi en zijn ExpoLab team aan de universiteit van California Davis. Samen hebben ze Cerberus rigoureus geanalyseerd en getest in een breed spectrum aan scenario’s, en ze hebben ook de mathematische bewijzen rond Cerberus ontwikkeld om grensgevallen te bewaken. Ze hebben hier zelfs een volledig academisch paper uitgebracht over het onderwerp.
Een protocol hebbend om te schalen terwijl compositionaliteit behouden blijft biedt weinig waarde als er geen applicaties zijn die erop draaien voor gebruikers om mee te interacteren. Dit is waar deel twee in beeld komt.
Het bouwen van een ecosysteem: snel, veilig en geprikkelde ontwikkeling
Solidity is de programmeertaal die gebruikt wordt om smart contracts op Ethereum te bouwen. Het is er al vele jaren en heeft een grote gemeenschap van ontwikkelaars, zowel professionals als hobbyisten. Smart contracts op Ethereum zijn aanpasbaar en krachtig, het ontwikkelaars mogelijk makend om complexe dApps te bouwen voor een brede variëteit van gebruikers. Op veel manieren is dit geweldig.
Helaas heeft het niveau van flexibiliteit aangeboden door Solidity op Ethereum nadelen; complexe code is uitdagend om te schrijven bij het vermijden van fouten en kan resulteren in onverwachte uitkomsten of zelfs catastrofaal falen. Zelfs de laatste paar weken in waren er in DeFi serieuze problemen (inclusief verlies van fondsen) veroorzaakt door fouten in smart contracts. Daarbij wordt dit zelfs nog meer gecompliceerd wanneer beschouwd wordt hoe “correcte” code zich gedraagt wanneer samengenomen met andere smart contracts. Dit is niet alleen een probleem voor gebruikers maar ook voor andere ontwikkelaars die andere dApp’s in hun eigen dApp kunnen gebruiken.
Vanwege de onveranderlijke aard van DLT’s kan een fout niet altijd worden verholpen. Dit betekent dat er een significante druk ligt op ontwikkelaars om te verzekeren dat hun code bij lancering functioneel en veilig is. Veel gebruikers (en ontwikkelaars) worden bijvoorbeeld gerustgesteld bij code-controle’s, maar deze reduceren alleen het risico van problemen in plaats van dat ze die elimineren. Op dezelfde manier reduceert het spenderen van meer tijd aan de code of het krijgen van meer ervaren ontwikkelaars ook risico, maar dit elimineert dit nog steeds niet. Al deze stappen betekenen dat het langer duurt om code te ontwikkelen terwijl het moeilijker wordt om bovenop het bestaande ecosysteem te bouwen en vergroot buiten hobbyontwikkeling significant de kosten van zelfs het doen van relatief eenvoudige dingen.
Het bouwen van een betrouwbare financiële applicatie is ene heel ander probleem dan het bouwen van een game, webservice of andere algemene applicatie. DeFi-applicaties zijn specifiek en ontwikkelaars moeten specifieke ontwikkelingsomgevingen gebruiken voor zulke taken.
De Radix Engine is onze oplossing. Specifiek gebouwd voor DeFi-applicaties maakt de Radix Engine veilige ontwikkeling mogelijk met gebruik van finite state machine “Components” in plaats van Turing complete smart contracts.
Terwijl veiligheid van het grootste belang is moet ontwikkeling ook snel zijn vanwege het tempo van innovatie in de scene. Zoals we boven hebben besproken zijn typische smart contracts complex en het is een kritiek probleem dat direct door het protocol moet worden opgelost. Alle Radix-componenten worden uitgerold in een component-“catalogus” waar ze kunnen worden optreden als configureerbare universele eigenschappen van Radix, toegankelijk voor iedere ontwikkelaar via een eenvoudige API-oproep. Dit maakt het voor ontwikkelaars mogelijk om gebruik te maken van bewezen, bestaand werk door anderen, en om door Radix aangeboden componenten te gebruiken om direct eenvoudige financiële componenten te creëren (zoals Continuous Function Market Makers en veel meer).
Het in staat zijn om snel veilige DeFi-apps te ontwikkelen is geweldig; maar om een florerend ecosysteem te bouwen moeten er commerciële prikkels zijn om te bouwen. Dit is het laatste (en vaak overheen gekeken) puzzelstukje. De typische oplossing is om voor het protocol een “ontwikkelaarsfonds” te creëren dat hopelijk een van de grond af opgebouwd ecosysteem draaiende krijgt. Het probleem is hier tweeledig: wat gebeurt er wanneer de fondsen op raken en hoe zijn de deelnemende ontwikkelaars betrokken bij het toevoegen van lange termijn-waarde aan het ecosysteem?
Radix lost dit probleem op met ons on-ledger ontwikkelaars royalty-systeem. Ieder Component die een ontwikkelaar bijdraagt aan de catalogus kan een aangepaste “prijs” insluiten die wordt toegevoegd aan transacties, iedere keer wanneer deze wordt gebruikt. De ontwikkelaar kan zelfs verschillende prijzen instellen volgens de manier waarop de Component is gebouwd. Dit betekent dat als een ontwikkelaar een nuttige (zelfs een eenvoudige) component bouwt en een kleine prijs voor ieder gebruik toewijst hij op de lange termijn kan verdienen met terugkerende inkomsten voor zijn werk. Dit maakt Radix een gedecentraliseerde marktplaats voor DeFi-gebruik, zij het voor eenvoudige nuttige functies of volledige apps. Bij ons weten is het Radix Developer Royalty System uniek. Je kunt er hier meer over lezen.
Samengenomen, en zoals je in onderstaande tabel kunt zien, is Radix (via de Radix Engine) de enige oplossing voor DeFi ontwikkelaars die een snelle, veilige en prikkelende omgeving biedt waar ze kunnen floreren.
Radix-voordeel: Radix Engine
Conclusie
DeFi ervaart een exponentiële groei, en terecht. Om deze groei te faciliteren moet DeFi gebouwd worden op een protocol dat snelle en veilige ontwikkeling van commerciële levensvatbare applicaties op schaal mogelijk maakt terwijl compositionaliteit wordt behouden.
Individueel zijn die uitdagingen moeilijk om te overwinnen, en gecombineerd nog meer. Dat is waarom we geloven dat Radix de enige oplossing is die alle hokjes aan vinkt.
Ontdek hier meer in het Radix DeFi-whitepaper.
Website (https://www.radixdlt.com/)
Medium (https://medium.com/@radixdlt)
Telegram (https://t.me/radix_dlt)
Twitter (https://twitter.com/RadixDLT)
