- Productos y plataforma de Helius
- Fundamentos de Solana
- Mecánica de las transacciones
- Tokens y activos
- Conectividad y streaming
- Ecosistema
Productos y plataforma de Helius
Escalado automático
Mecanismo automático de Helius para recargar créditos en los planes con moneda fiduciaria. Cuando se agota la asignación mensual de créditos, el escalado automático compra créditos adicionales hasta alcanzar un límite definido por el usuario, lo que evita que los errores429 interrumpan el tráfico de producción. Los planes de criptomonedas no tienen escalado automático. En su lugar, usan créditos prepagados, que se compran manualmente.
Consulta Escalado automático.
Crédito
La unidad que Helius usa para facturar el uso de API y streaming. Los métodos RPC, las llamadas a DAS y el rendimiento del streaming tienen cada uno un costo específico en créditos. Cada plan incluye una asignación mensual de créditos que se restablece en cada ciclo de facturación (los créditos sin usar no se acumulan). Consulta Créditos para ver la tabla completa de costos.API DAS
Estándar de activos digitales (Digital Asset Standard): una especificación abierta para una interfaz unificada de activos digitales de Solana (NFT, NFT comprimidos y tokens fungibles). La implementación de la API DAS de Helius devuelve metadatos enriquecidos, propiedad y precios en una única respuesta estructurada, lo que elimina la necesidad de analizadores personalizados para los datos de activos en cadena. Consulta API DAS.Nodos dedicados
Nodos RPC privados de Helius sin límites de frecuencia ni medición de créditos, facturados con una tarifa mensual fija. Son adecuados para casos de uso específicos que necesitan un rendimiento ilimitado. Para la mayoría de las aplicaciones, el RPC normal de Helius es una mejor opción por su rendimiento superior, conmutación por error y cobertura de funcionalidades. Consulta Nodos dedicados.Transacciones mejoradas
API de transacciones analizadas de Helius que decodifica transacciones sin procesar de Solana en eventos legibles, como transferencias de tokens, ventas de NFT, intercambios, operaciones de staking y más, sin requerir analizadores de instrucciones específicos para cada programa. Consulta Transacciones mejoradas.Códigos de error
Códigos de estado HTTP estándar que devuelven las API de Helius, con contexto específico de Helius:400 Bad Request— parámetros no válidos o solicitud con formato incorrecto (por ejemplo, formato de dirección no válido, campos obligatorios ausentes o JSON con formato incorrecto)401 Unauthorized— clave de API ausente o no válida403 Forbidden— acceso denegado, normalmente debido a restricciones de IP, una suscripción que no incluye el endpoint o permisos insuficientes de la clave de API404 Not Found— no hay datos disponibles para el recurso solicitado (es normal en consultas de identidad de billeteras desconocidas)429 Too Many Requests— asignación de créditos agotada, límite de frecuencia superado o límite de solicitudes simultáneas alcanzado5xx— problemas del lado de Helius; vuelve a intentarlo con espera exponencial
Gatekeeper
Gateway perimetral de Helius que ofrece una latencia considerablemente menor que las llamadas RPC estándar, ya que enruta las solicitudes a través de una flota de proxies distribuida globalmente. Se accede sustituyendomainnet.helius-rpc.com por beta.helius-rpc.com en la URL del RPC.
Consulta Gatekeeper y la publicación del blog de presentación de Gatekeeper para conocer los fundamentos de su arquitectura.
LaserStream
Servicio de streaming gRPC de alto rendimiento de Helius para datos en cadena de Solana. Ofrece reproducción histórica, conmutación por error entre regiones y el conjunto más completo de funcionalidades entre los productos de streaming de Helius. Hay SDK oficiales para JavaScript/TypeScript, Rust y Go. LaserStream WebSocket se ejecuta en la misma infraestructura. Consulta LaserStream y la publicación del blog sobre el rendimiento de los SDK de LaserStream para ver un análisis detallado de las pruebas de rendimiento de los SDK.LaserStream WebSocket
Servicio persistente de streaming WebSocket de Helius. Ofrece tanto los métodos WebSocket estándar de Solana como extensiones específicas de Helius (transactionSubscribe y un accountSubscribe mejorado con filtros más completos) en un único endpoint unificado. LaserStream WebSocket comparte su backend con el gRPC de LaserStream.
Consulta LaserStream WebSocket.
Preconfirmations
La señal de transacción de menor latencia de Helius. Transmite las transacciones antes de que se agrupen en entradas y se dividan en shreds: Helius envía preconfirmaciones en el instante en que el líder las ejecuta, junto con su estado de ejecución, y BAM envía preconfirmaciones cuando el validador se compromete a ejecutarlas, antes de su ejecución. Llegan antes que Shred Delivery y que los streams con nivel de compromiso procesado. Se entregan mediante una suscripción WebSocketpreconfSubscribe. Requiere un plan Professional o superior; se mide a 10 créditos por mensaje. La cobertura depende de qué validadores reenvían su stream a Helius, por lo que el flujo no es continuo.
Consulta Preconfirmations y preconfSubscribe.
API de comisiones de prioridad
Endpoint de estimación de comisiones de Helius que devuelve valores recomendados de comisiones de prioridad según los mercados de comisiones en cadena en tiempo real. Permite establecer comisiones competitivas sin hacer estimaciones ni pagar de más durante periodos de congestión. Consulta API de comisiones de prioridad.Límite de frecuencia
La cantidad máxima de solicitudes por segundo permitida en un plan determinado de Helius. Los límites de frecuencia varían según el nivel del plan y la familia de API (RPC estándar, API mejoradas y streaming). Si los superas, se devuelve429 Too Many Requests.
Consulta Límites de frecuencia.
Sender
Servicio especializado de Helius para el aterrizaje de transacciones, diseñado para operadores de baja latencia. Combina comisiones de prioridad, propinas de Jito y enrutamiento mediante conexiones con stake para maximizar las tasas de aterrizaje. Está disponible enhttps://sender.helius-rpc.com/fast.
Consulta Sender.
Shred Delivery
Servicio de Helius para transmitir shreds sin procesar de Solana mediante UDP antes del ensamblaje final del bloque. Helius agrega shreds de una red distribuida de validadores en varias regiones para minimizar la variación de latencia geográfica de cualquier validador individual. Resulta útil para operaciones de alta frecuencia, arbitraje y otras aplicaciones de baja latencia. Los shreds sin procesar están disponibles en modalidad de autoservicio desde el panel de Helius: $1,000 al mes por IP ($800 al mes por IP en los planes Pro). Consulta Shred Delivery y la publicación del blog Cómo ganar el juego de los milisegundos: shreds, LaserStream y la ventaja de Solana para ver un análisis detallado del funcionamiento de los shreds.Conexiones con stake
La ruta predeterminada de envío de transacciones para los planes de pago de Helius. Las conexiones con stake enrutan las transacciones hacia los próximos líderes de bloque mediante la calidad de servicio ponderada por stake (SWQoS) de Solana a nivel de protocolo. Esta concede slots de conexión preferentes según el stake del validador y reduce la pérdida de paquetes durante periodos de congestión. Los planes de pago de Helius heredan esta ventaja en la tasa de aterrizaje sin que quienes realizan las llamadas tengan que operar directamente un validador con una gran cantidad de stake. Consulta Optimización de transacciones y la publicación del blog Calidad de servicio ponderada por stake: todo lo que necesitas saber.API de billeteras
API REST de Helius para consultar los saldos, el historial de transacciones, las transferencias, la identidad y la fuente de fondos de una billetera de Solana. Devuelve respuestas estructuradas con precios en USD en lugar de resultados RPC sin procesar. Además de direcciones, acepta nombres de dominio SNS.sol y ANS.
Consulta API de billeteras.
Fundamentos de Solana
Cuenta
Contenedor que almacena datos de forma persistente en Solana y se identifica mediante una clave pública de 32 bytes. Todo el estado en cadena, como los saldos de usuarios, el código de programas y los metadatos de tokens, reside en cuentas, incluidos los propios programas. Cada cuenta tiene un propietario, que es un programa autorizado para modificar sus datos o retirar lamports, y debe mantener un saldo mínimo de SOL (exento de renta) para persistir. Consulta la publicación del blog El modelo de programación de Solana: introducción al desarrollo en Solana para obtener más información.Agave
El cliente validador canónico actual de Solana, mantenido por Anza: el sucesor con nueva marca del cliente original de Solana Labs. Las referencias a versiones específicas de Agave (por ejemplo, el umbral mínimo de stake de SWQoS en la versión 1.17.31) suelen vincular un comportamiento a una versión específica del cliente. Jito-Solana es una bifurcación de Agave con su motor de bloques integrado; Firedancer es una alternativa independiente basada en C y desarrollada por Jump Crypto. Consulta la publicación del blog Máquina virtual de Solana para conocer el modelo de SVM que implementa Agave.Airdrop
Concesión de SOL o tokens SPL a una dirección. En Devnet y Testnet, un airdrop suele referirse a una pequeña cantidad de SOL de prueba procedente de un faucet que se usa para financiar billeteras de desarrollo. En Mainnet, se refiere a distribuciones masivas de tokens entre titulares existentes. Los airdrops de Devnet están disponibles mediante el faucet de Devnet.Cuenta de token asociada (ATA)
Cuenta de token derivada de forma determinista que contiene un token SPL específico para una dirección de billetera determinada. Cada billetera tiene como máximo una ATA por cada acuñación de token, por lo que las ATA son el lugar canónico para consultar el saldo de tokens de un usuario. Se deriva usando como semillas la dirección de la billetera y la acuñación del token.Bloque
Estructura de datos que contiene un conjunto de transacciones y metadatos esenciales, incluidos el hash del bloque y el hash del bloque anterior, con los que se forma una cadena inmutable. Los bloques se producen durante los slots: el líder asignado a un slot valida las transacciones entrantes, las agrupa en un bloque y transmite el bloque a la red mediante Turbine. No todos los slots producen un bloque. Si el líder no produce uno a tiempo, el slot se omite y la red continúa. Cuando un bloque recibe una supermayoría de votos de validadores ponderados por stake, se considera confirmado (consulta Nivel de compromiso). Consulta la publicación del blog Cómo funcionan los slots, bloques y epochs en Solana para obtener más información.Nivel de compromiso
El grado de confianza de que una transacción se ha incluido en cadena:processed— el líder actual la ha visto, pero aún no se ha votado; todavía puede descartarse si el bloque pierde el consenso (~0.4 s)confirmed— ≥66 % de los votos de los validadores ponderados por stake están en el bloque; históricamente, ningún bloque confirmado se ha revertido (~0.6 s)finalized— el bloque tiene ≥66 % de los votos y otros 31 bloques posteriores construidos sobre él (es decir, el bloqueo máximo de Tower BFT), lo que lo vuelve prácticamente irreversible (~13 s)
confirmed es la opción predeterminada recomendada. Usa processed para ofrecer información en la interfaz de usuario e finalized para operaciones de alto valor, como depósitos en exchanges o puentes entre cadenas. Los hashes de bloque obtenidos con finalized vencen antes que los obtenidos con confirmed, lo que reduce el tiempo disponible antes de que venza la transacción.
Consulta la publicación del blog ¿Qué son los niveles de compromiso de Solana? para obtener más información.
Unidades de cómputo (CU)
Medida de Solana para el trabajo computacional realizado por una transacción, similar al gas de Ethereum. Cada transacción especifica un límite de unidades de cómputo y un precio por unidad de cómputo (la comisión de prioridad en microlamports por CU). Su producto determina el costo total de la comisión de prioridad. Si se supera el límite, la transacción falla.CPI (invocación entre programas)
Mecanismo de Solana que permite que un programa en cadena llame a otro y le pase cuentas y datos de instrucciones. Es la primitiva que hace posible la componibilidad de Solana. Las CPI se exponen mediante la llamada al sistemasol_invoke_signed, que verifica que el invocador tenga los permisos adecuados para las cuentas transferidas. Las PDA permiten que los programas firmen en nombre de las cuentas que poseen.
Un programa invocado opera dentro del presupuesto de cómputo restante del programa invocador. Si agota el presupuesto o supera un límite establecido, falla toda la cadena de llamadas, incluida la transacción original.
Consulta la publicación del blog Máquina virtual de Solana para obtener más información.
Epoch
Conjunto de aproximadamente 432,000 slots de Solana. Es el intervalo organizativo de nivel superior en el que Solana actualiza su conjunto de validadores, calendario de líderes, delegaciones de stake y distribuciones de recompensas. Cada epoch dura unos 2 días con el objetivo de duración de slot actual. Consulta la publicación del blog Cómo funcionan los slots, bloques y epochs en Solana para obtener más información.Firedancer
Segundo cliente validador independiente de Solana, escrito desde cero en C por Jump Crypto. Los objetivos declarados de Firedancer son: (1) documentar y estandarizar el protocolo de Solana mediante una implementación independiente, (2) mejorar la diversidad de clientes (ningún cliente controla >33 % del stake) y (3) aumentar el rendimiento del ecosistema. Su arquitectura es modular: muchos procesos de Linux con un solo propósito llamados “tiles” (tile QUIC, tile de verificación, etc.) se comunican mediante memoria compartida, a diferencia del diseño de proceso único de Agave. Frankendancer es su implementación híbrida intermedia: combina el código de red C de alto rendimiento de Firedancer con el runtime y el código de consenso Rust de Agave. Consulta la publicación del blog ¿Qué es Firedancer? para obtener más información.Instrucción
La unidad de trabajo más pequeña dentro de una transacción de Solana: una única invocación de programa con las cuentas y los datos pertinentes. Una transacción agrupa una o más instrucciones que se ejecutan de forma atómica (todas se completan correctamente o todas se revierten). Consulta la publicación del blog El modelo de programación de Solana: introducción al desarrollo en Solana para obtener más información.Lamport
La unidad más pequeña de SOL: 1 SOL = 1,000,000,000 lamports (10⁻⁹ SOL). Su nombre proviene de Leslie Lamport, ganador del Premio Turing por su trabajo fundacional en sistemas distribuidos. Los métodos RPC sin procesar de Solana devuelven los saldos y las comisiones en lamports. La API de billeteras de Helius realiza la conversión automáticamente. Las comisiones de prioridad se expresan en microlamports: una millonésima parte de un lamport (10⁻¹⁵ SOL).Líder / Calendario de líderes
El líder es el validador asignado para proponer un nuevo bloque durante un slot determinado. Los líderes se eligen mediante un calendario aleatorio ponderado por stake que se calcula al inicio de cada epoch. Por eso, cualquier validador puede determinar de forma independiente quién liderará cada slot durante los próximos ~2-3 días. Cada líder recibe cuatro slots consecutivos (~1.6 segundos a ~400 ms por slot), lo que le da un breve periodo de producción consecutiva de bloques. Si un líder no produce un bloque en su slot, este se omite: la red continúa en lugar de esperar el bloque ausente. Los servicios de envío de transacciones como Sender enrutan las transacciones firmadas al líder actual y a los dos siguientes para maximizar la probabilidad de aterrizaje. Consulta la publicación del blog Consenso en Solana: Tower BFT y prueba de historial para obtener más información.Árbol de Merkle
Estructura de árbol criptográfico en la que cada nodo que no es una hoja contiene un hash de sus hijos, de modo que el único hash raíz representa todo el conjunto de datos. Para verificar que un dato pertenece al árbol, solo se necesitan los hashes hermanos de la ruta desde la hoja hasta la raíz, es decir, una prueba de Merkle. Esto requiere O(log n) datos sin importar el tamaño del árbol. En un árbol de profundidad 26, la prueba contiene 26 hashes hermanos (~832 bytes). Es una cantidad pequeña, pero sigue siendo necesaria para cada hoja: esta es la estructura de prueba que usan los NFT comprimidos. ZK Compression la sustituye por una única prueba de validez de tamaño constante que no crece con el conjunto de datos. Consulta la publicación del blog Introducción a las herramientas criptográficas: explicación de las funciones hash y los árboles de Merkle.Programa
Cuenta ejecutable que contiene bytecode sBPF compilado (es decir, un contrato inteligente en Solana). Los programas no tienen estado: leen y escriben cuentas de datos que poseen y se identifican mediante un ID de programa (su dirección de 32 bytes). Solana incluye un conjunto de programas nativos (System, Stake, Vote, etc.) integrados en el runtime. Todo lo demás es un programa implementado por un usuario. Consulta la publicación del blog El modelo de programación de Solana: introducción al desarrollo en Solana para obtener más información.Dirección derivada de programa (PDA)
Dirección determinista derivada de un ID de programa y un conjunto de semillas. Las PDA permiten que los programas firmen por las cuentas que controlan, lo que las vuelve esenciales para diseñar programas con estado. Las PDA se encuentran intencionalmente fuera de la curva, por lo que no existe una clave privada para ellas.Prueba de historial (PoH)
Primitiva de sincronización de Solana, no un algoritmo de consenso. PoH proporciona una función criptográfica de marca de tiempo que permite que los validadores acuerden el orden de los eventos sin comunicarse entre sí. Implementación: una cadena secuencial de hashes SHA-256 que se ejecuta continuamente en un único núcleo de CPU por validador y usa el resultado de cada iteración como entrada de la siguiente. La generación es secuencial y de un solo hilo; la verificación puede paralelizarse. PoH proporciona los “ticks” que determinan cuándo es válido un bloque. Los líderes deben publicar los bloques dentro de un intervalo determinado de ticks de PoH. Un bloque fuera de ese intervalo se considera omitido. PoH se ejecuta junto con Tower BFT, que es el mecanismo de consenso real. Consulta la publicación del blog Explicación de la prueba de historial, la prueba de participación y la prueba de trabajo para obtener más información.Renta / Exención de renta
El saldo de SOL que toda cuenta de Solana debe mantener para persistir en cadena, ajustado al tamaño de almacenamiento de la cuenta. Las cuentas deben crearse exentas de renta: las transacciones que dejen una cuenta por debajo del mínimo fallan. Una vez exenta de renta, la cuenta persiste indefinidamente sin pagos adicionales.Sealevel
Motor de ejecución paralela de transacciones de Solana. A diferencia de las máquinas virtuales secuenciales como la EVM, Sealevel ejecuta varias transacciones al mismo tiempo en distintos núcleos de CPU. Esto es posible porque cada transacción de Solana declara explícitamente qué cuentas leerá y escribirá antes de que comience la ejecución. Así, el planificador puede identificar lotes sin conflictos sin analizarlos durante el runtime. Las reglas de planificación son sencillas: las transacciones que acceden a cuentas diferentes se ejecutan en paralelo; las transacciones que solo leen las mismas cuentas también se ejecutan en paralelo (las lecturas no generan conflictos); y las transacciones que escriben en las mismas cuentas se ejecutan secuencialmente para evitar condiciones de carrera. Consulta la publicación del blog Máquina virtual de Solana para obtener más información.Slot
Unidad de tiempo fundamental de Solana durante la cual un validador líder designado tiene la oportunidad de producir un bloque. El objetivo actual de los slots es de 400 ms, aunque su duración real puede variar según las condiciones de la red. Si un líder no produce un bloque durante su slot, este se omite: la red continúa con el siguiente slot en lugar de esperar, por lo que no todos los slots generan un bloque. Consulta la publicación del blog Cómo funcionan los slots, bloques y epochs en Solana para obtener más información.SVM (máquina virtual de Solana)
La pila completa de ejecución de transacciones de Solana, no solo un intérprete de bytecode. La SVM incluye el componente Bank que coordina la ejecución, el planificador Banking Stage, los cargadores BPF y la propia máquina virtual sBPF (una VM basada en registros con 11 registros de propósito general y ~100 códigos de operación, compilada mediante JIT para mejorar el rendimiento). Esto difiere de la EVM, que se refiere inequívocamente a un único ejecutor de bytecode. Los programas de Solana se compilan en sBPF, la bifurcación de Linux eBPF de Solana. Cualquier lenguaje con un frontend LLVM (C, C++, Rust o Zig) puede usar sBPF como destino. Exigir que las transacciones declaren de antemano el acceso a las cuentas es lo que permite la ejecución paralela de Sealevel y los mercados de comisiones localizados de Solana. Consulta la publicación del blog Máquina virtual de Solana para obtener más información.Tower BFT
Mecanismo de consenso de Solana. Tower BFT es un algoritmo similar a pBFT que aprovecha el reloj sincronizado de la prueba de historial, lo que elimina la necesidad de una ronda de consenso síncrona en cada slot. Los validadores construyen una “torre de votos”: una pila secuencial de votos en la que cada voto nuevo duplica el periodo de bloqueo de todos los votos anteriores. Esto aumenta exponencialmente el costo en pérdida de stake al cambiar de bifurcación. Umbrales de confirmación: un bloque queda confirmado cuando recibe ≥2/3 de los votos ponderados por stake (habría que recortar ≥4.6 % del stake total para infringir la finalidad). Un bloque queda finalizado cuando tiene esos votos y 31 bloques posteriores construidos sobre él, el bloqueo máximo de Tower BFT. Consulta Nivel de compromiso para obtener recomendaciones de uso. Consulta la publicación del blog Consenso en Solana: Tower BFT y prueba de historial para obtener más información.Turbine
Protocolo de propagación de bloques de Solana. El líder divide cada bloque en shreds del tamaño de la MTU y shreds de recuperación con codificación de borrado Reed-Solomon. La tasa FEC (normalmente 32:32) permite que la red reconstruya un bloque incluso con una pérdida de paquetes de ~33 %. Después, el líder reenvía los shreds mediante un árbol determinista de validadores pares ponderado por stake (inicializado para cada grupo de shreds mediante(leader id, slot, shred index, shred type)), en lugar de transmitir directamente el bloque completo a todos los validadores. El árbol (DATA_PLANE_FANOUT = 200) mantiene casi constante el ancho de banda saliente del líder sin importar la cantidad de validadores y permite que los bloques lleguen a la red en 2–3 saltos en lugar de O(n).
Consulta la publicación del blog Turbine: propagación de bloques en Solana.
Validador
Nodo de la red de Solana que participa en el consenso produciendo bloques durante los slots en los que tiene asignado el liderazgo y votando por los bloques de otros validadores. Los validadores se seleccionan para los slots de liderazgo de forma proporcional a su stake activo.Mecánica de las transacciones
Tabla de consulta de direcciones (ALT)
Tabla en cadena de direcciones de Solana a la que una transacción con versión puede hacer referencia mediante un índice de 1 byte en lugar de una clave pública completa de 32 bytes. Esto permite que una sola transacción haga referencia a hasta 256 cuentas. Las ALT son esenciales para operaciones DeFi complejas que, de otro modo, superarían los límites de tamaño de las transacciones.Hash de bloque
Hash de 32 bytes que identifica un bloque reciente y se incluye en cada transacción de Solana para demostrar su vigencia. Los hashes de bloque vencen después de ~150 slots (~1 minuto). Las transacciones con hashes de bloque vencidos se rechazan. Los clientes obtienen un hash de bloque reciente mediantegetLatestBlockhash justo antes de firmar.
Comisión de prioridad
Propina por unidad de cómputo que se paga a los validadores para dar prioridad a una transacción sobre otras y acelerar su inclusión. Las comisiones de prioridad se establecen en microlamports por unidad de cómputo (µLamports/CU). La API de comisiones de prioridad de Helius devuelve estimaciones en tiempo real basadas en mercados recientes de comisiones en cadena.Shred
La unidad más pequeña de un bloque de Solana. Los bloques se dividen en shreds para propagarse en paralelo por la red de validadores mediante Turbine. El acceso a nivel de shred proporciona a los operadores señales en cadena con latencia ultrabaja antes del ensamblaje del bloque. Sin embargo, las Preconfirmations llegan incluso antes, antes de que las entradas se dividan en shreds. Consulta Shreds sin procesar (UDP) y la descripción general de Shred Delivery.Calidad de servicio ponderada por stake (SWQoS)
Mecanismo de Solana a nivel de protocolo que prioriza las transacciones entrantes dirigidas a los líderes actuales y próximos según el stake del remitente. SWQoS se introdujo después de la interrupción de Solana del 30 de abril de 2022 como medida de resistencia a ataques Sybil. Evita que los pares con poco stake o sin stake monopolicen el ancho de banda del líder durante periodos de congestión. El líder expone dos grupos de conexiones entrantes: ~500 conexiones abiertas compartidas entre todos los pares sin stake y ~2,000 conexiones ponderadas por stake distribuidas proporcionalmente entre los validadores con stake. Un validador que posee el X % del stake activo total puede enviar hasta el X % de los paquetes al líder. Los validadores con menos de ~15,000 SOL de stake activo (~1/25,000 del stake total de la red) se tratan como validadores sin stake. El umbral mínimo de stake se incorporó en Agave v1.17.31. Las conexiones con stake de Helius heredan esta ventaja en la tasa de aterrizaje al enrutar las transacciones de los clientes mediante el mayor validador de Solana. Así, quienes realizan las llamadas se benefician de SWQoS sin operar directamente un validador con una gran cantidad de stake. Consulta la publicación del blog Calidad de servicio ponderada por stake: todo lo que necesitas saber.Transacción con versión
Formato de transacción de Solana identificado mediante un byte de versión al principio de la transacción serializada. La versión 0 (v0) añadió las tablas de consulta de direcciones, que permiten que una transacción haga referencia a hasta 256 cuentas (en comparación con ~35 en las transacciones heredadas). La versión 1 (v1, SIMD-0385, Agave 4.2) mueve las firmas al final de la transacción y almacena el presupuesto de cómputo en un campo de encabezadotransactionConfig, en lugar de usar instrucciones ComputeBudget. Define maxSupportedTransactionVersion: 1 en las solicitudes RPC para recibir todas las versiones. Consulta Compatibilidad con transacciones v1.
Tokens y activos
Cuenta comprimida
Una cuenta comprimida es una cuenta de Solana cuyos datos se registran en el libro mayor mediante registros de transacciones. En el estado del validador solo se almacena una huella hash, en lugar de que todos los datos ocupen el espacio de una cuenta tradicional en los discos de los validadores. Los desarrolladores pueden tratar las cuentas comprimidas como cuentas normales. Los indexadores (como Photon) analizan los registros de transacciones para reconstruir el estado actual, y una prueba de conocimiento cero Groth16 de tamaño constante verifica la integridad cuando las cuentas se leen o modifican mediante ZK Compression. Este modelo es más adecuado para cuentas con pocos datos; con datos más grandes (más de ~100 bytes), la compresión deja de ser práctica.NFT comprimido (cNFT)
NFT de Solana representado como una hoja de un árbol de Merkle concurrente en cadena, en lugar de tener su propia cuenta. El árbol reside en una cuenta de Solana y sus transiciones de estado están protegidas por el libro mayor. Los indexadores derivan el estado actual del NFT a partir del historial de transacciones y generan pruebas de Merkle verificables con la raíz en cadena del árbol. Por lo tanto, para leer un cNFT se necesita un indexador como la API DAS. El RPC estándar de Solana no puede devolver directamente datos de cNFT. Este modelo reduce los costos de acuñación hasta un 99 % en comparación con los NFT estándar.Árbol de Merkle concurrente
Variante específica de Solana de un árbol de Merkle, diseñada para permitir que varios escritores actualicen el árbol en el mismo slot sin invalidar las pruebas de los demás. La cuenta en cadena no solo almacena la raíz actual, sino también un búfer de registro de cambios con raíces válidas recientes y una canopia (un subconjunto en caché de los nodos superiores del árbol). Esto permite que los validadores verifiquen pruebas generadas con cualquier raíz que aún se encuentre en la ventana del búfer. Tres parámetros definen un árbol: la profundidad máxima (limita la cantidad de hojas a 2^profundidad), el tamaño del búfer (profundidad del registro de cambios: cuántas escrituras pueden realizarse antes de que las pruebas anteriores en curso pierdan validez) y la profundidad de la canopia (que intercambia renta en cadena por pruebas más pequeñas dentro de las transacciones). Los pares válidos de (profundidad, búfer) van de (3, 8) a (30, 2048). Para mantener una componibilidad práctica, usamaxDepth − canopyDepth ≤ 10.
El programa SPL Account Compression implementa los árboles de Merkle concurrentes. Estos son la base de los NFT comprimidos, que se acuñan como hojas mediante Metaplex Bubblegum.
Consulta la publicación del blog Todo lo que necesitas saber sobre la compresión en Solana.
Groth16
Sistema de pruebas zk-SNARK que genera pruebas de conocimiento cero de tamaño constante (128 bytes en la curva BN254, con compresión de puntos), sin importar la complejidad de la afirmación, y con verificación O(1). ZK Compression usa Groth16 para generar pruebas de validez que demuestran que una cuenta comprimida pertenecía a un estado conocido en una raíz conocida. El tamaño reducido de las pruebas mantiene bajo el costo de las transacciones de cuentas comprimidas. Consulta la publicación del blog Creadores de Solana: ZK Compression.Cuenta de acuñación
Cuenta en cadena que define las propiedades de un token SPL: suministro, decimales y autoridades de acuñación y congelación. La dirección de la cuenta de acuñación es el identificador canónico del token (su “dirección de contrato” en términos de Ethereum).Token SPL
Token de Solana emitido mediante el Programa de Tokens de la biblioteca de programas de Solana (SPL). Los tokens fungibles (USDC, BONK, JUP, etc.) son tokens SPL. Los NFT estándar (no comprimidos) también son tokens SPL, acuñados con un suministro de 1 y 0 decimales. Los tokens SPL son aproximadamente el equivalente en Solana de ERC-20 y ERC-721 en Ethereum. Token-2022 es un programa más reciente que amplía esta interfaz con funcionalidades opcionales, como comisiones de transferencia y transferencias confidenciales.Árbol de estado
Árbol de Merkle que ZK Compression usa para almacenar los hashes de las cuentas comprimidas. La cuenta en cadena solo contiene la raíz actual y metadatos mínimos. Los datos comprimidos reales residen en los registros de transacciones y los reconstruyen indexadores como Photon. Los programas leen o modifican el estado comprimido enviando una prueba de validez que demuestra que el hash del contenido declarado de la cuenta corresponde a una hoja situada bajo la raíz actual. Consulta ZK Compression.Cuenta de token
Cuenta en cadena que contiene un saldo de un token SPL específico para un propietario determinado. Una billetera puede poseer cualquier cantidad de cuentas de tokens, pero la convención es usar una cuenta de token asociada (ATA): una cuenta de token derivada de forma determinista para cada par (billetera, acuñación), creada por el programa de cuentas de tokens asociadas.Token-2022 (extensiones de tokens)
Variante del Programa de Tokens SPL compatible con extensiones opcionales (por ejemplo, comisiones de transferencia, transferencias confidenciales, tokens que generan intereses y tokens no transferibles). Token-2022 se ejecuta como un programa en cadena independiente, con su propio ID de programa, pero está diseñado como sucesor compatible del Programa de Tokens clásico, por lo que los SDK normalmente pueden gestionar ambos. Las acuñaciones deben crearse mediante el programa Token-2022 para usar extensiones. Consulta la publicación del blog ¿Qué son las extensiones de tokens?.Prueba de validez
Prueba de conocimiento cero Groth16 de tamaño constante que demuestra que el contenido declarado de una cuenta comprimida existía en el árbol de estado en una raíz específica. Los programas de ZK Compression requieren una prueba de validez siempre que se leen o modifican cuentas comprimidas. Esta prueba permite que el programa verifique el estado fuera de cadena sin que el validador almacene los datos en cadena. Photon ofrece pruebas de validez a quienes realizan llamadas mediante su método RPCgetValidityProof.
Las pruebas de validez son lo que distingue a ZK Compression de los NFT comprimidos: los cNFT usan pruebas de Merkle simples (una lista de hashes hermanos desde la hoja hasta la raíz que crece con la profundidad del árbol), mientras que la prueba ZK de tamaño constante de ZK Compression no revela la ruta ni el estado circundante del árbol.
Consulta la publicación del blog Creadores de Solana: ZK Compression.
ZK Compression
ZK Compression es una primitiva de Solana desarrollada por Helius y Light Protocol que reduce considerablemente los costos de almacenamiento en cadena. Registra los datos de las cuentas en los registros de transacciones del libro mayor y solo almacena una huella hash en el estado del validador. La integridad criptográfica se conserva mediante pruebas de conocimiento cero Groth16 de tamaño constante generadas a partir de datos de transacciones indexados. Esta primitiva es diferente de los NFT comprimidos, que usan árboles de Merkle concurrentes sin pruebas de conocimiento cero. Consulta ZK Compression y la publicación del blog Creadores de Solana: ZK Compression para obtener más información.Conectividad y streaming
Geyser
Sistema de complementos de Solana para transmitir en tiempo real los cambios de estado de un validador —cuentas, transacciones, slots y bloques— a consumidores externos. Los validadores cargan los complementos de Geyser como bibliotecas dinámicas. El complemento recibe actualizaciones de estado a medida que el validador las procesa, lo que elimina la necesidad de consultar periódicamente el RPC para detectar cambios. Yellowstone gRPC, el complemento dominante de Geyser, expone esas actualizaciones mediante gRPC. LaserStream de Helius implementa la interfaz de Yellowstone gRPC con funcionalidades adicionales, como reproducción histórica (hasta ~216,000 slots / ~24 horas) y conmutación por error entre regiones.gRPC
gRPC es un protocolo RPC binario de propósito general y alto rendimiento (un acrónimo recursivo de “gRPC Remote Procedure Call”). En el contexto de Solana, “gRPC” suele referirse a Yellowstone gRPC: una interfaz de streaming basada en el sistema de complementos Geyser de Solana que expone actualizaciones de cuentas y transacciones mediante gRPC. El servicio LaserStream de Helius se basa en una interfaz derivada de Yellowstone e incorpora funcionalidades adicionales, como reproducción histórica, conmutación por error entre regiones e infraestructura administrada.RPC
RPC significa llamada a procedimiento remoto (Remote Procedure Call), un patrón general para invocar un método de servidor como si fuera una función local. En Solana, “RPC” suele referirse a un nodo RPC: un nodo que sigue el estado de Solana, pero no participa en el consenso y se especializa en atender solicitudes de datos (es decir, estado de cuentas, historial de transacciones y envío de transacciones) mediante una interfaz JSON-RPC. En cambio, los validadores producen bloques y votan por ellos. El servicio RPC de Helius es una flota de nodos RPC distribuida globalmente y optimizada para cargas de trabajo de producción. Consulta la publicación del blog Nodos de Solana: introducción a los RPC, validadores y proveedores de RPC de Solana para obtener más información.Webhook
Un webhook es una solicitud HTTP POST que un servidor envía a una URL receptora cuando ocurre un evento suscrito: HTTP “inverso”, donde el servidor inicia la llamada. Los webhooks de Helius envían eventos en cadena de Solana (transferencias, ventas de NFT y actividad de programas personalizados) a un endpoint registrado, lo que elimina la necesidad de realizar consultas periódicas.WebSocket (WSS)
Un WebSocket es una conexión TCP bidireccional persistente actualizada desde HTTP que se usa para transmitir datos de Solana mediante inserción sin repetir solicitudes HTTP. WSS (WebSocket Secure) es el mismo protocolo ejecutado mediante TLS y es la variante que se usa para las conexiones de producción de Solana. LaserStream WebSocket, el producto de streaming WebSocket de Helius que incluye los métodos estándar de Solana y extensiones de Helius comotransactionSubscribe, usa WSS.
Ecosistema
Anchor
Anchor es un framework de Rust para crear programas de Solana de forma rápida y segura. Gestiona mediante macros de procedimiento el código repetitivo, como la serialización y validación de cuentas y el despacho de instrucciones. Esto permite que los desarrolladores se concentren en la lógica del programa en lugar de los detalles de bajo nivel. La mayoría de los desarrolladores de Solana usan Anchor en lugar de escribir programas directamente en Rust nativo. Consulta la publicación del blog Introducción a Anchor: guía para principiantes sobre la creación de programas de Solana para obtener más información.IDL
IDL significa lenguaje de definición de interfaces (Interface Definition Language). Una IDL es un esquema JSON que describe las instrucciones, cuentas y tipos de datos de un programa de Solana. Los clientes lo usan para construir transacciones y decodificar datos de programas sin crear manualmente las estructuras de las instrucciones. Anchor genera las IDL automáticamente y, de forma predeterminada, las publica en cadena en una cuenta dedicada para que puedan descubrirse públicamente.Jito
Empresa del ecosistema de Solana que opera el motor de bloques dominante de la red: una capa de infraestructura de MEV (valor máximo extraíble) que acepta paquetes de transacciones (grupos atómicos de transacciones que se ejecutan juntos o no se ejecutan) y permite que los buscadores paguen propinas a los validadores para dar prioridad a su aterrizaje. El cliente validador Jito-Solana es una bifurcación de Agave con el motor de bloques integrado. La inclusión de un paquete requiere una propina mínima de 10,000 lamports, y Jito-Relayer retiene el tráfico entrante durante ~200 ms para permitir la subasta de paquetes fuera de cadena. Sender de Helius envía las transacciones simultáneamente mediante conexiones con stake y el motor de bloques de Jito, y usa la ruta que aterrice primero. Consulta la publicación del blog MEV de Solana: introducción.Light Protocol
El equipo de protocolo de Solana que desarrolló ZK Compression junto con Helius. Helius creó el indexador canónico (Photon) y opera el RPC público. Light Protocol desarrolla los programas en cadena y la pila de pruebas de los que depende el indexador. Consulta github.com/Lightprotocol/light-protocol.Photon
El indexador de código abierto de ZK Compression creado por Helius. Los datos de las cuentas comprimidas residen en los registros de transacciones de Solana, no en el estado de las cuentas. Por eso, los validadores no los exponen mediante el RPC estándar. Photon analiza las transacciones de Solana, reconstruye el estado de las cuentas comprimidas y lo ofrece mediante una interfaz JSON-RPC que reproduce el RPC nativo de Solana y añade métodos específicos de ZK Compression, comogetCompressedAccount e getValidityProof. Los desarrolladores pueden alojarlo por su cuenta desde github.com/helius-labs/photon o usar el endpoint alojado por Helius.
Consulta ZK Compression.