Continuamos a nosa serie sobre a cadea de bloques de Monero, e o artigo de hoxe centrarase no protocolo RingCT (Ring Confidential Transactions), que introduce transaccións confidenciais e novas firmas de anel. Desafortunadamente, hai pouca información en Internet sobre como funciona, e intentamos cubrir este oco.
Falaremos de como a rede oculta as cantidades de transferencia mediante este protocolo, por que abandonaron as clásicas sinaturas de anel de criptonotes e como se desenvolverá aínda máis esta tecnoloxía.
Dado que este protocolo é unha das tecnoloxías máis complexas de Monero, o lector necesitará un coñecemento básico do deseño desta cadea de bloques e un coñecemento pasajero de criptografía de curvas elípticas (para repasar estes coñecementos, podes ler os primeiros capítulos do noso artigo anterior sobre ).
Protocolo RingCT
Un dos posibles ataques ás moedas criptográficas é a análise de cadeas de bloques baseada no coñecemento da cantidade e hora da transacción enviada. Isto permite reducir significativamente a área de busca de saídas de interese para o atacante. Para protexerse contra esa análise, Monero implementou un protocolo de transaccións anónimas que oculta completamente as cantidades de transferencias na rede.
Paga a pena notar que a idea de ocultar cantidades non é nova. O desenvolvedor de Bitcoin Core Greg Maxwell foi un dos primeiros en describilo no seu . A implementación actual de RingCT é a súa modificación coa posibilidade de usar sinaturas de anel (sexa sen elas), e así foi como recibiu o seu nome - Ring Confidential Transactions.
Entre outras cousas, o protocolo axuda a desfacerse dos problemas coa mestura de saídas de po - saídas dunha pequena cantidade (normalmente recibidas en forma de cambio das transaccións), que crearon máis problemas do que valían.
En xaneiro de 2017 tivo lugar unha bifurcación dura da rede Monero, que permitiu o uso opcional de transaccións confidenciais. E xa en setembro do mesmo ano, coa versión 6 hard fork, este tipo de transaccións convertéronse nas únicas permitidas na rede.
RingCT usa varios mecanismos á vez: sinaturas de grupos anónimos espontáneos vinculados con varias capas (sinatura de grupo anónimo espontáneo vinculable de varias capas, en adiante denominada MLSAG), un esquema de compromiso (Compromisos de Pedersen) e probas de rango (este termo non ten unha tradución establecida ao ruso) .
O protocolo RingCT introduce dous tipos de transaccións anónimas: simples e completas. A carteira xera o primeiro cando unha transacción usa máis dunha entrada, o segundo - na situación oposta. Diferéncianse na validación dos importes das transaccións e nos datos asinados cunha sinatura MLSAG (falaremos máis sobre isto a continuación). Ademais, as transaccións de tipo completo pódense xerar con calquera número de entradas, non hai diferenza fundamental. No libro Neste sentido, dise que a decisión de limitar as transaccións completas a unha entrada foi tomada con présa e pode cambiar no futuro.
Sinatura MLSAG
Lembremos cales son as entradas de transacción asinadas. Cada transacción gasta e xera algúns fondos. A xeración de fondos prodúcese creando saídas de transacción (unha analoxía directa son as facturas) e a saída que gasta a transacción (ao final, na vida real gastamos billetes) convértese na entrada (coidado, é moi fácil confundirse). aquí).
Unha entrada fai referencia a varias saídas, pero só gasta unha, creando así unha "cortina de fume" para dificultar a análise do historial de tradución. Se unha transacción ten máis dunha entrada, entón tal estrutura pódese representar como unha matriz, onde as filas son as entradas e as columnas son as saídas mixtas. Para demostrar á rede que a transacción gasta exactamente as súas saídas (coñece as súas claves secretas), as entradas asínanse cunha sinatura de anel. Tal sinatura garante que o asinante coñecía as claves secretas de todos os elementos de calquera das columnas.
As transaccións confidenciais xa non usan as clásicas sinaturas de anel, foron substituídas por MLSAG, unha versión de sinaturas de anel dunha soa capa similares adaptadas para múltiples entradas, .
Chámanse multicapa porque asinan varias entradas á vez, cada unha das cales se mestura con varias outras, é dicir, asinase unha matriz e non unha fila. Como veremos máis adiante, isto axuda a aforrar o tamaño da sinatura.
Vexamos como se forma unha sinatura de anel, usando o exemplo dunha transacción que gasta 2 saídas reais e usa m - 1 aleatorias da cadea de bloques para mesturar. Denotemos as claves públicas das saídas que gastamos
, e as imaxes clave para eles en consecuencia: Así, obtemos unha matriz de tamaño 2 x m. En primeiro lugar, necesitamos calcular os chamados desafíos para cada par de saídas:
Comezamos os cálculos coas saídas, que gastamos usando as súas claves públicas:e números aleatoriosComo resultado, obtemos os seguintes valores:
, que usamos para calcular o desafío
o seguinte par de saídas (para facilitar a comprensión do que estamos substituíndo onde, destacamos estes valores en diferentes cores). Todos os seguintes valores calcúlanse nun círculo usando as fórmulas dadas na primeira ilustración. O último que hai que calcular é o desafío para un par de saídas reais.
Como podemos ver, todas as columnas excepto a que contén resultados reais usan números xerados aleatoriamente. Para π- columna tamén os necesitaremos. Transformemosen s:
A sinatura en si é unha tupla de todos estes valores:
Estes datos son entón escritos nunha transacción.
Como podemos ver, MLSAG contén só un desafío c0, que permite aforrar o tamaño da sinatura (que xa require moito espazo). Ademais, calquera inspector, utilizando os datos, restaura os valores c1,…, cm e compróbao. Así, o noso anel está pechado e a sinatura foi verificada.
Para as transaccións RingCT do tipo completo, engádese unha liña máis á matriz con saídas mixtas, pero diso falaremos a continuación.
Compromisos de Pedersen
(o termo inglés compromisos úsase con máis frecuencia) utilízanse para que unha das partes poida demostrar que coñece un determinado segredo (número) sen revelalo realmente. Por exemplo, tiras un número determinado no dado, consideras o compromiso e pasasllo á parte verificadora. Así, no momento de revelar o número secreto, o verificador calcula de forma independente o compromiso, asegurándose así de que non o enganou.
Os compromisos de Monero úsanse para ocultar os importes das transferencias e utilizar a opción máis común: os compromisos de Pedersen. Por certo, un feito interesante: nun primeiro momento, os desenvolvedores propuxeron ocultar as cantidades mediante a mestura ordinaria, é dicir, engadir saídas a cantidades arbitrarias para introducir incerteza, pero despois pasaron a compromisos (non é un feito que aforrasen). o tamaño da transacción, como veremos a continuación).
En xeral, o compromiso é así:
Onde C - o significado do propio compromiso, a - cantidade oculta, H é un punto fixo na curva elíptica (xerador adicional) e x — algún tipo de máscara arbitraria, un factor de ocultación xerado ao azar. A máscara é necesaria aquí para que un terceiro non poida simplemente adiviñar o valor do compromiso.
Cando se xera unha nova saída, a carteira calcula o compromiso por ela e, cando se gasta, toma o valor calculado durante a xeración ou recalcúlao, dependendo do tipo de transacción.
RingCT sinxelo
No caso de transaccións RingCT simples, para garantir que a transacción crease saídas nunha cantidade igual á cantidade de entradas (non produciu diñeiro da nada), é necesario que a suma dos compromisos do primeiro e do segundo son os mesmos, é dicir:
As comisións de compromiso considérano un pouco diferente, sen máscara:
onde a — O importe da comisión, está a disposición do público.
Este enfoque permítenos demostrar á parte de confianza que estamos a utilizar as mesmas cantidades sen revelalas.
Para aclarar as cousas, vexamos un exemplo. Digamos que unha transacción gasta dúas saídas (o que significa que se converten en entradas) de 10 e 5 XMR e xera tres saídas por valor de 12 XMR: 3, 4 e 5 XMR. Ao mesmo tempo, paga unha comisión de 3 XMR. Así, a cantidade de diñeiro gastada máis a cantidade xerada e a comisión é igual a 15 XMR. Intentemos calcular os compromisos e ver a diferenza nos seus importes (lembrade as matemáticas):
Aquí vemos que para que a ecuación converxa, necesitamos que as sumas das máscaras de entrada e saída sexan iguais. Para iso, a carteira xera aleatoriamente x1, y1, y2 e y3, e o resto x2 calcula así:
Usando estas máscaras, podemos demostrar a calquera verificador que non xeramos máis fondos dos que gastamos, sen revelar a cantidade. Orixinal, non?
RingCT cheo
Nas transaccións RingCT completas, comprobar os importes das transferencias é un pouco máis complicado. Nestas transaccións, a carteira non recalcula os compromisos para as entradas, senón que utiliza os calculados cando se xeraron. Neste caso, debemos supoñer que xa non obteremos a diferenza das sumas igual a cero, senón que:
Aquí z — diferenza entre as máscaras de entrada e saída. Se temos en conta zG como chave pública (que de facto é), entón z é a clave privada. Así, coñecemos as claves públicas e privadas correspondentes. Con estes datos na man, podemos usalos na sinatura do anel MLSAG xunto coas claves públicas das saídas que se mesturan:
Así, unha sinatura de anel válida asegurará que coñecemos todas as claves privadas dunha das columnas e só podemos coñecer a clave privada da última fila se a transacción non xera máis fondos dos que gasta. Por certo, aquí está a resposta á pregunta "por que a diferenza de importes de compromisos non leva a cero" - se zG = 0, entón ampliaremos a columna con saídas reais.
Como sabe o destinatario dos fondos cantos cartos lle foron enviados? Aquí todo é sinxelo: o remitente da transacción e o destinatario intercambian as claves mediante o protocolo Diffie-Hellman, utilizando a clave de transacción e a clave de vista do destinatario e calcula o segredo compartido. O remitente escribe datos sobre os importes de saída, cifrados con esta chave compartida, en campos especiais da transacción.
Probas de rango
Que pasa se usa un número negativo como importe nos compromisos? Isto pode levar á xeración de moedas adicionais! Este resultado é inaceptable, polo que hai que garantir que as cantidades que utilizamos non sexan negativas (sen revelar estas cantidades, claro, se non hai tanto traballo e todo en balde). Noutras palabras, debemos demostrar que a suma está no intervalo [0, 2n - 1].
Para iso, a suma de cada saída divídese en díxitos binarios e o compromiso calcúlase para cada díxito por separado. É mellor ver como ocorre isto cun exemplo.
Supoñamos que as nosas cantidades son pequenas e caben en 4 bits (na práctica son 64 bits) e creamos unha saída por valor de 5 XMR. Calculamos os compromisos para cada categoría e o compromiso total para o importe total:
A continuación, cada compromiso mestúrase cun substituto (Ci-2iH) e está asinado por parellas coa sinatura do anel Borromeo (outra sinatura do anel), proposta por Greg Maxwell en 2015 (podes ler máis sobre ela). ):
En conxunto, isto denomínase proba de intervalo e permítelle garantir que os compromisos utilizan cantidades dentro do intervalo [0, 2n - 1].
Cal é o próximo?
Na implementación actual, as probas de rango ocupan moito espazo: 6176 bytes por saída. Isto leva a transaccións máis grandes e, polo tanto, taxas máis altas. Para reducir o tamaño dunha transacción de Monero, os desenvolvedores están a introducir a proba de balas en lugar das sinaturas Borromeo, un mecanismo de proba de rango sen compromisos por bits. , son capaces de reducir o tamaño da proba de rango ata un 94%. Por certo, a mediados de xullo pasou a tecnoloxía de Kudelski Security, que non revelou deficiencias significativas nin na propia tecnoloxía nin na súa implementación. A tecnoloxía xa se usa na rede de proba, e coa nova bifurcación dura, probablemente poida pasar á rede principal.
Fai as túas preguntas, suxire temas para novos artigos sobre tecnoloxías no campo da criptomoeda e tamén subscríbete ao noso grupo en para estar ao día dos nosos eventos e publicacións.
Fonte: www.habr.com