Seraphis: Hvad Det Vil Gør for Monero

Dette indlæg beskriver Seraphis, et sæt af transaktionsprotokolstrukturer og abstraktioner udviklet af pseudonym forskningsbidragyder koe for Monero-økosystemet og med løbende sikkerhedsanalyse af pseudonym bidragyder coinstudent2048.
Vi foretager nogle forenklinger og udelader visse tekniske detaljer for overskuelighedens skyld; af denne grund, og fordi designet af Seraphis stadig er i gang, bør interesserede læsere henvise til Seraphis-dokumentationen for at få den mest opdaterede information.

Protokoller som Bitcoin og Monero og andre er afhængige af en såkaldt "outputmodel", hvor et output er en repræsentation af værdi, der kan overføres.
Transaktioner forbruger et eller flere output styret af en afsender og genererer nye output rettet mod modtagere (eller tilbage til afsenderen som ændring); transaktionen skal balancere ved, at forbrugte output skal indeholde en samlet værdi, der nøjagtigt svarer til værdien i nye output (plus et netværkspålagt gebyr).
I mange protokoller som Bitcoin er værdien indeholdt i et output skrevet i det klare, og det samme er modtageren.
Ved at se på blockchain er det desuden trivielt at se, om og hvornår et output er blevet brugt (det vil sige, om det er blevet forbrugt i en senere transaktion, og hvilken transaktion brugt det).

Derimod introducerer protokoller som Monero et andet design:

• Outputværdier er skjulte og ikke synlige på blockchain
• Modtageradresser er skjult ved brug af en engangsadresseringsprotokol
• Hvorvidt et output er blevet brugt eller ej, skjules af brugen af tvetydige signaturer

Resultatet er, at det, uden ekstern information, er vanskeligt at afgøre, om et givent output er blevet brugt, hvad dets værdi er, og hvem dets modtager er.

Den nuværende Monero-transaktionsprotokol kaldes RingCT og bruger flere kryptografiske byggeklodser til at nå disse designmål.

• Forpligtelser skjuler beløb på en matematisk nyttig måde
• Rækkeviddebevis forhindrer overløb, der kan puste forsyningen op
• Ringsignaturer, der kan knyttes, giver underskriverens tvetydighed og forhindrer dobbeltforbrugsforsøg
• Forpligtelsesudligninger hævder, at transaktionerne balancerer

Disse byggeklodser er omhyggeligt sammenflettet for at bygge RingCT-protokollen.

En nyttig egenskab ved RingCT-protokollen er, at nogle byggeklodser kan ændres eller opgraderes på en måde, der holder det overordnede design og egenskaber intakte, men som kan give effektivitets- eller sikkerhedsforbedringer. Faktisk er denne slags opgraderinger forekommet (eller er planlagt til at forekomme) flere gange i Moneros historie. Rækkeviddebeviser i den originale RingCT-protokol var omfangsrige og langsomme; de blev senere opdateret til en konstruktion kaldet Bulletproofs der gjorde transaktioner mindre og hurtigere med bedre sikkerhedsanalyse og er planlagt til at blive opdateret til en nyere konstruktion kaldet Bulletproofs+ for endnu større effektivitetsfordele.

En lignende proces blev gennemgået med den sammenknyttede ringsignaturbyggeblok. I den originale protokol, en konstruktion kaldet MLSAG blev brugt. Dette blev senere opdateret til en nyere konstruktion kaldet CLSAG det er hurtigere, resulterer i mindre transaktioner og har bedre sikkerhedsanalyse. En endnu nyere linkbar ringsignaturkonstruktion baseret på Triptykon blev foreslået, men dette blev ikke valgt til implementering på grund af dets indvirkning på multisignaturoperationer.

Seraphis tager denne idé et skridt videre.
I stedet for at opdatere individuelle byggeklodser i den eksisterende RingCT-transaktionsprotokol introducerer den en anden protokol, der kan drage fordel af forskellige byggeklodser og tilbyde forbedret funktionalitet.

Seraphis bruger et andet sæt kryptografiske byggeklodser til at nå sine designmål.

• Forpligtelser skjuler stadig beløb
• Rangebevis forhindrer stadig overløb og forsyningsinflation
• Medlemskabsbeviser giver underskriverens uklarhed
• Forpligtelsesforskydninger hævder stadig balance
• Godkendende beviser forhindrer dobbeltforbrugsforsøg

Bemærk ændringen her: linkbare ringesignaturer erstattes med en kombination af medlemskabsbeviser og autoriserende beviser. Groft sagt viser medlemsbeviser, at et forbrugt output er en del af et større sæt, svarende til hvad der sker i RingCT. Men i modsætning til RingCT involverer medlemskabsbeviser slet ikke linkings-tagget! Godkendelsesbeviser viser, at det linkende tag er gyldigt og bruges til at underskrive den endelige transaktion.

Fordi RingCT bager linking-tagget ind i den tvetydige signatur, er signerings- (og multisignatur-) operationer mere beregningsintensive, og det bliver mere udfordrende at bygge anden tag-relateret funktionalitet. Men i Seraphis kan konstruktion af medlemskabsbeviser sikkert delegeres fra højt betroede enheder (som kan have begrænset computerkraft, som en hardware tegnebog) til en mindre betroet enhed, og signering (og multisignatur) operationer er langt nemmere ved at bruge det meget simplere godkendelsesbevis .

Heldigvis findes nogle af de byggeklodser, der kræves af Seraphis, allerede andre steder og behøver ikke at designes fra bunden. Både Bulletproofs og Bulletproofs+ konstruktionerne kan bruges som rækkeviddebevis. Ændringer af bevissystemer af Schnorr-typen kan bruges til at godkende beviser. Og et effektivt prøvesystem, der allerede bruges som grundlaget for Triptykon, Lelantus og Spark^* kan modificeres for medlemskabsbeviser.

^* Cypher Stack modtager støtte til Spark-udvikling.

Desværre er Monero-adresser, der er i brug, ikke kompatible med Seraphis. Brugere ville skulle generere nye adresser fra deres tegnebogsnøgler for at modtage Monero, hvis Seraphis blev implementeret. Disse økosystemomkostninger kommer dog med en række fordele.

Bortset fra de strukturelle fordele, der er diskuteret ovenfor, er Seraphis-designet modtageligt for mange forskellige adressekonstruktionsmuligheder, som hver især kommer med afvejninger. Mens den endelige adressekonstruktion, der skal bruges i Seraphis, er besluttes stadig (en ordning, der får meget opmærksomhed, kaldes JAMTIS), kan vi beskrive nogle almindelige og nyttige funktioner.

Du ved måske, at Monero-adresser tilbyder visningsnøgle-funktionalitet, hvor du kan levere en visningsnøgle til en enhed eller tredjepart og tillade den at se efter indgående udgange på dine vegne, men uden at give op bruge myndighed. Dette er nyttigt til tegnebøger, som kan holde sig opdateret, mens du holder din forbrugsnøgle sikkert låst væk. Det er også nyttigt i tilfælde, hvor du ønsker ekstern visningsadgang, såsom en offentlig velgørenhedsorganisation, der tilbyder gennemsigtighed, eller en virksomhed med en regnskabsafdeling.

Ulempen ved Monero-visningsnøgler er, at de ikke giver fuldstændig eller finmasket visningsadgang. Det er ikke muligt pålideligt at registrere, hvornår en tegnebog bruger penge, hvilket gør det vanskeligt at beregne tegnebogssaldi korrekt, når forbrugsnøglen ikke er tilgængelig. Det er heller ikke i øjeblikket muligt at detektere indgående output uden også at lære værdien indeholdt i disse output (hvilket betyder, at enhver tredjepart, der er ansvarlig for at finde indgående output, vil lære præcis, hvor meget Monero du erhverver).

Seraphis adresseringskonstruktioner kan løse dette. Med Seraphis er din adresse udstyret med forskellige nøgler, der kan gøre forskellige ting:

• Hold øje med indgående output, men skjul deres værdi
• Hold øje med indgående output, men vis deres værdi
• Hold øje med udgående udgange
• Hjælpe dig med at generere transaktioner, men ikke underskrive dem
• Generer nye adresser (nyttigt for forhandlere eller børser med mange kunder)

Som adresseindehaver kan du bestemme, hvor meget autoritet du uddelegerer til andre enheder eller tredjeparter.

Seraphis er en stor ændring af Monero-økosystemet. Selvom det involverer ændringer af adresser og transaktionsbyggeblokke, tilbyder dets design fleksibilitet og nyttig funktionalitet, som ikke er mulig med dagens RingCT-protokol. Mens meget af designet er færdiggjort og udviklet til en implementering, adressedesign og sikkerhedsanalyse er i gang. Seraphis tilbyder en fremragende mulighed for at skubbe Monero-økosystemet fremad!