Dans en Radix’ tech-reisRadix DLT, 11 februari 2020Radix’ reis startte terug in 2013 toen onze oprichter, Dan, de belofte en uitdagingen zag van Bitcoin. Dan wist dat als Bitcoin of enige andere cryptovaluta een nieuw wereldwijd betalingssysteem wilde worden hij moest schalen om tegemoet te komen aan de wereldwijde vraag. Om te kijken of dit mogelijk was startte Dan met het draaien van tests om te zien wat de beperkingen van Bitcoins schaalbaarheid waren.
Begin met BitcoinDaar in de coderingsgrot (in werkelijkheid best een leuke, zij het misschien rommelige, studiekamer, achterin Dans huis), startte Dan met het draaien van nodes en het spammen van zijn testnetwerk om echt te zien wat Bitcoin en blockchain konden doen. Hij deed alles, van het vergroten van de blockgrootte tot belachelijke grootten, met de best beschikbare hardware, tot zelfs het zo goedkoop mogelijk maken van mining. Uiteindelijk kon hij echter
slechts 700-1.000 transacties per seconde (TPS) met blockchain bereiken. Wetende dat Visa 24.000 TPS verwerkte en Alipay meer dan 725.000 transacties deed op hun grootste shoppingdag wist Dan dat deze snelheden niet genoeg zouden zijn om het doel van een wereldwijd betalingsondersteuning te bereiken.
Omhoog bouwen met blocktrees Dans volgende gedachte was dat als een enkele keten van blocks enkel 1.000 TPS kon bereiken, zou een vertakt netwerk van blockchains het dan beter doen? Gevat genaamd ‘blocktrees’ [‘block-bomen’] was dit Dans eerste stap in het onderzoeken en begrijpen van sharding [afsplitsing]. De theorie was dat verschillende vertakkingen van de blocktree verschillende staten van synchronisatie konden hebben, waarbij gerelateerde transacties zich in één tak bevinden en ongerelateerde transacties in een andere.
Het belang van groepsgerelateerde en niet-groepsgerelateerde transacties bleek een sleutelinzicht te zijn in hoe efficiëntie mogelijk te maken in een schaalbare ledgeroplossing. Je zult het doorheen dit artikel zien verschijnen omdat het is behouden doorheen de verschillende stadia en herhalingen van ledgers die Dan en het Radix-team hebben verkend.
Nu echter terug naar blocktrees. Het was terwijl Dan blocktrees aan het verkennen, bouwen en testen was dat hij ook de naam eMunie begon te gebruiken om het project te beschrijven dat was gestart om wat loyale gemeenschapsleden aan te trekken. Deze gemeenschapsleden stelden Dan in staat om zijn testen op te schalen en beta-tests te draaien in meer ‘echte wereld’ scenario’s. Wat deze tests echter helaas lieten zien was dat blocktrees slechts een paar honderd TPS konden bereiken voordat ze problemen tegen kwamen.
Wat Dan ontdekte was dat wanneer grote vertakkingen van de boom startten met het niet akkoord gaan met de correcte staat van een transactie dit leidde tot een hoog niveau van lading voor het netwerk om op één lijn te komen. Dat was vanwege een toenemend niveau van complexiteit van de boodschappen die werden verstuurd tussen nodes wanneer ze probeerden om op één lijn te komen over de staat van een transactie. Als een enkele transactie in een vertakking op één lijn moest komen dan gold dat voor alle transacties in die vertakking en alle sub-vertakkingen. Blijvend bij de benadering van het hebben van blocks van transacties en mining leende zichzelf, helaas, niet voor het zijn van de efficiënte oplossing van netwerksynchronisatieproblemen.
Het doen met DAGsJij en ik zouden gedemotiveerd kunnen zijn door dit nieuws, besluitend om alles in te pakken en in plaats daarvan naar de kroeg te gaan. Maar niet Dan. Hij nam een sterke kop thee, stroopte metaforisch zijn mouwen op (heel moeilijk om letterlijk te doen wanneer je alleen T-shirts draagt) en besloot dat hij anders moest denken. Wat als in plaats van het groeperen en synchroniseren van transacties in blocks ze individueel werden afgehandeld? Met dit in gedachte startte Dan het verkennen van Directed Acyclic Graphs (DAGs).
DAGs hadden vergelijkbare vertakkingseigenschappen als blocktrees, maar in tegenstelling tot blocktrees en blockchains, die een block creëren en toevoegen aan de ‘keten’ ieder ingesteld aantal van seconden / minuten laten DAGs het toe om direct naar de volgende te linken. Deze benadering had twee belangrijke voordelen – DAGs kunnen transacties direct verwerken, zonder gebruik van block-tijden, en ze kunnen ook het verwijderen van traditioneel mining toelaten – leidend tot grote efficiënties.
Was dit het dan? Had Dan de Heilige Graal gevonden van een wereldwijd schaalbare gedecentraliseerde ledger? Het korte antwoord is ‘nee’. Het lange antwoord is ‘nee’, maar met meer uitleg. Terwijl DAGs succesvol tot aan 1.500 TPS konden bereiken zonder problemen kwamen ze wanneer ze daaraan voorbij schaalden – Visa-achtige niveaus proberend te bereiken – veiligheidsproblemen tegen.
Om verdere schaalbaarheid te bereiken moet je de DAG sharden, maar een DAG kan alleen beschermen tegen dubbele spenderingen wanneer alle nodes toegang hebben tot alle transacties, voor zover we weten. Sharding voorkomt dit, wat betekent dat schaalbare DAGs fundamenteel kwetsbaar waren voor aanvallen van dubbele spenderingen. Andere projecten hebben dit probleem aangepakt met het creëren van gecentraliseerde “getuige-“ of “coödrinator-”nodes die alle transacties zien maar zich op deze nodes verlatend wordt de ledger fundamenteel gecentraliseerd, beheer en aanvalspunten aan het systeem toevoegend.
Verder kanaliserend met CASTToen Dan zijn sterke thee op had was het inmiddels bijna een jaar sinds hij voor het eerst DAGs startte te onderzoeken en twee jaar sinds hij blocktrees verkende; hij behield zijn positiviteit omdat hij wist dat het leren van DAGs en blocktrees van toepassing was op andere oplossingen. Zo gaat dat met onderzoek; wat zegt het beroemde Thomas Edison-gezegde?
Ik heb niet gefaald. Ik heb gewoon 10.000 manieren gevonden die niet werken.Met dat instagram-waardige citaat in het achterhoofd ging Dan (vastbesloten) verder naar de volgende herhaling van een schaalbare ledger: CAST – Channelled Asynchronous State Tree (we weten dat het acroniem wat geforceerd is maar we besloten om het hem niet voor de voeten te werpen). CAST wilde de berichtencomplexiteit zoals gezien in blocktrees aanpakken terwijl de bescherming tegen dubbele spenderingen in een gesharde ledger verzekerd bleef; did werd gedaan door stat van data te scheiden. De staat was in een vertakkende boom, welke de plaats was waar conflicten en dubbele spenderingen werden beheerd, terwijl de data zich in een DAG-achtige structuur bevond. Deze splitsing in structuur leidde tot een deels synchroon netwerk wat het efficiënter maakte, leidend tot snelheden van bijna 2.300 TPS voordat netwerk-latentie en de oude vijand van berichtencomplexiteit opnieuw opkwamen.
Het was tijdens het testen van CAST dat Dan het belang van echte wereld beta-testen zag. De loyale community-leden die werden aangetrokken in het blocktree-tijdperk waren bij het project gebleven; fondsen, ondersteunging, zowel moreel als technisch, biedend aan Dan doorheen de verschillende herhalingen van de technologie. Deze loyale groep stelde Dan ook in staat om beta-tests te draaien; nodes draaiend en transacties versturend en uiteindelijk zoveel mogelijk echte wereld-scenario’s proberend te creëren. Eén van deze community-leden, Greg, werd snel een berucht boeman. Wanneer een ladingstest werd gedraaid op het CAST beta-netwerk verliep alles soepel totdat Greg mee deed. Gregs grage netwerkverbinding zou uiteindelijk leiden tot latentie- en synchronisatieproblemen in het netwerk. Dit leidde tot twee uitkomsten – Greg werd een meme die synoniem was aan falen binnen d gemeenschap (sorry Greg) en de realisatie dat CAST niet bestand was tegen echte wereld-omstandigheden op schaal. Een wereldwijd netwerk voor iedereen moest uiteindelijk afrekenen met trage verbindingen en als Gregs ene trage verbinding zou zorgen voor een falen dan was CAST niet de oplossing die we zochten.
Omkering met TempoOp dit punt draaide Dan metaforisch de tafel om. We nemen tenminste aan en hopen dat het metaforisch was anders zou het nogal een rommel gecreëerd hebben in de kleine coderings-grot. Hij besloot om in plaats van het herhalen en ontwikkelen van iedere oplossing dit probleem opnieuw overdacht moest worden. Na een hoop brainstorming, dromen en andere overmatig gebruikte clichés kwam Dan met aandragen Tempo.
Geïnspireerd door de relativiteitstheorie, Leslie Lamports Logical Clocks en het belang van sharding van CASTs en DAGs (zie je; hij gooide niet alles weg) nam Tempo een nieuwe benadering. Zijn voor-gesharde datastructuur maakte het groeperen van gerelateerde transacties en het scheiden van ongerelateerde transacties (ik vertelde je dat dit belangrijk zou zijn) mogelijk en dit gecombineerd met een passief consensusmechanisme leidde tot ongelofelijke efficiënties.
Deze nieuwe benadering zag er veelbelovend uit maar er was een hoop te doen tussen de theorie, initieel succesvolle tests en een volwaardige wereldwijde ledgeroplossing. Dit moet allemaal niet door één persoon gedaan worden, zelfs met veel koppen sterke thee, dus Dan startte met het samenstellen van een team. Hoewel het leuk zou zijn om voor te stellen dat Dan het Radix-team samenstelde als
dit was het in realiteit meer een proces van netwerken, posten op StackOverflow, interviewen en het enkele maanden komen en vergezellen van Dan van gelukkige teamleden in Stoke-on-Trent.
Het is waarschijnlijk ook de moeite waard om te vermelden dat rond deze tijd het project zijn naam veranderde van eMunie, waarover we het denk ik eens kunnen zijn dat het een erg rare naam was, naar Radix. Met sterke Latijnse wortels en leuke mathematische implicaties gaf Radix het project voldoende aantrekking. Zelfs wanneer zou blijken dat het verschrikkelijke SEO-implicaties zou hebben omdat de wereld en zijn vrouw blijkbaar het woord Radix graag gebruikten om dingen te benoemen. Dat is echter een geheel ander onderwerp.
Met dit samengestelde droomteam kwam de ontwikkeling en het testen van Tempo echt in een nieuwe versnelling. Het team werkte niet slechts aan Tempo zelf maar ook aan het bouwen van de netwerk-infrastructuur, test-wallets en heel opwindend; de Radix Engine. De Radix Engine is de applicatielaag van Radix – het deel waarmee ontwikkelaars direct interacteren. De Radix Engine wordt uitvoerig besproken in
diverse andere artikelen, dus we gaan er hier niet in detail op door.
Al dit verwoede theoretiseren, ontwikkelen en testen leidde uiteindelijk tot de 1mlj TPS-test, waar de gehele geschiedenis van Bitcoin-transacties werd doorlopen via de Radix-ledger, Tempo, en snelheden bereikte van meer dan 1 miljoen transacties per seconde. Dit was een ongelofelijke prestatie voor Dan en het team, maar het bewees ook het begin te zijn van de waarschuwingstekens van enkele van de veiligheidsproblemen in Tempo.
Hoewel Tempo een geweldige schaalbaarheid mogelijk maakte werd het ook duidelijk dat hij kwetsbaar was voor twee aanvalsvectoren. De eerste, de Weak Atom Problem, betekende dat een klein aantal nodes een situatie zou kunnen opzetten waar de consensus zwak genoeg is voor ze om invloed te hebben over voltrokken transacties. Hoewel dit alleen het geval was in specifieke omstandigheden een zorgvuldig gecoördineerde en geplande aanval benodigde was het risico te groot om het niet te adresseren voor de lancering van het netwerk. De tweede aanvalsvector was van een Sybil-aanval. Tempo gebruikte een vernuftig Sybil-beschermingsmechanisme, genaamd ‘Mass’, dat de node-reputatie voor goed bedrag na verloop van tijd vergrootte. De manier waarop Mass werkte betekende dat Mass veel kwetsbaarder was voor oneerlijke actoren dan voor eerlijke actoren. Dit introduceerde een mogelijke aanval van een kwaadwillende actor die de node-ID’s (en reputatie) van eerlijke actoren koopt.
Toen deze problemen ontdekt werden hoopten Dan en het team dat ze repareerbaar waren op een manier die Tempo als onderliggende ledger voor Radix behield. Iedereen stroopte de mouwen opnieuw op (opnieuw metaforisch omdat T-shirts erg populair zijn binnen het Radix-team, Leroy uitgezonderd, die perse shirts wil dragen) en probeerde een manier te vinden om de problemen op te lossen. Diverse oplossingen werden bedacht, de één levensvatbaarder dan de ander, maar na maanden van onderzoek kon er geen gevonden worden dat gefaseerde uitgifte en testen mogelijk maakte. Dit niveau van onzekerheid en onbekendheden zou kunnen leiden tot jaren meer onderzoek en onzekerheid, zonder het uitbrengen van een publieke ledger.
Na jaren van onderzoek en ontwikkeling, en na net 1 miljoen TPS bereikt te hebben, wilde niemand Tempo terzijde leggen. Maar na enkele uitroepen tegen de goden van tech-ontwikkeling, wat deprimerende teamdrank (rum, Kracken naar voorkeur) moesten we accepteren dat als je moeilijke problemen wilt oplossen je soms moeilijke beslissingen moet nemen, en Tempo moest terzijde gelegd worden.
Voorwaarts stormend met CerberusWat nu? Wel, we herpakten ons en keken wat van Tempo het zo geweldig maakte en we konden behouden, wat we konden leren van andere onderzoeksprojecten en wat we opnieuw moesten doen. Het resultaat van deze oefening is Cerberus.
Cerberus gebruikt Tempo’s vooraf gedefinieerde shard-ruimteconcept maar bouwt ook op een aantal goed bewezen cryptografische primitieven, sterke garanties gevend rond veiligheid, levendigheid en goed gedefinieerde veiligheidsbgeondenheden. Deze combinatie maakt het mogelijk om een uniek BFT-stijl overeenstemmingsproces te creëren dat schaalbaarheid samen met veiligheid mogelijk maakt. Belangrijk voor het Weak Atom Problem is dat de veiligheidsgebondenheden hiervan goed bewezen kunnen worden en sterke garanties geeft rond veiligheid en finaliteit.
We zijn ongelofelijk opgelaten over het potentieel van Cerberus, maar ook over de toenemende benadering voor aflevering die het mogelijk maakt, bouwend op zowel de Radix-leringen van de afgelopen 7 jaren als de laatste consensusonderzoeken die tegenwoordig beschikbaar zijn. Er zijn nog steeds onbekende zaken en problemen die opgelost moeten worden. Als deel van onze toewijding aan sharding en regelmatige updates delen we niet alleen de Cerberus-theorie en het whitepaper met je, maar ook deze vragen en problemen.
Toen Dan besloot om een wereldwijd schaalbare ledger te creëren koos hij geen klein probleem om op te lossen. Hoewel ene klein, minuscuul deel van Dan wenste dat hij een gemakkelijkere uitdaging had gekozen om op te lossen, zoals het creëren van de ultieme ijsco-smaak of hoe mensen ervan te weerhouden muziek op hun telefoons te spelen in het openbaar vervoer, is de rest van hem (eigenlijk het hoofddeel) en het gehele Radix-team toegewijd aan het oplossen van voorgenoemde. We zullen niet stoppen tot we een waarlijk wereldwijde, gedecentraliseerde, schaalbare plaats hebben gecreëerd voor de wereld om op over te schrijven.
Om op de hoogte te blijven van de laatste Radix-nieuwtjes, roddels en toekomstige leukigheden kun je
inschrijven voor onze nieuwsbrief. Die is als piñata, maar minder gewelddadig en in de vorm van een email.
Website (https://radixdlt.com)
Medium (https://medium.com/@radixdlt)
Telegram (https://t.me/radix_dlt)
Twitter (https://twitter.com/RadixDLT)
