Ethereum ainda está trabalhando em um plano complementar para EVM paralelo, mas o Bitcoin pode em breve esperar sua própria camada 2 de VM paralela.
Vamos primeiro entender por que o Ethereum não consegue alcançar EVM paralelo.
Para manter a consistência e segurança da rede, o EVM possui uma característica crucial em seu design: as transações são executadas sequencialmente. A execução sequencial garante que as transações e contratos inteligentes possam ser executados em uma ordem determinística, facilitando o gerenciamento e a previsão do estado do blockchain. Esta escolha de design prioriza a segurança, reduzindo potenciais complexidades e vulnerabilidades associadas à execução paralela. No entanto, sob altas cargas de solicitações de transação, essa execução sequencial pode levar a congestionamentos e atrasos na rede, semelhantes a uma rodovia de faixa única.
É viável simplesmente adicionar pistas? Referenciando soluções existentes das chamadas VMs paralelas, incluindo cadeias de fragmentação como Near. Essas cadeias propuseram escalar o blockchain introduzindo mais VMs para escalar contratos inteligentes. Essencialmente, a carga de trabalho de um contrato inteligente ainda reside em uma determinada VM. Se todos os contratos inteligentes nesta cadeia consumirem uma quantidade igual de TPS, o problema estará resolvido. No entanto, se apenas alguns contratos, como os protocolos Aave e Uniswap, consumirem mais de 90% do espaço do bloco, ter contratos executados em um único shard significa apenas escalar no nível da cadeia, sem se beneficiar das melhorias trazidas pelo sharding. Adicionar pistas sem a capacidade de trocar de pista representa o dilema atual da paralelização de VMs.
O EVM paralelo envolve cortar ou armazenar dados em cache na camada de dados. No entanto, limitado pelo modelo de programação EVM, o Solidity, como a linguagem de programação de contratos inteligentes mais popular, não pode maximizar o potencial da arquitetura blockchain paralela. É o mesmo que não programar com SQL na GPU da NVIDIA. O Solidity carece de expressões para arquiteturas paralelas como Relay Execution e carece de uma atomicidade final definida para transações paralelas.
O verdadeiro paralelismo na arquitetura blockchain exige alcançar o resultado de que as transações de um contrato inteligente possam ser executadas em várias VMs simultaneamente. Um modelo de programação como CUDA é necessário para aproveitar totalmente um modelo paralelo na arquitetura blockchain.
BitReXe menciona que o Bitcoin introduz a camada 2 de VM paralela completa de Turing para fornecer suporte de infraestrutura subjacente para aplicações reais no ecossistema Bitcoin e um modelo de programação exclusivo para VMs paralelas, PREDA.
Como o BitReXe alcança VMs paralelos no Bitcoin
VMs paralelas
A ilustração a seguir destaca as distinções entre o BitReXe e outras iniciativas que promovem VMs Paralelas. Conforme mostrado no segmento mais à esquerda da figura, o Ethereum adere a um modelo de estado de máquina única, em que todos os códigos (contratos inteligentes) e estados (dados) são replicados e gerenciados por cada nó do blockchain por meio de sua Máquina Virtual Ethereum (EVM). Os projetos existentes utilizam EVMs Paralelos, conforme mostrado na seção central da figura, onde um único contrato inteligente é implantado em uma VM dedicada (ou VMs dentro de um fragmento designado para manter o consenso). Todas as transações pertencentes ao contrato inteligente são processadas pela VM (ou VMs do fragmento de forma totalmente duplicada).
No modelo de paralelização unificado do BitReXe, conforme mostrado no segmento mais à direita da figura, todos os contratos inteligentes são implantados em todas as VMs da rede. Os estados de um contrato inteligente passam por particionamento e distribuição entre instâncias de VM distintas, garantindo alocação não sobreposta. Da mesma forma, as transações do contrato inteligente são segmentadas e distribuídas para processamento independente e paralelo entre VMs. No caso ideal, esta abordagem facilita um escalonamento linear do rendimento geral da transação e da capacidade de estado com um número crescente de VMs.
O principal desafio reside no gerenciamento eficiente das dependências entre a lógica de execução (código) e o estado do contrato (dados), permitindo ao mesmo tempo a execução independente da VM e evitando a sincronização, uma vez que a lógica de execução abrangente de uma transação pode implicar acesso a vários segmentos de estados do contrato, cada um residente em VMs separadas após o particionamento de estado.
ensinar
Apresentamos a Arquitetura Distribuída de Execução de Retransmissão Paralela (PREDA), um modelo de programação inovador projetado para expandir contratos inteligentes em blockchains de fragmentação, sistemas parachain e blockchains de camada 2. PREDA suporta uma arquitetura paralela: se Solidity for Ethereum for comparado a programar em uma CPU de núcleo único, a arquitetura paralela de PREDA para BitReXe é semelhante a CUDA para GPU da NVIDIA.
O modelo PREDA introduz dois componentes principais: (1) “Escopos de contrato programáveis”, permitindo que os programadores definam o particionamento do estado do contrato com base no padrão de acesso aos dados do aplicativo, estreitando a faixa de acesso aos dados e minimizando a dependência dos dados; e (2) “Relé Funcional Assíncrono”, permitindo aos programadores articular a lógica de transação com dependências de dados implícitas para execução flexível em vários mecanismos de execução (VMs). Implementado como uma linguagem Solidity estendida, o PREDA inclui sintaxe adicional para escopos de contratos programáveis e instruções para relé funcional assíncrono.
A figura ilustra a versão PREDA de um contrato ERC20 simplificado. A palavra-chave “@address” define o escopo dos saldos dos usuários, equivalente à definição do mapa do Solidity, mas especifica estados refinados e separáveis para particionamento por endereço. Em tempo de execução, os estados particionados por endereço são gerenciados por um conjunto de VMs na cadeia BitReXe. Diferentes estados não são mantidos por diferentes conjuntos de VMs. A função de transferência dentro do escopo “@address”, invocada pelos pagadores (ou seja, endereços de usuários que iniciam transações de transferência), inicia uma “retransmissão” para depósito ao beneficiário. Essa retransmissão, executada por uma VM que hospeda os estados de endereço do beneficiário, adiciona fundos ao saldo do beneficiário.
No PREDA, um contrato inteligente pode ter múltiplos escopos com variáveis e funções definidas. Múltiplas funções e variáveis de tipos arbitrários, incluindo contêineres, podem ser definidas em um escopo. Múltiplas retransmissões, condicional ou incondicionalmente, podem ser iniciadas em uma única chamada de função, permitindo a iniciação recursiva e permitindo que o fluxo de execução da transação seja movido em vários saltos entre diferentes instâncias de VM. Essa abordagem de execução de retransmissão decompõe uma transação em múltiplas microtransações, garantindo acesso limitado ao estado em uma única máquina virtual e evitando condições de corrida. No contrato inteligente de transferência PREDA, a decomposição da transação em uma microtransação de “saque” e uma microtransação de “depósito” permite a execução paralela desses dois tipos de microtransações, desde que seus alvos (endereços neste caso) sejam mapeados para diferentes máquinas virtuais.
BitReXe organiza máquinas virtuais em vários grupos de consenso, cada um executando independentemente um protocolo de consenso (baseado em PoW na implementação) para chegar a um consenso sobre as transações executadas. O consenso entre grupos é implementado para manter a correção e consistência para retransmissões funcionais assíncronas, implementadas como transações de retransmissão no BitReXe.
Camada 2 de Bitcoin
O paradigma de emissão de ativos na camada Bitcoin, como a inscrição, está constantemente explorando uma vulnerabilidade no Bitcoin, diz Luke. Embora o dinheiro nunca durma, assim como as inscrições podem nunca morrer. O Bitcoin precisa desesperadamente de uma camada 2 verdadeiramente escalonável que possa liberar tal pressão e evitar que o tamanho do livro-razão cresça muito rápido, o que enfraquecerá a descentralização. É muito improvável que tal objetivo seja alcançado por uma solução EVM+Bridge.
BitReXe propõe VMs paralelas e PREDA para dimensionar o bitcoin. Enquanto isso, adapta-se à segurança do bitcoin. Ele usa o BTC como taxa de gás, compartilha a segurança do Bitcoin e fornece uma liquidação de ativos sem confiança entre as duas cadeias.
BitReXe reutiliza o poder de computação hash da rede Bitcoin, que é transportado por blocos on-chain, blocos órfãos e blocos prematuros como prova de trabalho para criar blocos válidos na rede de camada 2 sem modificar o protocolo Bitcoin. Os mineradores de fusão recebem rxBTC como recompensa, um bitcoin indexado 1:1 na rede BitReXe. Os usuários pagam taxas de gás com rxBTC para transações, interagindo com contratos inteligentes e outras atividades na rede. Laboratório Fullnodes, a equipe de desenvolvimento de PREDA e BitReXe está prestes a apresentar uma solução de ponte de liquidação de ativos sem confiança entre Bitcoin e BitReXe, onde o peg-out rxbtc é ao mesmo tempo o peg-in BTC de alguém. Os endereços oficiais de ligação não são mais necessários, portanto, a suposição de confiança é eliminada.
Nossas grandes expectativas para o ecossistema Bitcoin decorrem de sua capacidade de resolver problemas que o Ethereum – como rede de teste do Bitcoin – não abordou.
@Bit_ReXe acredita que esse problema decorre da falta de mecanismos paralelos no EVM que levam ao trilema do blockchain e visa resolvê-lo diretamente na Camada 2 do Bitcoin.
Se esse problema puder ser resolvido no Bitcoin, então o benchmarking da TVL ou mesmo ultrapassar o Ethereum em mais de três vezes na Camada 2 do Bitcoin representaria um avanço fundamental.”
Este é um post convidado da BitPNova. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
Fonte: bitcoinmagazine.com