Saltar al contenido
Financial Context Wiki

Redes de Layer 2

Guía específica de cada despliegue sobre ejecución, disponibilidad de datos, validación del estado, liquidación, finalidad, secuenciadores, gobernanza, puentes, comisiones y salidas ejecutables en Layer 2.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Una Layer 2 es un protocolo que ejecuta o coordina actividad fuera de una cadena base y depende de ella para una parte definida de la validación, la disponibilidad de datos, la liquidación o la ejecución de salidas. La etiqueta no es una norma universal. Un rollup que publica datos suficientes y hace cumplir las transiciones de estado mediante fault proofs o pruebas de validez tiene supuestos de confianza distintos de un validium, un canal de estado, una sidechain, un puente multifirma o un libro contable de un exchange, aunque todos se anuncien como L2.

Para un despliegue concreto, pregunte qué acepta realmente el contrato L1, dónde residen los datos de derivación, quién ordena las transacciones, cómo se rechaza un estado no válido, cuándo un bloque pasa a ser seguro o finalizado, quién puede actualizar o pausar el sistema y si el usuario puede salir sin el operador. Las confirmaciones rápidas y las comisiones bajas son útiles, pero por sí solas no demuestran seguridad heredada.

Cómo funciona

  1. Fije la identidad del sistema: chain IDs de L1 y L2, génesis y fork, stack y versión del rollup, contratos de liquidación y puente, implementaciones proxy, tipo de prueba o juego de disputas, modo de disponibilidad de datos, secuenciador y referencias de bloque. Trate el nombre del sitio web y el término L2 como metadatos de descubrimiento, no como autenticación.
  2. Clasifique la arquitectura en ejes separados. Registre entorno de ejecución, modelo de ordenación, mecanismo de validación del estado, ubicación de los datos, cadena de liquidación y ruta de custodia. Los optimistic rollups, validity rollups, validiums, canales y sidechains combinan estos ejes de forma distinta; un motor compatible con EVM no iguala su seguridad.
  3. Reconstruya el flujo de estado. Siga envío del usuario, ordenación del secuenciador, ejecución L2, codificación del batch, publicación de datos, compromiso de estado, impugnación mediante fault proof o verificación de prueba de validez, inclusión L1 y finalidad L1. Compruebe que software independiente pueda derivar el estado L2 declarado a partir de las entradas definidas por el protocolo.
  4. Separe disponibilidad y liveness. Determine si los datos están en calldata o blobs de L1, en un sistema DA externo o en un comité; identifique supuestos de retención y recuperación. Pruebe caída del secuenciador, inclusión forzada, envío alternativo, fallo del proponente o prover, retransmisión de mensajes y la ruta exacta de salida o retirada.
  5. Separe relojes y etiquetas de estado. Un bloque confirmado por el secuenciador o unsafe puede preceder la publicación de datos; un bloque safe puede preceder la finalidad L1; la aceptación de pruebas, resolución de disputas, maduración de retiradas y liberación del puente pueden añadir puertas independientes. Use las definiciones del despliegue, no un número universal de confirmaciones ni una regla fija de siete días.
  6. Mapee control y economía. Lea administradores de proxies, demoras de actualización, poderes del security council y guardian, estado de pausa, escalares de comisiones, token de gas, capacidad de batch y destinatarios de comisiones. Mantenga libros separados para ejecución L2, publicación L1 o DA, cargos del operador, comisiones del puente, gas de destino y coste de espera; una cotización no garantiza ejecución.
  7. Concilie los resultados del usuario. Verifique contrato y representación exactos del token, débito de origen, crédito de destino, estado del recibo, raíces de estado y mensaje, hashes de bloque safe y finalized, aprobaciones restantes y una salida de mercado o reembolso ejecutable. Revalide la configuración después de cada actualización y no deduzca la seguridad del puente del sistema de pruebas del rollup.

Ejemplos desarrollados

  • Economía del batch. Un batch contiene 2,000 transacciones de 160 bytes de media tras la compresión más 20,000 bytes de framing fijo, para un total de 340,000 bytes. A $0.00002/byte, los datos cuestan $6.80; al añadir $4.00 de coste fijo de prueba y liquidación se obtienen $10.80, o $0.0054/transaction. Con solo 200 transacciones, los mismos supuestos producen 52,000 bytes, $1.04 de coste de datos y $5.04 en total, o $0.0252/transaction. El batching reduce el coste medio solo bajo los supuestos indicados de tamaño, utilización y comisiones.
  • Capacidad frente a rendimiento realizado. Una L2 hipotética permite 60,000,000 gas cada 2 seconds, por lo que su capacidad es de 30,000,000 gas/second. Con 120,000 gas por operación de usuario, el techo mecánico es 250 operations/second; con una utilización efectiva del 72%, es 180 operations/second. Esto no mide finalidad, descentralización ni rendimiento de extremo a extremo; los límites de datos, pruebas o secuenciador pueden alcanzarse antes.
  • Tres relojes de estado y una puerta de retirada. En una cronología didáctica de estilo OP, una transacción recibe confirmación del secuenciador a las 12:00 UTC, su batch pasa a safe tras publicarse en L1 a las 12:07, y el bloque L1 que la contiene pasa a finalized a las 12:20. Si una retirada del puente se demuestra a las 14:00 y tiene una maduración ilustrativa de 7-day, su liberación más temprana sería a las 14:00 de la semana siguiente, sujeta al juego de disputas, pausas y condiciones L1. La finalidad de la transacción L2 a las 12:20 no es el mismo evento que la liberación del puente.
  • Valor ejecutable tras el puente. Un usuario deposita 1,000 USDC; una comisión del protocolo de 2 USDC deja 998 USDC en L2, mientras el gas de origen cuesta $7.50 por separado. El token recibido tiene un bid ejecutable de $0.995, impacto de precio del 0.20% y gas de salida de $3, por lo que el valor neto de salida es 998 * 0.995 * (1 - 0.002) - 3 = $988.02398. Frente a $1,000, el déficit es $11.97602, o 1.197602%; identidad del token, derecho frente al puente y liquidez importan además de la etiqueta L2.

Riesgos

  • Usar L1, L2, chain ID, despliegue, fork o versión de protocolo incorrectos.
  • Tratar la etiqueta comercial L2 como clasificación normalizada de seguridad.
  • Confundir una sidechain, validium, canal o libro custodial con un rollup.
  • Aceptar un RPC, explorador, puente, token o dirección de contrato falsificados.
  • Censura, equivocación, caída o abuso de ordenación privada del secuenciador.
  • Datos de batch y derivación ausentes o retrasados.
  • Retención, fallo o colusión de un sistema DA externo o comité.
  • Compromisos de estado no válidos o error del sistema de pruebas, juego o verifier.
  • Fallo de liveness del proponente, prover, challenger o relayer.
  • Congestión, censura, reorganización o finalidad retrasada de L1.
  • Confundir estados unsafe, safe, finalized, proven y withdrawable.
  • Rutas de inclusión forzada o escape pausadas, costosas o inutilizables.
  • Actualizaciones inmediatas de proxy o ventanas de salida insuficientes.
  • Claves comprometidas del administrador, guardian o security council.
  • Fallo de escrow del puente, mapping de tokens, decimales o representación.
  • Omitir de la cotización costes de datos, ejecución, operador, puente o destino.
  • Límites de capacidad, rate limits, congestión, slippage o falta del token de gas.
  • Confundir compatibilidad EVM con reglas idénticas de opcode, precompilados o seguridad.
  • Mensajes entre L2 que combinan supuestos más débiles de finalidad, puente o dependencia.
  • Confundir éxito del wallet, TPS alto o comisiones bajas con seguridad y finalidad económica.

Errores comunes

  • Toda red denominada Layer 2 hereda toda la seguridad de Ethereum.
  • Una confirmación del secuenciador equivale a finalidad respaldada por L1.
  • Las pruebas de validez o fault proofs resuelven automáticamente disponibilidad de datos y censura.
  • El sistema de pruebas del rollup garantiza también todos los tokens puenteados y aplicaciones.
  • Comisiones más bajas o TPS mayor demuestran descentralización, solvencia y una salida ejecutable.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...