Parceros
  • 👽Recursos
    • 💻Nodos validadores
      • Buenas prácticas y seguridad de un validador
      • Montaje de nodo validador de Stargaze
      • Montaje de nodo validador de Tgrade
      • Montaje de nodo validador de Juno
      • Instalacion del Cosmovisor
      • Instalación de AutoCompound
      • Guía de instalación Prometheus y Grafana para un Validador
    • 🎓Desarrollo
      • Fundamentos en Gnu/Linux
      • Fundamentos en Blockchain
      • Billeteras
      • Introducción a Cosmos Hub
      • Guia de Inicio en Rust
      • Clases de CosmWasm
        • Introducción a CosmWasm
        • Puntos de entrada de un contrato vacio
        • Consultas - Query
      • Clases de Rust
        • Introducción a Rust
        • Ciclos
        • Funciones
        • Manejo de la memoria
        • Tipos de datos avanzados
        • Macros
        • Manejo de paquetes
        • Manejo de errores
      • Guia Archway
        • Instalación de requisitos
        • Configuración del proyecto
        • Solicitud de tokens Testnet
        • Mi primera app
          • Configuracion
          • Produciendo ejecutables wasm
          • Despliegue e instanciación de contratos en la cadena
          • Interactuar con su contrato
          • Construir el frontend de la dApp
        • Proyecto NFT
          • Creando un proyecto NFT
          • Despliegue del contrato de tokens
          • Acuñación y envío de tokens
          • Construye la Dapp NFT
        • Fee Grant
          • Comprendiendo los Fee grant
          • Grant asignación
          • Utilizando asignaciones grant
        • Multifirmas
          • Archway multi firma hub
          • Navegar por la interfaz multi firmas
      • Cosmwasm Documentacion
        • Introducción
        • Primeros pasos
          • Introducción
          • Configuración del entorno
          • Elaborar un contrato
          • Test Unitarios
          • Despliegue e interacción
          • Integración con contratos inteligentes
          • Próximos pasos
        • Arquitectura
          • ¿Qué son los contratos multicadena?
          • Modelo de actor para las convocatorias de contratos
          • Nombres y direcciones
          • Consulta del estado del contrato
          • Formatos de serialización
          • Composición del contrato
          • Comparación con los contratos de solidity
        • Contratos inteligentes
          • Semántica contractual
          • Message
            • Messages
            • Submensajes
          • State
            • Simple state
            • Complex state y maps
          • Result y option
          • Entry points
          • Query
          • Events
          • Math
          • Verificación de contratos inteligentes
          • Migration
          • Migrar una dapp a una red diferente
          • Testing
          • Ejecución Sudo
          • CosmWasm y CIB
        • Tutoriales
          • Opcion simple
            • Testing
          • Storage
            • ¿Cómo funciona el almacenamiento de valores clave?
            • Índices
            • Modelización avanzada de estados
          • Cosmwasm con ejemplos
            • Operaciones matemáticas de Cosmowasm
            • Crear una instancia de un contrato CosmWasm
            • Timelock
            • Contrato Crowdfunding
            • Respuestas y atributos en Cosmwasm
            • Lee y escribe
            • Envío de tokens
            • Token Vaults
            • Creador de mercado automático de productos constantes (AMM)
      • Guia Celestia
        • Descripcion general de celestia
          • Introduccion
          • Blockchains monolíticos vs modulares
          • Capa de disponibilidad de datos
            • La capa de disponibilidad de datos de Celestia
            • El ciclo de vida de una transacción celestia-app
            • Recuperabilidad de datos y poda
            • Disponibilidad de datos FAQ
          • Recursos adicionales
            • Aprende modular
            • Glosario de Celestia
            • Especificaciones de aplicación de celestes
            • Documentación API de nodo celestial
        • Ejecutar un nodo
          • Descripción general de los nodos en ejecución en Celestia
          • Guía de inicio rápido
            • Decidir qué nodo ejecutar
            • Entorno de desarrollo
            • Instalar celestia-node
            • Instalar celestia-app
            • 🐳 Configuración de Docker
          • Redes
            • Resumen de redes
            • Mainnet Beta
            • Mocha testnet
            • Arábica devnet
          • Tipos de nodos
            • Disponibilidad de datos
              • Nodo ligero
              • Nodo completo
              • Nodo puente
            • Consenso
            • Relay de IBC
              • Guía de retransmisión IBC
              • Relays de IBC
          • Recursos
            • nodo-celestia
              • Metricas
              • guía config.toml
              • Redes y valores personalizados
              • Solución de problemas
            • celestia-app
              • Especificaciones
              • Métricas, visualización y alertas
              • Mecánica de corte
              • Crear un testnet Celestia
              • Comandos CLI útiles
              • Monitor de Actualización
              • Carteras en celestia-app
              • Multisig
              • Crea una cuenta de adquisición
            • SystemD
            • Proceso de hardfork
        • Desarrolladores
          • Construir modular
          • Envío de blobs de datos a Celestia
          • Directrices de reenvío de transacciones
          • API de nodo
            • Celestia-node RPC CLI tutorial
            • Documentación de la API RPC de Celestia-Node
            • Rápido Scavenger
            • Page
          • Integrar con Blobstream
            • Descripción general de Blobstream
            • Integrarse con contratos de Blobstream
            • Integrar con el cliente Blobstream
            • Consultando las pruebas de Blobstream
            • Operadores locales de Blobstream X
              • Solicitar rangos de compromiso de datos
              • Nuevas implementaciones de Blobstream X
          • Implementar un rollup
            • L2s Ethereum
              • Ethereum fallback
              • Arbitro
                • Introducción a los rollups de Arbitrum con Celestia como DA
                • Implementar un arbitrum rollup devnet
                • Testnet de nitrógeno
                • Implementar un contrato inteligente sobre la implementación de Arbitrum
                • Implemente un dapp en su devnet Arbitrum rollup
                • Optimismo
                  • Introducción a la integración de OP Stack
                  • Bubs testnet
                  • Implemente un contrato inteligente en Bubs testnet
                  • Implemente un dapp en Bubs testnet
                  • Implemente un devnet OP Stack
                  • Implemente un devnet OP Stack en Celestia
                  • Auditoría
                  • Implemente un dapp con thirdweb
                  • Rollups-as-a-Servicio
                    • Caldera
            • Rollkit
            • Astria
              • Documentación
              • Implementar a Dusknet
            • SDK Soberano
            • Vistara
            • Dimensión
          • Carteras
            • Crea una billetera con celestia-node
            • Integraciones de billeteras con Celestia
          • Integre Celestia para proveedores de servicios
      • Unión
        • Arquitectura
          • CometBLS
          • Galois
          • Voyager
        • Conceptos
          • BLS Firmas
          • Clientes de Luz Condicional
          • Verificación de Consenso
          • Tecnología de validador distribuido
          • IBC
          • Sin permiso versus sin confianza
        • Infraestructura
          • Operador de nodo
            • Empezando
            • Docker Compose
            • Kubernetes
            • NixOS
            • Configuración del Nodo
        • Integracion
          • IBC Enabled Solidity
        • Demostrar
          • Dirigiendo el Union Devnet
          • PingPong
        • Unirse al testnet
          • Empezando
          • Ejecutar el binario cliente
          • Ejecución de Unionvisor
          • Obteniendo Tokens Testnet
          • Crear un Validador
          • Endpoints publicos
          • Sincronización de estado
          • Liberar un validador
          • Preguntas frecuentes
          • Historial de actualizaciones
        • Guia de estilo
          • Lista de palabras
      • Avail
        • Introducción a Avail
          • Aprovechar DA
          • Aprovechar Nexus
          • Aprovechar la fusión
        • Informacion de red
        • Más información sobre disponibilidad
          • El conseso
            • BABE
            • GRANDPA
            • NPoS
          • EIP-4844 y disponible
        • Guia de nuevo usuario
          • Cómo crear y administrar una cuenta disponible
          • Cómo utilizar el Explorador Goldberg Testnet
          • Cómo utilizar el faucet Testnet
          • Cómo establecer una identidad en cadena
          • Cómo generar una identificación de aplicación disponible
          • Cómo realizar transferencias de saldo disponibles
          • Cómo crear grupos de nominaciones disponibles
        • Construir con disponibilidad
          • Cree un paquete acumulativo con Avail
          • Comience con Avail
          • Optimium
            • OP Stack
            • Aprovechando la pila OP con Avail
            • Cómo utilizar la pila OP con Avail
            • Adaptador de pila OP 🔗
          • Validium
            • Polygon zkEVM
              • Construyendo sobre Polygon zkEVM con Avail
              • Cómo utilizar Polygon zkEVM con Avail
              • Nodo Validium 🔗
              • Contratos de Validium 🔗
              • Puente Validium 🔗
            • Madara Starknet
              • Construyendo sobre Madara Stack con Avail
              • Cómo utilizar Madara con Avail
              • Madara Starknet🔗
            • Referencia
          • Sovereign Rollups
            • Sovereign SDK 🔗
            • Rollkit 🔗
            • OpEVM 🔗
        • Glosario
        • Preguntas generales frecuentes
      • Dymension
        • Aprender
          • ELI5
          • RollApps
            • RollApps
            • Tokens
            • Gobernancia
            • Puente
            • En profundidad
              • Dymension RDK
                • Dymint
              • Gobernanza
                • Gobernador
                  • Descripción general
                  • Crear gobernador
                  • Otros comandos
                • Votación
                  • Parámetros ajustables
                  • Gasto comunitario
                  • Registro de tokens ERC-20
              • IBC Puente
                • Visión general
                • Seguridad
                • Retransmisores
          • Dymension
            • Visión general
            • DYM
              • Supply
              • Demanda
              • Crecimiento
              • Distribución
            • Seguridad
              • Estándares
              • Actualizable
              • Disponibilidad de datos
              • Pruebas de fraude
              • Resistencia a la censura
              • Page 1
            • Puentes
              • IBC
              • eIBC
            • Liquidez
              • Descripción general
              • Depositar tokens
              • Vinculación de tokens LP
              • Incentivos
              • Comisiones
            • Gobernanza
              • Descripción general
              • Preparando una propuesta
              • Proponiendo a la dimocracia
        • Construir
          • Descripción general
          • Testnet
            • EVM
              • Descripción general
            • CosmWasm
              • Descripción general
              • Información
              • Ejemplo de cosmoWasm
          • Roller CLI
            • Descripción general
            • Comenzar
              • Instalar
              • Inicializar RollApp
              • Registro
              • Correr
                • Simple
                • Avanzado
                  • Cliente ligero DA
                  • Secuenciador
                  • Retransmisor
            • Nodo en ejecución
              • Ejecutando en producción
              • Supervisión
              • Información de RollApp
              • Exportar claves
              • Mejora
              • Editar la configuración de RollApp
              • Sincronización de estado
            • Solución de problemas
              • Descripción general
              • Saldos
              • Hardware
              • Rollapp de importación/exportación
              • Acceso externo
              • Estado
              • Archivos de registro
            • RollApp local
              • Ejecute la aplicación EVM RollApp
              • Ejecute la aplicación CosmWasm RollApp
        • Validar
          • Preguntas frecuentes sobre nodos
          • Construir dimensión
          • Configuración de nodo
          • Únase a una red
          • Nodo de sincronización
          • Validador
          • Actualizaciones
          • Solución de problemas
          • Programa de delegación
            • objetivos del programa
            • Parámetros de evaluación
            • Solicitud
      • Movement
        • Desarrolladores
          • Inicio rápido
          • Configuración
            • Usando contenedores
            • Usando el instalador
          • Tutoriales
            • Desplegar
              • Módulo Aptos
              • Módulo Sui
              • Contratos EVM
                • Implementación de contratos de solidez en movimiento utilizando Foundry y Fractal
                • Implementación de contratos de solidez en M1 usando Hardhat y Fractal
                • Implementación de contratos inteligentes de Solidity en M1 utilizando el tiempo de ejecución Fractal
            • Ejecute MoveVM
              • Ejecutando M1 usted mismo
            • Construir dApp
              • Aptos Move dApp
              • Aplicación Sui Move
              • DApp de solidity
            • Interoperar
              • AptosVM<>MEVM
          • Herramientas de desarrollo
            • Movement CLI
              • Movement aptos
                • cuenta
                  • crear
                  • crear-cuenta-de-recursos
                    • derivar-dirección-de-cuenta-de-recursos
                  • fondo-con-grifo
                  • lista
                  • dirección de búsqueda
                  • rotar llave
                  • transferir
                • configuración
                  • generar-compleciones-de-shell
                  • configurar-global-config
                  • show-global-config
                  • mostrar-perfiles
                • génesis
                  • generar-admin-escritura-conjunto
                  • generar-génesis
                  • obtener direcciones de grupo
                  • generar-claves
                  • generar-plantilla-de-diseño
                  • configuración-git
                  • configuración-del-validador-de-conjuntos
                • gobernancia
                  • proponer
                  • votar
                  • propuesta de show
                  • lista-propuestas
                  • verificar-propuesta
                  • ejecutar propuesta
                  • generar-propuesta-de-actualización
                  • aprobar-ejecución-hash
                • información
                • init
                • llave
                  • generar
                  • extraer-peer
                • mover
                  • construir-publicar-carga útil
                  • limpio
                  • compilar
                  • script de compilación
                  • cobertura
                    • resumen
                    • fuente
                    • código de bytes
                  • crear-cuenta-de-recursos-y-publicar-paquete
                  • desmontar
                  • documento
                  • descargar
                  • init
                  • list
                  • probar
                  • publicar
                  • correr
                  • ejecutar guión
                  • prueba
                  • prueba transaccional
                  • verificar-paquete
                  • vista
                • multifirma
                  • aprobar
                  • crear
                  • crear-transacción
                  • ejecutar
                  • ejecutar-rechazar
                  • ejecutar con carga útil
                  • rechazar
                  • verificar-propuesta
                • nodo
                  • analizar-validador-rendimiento
                  • arranque-db
                  • verificar-conectividad-de-red
                  • conseguir-participación-pool
                  • inicializar-validador
                  • conjunto de validadores de unión
                  • conjunto de validadores de licencia
                  • mostrar-información-de-época
                  • mostrar-validador-config
                  • mostrar-conjunto-validador
                  • mostrar-validador-participación
                  • ejecutar-testnet-local
                  • actualización-clave-de-consenso
                  • actualizar-validador-direcciones-de-red
                • apostar
                  • agregar apuesta
                  • crear-contrato-de-participación
                  • distribuir-monedas-adquiridas
                  • aumentar-bloqueo
                  • inicializar-propietario de la participación
                  • solicitud-comisión
                  • establecer-votante-delegado
                  • operador de conjunto
                  • desbloquear-apuesta
                  • desbloquear-monedas-adquiridas
                  • retirar-apuesta
                • actualizar
              • movement sui
                • comenzar
                • génesis
                • ceremonia-genesis
                  • init
                  • estado de validación
                  • agregar-validador
                  • validadores de lista
                  • punto de control de compilación sin firmar
                  • examinar-punto-de-control-génesis
                  • verificar y firmar
                  • finalizar
                • herramienta clave
                  • convertir
                  • decodificar-tx-bytes
                  • decodificar-multi-sig
                  • generar
                  • importar
                  • lista
                  • par de claves de carga
                  • dirección multifirma
                  • multi-sig-combinar-sig-parcial
                  • herencia-sig-parcial-combinada-multi-sig
                  • espectáculo
                  • firmar
                  • señal-kms
                  • deshacer
                  • zk-login-firmar-y-ejecutar-tx
                  • zk-login-ingresar-token
                  • zk-login-sig-verificar
                  • zk-login-signo-inseguro-mensaje-personal
                • consola
                • cliente
                  • dirección activa
                  • entorno-activo
                  • direcciones
                  • llamar
                  • identificador de cadena
                  • campo dinámico
                  • env
                  • ejecutar-tx firmado
                  • gas
                  • fusionar moneda
                  • nueva direccion
                  • nuevo-ambiente
                  • objeto
                  • objetos
                  • pagar
                  • pago todo-sui
                  • pay-sui
                  • publicar
                  • moneda dividida
                  • cambiar
                  • bloque tx
                  • transferir
                  • transferencia-sui
                  • mejora
                  • verificar-bytecode-metro
                  • verificar-fuente
                  • transacción-repetición
                  • lote de repetición
                  • punto de control de repetición
                • validador
                  • hacer-información-validador
                  • convertirse en candidato
                  • comité conjunto
                  • comité de licencia
                  • metadatos de visualización
                  • actualizar-metadatos
                    • nombre
                    • descripción
                    • URL de la imagen
                    • URL del proyecto
                    • dirección de red
                    • dirección primaria
                    • dirección-trabajador
                    • dirección-p2p
                    • clave-pub-de-red
                    • clave-pub-trabajador
                    • protocolo-pub-clave
                  • actualizar-precio-de-gas
                  • validador de informes
                  • serializar-carga útil-pop
                  • mostrar-actualización-del-precio-del-gas-raw-txn
                • move
                  • construir
                  • cobertura
                    • resumen
                    • fuente
                    • código de bytes
                  • desmontar
                  • nuevo
                  • probar
                  • prueba
                • simulacro de incendio
                  • rotación de metadatos
              • movement ctl
              • movement manage
            • fractales
              • marco evm
          • Desarrolladores Aptos
            • Configurar la CLI de Aptos
            • Usando la CLI de Aptos
          • Desarrolladores Sui
            • Configurar Sui CLI
            • Usando Sui CLI
          • Preguntas más frecuentes
        • Ecosistema
          • Wallets
          • Tokens
          • Faucet
          • Move idioma
            • Módulos y scripts
            • Tipos primitivos
              • Enteros
              • booleano
              • DIRECCIÓN
              • Vector
              • Firmante
              • Referencias
              • Tuplas y unidad
          • Recursos de aprendizaje
          • Techpedia
            • Paralelización
            • Mover recursos
            • SDK de movement
      • Initia
        • ACERCA DE
          • Bienvenido a Inicia
          • Arquitectura Omnitia
            • Inicia (Capa 1)
            • Minitia (Capa 2)
          • Ciclo de vida de la transacción
          • Liquidez y apuestas consagradas
            • IniciaDEX
          • Programa de intereses adquiridos
        • CONSTRUIR SOBRE LA INICIATIVA
          • iniciado
          • inicia.js
          • Creando cuenta
          • Tutoriales específicos de VM
            • MoverVM
              • Implementación de módulos de movimiento
              • Creando moneda de movimiento
              • Envío de moneda de movimiento
              • Creando movimiento NFT
              • Módulos relacionados con el replanteo
              • Interactuar con Oracle en MoveVM
              • Mover ganchos IBC
            • WASMVM
              • Implementación del contrato CosmWasm
              • Interactuando con Oracle en WasmVM
              • Ganchos Wasm IBC
              • Fábrica de fichas
            • EVM
              • Implementación del contrato de solidez
              • Crear un token ERC-20 personalizado
              • Consultar estados del cosmos
              • Ejecutando mensajes de Cosmos
              • Conversión de direcciones entre EVM y Cosmos
              • Conversión entre direcciones Denom y ERC-20
              • Interactuar con Oracle en EVM
              • Ganchos EVM IBC
              • Ethereum JSON-RPC
          • Tutoriales generales
            • Oráculo: Furtivo
            • Mensajes entre cadenas
            • Saltar API
            • Miniswap
              • Interactuando con Minitswap
            • Conversión entre nombres de usuario y direcciones
            • Usando el Explorador local de Initia
            • Interactuando con InitiaDEX
            • Usando el widget de billetera Initia
        • IMPLEMENTAR MINITIA
          • Empezando
            • Implementación de su propia Minitia (Capa 2)
          • Configuración
          • Implementación de una Minitia independiente
          • Implementación completa de Minitia
            • Dirigiendo la Minitia
            • Pila de OPinit
              • Módulo OPinit: OPhost y OPchild
              • Configurar robots OPinit
                • Ejecutor del puente
                • Remitente de salida
                • Desafiador
                • Envío por lotes
                  • Envío de lotes a Inicia L1
                  • Envío de lotes a Celestia
            • Relé Hermes (IBC)
            • Habilitando oráculos
          • Retroceder
          • Agregar tokens a Initia Wallet
          • Personalizando Minitia
        • EJECUTAR EL NODO DE INICIO
          • Ejecutando el nodo de inicio
          • Arrancar un nodo de inicio
          • Conéctese a la red Inicial
          • Oráculo
          • Automatización de actualizaciones de software con Cosmovisor
          • Convertirse en un validador
        • RECURSOS
          • Registro de Iniciación
          • Información de la cadena Testnet
          • Parámetros de cadena
          • Documentación de la API
          • Documentos API (MiniMove)
          • Documentos API (MiniWasm)
          • Documentos API (MiniEVM)
      • Internet Computer
        • ¡Hola, mundo!
        • Descripción general del ICP
Powered by GitBook
On this page
  • Disponibilidad de datos
  • Descripción general del diseño del sistema
  • ¿Cómo funciona Avail DA?
  • ¿Que sigue?
  1. Recursos
  2. Desarrollo
  3. Avail
  4. Introducción a Avail

Aprovechar DA

Construya con Avail DA, la capa de disponibilidad de datos de validez comprobada que unifica Web3

Avail DA está diseñado para satisfacer las necesidades de aplicaciones soberanas y aplicaciones de confianza minimizada de próxima generación. Sus puntos fuertes residen en su innovador enfoque de seguridad, que permite a los clientes ligeros verificar fácilmente la disponibilidad de los datos mediante muestreo a través de una red de igual a igual. Nuestro enfoque modular simplifica la integración de blockchain para los desarrolladores, ya que ya no necesitan preocuparse por los conjuntos de validadores o la tokenómica. Con la incomparable interfaz de disponibilidad de datos de Avail DA y sus potentes capacidades de seguridad, los desarrolladores pueden crear aplicaciones blockchain sin conocimiento o a prueba de fraude con mayor eficiencia y facilidad.

En esencia, Avail DA prioriza el pedido y la publicación de transacciones al tiempo que permite a los usuarios verificar la disponibilidad de datos de bloques sin necesidad de descargar bloques completos. La naturaleza independiente de los datos de Avail DA es una de sus características definitorias. Admite varios entornos de ejecución, incluidos EVM, WASM y nuevos tiempos de ejecución personalizados, lo que ofrece una base versátil para diversas aplicaciones blockchain.

Descripción general de la escalabilidad L2

En las redes blockchain tradicionales, los nodos completos ejecutan todas las transacciones, garantizando la integridad y la seguridad. Sin embargo, aunque es seguro, este modelo limita el rendimiento y la escalabilidad debido a sus completos requisitos de procesamiento. Las soluciones de Capa 2 (L2) surgieron para abordar estas limitaciones y ofrecieron un rendimiento mejorado al trasladar la mayor parte de la ejecución de transacciones fuera de la cadena principal (Capa 1).

A pesar de sus ventajas, las soluciones L2 enfrentan desafíos para mantener la disponibilidad de los datos y la integridad de las transacciones, especialmente de una manera que sea eficiente y rentable. Los rollups tienen como objetivo mitigar estos desafíos ejecutando transacciones fuera de la cadena y luego publicando resultados agregados en la cadena principal. Este enfoque reduce significativamente la tensión en la Capa 1, lo que genera menores costos operativos y tarifas de transacción reducidas, ofreciendo una solución más escalable para las redes blockchain.

Los paquetes acumulativos se presentan en dos formas principales:

Resúmenes optimistas:

Los Rollups optimistas operan según un principio de validez presunta, donde se supone que las transacciones son válidas a menos que se demuestre lo contrario. Su ciclo de vida implica:

  1. Agregación de transacciones : las transacciones se recopilan mediante secuenciadores y se forman en un bloque acumulativo.

  2. Envío de bloque : este bloque se envía a un contrato inteligente basado en Ethereum con un vínculo como medida de seguridad.

  3. Asunción de validez : las transacciones se presumen válidas al momento de su envío.

  4. Ventana de impugnación : Período para la presentación de pruebas de fraude, que permite impugnar la validez del bloque.

  5. Resultado :

    • Desafío exitoso : el vínculo se pierde y el bloqueo se revierte.

    • Sin desafío : el bloque finaliza si no es desafiado.

Acumulaciones de ZK:

ZK Rollups requiere pruebas criptográficas iniciales de la validez de la transacción, centrándose en la seguridad y la integridad de los datos. Su ciclo de vida implica:

  1. Requisito de validez : se debe proporcionar una prueba de validez antes del envío del bloque.

  2. Envío de bloques : los bloques se envían con la prueba de validez requerida.

  3. Asunción de validez : se exige prueba de validez por adelantado, a diferencia de los paquetes acumulativos optimistas.

  4. Disponibilidad de datos : si bien las pruebas de validez son independientes de la disponibilidad de datos, la seguridad de la cadena depende en gran medida de ello.

  5. Implicaciones de la falta de disponibilidad de datos :

    • Recreación del estado : los usuarios no pueden recrear el estado si los datos no están disponibles.

    • Intervención del secuenciador : otros secuenciadores pueden intervenir para restaurar el estado y continuar las operaciones.

Aún así, existen limitaciones con la disponibilidad de datos.

Disponibilidad de datos

¿Cuál es el problema de disponibilidad de datos?

El problema de la disponibilidad de datos es un tema crítico en las tecnologías blockchain y de contabilidad distribuida, y se centra en la necesidad de hacer que todos los datos de las transacciones sean públicamente accesibles y verificables en toda la red. Este desafío es integral para la integridad y seguridad de blockchain.

En los sistemas blockchain, los datos de transacción de cada bloque requieren verificación por parte de los nodos de la red. El problema surge cuando los nodos se esfuerzan por validar nuevos bloques descargando y verificando los datos de sus transacciones. El quid de la cuestión no está sólo en publicar los datos sino en asegurar su distribución fiable en toda la red, garantizando la igualdad de acceso a todos los participantes.

El problema de disponibilidad de datos es particularmente significativo en las redes L2 debido a varias razones:

  • Transacciones fuera de la cadena : las soluciones L2 procesan transacciones fuera de la cadena principal para mejorar la escalabilidad. Sin embargo, esto puede generar desafíos a la hora de verificar que todos los datos de la transacción estén completos y sean precisos, ya que no se registran inmediatamente en la cadena de bloques L1.

  • Dependencia de la seguridad en la capa 1 : si bien las redes L2 operan de forma independiente para el procesamiento de transacciones, dependen de la L1 para su seguridad. Garantizar una transferencia de datos completa y precisa de L2 a L1 es vital para mantener la integridad de la red general.

  • Mecanismos de resolución Dependencia de los datos : las redes L2 pueden utilizar mecanismos como pruebas de fraude para la resolución de disputas. La eficacia de estos mecanismos depende de la disponibilidad y accesibilidad de los datos de las transacciones.

  • Cuestiones de transparencia y confianza : la transparencia es un principio fundamental de la tecnología blockchain. En las redes L2, cualquier compromiso en la disponibilidad de datos puede generar problemas de confianza, ya que es posible que los usuarios no puedan verificar las transacciones de forma independiente.

  • Mayor complejidad en la verificación : la adición de L2 agrega complejidad para garantizar que los datos se informen con precisión a la cadena principal. Esto aumenta el riesgo de problemas de disponibilidad de datos, lo que afecta la confiabilidad de la red.

Disponibilidad de datos en la capa 2

La disponibilidad de datos en soluciones L2 se puede clasificar en dos métodos:

  • Disponibilidad de datos en cadena : todos los datos de las transacciones se almacenan en la cadena L1, lo que ofrece mayor seguridad pero a un mayor costo.

  • Disponibilidad de datos fuera de la cadena : los datos se almacenan fuera de la cadena, con solo resúmenes criptográficos (hashes) en la cadena. Este método es rentable pero depende de entidades externas para la recuperación de datos.

Estos métodos enfatizan el papel de las L2 en la mejora de la gestión del estado y la interacción con la L1.

Sacar los datos de la capa 2 fuera de la cadena

Las adaptaciones de paquetes acumulativos representan una clase de soluciones de escalabilidad que ofrecen disponibilidad de datos fuera de la cadena y al mismo tiempo mantienen la integridad del procesamiento de transacciones. Estas soluciones son las siguientes:

  • Validiums: ZK Rollups + DA fuera de la cadena

  • Optimiums: acumulaciones optimistas + DA fuera de la cadena

  • Voliciones: ZK Rollups + Validiums

  • Acumulaciones soberanas: Acumulaciones independientes con DA personalizado y modelos de seguridad

Mover la disponibilidad de datos fuera de la cadena incorpora inherentemente dependencias de confianza adicionales debido a su dependencia de administradores de datos externos.

¿Qué son los Validium?

Los validiums son una adaptación directa de los paquetes acumulativos de ZK, que trasladan la disponibilidad de datos fuera de la cadena mientras se continúan utilizando pruebas de validez.

Representan una clase de soluciones de escalamiento caracterizadas por computación fuera de la cadena y pruebas de validez sólidas. A diferencia de los enfoques tradicionales, Validiums no almacena datos en la cadena principal de Ethereum, lo que resulta en un rendimiento de transacciones significativamente mejorado. La piedra angular de estos sistemas es el uso de pruebas de conocimiento cero, como ZK-SNARK o ZK-STARK. Estas herramientas criptográficas permiten a una parte confirmar la veracidad de una declaración a otra sin revelar ninguna información adicional más allá de la validez de la declaración.

En Validiums, la integridad de todas las transacciones se garantiza a través de estas pruebas de validez, mientras que la disponibilidad de los datos se mantiene fuera de la cadena. Esta arquitectura permite a los usuarios ejecutar retiros proporcionando una prueba Merkle. Dichas pruebas pueden dar fe de que se incluye la transacción de retiro de un usuario, lo que permite que el contrato en cadena facilite el proceso de retiro.

Las interacciones entre Validiums y Ethereum se organizan mediante un conjunto de contratos inteligentes. El componente principal de esta configuración es el contrato de certificación principal. Este contrato almacena compromisos estatales, representados como raíces de datos de Merkle, que bloquean a los productores. Además, un contrato de verificación es fundamental para verificar las pruebas de validez durante las transiciones de estado, lo que garantiza la integración y el funcionamiento perfectos de Validiums dentro del ecosistema Ethereum.

¿Qué son los Optimium?

Optimium es una adaptación directa de los paquetes acumulativos de Optimistic y también elimina la disponibilidad de datos fuera de la cadena. Conservan mecanismos de verificación a prueba de fraude y al mismo tiempo aumentan la escalabilidad.

En el corazón de Optimiums se encuentra el principio de validez asumida de la transacción. Inicialmente se presume que las transacciones dentro de este sistema son válidas. Esta suposición se mantiene hasta que se demuestre lo contrario, proceso facilitado por mecanismos a prueba de fraude. Estos mecanismos son cruciales para mantener la integridad y confiabilidad de la red. Si se cuestiona una transacción y se descubre que es fraudulenta, se revierte, garantizando la seguridad y fidelidad de la red.

La distinción clave de Optimium de sus contrapartes tradicionales es el almacenamiento fuera de la cadena de datos de transacciones. Este cambio estratégico aumenta notablemente la eficiencia y escalabilidad de la red al reducir la carga de datos en la cadena principal de Ethereum. Sin embargo, esto también introduce nuevas consideraciones de recuperación y verificación de datos, que se manejan hábilmente a través del sistema a prueba de fraude.

En Optimiums, los usuarios pueden ejecutar transacciones e interactuar con el sistema sin problemas. Los retiros se procesan mediante la presentación de pruebas de fraude que validan la autenticidad de la transacción. Estas pruebas sirven como piedra angular para garantizar que todas las operaciones dentro de la red sean legítimas y se ajusten a las reglas establecidas.

La integración de Optimiums con la cadena principal de Ethereum se gestiona mediante un conjunto de contratos inteligentes especializados. Estos contratos supervisan colectivamente el ciclo de vida de la transacción, desde el envío hasta la finalización, al tiempo que garantizan que todos los datos, aunque almacenados fuera de la cadena, sigan siendo accesibles y verificables según sea necesario.

¿Qué son las voliciones?

Las voliciones representan un enfoque versátil en el ámbito de las soluciones de escalamiento. Combinan las características de ZK-Rollups y Validiums. Este modelo híbrido ofrece flexibilidad en el almacenamiento de datos, lo que permite a los usuarios elegir entre la disponibilidad de datos dentro y fuera de la cadena según sus requisitos y preferencias específicos.

En esencia, Volitions aprovecha las pruebas de conocimiento cero, como ZK-SNARK o ZK-STARK, para garantizar la integridad y validez de las transacciones. Este mecanismo permite la verificación de transacciones sin comprometer la privacidad ni revelar datos subyacentes.

La característica única de Volitions radica en su funcionamiento en modo dual. Los usuarios pueden optar por el modo ZK-Rollup, donde los datos de las transacciones se almacenan en la cadena, beneficiándose así de la seguridad y descentralización de la cadena principal de Ethereum. Alternativamente, los usuarios pueden elegir el modo Validium, que almacena datos de transacciones fuera de la cadena, mejorando la escalabilidad y el rendimiento mientras mantiene pruebas de validez sólidas.

En ambos modos, la integridad de la transacción se mantiene mediante pruebas de conocimiento cero, pero la elección del modo de disponibilidad de datos permite un equilibrio personalizable entre escalabilidad, seguridad y rentabilidad.

La interacción de Volitions con el ecosistema Ethereum también se facilita mediante un conjunto completo de contratos inteligentes. Estos contratos gestionan los compromisos estatales y las verificaciones de prueba de validez, lo que garantiza que el sistema siga siendo seguro, eficiente y perfectamente integrado con Ethereum, independientemente del modo de disponibilidad de datos elegido.

¿Qué son los rollups soberanos?

Los Rollups soberanos representan una clase distinta de soluciones de escalamiento de blockchain, donde cada rollup opera como una entidad autónoma con su propio conjunto de validadores y reglas de consenso. A diferencia de los rollups tradicionales vinculados al modelo de seguridad y disponibilidad de datos de una cadena principal específica, los Sovereign Rollups mantienen autonomía sobre estos aspectos.

Estos paquetes acumulativos brindan una combinación única de escalabilidad y soberanía, lo que les permite adaptar su infraestructura a casos de uso específicos o necesidades de la comunidad. Al gestionar su propia disponibilidad de datos, ya sea dentro o fuera de la cadena, los Sovereign Rollups pueden optimizar el rendimiento, el costo y la seguridad según sus requisitos.

La característica clave de Sovereign Rollups es su independencia en la toma de decisiones con respecto a actualizaciones, tokenómica y modelos de gobernanza. Esta autonomía permite un enfoque más flexible y adaptable a la escalabilidad de blockchain, atendiendo a las necesidades diversas y en evolución del ecosistema.

En Sovereign Rollups, la integridad de las transacciones generalmente se mantiene a través de mecanismos de consenso personalizados o pruebas criptográficas, y sus interacciones con las cadenas principales (si las hay) están definidas por sus protocolos de gobernanza únicos. Esta estructura les permite operar como cadenas de bloques independientes y al mismo tiempo beneficiarse de las características de escalabilidad de la tecnología acumulada.

Avail DA aborda estos supuestos de confianza al proporcionar un mecanismo de disponibilidad de datos fuera de la cadena sólido y confiable. Esta integración fortalece significativamente la integridad y accesibilidad de los datos de las transacciones al tiempo que minimiza la dependencia de la gestión de datos basada en la confianza, mejorando así la seguridad y eficiencia generales de diversas soluciones de escalamiento.

Descripción general del diseño del sistema

Al desacoplar el alojamiento, la ejecución y la verificación de datos, Avail DA optimiza la eficiencia y eficacia de cada componente como resultado directo de la modularidad.

Capa de alojamiento y pedido de datos (capa DA)

En el nivel fundamental, la capa DA tiene la tarea de ingerir y ordenar datos transaccionales. Esta capa no se dedica a ejecutar transacciones sino que se dedica a almacenar los datos y garantizar su disponibilidad. La capa DA es fundamental para garantizar que el sistema no dependa de cada nodo completo para ejecutar transacciones, mitigando así los problemas de cuellos de botella en las cadenas de bloques tradicionales.

Capa de ejecución (capa ejecutiva)

La capa ejecutiva interactúa con la capa DA para acceder a las transacciones ordenadas. Luego procesa estas transacciones y genera los puntos de control, afirmaciones o pruebas necesarios. Posteriormente, estos se comprometen con la capa de verificación/resolución de disputas (capa DR), que puede considerarse como el ancla de seguridad del ecosistema Avail.

Capa de verificación/resolución de disputas (capa DR)

La capa DR sirve como componente de adjudicación donde se verifican los puntos de control o las pruebas enviadas por la capa de ejecución. Esto garantiza que solo se acepten transiciones de estado válidas dentro de la red.

Participantes de la red

Avail DA comprende tres tipos de nodos:

  • Nodos completos : estos nodos descargan y verifican la exactitud de los bloques, pero no participan en el proceso de consenso. Su papel es esencial para mantener la integridad de la red.

  • Nodos validadores : estos nodos son fundamentales para el mecanismo de consenso de Avail DA. Son responsables de generar bloques, decidir la inclusión de transacciones y mantener el orden. Los nodos validadores se incentivan mediante la participación por consenso y son fundamentales para las operaciones de la capa DA.

  • Clientes ligeros : al operar con recursos limitados, los clientes ligeros dependen de encabezados de bloque para participar en la red. Pueden consultar nodos completos en busca de datos transaccionales específicos según sea necesario y son cruciales para mantener una red descentralizada y accesible.

Consenso

Avail DA opta por un modelo de consenso de prueba de participación nominada (NPoS) por sus beneficios de escalabilidad y eficiencia energética. Específicamente, emplea el consenso BABE/GRANDPA de Substrate, que ofrece una combinación de producción rápida de bloques y finalidad demostrable.

¿Cómo funciona Avail DA?

Avail DA redefine la escalabilidad de blockchain al combinar codificación de borrado, compromisos polinómicos KZG y muestreo de disponibilidad de datos para ofrecer garantías de disponibilidad de datos de clase mundial. Funciona como una capa fundamental (base), que ofrece alojamiento de datos escalable sin ejecución de transacciones, específicamente para acumulaciones.

Ciclo de vida de la transacción

  1. Envío de transacciones

  2. Codificación de extensión y borrado de datos

  3. Creación de compromiso

  4. Propagación de bloques

  5. Red de clientes ligeros

  6. Verificación de prueba

Comenzando con el envío de transacciones

Mejora de la confiabilidad de los datos mediante la codificación de borrado

Una vez que las transacciones llegan a Avail DA, se procesan mediante codificación de borrado. Este procedimiento añade redundancia, mejorando la confiabilidad e integridad de los datos. Los bloques se dividen en nfragmentos originales y se extienden hasta 2n, lo que permite la reconstrucción a partir de cualquier nfragmento 2n. Si bien Avail DA incorpora mecanismos de prueba de fraude, la integridad de los datos se basa principalmente en el consenso de los validadores. Más de 2/3 de los validadores deben ser honestos para llegar a un consenso, lo que garantiza una seguridad sólida para los datos codificados para el borrado.

Para combatir la construcción errónea de fragmentos codificados por borrado, los nodos completos pueden crear y propagar pruebas de fraude , asegurando que los clientes ligeros puedan verificar la autenticidad de los encabezados de los bloques.

Solidificar la integridad de los datos con la creación de compromisos

Garantizar el consenso y la propagación del bloque

Los validadores desempeñan un papel fundamental en Avail DA. Reciben los bloques cargados de compromisos, los regeneran para verificar su exactitud y llegan a un consenso sobre el bloque, que requiere el acuerdo de al menos dos tercios (supermayoría). Los validadores garantizan que solo se propaguen a través de la red datos verificados y acordados. Llegan a un consenso. Esta etapa es vital para garantizar que los datos, una vez validados, puedan transmitirse a través del puente de atestación de datos de Avail DA.

Clientes ligeros: los guardianes de la disponibilidad de datos utilizando DAS

Por otro lado, los nodos completos utilizan los compromisos de Kate para dos propósitos principales: reconstruir los datos completos para la verificación en toda la red o crear pruebas de fraude para cuestionar cualquier discrepancia en los datos. Este mecanismo dual de clientes ligeros y nodos completos trabajando en conjunto también fortalece la seguridad y confiabilidad generales de la red.

Verificación de pruebas: el punto de control final

El viaje culmina con los clientes ligeros realizando la verificación de pruebas. Este proceso implica generar pruebas a nivel de celda a partir de la matriz de datos, lo que permite a los clientes ligeros verificar de manera eficiente e independiente el estado de la cadena de bloques. Este enfoque descentralizado de verificación respalda la seguridad y la integridad de Avail DA.

El acuerdo en Avail DA tiene como objetivo principal garantizar la disponibilidad de datos para los resúmenes. La ejecución y finalidad de la transacción real se producen en la capa acumulativa, mientras que Avail proporciona la infraestructura de datos necesaria.

¿Que sigue?

Para instalar la CLI desde npm, ejecute el siguiente comando:

npm i -g @availproject/cli

Entonces corre:

avail lc up

¡Eso es todo!

Únase a la campaña Choque de nodos

PreviousIntroducción a AvailNextAprovechar Nexus

Last updated 1 year ago

Como consumidores principales de Avail DA, los rollups comienzan el proceso enviando transacciones a Avail DA. Cada transacción lleva un único(o appID para abreviar), que indica su origen y propósito dentro del ecosistema más amplio.

Avail DA toma los datos redundantes y aplica compromisos polinomiales KZG a cada bloque. Estos compromisos sirven como pruebas criptográficas de la integridad de los datos, garantizando que lo que se almacena sea preciso y a prueba de manipulaciones. Los compromisos son utilizados porpara confirmar la integridad de los datos antes de que se certifiquen y se transmitan a la cadena principal a través de Avail DA's.

Clientes ligeros dentro del uso del ecosistema de Avail DApara verificar la integridad de los datos del bloque. Comparan las aperturas del polinomio KZG con los compromisos en el encabezado del bloque para cada celda muestreada, lo que les permite verificar de forma independiente e instantánea la disponibilidad de los datos. Este método evita la necesidad de reconstruir compromisos completos de KZG o confiar en pruebas de fraude, lo que respalda los altos estándares de seguridad e integridad de datos de Avail DA mantenidos mediante verificación descentralizada. Sin embargo, para realizar comprobaciones de integridad de datos más completas, especialmente para la integridad de las filas dentro de la matriz de datos, los clientes de aplicaciones realizan la reconstrucción KZG. Este enfoque es más óptimo para verificar la integridad de filas enteras que validar celdas individuales.

Con su conocimiento básico de Avail DA, si es nuevo en el ecosistema, asegúrese de visitar elsección.

Además, considere experimentar con un cliente ligero. Para esto, eles un gran recurso. Para ejecutar un cliente ligero Avail DA, todo lo que necesita hacer es instalar y usar la CLI de Avail.

A medida que profundiza en el ecosistema de Avail, le espera una oportunidad emocionante. Avail está avanzando las fronteras de las cadenas de bloques modulares e invitamos a los operadores de nodos a participar en la campaña dinámica Choque de nodos. Esta campaña es una piedra angular en la prueba de las capacidades de Avail DA, ofreciendo un entorno de testnet incentivado en tiempo real. Es una oportunidad de ser parte de una comunidad que está dando forma al futuro de la infraestructura blockchain. Si está listo para continuar su viaje con Avail y participar en esta innovadora campaña, visite elsección en la documentación.

👽
🎓
ID de aplicación
validadores
puente de atestación de datos
Muestreo de disponibilidad de datos (DAS)
guía del usuario final
Guía de inicio rápido
Choque de nodos