No hay notificaciones nuevas
Más
Color de subida/bajada
Hora de inicio y finalización del cambio
- Tema
151k publicaciones
92k publicaciones
71k publicaciones
61k publicaciones
58k publicaciones
50k publicaciones
50k publicaciones
47k publicaciones
45k publicaciones
- 10#比特币#
45k publicaciones
- Anclado
- 📣 Gate.io Llamada a la acción de Post Cripto Observer!
📈 Compartir Noticias de Cripto y Ganar Grandes Recompensas Semanales!
💓 No dudes, únete ahora ⏬
1. Comparte noticias diarias de cripto, tendencias del mercado y perspectivas en tu publicación.
2. Incluya el #CryptoObservers# para participar con éxito.
🎁 ¡10 afortunados "Cripto Observers" serán recompensados con $20 puntos cada viernes!
📌 La lista de ganadores se anunciará todos los viernes, con recompensas distribuidas el mismo día.
📌 Nota: las publicaciones pueden incluir solo la etiqueta #CryptoObservers# ; de lo contrario, no habrá
- 🔥 ¡La tarea exclusiva de beneficios de publicación para embajadores de Gate.io está en pleno apogeo!
¡Publica diariamente y gana semanalmente una recompensa de $1,000 basada en los niveles de calidad de las publicaciones (1/20-1/26)!
👉 ¡Publica y comparte recompensas de $1,000 basadas en los niveles de calidad de las publicaciones!
¡Regístrate ahora: https://www.Gate.io.io/questionnaire/5902 (Finaliza el 20 de enero, 16:00 UTC)
🎁 Recompensa:
1️⃣ Recompensa semanal de clasificación S-Level:
Completa publicaciones diarias durante los 7 días de la semana con una puntuación general de calidad
- ⛏ El programa de líder social Minería ya está en vivo! Únete y disfruta de hasta un 60% de comisión!
📇 ¡Gana recompensas fácilmente a través del Programa de Minería de Contenido, Programa de Minería gateLive y Comisión de Referidos!
🧮 Content Minería gana hasta un 10% de beneficio
🔥 Estrategia Copia Comisión y Comisión en Vivo de Minería ganar hasta un 10% de beneficio
📈 Comparte contenido de Moments e invita a amigos para ganar hasta un 40% de beneficio
🚀 ¡Únete ahora y comienza tu viaje de ganancias por comisión!
Más información: https://www.gate.io/social-mining-commission
- 💥 Carnaval de listado de Gate.io x OFFICIAL TRUMP (TRUMP): ¡Disfruta de Triple Sorpresas!
✨ Apueste #TRUMP# para ganar #TRUMP# Airdrop
✨ Liga de Trading #TRUMP# : Únete y comparte $20,000 Recompensas
✨ Deposite #TRUMP# y Regístrese para reclamar una parte de las recompensas de $100,000
➡️ Únete ahora: https://www.gate.io/campaigns/368
#TRUMP#
- ¿Cómo optimizar el perfil de publicación de Gate.io para aumentar la influencia en la comunidad? Gate.io Post 101 ¡un solo artículo te ayuda a dominarlo!
Desde la programación de aplicaciones de Bitcoin, una explicación detallada de la programabilidad de CKB
El siguiente contenido es una reproducción del foro Nervos Talk, escrito por Ajian (editor en jefe de BTC Study, una plataforma de contenido de Bitcoin).
Resumen
理解一个系统的可编程性要求我们辨识这个系统在结构上的特征。对基于BTC脚本的应用编程的探索，有助于我们理解 CKB Cell 的基本结构及其编程范式。不仅如此，它还能将 CKB 的编程元件分解为恰当的部分，并帮助我们理解每一部分所带来的可编程性增益。
一. Introducción
"La 'programabilidad' es una dimensión comúnmente utilizada por las personas al comparar sistemas de cadena de bloques. Sin embargo, hay diferentes enfoques para describir la programabilidad. Una forma común de expresarlo es: 'La cadena de bloques XX admite un lenguaje de programación Turing completo' o 'La cadena de bloques XX admite programación general', lo que implica que la cadena de bloques XX tiene una gran capacidad de programación. Estas afirmaciones tienen cierta lógica: los sistemas que admiten programación Turing completa suelen ser más fáciles de programar que los que no la admiten. Sin embargo, las características estructurales de los sistemas de contratos inteligentes tienen varios aspectos, y esta afirmación solo aborda uno de ellos, por lo que no proporciona una comprensión profunda suficiente: los desarrolladores no obtienen orientación de ella, y los usuarios comunes no pueden distinguir estafas basándose en ella."
Contrato inteligente El sistema de características estructurales incluye:
Por lo tanto, además de la "capacidad de cálculo programable", hay al menos cuatro características más que pueden afectar la programabilidad de un sistema de contratos inteligentes. Incluso se podría decir que estas otras características son más importantes, ya que determinan más profundamente qué es fácil de lograr y qué es difícil de lograr; qué es una implementación más económica y qué es una implementación menos eficiente.
Para dar un ejemplo, la gente a menudo usa Ethereum como un buen ejemplo de programabilidad, pero la forma básica de expresión de estado en Ethereum es la cuenta, lo que dificulta la programación de contratos punto a punto (por ejemplo, canales de pago, contratos de apuestas uno a uno) - no es imposible de lograr, pero es complicado. La comunidad de Ethereum no carece de intentos para implementar canales de pago/estado, y hay mucha discusión teórica al respecto, pero parece que estos proyectos no están activos en la actualidad, lo que claramente no se debe a la falta de esfuerzo de los desarrolladores. Actualmente, los proyectos activos en Ethereum adoptan la forma de "pools de fondos", en lugar de la forma de "contratos punto a punto", y esto no es casualidad. Del mismo modo, es posible que la gente esté satisfecha con la programabilidad de Ethereum en la actualidad, pero el modelo de cuenta puede considerarse inherentemente deficiente si se quiere lograr una "abstracción de cuentas" (también se puede entender como una generalización del concepto de billetera).
Lo mismo ocurre al investigar la programabilidad de CKB, también se nos exige comprender las características estructurales del sistema de contratos inteligentes CKB en estos aspectos. Lo que ya sabemos es que CKB permite programar cualquier cálculo, permite registrar estado adicional dentro del contrato y permite que un contrato acceda al estado de otro contrato durante su ejecución. Sin embargo, su forma de contrato es la salida de una transacción (llamada "celda"), lo que crea una diferencia fundamental con Ethereum. Por lo tanto, comprender el sistema de contratos inteligentes de Ethereum y los ejemplos de contratos allí no nos ayuda a entender cómo CKB implementa estas características estructurales ni a reconocer su programabilidad.
Afortunadamente, los contratos inteligentes en Bitcoin parecen proporcionar la mejor base para comprender la programabilidad de CKB. Esto se debe no solo a que la forma básica de expresión del estado de Bitcoin también son las salidas de transacción (llamadas "UTXO"), sino también porque, a través de un concepto propuesto por la comunidad de Bitcoin llamado "covenants" (limitaciones contractuales), podemos entender las razones por las que CKB tiene estas características estructurales y dividir adecuadamente el efecto final en varias partes para identificar individualmente los beneficios de programabilidad que cada una de ellas aporta.
二. CKB v.s. BTC：largo了什么？
Estructura básica
Como forma básica de expresar el estado de Bitcoin, las UTXO (salidas de transacción no gastadas) de Bitcoin tienen dos campos.
与后来出现的contratos inteligentes系统相比，比特币脚本是相当受限的：
Esta clase de script, aunque limitado, no carece de la capacidad para crear aplicaciones asombrosas, y de hecho es la base de nuestra exploración de la programabilidad de CKB. En el siguiente texto se presentarán dos ejemplos específicos de programación de scripts de Bitcoin.
Conversely, la unidad de estado de CKB se llama "Cell", que tiene cuatro campos:
Además, Lock y Type también pueden ser programados para realizar cálculos arbitrarios. Puedes programar cualquier algoritmo de verificación de firma, cualquier algoritmo de comprobación de imagen inversa de cualquier función hash, etc.
Los lectores pueden ver fácilmente que Cell mejora la programabilidad en comparación con UTXO.
En combinación con la estructura de "salida de transacción" de Cell en sí, estas dos características por sí solas pueden traer beneficios enormes. Sin embargo, solo a partir de la descripción anterior, no sabemos cómo Cell implementa "el acceso de un contrato al estado de otro contrato durante la ejecución". Para esto, necesitamos recurrir a un concepto que la comunidad de Bitcoin ha estado discutiendo durante mucho tiempo: "cláusulas restrictivas (covenants)".
Términos y condiciones restringidos y reflexión interna
限制条款的本意是限制一笔钱能被花到哪里去。在当前的比特币（尚未部署任何限制条款提议）上，一笔资金一旦解锁，就可以花到任何地方（可以支付给任意的脚本公钥）。但限制条款的想法是，可以用某种方式，限制它只能花到某些地方去，比如，某一个 UTXO 将只能被某一笔交易花费，那么，即便有人能够为这个 UTXO 提供签名，它可以花到什么地方也已经被这笔交易决定了。这种功能看起来有点奇怪，却能产生一些有趣的应用，后文会有专门的一节介绍。重要的是，它是我们进一步理解 CKB 可编程性的关键。
Rusty Russell señaló correctamente que las cláusulas de restricción pueden entenderse como la capacidad de "introspección" de las transacciones, es decir, cuando se gasta una salida no utilizada (UTXO) A en una transacción B, el programa de script puede leer parte o la totalidad de la transacción B y verificar si cumplen con los parámetros requeridos por el script. Por ejemplo, si la clave pública del primer resultado de la transacción A coincide con la clave pública requerida por la salida no utilizada (UTXO) A (este es el significado original de la cláusula de restricción).
Los lectores perspicaces se darán cuenta de que, si tienen la capacidad completa de introspección, pueden leer el estado de otra entrada de la misma transacción con la entrada de una transacción, lo que realiza la habilidad de "un contrato accede al estado de otro contrato en tiempo de ejecución" que mencionamos anteriormente. De hecho, el CKB Cell está diseñado de esta manera.
基于此，我们又可以将这种完全的内省能力分成四种情形：
Esto nos permite analizar el papel de la capacidad de introspección de cada parte en diferentes escenarios de aplicación, es decir, analizar las ganancias de programabilidad que cada parte nos aporta bajo ciertas suposiciones (la división de funciones de bloqueo y tipo).
En los dos capítulos siguientes, aprenderemos sobre la programación de scripts de Bitcoin actual (sin propuestas de términos restringidos) y las funcionalidades esperadas de las propuestas de términos restringidos, para comprender concretamente cómo programar y mejorar las CKB Cells.
Tres. Bitcoin scripting
本节将使用 “闪电通道/闪电网络” 和 “谨慎日志合约（DLC）” 作为基于比特币脚本的应用编程的案例。在展开之前，我们要先了解两个概念。
OP_IF y "transacciones de compromiso"
El primer concepto son los códigos de operación de control de flujo en el script de Bitcoin, como por ejemplo: OP_IF, OP_ELSE. Estos códigos de operación no son diferentes del IF en la programación de computadoras, su función es ejecutar diferentes instrucciones según las diferentes entradas. En el contexto del script de Bitcoin, esto significa que podemos establecer múltiples rutas de desbloqueo de fondos; junto con la característica de bloqueo de tiempo, esto significa que podemos asignar la prioridad de acción.
En el ejemplo del famoso contrato "Hashed TimeLock Contrato (HTLC)", este script se traduce en lenguaje sencillo como:
要么，Bob 可以揭晓某个哈希值 H 背后的原像，再给出自己的签名，即可花费这笔资金；
要么，Alice 可以在一段时间 T 过后，凭借自己的签名花费这笔资金。 -> Alternativamente, Alice puede gastar estos fondos después de un período de tiempo T con su propia firma.
Esta efecto de "o bien ... o bien ..." se logra mediante el uso de códigos de operación de control de flujo.
HTLC destaca por su capacidad para combinar múltiples operaciones y lograr atomicidad. Por ejemplo, si Alice quiere intercambiar CKB con Bob por BTC, Bob puede primero proporcionar un valor hash y crear un HTLC en la red Nervos; luego, Alice crea un HTLC en Bitcoin utilizando el mismo valor hash. Luego, Bob puede reclamar los BTC pagados por Alice en Bitcoin y revelar el secreto, lo que permite a Alice reclamar CKB en la red Nervos. O bien, si Bob no revela el secreto, ambos contratos caducan y tanto Alice como Bob pueden recuperar sus fondos.
Después de la activación de la bifurcación suave de Taproot, esta característica de múltiples rutas de desbloqueo se ha fortalecido aún más gracias a la introducción de MAST (Árbol de Sintaxis de Abstracto de Merkel): podemos convertir una ruta de desbloqueo en una hoja del árbol de Merkel, donde cada hoja es independiente, por lo que ya no es necesario utilizar códigos de control de flujo como este; además, debido a que no es necesario revelar otras rutas al revelar una ruta, podemos agregar más rutas de desbloqueo a una salida sin preocuparnos por problemas económicos.
El segundo concepto es el de "transacciones prometidas". La idea de las transacciones prometidas es que en ciertos casos, una transacción válida de Bitcoin es real y vinculante, incluso si no se confirma en la cadena de bloques.
Por ejemplo, Alice y Bob poseen conjuntamente una UTXO que requiere las firmas de ambos para gastarla. En este caso, Alice crea una transacción para gastarla, transfiriendo el 60% del valor a Bob y el resto a sí misma. Alice firma esta transacción y la envía a Bob. Para Bob, no es necesario difundir esta transacción a la red de Bitcoin ni hacer que sea confirmada en la cadena de bloques. El efecto de pago de esta transacción es real y confiable. Esto se debe a que Alice no puede gastar la UTXO por sí sola (evitando gastos dobles) y porque la firma proporcionada por Alice es válida. Bob puede agregar su propia firma en cualquier momento y luego difundir la transacción para hacer efectivo el pago. En resumen, Alice le proporciona a Bob un "compromiso confiable" a través de esta transacción válida (que no se incluye en la cadena de bloques).
承诺交易是Bitcoin应用编程的核心概念。如前所述，Bitcoin的合同是基于验证的、无状态的、不允许交叉访问的；但是，如果合同不携带状态，那这些状态存放在哪里、合同如何安全推进（变更状态）？承诺交易给出了直截了当的答案：合同的状态可以用交易的形式来表达，从而，合同的参与者可以自己保存状态，而不必将它们展现在Bloquear上；合同的状态变更问题，也可以转化成如何安全地更新承诺交易的问题；此外，如果我们担心进入一个合同会有危险（例如，进入一个要求双方都签名才能花费的合同，会面临对方不响应从而卡死的风险），那么，只需提前生成花费该合同的承诺交易并获得签名，就可以化解风险、消除对其他参与者的信任。
Canales de rayos y Red de rayos
闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。
En la parte de explicar "transacción de compromiso", hemos introducido un canal de pago. Sin embargo, este tipo de contrato que utiliza únicamente una firma múltiple de 2 de 2 solo puede lograr pagos unidireccionales. Es decir, ya sea que solo Alice le pague a Bob o que solo Bob le pague a Alice, hasta que se agote el saldo en el contrato. Si se trata de pagos bidireccionales, esto significa que después de una actualización de estado, el saldo de una parte puede ser menor que antes, pero aún así tiene la transacción de compromiso anterior firmada por la otra parte. ¿Hay alguna forma de evitar que esa antigua transacción de compromiso se transmita y permitir que sólo se transmita la transacción de compromiso más reciente?
La solución a este problema se llama "LN-Penalty". Supongamos que Alice y Bob tienen 5 BTC cada uno en un canal, y ahora Alice quiere pagarle 1 BTC a Bob. Por lo tanto, ella firma una transacción de compromiso de este tipo y la envía a Bob:
Ingrese #0, 10 BTC: Salida de firma múltiple de Alie-Bob 2-de-2 (también conocida como contrato de canal)
Salida #0, 4 BTC: Alice firma única
El resultado #1, 6 BTC: ya sea la clave pública temporal conjunta de Alice-Bob #1 con una firma única o la cerradura de tiempo T1 con la firma única de Bob.
Bob también firma una transacción de compromiso (que corresponde a la transacción mencionada anteriormente) y la envía a Alice:
Entrada #0, 10 BTC: Salida de firma múltiple Alie-Bob 2-de-2 (es decir, contrato de canal)
"Enviar #0,6 BTC: Bob firma única"
"Salida #1, 4 BTC: Ya sea la clave pública temporal conjunta de Bob-Alice #1 con una firma única, o el bloqueo de tiempo T1 con una firma única de Alice."
Aquí está el truco, se trata de la "Llave pública temporal conjunta". Se genera utilizando una llave pública propia y una llave pública proporcionada por la otra parte. Por ejemplo, la llave pública temporal conjunta de Alice-Bob se obtiene multiplicando la llave pública de Alice por un valor hash y sumándola con la llave pública proporcionada por Bob. Al generar esta llave pública, nadie conoce su llave privada. Sin embargo, si Bob revela la llave privada de la llave pública que proporcionó, Alice puede calcular la llave privada de esta llave pública temporal conjunta. Esto es clave para "revertir" el estado anterior en el canal de rayos.
En la próxima actualización del estado del canal (iniciar pago), ambas partes intercambiarán la clave privada temporal entregada por la otra parte en la ronda anterior. De esta manera, los participantes ya no se atreverán a difundir la transacción de compromiso anterior que recibieron: esta transacción de compromiso tiene dos rutas de salida que asignan valor a uno mismo, pero la clave privada de la ruta de clave temporal ya es conocida por la otra parte; por lo tanto, una vez que se difunda la transacción de compromiso anterior, la otra parte puede utilizar inmediatamente esta clave privada temporal conjunta para llevarse todos los fondos de esta salida. - Esto es lo que significa "LN-Penalty".
En concreto, el orden de interacción es el siguiente: la parte que realiza el pago solicita primero una nueva clave pública temporal al otro lado, luego construye una nueva transacción de compromiso y se la entrega al otro lado; la parte que recibió la transacción de compromiso expone la clave privada de la clave pública temporal que proporcionó en la ronda anterior. Este orden de interacción garantiza que los participantes siempre obtengan primero una nueva transacción de compromiso y luego anulen la transacción de compromiso que obtuvieron en la ronda anterior, por lo tanto, es sin confianza.
En resumen, los diseños clave del canal relámpago son:
"Las partes siempre utilizan transacciones de compromiso para expresar el estado interno del contrato y representar los pagos mediante cambios en la cantidad;"
承诺交易总是花费同一个输入（需要双方同时提供签名的输入），因此所有承诺交易都是相互竞争的，最终只有一笔能够得到区块链的确认；
Dos participantes no firman la misma transacción comprometida (aunque están emparejadas); siempre firman transacciones que son más beneficiosas para sí mismos, es decir, las transacciones comprometidas que reciben los participantes siempre son desfavorables para ellos.
Esta desventaja se refleja en las salidas que asignan valor a sí mismas y tienen dos caminos de desbloqueo: uno que se puede desbloquear con la firma propia, pero que requiere esperar un período de tiempo; y otro que utiliza la llave pública del otro, solo está protegido si no se expone una clave privada temporal propia.
En cada transacción de pago, ambas partes intercambian las claves privadas temporales utilizadas en la ronda anterior mediante una nueva transacción de compromiso. Por lo tanto, la parte que entrega la clave privada temporal ya no se atreve a difundir la transacción de compromiso anterior, "revocando" así la transacción de compromiso anterior y actualizando el estado del contrato. (De hecho, estas transacciones de compromiso son válidas y se pueden difundir en la cadena de bloques, pero los participantes no se atreven a hacerlo debido al castigo).
Cualquiera de las partes puede retirarse del contrato en cualquier momento con el compromiso firmado por la otra parte; sin embargo, si ambas partes están dispuestas a colaborar, pueden firmar una nueva transacción que les permita recuperar inmediatamente su dinero.
Finalmente, debido a que las transacciones prometidas también pueden incluir HTLC, los canales de rayos también pueden reenviar pagos. Supongamos que Alice puede encontrar una ruta compuesta por canales de rayos que se conectan entre sí y llegan a Daniel, entonces se puede lograr un pago multi-salto sin confianza sin necesidad de abrir un canal con Daniel. Esto es lo que se conoce como la red de rayos.
Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel
Alice \u003c-- imagen original -- Bob \u003c-- imagen original -- Carol \u003c-- imagen original -- Daniel
Cuando Alice encuentra esta ruta y quiere pagarle a Daniel, ella solicita un valor hash a Daniel para construir un HTLC a Bob y le pide a Bob que reenvíe un mensaje a Carol y proporcione el mismo HTLC. El mensaje también le pide a Carol que reenvíe el mensaje a Daniel y proporcione el mismo HTLC. Cuando el mensaje llega a Daniel, él revela el preimagen a Carol, lo que le permite recibir el valor del HTLC y actualizar el estado del contrato. Carol hace lo mismo y recibe el pago de Bob y actualiza el estado del canal. Por último, Bob revela la preimagen a Alice y actualiza el estado. Debido a las características de HTLC, estos pagos se realizan todos juntos o fallan todos juntos, por lo que no requieren confianza mutua.
El Lightning Network está compuesto por una serie de canales, cada uno de ellos es independiente. Esto significa que Alice solo necesita conocer lo que sucede en su canal con Bob, sin importar cuántas interacciones haya en otros canales o qué tipo de moneda se utilice en esas interacciones, e incluso sin necesidad de saber si realmente se está utilizando el canal.
La escalabilidad de la red Lighting Network no solo se manifiesta en la velocidad de pago dentro de un canal de Lighting, que está limitada únicamente por los recursos de hardware de ambas partes, sino también en el hecho de que, debido al almacenamiento disperso de estados, un nodo individual puede obtener la mayor palanca con el menor costo.
Contrato de registro cauteloso
Cuidadoso Registro de Contratos (DLC) utiliza una técnica criptográfica llamada "firma adaptadora" para permitir que los scripts de Bitcoin programen contratos financieros dependientes de eventos externos.
Adaptar una firma de adaptador permite que una firma solo sea válida después de agregar una llave privada. Tomemos la firma Schnorr como ejemplo, la forma estándar de una firma Schnorr es (R, s), donde:
R = r.G # El valor de nonce utilizado para la firma r multiplicado por el punto de generación de la curva elíptica, también conocido como la llave pública de r
s = r + Hash(R || m || P) * p # p es la clave privada de firma, P es la clave pública
Verificar la firma es verificar s.G = r.G + Hash (R || m || P) * p.G = R + Hash (R || m || P) * PK
假设我给出了一对数据(R, s')，其中：
R = R1 + R2 = r1.G + r2.G
s' = r1 + Hash(R || m || P) * p
Obviamente, esta no es una firma Schnorr válida, no puede pasar la fórmula de verificación. Sin embargo, puedo demostrar a los validadores que, si conocen la llave privada r2 de R2, puedo convertirla en una firma válida.
s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P
El uso de la firma de adaptador permite que la validez de una firma dependa de datos secretos y sea verificable. Pero, ¿qué tiene que ver esto con los contratos financieros?
假设 Alice y Bob desean apostar por el resultado de un partido de fútbol. Alice y Bob apuestan por la victoria de los Green Demons y Arlinna respectivamente, con una apuesta de 1 BTC. Además, el sitio web de reseñas deportivas, Carol, se compromete a publicar una firma s_c_i del resultado usando un nonce R_c, una vez que se revele el resultado del partido.
Puede verse que hay tres posibles resultados en total (por lo tanto, Carol tiene tres posibles firmas).
为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：
输入 #0，2 BTC： Alie-Bob 2-of-2 firma múltiple de salida (es decir, contrato de apuestas).
Salida #0, 2 BTC: Alice firma única
Pero las firmas creadas por Alice y Bob para esta transacción no son (R, s), sino firmas adaptadoras (R, s'); es decir, las firmas entregadas por ambas partes no pueden desbloquear directamente este contrato inteligente, sino que se debe revelar un valor secreto. Este valor secreto es precisamente la preimagen de s\_c\_1.G, es decir, la firma de Carol. Dado que el valor de nonce de la firma de Carol ya está determinado (es R\_c), es posible construir s\_c\_1.G (s\_c\_1.G = R\_c + Hash(R\_c || '绿魔胜出' || PK\_c) \* PK\_c).
Cuando se revelen los resultados, si se supone que el Equipo Verde gana, Carol publicará la firma (R_c, s_c_1). Entonces, tanto Alice como Bob pueden completar la firma del adaptador del oponente, agregar su propia firma y hacer que la transacción anterior sea válida, luego difundirla a la red y desencadenar el efecto de Asentamiento. Pero si el Equipo Verde no gana, Carol no publicará s_c_1, por lo que esta transacción comprometida no podrá ser válida.
De esta manera, los otros dos intercambios son similares. De esta manera, Alice y Bob hacen que la ejecución de este contrato dependa de eventos externos (más precisamente, depende de que el oráculo informe sobre eventos externos en forma de una firma), sin necesidad de confiar en la contraparte. Este método se puede utilizar para implementar contratos financieros de diferentes tamaños, como futuros y opciones.
En comparación con otras formas de implementación, la característica más destacada del contrato de registro cauteloso es su privacidad: (1) Alice y Bob no necesitan informar a Carol que están utilizando sus datos, lo cual no afecta en absoluto la ejecución del contrato; (2) Los observadores en la cadena (incluido Carol) tampoco pueden determinar qué sitio web están utilizando Alice y Bob para sus transacciones de contrato, ni siquiera pueden determinar si su contrato es un contrato de apuestas en lugar de un canal de rayos.
IV. Introducción a la aplicación de los términos restrictivos
OP_CTV y Control de congestión
La comunidad de desarrolladores de Bitcoin ha propuesto varias propuestas que pueden clasificarse como cláusulas de restricción. Hasta ahora, la propuesta más destacada es OP_CHECKTEMPLATEVERIFY (OP_CTV), que es conceptualmente simple pero conserva una gran flexibilidad, por lo que es bien recibida por la comunidad de Bitcoin que valora la concisión. La idea de OP_CTV es comprometer un valor hash en el script para restringir que estos fondos solo puedan ser gastados por transacciones representadas por este valor hash; este valor hash compromete la salida de la transacción y la mayoría de los campos, pero no compromete la entrada, solo compromete la cantidad de la entrada.
""Control de congestión" es un buen ejemplo que demuestra las características de OP_CTV. Su escenario de aplicación básico consiste en ayudar a una gran cantidad de usuarios a retirarse de un intercambio (un entorno de confianza) hacia un grupo de fondos; debido a que este grupo de fondos utiliza OP_CTV para planificar la forma en que se gastarán los fondos en el futuro, esto garantiza que los usuarios puedan retirarse del grupo de fondos sin confiar en nadie más, sin necesidad de ayuda de ninguna persona; además, como este grupo de fondos se representa solo como una salida UTXO, se evita tener que pagar una gran cantidad de tarifas de transacción cuando la demanda de transacciones en la cadena aumenta (se reduce de n salidas a 1 salida, y de n transacciones a 1 transacción). Los usuarios dentro del grupo pueden salir del grupo cuando lo consideren oportuno."
Digamos que Alice, Bob, Carol quieren retirar 5 BTC, 3 BTC y 2 BTC de los intercambios, respectivamente. Entonces intercambio puede hacer una salida de 10 BTC con 3 OP_CTV ramas. Supongamos que Alicia quiere retirar dinero, puede usar la rama 1, y la transacción representada por el valor hash utilizado por el OP_CTV de esa rama formará dos salidas, una de las cuales es asignar 5 BTC a Alicia; La otra salida, a su vez, es un grupo, que también usa OP_CTV para comprometerse con una transacción, lo que permite a Bob sacar solo 3 BTC y enviar las 2 BTC restantes a Carol.
Bob o Carol también querrían retirar dinero, y el proceso sería similar. Al hacer retiros, solo podrán utilizar transacciones que pasen por la verificación correspondiente de OP_CTV, lo que significa que solo podrán pagarse a sí mismos la cantidad correspondiente y no podrán retirar fondos de forma arbitraria. Los fondos restantes volverán a entrar en un grupo de fondos bloqueados por OP_CTV, lo que garantiza que, sin importar el orden en que los usuarios realicen los retiros, los usuarios restantes puedan retirarse del grupo sin necesidad de confianza.
En términos abstractos, la función de OP_CTV aquí es planificar la ruta hacia el final de la vida del contrato, de modo que el contrato del fondo de capital aquí pueda mantener su propiedad de salida sin confianza, independientemente de la ruta que tome o del estado en el que se encuentre.
Esta OP_CTV también tiene otro uso muy interesante: "canales de pago unidireccionales ocultos". Supongamos que Alice forma un fondo de inversión de este tipo y garantiza que los fondos pueden retirarse sin confianza a una salida con el siguiente script:
要么，Alice 和 Bob 一起花费它要么，一段时间后，Alice 可以独自花费它
Si Alice no revela a Bob, Bob no sabrá de la existencia de esta salida; una vez que Alice revela a Bob, Bob puede considerar esta salida como un canal de pago unidireccional con límite de tiempo, y Alice puede pagar a Bob de inmediato con los fondos en él, sin tener que esperar la confirmación de la cadena de bloques. Bob solo necesita que Alice publique la transacción prometida en la cadena antes de que ella pueda gastarla.
OP_Vault y la caja fuerte
OP_VAULT es una propuesta de cláusulas restrictivas diseñada específicamente para construir "contratos de bóveda (vaults)".
La bóveda de contratos tiene como objetivo ser una forma más segura y avanzada de custodia autónoma. Si bien los contratos de múltiples firmas actuales eliminan la posibilidad de un único punto de fallo de clave privada, si un atacante realmente obtiene la cantidad umbral de claves privadas, el propietario de la billetera no puede hacer nada al respecto. La bóveda de contratos tiene como objetivo imponer un límite de gasto único para los fondos; al mismo tiempo, cuando se retira utilizando la ruta convencional, la operación de retiro se verá obligada a tener un período de espera; y durante ese período de espera, la operación de retiro puede ser interrumpida por una operación de recuperación de emergencia de la billetera. Con este tipo de contrato, incluso si se viola, el propietario de la billetera puede iniciar una operación de contraataque utilizando la rama de recuperación de emergencia.
En teoría, OP_CTV también puede programar este tipo de contrato, pero hay muchas inconveniencias, una de las cuales es la tarifa: al comprometer la transacción, también se compromete a pagar la tarifa de la transacción. Dado el propósito de este contrato, el intervalo de tiempo para configurar el contrato y retirar fondos seguramente será muy largo, por lo que es casi imposible predecir la tarifa adecuada. Aunque OP_CTV no tiene restricciones de entrada, por lo que se puede aumentar la tarifa aumentando las entradas, todas las entradas proporcionadas se convertirán en tarifas, por lo que no es realista; otra opción es CPFP, es decir, proporcionar tarifas en una nueva transacción al gastar los fondos retirados. Además, el uso de OP_CTV también significa que este tipo de contrato de caja fuerte no se puede retirar en lotes (y, por supuesto, no se puede restaurar en lotes).
OP_VAULT Proposes attempts to solve these problems by proposing new opcodes (OP_VAULT and OP_UNVAULT). OP_UNVAULT is designed for bulk recovery, but we won't mention it for now. The action of OP_VAULT works like this: when we put it on a branch of the script tree, it can be used to promise an operable opcode (such as OP_CTV) without specifying the parameters. When spending this branch, the transaction can input specific parameters but cannot change other branches. Therefore, it does not need to preset fees and can set fees when spending this branch. Assuming this branch also has a timelock, it will enforce a timelock. Finally, because it can only change the branch it is on, the other branches (including the emergency recovery branch) on the new script tree will not be changed, allowing us to interrupt such a withdrawal operation.
Además, hay dos puntos que vale la pena mencionar: (1) La acción del código de operación OP_VAULT es similar a otra propuesta de cláusula de restricción: OP_TLUV; Jeremy Rubin señala correctamente que esto ha dado lugar a cierto grado de "cómputo": OP_TLUV/OP_VAULT compromete un código de operación que permite al usuario pasar parámetros a través de una nueva transacción para actualizar todo el árbol de scripts de hojas; esto ya no es simplemente "verificar los datos entrantes según ciertas condiciones", sino más bien "generar nuevos datos significativos basados en los datos entrantes", aunque las capacidades de cálculo que habilita son relativamente limitadas.
El propuesta completa de OP_VAULT también utiliza algunas propuestas de políticas de mempool (como transacciones en formato v3) para obtener mejores resultados. Esto nos recuerda que el significado de "programación" puede ser más amplio de lo que imaginamos. (Un ejemplo similar es la Transacción Abierta en la Red Nervos Network).
5. Comprender CKB
在上述两个章节中，我们介绍了在一种更为受限的结构（Bitcoin UTXO）上，我们如何用脚本编程出有趣的应用；也介绍了尝试为这种结构加入内省能力的提议。
UTXO, aunque es capaz de programar estas aplicaciones, los lectores también notarán fácilmente sus defectos o áreas que se pueden optimizar, por ejemplo: 01928374656574839201
En realidad, la comunidad de Bitcoin ha propuesto respuestas a estos problemas, que básicamente están relacionadas con una propuesta de Sighash (BIP-118 AnyPrevOut).
Pero si estamos programando en CKB, BIP-118 está disponible ahora mismo (se puede simular esta etiqueta Sighash con capacidad de introspección y verificación de firma dirigida).
A través del estudio de la programación de Bitcoin, no solo aprendemos cómo programar en el formato de "salida de transacción" (qué puede programar CKB), sino que también conocemos los métodos de mejora de estas aplicaciones (cómo podemos utilizar las capacidades de CKB para mejorar estas aplicaciones si las programamos en CKB). Para los desarrolladores de CKB, programar basándose en los scripts de Bitcoin puede considerarse como un material de estudio e incluso una forma de acortar el camino.
A continuación, analizaremos la programabilidad de los distintos módulos de programación de CKB uno por uno. Primero, no consideraremos la capacidad de introspección.
Programabilidad de bloqueo de cálculo programable
Como se mencionó anteriormente, UTXO no se puede programar para realizar cálculos arbitrarios. En cambio, Lock puede hacerlo, lo que significa que Lock puede programar todo lo relacionado con UTXO antes de implementar las cláusulas de restricción, incluyendo pero no limitado a los canales de rayos y DLC mencionados anteriormente.
Además, esta capacidad de cómputo verificable permite que Lock tenga más medios de autenticación disponibles que UTXO, siendo más amplio y flexible. Por ejemplo, podríamos implementar un canal de rayos en CKB en el que una parte utilice firmas ECDSA y la otra utilice firmas RSA.
En realidad, esta es una de las áreas en las que las personas comenzaron a explorar en CKB: utilizar esta capacidad flexible de autenticación de identidad en la custodia autónoma del usuario, logrando así lo que se llama "abstracción de cuentas": la autorización y el control de la validez de las transacciones son muy flexibles y prácticamente no tienen restricciones. En principio, esto combina "múltiples ramas de gasto" con "métodos de autenticación arbitrarios". Ejemplos de implementación incluyen JoyID Wallet y UniPass.
Además, Lock también puede implementar la propuesta eltoo, lo que permite mantener solo la transacción de compromiso más reciente en los canales de pago de Lightning (de hecho, eltoo puede simplificar todos los contratos punto a punto).
Programabilidad de tipo de cálculo programable
Como se mencionó anteriormente, uno de los usos principales de Type es programar UDT. En combinación con Lock, esto significa que podemos implementar canales de pago rápidos con UDT como activo subyacente (así como otros tipos de contratos).
实际上，La separación entre Lock y Type puede considerarse como una mejora en la seguridad: Lock se centra en la implementación de métodos de custodia o protocolos contractuales, mientras que Type se centra en la definición de UDT.
Además, la capacidad de iniciar comprobaciones basadas en la definición de UDT también permite que UDT participe en contratos de manera similar a CKB (UDT es un ciudadano de primera clase).
En el caso de comparar la cantidad de la entrada y la salida de una transacción, el prestatario solo puede usar Bitcoin para pagar la deuda, incluso si tanto el prestatario como el prestamista están dispuestos a aceptar otra moneda (como USDT emitido por el protocolo RGB), la transacción de Bitcoin no puede garantizar que el prestatario pueda recuperar su NFT siempre que devuelva suficiente USDT, ¡porque la transacción de Bitcoin ni siquiera conoce el estado de USDT! (En otras palabras, no se puede construir una transacción condicional de reembolso en USDT).
Si pudiéramos verificar según la definición de UDT, permitiría al prestamista firmar otra transacción de compromiso que permita al prestatario usar USDT para pagar el préstamo. La transacción verificará la cantidad de USDT de entrada y salida, lo que otorgará confianza cero al usuario al usar USDT para pagar.
Revisión: suponiendo que los NFT utilizados como garantía y los tokens utilizados para el reembolso sean emitidos mediante el mismo protocolo (como RGB), el problema aquí puede resolverse. Podemos construir una transacción de compromiso según el protocolo RGB, de modo que la transición de estado del NFT y el reembolso ocurran simultáneamente (vinculando dos transiciones de estado en el protocolo RGB mediante transacciones). Sin embargo, debido a que las transacciones en RGB también dependen de transacciones de Bitcoin, la construcción de esta transacción de compromiso puede presentar cierta dificultad. En resumen, aunque el problema puede resolverse, no se puede lograr que el token sea un ciudadano de primera clase.
接下来我们再考虑内省能力。
Lock 读取其它 Lock s -> Leer otros Lock s
Esto significa que después de la implementación de la propuesta de términos de restricción, todas las posibilidades de programación en los UTXO de Bitcoin estarán limitadas. Esto incluye el contrato de caja de seguridad mencionado anteriormente, así como las aplicaciones basadas en OP_CTV, como el control de congestión.
XueJie mencionó una vez un ejemplo muy interesante: puedes implementar una cuenta de recepción en CKB, y al utilizar esta cuenta como entrada de una transacción, si la celda de salida (utilizando la misma cerradura) tiene una capacidad mayor, entonces esta entrada no necesita proporcionar una firma y no afectará la validez de la transacción. De hecho, sin la capacidad de introspección, esta celda no se puede implementar. Esta cuenta de recepción es muy adecuada como método de recepción para las instituciones, ya que puede consolidar los fondos, aunque su privacidad es deficiente.
Bloquear la lectura de otros tipos s (y Data)
Una aplicación interesante de esta capacidad es el token de capital. Lock determinará si puede utilizar su capacidad en función de la cantidad de tokens en otras entradas, así como a dónde puede gastar esta capacidad (requiere la capacidad de introspección de Lock).
Tipo Leer otros Lock s
No estoy seguro, pero se puede suponer que es útil. Por ejemplo, se puede verificar en el campo "Type" si los bloqueos de entrada y salida de la transacción se mantienen sin cambios.
Leer otros tipos de Type Script (y Data)
集换卡？集齐 n 个 token 可以换取更大的一个 token : )
6. Conclusión
A diferencia de los sistemas de contratos inteligentes programables de computación arbitraria (como Ethereum) que han aparecido anteriormente, Nervos Network ha adoptado una estructura diferente; por lo tanto, la comprensión de esos sistemas de contratos inteligentes anteriores a menudo resulta difícil para comprender la base de Nervos Network. Este artículo presenta un método para comprender la programabilidad de CKB Cell a través de la aplicación de una estructura más restringida, BTC UTXO. Además, utilizando el concepto de "introspección" para comprender la capacidad de "acceso entre contratos" de Cell, podemos clasificar los casos de uso de la capacidad de introspección y determinar sus usos específicos.
Revisado:
Sin considerar la capacidad de acceso cruzado de Cell (es decir, la capacidad introspectiva), se puede considerar que lock s es un Bitcoin con estado y capacidad de programación extrema, por lo tanto, solo con esto se puede programar todas las aplicaciones basadas en Bitcoin.
No consideramos la capacidad de acceso cruzado de las celdas (es decir, la capacidad de introspección), la distinción entre lock s y type s se puede considerar como una mejora de seguridad: divide la definición de activos UDT y los métodos de custodia; además, la implementación de type s (y Data) que expone el estado logra el efecto de que UDT sea un ciudadano de primera clase.
Esto significa algo con el mismo paradigma que "BTC + RGB", pero con una capacidad de programación más fuerte.
Sobre estos usos, este artículo no puede ofrecer muchos ejemplos concretos, pero esto se debe a la falta de comprensión del autor sobre el ecosistema de CKB. Con el tiempo, creo que la gente dedicará cada vez más imaginación para crear aplicaciones que hoy en día resultan difíciles de imaginar.
Gracias
Gracias a Retric, Jan Xie y Xue Jie por sus comentarios durante el proceso de escritura del artículo. Por supuesto, cualquier error en el texto es responsabilidad mía.
Referencias bibliográficas:
5._07_05_introducción_a_ckb__modelo_de_validación_de_programación/
6.（二）Contrato de registro cuidadoso (DLC)
"9."
13._PREGUNTA/discusiones/7