- O inventor do Ethereum, Vitalik Buterin, propôs uma solução de cross-rollup que permite o envio de transações entre dois rollups.
- A solução depende de um intermediário para permitir o envio de transações de A para B.
O inventor do Ethereum, Vitalik Buterin, apresentou uma proposta que permitiria a comunicação entre dois protocolos usando soluções de escala de segunda camada conhecidas como rollups. Intitulada “Cross-rollup DEX com contratos inteligentes apenas no lado do destino” a proposta permite que um usuário envie fundos de um rollup para outro no caso de apenas um dos dois usuários ter suporte total de contratos inteligentes e o outro só possa usar “transações simples”.
De acordo com o próprio conceito da Vitalik, os rollups são uma série de transações fora da chain que são agregadas em um contrato inteligente compatível com o Ethereum. Este contrato inteligente permite aos usuários realizar transações com segurança que são então agregadas na chain principal. Entretanto, a solução tem complicações. Os rollups têm tipos diferentes e podem utilizar contratos inteligentes únicos.
Por exemplo, os Rollups Otimistas (ORs) operam com um agregador de transações que utiliza uma pequena quantidade de informações, outros como o ZK-Rollups podem operar sob um esquema à prova de zero-conhecimento. Devido às suas características, é difícil que os rollups interajam entre si.
Como funciona a solução de Buterin?
Em sua proposta, Buterin explica que uma das muitas implementações que sua solução poderia ter, em uma troca descentralizada na qual “Alice”, um usuário que quer trocar moedas usando dois rolos diferentes, e Ivan, o intermediário, interagem. Aqui, é necessário que um dos dois rollups tenha um “campo de memorando” ou permitir o uso de ordens de baixo valor do valor enviado em uma transação como um memorando.
Este intermediário deve ter fundos em ambos os rollups (A e B) contratos inteligentes, portanto, o intermediário é chamado IVAN_A e IVAN_B. A Alice enviará fundos do endereço (ALICE_A) para endereçar IVAN_A usando a primeira das duas soluções de segunda camada. Além disso, o rollup B deve ser capaz de seguir a regra proposta pela Buterin:
Se alguém enviar uma transação enviando moedas TRADE_VALUE para IVAN_A, contendo um endereço DESTINO como memorando, então, após o MIN_REDEMPTION_DELAY bloquear, poderá enviar uma transação para IVAN_B contendo uma prova da transferência, que enfileira uma retirada de moedas TRADE_VALUE para endereçar DESTINO.
Os memorandos permitem a Alice especificar que ela é a destinatária dos fundos que virão de IVAN_B para ALICE_B. Esta receptora receberá os fundos após um período de tempo especificado. Assim, as transações podem ser agrupadas e indexadas de tal forma que correspondam às transações feitas pelo rollup A. Buterin resumiu a operação de sua solução 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 TRADE_VALUE * (1 – taxa) através de IVAN_B para ALICE_B.
Buterin explicou que na “pior das hipóteses” o intermediário pode não enviar as moedas para o endereço da ALICE_B, mas acredita que o usuário pode esperar pelo rollup A para confirmar a transação para “encontrar uma rota alternativa” para enviar seus fundos para o rollup B e “reivindicar ela mesma o fundos” Buterin conclui:
A principal limitação do esquema é que IVAN_B precisa deter uma grande quantidade de capital para garantir que todos os remetentes serão pagos.
