Hacia las piezas de Lego al estilo CKB: Polyjuice en Godwoken

[Lalo]

Antes de que veamos a Godwoken, Polyjuice, u otro tema relacionado a blockchains, empecemos con una historia, sobre las bases de datos.

Décadas atrás, la base de datos SQL nació de la necesidad de una herramienta para una mejor organización de datos. Las propiedades ACID fueron diseñadas para que los datos puedan ser escritos de forma segura y leerlos años después desde la creación original. En esta era, una base de datos solo servía para un numero limitado de personas, y una simple máquina (un mainframe, o un poderoso micro computador en los últimos años) es suficiente para alimentar una sola base de datos.

Gradualmente, las computadoras comenzaron a ser usadas por más personas, La explosión del internet aceleró el proceso. Pronto una simple computadora apenas podrían tener el poder para una base de datos, y las bases de datos distribuidas comenzaron a emerger. Desafortunadamente, el descubrimiento del teorema CAP (imagen 2 de 3 -Consistencia, Disponibilidad, Tolerancia a la partición) presenta a los ingenieros de software un gran desafío. En última instancia, ellos fueron forzados a escoger entre las bases de datos CP y AP. Para una referencia rápida, una simple (aunque unilateral) manera de distinguir entre una base de datos CP a la de una AP es:

• Una base de datos CP garantiza una visión global coherente de todo el sistema distribuido.
• Una base de datos AP, sin embargo, puede dar diferentes vistas para diferentes partes lógicas, o particiones.

Una base de datos AP, fuente: https://kgrvamsi.wordpress.com/2013/05/28/riak-in-depth/

Empezando con Amazon DynamoDB, y el floreciente MongoDB, fue un periodo en el que las base de datos AP recibieron mucho ruido. Todas las personas exclamaban , “¡NoSQL es el futuro! SQL es como un dinosaurio.” Fue una época en donde muchos desarrolladores eligieron las soluciones NoSQL para sus aplicaciones. En ese momento, parecía que el futuro de las bases de datos eran las soluciones particionadas.

Pero esta no es el final de historia. Hubo un avance muy rápido en pocos años, las debilidades en las bases de datos AP comenzaron a surgir: Las diferentes vistas observadas desde diferentes particiones realmente interfieren cuando uno está tomando decisiones en la arquitectura de un sistema.

Por ejemplo, tú eres un desarrollador construyendo sobre una base tradicional SQL, y solo necesitas tomar precaución sobre la lógica en las tablas y las conexiones entre ellas. Puede ser necesario realizar consultas más eficaces de vez en cuando, pero tus datos siempre permanecerán organizados. En una base de datos AP, sin embargo, tu solo estás equipado con un almacenamiento key-value (KV), o de documentos. Necesitas primero diseñar tu esquema, pero aparte de eso tienes que lidiar con escrituras inconsistentes que ocurren desde diferentes particiones de la base de datos. Esto complica significativamente el trabajo requerido por el desarrollador de la aplicación, lo que, en muchos casos, también produce un almacenamiento de datos desordenados.

Incluso mirando en AWS, donde la solución de base de datos CP DynamoDB está viva y se usa hasta el día de hoy, las bases tradicionales SQL siguen siendo muy usadas. Solo en casos especiales, como la lógica del carrito de compras, donde existe una función de combinación especial, Dynamo DB ha ganado una gran adopción. Para la gran mayoría de las aplicaciones que los desarrolladores crean a diario, las bases de datos AP no son una buena opción.

Y ahora llegamos a la tendencia de hoy: NewSQL, el cual mantiene las propiedades ACID del modelo original de SQL, ha ganado popularidad como remplazo de la solución NoSQL en la mayoría de casos de uso. Debido a los requerimientos de diseño, las soluciones de NewSQL se basan principalmente, si no todas, en modelos CP:

• Google Spanner es el producto preparado para el futuro de Google, una base de datos a escala global. Este sigue el diseño CP, destinado a proporcionar una mejor alternativa que BigTable basado en AP.
• CockroachDB y TiDB son modernas base de datos SQL abiertas y distribuidas construidas sobre el modelo CP.
• CitusDB, una famosa base de datos escalable basada en PostgreSQL, está también construida sobre el modelo CP.

Podríamos continuar, pero la tendencia ya es clara: los desarrolladores anhelan los sistemas CP para la productividad. La historia tomó un pequeño desvío hacia AP, pero se corrigió de nuevo a una ruta de CP, debido a su facilidad de desarrollo.

Para esta historia, nosotros podemos aprender, que en última instancia los desarrolladores elegirán al ganador según lo que los haga más productivos.

Ahora te preguntarás: Esta es una historia bastante larga e interesante, pero, ¿Qué tiene que ver con blockchain?

En Nervos, creemos firmemente en una solución en capas. Esta nunca ha sido una preferencia aleatoria, ni nuestro medio para ser cool. Se basa en nuestra amplia experiencia en la industria del software. Las capas nos brindan una forma de establecer los límites, encapsular las complejidades y proporcionar suposiciones.

Si miramos a nuestro alrededor, una gran cantidad de cosas en nuestra industria se basan en capas: las pilas de redes, la infraestructura del compilador, la arquitectura de la CPU y la lista continua. En todas partes de esta industria, así como en muchas otras industrias creadas por la humanidad, vemos capas creadas para ocultar detalles, al tiempo que brindan características a las capas superiores.

Incluso para los que piensan que blockchain es un novel, el uso de capas también presentan una clara diferencia:

• La blockchain principal en una red de capas asegura un vista global de forma consistente en sus transacciones.
• Sin embargo, un diseño blockchain fragmentado proporciona fragmentos diferentes que pueden funcionar de forma independiente.

¿Te suena esto? Una blockchain, si lo piensas, se parece mucho a una base de datos distribuida. Ciertamente, existen diferencias importantes, pero la discusión sobre las capas y fragmentos contrastantes, en nuestra opinión es similar a los que vimos entre las bases de datos CP y AP durante los últimos 10 años: En una blockchain en capas, está agrupando blockchains de capa superiores en función de su lógica, minimizando la necesidad de la comunicación entre blockchains; Mientras que en una blockchain fragmentada, la comunicación entre blockchains es la base de las necesidades de escalado y no se puede evitar.

Con el tiempo, creemos que las capas presentarán beneficios claros para que los adopten todos los desarrolladores de Dapps, al igual que el auge de las bases de datos NewSQL.

Sabemos que muchos de ustedes se han preguntado: ¿Cómo será la solución de capa 2 en Nervos?, entonces nos complace, presentarte 2 proyectos complementarios. La versión inicial de Godwoken, y una revisión completa de Polyjuice.

Godwoken: El Framework Rollup sin permiso

Al día de hoy existen varias soluciones de escalabilidad blockchain en el mundo. Algunas de ellas son los canales de pago, rollups, canales de estado, y plasma, solo por mencionar algunos.

En Nervos tenemos la ambición de soportar a todos, pero prácticamente, tenemos que empezar con uno. Entre las soluciones existentes, el rollup se destaca como el más prometedor, con la menor cantidad de peculiaridades. Como resultado, hemos comenzado nuestro viaje. Más adelante también veremos, que debido al diseño único de CKB, el rollup juega un papel aún más importante que simplemente poner esteroides a los TPS. Basándonos en casi un año de investigación, diseño e implementación, ahora vemos lanzado la versión pública inicial de Godwoken, nuestro framework rollup sin permiso.

Godwoken funciona al tener un conjunto de nodos agregadores que recopilan las transacciones de la capa 2 especialmente diseñadas, luego las empaqueta en una transacción de CKB para ser enviada a la capa 1 y aceptarlas. En este sentido, Godwoken realmente funciona en una capa 2:

• Los nodos agregadores especiales de Godwoken se están ejecutando además de los nodos CKB.
• Se utiliza un formato de transacción de capa 2 especialmente diseñado en lugar del formato de una transacción en CKB.
• Los nodos de Godwoken envían una transacción especial de CKB, que también se puede ver como bloques de capa 2.

A pesar de ser una solución de capa 2, un motivo de diseño importante detrás de Godwoken es que estamos construyendo una solución de capa 2 sin permiso:

• Las transacciones de capa 2 incentivan los nodos agregadores con tarifas de transacción, muy parecidas a las que proporciona la blockchain de capa 1.
• En Nervos CKB, son posibles hacer múltiples implementaciones individuales en Godwoken. Cada implementación es libre de tomar sus propias decisiones. Si una implementación no te satisface, puedes cambiar a otra o incluso iniciar con la tuya.
• Aunque algunas implementaciones pueden crear restricciones adicionales, el núcleo de Godwoken está diseñado para que todos puedan enviar un bloque a la blockchain de capa 2, haciéndolos escalar como una verdadera blockchain de capa 1 sin permiso.

Para mostrarte más sobre los aspectos internos de Godwoken, pronto publicaremos un artículo titulado “La vida de las transacciones en Godwoken”, donde cubriremos más a detalle del diseño e implementación de Godwoken.

Vale la pena mencionar que solo estamos lanzando la primera versión de Godwoken, que se limita a las siguientes opciones de diseño:

• Se utilizará un diseño basado en Rollup Optimistic.
• Un mecanismo de prueba de autoridad controla la emisión de bloques en la capa 2.

Continuaremos mejorando Godwoken con más funciones, que incluirán:

1. Un verdadero mecanismo basado en Proof of Stake para el consenso en la emisión de bloques.
2. Una configuración basada en ZK Rollup.
3. ¡Y más!

Últimamente, nos ha sorprendido que el rollup también está ganando popularidad rápidamente en el mundo blockchain. Nos sentimos honrados de estar sobre los hombros de gigantes y estamos inspirados para realizar un trabajo más diligente aquí, con la esperanza de innovar también en los demás.

Sin embargo, tener un framework rollup solo resuelve la mitad del problema. Una solución que solo puede enviar transferencias de los tokens no será muy útil. En un espacio de blockchain competitivo y en constante crecimiento, a menudo se necesita una solución de contrato inteligente para desbloquear más potencial. Para abordar esta otra mitad del problema, también construimos Polyjuice, que acompañará armoniosamente a Godwoken.

Polyjuice: Una solución de CKB 100% compatible con la EVM de Ethereum

Polyjuice es una solución CKB en Ethereum, lo que significa que deberías poder portar tus Dapps existentes que se ejecutan sobre Ethereum a CKB con un mínimo esfuerzo. Uno de los objetivos del diseño de Polyjuice es ser 100%, o incluso 120% compatible con la EVM, lo que significa:

• Cualquier contrato inteligente basado en Solidity que se ejecute en Ethereum debería poder ejecutarse en Polyjuice.
• Polyjuice puede incluso enviar más funciones que podrían no estar implementadas en Ethereum hoy. Si hay un EIP que se necesita desesperadamente, tal vez Polyjuice puede implementarlo para ayudar a tus dApps.

Ten en cuenta que el diseño de compatibilidad solo se aplica al EVM, Ethereum también tiene RPC de soporte, con los que una aplicación se comunica con la blockchain. Desafortunadamente, no podemos prometer una compatibilidad total con respecto a los RPC, debido a los diferentes diseños entre Polyjuice y Ethereum existentes necesitarán algo de trabajo antes de que puedan implementarse en Polyjuice.

Sin embargo, nos aseguraremos de que a) los contratos inteligentes no necesiten cambios; b) que los conjuntos de RPC se parezcan entre si. También trabajaremos para documentar claramente las diferencias. De esta forma, el esfuerzo de portabilidad se reducirá al mínimo posible. También se crearán integraciones con pw-wallet, por lo que se puede esperar una experiencia perfecta del lado del usuario final.

Es posible que te hayas dado cuenta que lanzamos a Polyjuice en Julio del 2020. La razón por la que no lo mencionamos nuevamente es que hemos revisado completamente a Polyjuice para solucionar el mayor problema: manejar el estado compartido.

Para demostrar el estado compartido, imagina que se ha implementado un contrato inteligente de Ethereum en Polyjuice. En nuestro modelo anterior, uno crearía una célula.

Para llamar a este contrato inteligente, uno necesariamente tiene que crear una transacción CKB que consume la célula del contrato y crear una nueva célula del contrato.

Aquí es donde surge el problema: cuando varios usuarios llaman al mismo contrato inteligente, todos necesitarán consumir y recrear la célula del contrato. Efectivamente, están compitiendo por la célula de estado del contrato compartido. En la mayoría de los casos, los usuarios no conocerían las transacciones que están creando otros; cada uno de ellos crearía una transacción utilizando la célula de estado del contrato más reciente en la blockchain.

Esto dará como resultado que múltiples transacciones consuman la misma célula de estado en el contrato, un minero tendrá que elegir una transacción, lo que invalidará todas las demás transacciones. Esto es una consecuencia del modelo basado en células seleccionado para CKB, pero no necesariamente una desventaja:

• Hay muchos más casos en los que no es necesario un solo estado compartido. sUDT es uno de esos ejemplos. Para estos casos, el modelo basado en células proporciona mejoras como una mayor escalabilidad y determinismo.
• Incluso en los casos en los que un estado compartido es inevitable (como las aplicaciones de votación o AMM), existen soluciones para resolver el problema:

En muchos casos, se puede aprovechar la lógica de reintento simple: se puede crear una regla que diga “siempre que la transacción contenga la entrada 1 y la salida 1 y 2, no me importa cuál sea la entrada 0, solo firme y envíe la transacción”. También se puede adjuntar a la regla un tiempo de espera, como una ventana de 10 minutos. Para dApps de volumen relativamente menor, como una aplicación de votación, esto sería lo suficientemente bueno.

En algunos casos se tiene otros requisitos, como unos requisitos de TPS más altos, que harían inviable la lógica de reintento. El resumen proporciona una respuesta diferente aquí. Al diseñar Polyjuice sobre Godwoken, cada transacción individual de Polyjuice puede ser simplemente una transacción en la capa 2 de Godwoken. De este modo, se evita el problema de estado compartido, ya que solo la transacción de Godwoken CKB empaquetada consumirá la célula de estado del contrato y volverá a crear una nueva y actualizada.

Aquí, Godwoken y Polyjuice se complementan: Polyjuice proporciona una forma de inyectar la lógica personalizada en la solución acumulada de Godwoken, Godwoken resuelve el problema de estado compartido de Polyjuice, al tiempo que proporciona un mayor potencial en TPS. Esperamos que la combinación de Godwoken y Polyjuice pueda ayudar a arrojar algo de luz sobre los diseños de dApps en capas en el jardín de las maravillas de Nervos CKB.

Vale la pena señalar que Polyjuice no es la única solución de VM para Godwoken. También se pueden integrar otras máquinas virtuales, proporcionando diferentes formas de construir dApps. Por ejemplo, una máquina virtual de JavaScript pura es totalmente posible, por lo que uno puede escribir JavaScript simple en una blockchain, o como un objetivo más ambicioso, Libra (ahora llamada diem) en CKB también es totalmente alcanzable con la ayuda de Godwoken.

Para explicar más de cerca los aspectos internos de Polyjuice, también publicaremos un artículo titulado “La vida de una Transacción en Polyjuice” pronto.

Mirando hacia el futuro

En Nervos, queremos atender a 2 grupos diferentes de ingenieros:

1. Para los ocupados artesanos de las aplicaciones, queremos proporcionar una solución integral, para que puedan aprovechar directamente la blockchain de capa 2 alimentada por EVM para enviar lo que quieran. Por ejemplo, ¿Qué pasaría si te dijéramos que Uniswap se puede implementar en CKB con solo una cantidad mínima de ajustes?
2. Para las mentes más aventureras, CKB proporciona las piezas perfectas al estilo Lego, que puedes desmontar y volver a montar. ¿No te gusta escribir contratos inteligentes a través de Solidity? ¿Por qué no construir tu propia máquina virtual en Godwoken para una blockchain de acumulación diferente? ¿Optimistic rollup te suena aburrido? Siente la libertad de sacar eso y cambiarlo por una pieza más desafiante, como ZK Rollup. ¿El mecanismo de PoA suena como una alarma? Simplemente elimina eso y usa tu propia solución PoS o incluso PoW.

En pocas palabras, esperamos que esta nueva implementación de Godwoken / Polyjuice de capa 2 en CKB pueda ser similar a lo que puedas estar acostumbrado con los automóviles: puedes sacarlo del lote (stock) después de haberlo comprado con un distribuidor, o puedes abrirlo para agregar un turbo-compresor para obtener más potencia. Estamos preparados para sorprendernos con todas las modificaciones que termines teniendo con tu “auto” nuevo.

Para mantenerse actualizado sobre todo lo relacionado con Nervos:

Únete a nuestra comunidad: Telegram - Discord - GitHub - Foro - Twitter

Esta es una traducción al español por @luisantoniocrag y revisada por @Lalo