Ir para o conteúdo
Financial Context Wiki

Redes de Layer 2

Guia específico por deployment sobre execução, disponibilidade de dados, validação de estado, liquidação, finalidade, sequenciadores, governança, bridges, taxas e saídas executáveis em Layer 2.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Uma Layer 2 é um protocolo que executa ou coordena atividades fora de uma cadeia-base enquanto depende dela para uma parte definida da validação, disponibilidade de dados, liquidação ou imposição da saída. O rótulo não é um padrão universal. Um rollup que publica dados suficientes e impõe transições de estado por fault proofs ou provas de validade tem premissas de confiança diferentes das de um validium, canal de estado, sidechain, bridge multisig ou livro contábil de exchange, mesmo que todos se apresentem como L2.

Para um deployment específico, verifique o que o contrato L1 realmente aceita, onde ficam os dados de derivação, quem ordena as transações, como um estado inválido é rejeitado, quando um bloco se torna safe ou finalized, quem pode atualizar ou pausar o sistema e se o usuário pode sair sem o operador. Confirmações mais rápidas e taxas menores são propriedades úteis, mas não estabelecem por si só segurança herdada.

Como funciona

  1. Fixe a identidade do sistema: chain IDs da L1 e L2, gênese e fork, stack e versão do rollup, contratos de liquidação e bridge, implementações de proxy, tipo de prova ou jogo de disputa, modo de disponibilidade de dados, sequenciador e referências de bloco. Trate o nome do site e o termo L2 como metadados para descoberta, não como autenticação.
  2. Classifique a arquitetura em eixos separados. Registre ambiente de execução, modelo de ordenação, mecanismo de validação de estado, local dos dados, cadeia de liquidação e caminho de custódia. Optimistic e validity rollups, validiums, canais e sidechains combinam esses eixos de formas distintas; um motor compatível com EVM não torna suas seguranças equivalentes.
  3. Reconstrua o pipeline de estado. Acompanhe envio do usuário, ordenação do sequenciador, execução L2, codificação do batch, publicação de dados, compromisso de estado, contestação por fault proof ou verificação da prova de validade, inclusão L1 e finalidade L1. Verifique se software independente consegue derivar o estado L2 alegado a partir das entradas definidas pelo protocolo.
  4. Separe disponibilidade e liveness. Determine se os dados ficam em calldata ou blobs da L1, em sistema DA externo ou comitê; identifique premissas de retenção e recuperação. Teste indisponibilidade do sequenciador, inclusão forçada, envio alternativo, falha do proponente ou prover, retransmissão de mensagens e o caminho exato de saída ou retirada.
  5. Separe relógios e rótulos de estado. Um bloco confirmado pelo sequenciador ou unsafe pode preceder a publicação de dados; um bloco safe pode preceder a finalidade L1; aceitação de prova, resolução de disputa, maturação da retirada e liberação da bridge podem impor barreiras independentes. Use as definições do deployment, e não um número universal de confirmações ou uma regra fixa de sete dias.
  6. Mapeie controle e economia. Leia administradores de proxy, atrasos de atualização, poderes do security council e guardian, estado de pausa, escalares de taxas, token de gas, capacidade do batch e destinatários das taxas. Mantenha livros separados para execução L2, publicação L1 ou DA, cobranças do operador, taxas da bridge, gas no destino e custo de espera; uma cotação não garante execução.
  7. Concilie os resultados do usuário. Verifique contrato e representação exatos do token, débito na origem, crédito no destino, status do recibo, raízes de estado e mensagem, hashes de bloco safe e finalized, aprovações restantes e um resgate ou saída de mercado executável. Revalide a configuração após cada atualização e não deduza a segurança da bridge do sistema de provas do rollup.

Exemplos detalhados

  • Economia do batch. Um batch contém 2,000 transações com média de 160 bytes após compressão mais 20,000 bytes de framing fixo, totalizando 340,000 bytes. A $0.00002/byte, os dados custam $6.80; somar $4.00 de custo fixo de prova e liquidação resulta em $10.80, ou $0.0054/transaction. Com apenas 200 transações, as mesmas premissas resultam em 52,000 bytes, $1.04 de custo de dados e $5.04 no total, ou $0.0252/transaction. O batching reduz o custo médio somente sob as premissas declaradas de tamanho, utilização e taxas.
  • Capacidade versus throughput efetivo. Uma L2 hipotética permite 60,000,000 gas a cada 2 seconds, portanto sua capacidade é 30,000,000 gas/second. Com 120,000 gas por operação de usuário, o teto mecânico é 250 operations/second; com utilização efetiva de 72%, é 180 operations/second. Isso não mede finalidade, descentralização ou throughput de ponta a ponta, e limites de dados, prova ou sequenciador podem ser atingidos primeiro.
  • Três relógios de status e uma barreira de retirada. Em uma linha do tempo didática no estilo OP, uma transação é confirmada pelo sequenciador às 12:00 UTC, seu batch se torna safe após publicação na L1 às 12:07, e o bloco L1 que a contém se torna finalized às 12:20. Se uma retirada pela bridge for provada às 14:00 e tiver maturação ilustrativa de 7-day, a liberação mais cedo será às 14:00 da semana seguinte, sujeita ao jogo de disputa, pausa e condições da L1. A finalidade da transação L2 às 12:20 não é o mesmo evento que a liberação pela bridge.
  • Valor executável após a bridge. Um usuário deposita 1,000 USDC; uma taxa de protocolo de 2 USDC deixa 998 USDC na L2, enquanto o gas de origem custa $7.50 separadamente. O token recebido tem bid executável de $0.995, impacto de preço de 0.20% e gas de saída de $3, portanto o valor líquido de saída é 998 * 0.995 * (1 - 0.002) - 3 = $988.02398. Em relação a $1,000, o déficit é $11.97602, ou 1.197602%; identidade do token, direito contra a bridge e liquidez importam além do rótulo L2.

Riscos

  • Usar L1, L2, chain ID, deployment, fork ou versão de protocolo errados.
  • Tratar um rótulo comercial L2 como classificação padronizada de segurança.
  • Confundir sidechain, validium, canal ou livro custodial com rollup.
  • Aceitar RPC, explorador, bridge, token ou endereço de contrato falsificados.
  • Censura, equivocação, indisponibilidade ou abuso de ordenação privada do sequenciador.
  • Dados de batch e derivação ausentes ou atrasados.
  • Retenção, falha ou conluio de sistema DA externo ou comitê.
  • Compromissos de estado inválidos ou bug do sistema de provas, jogo ou verifier.
  • Falha de liveness do proponente, prover, challenger ou relayer.
  • Congestionamento, censura, reorganização ou finalidade atrasada da L1.
  • Confundir estados unsafe, safe, finalized, proven e withdrawable.
  • Caminhos de inclusão forçada ou escape pausados, caros ou inutilizáveis.
  • Atualizações imediatas de proxy ou janelas de saída insuficientes.
  • Chaves comprometidas de administrador, guardian ou security council.
  • Falha no escrow da bridge, mapeamento do token, casas decimais ou representação.
  • Omitir da cotação taxas de dados, execução, operador, bridge ou destino.
  • Limites de capacidade, rate limit, congestionamento, slippage ou falta do token de gas.
  • Confundir compatibilidade EVM com regras idênticas de opcode, precompilados ou segurança.
  • Mensagens entre L2 que combinam premissas mais fracas de finalidade, bridge ou dependência.
  • Confundir sucesso da carteira, TPS alto ou taxas baixas com segurança e finalidade econômica.

Erros comuns

  • Toda rede chamada Layer 2 herda toda a segurança do Ethereum.
  • Uma confirmação do sequenciador equivale à finalidade respaldada pela L1.
  • Provas de validade ou fault proofs resolvem automaticamente disponibilidade de dados e censura.
  • O sistema de provas do rollup também garante todos os tokens em bridges e aplicativos.
  • Taxas menores ou TPS maior comprovam descentralização, solvência e uma saída executável.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...