Una corriente de pensamiento que se ha hecho popular recientemente en el mundo de las criptomonedas es que la única forma de que las cadenas de bloques resuelvan el Trilema de la Escalabilidad, consiguiendo alta seguridad, descentralización y escalabilidad, es adoptar una arquitectura modular o en capas.

Este diseño implica separar la ejecución de transacciones, el consenso y la disponibilidad de datos en capas separadas para lograr un alto rendimiento de las transacciones, sin sacrificar la descentralización y la seguridad. Este tipo de separación de capas no sólo es una idea excelente, sino que, tal como están las cosas actualmente, parece que es la única forma viable de lograr este objetivo.

Por esta razón, muchas plataformas de contratos inteligentes, que fueron diseñadas como monolíticas e inicialmente descartaron este enfoque, han cambiado recientemente de rumbo y han adoptado este camino hacia la escalabilidad. Naturalmente, esto ha planteado una pregunta muy importante: ¿qué papel deben desempeñar las blockchains de Capa 1 en una industria que avanza cada vez más hacia la modularidad?

Si vamos a abordar el trilema de la escalabilidad de la cadena de bloques a través del principio de separación de funciones, entonces, ¿de qué debería preocuparse la Capa 1 ideal en una pila modular de blockchain? Al fin y al cabo, el principio implica separar el software en componentes especializados según su funcionalidad y responsabilidad. Si las cadenas monolíticas han intentado ser expertos en todos los oficios para terminar siendo maestros en ninguno, en las redes en capas, el razonamiento expone que cada capa debe tener su propia especialidad. Entonces, para un Capa 1, ¿cuál debería ser esa especialidad?

Antes de que podamos responder a la pregunta anterior, debemos preguntarnos para qué sirven las cadenas de bloques.

El éxito masivo de Ethereum ha popularizado la idea de los contratos inteligentes como "una computación de propósito general que tiene lugar en una cadena de bloques". Sin embargo, esta idea no siempre fue popular y, para entender cómo surgió, tenemos que empezar con Bitcoin.

La cadena de bloques de Bitcoin se diseñó originalmente con un único propósito: transferir bitcoins de un propietario a otro. Sin embargo, una vez que la red estuvo en funcionamiento, la gente empezó a hacer otras cosas sobre ella, como incluir metadatos en las transacciones para crear nuevos activos y protocolos. Muy pronto empezaron a surgir otros proyectos, como Ripple y Stellar, que buscaban superar las limitaciones de programabilidad y escalabilidad de Bitcoin y dar soporte a una gama más amplia de actividades, como la creación de activos creados por los usuarios, los intercambios descentralizados y las transferencias interbancarias.

Sin embargo, seguían siendo cadenas de bloques para aplicaciones específicas con capacidades bastante limitadas, y después de perder la paciencia al trabajar con el protocolo Mastercoin sobre Bitcoin, Vitalik Buterin, creador de Ethereum, se propuso crear una cadena de bloques única, pública y Turing completa, con programabilidad de propósito general. A finales de 2015 nació Ethereum, que permite a cualquiera crear un contrato inteligente (un programa de propósito general asociado a una pequeña base de datos que solo puede ser modificado por el programa propietario) en la cadena de bloques.

Cuando se crea un contrato inteligente en Ethereum (o en cualquier otra plataforma de contratos inteligentes basada en cuentas), se establece el estado inicial de su base de datos y luego se detiene y permanece inactivo hasta que se le llama. Los usuarios pueden activar el contrato enviándole un mensaje (mediante una transacción). Dependiendo del código interno del contrato, puede hacer todo tipo de cosas, incluyendo activar otros contratos, modificar su base de datos, o enviar varias respuestas a la persona que llama. El punto clave a tener en cuenta aquí es que todos estos pasos se realizan o calculan de forma independiente en cada nodo de la red, con resultados idénticos.

A primera vista, realizar todo tipo de cálculos a través de contratos inteligentes en la cadena de bloques parece una idea muy buena y poderosa. Sin embargo, este concepto se vuelve rápidamente amargo cuando uno empieza a pensar en lo que son realmente las blockchains y lo que se supone que deben hacer.

Resulta que la computación es, por su propia naturaleza, impredecible, lo que significa que es imposible determinar de antemano, simplemente observando el programa, cuál será su resultado o si terminará de ejecutarse una vez desplegado. Esto no funcionaría en una cadena de bloques, donde todos los nodos tienen que estar de acuerdo sobre cada bloque.
Por ello, las plataformas de contratos inteligentes resuelven este problema introduciendo tarifas de transacción o "gas" para la computación. Más concretamente, cada transacción de blockchain establece por adelantado qué cantidad del gas del remitente (normalmente pagado en la moneda nativa de la blockchain) puede gastarse en procesarla. A continuación, la tarifa se gasta gradualmente a medida que el contrato se ejecuta, paso a paso, dentro de la máquina virtual de la plataforma de contratos inteligentes. Supongamos que la transacción se queda sin gas antes de terminar de ejecutarse. En ese caso, se revierte cualquier cambio en la base de datos, lo que significa que no se realizan cambios permanentes en el estado del blockchain, y se consume el gas. De este modo, los usuarios sólo pueden sobrecargar la red en la medida en que estén dispuestos a pagar por ello.

Las plataformas de contratos inteligentes como Ethereum enfrentan otro problema fundamental llamado concurrencia. La concurrencia se refiere a la capacidad de un sistema para procesar diferentes tareas desordenadas o en orden parcial sin afectar el resultado. En el contexto de las cadenas de bloques, una red con buena concurrencia puede procesar muchas transacciones en paralelo, lo que genera grandes beneficios en términos de escalabilidad.

Sin embargo, los contratos inteligentes tienen un desafío en lo que respecta a la concurrencia, porque necesitan acceso al estado global (información almacenada en los otros contratos en la cadena de bloques) para funcionar correctamente. Esto significa que si dos contratos inteligentes se ejecutan simultáneamente y ambos intentan modificar el mismo dato, puede producirse un conflicto. Este problema se conoce como condición de carrera y, para resolverlo, las plataformas de contratos inteligentes deben ejecutar transacciones una a una, en un orden específico. Esta ejecución en serie (opuesta a la ejecución concurrente) garantiza que todas las transacciones se procesen correctamente y de la misma manera y en el mismo orden por todos los nodos, pero también ralentiza significativamente la cadena de bloques porque la red no puede procesar múltiples transacciones al mismo tiempo (esto también aumenta la cantidad de tiempo que le toma a un nuevo usuario sincronizar un nodo).

Estos problemas apuntan a un hecho simple que ha sido bien comprendido en la comunidad altamente técnica de Bitcoin durante años: las cadenas de bloques son terribles para la computación. La razón de esto es simple y está determinada por la naturaleza misma de las cadenas de bloques, que están diseñadas para proporcionar un sistema descentralizado y confiable para verificar transacciones, y no para manejar tareas de computación o almacenamiento de datos a gran escala.

Diferencia entre Computación y Verificación

La computación es un proceso estocástico que implica la ejecución de un conjunto de instrucciones o un programa, que puede ser complejo y requerir cálculos aritméticos, manipulaciones de datos y comparaciones lógicas, lo que exige una potencia de procesamiento significativa. El resultado de un cálculo es un nuevo estado del blockchain basado en las entradas y las reglas definidas en el protocolo o contrato. Por ejemplo, la ejecución de un contrato inteligente puede implicar múltiples operaciones, bucles y comprobaciones de condiciones, que pueden requerir muchos ciclos de CPU y ser costosos desde el punto de vista computacional para los nodos individuales. Además, a menudo es necesario almacenar los resultados de los cálculos, lo que añade una carga adicional a los nodos en cuanto a requisitos de memoria y espacio en disco.

La verificación, en cambio, es un proceso determinista que consiste en comprobar la exactitud o validez de un resultado con respecto a una norma o conjunto de reglas conocidas, lo que consume muchos menos recursos que realizar los cálculos originales. Por ejemplo, verificar la validez de una transacción simple de blockchain implica comprobar una firma digital, y verificar la validez de un bloque implica comprobar si la prueba de trabajo que un minero ha transmitido a la red cumple el objetivo de dificultad actual del protocolo. Ambas son operaciones sencillas que requieren muy pocos cálculos.

La computación compleja de propósito general simplemente no tiene sentido en este paradigma porque las cadenas de bloques descentralizan las cosas mediante replicación, no mediante distribución. Tendría sentido distribuir tareas computacionales pesadas entre los numerosos nodos de la red proporcionándoles diferentes partes de la tarea (ésta era la premisa detrás del escalado mediante “fragmentación”, una idea que mayormente ha caido en desgracia), pero no hacer que calculen la misma cosa en conjunto, que es precisamente lo que hacen las cadenas de bloques. La verificación, por otro lado, tiene sentido porque no requiere muchos recursos y replicar esta tarea en toda la red es la única manera de garantizar la falta de confianza.

Todo esto quiere decir que introducir límites y requisitos de ejecución en serie y de gas para ejecutar transacciones es una forma de limitar artificialmente la complejidad de los cálculos que las cadenas de bloques pueden hacer desde el principio para lidiar con el hecho de que, en primer lugar, no pueden realizar cálculos complejos.

Una Forma Diferente de Pensar en Blockchain

Teniendo en cuenta lo anterior, una forma mejor de pensar en las cadenas de bloques es comparándolas con los tribunales.

Una forma de garantizar que nadie pueda ser defraudado en una transacción sería que todo el mundo hiciera todas sus operaciones ante un tribunal, de forma que un juez imparcial y perfectamente fiable pudiera garantizar que nadie hace trampas ni incumple lo que ha prometido. Sin embargo, si todo el mundo lleva todas sus transacciones a los tribunales, éstos se saturarían ya que no escalan particularmente bien, y las personas tendrían que esperar tiempos inaceptables para que aprueben sus transacciones. Para resolver este problema, la gente podría, en lugar de llevar cada transacción ante los tribunales (toda la red), organizar sus compromisos comerciales con contratos y registros de forma que sólo en caso de disputa tuvieran que acudir al tribunal para resolver sus disputas. De este modo, todos pueden liquidar sus transacciones a tiempo sin saturar el tribunal.

Esta analogía describe perfectamente el funcionamiento de las cadenas de bloques en capas. En lugar de ejecutar y verificar todas las transacciones en una sola capa, las blockchains modulares separan estas funciones en diferentes capas, donde la Capa 1 se utiliza para la verificación y la liquidación final, y la Capa 2 se utiliza para el procesamiento de las transacciones.

En concreto, las cadenas de bloques dependen de los productores de bloques (mineros o validadores) para agrupar las transacciones en bloques. Sin embargo, sin controles ni contrapesos, los productores de bloques malintencionados podrían incluir transacciones fraudulentas en un bloque (por ejemplo, acuñando tokens de la nada). Para evitarlo, las cadenas de bloques se basan en una red de nodos completos que determinan de forma independiente la validez de un bloque antes de agregarlo a su versión de la cadena.

El problema con las cadenas de bloques monolíticas es que el cálculo, ejecución y verificación de transacciones son realizados por las mismas entidades (validadores/mineros, es decir, nodos completos). Cuando un usuario transmite una transacción, un validador o minero la calculará/ejecutará y la incluirá en un bloque. Cuando se crea y propaga el bloque, otros nodos completos lo descargarán y volverán a ejecutar todas las transacciones en el bloque para confirmar que sean válidas. Si el bloque es válido, los nodos honestos lo agregarán a su versión de la cadena de bloques, atestiguando así su validez.

La escalabilidad de las cadenas de bloques monolíticas se ve gravemente limitada por este diseño porque, para aumentar el rendimiento de las transacciones, hay que aumentar el tamaño y/o la frecuencia de los bloques, lo que a su vez eleva los requisitos de recursos de los nodos completos. Procesar bloques más grandes y rápidos requiere más computación, lo que genera costos más altos. A diferencia de los productores de bloques, los nodos completos no son recompensados por sus servicios, lo que significa que no tienen incentivos económicos para incurrir en mayores costes. Esta situación naturalmente lleva a que más participantes de la red opten por no participar y ejecuten nodos ligeros, que no descargan la cadena de bloques completa ni verifican que todas las transacciones anteriores sean válidas, sino que asumen ciegamente que la mayor parte del poder de hash o la participación es honesta. Además, incluso ejecutar nodos ligeros es un escenario optimista, ya que la realidad sobre el terreno muestra que la mayoría de los usuarios de plataformas de contratos inteligentes confían en proveedores RPC centralizados para conectarse a la blockchain en lugar de ejecutar cualquier tipo de nodo ellos mismos.

En resumen, cuando se combinan la producción de bloques (ejecución de transacciones) y la validación, aumentar el rendimiento necesariamente aumenta la centralización de la validación de bloques o los nodos completos, lo que representa un riesgo significativo para la red. Esto contradice el propósito de las cadenas de bloques, que son sistemas que se supone que garantizan la falta de confianza, la resistencia a la censura y la ausencia de permisos a través de la descentralización. Las cadenas de bloques deben permanecer descentralizadas porque los sistemas descentralizados tienen (i) menos probabilidades de fallar, debido a que dependen de muchos componentes separados que operan de forma independiente (resistencia a fallas); (ii) más costosos de atacar, destruir o manipular porque carecen de puntos centrales proclives al fallo; y (iii) son más resistentes a la colusión.

¿Qué Puede Hacer una Capa 1?

Lo bueno de las cadenas de bloques modulares es que pueden disfrutar de todas las ventajas.

Al descargar la ejecución de transacciones casi por completo a la Capa 2, una Capa 1 puede especializarse casi exclusivamente en la verificación y la disponibilidad de datos y aspirar a una alta seguridad y descentralización sin preocuparse por ninguna de las limitaciones que surgen necesariamente cuando se intenta escalar la computación en la Capa 1.

La genialidad del enfoque modular es que mientras la verificación o validación de bloques esté lo suficientemente descentralizada, no es necesario descentralizar el cálculo o la producción de bloques. El tamaño y la frecuencia de los bloques se pueden aumentar, lo que lleva a la centralización en los productores de bloques, pero mientras la verificación esté desacoplada y realizada por diferentes entidades en la Capa 1, los bloques no válidos nunca se agregarán a la cadena.

Esto es precisamente lo que sucede con las soluciones de escalado de Capa 2, como los optimistics rollups y los rollups de conocimiento cero, en los que la tarea de ejecución de transacciones o producción de bloques, que requiere muchos recursos, la realizan entidades centralizadas llamadas secuenciadores que agrupan (o "acumulan") múltiples transacciones fuera de la cadena en grandes lotes antes de enviarlas a la Capa 1 para su validación y liquidación final.

Aunque la verificación de la transacción fuera de la cadena varía según el tipo de rollup, la verificación de las pruebas de fraude o de validez para garantizar la validez de los lotes de transacciones es una tarea que consume muchos menos recursos para los nodos completos de la Capa 1 que la ejecución de las transacciones en su conjunto. Por otro lado, los rollups pueden operar con garantías de seguridad más bajas y optimizar la escalabilidad porque toman prestada la seguridad de la Capa 1 subyacente, donde se consagra el proceso de verificación.

Lo más importante a tener en cuenta aquí es que la validación descentralizada y generalizada de la Capa 1 es extremadamente importante para que todo esto funcione. Supongamos que un poderoso actor malicioso intenta forzar un cambio en el protocolo (por ejemplo, cambiar la emisión del token nativo) y cuenta con el apoyo de la mayoría de los productores de bloques. En ese caso, si nadie más valida la cadena, el ataque puede tener éxito fácilmente, y todos los demás adoptarán la nueva cadena fraudulenta como canónica. Sin embargo, si la mayoría de los usuarios de la cadena de bloques están validando (ejecutando nodos completos), es casi seguro que el ataque fracasará, ya que depende del actor malicioso convencer a los usuarios de que descarguen el parche de software para aceptar el cambio de forma activa.

Por esta razón, es muy importante mantener los requisitos de recursos para ejecutar nodos completos lo más bajos posible para garantizar que los ejecute el mayor número de usuarios posible. La única forma escalable de hacerlo, como ya se ha explicado, es optimizando la Capa 1 para la verificación y descargando la computación a las redes de Capa 2.

En este caso, la Capa 1 no puede hacer demasiado, ya que ello implicaría una mayor complejidad que aumentaría la fragilidad, pero también debe ser lo suficientemente potente como para soportar las redes de Capa 2 situadas encima. Si la Capa 1 permite la publicación y garantiza la disponibilidad de datos para una cantidad suficientemente grande de datos, su capacidad de cálculo puede seguir siendo muy limitada, ya que todo lo demás relacionado con la ejecución puede (y debe) construirse encima.

Estas son precisamente las preocupaciones que la Capa 1 de Nervos, Base Común de Conocimientos (CKB), resuelve gracias a su diseño. Nervos separa el conocimiento descentralizado y la computación para empujar el trabajo pesado fuera de la cadena de base, lo que le permite centrarse en el conocimiento común que necesita consenso global y proporcionar seguridad a las redes de capa 2 en la parte superior.

Para los desarrolladores, Nervos CKB ofrece un motor de liquidación versátil que admite todas las primitivas criptográficas actuales y futuras así como el soporte "suficiente" para las validaciones. Es más expresivo y eficiente como motor de validación y liquidación y es menos probable que introduzca errores que las plataformas de contratos inteligentes de uso general como Ethereum.

Además, el hecho de que las primitivas criptográficas como los algoritmos hash y los esquemas de firma puedan ser importados por los desarrolladores de dApps como si fueran meros plug-ins significa que CKB siempre podrá admitir todo tipo de soluciones de Capa 2 sin necesidad de someterse a duras bifurcaciones para actualizarse y seguir siendo relevante.

CKB optimiza la descentralización y la seguridad al apegarse al mecanismo de consenso más probado en batalla, la Prueba de Trabajo, y resolviendo el problema de la explosión del estado al introducir la renta estatal y vincular el derecho a expandir el estado global al token nativo CKB de la plataforma, donde un CKB equivale a un byte de espacio en la cadena de bloques. Esto último garantiza que los requisitos de recursos para ejecutar nodos completos sigan siendo bajos a largo plazo, asegurando una descentralización duradera de la capa de validación.

Quizás lo más importante es que la economía del protocolo de CKB se diseñó desde el principio para alinearse con la naturaleza de preservación de la plataforma, lo que nos lleva al siguiente punto.

Conceptualmente, las cadenas de bloques tienen la doble función de preservar el valor y realizar transacciones.

Preservar el valor requiere una ocupación a largo plazo del estado global, mientras que las transacciones consumen recursos de ancho de banda y computación instantáneos pero renovables. El problema con las actuales cadenas de bloques de Capa 1 es que ninguna tiene un diseño económico que refleje su naturaleza de preservación. Esto es especialmente preocupante teniendo en cuenta que muchas cadenas de bloques están adoptando actualmente el enfoque de escalado modular o por capas, donde se supone que la mayoría de las transacciones tienen lugar fuera de la cadena, mientras que la capa base sirve principalmente como una capa de liquidación final o una plataforma de almacenamiento de valor.

Más allá de depender de la inflación, los supuestos de seguridad a largo plazo de las actuales cadenas de bloques de Capa 1 dependen de las tarifas de transacción, lo que contradice directamente su objetivo de descargar la mayor parte de la actividad transaccional en las Capas 2 para aumentar el rendimiento y reducir las tarifas de transacción. Esto significa que cuanto más exitosas sean las cadenas de bloques en el escalado fuera de la cadena, menores serán los incentivos para que los mineros o validadores aseguren la cadena a largo plazo.

Más transacciones fuera de la cadena significan un mayor rendimiento pero también recompensas por tarifas de transacción más bajas para los mineros y validadores y, por lo tanto, menos seguridad general en la Capa 1, que irónicamente es el principal módulo de seguridad en la pila. Dado que cualquiera puede crear un motor de ejecución de Capa 2 en cualquier momento, la capa base ya no necesita preocuparse por el cálculo o la ejecución de transacciones, sino por descentralizar la verificación, proporcionar seguridad y almacenar valor.

Esto significa que las cadenas de bloques de Capa 1 deben especializarse en ser plataformas de preservación en lugar de ser plataformas transaccionales, ya que ese es su propósito principal cuando se introducen capas de ejecución adicionales encima. Económicamente, esto significa que los mineros o validadores en la Capa 1 deben ser incentivados y compensados por la preservación del valor a largo plazo, no por el procesamiento puntual de transacciones.

Hasta este punto, CKB es la única Capa 1 que ha sido diseñada desde abajo hacia arriba con el objetivo principal de preservar valor.

El mecanismo periférico que garantiza esto es el modelo de contabilidad Cell, que es una versión generalizada del modelo UTXO. Debido a su funcionamiento, todos los activos (incluidos los tokens no nativos, los NFT y los contratos inteligentes) son ciudadanos de primera clase en la cadena de bloques CKB. Esto significa que se almacenan en cells controladas directamente por los usuarios, en lugar de contratos inteligentes de terceros, como en las cadenas de bloques basadas en cuentas como Ethereum. Esto garantiza que los usuarios tengan control y propiedad directos sobre todos sus activos en CKB, que es una característica necesaria que debe mantener una plataforma de preservación.

Sin embargo, el principal mecanismo que garantiza la naturaleza de preservación de CKB es su modelo tokenómico único y la estructura de incentivos que genera. En concreto, CKB tiene dos tipos de emisión nativa de tokens: la emisión base y la emisión secundaria.

La emisión base funciona exactamente igual que en Bitcoin, reduciéndose a la mitad cada cuatro años hasta que todos los tokens de la emisión base se extraen y se ponen en circulación. Todos los tokens de la emisión base se destinan a los mineros de CKB, que reciben una cantidad fija de tokens CKB por bloque como incentivo por proporcionar los recursos informáticos necesarios para procesar transacciones y proteger la red.

Si bien la emisión base desempeña un papel clave para garantizar la seguridad de la red y la equidad en la distribución inicial de tokens durante la fase de arranque de la red, el mecanismo que realmente garantiza la sostenibilidad a largo plazo de CKB es la emisión secundaria. La emisión secundaria, que no tiene límite y sigue un programa de emisión fijo de 1.344 millones de CKB al año, está diseñada para extraer la renta estatal de los ocupantes estatales a largo plazo y garantizar que los mineros sean compensados por sus servicios de seguridad a perpetuidad, independientemente del volumen histórico de transacciones.

La emisión secundaria se divide entre los mineros, los depositantes de NervosDAO y la tesorería de Nervos, dependiendo de la utilización actual del estado de la cadena de bloques. Supongamos, por ejemplo, que el 60% de los tokens CKB se utilizan para almacenar el estado, el 25% se depositan en el NervosDAO, y el 15% se mantienen líquidos. Entonces, el 60% de la emisión secundaria irá a los mineros, el 25% a los depositantes de NervosDAO, y el 15% a la tesorería (aprende más sobre la tesorería aquí, esta asignación se está quemando actualmente).

Esto significa que debido a que los ocupantes del estado necesitan tener un token CKB por cada byte de datos que desean almacenar en la Capa 1, no pueden depositar los mismos tokens en el refugio contra la inflación de NervosDAO, lo que, a su vez, significa que están constantemente siendo diluidos. Esta dilución tiene un objetivo limitado y solo afecta a los ocupantes estatales, lo que significa que el token CKB actúa efectivamente como un activo hard cap para todos los demás interesados en el sistema.

Nervos utiliza una emisión secundaria porque, como todas las demás redes modulares de cadenas de bloques, está pensada para escalar descargando la ejecución de transacciones fuera de la cadena. Esto significa que, a medida que las recompensas de los mineros de la emisión base disminuyen con cada reducción a la mitad, y cada vez más transacciones se ejecutan fuera de la cadena, CKB no puede confiar sólo en las comisiones por transacción para su seguridad a largo plazo. Dado que su función principal como Capa 1 es prestar seguridad a las capas superiores y servir como capa final de liquidación y disponibilidad de datos, CKB debe financiar su seguridad de una forma que esté alineada con su función de preservación.

El mecanismo de renta estatal, ejecutado mediante emisión secundaria, es exactamente lo que permite a CKB hacer esto. Al introducir inflación dirigida a los ocupantes estatales, CKB puede gravar a los ocupantes estatales a largo plazo y recompensar a los mineros que actúan como preservadores del estado a largo plazo. La estructura de incentivos que surge de esto previene la expansión excesiva del estado y garantiza la seguridad a largo plazo de la cadena de bloques al asegurar una fuente de ingresos predecible para los mineros que es independiente del volumen de transacciones.

En el mundo blockchain, donde todos los caminos conducen hacia la producción concentrada de bloques y la validación de bloques descentralizada, separar estas dos funciones en diferentes capas es la única forma de escalar sin sacrificar la descentralización y la seguridad.

Sin embargo, hacer esto requiere una pila de blockchain modular que se base en una Capa 1 que priorice la preservación y que esté: (i) optimizada para la verificación en lugar de la computación; (ii) sea lo suficientemente potente o flexible y expresiva para admitir todos los tipos de tecnologías de escalado de Capa 2, tanto actuales como futuros; (iii) preparada para el futuro, para garantizar la sostenibilidad a largo plazo sin requerir bifurcaciones duras potencialmente polémicas; (iv) osificada a nivel del protocolo central, otorgando certeza técnica y previsibilidad; y (v) contar con una estructura económica y de incentivos alineada con su carácter preservativo.

Tal como están las cosas actualmente, la Capa 1 de Nervos, Common Knowledge Base, es la única cadena de bloques que irradia todas estas cualidades y está diseñada específicamente para la modularidad desde cero.