Qué es Nervos Network: CKB, Cells y una capa 1 centrada en la verificación

2026-08-24

La capa base de Nervos Network se llama CKB, abreviatura de Common Knowledge Base. Usa el modelo Cell para el estado on-chain, ejecuta scripts en la CKB-VM compatible con RISC-V y emplea consenso de Proof of Work. Este texto explica funciones documentadas y no es una invitación a actuar respecto de la red o de su activo nativo.

Para entender el ecosistema y los casos de uso de Nervos, el propio Nervos Network y cómo funciona, conviene separar la capa base, el activo nativo de capacidad y las aplicaciones o protocolos que pueden utilizar esa capa. La documentación de Nervos presenta CKB como la base para preservar estado y verificar las reglas vinculadas a ese estado.

La distinción importa porque el nombre de un proyecto, una red, un ticker y una aplicación concreta no son equivalentes. CKB es el CKByte nativo de la capa base, una Cell es un contenedor de estado y un Script es el código que puede restringir el uso de una Cell. El estado actual de una aplicación, herramienta o integración independiente exige sus propias fuentes y su propia revisión on-chain.

¿Qué es Nervos Network?

Nervos Network es el sistema más amplio que rodea a CKB, la Common Knowledge Base. La documentación oficial define CKB como la capa fundacional de Nervos Network y como una blockchain pública y permissionless de capa 1. Su finalidad es ofrecer a otras capas y aplicaciones un entorno seguro y descentralizado para estado y verificación.

Common Knowledge Base describe una arquitectura, no valida cada afirmación que haga una aplicación. La capa base registra y verifica cambios de estado definidos conforme a reglas de consenso, pero no decide si una descripción externa es correcta, si una interfaz es fiable o si una regla de aplicación es sensata. Que el protocolo acepte una transacción no resuelve esas cuestiones por sí solo.

Nervos también se describe como un diseño multicapa. En ese marco, la capa base prioriza seguridad y descentralización, mientras otras capas o protocolos pueden tratar necesidades distintas de ejecución o de aplicación. La división en capas reparte responsabilidades, pero no transmite automáticamente las propiedades de la base a todo producto de una capa superior.

Por ello, una primera respuesta prudente a qué es Nervos Network es que se trata de un sistema alrededor de la capa base programable CKB con Proof of Work. Después hay que identificar qué Cells intervienen, qué Scripts las gobiernan, qué red se menciona y qué documentos oficiales o registros públicos de la cadena respaldan una afirmación concreta.

¿Qué problema aborda Nervos Network?

Una cadena pública debe permitir que participantes independientes comprueben los cambios de estado. Si una regla determina quién puede usar un activo o qué datos reconoce un programa, los nodos necesitan validarla sin confiar en la base de datos de un solo operador. Nervos aborda esa tarea de base con Cells, Scripts, transacciones y consenso Proof of Work, en lugar de tratar toda la lógica de aplicación como un único saldo de cuenta compartido.

El modelo Cell generaliza la idea de una salida no gastada como contenedor de estado. Una Cell puede incluir capacidad, datos y Scripts que fijan condiciones. Una vez incorporada a la cadena, no se edita en el mismo lugar; una actualización válida consume la Cell anterior y crea una o varias Cells nuevas, de modo que la red puede verificar una transición visible de entradas a salidas.

Con ello, la regla de actualización queda explícita. Un programa no sobrescribe un registro de forma silenciosa: la transacción aporta entradas y salidas, y los Scripts asociados evalúan si el cambio está permitido. Esto puede servir para activos, datos o estado específico de una aplicación, pero no elimina la necesidad de comprender las reglas del Script. La validez solo indica que las reglas desplegadas aceptaron la transición.

Proof of Work cubre otra parte del problema: el acuerdo entre participantes distribuidos sobre la historia válida y el orden de las transacciones. Los materiales oficiales de Nervos describen NC-MAX como una evolución del consenso de Nakamoto con un proceso de propuesta y confirmación. Son propiedades de la verificación de la red, no una razón para suponer que cualquier web, etiqueta de dirección o mensaje de aplicación sea auténtico.

¿Cómo funciona Nervos Network?

En términos generales, Nervos representa el estado on-chain reutilizable como Live Cells. Una transacción selecciona Live Cells existentes como entradas y crea nuevas output Cells. Las Cells de entrada se consumen y las de salida pasan a ser el candidato para el estado siguiente. Por eso la pregunta de cómo funciona Nervos Network es más precisa cuando identifica qué Cells se consumen, cuáles se crean y qué Scripts deben aceptar la transición.

Cada Cell tiene capacidad medida en CKBytes y puede contener datos y referencias a Scripts. La documentación oficial explica que un Lock Script asociado controla la propiedad y el acceso a una Cell, mientras que un Type Script puede definir cómo puede utilizarse o modificarse una Cell en una transacción. El primero suele tratar el derecho a consumir una Cell y el segundo puede añadir reglas para un tipo de Cells o un estado de aplicación.

Cuando se envía una transacción, los nodos ejecutan los Scripts pertinentes para sus entradas y salidas. La CKB-VM carga y ejecuta el código al que se refieren los campos Script de la transacción. Un resultado correcto permite esa parte de la verificación; un Script fallido impide que la transacción sea aceptada. Se trata de verificación programable, no de un certificado general de seguridad para cada contrato o interfaz.

La CKB-VM utiliza el conjunto de instrucciones RISC-V. Los documentos de Nervos la describen como el entorno de ejecución de Scripts y señalan el conteo de cycles y límites a nivel de bloque. Para quien no desarrolla, el punto principal es que el protocolo comprueba reglas ejecutables de una transición indicada; para quien revisa, siguen siendo esenciales el code hash exacto, los argumentos, dependencias, datos de transacción y versión de red.

¿Qué papel cumple CKB en Nervos Network?

CKB es el ticker oficial de CKByte, el activo nativo de la capa base de Nervos. La documentación oficial de Nervos indica que un CKByte equivale a un byte de capacidad de almacenamiento de datos on-chain. La capacidad que ocupa una Cell vincula CKB directamente con el almacenamiento de estado, en vez de tratarlo únicamente como una unidad genérica de transferencia.

CKB también tiene una función documentada en las comisiones relacionadas con transacciones y cómputo. Esto vincula el activo al uso de la capa base, pero una función de protocolo no determina un resultado para un titular o una aplicación. Las reglas de red, la necesidad de capacidad, la construcción de la transacción, las versiones de software y las condiciones de un despliegue concreto importan en cada caso.

En el modelo Cell, la capacidad tiene una consecuencia práctica: mientras el estado ocupa bytes, los CKBytes correspondientes quedan asociados a él. Cuando el estado se elimina mediante una transición válida, la capacidad relacionada puede quedar disponible para otro fin. Esto explica por qué CKB aparece tanto en el modelo de almacenamiento como en el de comisiones, pero no sustituye revisar los datos de la Cell y los Scripts de un registro concreto.

CKB es nativo de la capa base de Nervos, por lo que este artículo no inventa una dirección única de token contract. Conviene distinguir el activo nativo de una representación separada que pudiera existir en otro contexto. El primer paso fiable es identificar la red y después verificar la dirección, transacción, Cell o script hash afirmados con la documentación oficial y el CKB Explorer.

Ecosistema de Nervos y casos de uso

Diagrama de Nervos CKB: una transacción consume Live Cells, crea nuevas Cells, ejecuta Scripts en CKB-VM y es verificada por la capa base.

El ecosistema de Nervos y los casos de uso se explican mejor mediante los componentes expuestos por la documentación oficial que mediante una lista cambiante de nombres. La documentación ofrece materiales para Cells, Scripts, SDK, activos y objetos digitales. Un caso de uso tiene sentido concreto cuando identifica la red, la estructura Cell, los Scripts, los datos y la ruta de verificación.

Por ejemplo, una persona desarrolladora puede modelar un activo personalizado o un estado de aplicación mediante Cells y Scripts, mientras una persona usuaria puede encontrarse con una aplicación que se apoya en esas reglas. La capa base verifica la transacción frente a los Scripts asociados. No respalda la finalidad de la aplicación, no garantiza la disponibilidad de su interfaz ni convierte en correcta una afirmación externa solo porque una dirección esté visible en la cadena.

Los materiales oficiales de Nervos también apuntan a proyectos, herramientas, recursos de desarrollo y un Explorer relacionados con CKB. Son puntos útiles para comenzar una investigación, pero no miden uso, seguridad, descentralización o continuidad del servicio. Cada proyecto puede cambiar, operar en una red concreta o emplear otra versión y otro contrato; una afirmación actual sobre una integración requiere evidencia actual y propia de ese proyecto.

Para evaluar un caso de uso declarado, conviene plantear cuatro preguntas: qué Cells guardan el estado relevante, qué Lock Scripts y Type Scripts participan, qué transaction hash o script hash exacto puede revisarse y qué documento oficial enlaza esos registros con la función declarada. Este método es más sólido que deducir una conclusión únicamente del nombre de la red.

¿Cómo se estructura Nervos Network?

La arquitectura oficial sitúa CKB como capa 1 de un sistema multicapa. Proporciona un entorno para estado duradero, consenso y verificación; otros protocolos o aplicaciones pueden abordar necesidades diferentes de ejecución, comunicación o experiencia de uso. Las capas están relacionadas, pero una afirmación sobre una capa no debe trasladarse a otra sin evidencia técnica.

Dentro de la capa base, el modelo Cell, los Scripts, CKB-VM, las transacciones y el consenso tienen funciones distintas. Las Cells representan estado, los Scripts restringen transiciones concretas, la máquina virtual ejecuta los Scripts, la transacción propone la transición y los nodos y mineros participan en la verificación y formación de historial conforme al protocolo de consenso. Separar los papeles ayuda a ubicar dónde puede fallar una afirmación.

El repositorio oficial del nodo CKB describe el software como una implementación pública y permissionless de capa 1, y señala la compatibilidad de CKB-VM con RISC-V. El código fuente accesible resulta valioso para revisión, pero un repositorio visible no es un resultado de auditoría. Hay que relacionar una release concreta, una configuración de red, un binario Script o un despliegue con el objeto exacto del que se habla.

Esta estructura también implica que no existe una respuesta universal sobre la seguridad o utilidad de una aplicación. La respuesta puede depender de calidad del código, dependencias externas, construcción de la transición Cell, vigencia del Script y de que la persona usuaria esté observando la red prevista. El protocolo base ofrece reglas de verificación; una evaluación responsable requiere hechos concretos.

Riesgos y limitaciones

El riesgo central es confundir la validez del protocolo con la seguridad de la aplicación. Una transacción puede satisfacer los Lock Scripts y Type Scripts desplegados mientras el diseño de la aplicación, la interfaz, la interpretación de datos o un servicio externo sigue teniendo un defecto. Los Scripts son programas y pueden contener errores, depender de supuestos o desplegarse con una configuración inesperada.

El estado basado en Cells también exige una lectura cuidadosa. Un saldo de dirección visible no explica por sí solo qué Cells existen, qué datos contienen ni qué Scripts las restringen. Un activo, aplicación o identificador declarado puede usar un nombre conocido y sin embargo apuntar a otra red, Script o estructura de datos. Un registro de Explorer es evidencia útil solo tras comprobar red, dirección o hash y su relación con la documentación oficial.

Los detalles de red y protocolo pueden cambiar con releases o procesos de actualización. La documentación lleva fechas y las fuentes oficiales describen un hard fork como un cambio que requiere que los nodos sigan reglas actualizadas. El comportamiento actual debe comprobarse frente a la release, la red y la documentación técnica fechada pertinentes, no deducirse de un tutorial antiguo o una rama de código no relacionada.

También existen riesgos operativos comunes: sitios engañosos, direcciones copiadas, software sin soporte, servicios no disponibles y documentación incompleta pueden llevar a conclusiones erróneas. Este texto no formula una conclusión de auditoría. Que una página consultada no mencione un problema no demuestra que código, contrato o interfaz concreta haya sido evaluada de forma independiente o vaya a comportarse como se espera.

En esta sección corresponde un incidente de seguridad concreto. En junio de 2025, el puente entre cadenas del proyecto, Force Bridge, fue comprometido por un fallo de control de permisos; las firmas de seguridad y los medios que lo cubrieron situaron la pérdida en un rango de entre unos 3 y 3,9 millones de dólares, y no en una cifra única acordada, e informaron de que los activos sustraídos se cambiaron a ETH y se hicieron pasar por el mezclador Tornado Cash. La operación del puente se detuvo mientras se investigaba. Cuando los informes independientes no coinciden en el tamaño de una pérdida, un perfil debe conservar el rango en lugar de elegir un número.

El incidente también tuvo una consecuencia fuera del protocolo. El 2 de junio de 2025, la Digital Asset eXchange Alliance, la asociación de exchanges surcoreanos con licencia conocida como DAXA, emitió un aviso de precaución sobre CKB tras confirmar que se habían comprometido activos del ecosistema Nervos a través de un puente. Un aviso así es una medida de protección al inversor y no una declaración de conducta indebida, y permite a las plataformas miembro dar pasos adicionales, como marcar el activo como valor de precaución o poner fin al soporte de negociación. Conviene comprobar su estado actual en las plataformas que lo emitieron en lugar de darlo por inalterado.

¿Cómo verificar Nervos Network por tu cuenta?

Empieza por la documentación oficial de Nervos y confirma la fecha, el alcance de la página y la red a que se refiere una afirmación. La documentación establece el vocabulario: CKB es el CKByte nativo, una Cell lleva estado y capacidad y los Scripts definen las reglas de verificación pertinentes. Si una afirmación no puede vincularse a una página oficial, un repositorio o un registro identificable de la cadena, debe tratarse como no verificada.

Para los datos públicos de la cadena, usa el explorador de bloques oficial de CKB y revisa una dirección CKB, un transaction hash, una altura de bloque o un script hash. Compara la red exacta, el identificador, las entradas y salidas de la transacción y los detalles mostrados de Cell o Script con la documentación. Es una ruta de solo lectura que no exige firma ni envío de transacciones.

Como CKB es nativo de la capa base de Nervos, no debe suponerse que una dirección de contrato en una página promocional represente CKB nativo. Primero determina si la afirmación se refiere a la red CKB o a una representación separada en otro entorno, y después compara los identificadores exactos con el Explorer oficial y la documentación. Lo importante es comprobar toda la cadena de evidencia, no solo un nombre parecido.

Para afirmaciones de software o protocolo, usa el repositorio oficial de Nervos Network y relaciona la rama, release, versión de documentación y red. Los cambios y avisos de seguridad deben leerse en contexto. El repositorio oficial es una fuente fiable de código publicado, pero por sí solo no prueba que un sitio externo ejecute el mismo código ni que un despliegue concreto no tenga defectos.

Conclusión

Nervos Network se entiende mejor a través de la capa base CKB centrada en la verificación. Combina consenso Proof of Work, un modelo Cell para estado, Scripts que controlan transiciones y una máquina virtual compatible con RISC-V que ejecuta esos Scripts. El diseño explica con precisión cómo se verifica una transición de estado, pero no convierte toda afirmación de una aplicación en un hecho establecido.

CKB es el activo nativo CKByte. Sus funciones documentadas incluyen aportar capacidad de almacenamiento y cubrir comisiones relacionadas con transacciones y cómputo. Estas funciones explican el vínculo de CKB con el modelo de estado, pero no responden si una aplicación, interfaz o representación separada concreta es fiable. Antes de basarse en una afirmación, conviene comprobar red, Cells, Scripts, identificadores, documentos oficiales actuales y el explorador de bloques oficial.

Páginas de mercado relacionadas

Páginas de Bitbase para los tokens mencionados en este artículo:

- CKB: Ver el precio · Mercado de contratos perpetuos

Lecturas relacionadas

Otros artículos de Bitbase sobre este tema:

- Métricas on-chain de suministro y beneficio

- Sentimiento y actividad de los desarrolladores

- ¿Qué es la minería de criptomonedas?

Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. Explica qué hace un proyecto y qué papel cumple su token dentro de ese sistema; no constituye asesoramiento de inversión, negociación, fiscal ni financiero, ni supone una recomendación o un respaldo de ningún proyecto o token. Bitbase no ha realizado una diligencia debida sobre el proyecto descrito aquí, y mencionarlo no significa que Bitbase liste o respalde el activo. Los criptoactivos conllevan un riesgo significativo, incluida la volatilidad del precio, la baja liquidez, los fallos de los contratos inteligentes, la incertidumbre regulatoria y la posible pérdida total de su valor. Redactado en agosto de 2026; el estado del proyecto, la tokenómica, el equipo y los contratos pueden cambiar en cualquier momento. Verifícalo todo por tu cuenta a través de los canales oficiales, la dirección del contrato y un explorador de bloques, y desconfía de los sitios que imitan al proyecto y de los enlaces de phishing.