Revisión de la Capa 2 Dependiente de Convenios/Soft-Fork de Peter Todd

  • Revisión (más o menos) exhaustiva de todas las propuestas de soft fork y los sistemas de segunda capa que habilitan
  • Parece ser la primera revisión tan completa de un desarrollador de bitcoin respetado y de larga trayectoria
  • Concluye que debemos completar el soft fork de Gran Limpieza de Consenso y luego activar CTV (OP_CHECKTEMPLATEVERIFY)
  • Proporciona impulso al movimiento para actualizar las reglas de consenso de bitcoin y habilitar nuevas funcionalidades

Temas discutidos

  • Definiciones
    • ¿Qué es la Capa 2?
    • ¿Qué son los Convenios?
      • Convenios Recursivos
  • Objetivos
    • Límites de escalabilidad de Lightning
  • Visión general de L2
    • Lightning
      • Canales no interactivos
    • Fábricas de canales
    • Eltoo/LN-Symmetry
    • Ark
      • Economía de Ark
      • Lanzamiento de Ark
      • Interactividad
      • Ark Avanzado
      • Pago de tarifas en la cadena en retiros unilaterales
    • Validity Rollups
    • BitVM
    • Canales Jerárquicos
    • CoinPool
    • Red Enigma
  • Consideraciones sobre Mempool
    • Anclaje de transacciones
    • Pago de tarifas: RBF, CPFP, SIGHASH_ANYONECANPAY, Anchors y Sponsorship
    • Reciclaje de reemplazo
  • Patrones de características y Soft Forks
    • OP_Expire
    • SIGHASH_ANYPREVOUT
    • OP_CheckTemplateVerify
      • LNHANCE
    • OP_TXHASH
    • OP_CAT
      • ¿Es OP_CAT demasiado poderoso?
    • Hashing incremental
    • Revivir Script
      • Simplicity
    • OP_FancyTreeManipulationStuff
  • Pools de Fondos
    • Transacciones pre-firmadas individuales
    • Árboles Txout
    • Esquemas basados en balances
  • Ratio de datos fallidos
  • Limpieza de Consenso
  • Pruebas de L2 dependientes de soft fork
  • Posibles Soft-Forks
  • Notas al pie

Ventajas

  • Proporciona impulso al movimiento para actualizar las reglas de consenso de bitcoin y habilitar nuevas funcionalidades
  • Adopta un enfoque de sentido común, lento pero constante, para actualizar bitcoin
  • Define “capa 2” de una manera útil:
    1. Nadie puede robar fondos de manera rentable en el sistema, considerando los castigos y costos dentro del sistema. Costos y castigos fuera del sistema como la pérdida de reputación, consecuencias legales, etc., no se consideran en nuestra definición.
    2. (Preferible) Los verdaderos propietarios de los fondos pueden retirar unilateralmente sus fondos, menos las tarifas de transacción, sin la cooperación de terceros.
  • Establece una base para determinar qué sistemas capa-2 son interesantes:
    • Debe mejorar el límite de “un UTXO por usuario” experimentado por los usuarios de Lightning.
  • Filtra mucho ruido de ciertas propuestas, ya sea afirmando que no son sistemas de capa-2, o afirmando que no pueden mejorar la escalabilidad de bitcoin porque no pueden permitir más de un usuario por UTXO.
    • Por lo tanto, los únicos sistemas interesantes, según Todd, son:
      • Ark
      • Validity Rollups (incierto, ya que no explica cómo escalan bitcoin de manera significativa)
      • CoinPool (incierto, ya que Todd señala que el proyecto parece abandonado)
  • Explica en profundidad los ataques de anclaje en el mempool y las ventajas relativas de RBF vs CPFP, y RBFR vs V3 Transacciones/relé de paquetes.
  • Recomienda un plan de acción para actualizar las reglas de consenso de bitcoin:
    • Limpieza de Consenso, luego
    • CTV

Desventajas

  • Todd puede haber ido un poco demasiado lejos al filtrar cosas. Parece que tenía una fecha límite y se quedó sin tiempo.
  • Parece concluir, confusamente, que LNHANCE y TXHASH no están bien documentados o motivados.
  • Ignora el hecho de que los Canales de Simetría (anteriormente conocidos como “eltoo”) pueden implementarse usando CTV+CSFS, afirmando que APO es “requerido” para la Simetría.
  • Ignora los beneficios de los Canales de Simetría y el hecho de que los Canales de Simetría pueden implementarse usando penalidades.
  • No parece estar definitivamente a favor de ningún protocolo nuevo de capa dos excepto Ark.
  • Ignora completamente la existencia de casi todo el “calendario de adviento” de Jeremy Rubin de nuevas funcionalidades dependientes de convenios y sus descendientes, por ejemplo:
    • Coinpools (estilo CTV)
    • Darkpools
    • Control de congestión
    • Pools de minería descentralizados sin coordinación
    • Canales fríos
  • No considera bóvedas u otros usos de convenios que no son de capa-2, ignorando así VAULT y en su mayoría ignorando CCV (esto aparentemente estaba fuera del alcance de la subvención de Todd).

Preguntas

  • ¿Qué es una Capa 2?
  • ¿Por qué Lightning requiere (al menos) un UTXO por usuario?
  • ¿Qué son los convenios?
  • ¿Qué son los convenios recursivos?
  • ¿Qué es Ark?