Análisis en profundidad de la función de transacción privada de NEAR

No hace mucho, NEAR anunció una asociación con ZeroPool, que agregará soporte para funciones de transacciones privadas en el protocolo NEAR. Actualmente, en la plataforma de NEAR, todas las transacciones están disponibles públicamente, al igual que Bitcoin y Ethereum. Es decir, para cada transacción, la información como el remitente, el destinatario y el monto de la transacción están disponibles públicamente. El uso de este método puede garantizar que todos tengan derecho a auditar los libros de cuentas, confirmar la validez de la transacción y, al mismo tiempo, prevenir efectivamente la ocurrencia de gastos dobles. En muchos casos, el método de transacción ideal es: solo los participantes en la transacción pueden ver los detalles de la transacción. Cumplir con este requisito y garantizar que el libro mayor aún sea verificable es una tarea compleja que requiere el uso de técnicas criptográficas avanzadas. En este artículo, el autor analizará en profundidad cómo implementar la función de transacción privada en el sistema NEAR desde un punto de vista técnico, es decir, para garantizar que no se dañe el trabajo de verificar la corrección de la transacción, para que cada participante en la transacción y el monto de la transacción y otra información está oculta. Pasemos al tema: Salida no gastada En el ecosistema NEAR, generalmente usamos el modelo de cuenta como método de contabilidad, y el modelo UTXO (salida no gastada) se usa para transacciones privadas. Cada UTXO es una tupla, que contiene tres elementos: cantidad, destinatario y sal, donde la cantidad se refiere a la cantidad de la transacción, el destinatario es en realidad la clave pública del destinatario del pase y "sal" es solo un número aleatorio. Todos los UTXO se almacenan en un árbol de Merkle. El árbol de Merkle tiene una altura preestablecida. El valor de la altura determina el número de transacciones que puede procesar el conjunto de transacciones durante toda la vida útil del árbol de Merkle. Límites superior/inferior. Figura: UTXO Raíz de Merkle Cada rama (hoja) del árbol de Merkle es una UTXO o un valor nulo (valor vacío). Cada nulo representa una vacante, que se puede llenar en un nuevo UTXO en el futuro. Una vez que se completa un valor nulo, no puede volver al estado inicial. Todas las ramas están inicialmente en un estado vacío, es decir, todas son nulas. A excepción del receptor, el UTXO real no se revelará a nadie. Por lo tanto, las ramas del árbol de Merkle son en realidad hashes de UTXO, razón por la cual la "sal" debe existir. Sin él, una vez que Alice conoce la clave pública de Bob, puede usar diferentes números para verificar si la clave pública de Bob (valor hash) aparece en el árbol de Merkle, forzando así el monto de la transacción. En este punto, la transacción de Bob ya no es anónima. Imagen:  Transacción raíz de Merkel Supongamos que Alice quiere transferir algunos tokens a Bob en privado. El certificado que pertenece a Alice se almacena en UTXO y el receptor del certificado es equivalente a la clave pública de Alice. Para mantener la privacidad de la transacción, Alice crea una transacción de la siguiente forma: Esta transacción tiene 2 entradas y 2 salidas (el número exacto de entradas y salidas no tiene que ser 2, pero debe ser el mismo; esto es cierto para todas las transacciones ), donde la entrada es un UTXO existente, correspondiente a la rama del árbol de Merkle; la salida es un UTXO completamente nuevo, que se agregará al árbol de Merkle en el futuro. Cuando Alice inicia una transacción, si publica exactamente dos UTXO que se están gastando, la transacción se vinculará a la transacción que generó los dos UTXO. El propósito de establecer un grupo de transacciones es precisamente garantizar que dichos enlaces no se puedan establecer, para garantizar que no se liberen los UTXO de entrada. Entonces, la pregunta es, ¿cómo podemos asegurarnos de que durante el proceso de transacción, el nodo de verificación pueda confirmar que una transacción gasta el UTXO existente y, al mismo tiempo, no anunciará el UTXO real que se está gastando? Al igual que muchos motores de transacciones que preservan la privacidad, ZeroPool utiliza una prueba de conocimiento cero no interactiva (zk-SNARK) para lograr transacciones privadas. La prueba de conocimiento cero para un cálculo específico puede admitir las siguientes formas de prueba criptográfica: dada la entrada pública 1, la entrada pública 2... conocida la entrada privada 1, la entrada privada 2... puede obtener [alguna conclusión] dicho conocimiento. trabajos de prueba está más allá del alcance de este artículo. Para obtener más información sobre este tema, puede hacer clic en este enlace del blog. Si se quiere llegar a una transacción privada de la forma más sencilla, la prueba de conocimiento puede tener la siguiente forma: Dada una raíz de Merkle y dos valores hash OUT_HASH1 y OUT_HASH2, se sabe que existen cuatro UTXO de este tipo: IN1, IN2 , OUT1 , OUT2, dos certificados Merkel P1 y P2 y una clave privada x, los valores hash correspondientes a OUT1 y OUT2 son OUT_HASH1 y OUT_HASH2 respectivamente, los destinatarios en IN1 e IN2 son equivalentes a la clave pública X correspondiente a x; merkel Demuestre que P1 y P2 son pruebas válidas de que IN1 e IN2 están contenidos en un árbol de Merkle cuya raíz de Merkle ha sido determinada; la suma de las cantidades en IN1 e IN2 es igual a la suma de las cantidades en OUT1 y OUT2. La transacción contiene merkle_root, out_hash1, out_hash2 y prueba de conocimiento. Nada en la transacción revela el destinatario de la UTXO saliente, ni vincula la UTXO saliente a una UTXO entrante específica. Además, incluso la información como el monto de la transacción no se mostrará externamente durante la transacción. Por ejemplo: como se muestra en la figura anterior, supongamos que Alicia es la receptora del primer y tercer UTXO del árbol de Merkle, y las cantidades correspondientes son de $ 100 y $ 17 respectivamente. Alicia conoce estos dos UTXO, pero desconoce los demás UTXO. Si quiere enviar $42 a Bob, el enfoque habitual es que primero creará una transacción que use sus dos UTXO como entradas y cree dos salidas al mismo tiempo: una envía $42 a Bob y la otra enviará $42 a Bob, los $75 restantes vuelven a ella. Ella le dijo a la otra parte la UTXO que pertenece a Bob, pero solo ella conoce el resto de la UTXO y nadie más puede saberlo. Además, incluso el valor hash del UTXO de entrada se mantiene en secreto. El contrato inteligente es responsable del mantenimiento diario del conjunto de transacciones. Una vez que el contrato recibe dicha transacción, verificará la prueba de conocimiento. Una vez que la verificación sea correcta, se agregarán dos UTXO nuevos al árbol de Merkle. Después de que Bob reciba el UTXO de Alice, esperará un período de tiempo hasta que el valor hash del UTXO se incluya en el árbol de Merkle, y luego obtendrá estos tokens. Aunque este método parece sencillo, existe el problema de que se puede reutilizar la misma UTXO. Dado que nadie más que Alice conoce el valor hash del UTXO de entrada, el grupo de transacciones no puede eliminar el UTXO consumido del árbol de Merkle, porque ni siquiera sabe cuál comenzar a eliminar primero. Si Alice crea 2 pruebas diferentes de conocimiento cero, pero consume las mismas 2 entradas, todos pueden verificar que las dos transacciones consumen algo de UTXO que existía originalmente en el árbol de Merkle, pero no pueden conocer las dos transacciones. El UTXO consumido en realidad es el mismo. . Para resolver este problema, introducimos el concepto de anulador. En términos simples, el anulador es el valor hash de la UTXO y también la clave privada del receptor de la UTXO. Luego cambiamos la prueba de conocimiento de la transacción a lo siguiente: dada una raíz de Merkle y dos hashes OUT_HASH1 y OUT_HASH2, y otros dos hashes NULLIFIER1 y NULLIFIER2, los hashes correspondientes a OUT1 y OUT2 son OUT_HASH1 y OUT_HASH2 respectivamente; destinatarios en IN1 e IN2 son equivalentes a la clave pública X correspondiente a x; Las pruebas de Merkle P1 y P2 son pruebas válidas de inclusión de IN1 e IN2 en un árbol con una raíz de Merkle definida; IN1 e IN2 La suma en OUT1 y OUT2 es igual a la suma en OUT1 y OUT2; y hash(IN1,x) es igual a NULLIFIER1, y hash(IN2,x) es igual a NULLIFIER2 Tenga en cuenta que cualquier transacción que gaste un UTXO en particular calcula el mismo valor de NULLIFIER, porque NULLIFIER Depende del valor hash de UTXO y la clave privada correspondiente a la clave pública en UTXO. Dado que el NULLIFIER en la prueba de conocimiento anterior se encuentra en la declaración pública "dada" (Cláusula), si se han publicado dos transacciones que utilizan el mismo UTXO, todos pueden saber que tienen el mismo NULLIFIER y descartarlo. También vale la pena señalar que NULLIFIER no revelará ninguna información sobre el UTXO de entrada o la clave privada del destinatario, siempre que el hash utilizado para calcularlo sea resistente a los ataques de imágenes. Depósito y retiro de tokens Los tipos de transacciones anteriores se pueden usar para la transferencia de activos en el grupo, pero para un grupo de transacciones completamente funcional, debe admitir la transferencia de fondos dentro y fuera del grupo al mismo tiempo. Por lo tanto, agregamos un campo adicional llamado delta al formato de transacción privada, de modo que la cantidad total de UTXO de entrada sea igual a la cantidad de UTXO de salida + delta. Dado un árbol Merkle, dos valores hash OUT_HASH1 y OUT_HASH2, otros dos valores hash NULLIFIER1 y NULLIFIER2, y un valor delta. Se sabe que existen 4 UTXOs para IN1, IN2, OUT1, OUT2, dos certificados Merkel P1 y P2, y una clave privada x, entonces los valores hash correspondientes a OUT1 y OUT2 son OUT_HASH1 y OUT_HASH2 respectivamente; IN1 e IN2 El destinatario de la transacción es equivalente a la clave pública X correspondiente a la clave privada x; Merkel prueba que P1 y P2 son pruebas válidas del árbol de Merkel que contiene IN1 e IN2 con una raíz hash determinada; el número de IN1 e IN2 es igual a OUT1, la suma de OUT2 más el valor delta; hash (IN1, x) es igual a NULLIFIER1; hash (IN2, x) es igual a NULLIFIE2R. Tenga en cuenta que delta está en la declaración dada y, por lo tanto, es pública. Cuando NEAR procesa los tipos de transacciones anteriores, si el valor delta es negativo (es decir, hay menos tokens de entrada que de salida en una transacción privada), el exceso de tokens se almacenará en la cuenta del iniciador de la transacción; si el delta el valor es Si es positivo (es decir, se ingresan más tokens que los tokens que se emiten en una transacción privada), la transacción es válida solo cuando se reponen los tokens restantes. Tarifas de transacción Las transacciones privadas prohíben el establecimiento de un vínculo entre las UTXO recién creadas y las UTXO que se han utilizado como entradas de transacciones. Sin embargo, para que cualquier transacción se registre en la cadena NEAR, el remitente de la transacción debe pagar una tarifa de gas. Es por esta razón que el emisor debe tener una cierta cantidad de tokens NEAR en su cuenta. La cuenta puede haber obtenido algunos tokens NEAR a través de algún medio desconocido, creando así una cierta conexión entre los dos UTXO mencionados anteriormente, y el propósito de las transacciones privadas se verá muy frustrado. Para solucionar este problema, introdujimos el concepto de repetidor (Relayer) en el sistema. Supongamos que Alice quiere enviar una transacción a Bob y tiene la intención de que Ryan actúe como retransmisor. La tarifa de gasolina para esta transacción es inferior a Ⓝ1, y Alice está dispuesta a pagarle a RyanⓃ1 para permitir que Ryan lo ayude a poner la transacción en la cadena. Es posible que Alice ni siquiera tenga una cuenta NEAR, momento en el que crea una transacción privada. En esta transacción, los fondos totales de las dos UTXO utilizadas como entrada de la transacción son exactamente Ⓝ1 menos que los fondos totales de las UTXO utilizadas como salida de la transacción. El Ⓝ1 restante se retira a la cuenta del remitente de la transacción. Ryan recopila la información de la transacción de Alice, verifica su validez y envía la transacción con su propia cuenta. La tarifa de gas consumida en todo el proceso es menos de Ⓝ1, pero al final le pagaron Ⓝ1. Alice termina enviando una transacción sin revelar su identidad y Ryan recibe una pequeña recompensa. Tenga en cuenta que en la interacción, ninguna de las partes necesita ganarse la confianza de los demás: Ryan no puede alterar la transacción de ninguna forma, dejándolo con solo dos opciones: enviar o renunciar. Por lo tanto, el mayor riesgo para Alice es que su transacción no se confirme (en cuyo caso, puede pedirle a otro repetidor). Dado que Ryan valida la transacción antes de que se comprometa, Ryan no corre el riesgo de gastar gasolina y no ser recompensado a menos que otro retransmisor llegue primero. Desarrollo futuro El modelo descrito anteriormente ya es un grupo de transacciones que puede satisfacer plenamente las transacciones privadas. A continuación, el autor describirá brevemente cómo mejorar la seguridad o la usabilidad del grupo de transacciones desde varios aspectos. En el proceso de describir la transacción anterior, el autor mencionó que cuando Alice le envió discretamente el token a Bob, también compartió el UTXO recién creado con la otra parte. La realización de este proceso requiere que Alice y Bob se comuniquen fuera de la cadena, lo que no queremos ver. Para resolver este problema, podemos expandir el grupo de transacciones para que pueda almacenar todos los UTXO encriptados con la clave pública del receptor de transacciones. Cuando Alice transfiere activos a Bob y crea dos nuevos UTXO, Bob actúa como receptor y Alice utilizará su clave pública para cifrar el UTXO. Mirando a Bob nuevamente, monitorea todos los UTXO recién creados e intenta descifrarlos uno por uno con su clave privada. Una vez que prueba el UTXO creado por Alice, el descifrado es exitoso; de esta manera, Bob descubre su UTXO completamente a través de la comunicación en cadena específica de NEAR. Separación de firma y prueba Cuando Alice crea una transacción, necesita usar la información de su clave privada para diseñar una prueba compleja. Por lo tanto, la máquina que computa la prueba necesita acceso a su clave privada, lo cual no queremos. En general, es mejor usar algunos dispositivos de hardware externos para almacenar la clave privada. La función de este tipo de hardware suele ser relativamente simple. Por ejemplo, algunos productos solo tienen la función de firma de mensajes. Para dicho hardware, la prueba de conocimiento computacional generalmente está fuera de sus capacidades. Para adaptar este hardware, generamos 3 claves en lugar del tradicional par de claves públicas y privadas: clave privada, clave de descifrado y clave pública. En este caso, una parte de la información cifrada con la clave pública se puede descifrar utilizando la clave de descifrado. De manera similar, la firma de la clave privada se puede verificar descifrando la clave. Solo la clave pública es visible para todos. La clave de descifrado se almacena en un dispositivo que calcula la prueba de la transacción y la clave privada se almacena en un dispositivo externo que solo puede firmar información.

Tags：

OKB