¿Qué son los niveles de compromiso de Solana?

¿Qué son los niveles de compromiso de Solana?

Los niveles de compromiso de Solana son una forma estandarizada de medir el consenso de la red sobre un bloque o una transacción determinados. Cuando consultas a un nodo RPC de Solana por el estado de una transacción o los datos de una cuenta (por ejemplo, getTransaction), puedes especificar un nivel de compromiso para indicar qué tan finalizados quieres que estén los datos. Solana usa este nivel de compromiso para permitir que los clientes equilibren latencia y certeza: un compromiso menor ofrece respuestas más rápidas, mientras que los niveles más altos dan a los desarrolladores más garantías de que el estado no se revertirá.

Solana define tres niveles de compromiso principales, en orden descendente de finalidad:

Finalizado

Es el nivel más alto de certeza. Indica que una supermayoría del stake (≥66 %) confirmó el bloque y que se construyeron sobre él al menos 31 bloques confirmados adicionales, lo que da al slot el bloqueo máximo de 32 votos. Una transacción finalizada es, en la práctica, irreversible.

Confirmado

Es un nivel intermedio en el que una supermayoría del stake (≥66%) votó por el bloque, pero este todavía no se ha finalizado mediante un periodo más largo de votación continua que dificulte su reversión. Esto suele llamarse confirmación optimista y ofrece una garantía sólida de que la transacción está en el “fork principal” o cadena canónica.

Procesado

Procesado significa que un líder acaba de procesar la transacción y la incluyó en el bloque más reciente que conoce el nodo. Sin embargo, es posible que ese bloque aún no tenga votos de todo el clúster. La transacción todavía podría descartarse si ese bloque no termina en el fork mayoritario.

Estos niveles representan las etapas del ciclo de vida de una transacción. 

Una transacción recién enviada pasa de Procesado → Confirmado → Finalizado a medida que más participantes de la red observan y votan por el bloque que la contiene, y se construyen bloques posteriores sobre él. Un compromiso mayor implica que más nodos aceptaron la inclusión de la transacción, lo que reduce el riesgo de un fork o una reversión. 

Exploremos cada nivel en detalle.

Nivel de compromiso Procesado

Una transacción se considera Procesada en cuanto un nodo validador (es decir, el líder actual) la incluye en un bloque. Este es el primer reconocimiento: la transacción se recibió y se incorporó localmente al estado del ledger.

Las características principales del nivel Procesado incluyen:

• Incluida en un bloque: La transacción se encuentra en un bloque producido por un validador.
• Sin garantía de pertenecer al fork mayoritario: Este bloque puede o no terminar en el fork mayoritario (más largo o pesado).
• Respuesta más rápida: Ofrece una respuesta inmediata de que un nodo procesó la transacción. Esto resulta útil para actualizaciones rápidas del lado del cliente (por ejemplo, mostrar una transacción pendiente en la interfaz de una wallet).
• Sin seguridad completa: En esta etapa, no hay garantía de que otros validadores hayan visto el bloque o votado por él. El clúster todavía podría “omitir” este bloque o sobrescribirlo con un fork alternativo. En otras palabras, Procesado = incluido, pero aún no confirmado por otros.

Ejemplo de un bloque procesado: 

Supongamos que Alice envía una transferencia en Solana. En cuanto el líder actual la agrega a un bloque (slot N), la transacción se marca como Procesada. La wallet de Alice podría mostrarla de inmediato como pendiente/procesada. 

Sin embargo, si la mayoría de los validadores no acepta el bloque de ese líder (por ejemplo, porque el líder fue lento o estuvo fuera de línea y otro fork tomó el control), la transacción de Alice podría desaparecer, es decir, descartarse, porque el bloque procesado no pasó a formar parte de la cadena principal.

Nivel de compromiso Confirmado

Un nivel de compromiso Confirmado indica que la supermayoría del clúster aceptó el bloque de la transacción y que es muy probable que forme parte de la cadena canónica. Técnicamente, “confirmado” significa que validadores que representan ≥66% del stake votaron directamente por ese bloque. 

Características principales:

• En el fork mayoritario: El bloque que contiene la transacción se reconoce como parte del fork mayoritario del ledger. Esto implica que la red lo considera un bloque canónico.

• Votos de una supermayoría: Al menos dos tercios del stake total votaron para confirmar el bloque. Estos votos se recopilan mediante el mecanismo de gossip de Solana, lo que significa que los validadores transmitieron y observaron votos por este bloque en toda la red. Esta etapa utiliza la confirmación optimista, introducida en Solana v1.3, que permite a los nodos tratar un bloque como confirmado en cuanto una supermayoría vota por él, incluso antes de que se finalice.

• Bajo riesgo de reversión: Con un consenso del 66% o más, es muy poco probable, aunque no imposible, que un fork en conflicto sustituya este bloque. En la práctica, todos los validadores honestos se han comprometido con este bloque, salvo que ocurra una reorganización importante. Ningún bloque confirmado se ha revertido en los cinco años de historia de Solana.

• Más rápido que Finalizado: El estado confirmado suele alcanzarse poco después, en uno o dos segundos, de que un bloque o una transacción se marque como procesado, ya que los validadores votan rápidamente por los bloques nuevos. No espera muchos bloques posteriores. Por eso, en condiciones normales, Confirmado ofrece un buen equilibrio entre velocidad y confianza.

• Finalidad optimista: A menudo, los desarrolladores consideran que una transacción confirmada es prácticamente final para la mayoría de los fines, dado el rápido consenso de Solana. Sin embargo, existe una pequeña posibilidad de reversión hasta que se finalice.

Ejemplo de un bloque confirmado: 

La transacción anterior de Alice pasa a estar Confirmada cuando los validadores del clúster votan por el bloque N. En la práctica, si los siguientes validadores, en los slots N+1, N+2, etc., votan y ven el bloque N hasta alcanzar el umbral del 66%, la red marca el bloque N como confirmado. La wallet de Alice ya puede mostrar de forma segura la transacción al usuario como confirmada. 

La probabilidad de que la transferencia de Alice se revierta en este momento es muy baja; solo ocurriría ante un fork inusual o un problema de red. Esto es análogo a las “N confirmaciones” de otras cadenas, pero en Solana se basa en la votación ponderada por stake, no en un número fijo de confirmaciones de bloques.

Nivel de compromiso Finalizado

Una transacción está Finalizada cuando una supermayoría votó por su bloque y se construyeron suficientes bloques adicionales sobre él. En el consenso de Solana, esto corresponde a que el bloque alcance el bloqueo máximo, normalmente después de que 32 votos consecutivos (slots) lo hayan confirmado. Finalizado es el nivel de compromiso más fuerte y ofrece el máximo grado de certeza de que la transacción no se revertirá. 

Las características de Finalizado incluyen:

• Bloque irreversible: El clúster reconoció este bloque como finalizado, lo que significa que se ha arraigado en el estado del ledger. Los validadores no lo revertirán y, en la práctica, es permanente.

• Supermayoría + bloqueo: Al igual que con Confirmado, al menos el 66% del stake respaldó el bloque. Además, después de él se agregaron 31 o más bloques confirmados posteriores. En otras palabras, la red construyó una cadena profunda sobre este bloque y alcanzó una profundidad de bloqueo en la que una reorganización no es viable.

• Bloqueo máximo (32 votos): El mecanismo Tower BFT de Solana duplica exponencialmente el periodo de bloqueo de los votos. Cuando un bloque acumula 32 votos en la torre, lo que significa que permaneció en la cabecera del fork durante 32 slots adicionales, alcanza el bloqueo máximo y se finaliza. En ese momento, cualquier validador que intente votar por un fork alternativo infringiría las reglas de consenso.

• Máxima seguridad, confirmación más lenta: La finalización suele retrasarse respecto de los niveles Procesado y Confirmado (unos ~10-20 segundos en condiciones normales, ya que 32 slots de ~400 ms cada uno ≈ 13 segundos). Este es el costo de la certeza de Finalizado. Al esperar la finalización, los clientes eliminan todo riesgo de que la transacción se descarte o revierta, a cambio de latencia adicional.

• Confirmado + bloques construidos encima: Otra forma de entender la finalización es que se trata de un bloque confirmado que quedó enterrado bajo muchos más bloques. Todos los nodos honestos bloquearon de forma verificable este bloque como parte del ledger permanente.

Ejemplo de un bloque finalizado:

La transacción de Alice alcanza el estado Finalizado después de que la red continúa produciendo bloques más allá del slot N. Supongamos que, para el slot N+32, una supermayoría de validadores votó por cada bloque sucesivo hasta N+32, sin que ningún fork tomara el control. El bloque N, que contiene la transacción de Alice, ahora está finalizado. 

En este momento, la transacción de Alice es completamente permanente en el ledger de Solana. Aunque espere un tiempo, el estado que incluye su transferencia no cambiará. 

Cualquier aplicación que requiera una finalidad sólida, como un exchange que libera fondos, ya puede actuar de forma segura según esta transacción. En particular, si un atacante intentara revertirla, tendría que controlar más de un tercio del stake e infringir el consenso.

Niveles de compromiso obsoletos

Las versiones anteriores de Solana, previas a 2021, exponían niveles de compromiso adicionales que desde entonces se han marcado como obsoletos en favor de los tres anteriores.

Para ofrecer una visión completa, estos son los términos heredados y su correspondencia con los niveles actuales:

• recent – Obsoleto; equivale a Procesado. En la documentación anterior, “recent” simplemente hacía referencia al estado más reciente conocido por el nodo.

• single y singleGossip – Obsoletos; equivalen a Confirmado. Hacían referencia a confirmaciones de un solo validador o mediante gossip, lo que coincide con la definición de confirmado.

• root y max – Obsoletos; equivalen a Finalizado. “Root” hacía referencia al estado arraigado y finalizado en el clúster, mientras que “max” hacía referencia al bloqueo máximo; ambos significaban, en la práctica, finalizado.

Hoy, los desarrolladores solo deben usar processed, confirmed o finalized al especificar un nivel de compromiso. Desde la versión v1.5.5, la API JSON-RPC de Solana usa estos términos de forma predeterminada y trata los términos obsoletos como alias de sus niveles correspondientes. 

Además, si una solicitud RPC no especifica un compromiso, el valor predeterminado es Finalized, es decir, el nodo devuelve por defecto el estado con mayor grado de finalización.

Diferencias entre los niveles de compromiso

Las diferencias entre Procesado, Confirmado y Finalizado pueden entenderse según qué parte de la red reconoció la transacción y qué probabilidad existe de que se revierta. La siguiente tabla, adaptada de la documentación oficial de Solana, resume las distinciones principales:

En resumen, Procesado solo significa que la transacción está en un bloque, nada más. Confirmado significa que el clúster aceptó ese bloque mediante votos de una supermayoría, pero aún está cerca de la punta de la cadena. Finalizado significa que el bloque está a gran profundidad en la cadena y tiene muchas confirmaciones, tanta profundidad que, en la práctica, es inmutable.

Otra forma de entender la diferencia es mediante la probabilidad de que la transacción permanezca en el ledger canónico con el paso del tiempo. 

Inmediatamente después de procesarse, la probabilidad no es del 100% porque existe la posibilidad de un fork o una falla. Una vez que más del 66% del stake la confirma, la probabilidad de inclusión aumenta considerablemente. Cuando se finaliza con decenas de bloques construidos encima, la probabilidad de inclusión es de ~100%. 

Esto se ilustra en el siguiente gráfico, que muestra cómo aumenta la probabilidad de que una transacción se finalice a medida que pasan más slots y sube el nivel de compromiso:

La probabilidad de que una transacción se incluya en la cadena canónica final aumenta con el tiempo. Al principio, en el slot n (transacción procesada), existe cierto riesgo de que la transacción se “omita” o quede fuera debido a un fork. Con la confirmación optimista (confirmada), la probabilidad de inclusión aumenta drásticamente a medida que los validadores votan. Después de que se construyan sobre ella suficientes forks consecutivos (finalizada), la probabilidad de reversión se vuelve prácticamente nula. Esto demuestra que el riesgo de reversión disminuye a medida que aumenta el nivel de compromiso.

¿Cómo determina Solana los niveles de compromiso?

Comprender cómo funciona el consenso de Solana “por dentro” ayuda a entender por qué existen estos niveles de compromiso:

Proof of History (PoH) y producción de bloques

Los líderes de Solana producen bloques en rápida sucesión (un líder por slot, con slots de ~400 ms). Las transacciones se transmiten a una cadena de hashes de Proof of History (PoH), donde forman entradas dentro de un bloque. Los bloques se propagan rápidamente por la red mediante Turbine, el protocolo de propagación de bloques de Solana. Cuando un líder produce un bloque con tu transacción, ese bloque se propaga de inmediato, pero aún no está confirmado. Esto corresponde a la etapa Procesado.

Votación (Tower BFT)

Solana usa un algoritmo de consenso BFT llamado Tower BFT. Los validadores, cada uno con control sobre cierta cantidad de stake, votan por los bloques que consideran que deben convertirse en la siguiente parte del ledger. Los votos también son transacciones de Solana e incluyen un concepto de bloqueo. Cada vez que un validador vota por un bloque en el slot N, asume un bloqueo. Si después vota por un fork en conflicto, podría perder la capacidad de votar durante cierto tiempo. 

Estos bloqueos se duplican exponencialmente con cada voto sucesivo en el mismo fork (1, 2, 4, 8... slots de bloqueo) y alcanzan su límite con 32 votos. Si un validador votó 32 veces seguidas en un fork, lo que significa que el bloque de 32 slots atrás todavía forma parte del fork más pesado, ese bloque alcanza el bloqueo máximo. Este mecanismo incentiva a los validadores a mantener su apoyo al fork mayoritario y finalizar los bloques.

Confirmación (confirmación optimista)

Cuando se produce un bloque, los validadores transmiten votos por él. En cuanto una supermayoría del stake (≥66%) vota por un bloque, los nodos de Solana lo consideran confirmado de forma optimista. Este es el nivel de compromiso Confirmado. Ocurre rápidamente, a menudo uno o dos slots después del bloque, porque los votos se propagan mediante gossip. 

Es importante señalar que la implementación de Solana no exige esperar a que el bloque se arraigue en el ledger. Confía en el voto de la supermayoría como señal optimista de que el bloque terminará por finalizarse, siempre que menos del <33% del stake actúe de forma indebida. 

Por eso se llama confirmación optimista: bajo las suposiciones normales sobre fallas bizantinas, con un máximo de un tercio de participantes deshonestos, el voto de una supermayoría significa que el bloque no se revocará. Para que un fork lo sustituyera, más del 33% de los validadores tendría que votar por una cadena alternativa, lo que rompería dichas suposiciones.

Finalización (arraigo de un bloque)

A medida que se siguen produciendo bloques nuevos y los validadores votan por ellos, cada bloque confirmado avanza a mayor profundidad en el fork. Cuando un bloque acumula votos durante 32 slots consecutivos posteriores, alcanza el bloqueo máximo. En ese momento, la red arraiga ese bloque y lo marca como finalizado e irreversible. La finalización significa que el bloque está al menos 31 bloques detrás de la cabecera y que nunca se abandonó en favor de otro fork. Todos los nodos consideran ahora que este bloque forma parte del historial inmutable; el estado del ledger hasta ese slot queda congelado. 

En la práctica, el compromiso Finalizado equivale a “el bloque tiene ≥32 confirmaciones” en una analogía con una cadena PoW, pero Solana lo logra mediante votos con bloqueo temporal, no mediante confirmaciones de proof-of-work. La regla de 32 slots es consecuencia del diseño de Tower BFT, cuyos bloqueos se duplican hasta 2^32, y ofrece una garantía matemática de finalidad bajo la suposición de tolerancia a fallas de un tercio.

Selección de forks y reversión

El consenso de Solana evalúa los forks de forma continua. Los validadores usan un algoritmo de selección del fork más pesado, basado en el peso de los votos según el stake, para decidir sobre qué fork construir. Si solo un subconjunto de validadores procesa un bloque y este no recibe votos, otro fork puede sustituirlo. Por eso una transacción Procesada puede descartarse. 

Una vez que dos tercios confirman un bloque, un fork alternativo necesitaría el respaldo de más de un tercio del stake para ganar. Esto es muy poco probable e implicaría un comportamiento malicioso. 

Después de la finalización, es prácticamente imposible que un fork revierta ese bloque sin una falla catastrófica del consenso. Aunque la red se detuviera o sufriera un ataque, revertir slots finalizados exigiría coordinación fuera de las reglas del protocolo.

Para resumir los mecanismos: Procesado = bloque producido (PoH), pero aún sin una votación amplia; Confirmado = los votos del clúster (Tower BFT) alcanzaron una supermayoría para el bloque (consenso optimista); Finalizado = el bloque permaneció como “raíz” de la cadena después de muchos más votos (finalidad absoluta del consenso). El diseño de Solana garantiza que los bloques confirmados se finalicen tras una breve espera, lo que ofrece una confirmación rápida y una finalidad absoluta posterior.

Casos de uso para desarrolladores según el nivel de compromiso

Elegir el nivel de compromiso adecuado es crucial al desarrollar en Solana. Cada aplicación tiene requisitos diferentes de velocidad y certeza. 

Estos son los casos de uso y las prácticas recomendadas típicas para cada nivel:

Usa Procesado para respuestas inmediatas y operaciones no críticas

Los desarrolladores pueden usar el compromiso Procesado en situaciones donde la velocidad es primordial y se acepta cierto riesgo de reversión. Por ejemplo, durante el desarrollo y las pruebas, tal vez quieras una confirmación instantánea de que un validador recibió una transacción. 

Las aplicaciones con interfaz de usuario, como wallets o juegos, podrían mostrar una transacción de forma optimista en cuanto se procese para mejorar la experiencia del usuario; por ejemplo, mostrando un estado “pendiente”. 

Sin embargo, como no se garantiza que las transacciones procesadas permanezcan, este nivel no se recomienda para flujos críticos de producción. Si lo usas, debe ser para transacciones de poco valor o no críticas, donde una posible reversión no cause problemas graves.

Usa Confirmado para la mayoría de las transacciones

El nivel Confirmado suele ser la opción predeterminada recomendada para muchos casos de uso en Solana. Ofrece una garantía sólida de éxito con un impacto mínimo en la latencia. 

Por ejemplo, una aplicación DeFi que realiza un intercambio de tokens o un usuario que transfiere fondos suelen depender del estado confirmado: una vez confirmada la transacción, la aplicación puede considerarla completada en condiciones normales. Este nivel reduce considerablemente la probabilidad de que una transacción se descarte en comparación con Procesado. Una práctica recomendada es usar el nivel de compromiso Confirmado, especialmente al consultar blockhashes recientes y enviar transacciones, porque ofrece un mejor equilibrio entre latencia y seguridad.

Usa Finalizado para transacciones críticas y de alto valor

Cuando necesitas certeza absoluta, como en movimientos de activos de alto valor, puentes entre cadenas o confirmaciones de depósitos en exchanges, debes usar el nivel de compromiso Finalizado. Esto es habitual en situaciones donde incluso un riesgo mínimo de reversión resulta inaceptable. 

Por ejemplo, un exchange podría esperar a que una transacción se finalice antes de acreditar un depósito en la cuenta de un usuario. Así evita cualquier posibilidad de que una reorganización posterior deshaga el depósito. 

Otro caso es después de una serie de transacciones: puedes verificar que el estado final esté finalizado antes de considerar que una operación compleja terminó, por ejemplo, en una auditoría o un proceso de liquidación que requiere el estado final del ledger. 

Los desarrolladores deben tener presente que exigir un compromiso Finalizado agrega latencia y, con una carga elevada en la red, puede aumentar la probabilidad de que la transacción caduque, ya que esperas a que se finalice el hash de un bloque más antiguo. Debes usar Finalizado con prudencia y solo para las transacciones más críticas, donde la seguridad adicional compense la latencia.

En resumen, Procesado se usa principalmente para obtener respuestas rápidas y fuera de producción; Confirmado es la opción habitual para la mayoría de las operaciones porque equilibra seguridad y rendimiento; y Finalizado se reserva para situaciones donde realmente necesitas una finalidad garantizada a pesar de la espera. 

Muchas aplicaciones usan una combinación: actualizan la interfaz con Procesado, consideran completada la operación con Confirmado y la registran al alcanzar Finalizado.

Impacto en la confiabilidad, el rendimiento y la seguridad de las transacciones

La elección del nivel de compromiso tiene consecuencias directas en la confiabilidad (¿permanecerá la transacción?), el rendimiento (latencia) y la seguridad (riesgo de doble gasto o problemas con forks):

Confiabilidad

Los niveles de compromiso más altos aumentan la certeza de que una transacción quede registrada de forma permanente. Una transacción finalizada tiene prácticamente un 100% de confiabilidad en cuanto a su permanencia en el ledger, salvo acontecimientos extraordinarios. Una transacción confirmada tiene una confiabilidad muy alta, pero no del 100%, y las transacciones procesadas tienen una confiabilidad menor. 

Como se indicó antes, alrededor del ~5% de las transacciones podrían terminar descartadas si solo se considera el estado procesado debido a los cambios de forks, mientras que la confirmación reduce ese riesgo casi al 0%. 

En aplicaciones críticas, usar el compromiso Finalizado elimina el riesgo de que tu transacción esté en un fork que se descarte posteriormente.

Rendimiento (latencia)

Existe una clara compensación entre la rapidez con la que recibes una confirmación y el nivel de compromiso. 

La confirmación Procesado es casi instantánea: ocurre dentro del tiempo del bloque y, a menudo, en menos de un segundo. 

Confirmado agrega una breve espera, del orden de uno o dos slots, quizá ~0.5–1 segundo adicional, para recopilar los votos de los validadores. Sigue siendo muy rápido y, en la práctica, los usuarios normalmente no lo perciben. 

Finalizado agrega la mayor espera, ya que la transacción solo se registra como finalizada cuando se producen unos 30 o más bloques posteriores. Normalmente, tarda ~10-20 segundos en alcanzar la finalidad. 

Durante periodos de congestión de la red o producción lenta de bloques, la espera podría ser mayor. Por eso, exigir un compromiso Finalizado puede ralentizar la experiencia del usuario y reducir el throughput si se usa en exceso. Si una aplicación espera la finalización, debe tener en cuenta ese tiempo adicional. Sin embargo, esto no significa que la transacción tarde más en ejecutarse onchain. Significa que el cliente espera más para verificar que se finalizó. Mientras tanto, Solana continúa procesando transacciones nuevas.

Throughput frente a caducidad

Existe un efecto importante y sutil sobre la caducidad de las transacciones y el uso de blockhashes. Las transacciones de Solana incluyen un blockhash reciente y solo son válidas durante ~150 slots después de ese blockhash. 

Si solicitas un blockhash finalizado para firmar tu transacción, ese blockhash será más antiguo porque la finalización va por detrás de la punta. Por lo tanto, quedarán menos slots antes de que la transacción caduque. Esto puede aumentar la probabilidad de caducidad si la red está congestionada y tu transacción no se procesa rápidamente. 

Usar un blockhash más reciente (Confirmado) ofrece una ventana más amplia. La recomendación oficial es usar Confirmado para getLatestBlockhash y así reducir el riesgo de caducidad. 

Por lo tanto, usar Finalizado para el preflight o el blockhash puede reducir ligeramente el tiempo disponible para que tu transacción se procese, lo que afecta la confiabilidad bajo carga. 

En resumen, un compromiso Finalizado puede reducir algo la disponibilidad durante periodos de carga intensa: obtienes certeza, pero posiblemente a cambio de más vencimientos de transacciones si la red está cerca de su capacidad máxima.

Seguridad

Desde la perspectiva de la seguridad, como la prevención del doble gasto y la protección frente a forks, Finalizado es la opción más segura. 

Una vez finalizada, revertir una transacción exigiría que más de un tercio del stake total actuara de forma maliciosa, algo que probablemente se detectaría y castigaría. 

Confirmado es muy seguro en condiciones normales. Un atacante tendría que crear un fork en conflicto y convencer a más del 33% de los validadores para que lo respaldaran después de que una supermayoría ya hubiera votado. Esto es extremadamente improbable sin un ataque coordinado importante. 

Sin embargo, Confirmado tiene un escenario teórico en el que un bloque confirmado podría quedar huérfano si algunos validadores, justo por debajo del 33%, retuvieran sus votos o un fork estuviera justo en el límite. No obstante, el diseño de Solana, mediante la confirmación optimista, supone una mayoría honesta para disuadir este comportamiento. 

Procesado ofrece la menor seguridad: hasta que llegan los votos, no existe garantía de que otro validador siquiera conozca la transacción. Un líder malicioso podría incluir una transacción y luego no transmitir correctamente el bloque, entre otras posibilidades. 

Por eso no debes depender de Procesado para ninguna confirmación crítica de seguridad. Se parece más a una “notificación” de que el proceso comenzó. 

En resumen: Finalizado > Confirmado > Procesado en cuanto a seguridad frente a forks y doble gasto.

Uso del compromiso en lecturas y escrituras

Cuando lees el estado de Solana, por ejemplo al consultar el saldo de una cuenta mediante RPC, también especificas un nivel de compromiso. Si usas un nivel de compromiso Procesado para una lectura, puedes ver datos muy recientes, pero podrían proceder de un fork no finalizado. Usar Finalizado para las lecturas ofrece consistencia absoluta, es decir, el estado que todos aceptan, pero puede llevar algunos slots de retraso. En la mayoría de los casos, usar Confirmado para las consultas de estado ofrece un buen equilibrio, al igual que con las transacciones. Así evitas tomar decisiones basadas en un fork que podría revertirse. 

Para las consultas de escritura, es decir, el envío de transacciones, el compromiso afecta principalmente la forma en que la biblioteca cliente espera la confirmación. Un patrón habitual es enviar una transacción con cierto preflightCommitment, que podría simular la TX contra el estado más reciente, y luego usar confirmTransaction con el mismo nivel de compromiso. Los desarrolladores pueden decidir esperar una confirmación finalizada si es necesario.

Para expresarlo con cifras reales: según mediciones recientes, Solana procesó una transacción en ~0.4 segundos, alcanzó el estado confirmado en ~0.6 segundos y logró la finalización en ~13 segundos. 

Si tu aplicación, por ejemplo una aplicación de pagos, no puede esperar ~13 segundos por transacción, debes usar Confirmado, que aun así ofrece una seguridad sólida. 

Si transfieres una gran cantidad entre cadenas, puedes optar por esperar los ~13 segundos completos para tener absoluta certeza. Por otro lado, si desarrollas algo donde la velocidad es fundamental y aceptas un pequeño riesgo, como actualizar una interfaz de forma optimista, podrías usar el estado Procesado para ofrecer una experiencia ágil.

Conclusión

Los niveles de compromiso de Solana —Procesado, Confirmado y Finalizado— son una función esencial que permite a los desarrolladores adaptar el equilibrio entre velocidad y certeza para cada transacción.

Procesado ofrece resultados inmediatos pero inciertos, Confirmado proporciona una garantía casi final en uno o dos segundos, suficiente para la mayoría de las aplicaciones, y Finalizado ofrece finalidad absoluta después de un tiempo adicional. 

Por dentro, estos niveles corresponden al avance del consenso de Solana: desde la producción de un bloque y la votación de una supermayoría hasta su arraigo en el ledger con el bloqueo máximo.

Al desarrollar en Solana, es fundamental elegir el nivel de compromiso adecuado para cada tarea:

• Usa compromisos menores para obtener respuestas rápidas o realizar acciones no críticas.
• Usa Confirmado para operaciones estándar en las que necesitas velocidad y seguridad.
• Usa Finalizado cuando solo sea aceptable una finalidad total.

Cada nivel afecta la confiabilidad de la inclusión de la transacción y el tiempo de espera. 

Al comprender el significado técnico —66% de votos, 32 bloques, forks y bloqueos— y seguir las prácticas recomendadas más recientes, los desarrolladores pueden obtener el rendimiento que promete Solana sin sacrificar la consistencia ni la seguridad de sus aplicaciones.

Recursos adicionales

• Documentación de Solana – Configuración del compromiso de estado, Tabla de estados de compromiso
• Blog de Helius – Consenso en Solana (mecanismos de consenso y finalidad)