Ha habido mucha discusión y artículos sobre cómo la implementación de AMP beneficiará las capacidades de enrutamiento de Lightning Network. ¿Cuál es el problema exacto en la implementación actual de Lightning que AMP está resolviendo? ¿Cómo funciona realmente AMP? y ¿cómo se va a implementar?
El mayor desafío en el mecanismo de enrutamiento actual es encontrar canales con saldo suficiente en un lado de un nodo para reenviar un pago entrante. Para ser más descriptivos, channel_announcementlos channel_updatemensajes que se transmiten contienen a short_channel_idtravés de los cuales los nodos de rayos pueden buscar la transacción en la cadena de bloques de Bitcoin y averiguar cuántos bitcoins están bloqueados en ese canal. Sin embargo, no se sabe cuánto contiene cada nodo del canal. Esto crea un problema en términos de enrutamiento de un pago, ya que un lado del canal puede no tener suficiente saldo para reenviar la transacción, lo que genera una falla en el enrutamiento y el nodo de origen tiene que volver a intentar el pago utilizando una ruta diferente.
El segundo problema es con los saldos de canal del nodo de origen. Digamos que voy a comprar una taza de café de Starbucks que me cuesta 20 000 satoshis. Ahora tengo tres canales abiertos en Lightning Network con mi saldo igual a 9,000 satoshi en cada canal. Dejando de lado el saldo de reserva del canal y las tarifas de transacción por ahora, solo puedo hacer pagos de 9,000 satoshis en cada canal, lo que me hace incapaz de comprar esa taza de café en un solo pago. La solución sería hacer tres pagos a la misma factura de pago que me ofrece Starbucks al comprar esa taza de café en los tres canales. Pero esto genera problemas de seguridad, debido a la reutilización de hash. Un nodo que tenga canales a lo largo de las rutas puede usar la imagen previa que aprendió de una ruta para realizar un pago a lo largo de la otra ruta. También,
El tercer problema es que por el momento (aunque temporal) tenemos un límite de 2 32 mili-satoshi (~0.0429 BTC) en un solo tamaño de pago. Los pagos por encima de este límite deben realizarse a través de pagos múltiples. Pero esto nuevamente trae el riesgo de que un pago se realice y los pagos posteriores no lleguen al destinatario. Luego, le queda pedirle al receptor que le procese un reembolso.
Conner Fromknecht y Olaoluwa Osuntokun propusieron pagos Atomic Multi Path (AMP) para resolver los dos problemas anteriores al dividir un pago más grande en otros más pequeños y, al mismo tiempo, no reutilizar ningún hash de pago en todos los flujos de pago más pequeños y agregar una fuerte garantía de que el receptor no recibirá ningún pago hasta que se completen todos los flujos de pagos parciales (atomicidad).
Su propuesta requería que el remitente enviara algún secreto s_ial receptor en cada pago menor i. Cuando el receptor haya recibido todos los pagos, construirá el secreto de pago base (BP) tomando XOR de todos los secretos parciales que envió el remitente, de modo que BP = s_1 ^ s_2 ^ ... ^ s_n. Ahora cada imagen previa de pago es SHA256(BP || i). Esto tenía la ventaja de que el receptor no podía crear la imagen previa hasta que se hubieran recibido todos los pagos parciales, resolviendo así el pago parcial y el problema de la reutilización del hash.
Esta propuesta de forma de pago es realmente útil si se realiza entre amigos, sin embargo, para uso comercial, esta propuesta tiene una debilidad. Consideramos la recepción de una imagen previa como una prueba criptográfica de que se ha realizado un pago exitoso. Si el remitente sabe y puede calcular las preimágenes por adelantado, esto destruye todo el principio de un recibo criptográfico que obtendrá del receptor del pago. Dado que la propuesta requería que el remitente creara los secretos compartidos y el payment_hash, el remitente conocía las preimágenes de antemano.
Para resolver este problema, se propuso MPP básico (pagos de múltiples rutas). Los MPP básicos utilizan lo mismo payment_hashpara todas las rutas a través de las cuales se realizará el pago. Sin embargo, el receptor no libera la imagen previa del pago hasta que se hayan recibido todos los pagos exitosos para frustrar la posibilidad de que un nodo intermedio use la imagen previa de una parte del pago y satisfaga la otra rama. Dado que el comprobante de pago es valioso, ningún beneficiario racional aceptará pagos parciales hasta que todas las partes del pago hayan llegado y, como resultado, no se publicará una imagen previa. Sin embargo, si libera la imagen previa a lo largo de un camino, es de interés económico para el beneficiario liberar la imagen previa a lo largo de todos los caminos.
Ahora se sigue un nuevo formato de tipo-longitud-valor (TLV) en el protocolo Lightning Network en comparación con un flujo de bytes de longitud fija en versiones anteriores. El uso de TLV permite ahorrar espacio, dejando potencialmente más espacio para los datos de la aplicación a través del cable o en una carga útil de cebolla. Los nodos que admiten tales cebollas de enrutamiento de carga útil variable lo indican configurando la global_featuresbandera, bits 8/9 ( var_onion_optin). Además, la factura relámpago generada necesita configurar la basic_mppfunción.
Base AMPs usa lo mismo payment_hashpara todas las rutas a través de las cuales se realizará el pago. Si el nodo final recibe un paquete cebolla que incluye un basic_mppcampo, entonces el pago PUEDE ser un AMP "base". Establecer la basic_mppbandera es una promesa por parte del remitente de que el resto de los pagos seguirán en los HTLC sucesivos. Todos los HTLC que se recibirán que cumplen con los pagos que tienen la misma imagen previa de pago se denominan "htlcset".
Al recibir una cebolla con basic_mpp, el destinatario debe esperar al menos 60 segundos para que se realicen todos los demás pagos. Si los pagos no se reciben en un período de tiempo suficiente, el nodo final debe fallar todos los htlcs en el htlcset. Sin embargo, si cumple con cualquier HTLC en el htlset, debe cumplir TODOS ellos. Esta restricción de subconjunto evita que la imagen previa se libere antes de que hayan llegado todos los pagos parciales: eso permitiría que cualquier nodo intermedio reclamara inmediatamente cualquier pago parcial pendiente.
Actualmente se está trabajando en High AMP. Combina las propuestas originales de AMP y el Base MPP actual, conservando el comprobante de pago (que fue sacrificado por la propuesta original) y asegurando una espera criptográficamente segura para todas las partes (en lugar del mero incentivo económico de Base AMP) .
Sin embargo, esto requiere que cambiemos a puntos y escalares en lugar de hashes y preimágenes. Una factura ahora contendrá un punto de pago que básicamente se genera al multiplicar un escalar (equivalente a una clave privada) con el punto generador estándar en secp256k1. El comprobante de pago no requiere la revelación del escalar, pero una firma que utilice el escalar detrás de la clave pública es suficiente para proporcionar un comprobante de pago. Esto también permite el soporte para la descorrelación de pagos (se agregan escalares adicionales en cada salto, y el escalar total se le dice al beneficiario), mientras que no requiere comprobante de pago o pagos espontáneos (puede funcionar con cualquiera). Esto es básicamente el uso de scripts sin script en Lightning. En lugar de HTLC, tenemos contratos Scriptless Script Pointlocked Timelocked (PTLC).
Sin embargo, la implementación de esto requeriría la implementación de Schnorr en la cadena principal de Bitcoin, lo que podría demorar un par de años.
René Pickhardt
Ugam kamat
fiatjaf
Ugam kamat