Este artículo se publicó por primera vez en la cuenta pública de la comunidad china Nervos.
Soy fanático de Linus. Creó un sistema operativo de código abierto que está en todas partes, fue coautor de un libro que me encanta y creó un sistema de control de versiones distribuido que casi todos los desarrolladores usan todos los días.
Empecé a usar Git en el momento en que lo vi y me atrajo su velocidad y elegancia. Los desarrolladores utilizan sistemas de control de versiones [1] para gestionar el código fuente, de modo que puedan realizar un seguimiento de las actualizaciones del código, compartir cambios con amigos y colegas, volver a versiones anteriores sin errores cuando se produzcan nuevos errores y más. Git hace la vida más divertida y espero que CKB pueda hacer lo mismo.
CKB es Git
Nuestro proceso de creación de modelos CKB y Cell se inspiró en Git. Git surgió del deseo de Linus de facilitar el desarrollo del kernel de Linux, y podía usarse siempre que la gente quisiera organizar algo, desde comentarios hasta publicaciones de blog e imágenes. Es una base de conocimientos respaldada por excelentes capacidades de seguimiento del historial.
El repositorio de Git se llama "repositorio" e internamente mantiene una base de datos de objetos inmutable de solo agregar (¿recuerdas eso?). La unidad de almacenamiento básica en Git es un Blob (objeto binario grande), que es un objeto que contiene los datos que las personas almacenan en el repositorio, al igual que una Celda en CKB. Git crea un objeto blob para cada versión de cada archivo. Cada vez que se crea un archivo nuevo, se crea un nuevo blob. Cada vez que se modifica un archivo existente, se crea un blob con contenido nuevo sin modificar el blob antiguo (¿te suena familiar?). Cada blob tiene un hash y el hash del blob se usa como identificador para hacer referencia al blob. Después de trabajar durante unas horas, crea algunos archivos nuevos y modifica algunos archivos existentes, confirma todos los cambios en el repositorio, sincroniza las nuevas confirmaciones con sus colegas y termina el día.
Una confirmación es el punto básico del historial en Git, y el historial de un repositorio consta de una secuencia de confirmaciones desde el origen del repositorio hasta su actualización más reciente. Una confirmación es una versión del repositorio en un momento específico e incluye metadatos de la versión, como el autor, la marca de tiempo, la confirmación anterior y la referencia al árbol de blobs. Al igual que el encabezado del bloque contiene metadatos para cada actualización de la cadena de bloques al escribir la dirección del minero, la marca de tiempo, el hash del bloque principal y la raíz del árbol merkle de transacciones. A usted y a sus colegas se les paga al ampliar el historial de su repositorio Git, al igual que los mineros obtienen recompensas por bloques al ampliar el historial de bloques.
Los repositorios de Git también pueden tener Forks. La gente trabaja en diferentes ramas, pero los mantenedores del repositorio deciden qué rama es "correcta", no por consenso. Git es un sistema distribuido sin consenso que se basa en una comunicación especial entre pares (como ssh o correo electrónico) para el intercambio de datos.
Hay similitudes entre Git y blockchain, lo que también significa que deberíamos ser más cautelosos a la hora de incorporar ideas de Git en blockchain, y no deberíamos introducir opciones de diseño conflictivas en blockchain. Los desarrolladores de blockchain o de contratos inteligentes pueden disfrutar de algunas de las ventajas comprobadas de Git. Así es realmente CKB bajo el capó: el único repositorio Git a gran escala con una verdadera red p2p, consenso global y blobs mejorados, constantemente actualizado por un grupo de personas anónimas.
Esto no es una cadena de bloques
Nombra la celda como quieras
El núcleo de Git y CKB son los objetos de datos (blob/celda) y las referencias hash. Una referencia hash es el nombre inherente de un objeto, una varita mágica que puedes agitar para extraer el valor de los datos. Si conoce el nombre de un objeto, puede hacer referencia a él y así obtener acceso a su poder. En CKB, el código de los contratos inteligentes y los datos del usuario están separados, por lo que las referencias hash le permiten nombrar directamente un fragmento de código o datos del usuario, convirtiéndolos en objetos de primer nivel en el sistema [2]. Esta fina granularidad crea un modelo de programación flexible y potente. Aquí hay unos ejemplos.
Reutilizar código/datos
Debido a que las celdas son unidades de almacenamiento referenciables, reutilizar código/datos en CKB es fácil. Supongamos que hay algún código/datos compartidos almacenados en la celda 0xbee#1(salida 1 de la transacción 0xbeef), para reutilizarlos, primero debe cargar la celda 0xbee#1como dependencia de transacción (cell_deps) y luego leerlo usando la llamada al sistema ckb_load_cell_data Obtenga los datos como se muestra en el script de bloqueo predeterminado. Una vez que los datos de la celda 0xbee#1se cargan en la memoria de la VM, se pueden utilizar como código o datos, según sus necesidades [3]. De esta manera, CKB actúa como una biblioteca compartida de código y datos para que los utilicen los contratos inteligentes que se ejecutan en él. ¿No sería genial si pudiéramos construir un contrato inteligente [4] combinando ladrillos LEGO seguros existentes? En lugar de copiar el código desde algún lugar de GitHub e implementar el mismo código una y otra vez, lo que desperdicia tiempo y espacio en la cadena. Un análisis de los contratos de Ethereum [5][6] muestra que entre el 95% y el 99% de los contratos están duplicados.
Sin miedo a la eliminación de la dependencia
En el ejemplo anterior de reutilización de código/datos, no necesita preocuparse de que alguien modifique el código/datos almacenados en la celda dependiente porque la celda es inmutable, es decir, nadie tiene una forma de modificarla. Pero, ¿qué pasa si el propietario de la celda dependiente la elimina directamente de CKB? ¿Eso hará que mi contrato inteligente sea inutilizable?
De hecho, este es el caso de Ethereum. Si ha estado en este espacio el tiempo suficiente, es posible que esté al tanto del incidente de 2017 que involucró un incidente de 280 millones de dólares [7]. Toda la tragedia fue provocada por la eliminación accidental de un contrato inteligente en Ethereum que fue utilizado por muchos otros contratos inteligentes. Esta eliminación provocó que todos los contratos inteligentes que dependían de él se volvieran disfuncionales y todos los activos almacenados en estos contratos inteligentes se congelaron.
En CKB, tal accidente no tendrá ningún impacto, porque cualquiera que guarde una copia del código (como aquellos que ejecutan un nodo completo o un cliente ligero complejo) puede implementar el mismo código nuevamente en la cadena y el código hash La cita aun es válido. Sólo necesitamos construir la transacción usando la nueva celda de dependencia. Nadie sufrirá y todo seguirá funcionando con normalidad.
De hecho, incluso podemos usar esto intencionalmente para lograr "usar primero y luego implementar" el código. Supongamos que desea utilizar un nuevo script de bloqueo personalizado (contrato inteligente) para proteger sus celdas. A diferencia del proceso habitual de implementación y uso, puede usarlo sin implementar. Solo necesita colocar el código hash del nuevo script de bloqueo (implementación del código) en el bloqueo de celda (uso del código), y luego estas celdas estarán protegidas por el nuevo bloqueo y entrarán en vigencia de inmediato.
La implementación del código de secuencia de comandos de bloqueo real se puede retrasar hasta que desee desbloquear esas celdas. Si desea desbloquear, primero debe implementar el código de secuencia de comandos en la cadena y luego enviar otra transacción para desbloquear estas celdas como de costumbre. Una vez desbloqueada la celda, puede eliminar el código implementado y reclamar los CKBytes ocupados para reducir los costos de almacenamiento innecesarios. El beneficio adicional de usarlo primero y luego implementarlo es una mayor privacidad: nadie sabe cuál es la lógica de este nuevo bloqueo hasta que lo desbloqueas.
CKB evolucionado
Después de comprender las similitudes y ventajas entre CKB y Git, exploremos una pregunta más interesante: si CKB es una biblioteca git, ¿podemos usar CKB para administrar el código de CKB?
¡Sí! Es por eso que algunas funciones principales de CKB, como la verificación de firmas de transacciones [8] y Nervos DAO [9], se implementan en forma de contratos inteligentes. Tomemos como ejemplo la verificación de firmas de transacciones: esta es una característica central de casi todas las cadenas de bloques y está codificada en idiomas nativos (por ejemplo, C en Bitcoin, Go en go-ethereum).
Para actualizar una cadena de bloques, es necesario distribuir e implementar una nueva versión de software (bifurcación blanda/dura) en la mayoría de los nodos, lo que requiere mucha coordinación. Para CKB, la verificación de firmas de transacciones se puede actualizar como otros contratos inteligentes implementando una nueva versión en la cadena. Esto le da a CKB la escalabilidad a largo plazo propuesta por Tezos [10].
Podemos hacerlo mejor. En CKB, cada usuario posee sus propios datos, por lo que un contrato se parece más a un acuerdo entre dos partes entre el usuario y CKB, y los individuos pueden tomar decisiones independientes. Si utiliza un contrato mediante un código hash[11], significa "Acepto esta versión específica del contrato". No tiene que preocuparse de que algún día los desarrolladores actualicen el código del contrato, porque el hash del código del nuevo contrato es diferente y su bloqueo/tipo seguirá haciendo referencia al contrato anterior en lugar del nuevo. Una vez implementada la nueva versión, coexistirá con la versión anterior en el sistema. Si utiliza el contrato del sistema a través de su código hash, la nueva versión no le afectará y podrá decidir si desea actualizar. Si la respuesta es sí, entonces puedes actualizar todas las celdas para usar la nueva versión. En caso negativo, no es necesario hacer nada y continuará utilizando la versión anterior.
Esta es una garantía amigable para los titulares que no están en línea con frecuencia, ya que pueden garantizar que el contrato adjunto a su celular en el momento de la creación no se modificará. Los activos de las personas siempre estarán bloqueados de la manera que especificaron cuando fueron bloqueados. Esta es la máxima garantía para los usuarios de SoV y es lo que diferencia a los activos de CKB de otros activos en la cadena de bloques. Esto es lo mismo que Bitcoin brinda protección a los poseedores "sólo siguiendo las bifurcaciones suaves". El único inconveniente es que corre el riesgo de llegar "demasiado tarde" cuando se trata de actualizaciones de seguridad. Por lo tanto, por conveniencia, es posible que algunas personas prefieran usar siempre la última versión porque confían en el equipo de desarrollo y no necesitan preocuparse por revisar contratos y actualizaciones manuales. En este caso, usarán el tipo id[12]. para hacer referencia al contrato. En términos generales, el tipo id es similar a HEAD en Git, una referencia actualizable siempre apunta a la versión actual. Al proporcionar estas dos opciones (referenciadas mediante código hash y referenciadas por ID de tipo), le devolvemos al usuario el poder de elegir la estrategia de actualización adecuada. Siempre es bueno tener opciones. Podemos tener diferentes opciones y nadie se verá obligado a actualizar.
A largo plazo, CKB se volverá cada vez más abstracto y modular, y se extraerán e implementarán más funciones centrales en contratos inteligentes en cadena. En su forma completa, deberíamos poder actualizar CKB sin pasar por una bifurcación suave o dura. El eslabón que falta es, ¿cómo decidimos nosotros, la comunidad, si actualizamos el contrato del sistema o no, o cuál es el modelo de gobernanza de CKB? Más precisamente, así es como decidimos actualizar el ID de tipo de un contrato de sistema.
Hoy en día, CKB utiliza el mismo modelo de gobernanza fuera de la cadena que Bitcoin, y todavía dependemos de bifurcaciones blandas/duras. Para que cualquiera que use su referencia de identificación de tipo pueda habilitar una nueva versión de los scripts del sistema, se requiere una bifurcación para actualizar la referencia de identificación de tipo para que apunte a la última versión, porque la celda de código está bloqueada por un candado desbloqueable (https:/ /explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga, verifique su código hash). No utilizar bloqueos de firmas múltiples controlados por el equipo central es una elección intencional, ya que las actualizaciones de los scripts del sistema deben seguir las decisiones de gobernanza tomadas por la comunidad.
Como dijimos en nuestro documento técnico de posicionamiento, si bien hay muchas propuestas interesantes, todavía tenemos que ver un modelo de gobernanza práctico. Una vez que encontremos un modelo de gobernanza adecuado, podemos usar "bloqueos de gobernanza" para reemplazar los bloqueos no desbloqueables, permitiendo que los contratos inteligentes del sistema se actualicen con el consentimiento de la comunidad, como los resultados de la votación. Hasta entonces, por el momento nos atendremos al imperfecto modelo de gobernanza fuera de la cadena, pero#CKB La columna vertebral de la gobernanza y la evolución ya existe. $CKB ≠≠
Árbitro:
[1]: https://en.wikipedia.org/wiki/Version_control
[2]: https://talk.nervos.org/t/first-class-asset/405
[3]: https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_helper.h#L40-L66
[4]: https://talk.nervos.org/t/rfc-swappable-signature-verification-protocol-spec/4802
[5]:https://www.researchgate.net/publication/332799463_Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem
[6]: https://security.cse.iitk.ac.in/sites/default/files/17111011.pdf
[7]: https://medium.com/hackernoon/what-caused-the-latest-100-million-ethereum-bug-and-a-detection-tool-for-similar-bugs-7b80f8ab7279
[8]: https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_blake160_sighash_all.c
[9]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/dao.c
[10]: https://tezos.com/
[11]:https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#upgradable-script
[12]:https://docs.ckb.dev/blog/ckbscript-06
