Seraphis: Wat Het Zal Doen voor Monero

Dit bericht beschrijft Seraphis, een reeks transactieprotocolstructuren en abstracties ontwikkeld door pseudonieme onderzoeksmedewerker koe voor het Monero-ecosysteem, en met voortdurende beveiligingsanalyse door pseudonieme bijdrager coinstudent2048.
We maken enkele vereenvoudigingen en laten bepaalde technische details weg voor de duidelijkheid; om deze reden, en omdat het ontwerp van Seraphis nog in volle gang is, dienen geïnteresseerde lezers de documentatie van Seraphis te raadplegen voor de meest up-to-date informatie.

Protocollen zoals Bitcoin en Monero en andere vertrouwen op een zogenaamd "outputmodel" van de werking, waarbij een output een representatie is van waarde die kan worden overgedragen.
Transacties verbruiken een of meer outputs gecontroleerd door een afzender, en genereren nieuwe outputs gericht op ontvangers (of terug naar de afzender als wisselgeld); de transactie moet in evenwicht zijn aangezien verbruikte outputs een totale waarde moeten bevatten die exact gelijk is aan de waarde in nieuwe outputs (plus een door het netwerk opgelegde vergoeding).
In veel protocollen, zoals Bitcoin, wordt de waarde in een output duidelijk geschreven, net als de ontvanger.
Bovendien is het, door naar de blockchain te kijken, triviaal om te zien of en wanneer een output is uitgegeven (dat wil zeggen, of het is verbruikt in een latere transactie, en door welke transactie het is uitgegeven).

Daarentegen introduceren protocollen zoals Monero een ander ontwerp:

• Output-waarden zijn verborgen en niet zichtbaar op de blockchain
• Ontvangeradressen worden verborgen door het gebruik van een eenmalig adresseringsprotocol
• Of een output al dan niet is uitgegeven, wordt verdoezeld door het gebruik van dubbelzinnige handtekeningen

Het resultaat is dat het bij afwezigheid van externe informatie moeilijk is om te bepalen of een bepaalde output is uitgegeven, wat de waarde ervan is en wie de ontvanger is.

Het huidige Monero-transactieprotocol heet RingCT en gebruikt verschillende cryptografische bouwstenen om deze ontwerpdoelen te bereiken.

• Verplichtingen verbergen bedragen op een wiskundig handige manier
• Bereikbewijzen voorkomen overloop waardoor de toevoer kan worden opgeblazen
• Koppelbare ringhandtekeningen zorgen voor dubbelzinnigheid bij de ondertekenaar en voorkomen dubbele uitgaven
• Commitment offsets stellen dat transacties in evenwicht zijn

Deze bouwstenen zijn zorgvuldig met elkaar verweven om het RingCT-protocol te bouwen.

Een handige eigenschap van het RingCT-protocol is dat sommige bouwstenen zodanig kunnen worden gewijzigd of geüpgraded dat het algehele ontwerp en de eigenschappen intact blijven, maar dat efficiëntie- of beveiligingsverbeteringen kan opleveren. In de geschiedenis van Monero zijn dit soort upgrades zelfs meerdere keren voorgekomen (of zijn gepland). Bereikbewijzen in het oorspronkelijke RingCT-protocol waren omvangrijk en traag; ze werden later geüpdatet naar een constructie genaamd Bulletproofs die transacties kleiner en sneller maakte met betere beveiligingsanalyse, en het is de bedoeling dat ze worden geüpdatet naar een nieuwere constructie genaamd Bulletproofs+ voor nog grotere efficiëntievoordelen.

Een soortgelijk proces werd ondergaan met de bouwsteen van de koppelbare ringsignatuur. In het oorspronkelijke protocol werd een constructie met de naam MLSAG gebruikt. Dit werd later geüpdatet naar een nieuwere constructie genaamd CLSAG die sneller is, resulteert in kleinere transacties en een betere beveiligingsanalyse heeft. Er werd een nog nieuwere, koppelbare ringsignatuurconstructie voorgesteld, gebaseerd op Triptych, maar deze werd niet geselecteerd voor implementatie vanwege de gevolgen voor operaties met meerdere handtekeningen.

Seraphis gaat nog een stap verder met dit idee.
In plaats van individuele bouwstenen van het bestaande RingCT-transactieprotocol bij te werken, introduceert het een ander protocol dat kan profiteren van verschillende bouwstenen en een verbeterde functionaliteit biedt.

Seraphis gebruikt een andere set cryptografische bouwstenen om zijn ontwerpdoelen te bereiken.

• Toezeggingen verbergen nog steeds bedragen
• Bereikbewijzen voorkomen nog steeds overloop en voorraadinflatie
• Lidmaatschapsbewijzen zorgen voor dubbelzinnigheid van de ondertekenaar
• Commitment offsets behouden nog steeds saldo
• Bewijzen autoriseren voorkomen dat dubbele uitgaven worden gedaan

Let op de verandering hier: koppelbare ringhandtekeningen worden vervangen door een combinatie van lidmaatschapsbewijzen en machtigingsbewijzen. Grofweg laten lidmaatschapsbewijzen zien dat een verbruikte output deel uitmaakt van een grotere set, vergelijkbaar met wat er gebeurt in RingCT. Maar in tegenstelling tot RingCT, hebben lidmaatschapsbewijzen helemaal geen linktag nodig! Autorisatiebewijzen tonen aan dat de linking tag geldig is en worden gebruikt om de uiteindelijke transactie te ondertekenen.

Omdat RingCT de koppelingstag in de dubbelzinnige handtekening bakt, zijn ondertekenings- (en multisignatuur-) bewerkingen meer rekenintensief en wordt het een grotere uitdaging om andere taggerelateerde functionaliteit te bouwen. Maar in Seraphis kan het samenstellen van lidmaatschapsbewijzen veilig worden gedelegeerd van zeer vertrouwde apparaten (die mogelijk beperkte rekenkracht hebben, zoals een hardware portefeuille) naar een minder vertrouwd apparaat, en ondertekenings- (en meervoudige handtekeningen) bewerkingen zijn veel eenvoudiger met behulp van het veel eenvoudigere autorisatiebewijs .

Gelukkig bestaan sommige van de bouwstenen die Seraphis nodig heeft al elders en hoeven ze niet vanaf nul te worden ontworpen. Zowel de Bulletproofs als de Bulletproofs+ constructies kunnen gebruikt worden als range proofs. Wijzigingen aan testsystemen van het Schnorr-type kunnen worden gebruikt voor het autoriseren van bewijzen. En een efficiënt testsysteem dat al wordt gebruikt als basis voor Triptych, Lelantus en Spark^* kan worden aangepast voor lidmaatschapsbewijzen.

^* Cypher Stack ontvangt financiering voor Spark-ontwikkeling.

Helaas zijn de momenteel in gebruik zijnde Monero-adressen niet compatibel met Seraphis. Gebruikers zouden nieuwe adressen moeten genereren uit hun portefeuillesleutels om Monero te ontvangen als Seraphis zou zijn geïmplementeerd. Deze ecosysteemkosten brengen echter tal van voordelen met zich mee.

Afgezien van de hierboven besproken structurele voordelen, is het Seraphis-ontwerp vatbaar voor veel verschillende adresconstructiemogelijkheden, die allemaal gepaard gaan met compromissen. Hoewel de definitieve adresconstructie die in Seraphis zal worden gebruikt nog wordt besloten (een schema dat veel aandacht krijgt, heet JAMTIS), kunnen we enkele algemene en nuttige functies beschrijven.

U weet misschien dat Monero-adressen weergavesleutel-functionaliteit bieden, waarmee u een apparaat of een derde partij een weergavesleutel kunt geven en deze namens u naar inkomende output kunt laten kijken, maar zonder de uitgaven op te geven Gezag. Dit is handig voor portefeuilles, die up-to-date kunnen blijven terwijl uw uitgavensleutel veilig wordt opgeborgen. Het is ook handig voor gevallen waarin u toegang wilt tot externe weergaven, zoals een openbare liefdadigheidsinstelling die transparantie biedt of een bedrijf met een boekhoudafdeling.

Het nadeel van Monero-weergavetoetsen is dat ze geen volledige of fijnmazige weergavetoegang bieden. Het is niet mogelijk om op betrouwbare wijze te detecteren wanneer een portemonnee geld uitgeeft, wat het moeilijk maakt om het saldo van de portefeuille correct te berekenen wanneer de bestedingssleutel niet beschikbaar is. Het is momenteel ook niet mogelijk om inkomende outputs te detecteren zonder ook de waarde in die outputs te leren (wat betekent dat derden die verantwoordelijk zijn voor het vinden van inkomende outputs precies weten hoeveel Monero u verwerft).

Seraphis adresseringsconstructies kunnen dit oplossen. Met Seraphis is uw adres uitgerust met verschillende sleutels die verschillende dingen kunnen doen:

• Let op inkomende outputs maar verberg de waarde ervan
• Let op inkomende outputs, maar toon hun waarde
• Let op uitgaande outputs
• Help u om transacties te genereren, maar niet om ze te ondertekenen
• Genereer nieuwe adressen (handig voor winkeliers of uitwisselingen met veel klanten)

Als adreshouder mag u beslissen hoeveel bevoegdheid u delegeert aan andere apparaten of derden.

Seraphis is een grote verandering in het Monero-ecosysteem. Hoewel het aanpassingen aan adressen en transactiebouwstenen met zich meebrengt, biedt het ontwerp flexibiliteit en handige functionaliteit die niet mogelijk is met het huidige RingCT-protocol. Terwijl een groot deel van het ontwerp is voltooid en wordt ontwikkeld tot een implementatie, zijn adresontwerp en beveiligingsanalyse aan de gang. Seraphis biedt een uitstekende mogelijkheid om het Monero-ecosysteem vooruit te helpen!