Vitalik propõe uma solução de escalabilidade de segunda camada para vincular projetos
Protocolos L2 DeFi atualmente não podem se comunicar uns com os outros, então Vitalik propôs uma correção.
Em um esforço contínuo para combater o aumento das taxas de transação enquanto cria um ecossistema unificado, o co-fundador da Ethereum, Vitalik Buterin, propôs uma solução para um tipo específico de dimensionamento de rollup cruzado.
A proposta descreve como dois protocolos usando rollups podem se comunicar entre si, mantendo a interconectividade e capacidade de composição.
Rollups são soluções de segunda camada que são essencialmente redes de contratos inteligentes que processam e armazenam dados de transações fora da cadeia principal. No entanto, há vários tipos de rollup diferentes, cada um usando contratos inteligentes exclusivos, como optimistic e zero-knoledge.
Embora vários projetos DeFi tenham implantado rollups de segunda camada, como Loopring e Synthetix, as particularidades dos vários rollups significam que os projetos são incapazes de se comunicarem diretamente entre si na segunda camada.
A proposta de Buterin assume que um rollup pode processar transações simples, enquanto o outro tem suporte total para contratos inteligentes. Já existem propostas para transferências entre dois protocolos habilitados para contratos inteligentes usando rollups.
Para explicar como a proposta funciona, Buterin fornece o exemplo de um intermediário de câmbio hipotético que ele chamou de ‘Ivan’ – onde Ivan tem uma conta ‘IVAN_A’ no rollup A que ele controla totalmente e também tem alguns fundos depositados em um contrato inteligente ‘IVAN_B ‘no rollup B.
O contrato inteligente seria programado para aceitar “memorandos” que incluem dados adicionais de qualquer pessoa que o envie para proteger quaisquer transações futuras. As transações criam uma camada de conexão que mantém os depósitos em todos esses contratos isolados, permitindo que o rollup A envie para o rollup B por meio dessa camada.
Buterin sugeriu que o comportamento funcionaria da seguinte maneira;
“Alice envia uma transação para IVAN_A com N moedas e um memorando ALICE_B. Ivan envia uma transação enviando moedas de TRADE_VALUE * (1 – taxa) por meio de IVAN_B para ALICE_B ”
Ele acrescentou que o pior caso seria se Ivan não mandasse moedas para ALICE_B como deveria.
Abordando o cenário de “pior caso” que poderia surgir como resultado do uso da situação proposta, Buterin enfatizou que Alice ainda seria capaz de esperar até que a transação no rollup A confirmasse, encontre algum caminho alternativo para obter moedas no rollup B para pagar taxas e, em seguida, simplesmente reivindicar os fundos ela mesma.
Respondendo à proposta, Alon Muroch apontou que funcionava de maneira semelhante à forma como os bancos compensam as transações:
“Isso é muito interessante, semelhante a como os bancos compensam as transações entre si. Colocar ativos em lotes em “contas” separadas pode ter limitações, uma solução poderia ser apenas grandes pools em ambas as extremidades e taxas divididas proporcionalmente.”
LEIA MAIS
