Comprender la programabilidad de un sistema requiere que identifiquemos las características estructurales del sistema. La exploración de la programación de aplicaciones basada en Bitcoin Script nos ayuda a comprender la estructura básica de CKB Cell y su paradigma de programación. No solo eso, sino que desglosa los componentes de programación del CKB en las piezas correctas y nos ayuda a comprender las ganancias de programabilidad que aporta cada parte.
I. Introducción
La "programabilidad" es una dimensión que las personas suelen tomar al comparar sistemas blockchain. Sin embargo, a menudo hay desacuerdo sobre cómo se describe la programabilidad. Una expresión común es "XX blockchain soporta lenguajes de programación Turing-completos", o "XX blockchain soporta programación de propósito general", que pretende indicar que la "XX blockchain" aquí tiene una fuerte programabilidad. Hay algo de verdad en la implicación de estas afirmaciones: los sistemas que soportan la programación completa de Turing son generalmente más fáciles de programar que los que no lo hacen. Sin embargo, hay muchos aspectos en las características estructurales de un sistema de contratos inteligentes, y esta afirmación toca solo uno de ellos, por lo que no es suficiente para ser entendido con suficiente profundidad en virtud del hecho de que los desarrolladores no se guían por él, y no se puede confiar en los usuarios comunes para distinguir el fraude.
Las características estructurales de un sistema de contratos inteligentes incluyen:
La forma básica de expresión del estado (contrato) (cuenta vs. salida comercial)
Si se permite o no la programación de cálculos arbitrarios (de esto se trata el término "Turing-completo")
¿El proceso de ejecución crea nuevos datos o simplemente reparte booleanos? (Proceso frente a validación)
Si se permite o no que se registren estados adicionales dentro del contrato
Si un contrato tiene acceso al estado de otro contrato cuando se ejecuta
Por lo tanto, además de la "computación arbitraria programable", hay al menos cuatro características que afectan la programabilidad de un sistema de contrato inteligente. Incluso se puede decir que estas otras características son más importantes, porque determinan a un nivel más profundo lo que es fácil de lograr y lo que es difícil de lograr; ¿Qué es una implementación más económica y qué es una implementación menos eficiente?
Por ejemplo, Ethereum se cita a menudo como un ejemplo de buena programabilidad, pero la forma básica de expresión de estado en Ethereum es una cuenta, lo que dificulta la programación de contratos peer-to-peer (por ejemplo, pasarelas de pago, contratos de apuestas uno a uno), lo que no es absolutamente imposible, solo ingrato. No es raro que el ecosistema Ethereum intente implementar un canal de pago/canal de estado, y ha habido muchas discusiones teóricas, pero estos proyectos ya no parecen estar activos, y esto obviamente no se puede culpar a la falta de esfuerzo por parte de los desarrolladores. No es casualidad que los proyectos activos en Ethereum hoy en día estén tomando la forma de "pools" en lugar de "contratos peer-to-peer". Del mismo modo, la gente puede estar contenta con la programabilidad de Ethereum, pero el modelo de cuenta es inherentemente deficiente para lograr la "abstracción de la cuenta" (que también puede entenderse como una generalización del concepto de billetera).
De la misma manera, explorar la programabilidad de CKB también requiere que entendamos las características estructurales del sistema de contratos inteligentes de CKB en estos aspectos. Lo que ya sabemos es que CKB permite programar cálculos arbitrarios, permite registrar estados adicionales dentro de un contrato y permite que un contrato acceda al estado de otro contrato cuando se ejecuta. Sin embargo, la forma del contrato es el resultado de una transacción (llamada "célula"), lo que lo hace fundamentalmente diferente de Ethereum. Por lo tanto, una comprensión del sistema de contratos inteligentes de Ethereum y las instancias de contratos dentro de él no nos ayuda a comprender cómo CKB implementa estas características estructurales, ni nos ayuda a comprender la programabilidad de CKB.
Afortunadamente, los contratos inteligentes en Bitcoin parecen proporcionar la mejor base para comprender la programabilidad de CKB. Esto no solo se debe a que la forma básica de la representación estatal de Bitcoin es también la salida de transacciones (llamadas "UTXO"), sino también porque, con la ayuda de un concepto propuesto por la comunidad de Bitcoin llamado "covenants", podemos entender por qué CKB tiene estas características estructurales, y desglosar adecuadamente el efecto final en varias partes, identificando las ganancias de programabilidad que aporta cada una de ellas.
II. CKB v.s. BTC: ¿Qué más?
(1) Estructura básica
Como forma básica de la representación del estado de Bitcoin, el UTXO ("Salida de transacción no gastada") de Bitcoin tiene dos campos:
La cantidad, en Satoshi, indica el valor de Bitcoin que posee el UTXO;
La clave pública del script, también conocida como script de bloqueo, representa las condiciones que deben cumplirse para gastar los fondos, es decir, el programa de contrato inteligente que establece las condiciones para desbloquear los fondos.
En comparación con los sistemas de contratos inteligentes que vinieron después, Bitcoin Script es bastante limitado:
No permite programar cálculos arbitrarios; Solo hay unos pocos cálculos prácticos que se pueden utilizar para la verificación (verificación de firmas, verificación previa al hash, verificación de tiempo)
No permite que se registren estados adicionales dentro del contrato; (Por ejemplo, no puede usar un script para limitar la cantidad proporcional/máxima de dinero gastado a la vez; Tampoco hay forma de ocultar un token en él)
Tampoco permite acceder al estado de otro contrato en el momento de la ejecución (cada script es un universo separado y no depende el uno del otro).
Este tipo de scripting, aunque limitado, no carece de la capacidad de programar aplicaciones increíbles, y es la base de nuestra exploración de la programabilidad de CKB. Habrá una sección más adelante que presentará dos ejemplos de programación de Bitcoin Script.
Por el contrario, la unidad de estado de la CKB se denomina "celda" y tiene cuatro campos:
La capacidad, similar a la cantidad de UTXO, expresa la cantidad de espacio que puede ocupar la celda, medida en bytes.
Lock, similar a la clave pública del script UTXO, define la propiedad de la celda; Solo cuando los datos proporcionados pueden pasar a través de la cerradura, la celda se puede "actualizar" (o la celda se puede liberar y la capacidad se puede usar para acuñar nuevas celdas);
Datos, datos, datos arbitrarios, cuyo volumen está limitado por la capacidad;
Type, un script opcional que establece las condiciones para actualizar los datos.
Además, Lock y Type se pueden programar para cálculos arbitrarios. Puede programar cualquier algoritmo de verificación de firmas, puede programar cualquier algoritmo hash para la comprobación de preimágenes, etc.
Es fácil para los lectores ver cómo la programabilidad de Cell mejora con respecto a los UTXO:
Las celdas se pueden programar con cálculos arbitrarios, en lugar de solo unos pocos cálculos específicos; Su verificación de la titularidad será más flexible;
Debido a los campos Datos y Tipo, la celda puede registrar estados adicionales; Esto permite que la celda lleve lo que se conoce como "UDT" (token definido por el usuario).
Combinado con la estructura de "salida de transacción" de la propia célula, los beneficios de estos dos puntos en sí mismos son muy, muy significativos, pero solo a partir de la descripción anterior, no sabemos cómo la célula logra que "un contrato acceda al estado de otro contrato en tiempo de ejecución". Para ello, tenemos que recurrir a un concepto que se ha discutido durante mucho tiempo en la comunidad Bitcoin: los "covenants".
(2) Limitaciones e introspección
El propósito original de una cláusula de restricción es limitar dónde se puede gastar una suma de dinero. En el Bitcoin actual (donde no se han propuesto restricciones), una sola cantidad de dinero, una vez desbloqueada, se puede gastar en cualquier lugar (se puede pagar a una clave pública de script arbitraria). Pero la idea de la cláusula de restricción es que se puede gastar de una manera que lo limite a ciertos lugares, por ejemplo, una determinada UTXO solo se gastará en una determinada transacción, de modo que incluso si alguien puede proporcionar una firma para la UTXO, dónde se puede gastar ya ha sido determinado por esa transacción. Esto puede parecer un poco extraño, pero puede dar lugar a algunas aplicaciones interesantes, que se tratarán en una sección más adelante. Es importante destacar que es clave para nuestra mayor comprensión de la programabilidad de CKB.
Rusty Russell señala acertadamente que una restricción puede entenderse como una capacidad de "introspección" para operar, es decir, cuando una transacción B gasta un UTXO A, un operador de script puede leer parte (o toda) de la transacción B y luego verificar que coincidan con los parámetros solicitados previamente por el script. Por ejemplo, si la clave pública del script para la primera salida de la transacción A coincide con lo requerido por la clave pública del script de UTXO A (esto es lo que significaba originalmente la restricción).
El lector astuto se dará cuenta de que con una introspección completa, la entrada de una transacción puede leer el estado de otra entrada de la misma transacción, lo que permite la capacidad de un contrato para acceder al estado de otro contrato en tiempo de ejecución. De hecho, así es exactamente como se diseñó CKB Cell.
En base a esto, podemos dividir esta completa capacidad introspectiva en cuatro escenarios:
La cerradura lee otras cerraduras (de entrada y salida)
El bloqueo lee el tipo (así como los datos) del otro (entrada y salida)
El tipo lee otras cerraduras (de entrada y salida)
Tipo lee el Tipo (y Datos) del otro (entrada y salida)
Esto nos permite analizar el papel de las capacidades introspectivas de cada parte en diferentes casos de uso bajo ciertos supuestos (la división de funciones entre Lock y Type), es decir, la ganancia de programabilidad que nos aporta cada parte.
En las siguientes dos secciones, veremos la programación actual (y aún no propuesta) de Bitcoin Script, y la probable funcionalidad que se espera que logre la restricción propuesta, para dar una comprensión concreta de cómo se puede programar y hacer mejor CKB Cell.
III. Programación de scripts de Bitcoin
En esta sección, usaremos "Lightning Channel/Lightning Network" y "Caution Journal Contract (DLC)" como ejemplos de programación de aplicaciones basadas en Bitcoin Script. Antes de entrar en eso, analicemos dos cosas.
(1) OP_IF y "Acuerdos de compromiso"
El primer concepto es el código de operación de control de flujo en Bitcoin Script, como: OP_IF, OP_ELSE. Estos códigos de operación no son diferentes de IF en la programación de computadoras, y su propósito es ejecutar diferentes instrucciones basadas en diferentes entradas. En el contexto de Bitcoin Script, esto significa que podemos establecer múltiples rutas de desbloqueo para los fondos; Combinado con la función de bloqueo de tiempo, esto significa que podemos asignar prioridad a las acciones.
Tomemos como ejemplo el famoso "Contrato de bloqueo de tiempo de hash (HTLC)", que se traduce en lengua vernácula:
Alternativamente, Bob podría revelar la preimagen detrás de una H de hash y dar su propia firma, lo que costaría el dinero
O bien, Alicia puede gastar el dinero con su propia firma después de un cierto período de T
Este "o ... o ..." El efecto se logra a través del código de operación de control de procesos.
La ventaja más destacada de > HTLC es que puede agrupar múltiples operaciones y atomizarlas. Por ejemplo, si Alice quiere intercambiar BTC por CKB con Bob, entonces Bob puede primero dar un valor hash y crear un HTLC en la red Nervos. A continuación, Alice crea un HTLC en Bitcoin que utiliza el mismo hash. Alternativamente, Bob toma el BTC pagado por Alice en Bitcoin, al mismo tiempo que revela la preimagen, lo que permite a Alice retirar CKB en la red Nervos. De cualquier manera, Bob no revela la imagen original, ambos contratos expiran y tanto Alice como Bob pueden recuperar el dinero que invirtieron.
Después de la activación de la bifurcación suave Taproot, esta función de ruta de desbloqueo múltiple se mejora aún más con la introducción de MAST (Merkle Abstract Syntax Tree): podemos convertir una ruta de desbloqueo en una hoja en el árbol de Merkle, cada hoja es independiente, por lo que ya no es necesario usar un código de operación de control de flujo de este tipo; Además, debido a que una ruta se revela sin exponer las demás, podemos agregar un mayor número de rutas de desbloqueo a una salida sin tener que preocuparnos por la economía.
El segundo concepto es el "trading de compromiso". La idea de una transacción comprometida es que, en algunos casos, una transacción válida de Bitcoin, incluso si no está confirmada por la cadena de bloques, es igual de real y vinculante.
Por ejemplo, Alice y Bob comparten un UTXO que requiere que ambos estén firmados para gastar. En este punto, Alice construye una transacción para gastarlo, transfiriendo el 60% de su valor a Bob y el resto a sí misma; Alice proporciona su propia firma para la transacción, que luego se envía a Bob. Bueno, para Bob, no tiene que ser transmitido a la red Bitcoin, y no tiene que ser confirmado por la cadena de bloques, y el efecto de pago de esta transacción también es real y creíble. Debido a que Alice no puede gastar el UTXO por su cuenta (y, por lo tanto, no puede gastarlo repetidamente), y debido a que la firma proporcionada por Alice es válida, Bob siempre puede agregar su firma y transmitir la transacción para honrar el pago. En otras palabras, Alice proporcionó a Bob un "compromiso creíble" a través de esta transacción válida (fuera de la cadena).
Las transacciones comprometidas son un concepto central de la programación de aplicaciones de Bitcoin. Como se mencionó anteriormente, el contrato de Bitcoin se basa en la verificación, no tiene estado y no permite el acceso cruzado; Sin embargo, si el contrato no lleva estados, ¿dónde se almacenan esos estados y cómo puede avanzar el contrato de manera segura (cambiar de estado)? Las transacciones de compromiso dan una respuesta sencilla: el estado del contrato se puede expresar en forma de transacciones, de modo que los participantes del contrato pueden salvar el estado por sí mismos sin tener que mostrarlo en la cadena de bloques; El problema de cambiar el estado del contrato también puede transformarse en el problema de cómo actualizar de forma segura la transacción comprometida; Además, si nos preocupan los peligros de celebrar un contrato (por ejemplo, celebrar un contrato que requiere que ambas partes firmen para gastar, y existe el riesgo de que la otra parte no responda y se quede atascada), entonces simplemente generar una transacción de compromiso que cueste el contrato por adelantado y obtener una firma puede mitigar el riesgo y eliminar la confianza en otros participantes.
(2) Lightning channel y lightning network
Un canal relámpago es un contrato uno a uno en el que dos partes pueden pagarse mutuamente un número ilimitado de veces sin que la cadena de bloques confirme ningún pago. Como es de esperar, utiliza el trading de compromiso.
En la sección que explica "Transacciones comprometidas", ya hemos introducido un canal de pago. Sin embargo, este tipo de contrato, que solo aprovecha la multifirma 2 de 2, solo puede permitir pagos unidireccionales. Es decir, o Alicia siempre le paga a Bob, o Bob siempre le paga a Alicia hasta que él agota su saldo en el contrato. Si se trata de un pago bidireccional, significa que después de una actualización de estado, una de las partes puede tener menos saldo que antes, pero el AT tiene la última transacción comprometida firmada por la otra parte: ¿qué se puede hacer para evitar que el AT transmita la promesa anterior y el AT solo la transacción de compromiso más reciente?
La solución a este problema con el canal de rayos se llama "LN-Penalty". Ahora, digamos que Alice y Bob tienen 5 BTC cada uno en un canal; Ahora Alice quiere pagarle a Bob 1 BTC, así que firma la transacción prometida y se la envía a Bob:
Ingresa #0 y 10 BTC:
Salida multifirma Alie-Bob 2 de 2 (es decir, contrato de canal)
Salida #0 , 4 BTC:
Alicia de firma única
Salida #1 , 6 BTC:
o
Clave pública efímera federada Alice-Bob #1 firma única
o
Bloqueo de tiempo T 1, Bob con firma única
Bob también firma un compromiso (que corresponde a la transacción anterior) y se lo envía a Alice:
Ingresa #0 y 10 BTC:
Salida multifirma Alie-Bob 2 de 2 (es decir, contrato de canal)
Salida #0 , 6 BTC:
Bob con firma única
Salida #1 , 4 BTC:
o
Clave pública efímera federada Bob-Alice #1 de firma única
o
Bloqueo de tiempo T 1, Alice con firma única
El truco aquí radica en esta "clave pública temporal conjunta", que se genera utilizando una de sus propias claves públicas y una clave pública proporcionada por la otra parte, por ejemplo, la clave pública temporal conjunta Alice-Bob, que es obtenida por Alice utilizando una de sus propias claves públicas y una clave pública proporcionada por Bob, multiplicando cada una por un valor hash. Cuando se genera una clave pública de este tipo, nadie conoce su clave privada. Sin embargo, si Bob le dice a Alice la clave privada de la clave pública que proporcionó, Alice puede calcular la clave privada de la clave pública temporal federada. - Esta es la clave del hecho de que Lightning Channel puede "deshacer" el estado anterior.
La próxima vez que las dos partes quieran actualizar el estado del canal (iniciar un pago), las dos partes intercambiarán la clave privada de la clave pública temporal que se dieron en la ronda anterior. De esta manera, los participantes ya no se atreven a transmitir la última transacción prometida que recibieron: la salida de esta transacción prometida que asigna valor a su propia parte tiene dos rutas, y la clave privada de la ruta de clave pública temporal ya es conocida por la otra parte; Por lo tanto, una vez que se transmite la transacción de compromiso anterior, la otra parte puede usar inmediatamente esta clave privada temporal conjunta para tomar todos los fondos en esta salida. - Esto es lo que significa "LN-Penalty".
En concreto, el orden de interacción es el siguiente: la parte que inicia el pago solicita primero una nueva clave pública temporal a la otra parte, y luego construye una nueva transacción de compromiso y se la entrega a la otra parte; La parte que obtuvo la transacción prometida reveló a la otra parte la clave privada de la clave pública temporal que dio en la ronda anterior. Esta secuencia de interacciones garantiza que los participantes siempre obtengan una nueva transacción de compromiso antes de invalidar la transacción de compromiso que recibieron en la ronda anterior y, por lo tanto, no es de confianza.
En resumen, los diseños clave del canal de relámpagos son:
Ambas partes siempre utilizan las transacciones de compromiso para expresar el estado dentro del contrato, y el cambio en el monto para expresar el pago;
Las transacciones de compromiso siempre cuestan la misma entrada (entrada que requiere que ambas partes proporcionen firmas al mismo tiempo), por lo que todas las transacciones de compromiso compiten entre sí y solo una puede ser confirmada por la cadena de bloques.
Los dos participantes no firman la misma transacción de compromiso (aunque estén emparejados); Y lo que firman es siempre una transacción que les es más favorable, es decir, la transacción prometida que reciben los participantes es siempre desfavorable para ellos mismos;
La desventaja de esto es que la salida que se asigna valor a sí misma tiene dos rutas de desbloqueo: una ruta se puede desbloquear con su propia firma, pero necesita esperar un tiempo; La otra ruta utiliza la clave pública de la otra parte, que solo está protegida si una de sus claves privadas temporales no está expuesta.
En cada pago, ambas partes intercambian la clave privada temporal utilizada por la otra parte en la ronda anterior con una nueva transacción de compromiso, de modo que la parte que entregó la clave privada temporal ya no se atreve a transmitir la transacción de compromiso anterior, por lo que "cancela" la transacción de compromiso anterior y actualiza el estado del contrato; (En realidad, estas transacciones prometidas son todas transacciones válidas y se pueden transmitir a la cadena de bloques, pero los participantes se ven obligados a ser castigados y no se atreven a transmitir más)
Cualquiera de las partes puede rescindir el contrato en cualquier momento con un compromiso firmado por la otra parte; Sin embargo, si ambas partes están dispuestas a cooperar, pueden firmar un nuevo acuerdo para que ambas partes puedan recuperar su dinero de inmediato.
Finalmente, debido a que HTLC también se puede colocar en una transacción comprometida, el canal Lightning también puede reenviar pagos. Suponiendo que Alice puede encontrar un camino que consiste en canales de rayos que se conectan antes y después para llegar a Daniel, entonces se pueden lograr pagos de múltiples saltos sin confianza sin abrir un canal con Daniel. Esta es la Lightning Network:
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice < -- Preimagen -- Bob < -- Preimagen -- Carol < -- Preimagen -- Daniel
Cuando Alice encuentra ese camino y quiere pagarle a Daniel, le pide a Daniel un hash para construir un HTLC para Bob, y le pide a Bob que reenvíe un mensaje a Carol y proporcione el mismo HTLC; El mensaje le pide a Carol que reenvíe el mensaje a Daniel y proporcione el mismo HTLC. Cuando la noticia llega a Daniel, le revela la preimagen a Carol, que le da el valor de HTLC y actualiza el estado del contrato. Carol hizo lo mismo, Bob le pagó y actualizó el estado del canal; Finalmente, Bob le revela la preimagen a Alice y actualiza el estado. Debido a la naturaleza de HTLC, esta cadena de pagos tiene éxito o fracasa en conjunto y, como tal, no es confiable.
La Lightning Network se compone de un canal tras otro, cada uno de los cuales es independiente entre sí. Esto significa que Alice solo necesita saber lo que está sucediendo en su canal con Bob, independientemente de cuántas interacciones hayan tenido lugar en los canales de otras personas, qué moneda usan esas interacciones o incluso si realmente están usando el canal.
La escalabilidad de Lightning Network no solo se refleja en el hecho de que la velocidad de pago dentro de un Lightning Channel solo está limitada por la inversión de recursos de hardware por ambas partes, sino también en que debido al almacenamiento descentralizado del estado, un solo nodo puede aprovechar el máximo apalancamiento con el menor costo.
(3) Tenga cuidado con los contratos de diario
El Cautionary Journaling Contract (DLC) utiliza una técnica criptográfica llamada "firma de adaptador" que permite a Bitcoin Script programar contratos financieros que dependen de eventos externos.
Las firmas de adaptador permiten que una firma se convierta en una firma válida solo después de agregar una clave privada. Tomemos el ejemplo de una firma Schnorr, donde la forma estándar de una firma Schnorr es (R, s), donde:
R = r.G
El valor nonce r utilizado para la firma se multiplica por el punto de generación de la curva elíptica, que también se puede decir que es la clave pública de r
s = r + Hash(R || m || P) * p
p es la clave privada de firma y P es la clave pública
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
Digamos que doy un par de datos (R, s') donde:
R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p
Obviamente, esta no es una firma Schnorr válida, y no pasa la fórmula de validación, pero puedo demostrarle al verificador que puede ser una firma válida simplemente conociendo la clave privada de R 2, r 2:
s'. G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Hash(R || m || P) * P
Las firmas de adaptador hacen que la validez de una firma dependa de un dato secreto y sea verificable. Pero, ¿qué tiene que ver esto con los contratos financieros?
Supongamos que Alice y Bob quieren apostar por el resultado de un juego de pelota. Alice y Bob apostaron a que el Duende Verde y Alina ganarían, respectivamente, con una apuesta de 1 BTC. Además, Carol, un sitio web de reseñas de fútbol, prometió usar un nonce R_c para publicar una _c_i firmada de los resultados cuando se anunciaran los resultados del juego.
Como se puede ver, hay tres resultados posibles (por lo que hay 3 posibilidades para la firma de Carol):
Duende Verde gana, Alice gana 1 BTC
Alina gana y Bob gana 1 BTC
Empate, los fondos de los dos regresan de la misma manera
Para ello, los dos crean un acuerdo de compromiso para cada resultado. Por ejemplo, la transacción de compromiso que crearon para el primer resultado tendría el siguiente aspecto:
Ingresa #0 , 2 BTC:
Salida multifirma 2 de 2 de Alie-Bob (es decir, contrato de apuesta)
Salida #0 , 2 BTC:
Alicia de firma única
Sin embargo, en lugar de (R, s), la firma que Alice y Bob crearon para esta transacción es una firma de adaptador (R, s'); En otras palabras, las firmas dadas por ambas partes no pueden utilizarse directamente para desbloquear el contrato, sino que deben revelar un valor secreto. ¡Este valor secreto es la preimagen de s_c_ 1.G, que es la firma de Carol! Dado que se ha determinado el valor nonce de la firma de Carol (R_c), se puede construir s_c_ 1.G (s_c_ 1.G = R_c + Hash(R_c ||). 'El Duende Verde gana' || PK_c) * PK_c)。
Cuando se revelan los resultados, asumiendo que el Duende Verde gana, Carol emitirá una firma (R_c, s_c_ 1), para que Alice o Bob puedan completar la firma del adaptador del oponente y agregar su propia firma para hacer que la transacción anterior sea una transacción válida, y transmitirla a la red para desencadenar el efecto de liquidación. Pero si el Duende Verde no gana, Carol no publicará s_c_ 1, y el acuerdo de compromiso no será un trato válido.
Y así sucesivamente, al igual que los otros dos oficios. De esta manera, Alice y Bob hacen que la ejecución del contrato dependa de eventos externos (para ser precisos, de la transmisión de eventos externos por parte de la máquina de aserción, en forma de firma) sin tener que confiar en la contraparte. Los contratos financieros grandes y pequeños, como los futuros y las opciones, pueden implementarse de esta manera.
En comparación con otras formas de implementación, la característica más importante del contrato de registro cauteloso es su privacidad: (1) Alice y Bob no necesitan decirle a Carol que están utilizando los datos de Carol, lo que no afecta en absoluto a la ejecución del contrato; (2) Los observadores on-chain (incluida Carol) no podrán determinar qué sitio web están utilizando a través de la ejecución del contrato de Alice y Bob, o incluso que su contrato es un contrato de apuestas (no un canal relámpago).
IV. Introducción a la aplicación de restricciones
(a) OP_CTV y control de la congestión
Los desarrolladores de la comunidad Bitcoin han hecho una serie de propuestas que se pueden clasificar como cláusulas restrictivas. Por el momento, una de las propuestas más conocidas es OP_CHECKTEMPLATEVERIFY (OP_CTV), que es popular entre la comunidad Bitcoin por su simplicidad pero flexibilidad con su concepto simple. La idea de OP_CTV es confirmar un hash en el script para restringir que los fondos solo se puedan gastar en las transacciones representadas por este hash; Este hash promete la salida de la transacción y la mayoría de los campos, pero no la entrada de la transacción, solo el número de entradas.
"Control de la congestión" es un buen ejemplo de cómo se puede demostrar la OP_CTV. Su caso de uso básico es ayudar a un gran número de usuarios a salir de un exchange (un entorno que requiere confianza) a un pool; Dado que este grupo utiliza OP_CTV para planificar cómo se gastará en el futuro, garantiza que los usuarios puedan salir del grupo sin confianza, sin la ayuda de nadie; Y debido a que este grupo solo se comporta como un UTXO, evita pagar muchas tarifas cuando la demanda de transacciones en cadena es alta (de n salidas a 1 salida; también se redujo de n transacciones a 1 transacción). Los usuarios del grupo pueden esperar una oportunidad para salir del grupo.
Supongamos que Alice, Bob y Carol quieren retirar 5 BTC, 3 BTC y 2 BTC del exchange, respectivamente. Luego, el intercambio puede obtener una salida de 10 BTC con 3 OP_CTV ramas. Supongamos que Alicia quiere retirar dinero, puede usar la sucursal 1; La transacción representada por el valor hash utilizado por el OP_CTV de la rama formará dos salidas, una de las cuales es asignar 5 BTC a Alice; La otra salida, a su vez, es un grupo, que también utiliza OP_CTV para comprometerse con una transacción, lo que permite a Bob retirar solo 3 BTC y enviar los 2 BTC restantes a Carol.
Es lo mismo si Bob o Carol quieren retirar dinero. Al retirar dinero, solo podrán utilizar transacciones que puedan pasar el cheque OP_CTV correspondiente, es decir, solo podrán pagarse a sí mismos la cantidad correspondiente y no podrán retirar dinero arbitrariamente; Los fondos restantes irán a un grupo con un bloqueo OP_CTV, lo que garantiza que los usuarios restantes puedan ser colocados fuera del grupo sin confianza, independientemente del orden en que se retiren.
En abstracto, el papel de OP_CTV aquí es planificar el camino hasta el final de la vida del contrato para el contrato, de modo que el contrato de grupo aquí pueda mantener el atributo de salida sin confianza sin importar qué camino tome o qué estado vaya.
También hay un uso muy interesante de este OP_CTV: "canal de pago unidireccional que está oculto pero no revelado". Supongamos que Alice forma un grupo de fondos de este tipo y garantiza que los fondos se pueden retirar sin confianza en una salida con el siguiente script:
o Alice y Bob lo pasan juntos
o, después de un tiempo, Alicia puede gastarlo por su cuenta
Si Alice no se lo hubiera revelado a Bob, Bob no habría sabido que existía tal salida; Una vez que Alice se lo revela a Bob, Bob puede usar la salida como un canal de pago unidireccional y sensible al tiempo que Alice puede usar para pagarle a Bob de inmediato sin tener que esperar la confirmación de la cadena de bloques. Bob simplemente le pide a Alice que ponga su transacción de compromiso en la cadena antes de que Alice pueda gastarla por su cuenta.
(b) OP_Vault y seguro
El OP_VAULT es una propuesta de cláusula restrictiva diseñada específicamente para construir "bóvedas".
El contrato de Vault está diseñado para ser una forma más segura y avanzada de autocustodia. Aunque el contrato de firma múltiple actual puede evitar un único punto de error para una sola clave privada, si un atacante obtiene un número umbral de claves privadas, el propietario de la billetera está indefenso. Vault quiere imponer un único límite de gasto a tus fondos; Al mismo tiempo, al retirar dinero por la vía regular, la operación de retiro impondrá un período de espera; Y durante el período de espera, la operación de retiro puede ser interrumpida por la operación de recuperación de emergencia de la billetera. Incluso si se incumple dicho contrato, el propietario de la billetera puede iniciar una contraoperación (utilizando la rama de recuperación de emergencia).
Teóricamente, OP_CTV también puede programar un contrato de este tipo, pero hay muchos inconvenientes, uno de los cuales es la comisión: mientras se compromete con la transacción, también promete la tarifa que pagará la transacción. Dado el propósito de este contrato, el intervalo de tiempo entre la creación del contrato y el retiro de dinero debe ser muy largo, por lo que es casi imposible predecir la comisión adecuada. Aunque OP_CTV no limita los insumos, por lo que la tarifa se puede aumentar aumentando el insumo, el insumo proporcionado se convertirá en la comisión, por lo que no es realista; Otra forma es el CPFP, que consiste en proporcionar una comisión sobre nuevas transacciones gastando los fondos retirados. Además, el uso de OP_CTV significa que un contrato de Vault de este tipo no se puede retirar de forma masiva (y, desde luego, no se puede restaurar de forma masiva).
La propuesta de OP_VAULT intenta abordar estas cuestiones proponiendo nuevos códigos de operación (OP_VAULT y OP_UNVAULT). OP_UNVAULT está diseñado para la resistencia por lotes, por lo que no lo mencionaremos por ahora. OP_VAULT se comporta así: cuando lo colocamos en una rama del árbol de scripts, se puede usar para confirmar un código de operación utilizable (por ejemplo, OP_CTV) sin parámetros específicos; Al gastar esta rama, las transacciones se pueden pasar en parámetros específicos, pero no en otras ramas. Como resultado, no tiene que establecer una tarifa preestablecida, y se puede establecer cuando se gasta la sucursal; Suponiendo que la rama también tiene un bloqueo de tiempo, aplicará un bloqueo de tiempo; Finalmente, dado que solo puede cambiar la rama en la que se encuentra, y no se cambiará ninguna otra rama del nuevo árbol de scripts (incluida la rama de recuperación de emergencia), se nos permite interrumpir dichos retiros.
Además, vale la pena mencionar dos puntos: (1) el código de operación OP_VAULT se comporta de manera similar a otra propuesta de restricción: OP_TLUV; Jeremy Rubin señala acertadamente que esto ha dado lugar al concepto de "computación" hasta cierto punto: OP_TLUV/OP_VAULT primero promete un código de operación para permitir al consumidor actualizar toda la hoja del árbol de script pasando parámetros al código de operación con una nueva transacción; Ya no se trata de "validar los datos entrantes en función de ciertos criterios", sino de "generar nuevos datos significativos en función de los datos entrantes", aunque el cómputo que puede permitir es limitado.
(2) La propuesta completa de OP_VAULT también hace uso de algunas de las propuestas sobre la política de mempool (por ejemplo, transacciones v3) para lograr mejores resultados. Esto nos recuerda que el significado de "programación" puede ser más amplio de lo que pensamos. (Un ejemplo similar es Open Transaction en la red Nervos). ）
V. Entendiendo CKB
En las dos secciones anteriores, describimos cómo podemos programar aplicaciones interesantes en una estructura más restringida (Bitcoin UTXO); También se presentaron propuestas para tratar de añadir introspección a dicha estructura.
Si bien los UTXO tienen la capacidad de programar estas aplicaciones, es fácil para los lectores detectar sus deficiencias o áreas que se pueden optimizar, como:
En LN-Punishment, los participantes del canal deben guardar cada transacción cometida en el pasado y el valor secreto de penalización correspondiente para hacer frente al fraude del oponente, que constituye una carga de almacenamiento. Si existe un mecanismo que garantiza que solo la transacción de compromiso más reciente surtirá efecto, y la transacción de compromiso anterior no lo hará, puede eliminar esta carga y también puede eliminar el problema de que los nodos sean penalizados accidentalmente por poner por error una transacción de compromiso anterior en la cadena.
En el DLC, se asume que hay muchos resultados posibles del evento, y hay muchas firmas que ambas partes tienen que generar y entregarse mutuamente por adelantado, lo que también es una gran carga; Además, los ingresos del contrato DLC están directamente vinculados a la clave pública, por lo que su posición no es fácil de transferir, ¿hay alguna forma de transferir la posición del contrato?
De hecho, la comunidad Bitcoin ha encontrado respuestas a estas preguntas, básicamente relacionadas con una propuesta de Sighash (BIP-118 AnyPrevOut).
Sin embargo, si estuviéramos programando en CKB, BIP-118 estaría disponible ahora (tales etiquetas Sighash podrían simularse con la capacidad de verificar firmas de manera introspectiva y deliberada).
Al aprender a programar Bitcoin, no solo sabemos cómo se pueden programar en el formato "Transaction Output" (qué se puede programar en CKB), sino también cómo mejorar estas aplicaciones (y cómo podemos usar las capacidades de CKB para mejorarlas si las programamos en CKB). Para los desarrolladores de CKB, la programación basada en Bitcoin Script se puede utilizar como material de aprendizaje, o incluso como atajo.
A continuación, analicemos la programabilidad de cada módulo de programación CKB uno por uno. No consideremos la introspección por ahora.
Como se mencionó anteriormente, los UTXO no se pueden programar para calcular arbitrariamente. Lock, por otro lado, significa que Lock puede programar todo (antes de la implementación de restricción) basado en UTXO, incluidos, entre otros, Lightning Channel y DLC mencionados anteriormente.
Además, esta capacidad de verificar el cálculo arbitrario también hace que Lock sea más flexible que UTXO en términos de métodos de autenticación. Por ejemplo, podemos implementar un canal lightning en el CKB donde una parte firma ECDSA y la otra parte usa RSA.
De hecho, esta es una de las primeras áreas que la gente comenzó a explorar en CKB: el uso de esta capacidad de autenticación flexible en la autocustodia del usuario para permitir lo que se conoce como "abstracción de cuentas": la autorización de la validez de la transacción y la restauración del control son muy flexibles y casi ilimitadas. En principio, se trata de una combinación de "múltiples ramas de gasto" y "métodos de autenticación arbitrarios". Ejemplos de implementaciones son: joyid wallet, UniPass.
Además, Lock puede implementar propuestas de eltoo, habilitando un canal lightning que solo necesita mantener la última transacción comprometida (de hecho, eltoo puede simplificar todos los contratos peer-to-peer).
(2) Tipo programable calculado arbitrariamente
Como se mencionó anteriormente, uno de los grandes usos de Type es programar UDT. Combinado con Lock, esto significa que podemos implementar canales de iluminación basados en UDT (y otros tipos de contratos).
De hecho, la división entre Lock y Type puede verse como una mejora de seguridad: Lock se centra en la implementación de métodos de custodia o acuerdos contractuales, mientras que Type se centra en la definición de UDT.
Además, la capacidad de iniciar comprobaciones basadas en definiciones de UDT también permite a UDT participar en los contratos de forma similar a CKB (UDT es ciudadano de primera clase).
Por ejemplo, el autor propuso una vez un protocolo para implementar préstamos respaldados por NFT sin confianza en Bitcoin. La clave de un protocolo de este tipo es una transacción comprometida en la que el valor de la entrada es menor que el valor de la salida (por lo que aún no es una transacción válida), pero una vez que se puede proporcionar suficiente información para la transacción, es una transacción válida: una vez que el prestamista puede pagar, el prestamista no puede tomar el NFT apostado para sí mismo. Sin embargo, la falta de confianza de esta transacción de compromiso se basa en que la transacción verifique la cantidad de entrada y salida, por lo que el prestamista solo puede usar Bitcoin para pagar el préstamo: incluso si tanto el prestamista como el prestamista están dispuestos a aceptar otra moneda (como USDT emitida bajo el protocolo RGB), la transacción de compromiso de Bitcoin no garantiza que el prestamista recupere su NFT siempre que el prestamista devuelva la cantidad total de USDT, ¡porque la transacción de Bitcoin no tiene idea del estado de USDT! (Revisión: En otras palabras, no es posible construir una transacción comprometida condicionada al reembolso de USDT). ）
Si somos capaces de iniciar una comprobación basada en la definición de UDT, podremos conseguir que el prestamista firme otra transacción comprometida que le permitirá utilizar USDT para pagar el préstamo. La transacción verificará la cantidad de USDT ingresada y la cantidad de USDT saliente, lo que brindará a los usuarios un pago sin confianza con USDT.
Enmienda: Suponiendo que el NFT utilizado como garantía y el token utilizado para el reembolso se emiten utilizando el mismo protocolo (como RGB), entonces el problema aquí se puede resolver y podemos construir una transacción de compromiso de acuerdo con el protocolo RGB, de modo que la transición de estado y el reembolso del NFT puedan ocurrir simultáneamente (dos transiciones de estado están vinculadas con transacciones dentro del protocolo RGB). Sin embargo, debido a que las transacciones RGB también dependen de las transacciones de Bitcoin, la construcción de transacciones de compromiso aquí será algo difícil. Con todo, aunque el problema se puede resolver, no se puede hacer Token es un ciudadano de primera clase.
A continuación, consideremos la introspección.
(3) La cerradura lee otras cerraduras
Esto significa toda la gama de posibilidades de programación en los UTXO de Bitcoin después de que se implemente la restricción propuesta. Esto incluye los contratos de Vault mencionados anteriormente, así como las aplicaciones basadas en OP_CTV (por ejemplo, control de congestión).
XueJie mencionó una vez un ejemplo muy interesante: puede implementar una celda de cuenta de cobro en CKB, cuando se usa este tipo de celda como entrada de la transacción, si la celda de salida (la celda que usa el mismo bloqueo) tiene más capacidad, entonces la entrada no necesita proporcionar una firma y no afecta la validez de la transacción. De hecho, este tipo de célula no sería posible sin la capacidad de introspección. Esta celda de cuenta de cobro es ideal como método institucional para recibir dinero porque reúne fondos y tiene la desventaja de no tener un buen sentido de privacidad.
(4) Bloquear lee otros tipos (y datos)
Una aplicación interesante de esta capacidad son los tokens de apuesta. Lock decidirá si puede usar su propia capacidad en función de la cantidad de tokens en las otras entradas y dónde se puede gastar (requiere la capacidad de bloquear por introspección).
(5) El tipo lee otras cerraduras
No estoy seguro, pero se puede suponer que es útil. Por ejemplo, puede comprobar en Tipo que los bloqueos de las entradas y salidas de una transacción permanezcan sin cambios.
(6) El tipo Scirpt lee otros tipos (y datos)
¿Cromos? Recoge n tokens a cambio de un token más grande :)
VI. Conclusión
En comparación con los sistemas de contratos inteligentes anteriores que se pueden programar con computación arbitraria, como Ethereum, Nervos Network tiene una estructura diferente; Como resultado, a menudo es difícil entender la Red Nervos basándose en el conocimiento de los sistemas de contratos inteligentes del pasado. En este trabajo se propone un método para entender la programabilidad de CKB Cell, a partir de la programación de aplicación de una estructura más restringida que CKB Cell, BTC UTXO. Y, utilizando el concepto de "introspección" para comprender las capacidades de "acceso entre contratos" de las células, podemos dividir las situaciones en las que se utilizan las capacidades introspectivas y determinar sus usos específicos.
Recensión:
Independientemente de las capacidades de acceso cruzado de la celda (es decir, las capacidades de introspección), las cerraduras pueden considerarse como Bitcoin con capacidades de estado y programación que han llegado al extremo, de modo que todas las aplicaciones basadas en Bitcoin se pueden programar solo sobre esta base;
Independientemente de la capacidad de acceso cruzado (es decir, la capacidad de introspección) de la célula, la distinción entre cerraduras y tipos puede considerarse como una mejora de seguridad: separa la definición de activos y el método de custodia de la UDT; Además, el tipo s (y los datos) del estado exponible logran el efecto de UDT es ciudadano de primera clase.
Los dos puntos anteriores significan algo con el mismo paradigma que "BTC + RGB" pero con más capacidades de programación;
Teniendo en cuenta la capacidad introspectiva de Cell, Cell puede obtener capacidades de programación más sólidas que BTC UTXO posteriores a los convenios e implementar algo que es difícil de lograr con BTC + RGB (porque BTC no puede leer el estado de RGB)
No hay muchos ejemplos específicos de estos usos, pero esto se debe a la falta de comprensión del autor sobre la ecología de la CKB. Con el tiempo, se cree que se invertirá más y más imaginación en él, y se armarán aplicaciones que hoy son inimaginables.
Agradecimientos
Gracias a Retric, Jan Xie y Xue Jie por sus comentarios durante la redacción del artículo. Por supuesto, soy responsable de todos los errores en el texto.
Referencias
Cuentas, listas de acceso estricto y UTXO
Restricciones en Bitcoin: Taxonomía para revisión
Modelo de célula
Nervos CKB en pocas palabras
La programabilidad de Bitcoin
Abstracción a cuenta (2022)
¿Qué es un árbol sintáctico abstracto de Bitcoin Merkelizado?
BIP 345: Propuesta de _VAULT
Introducción a los códigos de operación de restricción TLUV
Los componentes que construyen el contrato se actualizan con Bitcoin
Explicación de Eltoo
Un contrato de préstamo garantizado de NFT basado en transacciones comprometidas · btc-estudio/OP_QUESTION · Discusión #7
Enlace al artículo original
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Comprender la programabilidad de CKB a partir de la programación de aplicaciones de Bitcoin
Autor original: Ajian
Resumen
Comprender la programabilidad de un sistema requiere que identifiquemos las características estructurales del sistema. La exploración de la programación de aplicaciones basada en Bitcoin Script nos ayuda a comprender la estructura básica de CKB Cell y su paradigma de programación. No solo eso, sino que desglosa los componentes de programación del CKB en las piezas correctas y nos ayuda a comprender las ganancias de programabilidad que aporta cada parte.
I. Introducción
La "programabilidad" es una dimensión que las personas suelen tomar al comparar sistemas blockchain. Sin embargo, a menudo hay desacuerdo sobre cómo se describe la programabilidad. Una expresión común es "XX blockchain soporta lenguajes de programación Turing-completos", o "XX blockchain soporta programación de propósito general", que pretende indicar que la "XX blockchain" aquí tiene una fuerte programabilidad. Hay algo de verdad en la implicación de estas afirmaciones: los sistemas que soportan la programación completa de Turing son generalmente más fáciles de programar que los que no lo hacen. Sin embargo, hay muchos aspectos en las características estructurales de un sistema de contratos inteligentes, y esta afirmación toca solo uno de ellos, por lo que no es suficiente para ser entendido con suficiente profundidad en virtud del hecho de que los desarrolladores no se guían por él, y no se puede confiar en los usuarios comunes para distinguir el fraude.
Las características estructurales de un sistema de contratos inteligentes incluyen:
Por lo tanto, además de la "computación arbitraria programable", hay al menos cuatro características que afectan la programabilidad de un sistema de contrato inteligente. Incluso se puede decir que estas otras características son más importantes, porque determinan a un nivel más profundo lo que es fácil de lograr y lo que es difícil de lograr; ¿Qué es una implementación más económica y qué es una implementación menos eficiente?
Por ejemplo, Ethereum se cita a menudo como un ejemplo de buena programabilidad, pero la forma básica de expresión de estado en Ethereum es una cuenta, lo que dificulta la programación de contratos peer-to-peer (por ejemplo, pasarelas de pago, contratos de apuestas uno a uno), lo que no es absolutamente imposible, solo ingrato. No es raro que el ecosistema Ethereum intente implementar un canal de pago/canal de estado, y ha habido muchas discusiones teóricas, pero estos proyectos ya no parecen estar activos, y esto obviamente no se puede culpar a la falta de esfuerzo por parte de los desarrolladores. No es casualidad que los proyectos activos en Ethereum hoy en día estén tomando la forma de "pools" en lugar de "contratos peer-to-peer". Del mismo modo, la gente puede estar contenta con la programabilidad de Ethereum, pero el modelo de cuenta es inherentemente deficiente para lograr la "abstracción de la cuenta" (que también puede entenderse como una generalización del concepto de billetera).
De la misma manera, explorar la programabilidad de CKB también requiere que entendamos las características estructurales del sistema de contratos inteligentes de CKB en estos aspectos. Lo que ya sabemos es que CKB permite programar cálculos arbitrarios, permite registrar estados adicionales dentro de un contrato y permite que un contrato acceda al estado de otro contrato cuando se ejecuta. Sin embargo, la forma del contrato es el resultado de una transacción (llamada "célula"), lo que lo hace fundamentalmente diferente de Ethereum. Por lo tanto, una comprensión del sistema de contratos inteligentes de Ethereum y las instancias de contratos dentro de él no nos ayuda a comprender cómo CKB implementa estas características estructurales, ni nos ayuda a comprender la programabilidad de CKB.
Afortunadamente, los contratos inteligentes en Bitcoin parecen proporcionar la mejor base para comprender la programabilidad de CKB. Esto no solo se debe a que la forma básica de la representación estatal de Bitcoin es también la salida de transacciones (llamadas "UTXO"), sino también porque, con la ayuda de un concepto propuesto por la comunidad de Bitcoin llamado "covenants", podemos entender por qué CKB tiene estas características estructurales, y desglosar adecuadamente el efecto final en varias partes, identificando las ganancias de programabilidad que aporta cada una de ellas.
II. CKB v.s. BTC: ¿Qué más?
(1) Estructura básica
Como forma básica de la representación del estado de Bitcoin, el UTXO ("Salida de transacción no gastada") de Bitcoin tiene dos campos:
En comparación con los sistemas de contratos inteligentes que vinieron después, Bitcoin Script es bastante limitado:
Este tipo de scripting, aunque limitado, no carece de la capacidad de programar aplicaciones increíbles, y es la base de nuestra exploración de la programabilidad de CKB. Habrá una sección más adelante que presentará dos ejemplos de programación de Bitcoin Script.
Por el contrario, la unidad de estado de la CKB se denomina "celda" y tiene cuatro campos:
Además, Lock y Type se pueden programar para cálculos arbitrarios. Puede programar cualquier algoritmo de verificación de firmas, puede programar cualquier algoritmo hash para la comprobación de preimágenes, etc.
Es fácil para los lectores ver cómo la programabilidad de Cell mejora con respecto a los UTXO:
Combinado con la estructura de "salida de transacción" de la propia célula, los beneficios de estos dos puntos en sí mismos son muy, muy significativos, pero solo a partir de la descripción anterior, no sabemos cómo la célula logra que "un contrato acceda al estado de otro contrato en tiempo de ejecución". Para ello, tenemos que recurrir a un concepto que se ha discutido durante mucho tiempo en la comunidad Bitcoin: los "covenants".
(2) Limitaciones e introspección
El propósito original de una cláusula de restricción es limitar dónde se puede gastar una suma de dinero. En el Bitcoin actual (donde no se han propuesto restricciones), una sola cantidad de dinero, una vez desbloqueada, se puede gastar en cualquier lugar (se puede pagar a una clave pública de script arbitraria). Pero la idea de la cláusula de restricción es que se puede gastar de una manera que lo limite a ciertos lugares, por ejemplo, una determinada UTXO solo se gastará en una determinada transacción, de modo que incluso si alguien puede proporcionar una firma para la UTXO, dónde se puede gastar ya ha sido determinado por esa transacción. Esto puede parecer un poco extraño, pero puede dar lugar a algunas aplicaciones interesantes, que se tratarán en una sección más adelante. Es importante destacar que es clave para nuestra mayor comprensión de la programabilidad de CKB.
Rusty Russell señala acertadamente que una restricción puede entenderse como una capacidad de "introspección" para operar, es decir, cuando una transacción B gasta un UTXO A, un operador de script puede leer parte (o toda) de la transacción B y luego verificar que coincidan con los parámetros solicitados previamente por el script. Por ejemplo, si la clave pública del script para la primera salida de la transacción A coincide con lo requerido por la clave pública del script de UTXO A (esto es lo que significaba originalmente la restricción).
El lector astuto se dará cuenta de que con una introspección completa, la entrada de una transacción puede leer el estado de otra entrada de la misma transacción, lo que permite la capacidad de un contrato para acceder al estado de otro contrato en tiempo de ejecución. De hecho, así es exactamente como se diseñó CKB Cell.
En base a esto, podemos dividir esta completa capacidad introspectiva en cuatro escenarios:
Esto nos permite analizar el papel de las capacidades introspectivas de cada parte en diferentes casos de uso bajo ciertos supuestos (la división de funciones entre Lock y Type), es decir, la ganancia de programabilidad que nos aporta cada parte.
En las siguientes dos secciones, veremos la programación actual (y aún no propuesta) de Bitcoin Script, y la probable funcionalidad que se espera que logre la restricción propuesta, para dar una comprensión concreta de cómo se puede programar y hacer mejor CKB Cell.
III. Programación de scripts de Bitcoin
En esta sección, usaremos "Lightning Channel/Lightning Network" y "Caution Journal Contract (DLC)" como ejemplos de programación de aplicaciones basadas en Bitcoin Script. Antes de entrar en eso, analicemos dos cosas.
(1) OP_IF y "Acuerdos de compromiso"
El primer concepto es el código de operación de control de flujo en Bitcoin Script, como: OP_IF, OP_ELSE. Estos códigos de operación no son diferentes de IF en la programación de computadoras, y su propósito es ejecutar diferentes instrucciones basadas en diferentes entradas. En el contexto de Bitcoin Script, esto significa que podemos establecer múltiples rutas de desbloqueo para los fondos; Combinado con la función de bloqueo de tiempo, esto significa que podemos asignar prioridad a las acciones.
Tomemos como ejemplo el famoso "Contrato de bloqueo de tiempo de hash (HTLC)", que se traduce en lengua vernácula:
Este "o ... o ..." El efecto se logra a través del código de operación de control de procesos.
La ventaja más destacada de > HTLC es que puede agrupar múltiples operaciones y atomizarlas. Por ejemplo, si Alice quiere intercambiar BTC por CKB con Bob, entonces Bob puede primero dar un valor hash y crear un HTLC en la red Nervos. A continuación, Alice crea un HTLC en Bitcoin que utiliza el mismo hash. Alternativamente, Bob toma el BTC pagado por Alice en Bitcoin, al mismo tiempo que revela la preimagen, lo que permite a Alice retirar CKB en la red Nervos. De cualquier manera, Bob no revela la imagen original, ambos contratos expiran y tanto Alice como Bob pueden recuperar el dinero que invirtieron.
Después de la activación de la bifurcación suave Taproot, esta función de ruta de desbloqueo múltiple se mejora aún más con la introducción de MAST (Merkle Abstract Syntax Tree): podemos convertir una ruta de desbloqueo en una hoja en el árbol de Merkle, cada hoja es independiente, por lo que ya no es necesario usar un código de operación de control de flujo de este tipo; Además, debido a que una ruta se revela sin exponer las demás, podemos agregar un mayor número de rutas de desbloqueo a una salida sin tener que preocuparnos por la economía.
El segundo concepto es el "trading de compromiso". La idea de una transacción comprometida es que, en algunos casos, una transacción válida de Bitcoin, incluso si no está confirmada por la cadena de bloques, es igual de real y vinculante.
Por ejemplo, Alice y Bob comparten un UTXO que requiere que ambos estén firmados para gastar. En este punto, Alice construye una transacción para gastarlo, transfiriendo el 60% de su valor a Bob y el resto a sí misma; Alice proporciona su propia firma para la transacción, que luego se envía a Bob. Bueno, para Bob, no tiene que ser transmitido a la red Bitcoin, y no tiene que ser confirmado por la cadena de bloques, y el efecto de pago de esta transacción también es real y creíble. Debido a que Alice no puede gastar el UTXO por su cuenta (y, por lo tanto, no puede gastarlo repetidamente), y debido a que la firma proporcionada por Alice es válida, Bob siempre puede agregar su firma y transmitir la transacción para honrar el pago. En otras palabras, Alice proporcionó a Bob un "compromiso creíble" a través de esta transacción válida (fuera de la cadena).
Las transacciones comprometidas son un concepto central de la programación de aplicaciones de Bitcoin. Como se mencionó anteriormente, el contrato de Bitcoin se basa en la verificación, no tiene estado y no permite el acceso cruzado; Sin embargo, si el contrato no lleva estados, ¿dónde se almacenan esos estados y cómo puede avanzar el contrato de manera segura (cambiar de estado)? Las transacciones de compromiso dan una respuesta sencilla: el estado del contrato se puede expresar en forma de transacciones, de modo que los participantes del contrato pueden salvar el estado por sí mismos sin tener que mostrarlo en la cadena de bloques; El problema de cambiar el estado del contrato también puede transformarse en el problema de cómo actualizar de forma segura la transacción comprometida; Además, si nos preocupan los peligros de celebrar un contrato (por ejemplo, celebrar un contrato que requiere que ambas partes firmen para gastar, y existe el riesgo de que la otra parte no responda y se quede atascada), entonces simplemente generar una transacción de compromiso que cueste el contrato por adelantado y obtener una firma puede mitigar el riesgo y eliminar la confianza en otros participantes.
(2) Lightning channel y lightning network
Un canal relámpago es un contrato uno a uno en el que dos partes pueden pagarse mutuamente un número ilimitado de veces sin que la cadena de bloques confirme ningún pago. Como es de esperar, utiliza el trading de compromiso.
En la sección que explica "Transacciones comprometidas", ya hemos introducido un canal de pago. Sin embargo, este tipo de contrato, que solo aprovecha la multifirma 2 de 2, solo puede permitir pagos unidireccionales. Es decir, o Alicia siempre le paga a Bob, o Bob siempre le paga a Alicia hasta que él agota su saldo en el contrato. Si se trata de un pago bidireccional, significa que después de una actualización de estado, una de las partes puede tener menos saldo que antes, pero el AT tiene la última transacción comprometida firmada por la otra parte: ¿qué se puede hacer para evitar que el AT transmita la promesa anterior y el AT solo la transacción de compromiso más reciente?
La solución a este problema con el canal de rayos se llama "LN-Penalty". Ahora, digamos que Alice y Bob tienen 5 BTC cada uno en un canal; Ahora Alice quiere pagarle a Bob 1 BTC, así que firma la transacción prometida y se la envía a Bob:
Bob también firma un compromiso (que corresponde a la transacción anterior) y se lo envía a Alice:
El truco aquí radica en esta "clave pública temporal conjunta", que se genera utilizando una de sus propias claves públicas y una clave pública proporcionada por la otra parte, por ejemplo, la clave pública temporal conjunta Alice-Bob, que es obtenida por Alice utilizando una de sus propias claves públicas y una clave pública proporcionada por Bob, multiplicando cada una por un valor hash. Cuando se genera una clave pública de este tipo, nadie conoce su clave privada. Sin embargo, si Bob le dice a Alice la clave privada de la clave pública que proporcionó, Alice puede calcular la clave privada de la clave pública temporal federada. - Esta es la clave del hecho de que Lightning Channel puede "deshacer" el estado anterior.
La próxima vez que las dos partes quieran actualizar el estado del canal (iniciar un pago), las dos partes intercambiarán la clave privada de la clave pública temporal que se dieron en la ronda anterior. De esta manera, los participantes ya no se atreven a transmitir la última transacción prometida que recibieron: la salida de esta transacción prometida que asigna valor a su propia parte tiene dos rutas, y la clave privada de la ruta de clave pública temporal ya es conocida por la otra parte; Por lo tanto, una vez que se transmite la transacción de compromiso anterior, la otra parte puede usar inmediatamente esta clave privada temporal conjunta para tomar todos los fondos en esta salida. - Esto es lo que significa "LN-Penalty".
En concreto, el orden de interacción es el siguiente: la parte que inicia el pago solicita primero una nueva clave pública temporal a la otra parte, y luego construye una nueva transacción de compromiso y se la entrega a la otra parte; La parte que obtuvo la transacción prometida reveló a la otra parte la clave privada de la clave pública temporal que dio en la ronda anterior. Esta secuencia de interacciones garantiza que los participantes siempre obtengan una nueva transacción de compromiso antes de invalidar la transacción de compromiso que recibieron en la ronda anterior y, por lo tanto, no es de confianza.
En resumen, los diseños clave del canal de relámpagos son:
Finalmente, debido a que HTLC también se puede colocar en una transacción comprometida, el canal Lightning también puede reenviar pagos. Suponiendo que Alice puede encontrar un camino que consiste en canales de rayos que se conectan antes y después para llegar a Daniel, entonces se pueden lograr pagos de múltiples saltos sin confianza sin abrir un canal con Daniel. Esta es la Lightning Network:
Cuando Alice encuentra ese camino y quiere pagarle a Daniel, le pide a Daniel un hash para construir un HTLC para Bob, y le pide a Bob que reenvíe un mensaje a Carol y proporcione el mismo HTLC; El mensaje le pide a Carol que reenvíe el mensaje a Daniel y proporcione el mismo HTLC. Cuando la noticia llega a Daniel, le revela la preimagen a Carol, que le da el valor de HTLC y actualiza el estado del contrato. Carol hizo lo mismo, Bob le pagó y actualizó el estado del canal; Finalmente, Bob le revela la preimagen a Alice y actualiza el estado. Debido a la naturaleza de HTLC, esta cadena de pagos tiene éxito o fracasa en conjunto y, como tal, no es confiable.
La Lightning Network se compone de un canal tras otro, cada uno de los cuales es independiente entre sí. Esto significa que Alice solo necesita saber lo que está sucediendo en su canal con Bob, independientemente de cuántas interacciones hayan tenido lugar en los canales de otras personas, qué moneda usan esas interacciones o incluso si realmente están usando el canal.
La escalabilidad de Lightning Network no solo se refleja en el hecho de que la velocidad de pago dentro de un Lightning Channel solo está limitada por la inversión de recursos de hardware por ambas partes, sino también en que debido al almacenamiento descentralizado del estado, un solo nodo puede aprovechar el máximo apalancamiento con el menor costo.
(3) Tenga cuidado con los contratos de diario
El Cautionary Journaling Contract (DLC) utiliza una técnica criptográfica llamada "firma de adaptador" que permite a Bitcoin Script programar contratos financieros que dependen de eventos externos.
Las firmas de adaptador permiten que una firma se convierta en una firma válida solo después de agregar una clave privada. Tomemos el ejemplo de una firma Schnorr, donde la forma estándar de una firma Schnorr es (R, s), donde:
Digamos que doy un par de datos (R, s') donde:
Obviamente, esta no es una firma Schnorr válida, y no pasa la fórmula de validación, pero puedo demostrarle al verificador que puede ser una firma válida simplemente conociendo la clave privada de R 2, r 2:
Las firmas de adaptador hacen que la validez de una firma dependa de un dato secreto y sea verificable. Pero, ¿qué tiene que ver esto con los contratos financieros?
Supongamos que Alice y Bob quieren apostar por el resultado de un juego de pelota. Alice y Bob apostaron a que el Duende Verde y Alina ganarían, respectivamente, con una apuesta de 1 BTC. Además, Carol, un sitio web de reseñas de fútbol, prometió usar un nonce R_c para publicar una _c_i firmada de los resultados cuando se anunciaran los resultados del juego.
Como se puede ver, hay tres resultados posibles (por lo que hay 3 posibilidades para la firma de Carol):
Duende Verde gana, Alice gana 1 BTC
Alina gana y Bob gana 1 BTC
Empate, los fondos de los dos regresan de la misma manera
Para ello, los dos crean un acuerdo de compromiso para cada resultado. Por ejemplo, la transacción de compromiso que crearon para el primer resultado tendría el siguiente aspecto:
Sin embargo, en lugar de (R, s), la firma que Alice y Bob crearon para esta transacción es una firma de adaptador (R, s'); En otras palabras, las firmas dadas por ambas partes no pueden utilizarse directamente para desbloquear el contrato, sino que deben revelar un valor secreto. ¡Este valor secreto es la preimagen de s_c_ 1.G, que es la firma de Carol! Dado que se ha determinado el valor nonce de la firma de Carol (R_c), se puede construir s_c_ 1.G (s_c_ 1.G = R_c + Hash(R_c ||). 'El Duende Verde gana' || PK_c) * PK_c)。
Cuando se revelan los resultados, asumiendo que el Duende Verde gana, Carol emitirá una firma (R_c, s_c_ 1), para que Alice o Bob puedan completar la firma del adaptador del oponente y agregar su propia firma para hacer que la transacción anterior sea una transacción válida, y transmitirla a la red para desencadenar el efecto de liquidación. Pero si el Duende Verde no gana, Carol no publicará s_c_ 1, y el acuerdo de compromiso no será un trato válido.
Y así sucesivamente, al igual que los otros dos oficios. De esta manera, Alice y Bob hacen que la ejecución del contrato dependa de eventos externos (para ser precisos, de la transmisión de eventos externos por parte de la máquina de aserción, en forma de firma) sin tener que confiar en la contraparte. Los contratos financieros grandes y pequeños, como los futuros y las opciones, pueden implementarse de esta manera.
En comparación con otras formas de implementación, la característica más importante del contrato de registro cauteloso es su privacidad: (1) Alice y Bob no necesitan decirle a Carol que están utilizando los datos de Carol, lo que no afecta en absoluto a la ejecución del contrato; (2) Los observadores on-chain (incluida Carol) no podrán determinar qué sitio web están utilizando a través de la ejecución del contrato de Alice y Bob, o incluso que su contrato es un contrato de apuestas (no un canal relámpago).
IV. Introducción a la aplicación de restricciones
(a) OP_CTV y control de la congestión
Los desarrolladores de la comunidad Bitcoin han hecho una serie de propuestas que se pueden clasificar como cláusulas restrictivas. Por el momento, una de las propuestas más conocidas es OP_CHECKTEMPLATEVERIFY (OP_CTV), que es popular entre la comunidad Bitcoin por su simplicidad pero flexibilidad con su concepto simple. La idea de OP_CTV es confirmar un hash en el script para restringir que los fondos solo se puedan gastar en las transacciones representadas por este hash; Este hash promete la salida de la transacción y la mayoría de los campos, pero no la entrada de la transacción, solo el número de entradas.
"Control de la congestión" es un buen ejemplo de cómo se puede demostrar la OP_CTV. Su caso de uso básico es ayudar a un gran número de usuarios a salir de un exchange (un entorno que requiere confianza) a un pool; Dado que este grupo utiliza OP_CTV para planificar cómo se gastará en el futuro, garantiza que los usuarios puedan salir del grupo sin confianza, sin la ayuda de nadie; Y debido a que este grupo solo se comporta como un UTXO, evita pagar muchas tarifas cuando la demanda de transacciones en cadena es alta (de n salidas a 1 salida; también se redujo de n transacciones a 1 transacción). Los usuarios del grupo pueden esperar una oportunidad para salir del grupo.
Supongamos que Alice, Bob y Carol quieren retirar 5 BTC, 3 BTC y 2 BTC del exchange, respectivamente. Luego, el intercambio puede obtener una salida de 10 BTC con 3 OP_CTV ramas. Supongamos que Alicia quiere retirar dinero, puede usar la sucursal 1; La transacción representada por el valor hash utilizado por el OP_CTV de la rama formará dos salidas, una de las cuales es asignar 5 BTC a Alice; La otra salida, a su vez, es un grupo, que también utiliza OP_CTV para comprometerse con una transacción, lo que permite a Bob retirar solo 3 BTC y enviar los 2 BTC restantes a Carol.
Es lo mismo si Bob o Carol quieren retirar dinero. Al retirar dinero, solo podrán utilizar transacciones que puedan pasar el cheque OP_CTV correspondiente, es decir, solo podrán pagarse a sí mismos la cantidad correspondiente y no podrán retirar dinero arbitrariamente; Los fondos restantes irán a un grupo con un bloqueo OP_CTV, lo que garantiza que los usuarios restantes puedan ser colocados fuera del grupo sin confianza, independientemente del orden en que se retiren.
En abstracto, el papel de OP_CTV aquí es planificar el camino hasta el final de la vida del contrato para el contrato, de modo que el contrato de grupo aquí pueda mantener el atributo de salida sin confianza sin importar qué camino tome o qué estado vaya.
También hay un uso muy interesante de este OP_CTV: "canal de pago unidireccional que está oculto pero no revelado". Supongamos que Alice forma un grupo de fondos de este tipo y garantiza que los fondos se pueden retirar sin confianza en una salida con el siguiente script:
Si Alice no se lo hubiera revelado a Bob, Bob no habría sabido que existía tal salida; Una vez que Alice se lo revela a Bob, Bob puede usar la salida como un canal de pago unidireccional y sensible al tiempo que Alice puede usar para pagarle a Bob de inmediato sin tener que esperar la confirmación de la cadena de bloques. Bob simplemente le pide a Alice que ponga su transacción de compromiso en la cadena antes de que Alice pueda gastarla por su cuenta.
(b) OP_Vault y seguro
El OP_VAULT es una propuesta de cláusula restrictiva diseñada específicamente para construir "bóvedas".
El contrato de Vault está diseñado para ser una forma más segura y avanzada de autocustodia. Aunque el contrato de firma múltiple actual puede evitar un único punto de error para una sola clave privada, si un atacante obtiene un número umbral de claves privadas, el propietario de la billetera está indefenso. Vault quiere imponer un único límite de gasto a tus fondos; Al mismo tiempo, al retirar dinero por la vía regular, la operación de retiro impondrá un período de espera; Y durante el período de espera, la operación de retiro puede ser interrumpida por la operación de recuperación de emergencia de la billetera. Incluso si se incumple dicho contrato, el propietario de la billetera puede iniciar una contraoperación (utilizando la rama de recuperación de emergencia).
Teóricamente, OP_CTV también puede programar un contrato de este tipo, pero hay muchos inconvenientes, uno de los cuales es la comisión: mientras se compromete con la transacción, también promete la tarifa que pagará la transacción. Dado el propósito de este contrato, el intervalo de tiempo entre la creación del contrato y el retiro de dinero debe ser muy largo, por lo que es casi imposible predecir la comisión adecuada. Aunque OP_CTV no limita los insumos, por lo que la tarifa se puede aumentar aumentando el insumo, el insumo proporcionado se convertirá en la comisión, por lo que no es realista; Otra forma es el CPFP, que consiste en proporcionar una comisión sobre nuevas transacciones gastando los fondos retirados. Además, el uso de OP_CTV significa que un contrato de Vault de este tipo no se puede retirar de forma masiva (y, desde luego, no se puede restaurar de forma masiva).
La propuesta de OP_VAULT intenta abordar estas cuestiones proponiendo nuevos códigos de operación (OP_VAULT y OP_UNVAULT). OP_UNVAULT está diseñado para la resistencia por lotes, por lo que no lo mencionaremos por ahora. OP_VAULT se comporta así: cuando lo colocamos en una rama del árbol de scripts, se puede usar para confirmar un código de operación utilizable (por ejemplo, OP_CTV) sin parámetros específicos; Al gastar esta rama, las transacciones se pueden pasar en parámetros específicos, pero no en otras ramas. Como resultado, no tiene que establecer una tarifa preestablecida, y se puede establecer cuando se gasta la sucursal; Suponiendo que la rama también tiene un bloqueo de tiempo, aplicará un bloqueo de tiempo; Finalmente, dado que solo puede cambiar la rama en la que se encuentra, y no se cambiará ninguna otra rama del nuevo árbol de scripts (incluida la rama de recuperación de emergencia), se nos permite interrumpir dichos retiros.
Además, vale la pena mencionar dos puntos: (1) el código de operación OP_VAULT se comporta de manera similar a otra propuesta de restricción: OP_TLUV; Jeremy Rubin señala acertadamente que esto ha dado lugar al concepto de "computación" hasta cierto punto: OP_TLUV/OP_VAULT primero promete un código de operación para permitir al consumidor actualizar toda la hoja del árbol de script pasando parámetros al código de operación con una nueva transacción; Ya no se trata de "validar los datos entrantes en función de ciertos criterios", sino de "generar nuevos datos significativos en función de los datos entrantes", aunque el cómputo que puede permitir es limitado.
(2) La propuesta completa de OP_VAULT también hace uso de algunas de las propuestas sobre la política de mempool (por ejemplo, transacciones v3) para lograr mejores resultados. Esto nos recuerda que el significado de "programación" puede ser más amplio de lo que pensamos. (Un ejemplo similar es Open Transaction en la red Nervos). ）
V. Entendiendo CKB
En las dos secciones anteriores, describimos cómo podemos programar aplicaciones interesantes en una estructura más restringida (Bitcoin UTXO); También se presentaron propuestas para tratar de añadir introspección a dicha estructura.
Si bien los UTXO tienen la capacidad de programar estas aplicaciones, es fácil para los lectores detectar sus deficiencias o áreas que se pueden optimizar, como:
De hecho, la comunidad Bitcoin ha encontrado respuestas a estas preguntas, básicamente relacionadas con una propuesta de Sighash (BIP-118 AnyPrevOut).
Sin embargo, si estuviéramos programando en CKB, BIP-118 estaría disponible ahora (tales etiquetas Sighash podrían simularse con la capacidad de verificar firmas de manera introspectiva y deliberada).
Al aprender a programar Bitcoin, no solo sabemos cómo se pueden programar en el formato "Transaction Output" (qué se puede programar en CKB), sino también cómo mejorar estas aplicaciones (y cómo podemos usar las capacidades de CKB para mejorarlas si las programamos en CKB). Para los desarrolladores de CKB, la programación basada en Bitcoin Script se puede utilizar como material de aprendizaje, o incluso como atajo.
A continuación, analicemos la programabilidad de cada módulo de programación CKB uno por uno. No consideremos la introspección por ahora.
(1) Cerradura programable calculada arbitrariamente
Como se mencionó anteriormente, los UTXO no se pueden programar para calcular arbitrariamente. Lock, por otro lado, significa que Lock puede programar todo (antes de la implementación de restricción) basado en UTXO, incluidos, entre otros, Lightning Channel y DLC mencionados anteriormente.
Además, esta capacidad de verificar el cálculo arbitrario también hace que Lock sea más flexible que UTXO en términos de métodos de autenticación. Por ejemplo, podemos implementar un canal lightning en el CKB donde una parte firma ECDSA y la otra parte usa RSA.
De hecho, esta es una de las primeras áreas que la gente comenzó a explorar en CKB: el uso de esta capacidad de autenticación flexible en la autocustodia del usuario para permitir lo que se conoce como "abstracción de cuentas": la autorización de la validez de la transacción y la restauración del control son muy flexibles y casi ilimitadas. En principio, se trata de una combinación de "múltiples ramas de gasto" y "métodos de autenticación arbitrarios". Ejemplos de implementaciones son: joyid wallet, UniPass.
Además, Lock puede implementar propuestas de eltoo, habilitando un canal lightning que solo necesita mantener la última transacción comprometida (de hecho, eltoo puede simplificar todos los contratos peer-to-peer).
(2) Tipo programable calculado arbitrariamente
Como se mencionó anteriormente, uno de los grandes usos de Type es programar UDT. Combinado con Lock, esto significa que podemos implementar canales de iluminación basados en UDT (y otros tipos de contratos).
De hecho, la división entre Lock y Type puede verse como una mejora de seguridad: Lock se centra en la implementación de métodos de custodia o acuerdos contractuales, mientras que Type se centra en la definición de UDT.
Además, la capacidad de iniciar comprobaciones basadas en definiciones de UDT también permite a UDT participar en los contratos de forma similar a CKB (UDT es ciudadano de primera clase).
Por ejemplo, el autor propuso una vez un protocolo para implementar préstamos respaldados por NFT sin confianza en Bitcoin. La clave de un protocolo de este tipo es una transacción comprometida en la que el valor de la entrada es menor que el valor de la salida (por lo que aún no es una transacción válida), pero una vez que se puede proporcionar suficiente información para la transacción, es una transacción válida: una vez que el prestamista puede pagar, el prestamista no puede tomar el NFT apostado para sí mismo. Sin embargo, la falta de confianza de esta transacción de compromiso se basa en que la transacción verifique la cantidad de entrada y salida, por lo que el prestamista solo puede usar Bitcoin para pagar el préstamo: incluso si tanto el prestamista como el prestamista están dispuestos a aceptar otra moneda (como USDT emitida bajo el protocolo RGB), la transacción de compromiso de Bitcoin no garantiza que el prestamista recupere su NFT siempre que el prestamista devuelva la cantidad total de USDT, ¡porque la transacción de Bitcoin no tiene idea del estado de USDT! (Revisión: En otras palabras, no es posible construir una transacción comprometida condicionada al reembolso de USDT). ）
Si somos capaces de iniciar una comprobación basada en la definición de UDT, podremos conseguir que el prestamista firme otra transacción comprometida que le permitirá utilizar USDT para pagar el préstamo. La transacción verificará la cantidad de USDT ingresada y la cantidad de USDT saliente, lo que brindará a los usuarios un pago sin confianza con USDT.
A continuación, consideremos la introspección.
(3) La cerradura lee otras cerraduras
Esto significa toda la gama de posibilidades de programación en los UTXO de Bitcoin después de que se implemente la restricción propuesta. Esto incluye los contratos de Vault mencionados anteriormente, así como las aplicaciones basadas en OP_CTV (por ejemplo, control de congestión).
XueJie mencionó una vez un ejemplo muy interesante: puede implementar una celda de cuenta de cobro en CKB, cuando se usa este tipo de celda como entrada de la transacción, si la celda de salida (la celda que usa el mismo bloqueo) tiene más capacidad, entonces la entrada no necesita proporcionar una firma y no afecta la validez de la transacción. De hecho, este tipo de célula no sería posible sin la capacidad de introspección. Esta celda de cuenta de cobro es ideal como método institucional para recibir dinero porque reúne fondos y tiene la desventaja de no tener un buen sentido de privacidad.
(4) Bloquear lee otros tipos (y datos)
Una aplicación interesante de esta capacidad son los tokens de apuesta. Lock decidirá si puede usar su propia capacidad en función de la cantidad de tokens en las otras entradas y dónde se puede gastar (requiere la capacidad de bloquear por introspección).
(5) El tipo lee otras cerraduras
No estoy seguro, pero se puede suponer que es útil. Por ejemplo, puede comprobar en Tipo que los bloqueos de las entradas y salidas de una transacción permanezcan sin cambios.
(6) El tipo Scirpt lee otros tipos (y datos)
¿Cromos? Recoge n tokens a cambio de un token más grande :)
VI. Conclusión
En comparación con los sistemas de contratos inteligentes anteriores que se pueden programar con computación arbitraria, como Ethereum, Nervos Network tiene una estructura diferente; Como resultado, a menudo es difícil entender la Red Nervos basándose en el conocimiento de los sistemas de contratos inteligentes del pasado. En este trabajo se propone un método para entender la programabilidad de CKB Cell, a partir de la programación de aplicación de una estructura más restringida que CKB Cell, BTC UTXO. Y, utilizando el concepto de "introspección" para comprender las capacidades de "acceso entre contratos" de las células, podemos dividir las situaciones en las que se utilizan las capacidades introspectivas y determinar sus usos específicos.
Recensión:
Los dos puntos anteriores significan algo con el mismo paradigma que "BTC + RGB" pero con más capacidades de programación;
No hay muchos ejemplos específicos de estos usos, pero esto se debe a la falta de comprensión del autor sobre la ecología de la CKB. Con el tiempo, se cree que se invertirá más y más imaginación en él, y se armarán aplicaciones que hoy son inimaginables.
Agradecimientos
Gracias a Retric, Jan Xie y Xue Jie por sus comentarios durante la redacción del artículo. Por supuesto, soy responsable de todos los errores en el texto.
Referencias
Cuentas, listas de acceso estricto y UTXO
Restricciones en Bitcoin: Taxonomía para revisión
Modelo de célula
Nervos CKB en pocas palabras
La programabilidad de Bitcoin
Abstracción a cuenta (2022)
¿Qué es un árbol sintáctico abstracto de Bitcoin Merkelizado?
BIP 345: Propuesta de _VAULT
Introducción a los códigos de operación de restricción TLUV
Los componentes que construyen el contrato se actualizan con Bitcoin
Explicación de Eltoo
Un contrato de préstamo garantizado de NFT basado en transacciones comprometidas · btc-estudio/OP_QUESTION · Discusión #7
Enlace al artículo original