Como funcionam as blockchains L3 compatíveis com ADI Chain? Modelos de implantação e fluxo de liquidação

As cadeias L3 compatíveis da ADI Chain são Rollups de conhecimento zero de terceira camada que realizam liquidação na ADI Chain (L2), enquanto a L2 liquida na mainnet Ethereum (L1). Instituições podem operar cadeias independentes por jurisdição ou segmento de negócio, definindo políticas de conformidade conforme necessário. Seguindo o modelo de segurança em camadas duplas descrito na visão geral da ADI Chain, a L3 herda garantias criptográficas tanto da L2 quanto da L1, mantendo ambientes de execução e domínios de conformidade isolados do estado compartilhado da L2.

Para governos, bancos e consórcios do setor, a L3 possibilita “um ecossistema, regras diferentes”: ativos regulados circulam em cadeias dedicadas, aplicações abertas funcionam em outras L3 ou na L2, e todas as camadas se conectam via bridging na L2.

Onde a L3 se encaixa na arquitetura em camadas da ADI Chain?

A ADI Chain adota uma hierarquia de liquidação em três níveis: L3→L2→L1. As cadeias L3 executam transações localmente e mantêm estado próprio; a L2 (ADI Chain) verifica provas de validade em lote da L3 e armazena as raízes de estado da L3; a L1 (Ethereum) valida provas em lote da L2 e finaliza o estado global. Cada camada transmite segurança para cima por meio de provas de validade de conhecimento zero, impedindo que transições de estado inválidas sejam aceitas por uma camada superior.

Diferente do deployment de dApps diretamente na L2, a L3 oferece isolamento físico de execução: cada L3 possui Sequencer, Prover e contrato Diamond Proxy próprios, com estados independentes. Múltiplas L3s podem ser implantadas no mesmo ecossistema, compartilhando contratos de infraestrutura como Bridgehub (registro de cadeias) e StateTransitionManager (STM). A L2 da ADI atinge aproximadamente 2.000–10.000 TPS; a adição de múltiplas L3s pode escalar ainda mais a capacidade por aplicação ou jurisdição.

A tabela mostra que a L3 não é uma cadeia pública independente, mas um domínio de execução personalizável aninhado na ADI L2 e na Ethereum L1. A ADI L2, como zkRollup, herda a segurança econômica da Ethereum; a L3 acrescenta uma camada institucional de conformidade adicional.

Figura 1. Posição das cadeias L3 compatíveis da ADI Chain na arquitetura em camadas L3→L2→L1 e relação entre os componentes principais.

Quais são os componentes principais do ecossistema L3?

O ecossistema L3 implanta infraestrutura compartilhada na camada de liquidação L2, além de contratos e nós operacionais específicos em cada L3. O Bridgehub atua como registro central, mantendo mapeamentos de ID de cadeia para endereços de contrato, roteamento de mensagens cross-chain e configuração em nível de ecossistema. O StateTransitionManager gerencia o registro de novas cadeias, upgrades de protocolo e administração de parâmetros de verificação compartilhados. Cada L3 conta com contrato Diamond Proxy no padrão Facet para upgrades modulares, gerenciando submissão e verificação de lotes, armazenamento da raiz de estado e gestão de validadores.

No operacional da L3, cada cadeia executa Sequencer, Prover e um conjunto de carteiras Operator (responsáveis por Commit, Prove e Execute). Na L2, o Prover agrega transações nativas da L2 e liquidações da L3 em provas submetidas à L1. O Validator Timelock impõe atraso entre Commit e Execute, reservando tempo para detecção de anomalias.

O design Facet do Diamond Proxy permite que lógica de execução, consulta e gestão seja atualizada de forma independente. A combinação de registro compartilhado na L2 com estado isolado em cada L3 diferencia a ADI Chain do modelo geral de L2 “cadeia única, muitos apps”; na comparação ADI Chain vs Arbitrum e Base, o suporte nativo a L3 e o modelo Bridgehub são diferenciais importantes.

Quais são os três modelos de deployment para cadeias L3?

A ADI Chain L3 suporta modelos gerenciado pela ADI, operado pelo cliente e híbrido, atendendo desde instituições que buscam zero operação até controle total.

O deployment de contratos usa controle de acesso por papéis: Governor gerencia upgrades de protocolo, Admin lida com emergências, Operator executa Commit em lote, Prove Operator submete provas, Execute Operator executa lotes verificados. A titularidade pode ser transferida para multisig do cliente ou em fases. O ecossistema L3 segue o padrão “deploy once, add chains incrementally”: Bridgehub e STM são implantados uma vez, e novas L3s ingressam como contratos independentes.

No modo operado pelo cliente, o Prover exige GPUs NVIDIA H100 ou H200 (70–140 GB VRAM) e pelo menos 64 GB de RAM; o Sequencer requer 8 núcleos de CPU, 32 GB de RAM e endpoint público de transações. Carteiras Operator devem possuir tokens $ADI como gas na L2 para operações on-chain de Commit, Prove e Execute.

Como funciona o fluxo de liquidação Commit-Prove-Execute?

Quando lotes da L3 são liquidados na L2, passam por Commit, Prove e Execute. O Sequencer agrupa transações da L3 em lotes; o Operator submete uma transação Commit à L2 com diferenças de estado (mudanças em slots de armazenamento), informações de deployment e hashes de mensagens L2→L3 — não snapshots completos — para reduzir custos de dados.

Na fase Prove, o Prover gera uma prova de validade usando o sistema Airbender (pipeline FRI/STARK → FFLONK SNARK), garantindo criptograficamente que as transições de estado obedecem às regras da L3. Na fase Execute, após a L2 verificar a prova, a nova raiz de estado da L3 é gravada no contrato Diamond Proxy e o lote é finalizado.

O ciclo completo consome cerca de 747.000 Gas (Commit ~136.000, Prove ~494.000, Execute ~117.000), com cada fase paga em $ADI pelas carteiras Operator. Em produção, Provers FRI e SNARK podem operar em paralelo em partições de GPU, aumentando o throughput de lotes em 15%–20%; um Prover suporta cerca de 15–20 TPS.

Figura 2. Fluxo do agrupamento de transações até Commit, Prove e Execute na liquidação na L2 para um lote da L3.

A configuração recomendada é NVIDIA H200 (140 GB VRAM), com 2 Provers FRI em paralelo e 1 Prover SNARK dedicado (~33 GB VRAM). Instituições no modo cliente devem planejar clusters de GPU e conexões RPC de baixa latência com a L2 para manter a cadência de submissão de lotes.

Como a finalidade é propagada da L3 para a Ethereum?

As confirmações de transação da L3 evoluem ao longo de L3→L2→L1 conforme a liquidação avança. Após o Sequencer da L3 incluir uma transação em um bloco, usuários recebem confirmação soft em segundos e podem usar os ativos imediatamente; a confirmação soft depende da honestidade do Sequencer e ainda não é criptograficamente final.

Após o Commit de um lote da L3 na L2, ele entra na confirmação L2 (minutos). Após Prove e Execute na L2, a raiz de estado da L3 é gravada no contrato da L2 e não pode ser revertida. O Prover da L2 então prova o estado da L2 — incluindo liquidações da L3 — para a Ethereum L1; após os contratos verificador da L1 confirmarem, toda a cadeia de liquidação atinge a finalidade L1 (horas).

Grandes liquidações ou saques cross-chain devem aguardar a finalidade L2 ou L1; interações cotidianas podem confiar na confirmação soft. O Validator Timelock introduz atraso configurável entre Commit e Execute, reservando tempo para detecção de anomalias.

Quais casos de uso são adequados para cadeias L3 compatíveis?

A L3 segue a lógica de “isolamento de regras, segurança compartilhada”: bancos operam stablecoins soberanas, gestoras de ativos implantam contratos RWA com acesso KYC, governos tokenizam dados por jurisdição. Deployments cliente exigem gestão de clusters de GPU e whitelists de RPC; deployments gerenciados pela ADI transferem as operações para a ADI.

Resumo

As cadeias L3 compatíveis da ADI Chain utilizam arquitetura ZK Rollup em três camadas L3→L2→L1, permitindo que instituições herdem a segurança da Ethereum e obtenham execução independente com regras de conformidade por jurisdição. Bridgehub e StateTransitionManager oferecem infraestrutura compartilhada; cada L3 mantém isolamento de estado via Diamond Proxy, Sequencer e Prover próprios. Lotes são liquidados na L2 via Commit, Prove e Execute; o sistema Airbender e GPUs (H100/H200) suportam geração de provas de validade; a finalidade vai da confirmação soft da L3 à finalidade criptográfica na L2 e L1. Três modelos atendem diferentes necessidades operacionais e de governança, ideais para stablecoins soberanas, RWAs, pagamentos cross-border e tokenização de dados governamentais.

Perguntas Frequentes

O que é uma L3 na ADI Chain?

Uma L3 é um ZK Rollup de terceira camada que liquida na ADI Chain (L2), permitindo que instituições, governos ou consórcios operem cadeias independentes por jurisdição com políticas de conformidade personalizadas. Cada L3 possui Sequencer, Prover e Diamond Proxy próprios, herda segurança dual via L2 e Ethereum, e compartilha a infraestrutura Bridgehub com outras L3s.

Qual é a relação entre ADI Chain e Ethereum?

A ADI Chain opera como um zkRollup L2 sobre a Ethereum; transições de estado em lote na L2 exigem que contratos verificador na L1 validem provas ZK antes da finalização. As cadeias L3 liquidam na ADI L2, formando uma cadeia de provas L3→L2→L1. Ativos circulam entre L1, L2 e L3 via bridges, com a segurança herdada da Ethereum em cada nível.

A ADI Chain é segura?

A ADI Chain utiliza provas ZK, impedindo que estados inválidos sejam aceitos na L1; lotes da L3 também devem passar por verificação na L2 antes da finalização. O Sequencer fornece confirmação soft em segundos; a finalidade criptográfica exige verificação de prova na L2 e L1. Usuários e instituições devem considerar riscos residuais de contratos de bridge, gestão de chaves, infraestrutura de GPU autogerida na L3 e a janela entre confirmação soft e finalidade L1.

Quais modelos de deployment estão disponíveis para cadeias L3?

A ADI Chain L3 suporta três modelos: gerenciado pela ADI (ADI opera Sequencer, Prover e contratos), operado pelo cliente (a instituição opera nós, Prover com GPU e detém as chaves) e híbrido (governança do cliente, Sequencer e Prover configuráveis). A escolha depende do equilíbrio entre operação, soberania e flexibilidade de conformidade.

Como funciona o fluxo Commit-Prove-Execute para lotes L3?

O Sequencer da L3 agrupa transações em lotes; o Operator faz Commit das diferenças de estado na L2; o Prover gera prova ZK via Airbender e submete Prove; após verificação na L2, o Execute Operator executa, gravando a raiz de estado da L3 no contrato e finalizando o lote. As três fases consomem cerca de 747.000 Gas, pagos em $ADI.

Qual hardware é necessário para rodar um Prover L3?

Ambientes de produção exigem GPUs NVIDIA H100 ou H200 com pelo menos 70 GB (140 GB recomendado) de VRAM, 64 GB ou mais de RAM e NVMe SSD para dados de witness. A configuração recomendada inclui 2 Provers FRI em paralelo e 1 Prover SNARK dedicado (~33 GB VRAM), visando 15–20 TPS. O Sequencer requer 8 núcleos de CPU, 32 GB de RAM e endpoint público de transações.