Haven Deep Dive: de xUSD-code kraken

Neac (Haven's Protocol Lead) en ik hebben de afgelopen maanden gewerkt aan de voorbereiding op de lancering van xUSD door het mainnet.
Image for post

Neac (Haven's Protocol Lead) en ik hebben de afgelopen maanden gewerkt aan de voorbereiding op de lancering van xUSD door het mainnet. Tijdens onze tests hebben we ons gericht op het veilig verifiëren van xUSD-uitwisselingen om een soepele lancering en langdurig succes voor deze eerste privé-stablecoin te garanderen.

Dit werk heeft geresulteerd in een uitgebreide herinrichting van de codebase van Haven. Zoals we in onze testnets hebben geleerd, bleek de structuur van Monero een unieke uitdaging voor het ondertekenen en verifiëren van xUSD-transacties. Het was vervelend, traag en soms ronduit frustrerend. Maar we zijn er trots op dat we een innovatieve oplossing hebben ontwikkeld die de nauwkeurigheid, betrouwbaarheid en privacy van xUSD-transacties nu en in de toekomst garandeert. Hieronder volgt een diepe duik in het proces dat ons tot deze oplossing heeft geleid.

Haven's eerste testnet berekende een geschatte waarde om gebruikers te vertellen hoeveel xUSD ze zouden ontvangen voor de XHV die ze wilden inwisselen. Dit komt omdat in Monero (en Cryptonote), wanneer gebruikers een transactie indienen, ze een inzet op een aantal munten: zowel inputs als outputs. Deze inputs en outputs moeten gelijk zijn, anders mislukt de transactie altijd.

Deze Monero-structuur werd een probleem voor Haven toen we begonnen met het implementeren van xUSD-uitwisselingen. Aanvankelijk konden we het laatste hoeveelheid xUSD uitgewisseld zou gelijk zijn aan de bij benadering hoeveelheid xUSD genoteerd voordat een transactie werd ingediend. Dit komt doordat de XHV-prijs dynamisch verandert. De XHV-prijs (en dus de xUSD-wisselkoers) kan veranderen tussen het moment waarop een gebruiker een transactie heeft ingediend en het moment waarop de transactie werd bevestigd.

De eerste manier waarop we een oplossing voor deze uitdaging benaderden, was door niet langer te zoeken naar gelijkheid van inputs en outputs. Maar om manipulatie te voorkomen, moesten we de afzender niet in staat stellen om een vals bedrag op te geven. Daarom hebben we besloten om deze stap helemaal uit handen van de afzender te nemen en die verantwoordelijkheid bij de mijnwerker te leggen.

Deze oplossing, geïmplementeerd in een volgende testnet, een vertraging toegevoegd bij het verstrekken van de exacte xUSD-wisselkoers. De afzender zou moeten wachten tot een blok werd gedolven, en de mijnwerker moest de ruilprijs opnemen in de block-header. Er zaten echter gaten in deze oplossing - vervelende.

Stel je een vijandige aanvaller voor met zowel het geld als de kennis van dit deel van de code van Haven. Na het opzetten van de infrastructuur om 51% van de hash van Haven te verkrijgen, konden ze zowel de mijnwerker als de afzender worden en zo hun eigen xUSD-wisselkoersen bepalen. Deze mogelijkheid was, laten we zeggen, suboptimaal!

Dus in de volgende testnethebben we besloten om de verantwoordelijkheid terug te schuiven naar de afzender, maar alleen zodat ze het laatste geverifieerde prijsrecord in de keten van Haven (het prijsrecord van het bovenste blok) konden nemen en specificeren welk blok ze in de transactie gebruikten. Dit kon worden gecontroleerd en geverifieerd door miners en daemons, die ook konden controleren of inputs en outputs gelijk waren, niet in munten, maar in dollarwaarde (kritiek voor xUSD).

Dit bewijs van waarde werd de sleutel tot het succes van Haven. Maar het hierboven beschreven model bleek ook kwetsbaar voor aanvallen. Er kwamen verschillende lessen uit de volgende xUSD-testnets die met ons team en de gemeenschap werden uitgevoerd. Ten eerste hebben we geleerd dat een kortere ketting het systeem kan bespelen. Ten tweede leerden we dat we een manier nodig hadden om het circulerende aanbod van xUSD (en toekomstige xAssets) te laten zien, anders konden we nooit de gezondheid van het netwerk van Haven bepalen.

De volgende ontwikkelingsfase bracht ons op een ander pad. Zoals hierboven vermeld, was het bewijzen van de waarde van een transactie de sleutel, en we moesten het bewijs van Monero inputs = outputs vervangen door het bewijs van dollarwaarde voor xUSD-uitwisselingen.

We hebben meer dan een dozijn verschillende bewijzen, controles en validaties geprobeerd. Maar we hebben ontdekt dat tenzij je XHV en daadwerkelijk verzendt geen ander type activa, wat we bij privétesten deden, raakt het hele systeem in de war na een paar achterwaartse en voorwaartse transacties. Hoe complexer de uitwisselingen, hoe moeilijker het werd om de dollarwaarde van een transactie te verifiëren. Voer vervolgens meerdere transacties in, die grote hoeveelheden invoer moesten omvatten, en de zaken raakten echt in de war.

Deze uitdagingen hielden allemaal verband met de manier waarop handtekeningen voor toezeggingen werken, wat een absolute vereiste is in Monero. Tenzij uw toezeggingen geldig zijn, kunt u nooit verifiëren dat het geld niet vanuit het niets is gecreëerd.

Op dit punt hebben we besloten om het oude model van "gekleurde munten”Die eerder bovenop Bitcoin is gelegd, waardoor een nieuwe set informatie ontstaat over munten die worden uitgewisseld. Door gekleurde munten te gebruiken, kunnen transacties worden "gekleurd" met specifieke attributen. Dit verandert effectief gekleurde munten in tokens, die kunnen worden gebruikt om alles weer te geven. Maar - en dit is van cruciaal belang - gekleurde munten kunnen alleen werken als u niet gebonden bent aan de verbintenisstructuur van Monero.

Dus dat is de uitdaging die we aangingen: het aanpassen van Monero's verbintenisstructuur om het gebruik van "gekleurde munten" mogelijk te maken die onderscheid kunnen maken tussen XHV, xUSD en toekomstige xAssets op een enkele op Monero gebaseerde keten. En ik ben er trots op dat ik dat voor het eerst kan delen, we hebben precies dat gedaan.

We moesten Monero's vervangen meerlagige koppelbare spontane anonieme groep (MLSAG) handtekeningen met de nieuwere compacte koppelbare spontane anonieme groep (CLSAG) handtekeningen om dit te bereiken. Maar met een beetje hulp van een van de beste ontwikkelaars van Monero, Sarang Noetherwerkt de oplossing nu zoals bedoeld. We willen Sarang bedanken voor zijn hulp bij het navigeren door dit nieuwe coderingsschema.

Het resultaat van al dit testen en knutselen is dus het volgende: we hebben een nieuwe transactiestructuur gecreëerd met echte inputs als XHV en echte outputs als xUSD. Om van XHV naar xUSD te converteren, geven we XHV eigenlijk als invoer en xUSD als uitvoer. Daemons controleren vervolgens of het aantal uitgangen gelijk is op basis van de wisselkoers die is opgegeven in het blok dat de afzender heeft opgegeven als het prijsrecord. Dit gebeurt louter door het optellen van de verbintenismaskers en de wisselkoers die onafhankelijk worden opgehaald door verificateurs.

De logica is dat een verificateur altijd zijn eigen wisselkoers krijgt. De enige manier waarop een afzender een transactie kan verwerken, is door zowel die exacte wisselkoers als het exacte aantal invoer te kennen (wat alleen zij kunnen weten omdat het in hun portemonnee zit en elders onleesbaar is). De verificateur telt vervolgens de outputverplichtingen op en vergelijkt die met de inputs, rekening houdend met hun onafhankelijk verkregen wisselkoers. Ze moeten gelijk zijn om te slagen. Uiteraard zijn alle waarden versleuteld zodat niemand de bedragen kan zien of wijzigen.

Opmerking: de afzender kan alleen een reeds geverifieerd prijsrecord gebruiken, die momenteel allemaal zijn aangemaakt via Chainlink's XHV-orakel. Daemons lezen het prijsrecordnummer in de transactie en halen het record (de werkelijke prijs) uit de blokkop. Dit betekent dat de prijzen op het moment van gebruik al onveranderlijk zijn.

Dit is precies het type oplossing waarnaar we op zoek waren nadat we hadden nagedacht over het aanpakken van uitdagingen in verband met xUSD-uitwisselingsverificatie in het allereerste testnet. Deze oplossing werkt goed in onze privétests en zal de komende dagen worden gedeeld in onze volgende openbare podia.

Ervan uitgaande dat er tijdens het testen geen andere problemen worden geïdentificeerd, is dit de oplossing die we zullen gebruiken om xUSD live op het mainnet van Haven te lanceren. Als onderdeel van het lanceringsproces kijken we ernaar uit om de xUSD-uitwisselingscode die we het afgelopen jaar privé hebben ontwikkeld publiekelijk te delen om de allereerste private stablecoin te creëren.

Word intussen lid van de Haven-community en maak deel uit van de toekomst van financiële privacy. U kunt zich bij ons aansluiten Onenigheid en volg ons Twitter.

nl_NL_formalNederlands (Formeel)