Taproot Wizards lanzó ayer una caricatura llamada gatovm. No me referiré a él como un documento técnico, son documentos académicos reales para adultos. En la caricatura, intercaladas entre las absurdas narrativas infantiles, había algunas ideas técnicas valiosas sobre diferentes propuestas de escala en el ecosistema de Bitcoin. Por supuesto, al más puro estilo caricaturesco, enterrado entre la exageración salvaje y el embellecimiento.
El objetivo final de la caricatura era proponer un nuevo mecanismo para entrar y salir de las capas de escala construidas sobre Bitcoin. Para desenredar esa propuesta real de la caricatura, tendremos que dividir las dos piezas involucradas.
Los bloques de construcción
El primer experimento OP_CAT de Rijndael fue la construcción de una bóveda, un esquema que permite al usuario crear una transacción intermedia «preparada» para retirar sus fondos de la bóveda. Esto inicia un bloqueo de tiempo, durante el cual en cualquier momento pueden enviar sus fondos a la bóveda oa una billetera segura de almacenamiento en frío, y después del bloqueo de tiempo, el usuario puede retirar libremente los fondos al destino que eligió al comenzar el proceso de retiro. Estos son los solo Hay dos formas en que se pueden gastar los bitcoins enviados a la bóveda.
Explicar la mecánica completa de cómo se logra esto es esencialmente un artículo en sí mismo, así que hará algo que normalmente no hago y lo descartaré como «mágico». (Explicado aquí por Andrew Poelstra) Lo que esta “magia” le permite hacer, al crear firmas Schnorr no estándar y con la ayuda de OP_CAT, es construir la transacción con la que se verifica la firma en la pila de script. Esto le permite exigir que ciertas partes de la transacción sean exactamente como se definieron de antemano. También le permite colocar el resultado de una transacción anterior en la pila en el proceso de creación de la transacción gastándolo, lo que significa que puede comparar los resultados de la transacción de gasto con los resultados de la transacción anterior. Esto le permite garantizar, comparándolos, que ciertas partes de los resultados de la transacción anterior coinciden con ciertas partes de los nuevos resultados. Es decir, el guión o una cantidad. Por lo tanto, puede «trasladar» partes de los resultados antiguos a los nuevos y aplicarlos.
Otra cosa que puedes hacer con OP_CAT, que no necesitó que Rijndael retocara ni experimentara para demostrarlo, es verificar las ramas de los árboles merkle. Debido a que CAT puede apilar elementos juntos, y Bitcoin ya admite datos hash en la pila, puede construir lentamente una raíz de árbol merkle a partir de un nodo hoja con los nodos interiores. Combina dos piezas para obtener un hash, hazlo con el par de hash, y así sucesivamente. Finalmente obtienes el hash raíz en la pila. Luego puede compararlo con OP_EQUAL con un hash raíz predefinido en el script de bloqueo.
retiro unilateral
Estos dos componentes son suficientes para facilitar un mecanismo de retirada unilateral de un UTXO compartido en grupo. Se puede incrustar una raíz merkle en una transacción usando OP_RETURN u otro mecanismo que se compromete con un nodo hoja para cada usuario. El script UTXO se puede estructurar para que cualquier usuario con saldo pueda intentar retirarlo. Para hacerlo, proporcionarían a la sucursal de Merkle el compromiso de la cantidad a la que tienen derecho, la prueba de autorización, como una clave pública para verificar una firma, y construirían la transacción en la pila para verificar que se cumplan las condiciones. apropiadas.
De manera similar a la bóveda OP_CAT de Rijndael, esta transacción de retiro funcionaría como un punto de parada. Los fondos de los usuarios estarían restringidos por un bloqueo de tiempo y no podrían completar el retiro hasta que expire. En cualquier momento antes de que expire el bloqueo de tiempo, cualquier otro usuario puede crear una prueba de fraude para detener el retiro y devolver los fondos al script UTXO del grupo. Pueden hacer esto gracias a la capacidad de OP_CAT para verificar árboles merkle. Si alguien ha usado una rama merkle específica para retirar fondos del UTXO antes, entonces eso se incluirá en un bloque en alguna parte. Al construir una transacción que contiene la prueba SPV de esa transacción dentro de un bloque real, que puede usar OP_LESSTHANOREQUAL para verificar que el encabezado del bloque cumple con una dificultad mínima, pueden probar en la pila que la rama merkle se nosotros antes. Esto permite evitar retiros duplicados.
Además de esto, debido a que puede usar el truco «CAT en la pila» para garantizar que las partes específicas de una transacción anterior se incluyan en la siguiente, puede garantizar que la raíz de merkle actual se transfiera a la siguiente transacción después de una transacción exitoso. retiro. También puede garantizar que el cambio del retiro regrese al script para compartir en grupo. Esto garantiza que después de que un usuario retire sus fondos, el UTXO de cambio se bloquea con un script que permite a cualquier usuario restante retirarlos, y así sucesivamente. Cualquier usuario puede retirar unilateralmente sus fondos en cualquier momento y en cualquier orden, con la garantía de que el resto de los fondos siguen siendo accesibles para el resto de usuarios.
La parte de la máquina virtual.
Los lectores deben estar familiarizados con la idea básica de BitVM. Se puede tomar un cálculo arbitrario y dividirlo en cada una de sus partes constituyentes e incrustarlas en un gran árbol de raíz principal, convirtiendo ese cálculo en un juego de desafío/respuesta de ida y vuelta. Esto le permite bloquear bitcoins con condiciones más complicadas que las que admite directamente el propio script de bitcoin. El único defecto real es la necesidad de elaborar una gran cantidad de transacciones prefirmadas para facilitar esto.
El requisito de utilizar transacciones prefirmadas es para que, en la dinámica de desafío/respuesta, pueda garantizar que las monedas se gasten nuevamente en el gran árbol de raíz principal que las codificadas, a menos que se alcance una condición de salida en un sentido u otro. OP_CAT y la capacidad de «trasladar» datos de transacciones anteriores le permite garantizarlo sin necesidad de transacciones prefirmadas.
Entonces, este esquema no solo permite que cualquier usuario salga unilateralmente por su cuenta, sino que también permite que las condiciones de bloqueo respaldadas por una segunda capa que no son respaldadas por el script de Bitcoin se aplican en el proceso de retiro. Es decir, si algunas monedas estuvieran gravadas por un contrato inteligente que la capa base no comprende y luego se retiraran de la segunda capa, esas condiciones más complicadas aún podrían resolverse correctamente en la capa base a medida que se retiren las monedas.
La pieza que falta
Una cosa que OP_CAT no habilita es la actualización de la raíz del árbol merkle que representa los saldos de los usuarios fuera de la cadena de manera verificable. Puede permitir que un Estado ya esté comprometido facilite retiradas unilaterales, pero eso se debe a que en realidad se pone en cadena y se verifica una sección completa del árbol. Actualizar esa raíz fuera de la cadena, por definición, significa que no está poniendo los datos en la cadena. Esto representa un problema. No hay forma solo con CAT de verificar de manera eficiente que todos los cambios en el árbol merkle fueron autorizados correctamente por los usuarios relevantes.
Se debe confiar en alguien y, por la naturaleza de las cosas, es capaz de gastar el UTXO como y donde quieran, para reemplazar de manera eficiente una antigua raíz estatal por una nueva para representar todos los cambios de equilibrio fuera de la cadena. Se necesitaría un nuevo código de operación además de OP_CAT, como OP_ZKVERIFY, para hacer esto sin confianza.
Sin embargo, este no sería el fin del mundo sin OP_ZKVERIFY. La entidad que actualiza la raíz de merkle para transferencias fuera de la cadena podría ser una firma múltiple n de n, y el 100% de los participantes deberán aprobar cualquier cambio de raíz. Esto se reduce al mismo modelo de confianza que las vinculaciones basadas en BitVM, donde mientras exista un único participante honesto, no se pueden robar los fondos de nadie. Sin embargo, es una gran mejora con respecto a los diseños de BitVM existentes en lo que respeta al proceso de retiro.
En las clavijas de BitVM, los usuarios no tienen un mecanismo de retiro unilateral. Se debe confiar en los operadores de clavijas para realizar los retiros de los usuarios, sabiendo que pueden reclamar los fondos que han gastado al hacerlo de manera relativamente confiable desde la clavija de BitVM. Si bien los incentivos de esto son muy sólidos, todavía requiere que los usuarios obtengan esencialmente el permiso de otra persona para salir del sistema, no pueden hacerlo por sí mismos. Con CatVM, los usuarios pueden reclamar sus fondos unilateralmente y no se requiere que un operador enfrente su propia liquidez para procesar los retiros.
terminando
En general, el diseño está incompleto en términos de construcción. Esto no es algo que yo llamaría Capa 2 en sí mismo. Es el núcleo de uno, el mecanismo y la estructura de cómo se bloquean los fondos en una Capa 2 y el proceso de cómo los usuarios pueden retirar sus fondos. Definitivamente tiene mucha flexibilidad y utilidad.
En el peor de los casos, los usuarios no necesitan el permiso de nadie para reclamar de forma segura sus fondos en la cadena. También permite una programabilidad más flexible de los fondos, sin dejar de llevar la aplicación de esas condiciones al nivel base en caso de que se produzcan salidas unilaterales en el peor de los casos. Si algún día finalmente obtenemos algo como OP_ZKVERIFY, la progresión del estado fuera de la cadena puede convertirse en un proceso realmente sin confianza.
No espero ninguna demostración concreta en el futuro cercano, pero en mi opinión definitivamente es una buena idea y algo que vale la pena considerar. También muestra que los magos están haciendo algo más que simplemente generar archivos JPEG estúpidos.