[ad_1]
BitVM ha sido recientemente objeto de escrutinio después de que Taproot Wizards, Tyler y Rijndael, publicaran su críticas a las exigencias de liquidez impuestas al operador de una vinculación bidireccional basada en BitVM. En todas las discusiones recientes sobre las soluciones de capa dos basadas en BitVM, di por sentado que las personas que las discutían y estaban interesadas en el espacio de diseño entendían los requisitos de garantía/liquidez impuestos por la arquitectura a los operadores. La reciente discusión sobre el tema de la «crisis de liquidez» me muestra que estaba equivocado acerca de esta suposición, y que muchas personas fuera de las que participan activamente en el desarrollo de BitVM no estaban al tanto de este problema.
Antes de entrar en el tema de la crisis de liquidez, creo que es importante aclarar una de las propiedades únicas de una vinculación BitVM (llamada puentes por los desarrolladores de altcoins). En los puentes construidos en otras redes, los fondos retenidos en el contrato puente real que controla el movimiento de fondos entre redes son los que se utilizan para procesar los retiros. En el caso de una vinculación de BitVM, estos fondos no son accesibles para realizar retiros. El operador del sistema (rollup, sidechain, etc.) debe afrontar su propia liquidez para poder procesar las solicitudes de retiro de los usuarios.
A medida que llegan las solicitudes de retiro de los usuarios, el operador que avanza el estado acumulativo analiza cada solicitud y procesa esos retiros utilizando sus propios fondos personales. Después de un período, el sistema verifica su estado en un límite comprometiéndose a todos los retiros pendientes. Después del operador ha cumplido con todos los retiros pendientes del último estado Luego pueden participar en un proceso de reclamación de los fondos garantizados de BitVM para recuperar todo el capital que han adelantado. El contrato BitVM se establece para que a los operadores se les pueda revocar su capacidad de reclamar estos fondos si no han cumplido con todos los retiros pendientes del último estado.
Entonces, el flujo general de usuarios es un depósito que va a un contrato garantizado por BitVM, el operador aporta su propio capital para procesar los retiros y luego, periódicamente, el operador se compensa por el dinero que ha gastado de su bolsillo del contrato de BitVM. Esto distingue una vinculación de BitVM de cualquier otro tipo de vinculación bidireccional, introduciendo un requisito de liquidez similar a Lightning Network.
La crisis de liquidez
El problema que Taproot Wizards identificó en su artículo es el resultado de la combinación de los requisitos de liquidez iniciales impuestos al operador y el esquema a prueba de fraude que permite a los verificadores de BitVM revocar el acceso del operador a los fondos si no lo han hecho. cumplió con todos los retiros en una época acumulada determinada. Esto crea un gran problema potencial para el sistema y, en particular, para el operador.
Por ahora, ignoremos por completo el escenario potencial de que un operador se niegue intencionalmente a procesar un retiro debido a una censura maliciosa. Eso no es una preocupación por ahora al analizar los problemas potenciales, ya que si un operador hiciera tal cosa, debería se les revocará el acceso e incurrirán en la pérdida de los fondos que ya hayan gastado en el procesamiento de retiros.
Es absolutamente posible que un operador honesto se encuentre con una situación en la que, sin intención maliciosa de su parte, no tenga acceso a suficiente liquidez para procesar los retiros pendientes en una única época acumulada. Si esto sucediera, entonces un operador honesto ya no podría compensarse a sí mismo con el contrato BitVM por lo que tener procesados sin exponerse a que un solo verificador los cuestione y les haga perder permanentemente el acceso a los fondos. Todo lo que hayan gastado procesando retiros en esa época serían fondos perdidos que no podrían recuperar.
Esto crea un gran riesgo para un operador de clavijas. Sin ninguna acción maliciosa, simplemente mediante limitaciones de sus propios fondos, aumento de las tasas de interés en los fondos prestados, simplemente factores de tiempo necesarios para acceder a los fondos, pueden perder una enorme cantidad de dinero. Esto introduce una gran inestabilidad potencial en la vinculación y también plantea la pregunta ¿adónde va el dinero de los usuarios en caso de que un operador se encuentre con una prueba de fraude?
Las opciones
Lo importante a tener en cuenta es que el destino final de los fondos depende de las elecciones de diseño particulares realizadas por quienes implementan cualquier vinculación determinada. Hay un buen grado de libertad disponible en las opciones de diseño, el destino final de los fondos después de que un desafío expulsa a un operador tiene múltiples opciones, el período después del final de una época en el que un operador tiene para cumplir con todos los retiros es configurable, ninguna de estas cosas está establecida en piedra como única forma posible de configurarlos.
Ahora que entendemos el problema, veamos algunas posibles soluciones.
estrangulamiento
Podrías solucionar el problema limitando los retiros. Esto implicaría crear un límite máximo de fondos que un operador podría estar obligado a cumplir en virtud del contrato en cualquier época de acumulación determinada. Esto permitiría al operador asegurarse de tener suficiente capital para procesar la cantidad máxima que necesita. En cada período, el operador podría procesar esa cantidad de retiros, pasar por el proceso de reclamo para compensarse con el contrato de BitVM y luego, en la siguiente época, reciclar esa cantidad para cumplir con la siguiente ola de retiros.
El problema con esto es que no se sabe cuándo se producirá un gran aumento en los fondos vinculados al sistema, y tampoco se sabe cuándo se alineará la actividad del mercado para incentivar que una enorme cantidad de dinero quiera salir del sistema. . A medida que se vinculan más fondos, aumenta la posibilidad de un gran aumento en el volumen que se desea vincular de inmediato. Esta dinámica esencialmente conduce a una cola cada vez mayor para salir del sistema a menos que aumente el monto máximo de retiro de la época, lo que también aumenta los requisitos de liquidez para el operador.
Esto exacerba el requisito de liquidez que tienen estas vinculaciones y esencialmente crea una enorme fricción para los retiros. Los swaps no resuelven el problema, ya que esto en última instancia atrapa la liquidez de las contrapartes en esta cola cada vez mayor, a diferencia de otras vinculaciones bidireccionales donde podrían salir prácticamente inmediatamente después de facilitar el swap.
Múltiples operadores
Tanto BitVM 1 como BitVM 2 admiten tener múltiples verificadores de diferentes formas, permitiendo que más de uno participe y sea capaz de revocar el acceso de un operador a los fondos. También es posible en BitVM 2 (y algunas clavijas basadas en BitVM, como el paquete acumulativo de Citrea) tener múltiples operadores trabajando en paralelo. Más de una entidad puede ayudar a procesar los retiros de la vinculación, por lo que hay múltiples fondos de liquidez disponibles para facilitar la vinculación.
En principio, esto haría que toda la dinámica de liquidez fuera mucho más escalable, ya que ya no se limitaría a que una sola entidad tuviera que afrontar la liquidez para facilitar los retiros oportunos del sistema, sino que introduce cuestiones de complejidad. Cada UTXO depositado en la clavija BitVM y sujeto al contrato debe tener definidos los términos de reclamación. Ese contrato ahora debe poder distinguir entre múltiples operadores y garantizar un medio para distinguir qué retiros están asociados a qué operador, y garantizar que solo puedan reclamar lo que han facilitado en lugar de los fondos destinados a un operador diferente.
También debe tener en cuenta cómo manejar la demanda global de retiros que todos los operadores existen para facilitar. ¿Qué pasa si cada operador ha utilizado todo el capital que tiene, pero todavía hay demanda insatisfecha? ¿A todos se les revocó el acceso a los fondos de BitVM? ¿Ninguno de ellos? ¿Existe algún período de gracia de transferencia similar a tener un acelerador de cola? Si lo hay, ¿quién es responsable si esos retiros aún no se facilitan en la próxima época? Todas estas son cosas que deben resolverse concretamente.
Múltiples operadores lineales
Además de tener múltiples operadores paralelos, podría tener una cadena de operadores lineales. Un solo operador podría funcionar a la vez, facilitando los retiros, y si alguna vez tuvieran un problema de liquidez y se les revocara el acceso a los fondos de BitVM, los fondos después de un proceso de impugnación/revocación podrían enviarse inmediatamente a un nuevo BitVM con un nuevo operador. Esto no abordaría en absoluto el riesgo de que un solo operador sufra una crisis de liquidez y se daría cuenta de la pérdida de los retiros que ya depositaron, pero garantizaría que alguien más pudiera intervenir y tener la oportunidad de continuar facilitando los retiros con la capacidad. reclamar una indemnización a BitVM.
Sin embargo, esto añade un coste considerable al proceso de vinculación. Generar una instancia de BitVM no es barato en términos de datos e interactividad, lo que significa que para encadenar operadores lineales de BitVM de esta manera, debe generar para las vinculaciones esa cantidad de BitVM.
El respaldo
En todos los casos de vinculación que utiliza BitVM, existe una pregunta fundamental: ¿adónde irán finalmente los fondos en el peor de los casos? En última instancia, hay dos opciones. O quemas los fondos o los pones bajo el control de un verificador. El primero significa que los fondos de los usuarios ahora se destruyen y todos los que tienen fondos en la vinculación ahora son resistentes. El segundo significa que el modelo de confianza ha pasado directamente a confiar en un verificador individual o en un grupo de verificadores en una federación que controla unilateralmente los fondos.
Quemar los fondos es imposible en un modelo sin un acelerador de retiro, ya que eso validaría las preocupaciones del peor de los casos expresadas por Taproot Wizards. Un caso de falla constante de los operadores, independientemente de si son paralelos o lineales, resultaría en la destrucción de los fondos de los usuarios. El único modelo en el que sería remotamente seguro sería con un acelerador de retirada; pero incluso entonces, si los operadores definidos en el contrato desaparecieran o se les revocara el acceso, seguiría existiendo el riesgo de pérdida permanente de fondos.
Eso deja los fondos nuevamente bajo el control de un solo verificador o de un grupo de ellos. En caso de un fallo total de todos los operadores, esto permitiría a los verificadores involucrados en el sistema recuperar los fondos de los usuarios y compensarlos. No creo que esto sea tan malo.
Cada instancia de BitVM está configurada con un multisig n de n que maneja la firma de todas las transacciones prefirmadas involucradas en el contrato de BitVM. El modelo de seguridad fundamental de todo el esquema es que uno solo de esos poseedores de claves debe ser honesto y negarse a firmar una dispersión de fondos deshonesta, para que el sistema sea seguro.
Ese mismo modelo de seguridad se puede aplicar a dónde van los fondos (menos los operadores) en caso de una falla total del operador. Sin embargo, eso introduce el riesgo de que se pierda una sola clave o de que no coopere con la quema de fondos, por lo que también podría convertirlo en un multifirma m-of-n convencional.
No veo ningún problema en este tipo de configuración, logra el objetivo de garantizar que los fondos de los usuarios no se quemen irrevocablemente sin crear una alteración salvaje en el modelo de confianza. En última instancia, si no es un participante directo del contrato BitVM, es decir, si posee una de esas n de n claves, todavía está confiando en una federación de algún tipo. Obviamente, tener que confiar en un solo miembro para mantener las cosas seguras es superior a tener que confiar en 3 personas en un multifirma de 5 de 7, pero sigue siendo una forma de confianza delegada.
Terminando
Al final del día, creo que el problema de la crisis de liquidez identificado por Taproot Wizards es un problema muy legítimo. Dependiendo de la arquitectura específica de la vinculación en cuestión, podría introducir problemas que van desde quemar completamente los fondos de los usuarios, hasta perder los fondos de los operadores incluso sin una acción maliciosa, o simplemente crear una cola cada vez mayor para salir sin detener los depósitos ni recurrir a la grupo n-de-n para evitar la cola.
Sin embargo, en mi opinión, no es algo que signifique que la idea de usar BitVM para asegurar una vinculación bidireccional sea una idea fundamentalmente fallida. Creo que he expuesto una buena cantidad de formas en que implementaciones específicas podrían respaldar o mitigar el problema y, en última instancia, la realidad del grupo n de n existente y el potencial de enviar fondos en un caso de fracaso a un grupo delegado para manejar los retiros podría abordar el riesgo de pérdida permanente de fondos.
Como última nota, el ritmo de desarrollo en este espacio ha alcanzado un ritmo en el último año que nunca había visto en mi tiempo aquí, creo que es importante cuando se habla de estos desarrollos dar un paso atrás y mantener la cabeza tranquila mientras observando las discusiones que ocurren sobre compensaciones y riesgos. Sí, la percepción pública es un aspecto de estas conversaciones que ocurren en público, pero estas discusiones deben estar arraigadas en el objetivo de llegar a una comprensión precisa de los temas en cuestión. Eso no debería pasar a un segundo plano ante el intento de ilícitar o defender en primer lugar cualquier percepción pública en particular.
[ad_2]
Una información de Bitcoin Magazine – Bitcoin News, Articles and Expert Insights