Jeremy Rubin publicó una propuesta hace dos semanas titulada Un’FE’d Covenants (FE = Cifrado funcional). Dado el debate en curso sobre las propuestas de pactos para Bitcoin durante los últimos dos años, su propuesta marca una nueva opción práctica. Todas las propuestas de pacto hasta ahora requieren una bifurcación suave (códigos de operación reales), el desarrollo y la implementación de criptografía no probado (Cifrado funcional) o un costo monetario absurdamente alto para su uso (ColliderScript).
La propuesta de Jeremy no requiere bifurcaciones blandas y no impone un costo gravoso y poco práctico para que los usuarios la utilicen. La compensación por esa capacidad es un modelo de seguridad radicalmente diferente. Mediante el uso de un sistema de oráculos y bonos basados en BitVM capaces de recortar, los convenios se pueden emular en Bitcoin ahora mismo.
Los Oráculos
La primera parte del esquema son obviamente los oráculos que imponen diferentes condiciones del pacto. Esta es una configuración relativamente sencilla y el primer elemento necesario para la propuesta de Jeremy. El oráculo tiene la custodia de los fondos de este plan y se le confía la aplicación de las condiciones del pacto. Quiere que el oráculo no tenga que realizar un seguimiento local de las condiciones del pacto que se aplican para cada moneda que custodia. Esto introduce un riesgo estatal en el que, si la base de datos de Oracles se corrompe o se pierde, no tiene idea de cómo manejar la aplicación honesta de las monedas de todos. Para solucionar este problema, Jeremy utiliza Taproot.
Las claves basadas en Schnorr se pueden «modificar» utilizando el hash de datos para modificar una clave pública. Esto permite modificar la clave privada correspondiente para poder firmar por la clave modificada, así como demostrar que cualquier dato que se haya utilizado para modificar la clave pública está comprometido con esa clave. Hacer que Oracle genere una clave y luego que el usuario modifique esa clave con su programa de convenio permite un compromiso con lo que se supone que debe hacer cumplir el Oracle mientras se mantiene la carga de almacenar esa información en el usuario.
Los oráculos también se pueden federar para minimizar la confianza requerida en una sola parte para hacer cumplir las cosas. Desde aquí, los usuarios pueden simplemente cargar la dirección resultante y, cuando quieran hacer cumplir la condición, acercarse al oráculo con la transacción de gasto, el programa del oráculo y los datos del testigo necesarios para demostrar que la transacción dada al oráculo cumple las condiciones. del pacto. Si la transacción es válida según las reglas del pacto, el oráculo la firma.
Para cualquier convenio simple donde los resultados se conocen de antemano, como CHECKTEMPLATEVERIFY (CTV), los usuarios pueden hacer que Oracle prefirme inmediatamente las transacciones que hacen cumplir el convenio y simplemente retrasar su uso hasta que sea necesario.
Un escenario importante a considerar que requiere funcionalidad adicional son los convenios basados en estados, como los paquetes acumulativos, que progresan regularmente y tienen un estado real (el saldo actual de usuarios) del que realizan un seguimiento. En el caso de tales convenios, las transacciones que firma Oracle deben comprometerse con el estado actual del convenio utilizando OP_RETURN para que Oracle pueda verificar de manera eficiente cada transacción actualizando el resumen u otro sistema sin tener que descargar datos de testigos para todo el historial. Esto es para evitar que Oracle tenga que almacenar el estado localmente, lo que, como se señaló anteriormente, genera riesgos.
A largo plazo, los requisitos de datos de los oráculos se pueden optimizar mediante el uso de pruebas de conocimiento cero, de modo que el oráculo pueda simplemente verificar una prueba de que la transacción que se les pide que firmen sigue las reglas del pacto sin tener. que verificar los datos brutos de los testigos. para convenios más grandes y complejos. Sin embargo, una vez más, en el caso de sistemas como los rollups, se debe tener cuidado al diseñarlos para garantizar que los datos necesarios para salir del sistema estén disponibles para los usuarios, de modo que los tengan en su poder si necesitan comunicarse directamente. con el oráculo para reclamar su cuenta. fondos.
El vínculo BitVM
Hasta ahora, se confía plenamente en el plan. Básicamente, simplemente le estás dando tu dinero a otra persona y esperando que se pueda confiar en que hará cumplir las condiciones de los convenios arbitrarios. Modificando ligeramente el esquema anterior, esto se puede asegurar con un incentivo criptoeconómico en lugar de pura confianza.
Arriba se describe cómo se requiere utilizar OP_RETURN para rastrear el estado de los convenios con estado. OP_RETURN también se puede utilizar para publicar los datos de los testigos de cualquier transacción de pacto para demostrar que las condiciones se cumplieron correctamente.
Se puede construir un circuito BitVM para verificar si una transacción firmada por el oráculo coincide con éxito con las condiciones del pacto que está aplicando. Recuerde que la clave en sí que se genera y los fondos enviados se comprometen con las condiciones de cualquier convenio que se aplique. Lo que significa que los datos, así como una transacción que se realiza desde la dirección, se pueden introducir en una instancia de BitVM.
Luego se puede exigir a los Oráculos que presenten una prometida con un operador de BitVM (que también debe presentar una fianza para que Oracle la reclame si se le acusa falsamente). De esta manera, siempre que el valor del bono sea mayor que el valor garantizado en los pactos por un oráculo, el sistema se puede utilizar de forma segura. No habría forma de que un oráculo violara las condiciones de un pacto que está haciendo cumplir sin perder dinero en conjunto.
Compensaciones
Aquí hay claras compensaciones que son materialmente peores que simplemente implementar acuerdos en reglas de consenso. En primer lugar, el oráculo debe estar en línea y ser accesible para poder utilizar los convenios impuestos por el oráculo. Con la excepción de los convenios prefirmados como CTV, si el oráculo está fuera de línea cuando los usuarios necesitan hacer cumplir un convenio, no pueden hacerlo. El oráculo debe estar presente para firmar.
En segundo lugar, los requisitos de liquidez para los bonos Oracle pueden volverse enormes si el sistema alguna vez se adopta ampliamente. Esto lo hace increíblemente ineficiente en comparación con la implementación nativa de códigos de operación de pactos a nivel de consenso.
Por último, los datos adicionales que deben publicarse en la cadena para que funcione el esquema de bonos BitVM son mucho menos eficientes con el uso del espacio de bloques que las implementaciones de convenios nativos.
En general, la propuesta no es tan eficiente y segura como los pactos nativos. Por otro lado, si terminamos en el peor de los casos de osificación prematura, esta es una forma muy viable de calzar pactos en Bitcoin sin depender de criptografía no probada o de costos completamente imprácticos impuestos a los usuarios finales.
Jeremy nos ha dado la opción del peor de los casos para ampliar el espacio de diseño de lo que se puede construir en Bitcoin.