Ark es el tercer protocolo importante de Capa 2 con algún tipo de salida unilateral o mecanismo de aplicación en la capa base para acercarse al punto de lanzamiento en Bitcoin. Lightning llegó primero cuando C-Lightning entró en funcionamiento en la campaña Reckless en 2018, Statechains en 2021 cuando Mercury Wallet entró en funcionamiento, y ahora la próxima implementación de clArk (covenantless Ark) en la billetera Arkade de Ark Lab se acerca a la misma línea de objetivo.
clArk tiene algunas deficiencias en comparación con una implementación completa de Ark, a saber, el requisito en una versión sin confianza para que cada usuario dentro de un Ark individual firme de forma colaborativa las transacciones de salida en un multisig masivo de n cuando se crea. Si tuviéramos CTV u otro convenio equivalente, los usuarios no necesitarían participar en un proceso de firma interactiva, y el Proveedor de Servicios Ark (ASP) podría simplemente crear el Arca usando un convenio y los usuarios podrían estar seguros de que tienen control total de sus fondos después de esto confirmado.
Ark presenta una compensación interesante en comparación con Lightning Network, ambos requieren que los participantes tengan un exceso de liquidez para poder recibir pagos. Sin embargo, en el caso de Lightning, es un juego complicado en el que los usuarios individuales tienen que descubrir dónde asignar su propia liquidez y cómo obtener liquidez de otros para poder enviar y recibir funcionalmente. Es un problema individual que cada usuario debe resolver solo. Con Ark, cualquier ASP puede asignar libremente parte de su liquidez a cualquiera de sus usuarios. Todavía necesito resolver el problema de obtenerlo, pero ya no existe el problema por usuario de decidir si vale la pena asignar liquidez en esa dirección, simplemente se puede hacer en el momento en que cualquier usuario individual lo necesite. de un fondo de liquidez común.
Sin embargo, todavía hay un problema con el problema de liquidez de Ark. Por cada pago que flota en un Arca que aún no se ha cerrado, la ASP debe anticipar liquidez para esos pagos para permitir a los usuarios recibirlos en una nueva Arca. Cuando la ASP llega a un punto en el que se está quedando sin liquidez, sus tarifas periódicas deben comenzar a dispararse para poder gestionar ese problema hasta que puedan recuperar la liquidez bloqueada cerrando Arks.
Creo que una forma de abordar esta curva de cola de tarifas más altas podría ser explorar algunas lecciones de Lightning, es decir, una topología enrutable. 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 crisis de liquidez podría «desviar» pagos de sus propios Arks a otro ASP con más liquidez disponible, estableciendo el vínculo ATLC entre su propio Ark desde el que se origina el pago y el Ark de otro ASP para recibirlo, ahorrando tarifas a los usuarios. A su vez, a medida que pueden recuperar liquidez a medida que cierran Arks existentes y sus propias tarifas bajan, otros ASP que experimentan una crisis de liquidez podrían «devolver el favor» devolviendo los pagos en su dirección.
Esto podría establecer una especie de round robin y una dinámica fácilmente analizable de “yo te rasco la espalda, tú me rascas la mía” entre los ASP, que si bien dejaría algunos ingresos sobre la mesa durante las crisis de liquidez con tarifas elevadas, en general crearía una experiencia más predecible y asequible para sus clientes. usuarios.
Esto conlleva el riesgo de que los pagos entre ASP como este esencialmente interconectan Arks entre diferentes ASP, lo que significa que los cierres no cooperativos requerirían el cierre de Arks operado por múltiples entidades, pero dado que los cierres cooperativos dependen del comportamiento del usuario, no Creo que esto cambia esencialmente el perfil de riesgo en ausencia de ASP que se aflijan intencionalmente entre sí. Sin embargo, esto podría verse como análogo al problema de interferencia de canales de Lightning.
Hay algunas ventajas y posibles desventajas, pero creo que este es un concepto que vale la pena explorar en términos de mejorar el problema de la crisis de liquidez de Ark.