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

As cadeias L3 compatíveis da ADI Chain são rollups de Layer 3 com zero-knowledge que liquidam na ADI Chain (L2), enquanto a L2 liquida na mainnet Ethereum (L1). Permite às instituições operar cadeias independentes por jurisdição ou área de negócio, definindo políticas de conformidade específicas. De acordo com o modelo dual de segurança descrito na visão geral da ADI Chain, a L3 herda garantias criptográficas tanto da L2 como da L1, isolando ambientes de execução e domínios de conformidade do estado partilhado da L2.

Governos, bancos e consórcios industriais beneficiam do princípio “um ecossistema, regras diferentes”: ativos regulados circulam em cadeias dedicadas, aplicações abertas executam noutra L3 ou na L2, e todas as camadas comunicam através de pontes L2.

Onde se insere a L3 na arquitetura da ADI Chain?

A ADI Chain segue uma hierarquia de liquidação de três níveis: L3→L2→L1. As cadeias L3 executam transações localmente e mantêm estados independentes; a L2 (ADI Chain) verifica provas de validade em lote da L3 e armazena as raízes de estado dessas L3; a L1 (Ethereum) valida provas em lote da L2 e finaliza o estado global. Cada camada transmite segurança para a superior através de provas de validade zero-knowledge, impedindo que transições de estado inválidas sejam aceites acima.

Ao contrário da implementação direta de DApps em L2, a L3 oferece isolamento físico de execução: cada L3 opera com Sequencer, Prover e contrato Diamond Proxy próprios, cujos estados não interferem entre si. Múltiplas L3 podem ser implementadas no mesmo ecossistema, partilhando contratos como Bridgehub (registo de cadeias) e StateTransitionManager (STM). O throughput da ADI L2 situa-se entre 2 000–10 000 TPS; múltiplas L3 aumentam a capacidade por aplicação ou jurisdição.

A tabela demonstra que a L3 não atua como cadeia pública autónoma, mas sim como domínio de execução personalizável inserido na ADI L2 e Ethereum L1. A ADI L2, enquanto zkRollup, herda a segurança económica da Ethereum; a L3 acrescenta uma camada de conformidade institucional.

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

Quais são os principais componentes do ecossistema L3?

O ecossistema L3 implementa infraestrutura partilhada na camada de liquidação L2 e contratos específicos e nós operacionais em cada L3. O Bridgehub serve de registo central, mapeando IDs de cadeia para endereços de contrato, encaminhando mensagens entre cadeias e gerindo a configuração do ecossistema. O StateTransitionManager gere o registo de novas cadeias, upgrades de protocolo e parâmetros de verificação partilhados. Cada L3 utiliza um contrato Diamond Proxy com padrão Facet para upgrades modulares, tratando da submissão e verificação de lotes, armazenamento de raízes de estado e gestão de validadores.

Operacionalmente, cada L3 executa um Sequencer, Prover e um conjunto de carteiras Operator (para Commit, Prove e Execute, respetivamente). Na L2, o Prover L2 agrega transações nativas L2 e liquidações L3 em provas submetidas à L1. O Validator Timelock impõe um atraso entre Commit e Execute, permitindo deteção de anomalias.

O design Facet do Diamond Proxy permite atualizar de forma independente a lógica de execução, consulta e gestão. A combinação de registo partilhado na L2 e isolamento de estado em cada L3 distingue a ADI Chain do modelo L2 “cadeia única, múltiplas apps”; na comparação entre ADI Chain, Arbitrum e Base, o suporte nativo L3 e o modelo Bridgehub destacam-se.

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

A ADI Chain L3 suporta modelos geridos pela ADI, operados pelo cliente e híbridos, cobrindo necessidades institucionais desde zero-ops até controlo total.

A implementação de contratos utiliza controlo de acesso por funções: Governor gere upgrades de protocolo, Admin gere emergências, Operator executa Commit em lote, Prove Operator submete provas e Execute Operator executa lotes verificados. A titularidade pode ser transferida para multisig do cliente ou entregue por fases. O padrão é “implementar uma vez, adicionar cadeias incrementalmente”: Bridgehub e STM são implementados ao nível do ecossistema, novas L3 juntam-se como contratos independentes.

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

Como funciona o fluxo Commit-Prove-Execute?

Quando lotes L3 liquidam na L2, passam por Commit, Prove e Execute. O Sequencer empacota transações L3 em lotes; o Operator submete um Commit à L2 com diferenças de estado, dados de implementação de contrato e hashes de mensagens L2→L3 — sem snapshots completos — reduzindo custos de dados.

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

Um ciclo de liquidação consome cerca de 747 000 Gas (Commit ~136 000, Prove ~494 000, Execute ~117 000), pago em $ADI pelas carteiras Operator. Em produção, Provers FRI e SNARK podem correr em paralelo em partições GPU separadas, aumentando throughput de lotes em 15%–20%; um Prover suporta cerca de 15–20 TPS.

Figura 2. Fluxo desde o empacotamento de transações até Commit, Prove e Execute na L2 para um lote L3.

A configuração recomendada do Prover é NVIDIA H200 (140 GB VRAM), com 2 Provers FRI paralelos e 1 SNARK Prover dedicado (~33 GB VRAM). Instituições no modo cliente devem planear clusters GPU e ligações RPC L2 de baixa latência para manter o ritmo de lotes.

Como se propaga a finalidade da L3 para Ethereum?

A confirmação de transações L3 evolui ao longo de L3→L2→L1. Após inclusão pelo Sequencer L3, os utilizadores recebem confirmação soft em segundos e podem utilizar os ativos; esta confirmação depende da honestidade do Sequencer e não tem finalidade criptográfica.

Após Commit do lote na L2, entra em confirmação L2 (minutos). Após Prove e Execute na L2, a raiz de estado L3 é escrita no contrato L2 e não pode ser revertida. O Prover L2 prova o estado L2 — incluindo liquidações L3 — na Ethereum L1; após confirmação dos contratos verificador L1, a cadeia atinge finalidade L1 (horas).

Liquidações grandes ou levantamentos entre cadeias devem aguardar finalidade L2 ou L1; operações diárias podem confiar na confirmação soft. O Validator Timelock introduz atraso configurável entre Commit e Execute para deteção de anomalias.

Que casos de uso são indicados para cadeias L3 compatíveis?

A L3 segue a lógica “isolamento de regras, segurança partilhada”: bancos operam stablecoins soberanas, gestoras de ativos lançam contratos RWA com acesso KYC, governos tokenizam dados por jurisdição. Em modo cliente, a responsabilidade por clusters GPU e listas brancas RPC é do cliente; em modo gerido, a operação é da ADI.

Resumo

As cadeias L3 compatíveis da ADI Chain usam uma arquitetura ZK Rollup L3→L2→L1, permitindo que instituições herdem segurança Ethereum e obtenham domínios de execução independentes com regras de conformidade ajustáveis. Bridgehub e StateTransitionManager dão registo e upgrades partilhados; cada L3 mantém isolamento de estado via Diamond Proxy, Sequencer e Prover independentes. Lotes liquidam na L2 via Commit, Prove e Execute; o sistema Airbender e GPUs (H100/H200) suportam provas de validade; a finalidade propaga-se da confirmação soft L3 para a finalidade criptográfica L2 e L1. Três modelos de implementação cobrem necessidades de stablecoins soberanas, RWAs, pagamentos internacionais e tokenização de dados públicos.

Perguntas Frequentes

O que é uma L3 na ADI Chain?

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

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

A ADI Chain funciona como zkRollup L2 em Ethereum; transições de estado L2 exigem validação de provas ZK por contratos verificador L1 antes de finalização. L3 liquida adicionalmente em ADI L2, formando a cadeia L3→L2→L1. Ativos movem-se entre L1, L2 e L3 via pontes, com segurança económica herdada da Ethereum em cada nível.

A ADI Chain é segura?

A ADI Chain utiliza provas de validade ZK, impedindo aceitação de estados inválidos na L1; lotes L3 também precisam de verificação L2 antes de finalização. O Sequencer dá confirmação soft em segundos; finalidade criptográfica depende de verificação de prova em L2 e L1. Utilizadores e instituições devem considerar riscos residuais em contratos de ponte, gestão de chaves, operação de GPU própria em L3 e o intervalo entre confirmação soft e finalidade L1.

Que modelos de implementação existem para cadeias L3?

A ADI Chain L3 suporta três modelos: gerido pela ADI (ADI gere Sequencer, Prover e contratos), operado pelo cliente (instituição gere nós, GPUs e chaves), e híbrido (governança com cliente, Sequencer e Prover atribuíveis). A escolha depende do equilíbrio entre carga operacional, soberania de controlo e flexibilidade de conformidade.

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

O Sequencer L3 empacota transações; o Operator Commita diferenças de estado na L2; o Prover gera prova de validade ZK via Airbender e submete Prove; após verificação L2, o Execute Operator aciona execução, escrevendo a raiz de estado L3 no contrato e finalizando o lote. As três fases consomem cerca de 747 000 Gas, pagos em $ADI.

Que hardware é necessário para operar um Prover L3?

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