CKB联创Jan：什么是L1饥饿问题 L2与L1该如何设计

Compilación: Niebla y Bai Ding, Geek web3

Este artículo es un discurso del co-fundador de Nervos, Jan, en la Conferencia HBS Blockchain+Crypto Club en 2019. El tema se centra en la relación entre Layer2 y Layer1, y propone claramente que la blockchain modular será la dirección correcta. También se aborda el problema del mecanismo de almacenamiento de datos en la blockchain. Al mismo tiempo, Jan plantea un tema interesante: ¿cómo se debe resolver si el surgimiento de Layer2 causa hambre en Layer1?

Como uno de los primeros equipos en apoyar la narrativa de Layer2 y la blockchain modular, las propuestas de Nervos fueron muy visionarias en los años 18 y 19. En ese momento, la comunidad de ETH aún tenía ilusiones poco realistas sobre la Fragmentación, y la narrativa de las cadenas de bloques de alto rendimiento también estaba en un estado de efervescencia, aún sin ser completamente probada.

Pero hoy, en 2024, al mirar los problemas que ETH Layer2 ha expuesto en la práctica, así como las desventajas de la ‘alta cadena pública’ representada por Solana en términos de Descentralización y problemas de confianza, es necesario decir que Jan tenía una visión muy perspicaz hace 5 años. Por interés en Layer2 en sí, ‘geek web3’ ha organizado la conferencia de Jan en forma de texto y la ha publicado aquí. Se invita a los entusiastas de Layer2 de Nervos, ETH y la comunidad BTC a aprender y discutir juntos.

A continuación se muestra el texto original de la conferencia de Jan.

Definición de Layer1 y Layer2

Esta es mi definición de L1 y L2 (red de capa 2), como se muestra en la imagen.

En primer lugar, es importante destacar que Nerovs es solo una red de bloques que se esfuerza por satisfacer las necesidades económicas de descentralización, y no se encarga de resolver ‘todos los problemas’. En nuestra comprensión, la diferencia entre Layer1 y Layer2 radica en la fortaleza del consenso. La red L1 debe tener el consenso más amplio, es decir, un ‘consenso global’. A través de un consenso global sin permisos, cualquier persona en el mundo puede participar en el proceso de consenso de L1, y finalmente, L1 puede servir como un ‘ancla’ para la economía descentralizada. Desde esta perspectiva, podemos llamar a L1 la ‘capa de consenso’.

En comparación, el alcance del consenso en la red L2 puede ser más pequeño, con participantes que pueden ser de un país, una industria, una empresa o institución específica, o incluso una comunidad pequeña. El sacrificio en el alcance del consenso en L2 es un costo que se traduce en avances en otros aspectos, como mayor TPS, menor latencia y mejor escalabilidad, entre otros. Podemos llamar a L2 ‘capa de protocolo’, y a menudo se conecta con L1 a través de puentes cross-chain.

Es necesario enfatizar que no solo estamos construyendo una red L2 para abordar el problema de la escalabilidad de la cadena de bloques, sino porque la arquitectura de capas es la forma más fácil de implementar ‘blockchain modular’. El ‘blockchain modular’ consiste en abordar diferentes tipos de problemas en módulos separados.

Mucha gente ha estado discutiendo el tema de Cumplimiento y regulación en blockchain. Entonces, ¿cómo podemos incorporar Bitcoin o Ethereum en el marco regulatorio existente? Una posible solución puede ser la arquitectura de capas. Añadir directamente la lógica empresarial que cumpla con los requisitos regulatorios en Layer1 puede comprometer la Descentralización y la neutralidad, por lo que la lógica relacionada con Cumplimiento puede implementarse de forma independiente en Layer2.

Layer2 puede ser personalizado según regulaciones o estándares específicos, como establecer una pequeña cadena de bloques con licencia o algo como la red de estado del canal. De esta manera, se logra la conformidad sin afectar la descentralización y neutralidad de Layer1.

Además, también podemos resolver el conflicto entre seguridad y experiencia del usuario a través de la arquitectura escalonada. Por analogía, si quieres asegurar la seguridad de tu Llave privada, debes sacrificar cierta comodidad, y lo mismo ocurre con la cadena de bloques, si quieres garantizar la seguridad absoluta de la cadena de bloques, debes sacrificar algo, como el rendimiento de la cadena, entre otras cosas.

Pero si usamos una arquitectura de capas, podemos buscar la máxima seguridad en la red L1, y sacrificar un poco de seguridad en la red L2 para obtener una mejor experiencia de usuario. Por ejemplo, podemos usar canales de estado en L2 para optimizar el rendimiento de la red, Soltarlatencia. Por lo tanto, el diseño de la capa 2 no es más que un equilibrio entre seguridad y experiencia del usuario.

El contenido anterior naturalmente plantea la pregunta: ¿Puede cualquier blockchain ser considerada como Layer1?

La respuesta es negativa, primero debemos tener claro que la **Descentralización y la seguridad de la red Layer1 están por encima de todo, ** ya que debemos lograr la resistencia a la censura a través de la Descentralización. La búsqueda de la seguridad de Layer1, en última instancia, se debe a que L1 es la raíz de toda la red de Bloquear y el ancla de todo el sistema económico de encriptación.

Bajo estos criterios de evaluación, Bitcoin y Ethereum son sin duda las redes L1 más clásicas, con un alcance de Consenso extremadamente fuerte. Aparte de estas dos, la mayoría de las cadenas de bloques no cumplen con los estándares de L1 y tienen un grado de Consenso más bajo. Por ejemplo, el Consenso de EOS no cumple con los requisitos, por lo que solo puede actuar como una red L2, y algunas de sus reglas solo se aplican a sí misma.

Problemas actuales en la red Layer1

Una vez que se haya definido claramente Layer1, debemos señalar que existen tres problemas en algunas redes L1 existentes, que también existen en cierta medida en BTC y ETH:

1. El problema de la tragedia de los bienes comunes en el almacenamiento de datos

Al usar la cadena Bloquear, debemos pagar una cierta tarifa, pero en el modelo económico de BTC, la estructura de tarifas solo considera el costo de cálculo y el ancho de banda de la red, sin tener en cuenta de manera madura el costo de almacenamiento de datos.

Por ejemplo, los usuarios solo necesitan pagar una vez por el almacenamiento de datos en la cadena, pero el plazo de almacenamiento es permanente, por lo que las personas pueden abusar de los recursos de almacenamiento y poner cualquier cosa en la cadena de forma permanente, lo que finalmente llevará a un aumento cada vez mayor en el costo de almacenamiento para todos los nodos en la red. Esto plantea un problema: cualquier operador de nodo que quiera participar en los costos de esta red verá un aumento máximo.

Suponiendo que el estado / cuenta de datos de una cierta cadena de bloques supera los 1TB, no todos pueden sincronizar fácilmente todo el estado y el historial de transacciones. En este caso, incluso si puede sincronizar todo el estado, es difícil verificar por sí mismo el historial correspondiente de transacciones, lo que debilitará la confianza en la cadena de bloques, y la confianza es precisamente el valor fundamental de la cadena de bloques.

La Fundación ETH ha reconocido este problema y ha incorporado un diseño de arrendamiento de almacenamiento en el EIP-103, pero creemos que esta no es la solución óptima.

En Nervos, hemos propuesto un nuevo modelo de estado llamado “Cell”, que puede considerarse como una extensión de UTXO. En el estado de BTCUTXO, solo puedes almacenar el saldo de BTC, mientras que en Cell puedes almacenar cualquier tipo de datos, y generalizar el “amount” y el valor entero de BTCUTXO como “Capacidad”, para especificar la capacidad de almacenamiento máxima de Cell.

De esta manera, vinculamos la cantidad y el estado del activo nativo en CKB. El espacio ocupado por cualquier celda no puede exceder su límite de capacidad, por lo que el volumen de datos se mantendrá dentro de un rango determinado.

Y nos aseguramos de que el tamaño de los datos de estado no interfiera con los operadores de nodos mediante una tasa de inflación de tokens adecuada. Cualquier persona puede unirse a la red CKB y verificar tanto los datos históricos como la validez del estado final, esta es la solución propuesta por CKB para el problema de almacenamiento en la cadena Bloquear.

2. Problema de hambre de Layer1

Si ampliamos en Layer2 y ** realizamos muchas transacciones en Layer2, inevitablemente reducirá la cantidad de transacciones en Layer1, y las recompensas económicas para los Mineros/Nodos de Layer1 también se reducirán en consecuencia. Esto hará que la motivación de los Mineros/Nodos de Layer1 disminuya, ** lo que a su vez afectará la seguridad de Layer1. ** Esto es lo que se conoce como el problema de hambre en Layer1.

Tomemos un ejemplo extremo, si transferimos todas las actividades comerciales a L2, entonces L1, que es su base, será insostenible. ¿Cómo podemos resolver este problema?

En este sentido, debemos distinguir qué tipos de usuarios hay en la red de blockchain, que en pocas palabras se pueden dividir en Usuarios de Almacenamiento de Valor (SoV user, usuarios de almacenamiento de valor) y Usuarios de Utilidad (usuarios de tipo utilitario).

Tomando CKB como ejemplo, los usuarios de SoV utilizan CKBToken como medio de almacenamiento de valor, mientras que los usuarios de utilidad utilizan Cell para almacenar el estado. Los usuarios de SoV rechazan la dilución de precios causada por la inflación de CKBToken, mientras que los usuarios de utilidad deben pagar tarifas de almacenamiento de estado a Minero, que están directamente relacionadas con la duración y el espacio ocupado del almacenamiento de datos.

Continuaremos emisión nuevos CKBToken en la red para crear una tasa de inflación fija y pagarlos a los Mineros, lo que diluirá el valor de los Tokens en manos de los Usuarios de Utilidad (esto es uno de los tres modos de emisión en el modelo económico de CKB llamado ‘emisión de segundo nivel’, que emite 1.344 mil millones de CKBToken cada año. Puedes obtener más información en ‘Interpretación de Stable++: el protocolo de la primera capa de RGB++ comienza oficialmente’.)

En este proceso, los activos de los usuarios de SOV también se diluyen, por lo que podemos darles una cierta cantidad de subsidio para compensar las pérdidas por inflación (que luego se convierte en la división NervosDAO). Es decir, los ingresos que los Mineros obtienen de la inflación de CKB en realidad son pagados solo por el Usuario de Utilidad. Pronto publicaremos un documento económico sobre la emisión de Tokens CKB, donde se explicarán en detalle los problemas relacionados.

Con base en este diseño tokenómico, Minero puede recibir recompensas incluso si no hay ninguna actividad comercial en la cadena CKB, lo que nos permite ser compatibles con cualquier ‘capa de almacenamiento de valor’ o Layer2. En resumen, resolvemos el problema de la escasez en Layer1 mediante una inflación fija intencional.

3. La falta de primitivas de encriptación

Los usuarios necesitan diferentes primitivas de encriptación para utilizar diferentes métodos de encriptación o diferentes algoritmos de firma, como Schnorr, BLS, etc.

Para convertirse en una cadena de bloques Layer1, se debe considerar cómo interactuar con Layer2. Algunas personas en la comunidad de Ethereum proponen utilizar ZK o Plasma para implementar Layer2, pero ¿cómo se puede realizar la verificación en Layer1 sin primitivas ZK relacionadas?

Además, Layer1 también debe considerar la interoperabilidad con otros Layer1. Tomando Ethereum como ejemplo, algunas personas han solicitado al equipo de Ethereum que precompile la función hash Blake2b como un opcode compatible con EVM. El propósito de esta propuesta es habilitar un puente entre Zcash y Ethereum para que los usuarios puedan comerciar entre ambas. A pesar de que esta propuesta se presentó hace dos años, aún no se ha implementado debido a la falta de primitivas de encriptación correspondientes, lo que ha obstaculizado gravemente el desarrollo de Layer1.

Para resolver este problema, CKB ha construido una Máquina virtual altamente abstracta, es decir, CKB-VM, que es completamente diferente de la Máquina virtual de BTC y el EVM. Por ejemplo, BTC tiene un opcode especial OP_CHECKSIG para verificar la firma secp256k1 en las transacciones de BTC. En cambio, en CKB-VM, la firma secp256k1 no requiere un tratamiento especial, solo necesita ser verificada por un script personalizado o un contrato inteligente.

CKB también utiliza secp256k1 como su algoritmo de firma predeterminado, pero se ejecuta en CKB-VM en lugar de ser un primitivo de encriptación codificado en duro.

El propósito de construir CKB Máquina virtual es mejorar la lenta ejecución de las primitivas de encriptación en otras máquinas virtuales como EVM. La verificación de una sola firma secp256k1 en EVM lleva aproximadamente 9 milisegundos, mientras que en CKB-VM con el mismo Algoritmo, solo lleva 1 milisegundo, lo que supone casi diez veces más eficiencia.

Por lo tanto, el valor de CKB-VM radica en que los usuarios ahora pueden personalizar los primitives de encriptación en él, y la mayoría de ellos son compatibles con CKB-VM, ya que CKB-VM utiliza el conjunto de instrucciones RISC-V, cualquier lenguaje compilado por GCC (GNU Compiler Collection, una colección de compiladores ampliamente utilizada) puede ejecutarse en CKB.

Además, la alta compatibilidad de CKB-VM también mejora la seguridad de CKB. Como los desarrolladores siempre dicen: ‘No implementes tu propia versión de algoritmos de cifrado, siempre lo harás mal’, definir tus propios algoritmos de cifrado a menudo conlleva riesgos de seguridad impredecibles.

En resumen, la red CKB ha resuelto los tres problemas que enfrenta la red L1 que he planteado utilizando varios métodos, por lo que CKB puede considerarse una red de capa 1 calificada.