Continuem amb la nostra sèrie sobre la cadena de blocs de Monero, i l'article d'avui se centrarà en el protocol RingCT (Ring Confidential Transactions), que introdueix transaccions confidencials i noves signatures d'anell. Malauradament, a Internet hi ha poca informació sobre com funciona, i hem intentat omplir aquest buit.
Parlarem de com la xarxa amaga les quantitats de transferència mitjançant aquest protocol, per què van abandonar les clàssiques signatures d'anell de criptonotes i com es desenvoluparà encara més aquesta tecnologia.
Com que aquest protocol és una de les tecnologies més complexes de Monero, el lector necessitarà uns coneixements bàsics del disseny d'aquesta cadena de blocs i uns coneixements passatgers de criptografia de corbes el·líptiques (per repassar aquests coneixements, podeu llegir els primers capítols del nostre article anterior sobre ).
Protocol RingCT
Un dels possibles atacs a les monedes criptonotes és l'anàlisi de la cadena de blocs basada en el coneixement de la quantitat i el temps de la transacció enviada. Això permet redueix significativament l'àrea de cerca de sortides d'interès per a l'atacant. Per protegir-se d'aquesta anàlisi, Monero ha implementat un protocol de transaccions anònims que amaga completament les quantitats de transferències a la xarxa.
Val la pena assenyalar que la idea d'ocultar quantitats no és nova. El desenvolupador de Bitcoin Core, Greg Maxwell, va ser un dels primers a descriure-ho . La implementació actual de RingCT és la seva modificació amb la possibilitat d'utilitzar signatures d'anell (ja sigui sense elles), i així va rebre el seu nom - Ring Confidential Transactions.
Entre altres coses, el protocol ajuda a desfer-se dels problemes amb la barreja de sortides de pols: sortides d'una petita quantitat (normalment es reben en forma de canvi de transaccions), que van crear més problemes del que valien.
El gener de 2017 es va produir una bifurcació dura de la xarxa Monero, que va permetre l'ús opcional de transaccions confidencials. I ja al setembre del mateix any, amb la versió 6 hard fork, aquestes transaccions es van convertir en les úniques permeses a la xarxa.
RingCT utilitza diversos mecanismes alhora: signatures de grups anònims espontànies enllaçades de diverses capes (signatura de grup anònim espontani enllaçable de múltiples capes, d'ara endavant MLSAG), un esquema de compromís (Compromisos de Pedersen) i proves de rang (aquest terme no té una traducció establerta al rus) .
El protocol RingCT introdueix dos tipus de transaccions anònimes: simples i completes. La cartera genera la primera quan una transacció utilitza més d'una entrada, la segona, en la situació oposada. Es diferencien en la validació dels imports de les transaccions i les dades signades amb una signatura MLSAG (en parlarem més a continuació). A més, les transaccions de tipus full es poden generar amb qualsevol nombre d'entrades, no hi ha cap diferència fonamental. En el llibre En aquest sentit, es diu que la decisió de limitar les transaccions completes a una entrada es va prendre de pressa i pot canviar en el futur.
Signatura MLSAG
Recordem quines són les entrades de transacció signades. Cada transacció gasta i genera alguns fons. La generació de fons es produeix creant sortides de transaccions (una analogia directa són les factures) i la sortida que gasta la transacció (al cap i a la fi, a la vida real gastem bitllets) es converteix en l'entrada (compte, és molt fàcil confondre's). aquí).
Una entrada fa referència a múltiples sortides, però només en gasta una, creant així una "corta de fum" per dificultar l'anàlisi de l'historial de traduccions. Si una transacció té més d'una entrada, llavors aquesta estructura es pot representar com una matriu, on les files són les entrades i les columnes són les sortides mixtes. Per demostrar a la xarxa que la transacció gasta exactament les seves sortides (coneix les seves claus secretes), les entrades es signen amb una signatura d'anell. Aquesta signatura garanteix que el signant coneixia les claus secretes de tots els elements de qualsevol de les columnes.
Les transaccions confidencials ja no utilitzen les clàssiques signatures d'anell, van ser substituïdes per MLSAG: una versió de signatures d'anell d'una sola capa similars adaptades per a múltiples entrades, .
S'anomenen multicapa perquè signen diverses entrades alhora, cadascuna de les quals es barreja amb diverses altres, és a dir, es signa una matriu i no una fila. Com veurem més endavant, això ajuda a estalviar la mida de la signatura.
Vegem com es forma una signatura d'anell, utilitzant l'exemple d'una transacció que gasta 2 sortides reals i utilitza m - 1 aleatòries de la cadena de blocs per a la barreja. Denotem les claus públiques de les sortides que gastem com a
, i les imatges clau per a ells en conseqüència: Així, obtenim una matriu de mida 2 x m. En primer lloc, hem de calcular els anomenats reptes per a cada parell de sortides:
Comencem els càlculs amb les sortides, que gastem utilitzant les seves claus públiques:i nombres aleatorisCom a resultat, obtenim els valors següents:
, que fem servir per calcular el repte
el següent parell de sortides (per facilitar la comprensió del que estem substituint on, hem destacat aquests valors en diferents colors). Tots els valors següents es calculen en cercle mitjançant les fórmules que es donen a la primera il·lustració. L'últim que cal calcular és el repte d'un parell de sortides reals.
Com podem veure, totes les columnes excepte la que conté sortides reals utilitzen números generats aleatòriament. Per π- columna també els necessitarem. Transformem-nosen s:
La signatura en si és una tupla de tots aquests valors:
A continuació, aquestes dades s'escriuen en una transacció.
Com podem veure, MLSAG només conté un repte c0, que us permet estalviar la mida de la signatura (que ja requereix molt d'espai). A continuació, qualsevol inspector, utilitzant les dades, restaura els valors c1,…, cm i ho comprova. Així, el nostre anell està tancat i s'ha verificat la signatura.
Per a les transaccions RingCT del tipus complet, s'afegeix una línia més a la matriu amb sortides mixtes, però en parlarem a continuació.
Compromisos de Pedersen
(el terme anglès compromisos s'utilitza més sovint) s'utilitzen perquè una part pugui demostrar que coneix un determinat secret (número) sense revelar-lo realment. Per exemple, tireu un nombre determinat al dau, considereu el compromís i el transmeteu a la part verificadora. Així, en el moment de revelar el número secret, el verificador calcula de manera independent el compromís, assegurant-se així que no l'heu enganyat.
Els compromisos Monero s'utilitzen per ocultar els imports de les transferències i utilitzar l'opció més habitual: els compromisos de Pedersen. Per cert, un fet interessant: al principi, els desenvolupadors van proposar amagar les quantitats mitjançant la barreja ordinària, és a dir, afegir sortides per a quantitats arbitràries per introduir incertesa, però després van passar als compromisos (no és un fet que estalviessin en la mida de la transacció, com veurem a continuació).
En general, el compromís és el següent:
On C - el significat del propi compromís, a - quantitat oculta, H és un punt fix de la corba el·líptica (generador addicional) i x — algun tipus de màscara arbitrària, un factor d'ocultació generat aleatòriament. La màscara és necessària aquí perquè un tercer no pugui endevinar simplement el valor del compromís.
Quan es genera una nova sortida, la cartera calcula el compromís per a ella i, quan es gasta, pren el valor calculat durant la generació o el recalcula, depenent del tipus de transacció.
RingCT senzill
En el cas de transaccions RingCT simples, per tal d'assegurar que la transacció creï sortides en una quantitat igual a la quantitat d'inputs (no produïa diners de la nada), és necessari que la suma dels compromisos del primer i el segon seran els mateixos, és a dir:
Les comissions de compromís ho consideren una mica diferent, sense màscara:
On a — L'import de la comissió, està a disposició del públic.
Aquest enfocament ens permet demostrar a la part de confiança que estem utilitzant les mateixes quantitats sense revelar-les.
Per aclarir les coses, mirem un exemple. Suposem que una transacció gasta dues sortides (és a dir, es converteixen en entrades) de 10 i 5 XMR i genera tres sortides per valor de 12 XMR: 3, 4 i 5 XMR. Al mateix temps, paga una comissió de 3 XMR. Així, la quantitat de diners gastada més la quantitat generada i la comissió és igual a 15 XMR. Intentem calcular els compromisos i veure la diferència en els seus imports (recordeu les matemàtiques):
Aquí veiem que perquè l'equació convergi, necessitem que les sumes de les màscares d'entrada i de sortida siguin iguals. Per fer-ho, la cartera es genera aleatòriament x1, y1, y2 i y3, i la resta x2 calcula així:
Amb aquestes màscares, podem demostrar a qualsevol verificador que no generem més fons dels que gastem, sense revelar l'import. Original, oi?
RingCT ple
En les transaccions completes de RingCT, comprovar els imports de la transferència és una mica més complicat. En aquestes transaccions, la cartera no recalcula els compromisos per a les entrades, sinó que utilitza els calculats quan es van generar. En aquest cas, hem de suposar que ja no obtindrem la diferència de les sumes iguals a zero, sinó que:
Aquí z — diferència entre les màscares d'entrada i de sortida. Si tenim en compte zG com a clau pública (que és de facto), doncs z és la clau privada. Així, coneixem les claus públiques i privades corresponents. Amb aquestes dades a la mà, les podem utilitzar a la signatura d'anell MLSAG juntament amb les claus públiques de les sortides que es barregen:
Així, una signatura d'anell vàlida garantirà que coneixem totes les claus privades d'una de les columnes, i només podrem conèixer la clau privada de l'última fila si la transacció no genera més fons dels que gasta. Per cert, aquí teniu la resposta a la pregunta "per què la diferència en els imports dels compromisos no condueix a zero" - si zG = 0, llavors ampliarem la columna amb sortides reals.
Com sap el destinatari dels fons quants diners li van enviar? Aquí tot és senzill: el remitent de la transacció i el destinatari intercanvien les claus mitjançant el protocol Diffie-Hellman, utilitzant la clau de transacció i la clau de vista del destinatari i calcula el secret compartit. El remitent escriu dades sobre les quantitats de sortida, xifrades amb aquesta clau compartida, en camps especials de la transacció.
Proves de rang
Què passa si utilitzeu un nombre negatiu com a import en compromisos? Això pot provocar la generació de monedes addicionals! Aquest resultat és inacceptable, així que hem de garantir que les quantitats que utilitzem no siguin negatives (sense revelar aquestes quantitats, és clar, sinó hi ha molta feina i tot en va). En altres paraules, hem de demostrar que la suma està a l'interval [0, 2n - 1].
Per fer-ho, la suma de cada sortida es divideix en dígits binaris i el compromís es calcula per a cada dígit per separat. És millor veure com passa això amb un exemple.
Suposem que les nostres quantitats són petites i encaixen en 4 bits (a la pràctica això són 64 bits) i creem una sortida per valor de 5 XMR. Calculem els compromisos per a cada categoria i el compromís total per a l'import total:
A continuació, cada compromís es barreja amb un substitut (Ci-2iH) i està signat per parelles amb la signatura de l'anell Borromeo (una altra signatura de l'anell), proposada per Greg Maxwell el 2015 (podeu llegir-ne més informació). ):
En conjunt, això s'anomena prova d'interval i us permet assegurar-vos que els compromisos utilitzen quantitats dins l'interval [0, 2n - 1].
Què serà el següent?
En la implementació actual, les proves de rang ocupen molt d'espai: 6176 bytes per sortida. Això comporta transaccions més grans i, per tant, comissions més elevades. Per reduir la mida d'una transacció de Monero, els desenvolupadors estan introduint a prova de bales en lloc de signatures Borromeo, un mecanisme de prova de rang sense compromisos per bits. , són capaços de reduir la mida de la prova de rang fins a un 94%. Per cert, a mitjans de juliol la tecnologia va passar de Kudelski Security, que no va revelar cap mancança significativa ni en la pròpia tecnologia ni en la seva implementació. La tecnologia ja s'utilitza a la xarxa de proves, i amb la nova bifurcació dura, probablement es pot passar a la xarxa principal.
Feu les vostres preguntes, suggeriu temes per a nous articles sobre tecnologies en el camp de la criptomoneda i també subscriviu-vos al nostre grup a per estar al dia dels nostres esdeveniments i publicacions.
Font: www.habr.com