Ethereum todavía está trabajando en un plan complementario para EVM paralelo, pero Bitcoin pronto puede esperar su propia capa 2 de VM paralela.
En primer lugar, comprendamos por qué Ethereum no puede lograr un EVM paralelo.
Para mantener la coherencia y la seguridad de la red, EVM tiene una característica crucial en su diseño: las transacciones se ejecutan de forma secuencial. La ejecución secuencial garantiza que las transacciones y los contratos inteligentes se puedan ejecutar en un orden determinista, lo que facilita la gestión y predicción del estado de la cadena de bloques. Esta elección de diseño prioriza la seguridad, reduciendo las posibles complejidades y vulnerabilidades asociadas con la ejecución paralela. Sin embargo, bajo una gran cantidad de solicitudes de transacciones, esta ejecución secuencial puede provocar congestión y retrasos en la red, similar a una autopista de un solo carril.
¿Es factible simplemente agregar carriles? Hace referencia a soluciones existentes de las llamadas máquinas virtuales paralelas, incluidas cadenas de fragmentación como Near. Estas cadenas propusieron escalar blockchain mediante la introducción de más máquinas virtuales para escalar contratos inteligentes. Básicamente, la carga de trabajo de un contrato inteligente todavía reside en una determinada máquina virtual. Si todos los contratos inteligentes de esta cadena consumen la misma cantidad de TPS, entonces el problema está resuelto. Sin embargo, si solo unos pocos contratos, como los protocolos Aave y Uniswap, consumen más del 90% del espacio del bloque, tener contratos ejecutándose en un solo fragmento significa solo escalar a nivel de cadena sin beneficiarse de las mejoras que aporta el fragmentación. Agregar carriles sin la capacidad de cambiar de carril representa el dilema actual de la paralelización de las máquinas virtuales.
El EVM paralelo implica cortar o almacenar en caché datos en la capa de datos. Sin embargo, limitado por el modelo de programación de EVM, Solidity, como el lenguaje de programación de contratos inteligentes más popular, no puede maximizar el potencial de la arquitectura blockchain paralela. Es como no programar con SQL en la GPU de NVIDIA. La solidez carece de expresiones para arquitecturas paralelas como Relay Execution y carece de una atomicidad final definida para transacciones paralelas.
El verdadero paralelismo en la arquitectura blockchain requiere lograr que las transacciones de un contrato inteligente puedan ejecutarse en múltiples máquinas virtuales simultáneamente. Se necesita un modelo de programación como CUDA para aprovechar plenamente un modelo paralelo en la arquitectura blockchain.
BitReXe menciona que Bitcoin presenta la capa 2 de VM paralela completa de Turing para proporcionar soporte de infraestructura subyacente para aplicaciones reales en el ecosistema de Bitcoin y un modelo de programación exclusivo para VM paralelas, PREDA.
Cómo BitReXe logra Parallel Vms en Bitcoin
VM paralelas
La siguiente ilustración resalta las distinciones entre BitReXe y otras iniciativas que promueven máquinas virtuales paralelas. Como se muestra en el segmento más a la izquierda de la figura, Ethereum se adhiere a un modelo de estado de máquina única, en el que todos los códigos (contratos inteligentes) y estados (datos) son replicados y administrados por cada nodo de blockchain a través de su Máquina Virtual Ethereum (EVM). Los proyectos existentes utilizan EVM paralelas, como se muestra en la sección central de la figura, donde se implementa un único contrato inteligente en una VM dedicada (o VM dentro de un fragmento designado para mantener el consenso). Todas las transacciones relacionadas con el contrato inteligente son procesadas por la VM (o las VM del fragmento de forma totalmente duplicada).
En el modelo de paralelización unificado de BitReXe, como se muestra en el segmento más a la derecha de la figura, todos los contratos inteligentes se implementan en todas las máquinas virtuales de la red. Los estados de un contrato inteligente se dividen y distribuyen entre distintas instancias de VM, lo que garantiza una asignación que no se superponga. En consecuencia, las transacciones del contrato inteligente se segmentan y distribuyen para un procesamiento independiente y paralelo entre las máquinas virtuales. En el caso ideal, este enfoque facilita un escalamiento lineal del rendimiento general de las transacciones y la capacidad estatal con un número cada vez mayor de máquinas virtuales.
El principal desafío radica en gestionar eficientemente las dependencias entre la lógica de ejecución (código) y el estado del contrato (datos), al tiempo que se permite la ejecución independiente de la VM y se evita la sincronización, ya que la lógica de ejecución integral de una transacción puede implicar el acceso a múltiples segmentos de estados del contrato, cada uno de los cuales reside en en máquinas virtuales separadas después de la partición estatal.
enseñar
Presentamos la arquitectura distribuida de ejecución de retransmisión paralela (PREDA), un modelo de programación innovador diseñado para escalar contratos inteligentes en cadenas de bloques de fragmentación, sistemas parachain y cadenas de bloques de capa 2. PREDA admite una arquitectura paralela: si Solidity para Ethereum se compara con un programa en una CPU de un solo núcleo, la arquitectura paralela de PREDA para BitReXe es similar a CUDA para la GPU de NVIDIA.
El modelo PREDA introduce dos componentes clave: (1) "Ámbitos de contrato programables", que permiten a los programadores definir la partición del estado del contrato en función del patrón de acceso a datos de la aplicación, reduciendo el rango de acceso a datos y minimizando la dependencia de datos; y (2) "Retransmisión funcional asíncrona", que permite a los programadores articular la lógica de transacciones con dependencias de datos implícitas para una ejecución flexible en múltiples motores de ejecución (VM). Implementado como un lenguaje extendido de Solidity, PREDA incluye sintaxis adicional para alcances de contrato programables y declaraciones para retransmisión funcional asincrónica.
La figura ilustra la versión PREDA de un contrato ERC20 simplificado. La palabra clave "@address" define el alcance de los saldos de los usuarios, equivalente a la definición del mapa de Solidity, pero especifica estados detallados y separables para la partición por dirección. En tiempo de ejecución, los estados particionados por dirección son administrados por un conjunto de VM en la cadena BitReXe. Diferentes conjuntos de máquinas virtuales no mantienen diferentes estados. La función de transferencia dentro del alcance de "@dirección", invocada por los pagadores (es decir, direcciones de usuario que inician transacciones de transferencia), inicia una "retransmisión" para depositar al beneficiario. Esta retransmisión, ejecutada por una máquina virtual que aloja los estados de dirección del beneficiario, agrega fondos al saldo del beneficiario.
En PREDA, un contrato inteligente puede tener múltiples alcances con variables y funciones definidas. En un ámbito se pueden definir múltiples funciones y variables de tipos arbitrarios, incluidos contenedores. Se pueden iniciar múltiples retransmisiones, condicional o incondicionalmente, en una única llamada de función, lo que permite el inicio recursivo y permite que el flujo de ejecución de transacciones se mueva en múltiples saltos entre diferentes instancias de VM. Este enfoque de ejecución de retransmisión descompone una transacción en múltiples microtransacciones, lo que garantiza un acceso de estado limitado en una única máquina virtual y evita condiciones de carrera. En el contrato inteligente de transferencia PREDA, descomponer la transacción en una microtransacción de “retiro” y una microtransacción de “depósito” permite la ejecución paralela de estos dos tipos de microtransacciones, siempre que sus objetivos (direcciones en este caso) sean asignados a diferentes máquinas virtuales.
BitReXe organiza las máquinas virtuales en múltiples grupos de consenso, cada uno de los cuales ejecuta de forma independiente un protocolo de consenso (basado en PoW en la implementación) para llegar a un consenso sobre las transacciones ejecutadas. Se implementa el consenso entre grupos para mantener la corrección y la coherencia de los retransmisiones funcionales asincrónicas, implementadas como transacciones de retransmisión en BitReXe.
Bitcoin capa 2
El paradigma de emisión de activos en la capa de Bitcoin, como la inscripción, explota constantemente una vulnerabilidad en Bitcoin, dice Luke. Mientras que el dinero nunca duerme, del mismo modo que las inscripciones nunca mueren. Bitcoin necesita desesperadamente una capa 2 verdaderamente escalable que pueda liberar esa presión y evitar que el tamaño del libro mayor crezca demasiado rápido, lo que debilitará la descentralización. Es muy poco probable que se logre ese objetivo con una solución EVM+Bridge.
BitReXe propone VM paralelas y PREDA para escalar bitcoin. Mientras tanto, se adapta a la seguridad de bitcoin. Utiliza BTC como tarifa de gas, comparte la seguridad de Bitcoin y proporciona una liquidación de activos sin confianza entre las dos cadenas.
BitReXe reutiliza la potencia informática de hash de la red Bitcoin, que se transporta mediante bloques en cadena, bloques huérfanos y bloques prematuros como prueba de trabajo para crear bloques válidos en la red de capa 2 sin modificar el protocolo Bitcoin. Los mineros fusionados reciben rxBTC como recompensa, un bitcoin vinculado 1:1 en la red BitReXe. Los usuarios pagan tarifas de gas con rxBTC por transacciones, interacción con contratos inteligentes y otras actividades en cadena. Fullnodes lab, el equipo de desarrollo de PREDA y BitReXe está a punto de presentar una solución puente de liquidación de activos sin confianza entre Bitcoin y BitReXe, donde la vinculación de rxbtc es al mismo tiempo la vinculación de BTC de alguien. Ya no se requieren direcciones oficiales de conexión, por lo que se elimina la suposición de confianza.
Nuestras altas expectativas para el ecosistema de Bitcoin se derivan de su capacidad para resolver problemas que Ethereum –como testnet de Bitcoin– no ha abordado.
@Bit_ReXe cree que este problema se debe a que EVM carece de mecanismos paralelos que conduzcan al trilema de blockchain y pretende resolverlo directamente en la capa 2 de Bitcoin.
Si este problema puede resolverse en Bitcoin, entonces la evaluación comparativa de TVL o incluso superar a Ethereum en más de tres veces en la Capa 2 de Bitcoin presentaría un avance fundamental”.
Esta es una publicación invitada de BitPNova. Las opiniones expresadas son enteramente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
Fuente: Revista Bitcoin
La publicación BitReXe: Habilitación de máquinas virtuales paralelas en la red Bitcoin apareció por primera vez en Crypto Breaking News.
