NFTs Comprimidos Explicados
Un NFT comprimido (cNFT) es un activo digital único cuya propiedad y metadatos viven como un hash de hoja en un árbol de Merkle, no como un conjunto completo de cuentas de Solana que pagan alquiler por elemento. La cadena almacena una pequeña cuenta de árbol (raíz, dosel, registro de cambios). Los indexadores reconstruyen las hojas y sirven pruebas para que las billeteras y los programas puedan probar y actualizar un activo específico.
La compresión de estado es el patrón más amplio: muchos registros comparten un árbol de Merkle concurrente, y cada actualización prueba que la nueva hoja es consistente con la raíz actual. Bubblegum es la capa NFT del programa SPL Account Compression: emisión, transferencia, quema y vinculación de colecciones a escala.
Esta página es el paraguas para Compresión de Estado y cNFTs. Las páginas hermanas profundizan en los conceptos básicos, la mecánica del árbol, Bubblegum, DAS, transferencias y costos.
Resumen
- Los cNFTs comprimen el estado de NFT por elemento en hojas de Merkle bajo un árbol concurrente; la integridad en cadena es una raíz (y un dosel), mientras que los indexadores DAS contienen datos de hojas y pruebas para lecturas y mutaciones.
- Por Qué Importa: Token Metadata completo o Core NFTs pagan alquiler por emisión, metadatos y cuentas relacionadas. Con decenas de miles a millones de elementos (inventarios de juegos, POAPs, grandes lanzamientos generativos), ese alquiler domina. La compresión amortiza el almacenamiento para que el costo marginal de emisión sea principalmente tarifas de transacción.
- Conceptos Clave: Compresión de estado, árbol de Merkle concurrente, hoja / raíz / dosel, registro de cambios / búfer, Bubblegum, API DAS, prueba de Merkle, propietario de la hoja, autoridad del árbol.
- Cuándo Usar: Activos únicos de alto volumen donde el alquiler por cuenta es prohibitivo; airdrops por lotes; credenciales de lealtad o asistencia; artículos de juegos a escala de más de 10k con requisitos de mercado ligeros.
- Limitaciones / Compensaciones: Dependes de un indexador compatible con DAS para la experiencia de usuario de producción; las transferencias necesitan pruebas frescas y más cuentas/CU que una simple transferencia de tokens; la composabilidad en cadena (depósito en garantía, colateral DeFi) es más delgada que para los NFTs basados en cuentas completas.
- Temas Relacionados: Conceptos básicos de compresión de estado, cómo funciona la compresión, emisión de Bubblegum, lectura de DAS, transferencia de cNFTs, costos y compensaciones.
Fundamentos
El problema del alquiler que crean los NFTs estándar
En Solana, los datos duraderos residen en cuentas que deben permanecer exentas de alquiler. Un NFT típico de Metaplex Token Metadata generalmente involucra una emisión, una cuenta de token (o ATA), metadatos y, a menudo, cuentas relacionadas con la edición. Cada una bloquea lamports para el alquiler. Multiplica por 100,000 elementos y el costo de capital se convierte en el producto de decisión.
Los cNFTs invierten ese modelo. Una cuenta de árbol almacena el estado resumen para hasta 2^maxDepth hojas. Cada emisión inserta (o reemplaza posteriormente) un hash de hoja que se compromete con la propiedad y los campos de metadatos, en lugar de una nueva cuenta de datos de larga duración. Todavía alojas JSON y medios fuera de cadena (Arweave, IPFS, HTTPS). Lo que cambia es dónde residen la unicidad y la prueba de propiedad en cadena.
Árboles de Merkle en una imagen
Un árbol de Merkle hashea pares de nodos hacia arriba hasta que queda una única raíz. Dada la raíz y una ruta de hashes hermanos (una prueba), puedes verificar que una hoja pertenece al árbol sin almacenar cada hoja en cadena.
Fuera de cadena / indexador Cuenta de árbol en cadena
-------------------- ---------------------
hoja_0 hoja_1 ... hoja_n hash de raíz
\ / / dosel (nodos superiores, opcional)
h01 ... ... registro de cambios (raíces recientes)
\ /
raíz <-----------------------> debe coincidir con proof.rootLa compresión de estado utiliza un árbol de Merkle concurrente para que múltiples actualizaciones puedan aterrizar sin tratar el árbol como una estructura de un solo escritor. La cuenta mantiene un registro de cambios de raíces recientes y un búfer dimensionado por maxBufferSize para que las actualizaciones concurrentes de hojas aún puedan verificarse.
La profundidad del dosel almacena nodos de prueba superiores en la cuenta del árbol. Doseles más profundos cuestan más alquiler por adelantado y reducen las cuentas de prueba que debes pasar en la transferencia. Esa compensación es central para el diseño de árboles de producción.
Bubblegum vs el programa de compresión
| Capa | Rol |
|---|---|
| SPL Account Compression | Posee la cuenta del árbol; verifica pruebas; añade o reemplaza hojas |
| Bubblegum | Semántica NFT: metadatos, propietario de la hoja, creadores, colección, emisión/transferencia/quema que CPI en la compresión |
IDs de programa comunes (implementaciones de Metaplex):
- Compresión de Cuentas:
cmtDvXnzBMY46rZyrBGX7p7r4Xc78DGpXEC5rVjrvAf - Bubblegum:
BGUMAp9Gq7iN3nEkgqX1FbwwdBonfLCEEgxoj36SYPk
Los clientes a menudo usan Metaplex Umi con mpl-bubblegum y mpl-account-compression para la creación de árboles y la emisión, con @solana/kit 7.0.0 para envíos generales de RPC. Los programas de Anchor que integran cNFTs usan el mismo modelo de prueba; no inventan un segundo tiempo de ejecución de compresión.
Mapa del ciclo de vida
- Crear árbol - elige
maxDepth,maxBufferSizeycanopyDepth; paga el alquiler del árbol una vez. - Emitir - Bubblegum hashea los metadatos + propietario en una hoja y la añade a través de la compresión.
- Indexar - un proveedor DAS materializa los registros de activos y las pruebas a partir de eventos.
- Leer - las billeteras llaman a DAS (
getAsset,searchAssets,getAssetsByGroup), no agetAccountInfopor elemento. - Transferir / actualizar - el cliente recupera una prueba fresca, construye la instrucción de Bubblegum, verifica contra la raíz en vivo, reemplaza la hoja.
La integridad está en cadena (transiciones de raíz). La descubribilidad está fuera de cadena (indexador). Los productos necesitan ambos.
Mecánicas e Interacciones
Parámetros del árbol que bloquean la capacidad del producto
En la creación, fijas la capacidad aproximadamente como 2^maxDepth hojas:
| maxDepth | Hojas máximas aproximadas |
|---|---|
| 14 | 16,384 |
| 20 | ~1,048,576 |
| 24 | ~16.7M |
No puedes cambiar fácilmente la profundidad más tarde. Subestimar obliga a un segundo árbol, colecciones divididas o una migración dolorosa. Planifica el suministro más margen (a menudo 2x-4x), equilibrado contra un alquiler más alto para árboles más profundos y doseles más grandes.
maxBufferSize admite actualizaciones concurrentes contra el registro de cambios. canopyDepth acorta las pruebas en las transacciones. Los árboles profundos sin dosel a menudo superan los límites de tamaño de transacción; el dosel es cómo los equipos mantienen las transferencias realizables.
A qué se compromete una hoja
Bubblegum define una forma de metadatos comprimidos (nombre, uri, tarifa del vendedor, creadores, campos de colección y hashes relacionados). La propiedad se codifica con el propietario de la hoja (y delegados opcionales). Cambiar el propietario significa reemplazar el hash de la hoja para que el nuevo hash coincida con la nueva carga útil de propiedad bajo el mismo árbol.
Es por eso que las transferencias no son spl_token::transfer. No hay un saldo de token clásico para debitar. La instrucción prueba "esta hoja está en el árbol bajo la raíz R", luego instala una nueva hoja en el mismo índice con un nuevo compromiso de propietario.
Por qué DAS no es opcional en producción
El RPC estándar responde "¿qué bytes contiene esta cuenta?" Los cNFTs no asignan una cuenta por activo, y la cuenta del árbol no lista cada nombre e imagen. Sin un indexador que siga los eventos de compresión y Bubblegum, una billetera no puede listar el inventario del propietario ni construir una prueba válida.
La API del Estándar de Activos Digitales (DAS) es la superficie de lectura común:
| Método | Uso típico |
|---|---|
getAsset | Metadatos de un solo activo + campos de compresión (árbol, ID de hoja, seq) |
getAssetProof | Raíz, matriz de pruebas hermanas, índices para instrucciones de Bubblegum |
getAssetsByGroup / searchAssets | Galerías de colecciones e inventarios de propietarios |
Las pruebas caducan cuando la raíz del árbol avanza. Los clientes deben volver a obtenerlas inmediatamente antes de firmar. Almacenar en caché metadatos con TTL está bien; almacenar en caché pruebas durante minutos es un modo de falla común.
Flujo de transferencia de extremo a extremo
Billetera / dapp
|
| 1. getAsset(id) + getAssetProof(id) --> DAS RPC
|
| 2. Construir instrucción de transferencia de Bubblegum
| - árbol de Merkle, firmante del propietario de la hoja, nuevo propietario de la hoja
| - raíz, hashes de datos/creador, nonce/índice
| - nodos de prueba como cuentas restantes
v
Bubblegum --> CPI verifica + reemplaza hoja
v
Compresión de Cuentas --> actualización de raíz + registro de cambios
v
Indexer --> El estado DAS se pone al díaLos modos de falla se mapean a esta ruta: raíz obsoleta, orden de prueba incorrecto, longitud de prueba incorrecta ajustada por el dosel, límites de CU o tamaño de transacción, firmante de propietario de hoja incorrecto, o retraso del indexador que confunde "tx exitosa" con "la galería ya se actualizó".
Costos: dónde se mueve el dinero
Por adelantado: alquiler del árbol (profundidad, búfer, dosel). Por emisión: tarifas de transacción (y tarifas de prioridad bajo contención), no alquiler completo de cuenta por NFT. Continuo: niveles DAS, ingeniería de canalización de pruebas, soporte de envío y mayor CU que una simple transferencia de Core.
Por debajo de unos pocos cientos de prestigiosos 1/1, Metaplex Core suele ser más simple. A escala de miles de elementos generativos o de juegos, el ahorro de alquiler de cNFT domina si aceptas la dependencia del indexador y la complejidad de la experiencia de prueba. El colateral DeFi y la composición profunda de programas todavía favorecen los estándares basados en cuentas a menos que los socios admitan flujos comprimidos.
Los clientes de @solana/kit 7.0.0 todavía usan RPC ordinario para enviar/confirmar; DAS es una superficie de método separada (a menudo la misma URL del proveedor). Valida la CU y el tamaño de la transacción en las herramientas Agave 4.1.1 / Solana CLI 3.0.10 antes de las ventanas de emisión en mainnet.
Consideraciones Avanzadas y Aplicaciones
Opciones de arquitectura que envejecen bien
| Enfoque | Fortaleza | Debilidad | Mejor ajuste |
|---|---|---|---|
| Bubblegum cNFT | Eficiencia de costo extrema por artículo; suministro enorme | Complejidad de DAS + pruebas; menor composabilidad | Juegos, POAPs, generativos grandes, lealtad a escala |
| Metaplex Core | Modelo en cadena más limpio; transferencias más simples | Cuentas por artículo y alquiler | Colecciones medianas, arte, integración de programas más sólida |
| Token Metadata (legado) | Amplio soporte histórico del mercado | Cuentas más pesadas; pila más antigua | Lugares que aún requieren cuentas TM clásicas |
| Múltiples árboles | Aislar riesgo y ventanas de emisión | UX de inventario dividido; más autoridades | Lanzamientos paralelos, aislamiento de autoridad |
| Dosel alto | Transacciones de actualización más pequeñas | Mayor alquiler del árbol | Árboles profundos con transferencias frecuentes |
La autoridad del árbol es seguridad operativa. El compromiso de la autoridad de emisión o del árbol es un incidente a nivel de colección. Usa multisig o autoridades de programas bien gobernadas.
La vinculación de colecciones sigue siendo importante para los mercados y getAssetsByGroup. Planifica los flujos de verificación de colecciones antes de la emisión masiva para que la agrupación DAS funcione desde el primer día.
Las ventanas de emisión por lotes requieren tarifas de prioridad, envío consciente de la tasa y monitoreo de retrasos. Una emisión exitosa en cadena invisible en DAS durante minutos es un ticket de soporte, no un error de cadena.
Composabilidad y diseño de programas
Los programas que escatiman o enrutan cNFTs deben hablar el idioma de las cuentas de Bubblegum y compresión, no la transferencia del Programa de Tokens. Las cuentas de prueba inflan las listas de cuentas restantes. Bajo Agave 4.1.1, la verificación de pruebas anidadas es más pesada que una sola transferencia SPL. Prefiere SDKs validados sobre la verificación de pruebas hecha a mano.
Si necesitas colateral DeFi o CPI profunda en protocolos de terceros, valida el soporte del socio antes de elegir cNFT. La compresión optimiza la economía de almacenamiento, no la composabilidad universal.
Observabilidad y modos de falla
Rastrea tres relojes:
- Tiempo de cadena - la transacción aterrizó y la raíz avanzó.
- Tiempo del indexador - DAS refleja la nueva hoja.
- Tiempo del cliente - la prueba para la siguiente acción sigue siendo válida contra la raíz.
La telemetría debe cubrir fallos en la obtención de pruebas, fallos en la simulación de transferencias (raíz obsoleta), retraso de DAS después de ráfagas de emisión y llenado del árbol frente a 2^maxDepth. Alerta mucho antes de la última hoja.
Evolución de la pila
La compresión de estado generalizó "hashear muchas cosas, almacenar la raíz". Bubblegum especializó eso para metadatos NFT. DAS estandarizó las lecturas de billetera para activos digitales. Separa la ruta de escritura (Bubblegum + compresión + RPC ordinario) de la ruta de lectura (DAS) en la configuración, reintentos y SLAs, incluso cuando los clientes Umi, kit y Anchor 0.32.1 mejoran la ergonomía.
Conceptos Erróneos Comunes
- "Los cNFTs son NFTs gratuitos." El alquiler del árbol, las tarifas, las suscripciones DAS y la ingeniería de pruebas son reales. Ahorras el alquiler de la cuenta por artículo, no todos los costos.
- "Puedo leer un cNFT con getAccountInfo en el ID del activo." No hay una cuenta de datos completa por artículo. Usa
getAssetde DAS y métodos relacionados. - "Una prueba es permanente como una clave privada." Las pruebas son válidas en relación con una raíz. Las emisiones y transferencias concurrentes las invalidan rápidamente.
- "La compresión significa que los metadatos viven completamente en cadena." La cadena se compromete con hashes y propiedad; los medios y el JSON todavía residen fuera de cadena en la URI de la hoja.
- "Cualquier mercado o protocolo DeFi funcionará sin problemas." Muchas integraciones asumen NFTs basados en cuentas. Confirma explícitamente el soporte comprimido.
- "Puedo expandir la profundidad del árbol más tarde si nos volvemos virales." La profundidad es una decisión en el momento de la creación. Planifica margen o una estrategia de múltiples árboles con anticipación.
- "RPC normal sin DAS está bien si almaceno las hojas en mi DB." Te conviertes en el indexador: la disponibilidad, las reorganizaciones, la corrección de pruebas y la experiencia de usuario multicanal recaen sobre ti.
Preguntas Frecuentes
¿Qué es un NFT comprimido en una oración?
Un cNFT es un activo único representado como una hoja de Merkle bajo un árbol concurrente, con integridad de raíz en cadena y datos de hoja y pruebas fuera de cadena (DAS) para lecturas y transferencias.
¿Cómo difiere la compresión de estado del "zipping" de datos de cuenta?
No comprime los bytes de la cuenta con gzip. Reemplaza muchas cuentas con compromisos criptográficos: hojas fuera de cadena o en indexadores, raíz y dosel en cadena, pruebas en cada actualización.
¿Qué añade Bubblegum sobre el programa de compresión?
Semántica NFT: campos de metadatos, propiedad de la hoja, flujos de emisión/transferencia/quema y comportamiento relacionado con la colección, implementados como instrucciones que impulsan operaciones verificadas de adición/reemplazo de hojas.
¿Por qué necesito un árbol de Merkle concurrente en lugar de un árbol simple?
Muchas emisiones y transferencias pueden golpear el mismo árbol muy juntas. El diseño concurrente más el registro de cambios/búfer permiten que el programa verifique las actualizaciones sin requerir una reescritura serializada global única de todo el árbol cada vez.
¿Qué es el dosel y por qué pagar por él?
Los nodos del dosel son niveles superiores de Merkle almacenados en la cuenta del árbol para que los clientes pasen menos cuentas de prueba por transacción, intercambiando un alquiler inicial más alto por transacciones de actualización más pequeñas y confiables.
¿Cómo elijo maxDepth?
Estima el suministro máximo, agrega margen (a menudo 2x-4x) y elige la profundidad más pequeña que se ajuste a esa capacidad, aceptando el alquiler del árbol y los tamaños de prueba correspondientes.
¿Cómo listan las billeteras los cNFTs para un usuario?
A través de métodos DAS como searchAssets o consultas filtradas por propietario, utilizando campos de compresión e IDs de activos devueltos por el indexador, no escaneando una cuenta por NFT.
¿Por qué falló mi transferencia después de una obtención de prueba exitosa minutos antes?
Es probable que la raíz del árbol haya avanzado (otra actividad en el árbol). Vuelve a obtener getAssetProof inmediatamente antes de construir y firmar la transferencia.
¿Son atómicas las transferencias de cNFT en cadena?
Sí. La transferencia de Bubblegum y el reemplazo de la hoja de compresión tienen éxito o fallan en una transacción; el retraso del indexador no deshace la transición de raíz en cadena.
¿Cuándo debería preferir Metaplex Core sobre los cNFTs?
Cuando el tamaño de la colección es modesto, deseas transferencias más simples y una composabilidad genérica más sólida, y el alquiler por artículo es aceptable en relación con el valor del producto.
¿La compresión elimina la necesidad de Arweave o IPFS?
No. Los hashes de hoja todavía suelen comprometerse con una URI de metadatos y campos relacionados. La permanencia y el alojamiento de contenido siguen siendo una opción de diseño fuera de cadena.
¿Puede mi programa Anchor emitir cNFTs?
Sí, componiendo con cuentas e instrucciones de Bubblegum/compresión (a menudo a través de CPI o transacciones multi-instrucción construidas por el cliente). Aún necesitas pruebas correctas, configuración del árbol y DAS para lecturas; Anchor 0.32.1 no elimina el modelo de compresión.
¿Cuál es el principal riesgo operativo en el lanzamiento de la emisión?
Agotamiento de la capacidad del árbol o sobrecarga/retraso de DAS que oculta las emisiones exitosas de las galerías. Dimensiona los árboles con anticipación y prueba las cargas de los niveles del indexador antes de la emisión pública.
¿Adónde debo ir después de esta página?
Comienza con Conceptos Básicos de Compresión de Estado y Cómo Funciona la Compresión, luego la emisión de Bubblegum, lecturas de DAS, transferencias y Costos y Compensaciones para decisiones de ir/no ir.
Relacionados
- Conceptos Básicos de Compresión de Estado - primer vocabulario y ejemplos de inicio para árboles y cNFTs
- Cómo Funciona la Compresión - raíces, pruebas, dosel y mecánicas de dimensionamiento de árboles
- NFTs Comprimidos (Bubblegum) - createTree, mintV1 y canalizaciones de emisión a escala
- Lectura de Activos Comprimidos (DAS) - getAsset, getAssetProof y consultas de galería
- Transferencia de cNFTs - cambios de propiedad basados en pruebas de extremo a extremo
- Costos y Compensaciones - cuándo la compresión gana frente a Core o Token Metadata
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.