Ark es el tercer protocolo importante de Capa 2 con algún tipo de mecanismo de salida unilateral o de ejecución en la capa base que se acerca al punto de lanzamiento en Bitcoin. Lightning fue el primero cuando C-Lightning se puso en marcha durante la campaña Reckless en 2018, luego las Statechains en 2021 cuando Mercury Wallet se hizo operativo, y ahora la implementación de la billetera Arkade de Ark Lab con clArk (Ark sin convenios) se acerca al mismo objetivo.
Comparativa de clArk y Ark
clArk tiene algunas limitaciones en comparación con una implementación completa de Ark, principalmente la exigencia en una versión sin confianza de que cada usuario dentro de un Ark individual firme colaborativamente las transacciones de salida en un masivo multifirma n-de-n al momento de ser creado. Si tuviéramos CTV u otro convenio equivalente, los usuarios no tendrían que participar en un proceso interactivo de firma, y el Proveedor de Servicios Ark (ASP) podría simplemente crear el Ark usando un convenio, garantizando a los usuarios el control total de sus fondos una vez confirmado.
Contrastando Ark y Lightning Network
Ark presenta un interesante equilibrio en comparación con Lightning Network, ya que ambos requieren que los participantes tengan liquidez excedente para recibir pagos. Sin embargo, en el caso de Lightning, es un desafío complejo para los usuarios individuales, quienes deben descubrir cómo asignar su propia liquidez y cómo obtenerla de otros para enviar y recibir funcionalmente. Es un problema individual que cada usuario debe resolver de manera independiente. Con Ark, cualquier ASP puede asignar libremente parte de su liquidez a cualquiera de sus usuarios. Aunque aún deben resolver el problema de la obtención de liquidez, ya no enfrentan el problema individual de decidir si vale la pena asignar liquidez en esa dirección; simplemente se puede realizar en el momento según lo necesite cualquier usuario individual de un fondo común de liquidez.
Problemas de Liquidez en Ark
Aún existe un problema con la liquidez en Ark. Para cada pago en tránsito en un Ark que aún no se ha cerrado, el ASP debe adelantar liquidez para permitir que los usuarios los reciban en un nuevo Ark. Cuando el ASP se encuentra en un punto en que su liquidez se agota, sus tarifas necesariamente comienzan a dispararse para manejar este problema hasta que puedan recuperar la liquidez bloqueada al cerrar Arks.
Propuestas de Mejora
Una forma de abordar esta curva de tarifas altas sería explorar algunas lecciones de Lightning, específicamente una topología enrutada. Esto sería increíblemente simple en comparación con Lightning. Lightning requiere mapeo y enrutamiento a través de rutas de liquidez establecidas entre pares de usuarios individuales, mientras que con Ark es simplemente de ASP a ASP.
- Un ASP que experimente una escasez de liquidez podría transferir pagos de sus propios Arks a otro ASP con más liquidez disponible, estableciendo el enlace ATLC entre su propio Ark desde donde se origina el pago a otro Ark de ASP para ser recibido, ahorrando tarifas a los usuarios.
- A medida que recuperan la liquidez al cerrar Arks existentes y sus propias tarifas bajan, otros ASPs que luego experimentan una escasez de liquidez podrían «devolver el favor» transfiriendo pagos de regreso en su dirección.
- Esto podría establecer una especie de dinámica de «hoy por ti, mañana por mí» entre los ASPs, que, aunque deja algunos ingresos en la mesa durante las escaseces de liquidez de tarifas altas, generarían una experiencia más predecible y asequible para sus usuarios.
Esto implica el riesgo de que los pagos entre ASPs esencialmente interconecten Arks a través de diferentes ASPs, lo que significa que los cierres no cooperativos requerirían el cierre de Arks operados por múltiples entidades, pero dado que los cierres cooperativos dependen del comportamiento del usuario, no creo que esto cambie fundamentalmente el perfil de riesgo, a menos que los ASPs intencionadamente decidan obstaculizarse. Esto podría ser visto como un problema análogo al de la obstrucción de canales en Lightning.
Hay algunos aspectos positivos y potenciales desventajas, pero creo que este es un concepto que vale la pena explorar en términos de mejorar el problema de escasez de liquidez de Ark.
FAQs
- ¿Qué es clArk y en qué se diferencia de una implementación completa de Ark?
clArk es una versión de Ark que requiere que cada usuario colabore en la firma de transacciones de salida en un multifirma n-de-n cuando se crea. Una implementación completa con un convenio evitaría la necesidad de un proceso de firma interactivo. - ¿Cómo se compara Ark con Lightning Network en términos de liquidez?
Ambos requieren liquidez excedente para recibir pagos, pero Ark permite que el ASP asigne liquidez a los usuarios, simplificando el proceso en comparación con Lightning, donde los usuarios deben gestionar individualmente su liquidez. - ¿Cómo podría mitigarse la escasez de liquidez en Ark?
Se propone explorar una topología enrutada similar a Lightning, permitiendo que los ASPs transfieran pagos a otros con más liquidez, lo que reduciría las tarifas para los usuarios y mantendría la estabilidad del sistema.
