Las computadoras en una red se comunican entre sí según protocolos. Aquí, "protocolo" se refiere a un sistema de reglas que especifican cómo se deben transmitir e interpretar los mensajes. La parte de transmisión de mensajes de pago del protocolo Lightning Network se describe en BOLT#4, también conocido como "Protocolo de enrutamiento de cebolla (Protocolo de enrutamiento de cebolla)".
Onion Routing es una tecnología anterior a Lightning Network por 25 años. También se usa en Tor, de donde proviene el nombre "Tor" ("The Onion Router"). Lightning Network utiliza una versión ligeramente modificada llamada "enrutamiento de cebolla basado en el origen", abreviado "SPHINX". En este artículo, vamos a hablar sobre cómo funciona el enrutamiento de cebolla.
¿Por qué usar el enrutamiento de cebolla?
Existen muchos protocolos de comunicación diferentes en el mundo, pero dado que Lightning Network es una red de pago, tiene sentido elegir un protocolo que revele la menor información posible sobre el pago que se reenvía.
Si Lightning Network usara el mismo protocolo que Internet, cada intermediario sabría quién fue el remitente del pago, quién fue el destinatario y quiénes fueron los otros intermediarios a lo largo del camino. El enrutamiento cebolla es una buena opción porque sus características garantizan nodos intermedios:
Solo conoce tu nodo anterior (quien te envió un mensaje) y el siguiente nodo (donde quieres reenviar el mensaje).
no conoce la longitud de todo el camino;
No saber dónde estás en el camino.
Descripción general del enrutamiento de cebolla
Usemos una parcela como analogía para explicar cómo funciona el enrutamiento cebolla.
Supongamos que Alice quiere pagarle a Dina. Primero, Alice necesita encontrar una ruta factible para su pago:
Alice→Bob→Chan→Dina
Luego, construye una "cebolla". Comienza con Dina (desde el final del camino). Ella pone un mensaje secreto (contenido de pago) en un paquete enviado a Dina y lo bloquea con una llave que solo ella y Dina conocen. Ahora, coloca este paquete en otro paquete para enviárselo a Chan, y le cierra el paquete a Chan con una llave que solo ella y Chan conocen. Correcto y así sucesivamente.
Alice envía la última cebolla (paquete) al primer intermediario en el camino, Bob. Bob abre su paquete con su propia llave y ve que el próximo paquete es para Chan. Así que le envió el paquete a Chan. Lo mismo ocurre con Chan.Después de desempacar el paquete, le envió el paquete a Dina. Finalmente, Dina abrió su propio paquete y encontró dentro el mensaje de pago.
En el enrutamiento cebolla, los intermediarios como Bob y Chan no conocen el contenido del mensaje a Dina ni la longitud de la ruta de pago completa. Lo único que saben es quién les envió el paquete y quién lo recibirá a continuación. Esto garantiza la privacidad del mensaje y la confidencialidad de la ruta. Cada intermediario solo puede tocar la capa de mensajes especialmente hecha para TA.
En el enrutamiento de cebolla basado en la fuente de Lightning Network, el remitente elige la ruta de pago y construye una cebolla completa para esa ruta, que puede verse como un agujero de privacidad (Nota del traductor: la ubicación de la red del receptor debe estar expuesta al remitente). Otros esquemas de enrutamiento, como el "enrutamiento ciego" (traducción al chino), resuelven este problema ofuscando parte de la ruta de pago al remitente. Sin embargo, en este artículo, nos centramos exclusivamente en ESFINGE.
Montar la cebolla
Ahora, echemos un vistazo a la especificación del enrutamiento de cebolla. Al principio, necesitamos definir estas cosas:
El remitente es el "nodo inicial" (Alice);
El receptor es el "nodo final" (Dina);
Cada nodo intermedio en la ruta de pago es un "salto" (Bob y Chan);
La información de comunicación entre cada salto se denomina "carga de salto".
Carga de salto de construcción
Una vez que Alice ha elegido una ruta de pago, obtiene la información para cada canal de pago del protocolo de chismes para crear la carga útil para cada salto, esencialmente diciéndole a cada salto cómo crear el HTLC para el pago que se reenvía (contrato hash de bloqueo de tiempo).
Para establecer un HTLC adecuado, cada salto necesita:
La cantidad que necesita ser enviada;
valor secreto pagado;
El ID del canal de pago que sigue enviando cebollas;
La duración del bloqueo de tiempo.
La mayoría de estos datos provienen de mensajes de "actualización de canales", que contienen información sobre tarifas de enrutamiento, solicitudes de eventos e ID de canales de pago. El monto total que debe reenviarse es la suma del monto del pago más la tarifa de manejo cobrada por cada salto posterior; mientras que Dina calcula el valor secreto del pago y lo incluye en la factura de pago (informado por el mensaje de cebolla a cada uno). brincar).
Alice comienza con el nodo final Dina. Ella incluye el monto del reenvío, el valor de la duración del bloqueo de tiempo, el valor secreto del pago y el monto del pago en el paquete. Tenga en cuenta que no necesita agregar la ID del canal, porque Dina es el nodo final y no necesita reenviar el pago a otros.
A primera vista, parece redundante proporcionar el monto del reenvío, porque este monto es el mismo que el monto del pago. Sin embargo, el pago de múltiples rutas enviará el monto del pago a través de múltiples rutas, y luego los dos valores no coincidirán.
En la carga útil de Chan, Alice agrega los ID de canal de Chan y Dina. También agregó montos de reenvío y valores de bloqueo de tiempo. Finalmente, Alice crea una carga útil para Bob. Chan cobra 100 Satoshi por el pago a través del canal entre ella y Dina, por lo que Alice debe decirle a Bob que el monto reenviado es el pago más la tarifa de manejo. De acuerdo con el mensaje de actualización del canal de Chan, el valor del bloqueo de tiempo también se incrementó en 20 (en bloques). Finalmente, Alice también considera la tarifa de manejo de Bob y los requisitos de bloqueo de tiempo, y le da un HTLC con una longitud de bloqueo de tiempo de 700040 y un valor de 100200 Satoshi.
Valor secreto compartido y generación de claves
Luego, Alice prepara la cebolla generando un secreto compartido para cada salto (incluido el nodo final). Este valor de secreto compartido puede ser generado por Alice y el salto de destino, respectivamente, al multiplicar su propia clave privada con la clave pública de la otra parte.
Se necesita un valor de secreto compartido para el enrutamiento de cebolla, lo que permite que Alice y cada salto obtengan la misma clave. Luego, Alice usa esas teclas para ofuscar cada capa de la cebolla, y ese salto usa las teclas para desofuscar.
Para proteger la privacidad de Alice, crea una clave de sesión única para una cebolla, en lugar de usar su propia clave pública de nodo, para derivar el valor secreto compartido. Utiliza esta clave de sesión para el primer salto y luego, para cada salto subsiguiente, Alice aleatoriza de manera determinista la clave multiplicando la última clave por un factor de cegamiento. Estos se utilizan para crear una clave de valor secreto compartido, que llamamos "claves efímeras".
Bob, Chan y Dina necesitan obtener el mismo valor secreto que Alice, por lo que necesitan saber la clave efímera para usar en su sesión. Alice solo pone la primera clave en la cebolla para ahorrar tamaño de mensaje. Cada salto calcula la siguiente clave efímera y la incrusta en la cebolla para el siguiente nodo. Cada salto puede usar su propia clave pública y valor secreto compartido para calcular el factor de cegamiento que usa Alice para determinar la siguiente clave efímera.
Como se mencionó anteriormente, el valor del secreto compartido se usará para generar algunas claves, y Alice y el salto correspondiente pueden usar estas claves para realizar algunas operaciones en la cebolla. Echemos un vistazo a lo que hace cada tecla.
Tecla Rho
Alice utiliza la clave Rho para cifrar una capa de cebolla; esto ofuscará el contenido de la carga útil para que no pueda ser descifrado por personas ajenas. Solo el propietario de la clave rho puede descifrar la carga útil. Eso es lo que tiene que hacer el nodo que recibe la cebolla: usar el valor secreto compartido con Alice para derivar la clave rho, luego descifrar la cebolla y leer el contenido.
mukey
Alice usa la tecla mu para crear una suma de verificación para cada carga útil. Ella también pasa la suma de control al salto que recibe la cebolla. Este salto, a su vez, utiliza la clave mu para generar una suma de comprobación del payload recibido, comprobando que coincide con el proporcionado por Alice. Esto es para verificar la integridad de la carga útil, verificando que no haya sido manipulada.
Tecla de teclado
Esta clave solo la utiliza Alice para generar datos "basura" aleatorios. Estos datos también son parte de la cebolla, y no tienen nada que ver con la longitud de la ruta de pago, cuántos saltos ha pasado la cebolla y mantiene la cebolla siempre del mismo tamaño, incluso si algunos de sus contenidos son irrelevantes. Así es como el enrutamiento cebolla oculta la longitud de la ruta, protegiendo de hecho la privacidad del remitente y el receptor.
Una llave
Esta clave también se usa para verificar la integridad de los datos contenidos en la cebolla, pero solo si se devuelve un error. Sí, se llama "um" porque es "mu" escrito al revés. En el caso de un error de pago, el salto que encuentre el error usará la tecla um para crear una suma de verificación, y cuando el nodo anterior reciba el informe de error, también usará la tecla um para verificar la integridad del mensaje.
Encapsulando la capa de cebolla
La envoltura de cebolla final se ve así:
Alice ahora tiene la carga útil para cada salto y el valor secreto compartido para cada salto. Veamos cómo Alice transforma esta información en la cebolla final. Comienza con el nodo final y avanza paso a paso.
Primero crea un campo vacío con una longitud de 1300 bytes, que es la longitud total de todas las cargas útiles de cebolla. Luego usa la tecla pad para crear una cadena aleatoria de 1300 bytes de largo, que es basura que no sirve para ningún salto. Este paso se realiza para garantizar que cada capa de la cebolla tenga el mismo aspecto, de modo que no pueda ver la longitud total de la ruta (cuántos saltos), ni quién es el remitente y quién es el receptor.
Luego crea una suma de verificación de la carga útil que debe usarse y la coloca al final de la carga útil. En el mensaje al nodo final, la suma de verificación es todo 0 para informar a Dina que ella es la destinataria final de esta cebolla. Después de agregar la suma de verificación al final de la carga útil, Alice coloca la carga útil (y la suma de verificación) al comienzo de la basura y elimina la parte del mensaje completo que supera los 1300 bytes, de modo que el mensaje completo tiene una longitud de 1300 bytes.
Luego, Alice usa la clave rho para crear una cadena de bytes aleatorios y usa una operación exclusiva o (XOR) en la carga útil de cebolla obtenida en el paso anterior para obtener la carga útil ofuscada. El texto original de la carga útil se puede obtener utilizando la operación XOR de esta cadena de bytes aleatorios en el texto ofuscado (Nota del traductor: en otras palabras, XOR aquí es el algoritmo de cifrado simétrico y la cadena de bytes aleatorios es la clave). La operación XOR compara la carga útil de la cebolla con la cadena de bytes aleatorios (generada por la clave rho) bit a bit, generando un 1 solo si uno de los bits de datos es un 1; esto da como resultado una carga útil ofuscada. Lo inteligente de la operación XOR es que siempre que obtenga la cadena de bytes aleatorios correcta y la carga útil ofuscada, solo necesita ejecutar la operación XOR con los dos nuevamente para obtener la carga útil ofuscada.
Dado que los nodos que reciben la cebolla pueden derivar la misma clave rho, pueden generar la misma cadena de bytes aleatorios que Alice. Así es como cada nodo a lo largo del camino puede desenredar la confusión y leer el contenido.
Después de preparar la cebolla de confusión para un salto, Alice repite los mismos pasos para el siguiente nodo. La diferencia clave es que una vez que las cebollas de Dina están listas, ya no necesita generar basura. Simplemente agrega la cebolla ofuscada del paso anterior después de la carga útil útil y la suma de verificación, y recorta todo lo que supere los 1300 bytes.
Finalmente, Alice toma la cebolla ofuscada final y agrega una suma de verificación para que Bob pueda verificar la integridad de esta cebolla. Luego, Alice agrega la clave pública de la sesión para que Bob pueda usar esta clave pública para calcular el valor del secreto compartido. Finalmente, también agrega un byte que representa la versión, indicando a otros nodos cómo interpretar los datos en él. Para la versión descrita por BOLT #4, el byte de versión será 0.
cebolla adelante
Para enviar este paquete de cebolla, el remitente crea un mensaje update_add_htlc con los siguientes campos:
ID de canal: el canal específico con el que se relaciona este mensaje.
ID: El identificador de este HTLC.
Monto: El valor de este HTLC.
Pago Hash: Creado por el destinatario del pago.
Tiempo de caducidad: este HTLC caducará después de un bloque determinado.
Paquete de cebolla: La cebolla creada para este pago, que es lo mencionado anteriormente.
Datos adicionales: se utiliza para especificar datos adicionales.
Después de preparar el mensaje, Alice le envía el mensaje a Bob. Después de recibir el mensaje, Bob puede comenzar a decodificar su propia cebolla. Primero obtiene la clave de sesión del envoltorio de cebolla y la usa para derivar el valor del secreto compartido con Alice.
Armado con el valor del secreto compartido, Bob genera la clave mu para verificar la suma de verificación de la carga útil incrustada en el paquete de cebolla. Si la carga útil no ha sido alterada, las sumas de verificación deben coincidir.
Para evitar que otros nodos en la ruta sepan cuánto dura la ruta, Bob agrega un campo de 1300 bytes lleno de ceros al paquete cebolla. Luego, Bob genera una cadena de bytes aleatorios de 2600 bytes de longitud a partir de la clave rho. Bob usa esta cadena de bytes aleatorios para XOR la carga útil de cebolla llena de ceros.
¿Recuerdas que te dije sobre las cargas de cebolla confusas? Utilice la carga útil de cebolla ofuscada como entrada y ejecute la operación "XOR" con la misma cadena de bytes para obtener la carga útil de cebolla antes de la ofuscación. Debido a que Alice y Bob usan el mismo valor secreto compartido, generando la misma clave rho, Bob puede desobstruir la ofuscación. Esto tiene la ventaja añadida de que convierte los caracteres de relleno de 1300 bytes de longitud en bytes aleatorios.
La carga útil no ofuscada de Bob incluye los datos de la carga útil de su salto junto con una huella digital. Bob guarda esta huella digital para poder agregarla al paquete de cebolla que le envía a Chan. Después de que Bob separa su propia carga útil del mensaje cebolla, vuelve a convertir el paquete cebolla a su tamaño original de 1300 bytes y aleatoriza su clave de sesión como lo hizo Alice. Finalmente, Bob agrega los bytes de la versión, la clave de sesión y la huella digital que pretende colocar en la carga útil de la cebolla, y reenvía el paquete cebolla a Chan a través de un mensaje update_add_htlc.
Este proceso continuará hasta que el mensaje se envíe al nodo final, Dina. Cuando Dina recibe el mensaje update_add_htlc, puede ingresar el valor hash del valor secreto generado por ella misma, lo que significa que este HTLC está destinado a ella. Entonces, Dina solo necesita verificar las huellas dactilares, desentrañar los mensajes de cebolla y revelar su propia carga útil.
Solución de problemas
Estamos hablando de una historia de éxito, un caso en el que todo salió según lo planeado, pero si algo sale mal en el camino, debe enviar un mensaje de regreso para notificar a todos los nodos que algo salió mal. Este proceso es similar al enrutamiento de cebolla normal. Detectar un nodo defectuoso requiere derivar la clave um del valor secreto compartido, usarla para generar una cadena de bytes aleatorios y usar una operación XOR para ofuscar el paquete de cebolla devuelto.
Un nodo que encuentra un error enviará un mensaje al nodo anterior en la ruta de pago. Cada salto utiliza la tecla um y la tecla ammag para realizar la misma operación hasta que el remitente recibe el paquete. Finalmente, el remitente usa la clave ammag y la clave um para desofuscar y verificar el paquete.
Los errores pueden ser causados por paquetes, nodos o canales de cebolla. Si usa mucho Lightning Network, es posible que haya encontrado errores como "canal no disponible" o "cargos insuficientes".
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
"Enrutamiento cebolla" en Lightning Network y cómo funciona
Autor: LORENZO
Las computadoras en una red se comunican entre sí según protocolos. Aquí, "protocolo" se refiere a un sistema de reglas que especifican cómo se deben transmitir e interpretar los mensajes. La parte de transmisión de mensajes de pago del protocolo Lightning Network se describe en BOLT#4, también conocido como "Protocolo de enrutamiento de cebolla (Protocolo de enrutamiento de cebolla)".
Onion Routing es una tecnología anterior a Lightning Network por 25 años. También se usa en Tor, de donde proviene el nombre "Tor" ("The Onion Router"). Lightning Network utiliza una versión ligeramente modificada llamada "enrutamiento de cebolla basado en el origen", abreviado "SPHINX". En este artículo, vamos a hablar sobre cómo funciona el enrutamiento de cebolla.
¿Por qué usar el enrutamiento de cebolla?
Existen muchos protocolos de comunicación diferentes en el mundo, pero dado que Lightning Network es una red de pago, tiene sentido elegir un protocolo que revele la menor información posible sobre el pago que se reenvía.
Si Lightning Network usara el mismo protocolo que Internet, cada intermediario sabría quién fue el remitente del pago, quién fue el destinatario y quiénes fueron los otros intermediarios a lo largo del camino. El enrutamiento cebolla es una buena opción porque sus características garantizan nodos intermedios:
Descripción general del enrutamiento de cebolla
Usemos una parcela como analogía para explicar cómo funciona el enrutamiento cebolla.
Supongamos que Alice quiere pagarle a Dina. Primero, Alice necesita encontrar una ruta factible para su pago:
Alice→Bob→Chan→Dina
Luego, construye una "cebolla". Comienza con Dina (desde el final del camino). Ella pone un mensaje secreto (contenido de pago) en un paquete enviado a Dina y lo bloquea con una llave que solo ella y Dina conocen. Ahora, coloca este paquete en otro paquete para enviárselo a Chan, y le cierra el paquete a Chan con una llave que solo ella y Chan conocen. Correcto y así sucesivamente.
Alice envía la última cebolla (paquete) al primer intermediario en el camino, Bob. Bob abre su paquete con su propia llave y ve que el próximo paquete es para Chan. Así que le envió el paquete a Chan. Lo mismo ocurre con Chan.Después de desempacar el paquete, le envió el paquete a Dina. Finalmente, Dina abrió su propio paquete y encontró dentro el mensaje de pago.
En el enrutamiento cebolla, los intermediarios como Bob y Chan no conocen el contenido del mensaje a Dina ni la longitud de la ruta de pago completa. Lo único que saben es quién les envió el paquete y quién lo recibirá a continuación. Esto garantiza la privacidad del mensaje y la confidencialidad de la ruta. Cada intermediario solo puede tocar la capa de mensajes especialmente hecha para TA.
En el enrutamiento de cebolla basado en la fuente de Lightning Network, el remitente elige la ruta de pago y construye una cebolla completa para esa ruta, que puede verse como un agujero de privacidad (Nota del traductor: la ubicación de la red del receptor debe estar expuesta al remitente). Otros esquemas de enrutamiento, como el "enrutamiento ciego" (traducción al chino), resuelven este problema ofuscando parte de la ruta de pago al remitente. Sin embargo, en este artículo, nos centramos exclusivamente en ESFINGE.
Montar la cebolla
Ahora, echemos un vistazo a la especificación del enrutamiento de cebolla. Al principio, necesitamos definir estas cosas:
Carga de salto de construcción
Una vez que Alice ha elegido una ruta de pago, obtiene la información para cada canal de pago del protocolo de chismes para crear la carga útil para cada salto, esencialmente diciéndole a cada salto cómo crear el HTLC para el pago que se reenvía (contrato hash de bloqueo de tiempo).
Para establecer un HTLC adecuado, cada salto necesita:
La mayoría de estos datos provienen de mensajes de "actualización de canales", que contienen información sobre tarifas de enrutamiento, solicitudes de eventos e ID de canales de pago. El monto total que debe reenviarse es la suma del monto del pago más la tarifa de manejo cobrada por cada salto posterior; mientras que Dina calcula el valor secreto del pago y lo incluye en la factura de pago (informado por el mensaje de cebolla a cada uno). brincar).
Alice comienza con el nodo final Dina. Ella incluye el monto del reenvío, el valor de la duración del bloqueo de tiempo, el valor secreto del pago y el monto del pago en el paquete. Tenga en cuenta que no necesita agregar la ID del canal, porque Dina es el nodo final y no necesita reenviar el pago a otros.
A primera vista, parece redundante proporcionar el monto del reenvío, porque este monto es el mismo que el monto del pago. Sin embargo, el pago de múltiples rutas enviará el monto del pago a través de múltiples rutas, y luego los dos valores no coincidirán.
En la carga útil de Chan, Alice agrega los ID de canal de Chan y Dina. También agregó montos de reenvío y valores de bloqueo de tiempo. Finalmente, Alice crea una carga útil para Bob. Chan cobra 100 Satoshi por el pago a través del canal entre ella y Dina, por lo que Alice debe decirle a Bob que el monto reenviado es el pago más la tarifa de manejo. De acuerdo con el mensaje de actualización del canal de Chan, el valor del bloqueo de tiempo también se incrementó en 20 (en bloques). Finalmente, Alice también considera la tarifa de manejo de Bob y los requisitos de bloqueo de tiempo, y le da un HTLC con una longitud de bloqueo de tiempo de 700040 y un valor de 100200 Satoshi.
Valor secreto compartido y generación de claves
Luego, Alice prepara la cebolla generando un secreto compartido para cada salto (incluido el nodo final). Este valor de secreto compartido puede ser generado por Alice y el salto de destino, respectivamente, al multiplicar su propia clave privada con la clave pública de la otra parte.
Se necesita un valor de secreto compartido para el enrutamiento de cebolla, lo que permite que Alice y cada salto obtengan la misma clave. Luego, Alice usa esas teclas para ofuscar cada capa de la cebolla, y ese salto usa las teclas para desofuscar.
Para proteger la privacidad de Alice, crea una clave de sesión única para una cebolla, en lugar de usar su propia clave pública de nodo, para derivar el valor secreto compartido. Utiliza esta clave de sesión para el primer salto y luego, para cada salto subsiguiente, Alice aleatoriza de manera determinista la clave multiplicando la última clave por un factor de cegamiento. Estos se utilizan para crear una clave de valor secreto compartido, que llamamos "claves efímeras".
Bob, Chan y Dina necesitan obtener el mismo valor secreto que Alice, por lo que necesitan saber la clave efímera para usar en su sesión. Alice solo pone la primera clave en la cebolla para ahorrar tamaño de mensaje. Cada salto calcula la siguiente clave efímera y la incrusta en la cebolla para el siguiente nodo. Cada salto puede usar su propia clave pública y valor secreto compartido para calcular el factor de cegamiento que usa Alice para determinar la siguiente clave efímera.
Como se mencionó anteriormente, el valor del secreto compartido se usará para generar algunas claves, y Alice y el salto correspondiente pueden usar estas claves para realizar algunas operaciones en la cebolla. Echemos un vistazo a lo que hace cada tecla.
Tecla Rho
Alice utiliza la clave Rho para cifrar una capa de cebolla; esto ofuscará el contenido de la carga útil para que no pueda ser descifrado por personas ajenas. Solo el propietario de la clave rho puede descifrar la carga útil. Eso es lo que tiene que hacer el nodo que recibe la cebolla: usar el valor secreto compartido con Alice para derivar la clave rho, luego descifrar la cebolla y leer el contenido.
mukey
Alice usa la tecla mu para crear una suma de verificación para cada carga útil. Ella también pasa la suma de control al salto que recibe la cebolla. Este salto, a su vez, utiliza la clave mu para generar una suma de comprobación del payload recibido, comprobando que coincide con el proporcionado por Alice. Esto es para verificar la integridad de la carga útil, verificando que no haya sido manipulada.
Tecla de teclado
Esta clave solo la utiliza Alice para generar datos "basura" aleatorios. Estos datos también son parte de la cebolla, y no tienen nada que ver con la longitud de la ruta de pago, cuántos saltos ha pasado la cebolla y mantiene la cebolla siempre del mismo tamaño, incluso si algunos de sus contenidos son irrelevantes. Así es como el enrutamiento cebolla oculta la longitud de la ruta, protegiendo de hecho la privacidad del remitente y el receptor.
Una llave
Esta clave también se usa para verificar la integridad de los datos contenidos en la cebolla, pero solo si se devuelve un error. Sí, se llama "um" porque es "mu" escrito al revés. En el caso de un error de pago, el salto que encuentre el error usará la tecla um para crear una suma de verificación, y cuando el nodo anterior reciba el informe de error, también usará la tecla um para verificar la integridad del mensaje.
Encapsulando la capa de cebolla
La envoltura de cebolla final se ve así:
Alice ahora tiene la carga útil para cada salto y el valor secreto compartido para cada salto. Veamos cómo Alice transforma esta información en la cebolla final. Comienza con el nodo final y avanza paso a paso.
Primero crea un campo vacío con una longitud de 1300 bytes, que es la longitud total de todas las cargas útiles de cebolla. Luego usa la tecla pad para crear una cadena aleatoria de 1300 bytes de largo, que es basura que no sirve para ningún salto. Este paso se realiza para garantizar que cada capa de la cebolla tenga el mismo aspecto, de modo que no pueda ver la longitud total de la ruta (cuántos saltos), ni quién es el remitente y quién es el receptor.
Luego crea una suma de verificación de la carga útil que debe usarse y la coloca al final de la carga útil. En el mensaje al nodo final, la suma de verificación es todo 0 para informar a Dina que ella es la destinataria final de esta cebolla. Después de agregar la suma de verificación al final de la carga útil, Alice coloca la carga útil (y la suma de verificación) al comienzo de la basura y elimina la parte del mensaje completo que supera los 1300 bytes, de modo que el mensaje completo tiene una longitud de 1300 bytes.
Luego, Alice usa la clave rho para crear una cadena de bytes aleatorios y usa una operación exclusiva o (XOR) en la carga útil de cebolla obtenida en el paso anterior para obtener la carga útil ofuscada. El texto original de la carga útil se puede obtener utilizando la operación XOR de esta cadena de bytes aleatorios en el texto ofuscado (Nota del traductor: en otras palabras, XOR aquí es el algoritmo de cifrado simétrico y la cadena de bytes aleatorios es la clave). La operación XOR compara la carga útil de la cebolla con la cadena de bytes aleatorios (generada por la clave rho) bit a bit, generando un 1 solo si uno de los bits de datos es un 1; esto da como resultado una carga útil ofuscada. Lo inteligente de la operación XOR es que siempre que obtenga la cadena de bytes aleatorios correcta y la carga útil ofuscada, solo necesita ejecutar la operación XOR con los dos nuevamente para obtener la carga útil ofuscada.
Dado que los nodos que reciben la cebolla pueden derivar la misma clave rho, pueden generar la misma cadena de bytes aleatorios que Alice. Así es como cada nodo a lo largo del camino puede desenredar la confusión y leer el contenido.
Después de preparar la cebolla de confusión para un salto, Alice repite los mismos pasos para el siguiente nodo. La diferencia clave es que una vez que las cebollas de Dina están listas, ya no necesita generar basura. Simplemente agrega la cebolla ofuscada del paso anterior después de la carga útil útil y la suma de verificación, y recorta todo lo que supere los 1300 bytes.
Finalmente, Alice toma la cebolla ofuscada final y agrega una suma de verificación para que Bob pueda verificar la integridad de esta cebolla. Luego, Alice agrega la clave pública de la sesión para que Bob pueda usar esta clave pública para calcular el valor del secreto compartido. Finalmente, también agrega un byte que representa la versión, indicando a otros nodos cómo interpretar los datos en él. Para la versión descrita por BOLT #4, el byte de versión será 0.
cebolla adelante
Para enviar este paquete de cebolla, el remitente crea un mensaje update_add_htlc con los siguientes campos:
Después de preparar el mensaje, Alice le envía el mensaje a Bob. Después de recibir el mensaje, Bob puede comenzar a decodificar su propia cebolla. Primero obtiene la clave de sesión del envoltorio de cebolla y la usa para derivar el valor del secreto compartido con Alice.
Armado con el valor del secreto compartido, Bob genera la clave mu para verificar la suma de verificación de la carga útil incrustada en el paquete de cebolla. Si la carga útil no ha sido alterada, las sumas de verificación deben coincidir.
Para evitar que otros nodos en la ruta sepan cuánto dura la ruta, Bob agrega un campo de 1300 bytes lleno de ceros al paquete cebolla. Luego, Bob genera una cadena de bytes aleatorios de 2600 bytes de longitud a partir de la clave rho. Bob usa esta cadena de bytes aleatorios para XOR la carga útil de cebolla llena de ceros.
¿Recuerdas que te dije sobre las cargas de cebolla confusas? Utilice la carga útil de cebolla ofuscada como entrada y ejecute la operación "XOR" con la misma cadena de bytes para obtener la carga útil de cebolla antes de la ofuscación. Debido a que Alice y Bob usan el mismo valor secreto compartido, generando la misma clave rho, Bob puede desobstruir la ofuscación. Esto tiene la ventaja añadida de que convierte los caracteres de relleno de 1300 bytes de longitud en bytes aleatorios.
La carga útil no ofuscada de Bob incluye los datos de la carga útil de su salto junto con una huella digital. Bob guarda esta huella digital para poder agregarla al paquete de cebolla que le envía a Chan. Después de que Bob separa su propia carga útil del mensaje cebolla, vuelve a convertir el paquete cebolla a su tamaño original de 1300 bytes y aleatoriza su clave de sesión como lo hizo Alice. Finalmente, Bob agrega los bytes de la versión, la clave de sesión y la huella digital que pretende colocar en la carga útil de la cebolla, y reenvía el paquete cebolla a Chan a través de un mensaje update_add_htlc.
Este proceso continuará hasta que el mensaje se envíe al nodo final, Dina. Cuando Dina recibe el mensaje update_add_htlc, puede ingresar el valor hash del valor secreto generado por ella misma, lo que significa que este HTLC está destinado a ella. Entonces, Dina solo necesita verificar las huellas dactilares, desentrañar los mensajes de cebolla y revelar su propia carga útil.
Solución de problemas
Estamos hablando de una historia de éxito, un caso en el que todo salió según lo planeado, pero si algo sale mal en el camino, debe enviar un mensaje de regreso para notificar a todos los nodos que algo salió mal. Este proceso es similar al enrutamiento de cebolla normal. Detectar un nodo defectuoso requiere derivar la clave um del valor secreto compartido, usarla para generar una cadena de bytes aleatorios y usar una operación XOR para ofuscar el paquete de cebolla devuelto.
Un nodo que encuentra un error enviará un mensaje al nodo anterior en la ruta de pago. Cada salto utiliza la tecla um y la tecla ammag para realizar la misma operación hasta que el remitente recibe el paquete. Finalmente, el remitente usa la clave ammag y la clave um para desofuscar y verificar el paquete.
Los errores pueden ser causados por paquetes, nodos o canales de cebolla. Si usa mucho Lightning Network, es posible que haya encontrado errores como "canal no disponible" o "cargos insuficientes".