Mecanismo de Consenso de Solana: PoH, Tower BFT, PoS

Nota sobre precisión: El rendimiento de la red, el recuento de validadores, las comisiones, las características del protocolo, el soporte de carteras y las integraciones de terceros cambian con el tiempo. Trate las cifras fechadas como instantáneas históricas y verifique la documentación actual de fuentes primarias.

El mecanismo de consenso de Solana combina Proof of History para el ordenamiento temporal, Tower BFT para la votación ponderada por staking y Proof of Stake para la participación e incentivos de los validadores.

Resumen: Solana utiliza Proof of History para el ordenamiento temporal, Tower BFT para la votación ponderada por el staking y la elección de Fork, y Proof of Stake para la participación e incentivos de los validadores. El rendimiento y la confirmación dependen del tiempo de ejecución completo, las condiciones de la red, la combinación de transacciones y el nivel de compromiso que se esté midiendo.

Contenidos

1. ¿Qué es el Mecanismo de Consenso de Solana?
2. El problema que Solana fue creada para resolver
3. Proof of History: El reloj criptográfico de Solana explicado
4. Tower BFT: Cómo llegan a un acuerdo los validadores
5. Cómo trabajan juntos Proof of History, Tower BFT y Proof of Stake
6. Cómo alcanza la finalidad una transacción de Solana: paso a paso
7. Rendimiento de Solana: velocidad, capacidad y finalidad
8. Consenso de Solana frente a Ethereum, Avalanche, Cardano y Polkadot
9. Fortalezas y limitaciones del modelo de consenso de Solana
10. Cómo participar: Staking y validación en Solana
11. Preguntas frecuentes
12. Conclusiones clave

Solana está diseñada para una ejecución de alto rendimiento y baja latencia, mientras que su historial de interrupciones y los requisitos de los validadores plantean importantes cuestiones sobre fiabilidad y descentralización. Esos compromisos son fundamentales para entender el mecanismo de consenso.

Solana lanzó su Mainnet Beta en marzo de 2020 y rápidamente atrajo la atención por procesar miles de transacciones por segundo a fracciones de céntimo por transacción. Los protocolos DeFi y los mercados NFT construidos sobre Solana dependen de ese rendimiento; es lo que hace que el trading en tiempo real, las acuñaciones masivas de NFT y los pagos de microcomisiones sean prácticos on-chain. Pero la velocidad sin fiabilidad no es una base sobre la cual nadie deba construir, y varios eventos de interrupción de alto perfil entre 2021 y 2023 plantearon preguntas legítimas sobre si la arquitectura del protocolo es sólida.

Este artículo explica el mecanismo con honestidad: cómo funciona, por qué es rápido, por qué se ha detenido la red y qué significan las compensaciones para cualquiera que evalúe Solana como inversor, desarrollador o participante.

¿Qué es el Mecanismo de Consenso de Solana?

Solana utiliza un sistema de consenso híbrido que combina tres componentes: Proof of History (PoH), Tower BFT y Proof of Stake (PoS). Proof of History actúa como un reloj criptográfico que pone marcas de tiempo a las transacciones antes de que los validadores se comuniquen. Tower BFT es el algoritmo de acuerdo de Tolerancia a Faltas Bizantinas que alcanza el consenso utilizando PoH como reloj compartido. Proof of Stake determina qué validadores participan y pondera sus votos según el SOL en el que se haya decidido participar en staking.

Estos tres componentes no son nombres intercambiables para la misma cosa. Cada uno desempeña un papel distinto en cómo Solana produce y confirma bloques en su Blockchain, el Ledger distribuido que registra todas las transacciones de la red.

Así es como opera el sistema a alto nivel:

1. Proof of History genera un registro de tiempo continuo y verificable que comparten todos los validadores de la red.
2. Los validadores (los participantes de la red que producen y verifican bloques) se asignan a franjas horarias específicas en función de cuánto SOL han puesto al participar en staking.
3. El validador líder asignado para cada franja utiliza la línea de tiempo de PoH para poner marcas de tiempo y ensamblar transacciones en un bloque.
4. Todos los demás validadores verifican el bloque y emiten votos Tower BFT ponderados por su staking; cuando más de dos tercios del SOL en staking confirma el bloque, este alcanza la finalidad.

Concepto erróneo común: Solana no es una Blockchain de Proof of Work (no hay resolución de acertijos computacionales ni computación intensiva en energía). Llamar a Solana simplemente "una Blockchain de Proof of Stake" es técnicamente exacto pero incompleto. Omite Proof of History y Tower BFT, que son igualmente centrales para la forma en que Solana alcanza el consenso. La descripción completa y precisa es: Solana utiliza un sistema híbrido que combina PoH, Tower BFT y PoS.

El problema que Solana fue creada para resolver

Cada mecanismo de consenso de Blockchain se enfrenta al mismo desafío fundamental: ¿cómo se ponen de acuerdo miles de ordenadores distribuidos geográficamente sobre el orden de las transacciones sin confiar unos en otros?

El trilema de la escalabilidad de la Blockchain, un marco popularizado por el cofundador de Ethereum, Vitalik Buterin, describe por qué esto es difícil. El trilema establece que una Blockchain puede alcanzar de forma realista, como máximo, dos de tres propiedades simultáneamente: descentralización, seguridad y escalabilidad. Bitcoin, la Blockchain original, prioriza la descentralización y la seguridad. El resultado es una red que logra aproximadamente 7 transacciones por segundo con tiempos de bloque de 10 minutos, propiedades que son seguras y están ampliamente distribuidas, pero que hacen que Bitcoin sea poco práctico para aplicaciones de alta frecuencia. El Ethereum temprano enfrentó limitaciones similares antes de su propio camino de actualización.

El cuello de botella específico que dificulta la escalabilidad es la latencia de la red. En el consenso de Blockchain tradicional, los validadores deben enviarse mensajes con marcas de tiempo entre sí para acordar el orden de las transacciones. Esta sobrecarga de comunicación entre nodos crea un techo sobre la rapidez con la que cualquier red puede llegar a un acuerdo. No importa cuán rápido procesen los datos los ordenadores individuales, todavía tienen que esperar a que los mensajes viajen por todo el mundo y a que todos los participantes confirmen lo que recibieron.

Anatoly Yakovenko, un antiguo ingeniero de Qualcomm que dedicó su carrera a trabajar en sistemas distribuidos y sincronización de relojes a nivel de hardware, identificó este problema de comunicación de marcas de tiempo como el cuello de botella fundamental. Su idea clave: si los validadores pudieran compartir un único reloj criptográficamente verificable en el que todos confiaran sin necesidad de comunicarse marcas de tiempo entre sí, el proceso de consenso podría ser drásticamente más rápido. En noviembre de 2017, Yakovenko publicó Solana: A new architecture for a high performance blockchain, esbozando lo que se convertiría en Proof of History. Cofundó Solana Labs (la empresa de desarrollo con fines de lucro detrás del protocolo Solana) con Greg Fitzgerald y Raj Gokal, y los tres lanzaron la Mainnet Beta en marzo de 2020.

La tesis de diseño de Solana es que el trilema de la escalabilidad puede reducirse significativamente —no eliminarse, pero sí reducirse— combinando enfoques criptográficos novedosos (PoH) con capacidades de hardware modernas para impulsar las tres métricas simultáneamente. Si esa reducción ha tenido un coste en la descentralización es una pregunta que la evidencia en este artículo aborda directamente.

Proof of History: El reloj criptográfico de Solana explicado

Proof of History (PoH) es un mecanismo criptográfico de cronometraje que crea un registro verificable y a prueba de manipulaciones de cuándo ocurrió cada evento en la red Solana. Al dotar a todos los validadores de un reloj compartido en el que pueden confiar sin intercambiar mensajes, PoH permite que el algoritmo de consenso real de Solana, Tower BFT, funcione con muchas menos rondas de comunicación que cualquier sistema de consenso de Blockchain estándar.

PoH no es un Mecanismo de Consenso. Es el reloj que hace posible el mecanismo de consenso de Solana.

¿Qué problema resuelve Proof of History?

En una red distribuida sin una autoridad central, los validadores no pueden simplemente acordar el uso de un reloj de pared. Cada nodo funciona en hardware diferente en distintas zonas horarias, y los relojes se desincronizan. Lo que es más importante, un validador malicioso podría falsificar marcas de tiempo para manipular el orden de las transacciones. Las redes Blockchain tradicionales resuelven esto haciendo que los validadores se envíen mensajes con marcas de tiempo entre sí y lleguen a un acuerdo a través de múltiples rondas de comunicación. Cada ronda de comunicación adicional añade latencia.

PoH elimina esa latencia al crear una línea de tiempo compartida que todos los validadores pueden verificar de forma independiente, sin necesidad de comunicación entre nodos para establecer cuándo ocurrió algo.

Cómo funciona Proof of History: la cadena de hashes

Piense en PoH como un cronómetro criptográfico que funciona continuamente en la red. Cada tic del cronómetro produce un resultado único y verificable. Debido a que cada resultado se genera a partir del anterior, cualquiera puede verificar toda la secuencia y confirmar que ha pasado una cantidad específica de tiempo entre dos puntos cualesquiera, sin necesidad de confiar en el propietario del reloj.

El mecanismo técnico funciona de la siguiente manera:

1. El generador de PoH de Solana comienza con un valor de hash inicial.
2. Ejecuta la función de hash criptográfico SHA-256 sobre ese valor, produciendo un nuevo resultado de 256 bits.
3. Alimenta inmediatamente ese resultado de nuevo como entrada para la siguiente operación SHA-256.
4. Cada hash en la cadena se registra junto con un contador, creando una secuencia verificable que demuestra que ha transcurrido tiempo de computación real.
5. Las transacciones se insertan en la cadena de hashes en posiciones específicas, poniéndoles una marca de tiempo permanente frente a la secuencia verificable antes de que cualquier validador necesite comunicarse con otro.

El resultado es un registro público de exactamente cuándo entró cada transacción en la cola. Cualquiera puede verificar que la cadena está intacta. Nadie puede falsificar el tiempo que se tardó en producirla.

Lenguaje sencillo: PoH es como un cronómetro criptográfico que pone una marca de tiempo a cada evento incluso antes de que los validadores necesiten comunicarse. Es un registro público de exactamente cuándo entró cada transacción en la cola, verificable por cualquiera y manipulable por nadie.

Inmersión técnica: SHA-256 es una función de hash criptográfico unidireccional: rápida de calcular en una dirección, pero computacionalmente inviable de aplicar ingeniería inversa. El encadenamiento secuencial de los resultados de SHA-256 otorga a PoH su propiedad de "retardo verificable": la cadena tarda tiempo real en producirse (la computación secuencial no se puede paralelizar), pero cualquier observador que compruebe cada hash frente al anterior puede verificarla en paralelo muy rápidamente. Esto es funcionalmente similar a una Función de Retardo Verificable (VDF), una construcción criptográfica que requiere una cantidad mínima de computación secuencial para producirse pero que puede verificarse rápidamente. El papel de SHA-256 en PoH es totalmente diferente al que desempeña en Bitcoin, donde se utiliza como un rompecabezas competitivo (encontrar un hash por debajo de un objetivo). En PoH, SHA-256 se utiliza para el cronometraje secuencial, no para la computación competitiva.

Lo que Proof of History es y lo que no es

Proof of History no es el mecanismo de consenso de Solana. Un mecanismo de consenso es el proceso mediante el cual los validadores llegan a un acuerdo sobre qué transacciones son válidas y en qué orden. PoH no hace eso. PoH registra el orden y el momento de los eventos; Tower BFT es el algoritmo que alcanza el consenso sobre si esos eventos son válidos.

PoH tampoco es Proof of Stake. Proof of Stake determina quién es económicamente elegible para participar en el consenso y cuánto peso tiene su voto. PoH no determina la elegibilidad ni el peso del voto; proporciona el reloj compartido que hace que el proceso de votación sea más rápido.

La idea errónea de que "Solana utiliza Proof of History" como su mecanismo de consenso completo es uno de los errores más comunes en los escritos públicos sobre Solana. Es inexacto y es importante: sin Tower BFT y Proof of Stake, PoH por sí solo no proporcionaría ninguna garantía de seguridad.

Tower BFT: Cómo llegan a un acuerdo los validadores

Tower BFT es el algoritmo de consenso de Solana, una adaptación de la Tolerancia a Faltas Bizantinas Práctica (PBFT) diseñada para utilizar PoH como reloj compartido. Permite a los validadores llegar a un acuerdo sobre el estado del libro mayor mediante votos ponderados por stake. Debido a que los validadores comparten Proof of History como un reloj de confianza, Tower BFT requiere muchas menos rondas de comunicación que las implementaciones estándar de BFT, y finaliza los bloques en aproximadamente 400 a 800 milisegundos en condiciones normales de red.

¿Qué es la Tolerancia a Faltas Bizantinas?

El nombre proviene del Problema de los Generales Bizantinos, un experimento mental clásico de sistemas distribuidos formalizado por Leslie Lamport en 1982. El problema plantea: ¿cómo puede coordinar un ataque un grupo de generales cuando algunos de ellos podrían ser traidores que envían información falsa? Un sistema es Tolerante a Faltas Bizantinas si puede alcanzar un consenso correcto incluso cuando algunos participantes actúan de forma maliciosa, envían mensajes falsos o fallan de forma arbitraria.

Los sistemas BFT tradicionales, incluido el algoritmo fundacional PBFT publicado por Miguel Castro y Barbara Liskov en 1999, requieren que menos de un tercio de todos los participantes sean defectuosos o maliciosos. Para una red con 100 validadores, hasta 33 pueden estar comprometidos y los 67 restantes aún pueden alcanzar un consenso correcto. Esta propiedad es demostrable matemáticamente, lo que hace que los sistemas basados en BFT sean atractivos para aplicaciones críticas para la seguridad.

Tower BFT de Solana hereda esta propiedad. Un atacante necesitaría controlar más de un tercio de todo el SOL en el que se ha decidido Participar en staking para detener la red, y más de dos tercios para anular el consenso. A diferencia de las redes de Proof of Work donde un atacante necesita el 51% de la potencia de cálculo, Tower BFT de Solana requiere controlar más del 33% de todo el SOL en el que se ha decidido Participar en staking para detener la red. Ese umbral se considera generalmente más difícil de alcanzar en la práctica porque requiere acumulación de capital, no solo recursos computacionales.

Inmersión técnica: El PBFT estándar requiere una complejidad de mensajes de O(n²), donde n es el número de validadores. Cada validador debe comunicarse con todos los demás para confirmar el acuerdo. Para redes con miles de validadores, esto crea una sobrecarga de comunicación prohibitiva. Tower BFT reduce esta sobrecarga utilizando PoH como reloj compartido: dado que todos los validadores están de acuerdo con el cronometraje de la secuencia de PoH sin enviarse mensajes al respecto, Tower BFT solo necesita que los validadores voten sobre la validez del bloque, no sobre el orden de las marcas de tiempo. El mecanismo de bloqueo añade otra eficiencia: cuando un validador vota sobre un bloque, queda bloqueado en ese voto durante un periodo de tiempo de espera que aumenta exponencialmente. Cambiar los votos requiere esperar a que finalice el bloqueo, lo que crea un desincentivo económico para las reorganizaciones (Fork) y reduce el número de rondas de votación necesarias para alcanzar la finalidad.

Cómo utiliza Tower BFT el Proof of History

Sin un reloj compartido, los validadores en un sistema BFT estándar deben enviarse mensajes con marcas de tiempo entre sí para establecer el orden de los eventos, lo que añade una sobrecarga de comunicación en cada paso. Con PoH, el orden ya está establecido y es verificable por cada validador de forma independiente.

Los validadores emiten votos ponderados por stake en los bloques, y Tower BFT utiliza bloqueos y votación por mayoría calificada en la selección de Fork. La confirmación optimista, la confirmación arraigada y la finalidad económica a nivel de aplicación son umbrales diferentes. Sus tiempos varían según las condiciones del clúster y deben consultarse en la documentación actual en lugar de reducirse a una cifra fija en milisegundos.

Al comienzo de cada epoch, Solana computa una asignación determinista de qué validador actuará como líder para cada próximo slot. La asignación es proporcional al peso del stake de cada validador: a un validador que controle el 5% de todo el SOL en staking se le asignará como líder aproximadamente el 5% de todos los slots en ese epoch.

Un slot es la unidad de tiempo básica de Solana, con un objetivo de aproximadamente 400 milisegundos por slot (verifique la cifra actual en docs.solana.com al momento de leer esto). Un epoch abarca aproximadamente 432.000 slots, lo que se traduce en aproximadamente dos o tres días (verifique en docs.solana.com al momento de leer esto).

El cronograma de líderes se conoce públicamente con antelación. Los validadores pueden usarlo para reenviar transacciones hacia un próximo líder antes de que comience ese slot. Esto reduce la dependencia de una Mempool global convencional, pero no elimina la congestión, la competencia por comisiones de prioridad, la caída de transacciones o el riesgo de MEV.

La implicación de descentralización del liderazgo ponderado por stake es directa: los validadores con más SOL en staking reciben proporcionalmente más slots de líder, lo que significa que producen proporcionalmente más bloques. Esta estructura otorga a los grandes participantes de staking más influencia sobre qué transacciones se incluyen y en qué orden. Las consecuencias concretas de esa concentración, incluidos el coeficiente de Nakamoto de Solana y las barreras de participación por hardware, se examinan en la sección de fortalezas y limitaciones a continuación.

Cómo funcionan juntos Proof of History, Tower BFT y Proof of Stake

Proof of History, Tower BFT y Proof of Stake no son tres mecanismos de consenso separados que se ejecutan en paralelo. Son tres capas interdependientes de un único sistema integrado, cada una de las cuales resuelve una parte diferente del problema del consenso distribuido.

Proof of Stake es la base económica. Los validadores deben participar en staking (bloquear) SOL para participar en el consenso. Este stake crea un compromiso financiero directo: los validadores que votan incorrectamente o intentan manipular el libro de contabilidad corren el riesgo de perder su SOL en staking mediante el slashing (verifique los detalles actuales de la implementación del slashing en docs.solana.com, ya que esto evoluciona con las actualizaciones del protocolo). Los delegadores, es decir, cualquier titular de SOL que no quiera ejecutar un validador, pueden participar en staking con su SOL en un validador y ganar una parte de las recompensas de ese validador proporcional a su delegación.

Una vez que el Proof of Stake establece quién participa y con qué peso, el Proof of History proporciona la línea de tiempo que esos participantes utilizan. El reloj PoH funciona continuamente, produciendo la secuencia verificable de hashes que marca el tiempo de cada transacción. No se necesita comunicación entre nodos para establecer el orden porque todos los validadores pueden verificar la secuencia PoH de forma independiente.

Tower BFT es el algoritmo que utilizan esos validadores elegibles y sincronizados en el tiempo para votar. La combinación de un reloj compartido (PoH) y un sistema de votación económicamente asegurado (Tower BFT ponderado por PoS) produce un consenso que es a la vez rápido y resistente a la manipulación.

Los validadores alcanzan el consenso sobre el estado del bloque, que incluye los resultados de los contratos inteligentes, llamados programas en el ecosistema de Solana. El tiempo de ejecución de contratos inteligentes en paralelo de Solana (Sealevel) permite que varios programas que no entren en conflicto se ejecuten simultáneamente, contribuyendo aún más al rendimiento de la red.

Cómo alcanza la finalidad una transacción de Solana: paso a paso

Una transacción de Solana puede enrutarse hacia los líderes programados sin esperar en una Mempool global convencional. Su ciclo de vida sigue las etapas a continuación, pero la confirmación y la hora de liquidación varían según el nivel de compromiso y las condiciones del clúster; la duración del slot objetivo no es una garantía de finalidad total.

1. Envío de la transacción. El usuario firma y transmite una transacción a la red Solana. La transacción firmada contiene toda la información que los validadores necesitan para verificar su autenticidad: la clave pública del remitente, la operación prevista y una firma criptográfica que demuestra que el remitente la autorizó. La firma ocurre localmente; luego, la transacción se propaga a la red.

2. Reenvío consciente del líder. Solana reenvía la transacción hacia un próximo líder identificado a partir del cronograma público. A diferencia de una Mempool global convencional, este diseño puede preparar el trabajo antes del slot del líder, aunque la congestión, la pérdida de paquetes, el vencimiento de la transacción (con vencimiento), las comisiones de prioridad y los incentivos de ordenación siguen afectando al resultado.

3. Marcado de tiempo PoH del líder. El validador líder inserta la transacción en la posición actual de la cadena de hash PoH, registrando permanentemente la posición de la transacción en la línea de tiempo verificable. Esta marca de tiempo está vinculada criptográficamente a la secuencia de todos los hashes PoH anteriores; no puede alterarse retroactivamente sin invalidar cada hash posterior, lo que hace que el registro sea a prueba de manipulaciones.

4. Producción de bloques. Dentro de su ventana de slot de aproximadamente 400 milisegundos, el líder reúne todas las transacciones con marca de tiempo en un bloque. Debido a que las transacciones llegan preordenadas por la secuencia PoH, el líder no necesita negociar el orden con otros validadores. Simplemente construye el bloque de acuerdo con la línea de tiempo establecida.

5. Propagación Turbine. El protocolo de propagación de bloques Turbine de Solana divide el bloque completado en paquetes de datos más pequeños llamados shreds y los distribuye entre todos los demás validadores utilizando una estructura de propagación en árbol inspirada en BitTorrent. En lugar de transmitir el bloque completo a cada validador simultáneamente (lo que requeriría un ancho de banda enorme con un volumen alto), Turbine pasa los shreds a través de un árbol estructurado de validadores, siendo cada validador responsable de retransmitirlos a un pequeño número de pares. Esto reduce la carga de ancho de banda en cualquier validador individual mientras garantiza que el bloque completo llegue a todos los participantes rápidamente.

6. Votación Tower BFT. Al recibir los shreds del bloque y reconstruir el bloque completo, otros validadores verifican que la secuencia PoH sea válida y que las transacciones estén correctamente formadas. Cada validador emite un voto Tower BFT ponderado por stake sobre la validez del bloque. Los validadores con más SOL en staking tienen proporcionalmente más peso en este voto. Los votos se propagan por la red a medida que los validadores señalan su confirmación.

7. Finalidad. Cuando los validadores que representan colectivamente más de dos tercios de todo el SOL en staking han confirmado el bloque, este alcanza la finalidad de Tower BFT y se registra permanentemente en el libro de contabilidad. Este umbral de mayoría calificada es el mismo requisito de 2/3+ que sustenta la teoría de Tolerancia a Faltas Bizantinas: garantiza que el consenso se mantenga incluso si hasta un tercio de los participantes ponderados por stake fallan o son maliciosos.

Terminología de finalidad: El tiempo de un slot objetivo no es lo mismo que la confirmación optimista, el enraizamiento (rooting) o la finalidad económica. Las aplicaciones deben seleccionar un nivel de compromiso basado en sus requisitos de riesgo y verificar el comportamiento actual del clúster.

Rendimiento de Solana: velocidad, capacidad de procesamiento y finalidad

La velocidad de Solana no es el resultado de una única elección de diseño. Es el efecto acumulativo de cuatro decisiones arquitectónicas que trabajan en coordinación: Proof of History, Tower BFT, el protocolo Gulf Stream de Solana y el protocolo de propagación de bloques Turbine de Solana.

¿Por qué Solana es rápida? Cuatro razones

1. Proof of History proporciona una referencia de ordenación verificable que puede reducir parte de la sobrecarga de coordinación temporal; los validadores siguen intercambiando votos y datos de red.
2. Tower BFT requiere menos rondas de votación que las implementaciones BFT estándar porque todos los validadores comparten un reloj PoH común y no necesitan negociar el tiempo.
3. El reenvío consciente del líder (Leader-aware forwarding) envía transacciones a los próximos líderes antes de que comiencen sus slots, lo que puede reducir la cola convencional de la mempool sin eliminar toda la latencia o la competencia por comisiones.
4. El protocolo de propagación de bloques Turbine de Solana distribuye bloques en pequeños fragmentos a través de una estructura de árbol en lugar de transmitir bloques completos a cada validador simultáneamente, lo que reduce los requisitos de ancho de banda en grandes redes.

El rendimiento máximo teórico de Solana es una cifra histórica teórica de aproximadamente 65.000 transacciones por segundo bajo condiciones de red ideales. Esa cifra es un punto de referencia, no una descripción del rendimiento típico. El rendimiento real en la Mainnet ha promediado históricamente entre 2.000 y 4.000 TPS, con picos durante periodos de alta demanda. La brecha entre el máximo teórico y el promedio en el mundo real refleja los retrasos en la propagación de la red, la distribución geográfica de los validadores y la sobrecarga de software que los puntos de referencia en condiciones ideales no capturan. Verifique las cifras actuales en Solscan (solscan.io) en el momento de redactar este documento.

La documentación de Solana ha descrito históricamente un tiempo de slot objetivo cercano a los 400 milisegundos, pero los slots reales y las etapas de confirmación varían. La confirmación optimista, el enraizamiento (rooting) y la finalidad económica a nivel de aplicación son umbrales diferentes y deben medirse utilizando la documentación actual y las condiciones del clúster en vivo.

Para comparar: Ethereum, que pasó de Proof of Work a Proof of Stake en septiembre de 2022, alcanza ahora aproximadamente de 15 a 30 TPS en su capa 1 con una finalidad económica completa que tarda aproximadamente de 12 a 15 Min a través de las épocas de puntos de control de Casper FFG (verificar en ethereum.org). El consenso Nakamoto de Bitcoin alcanza aproximadamente 7 TPS con una finalidad probabilística que tarda aproximadamente 60 Min a través de 6 confirmaciones de bloque.

La brecha de finalidad entre Solana y la capa 1 de Ethereum es sustancial. Si esa brecha es relevante para un caso de uso específico depende de la aplicación. Las redes de capa 2 de Ethereum (Arbitrum, Optimism y otras) ofrecen una finalidad más rápida que la L1 de Ethereum, aunque operan mediante mecanismos diferentes al consenso de Solana.

Consenso de Solana frente a Ethereum, Avalanche, Cardano y Polkadot

Solana no es la única blockchain de alto rendimiento, y su Mecanismo de Consenso no es el único enfoque para lograr una finalidad de transacción rápida y escalable. A continuación se muestra cómo se compara el sistema PoH + Tower BFT + PoS de Solana estructuralmente y mediante métricas de rendimiento frente a las alternativas más destacadas.

Ethereum (post-Merge, septiembre de 2022) utiliza ahora Gasper, un sistema de consenso que combina LMD-GHOST (una regla de elección de bifurcación o Fork que selecciona la cadena con el mayor número acumulado de atestaciones de validadores) y Casper FFG (un dispositivo de finalidad que establece puntos de control periódicos en la cadena). Ethereum pasó de Proof of Work a Proof of Stake el 15 de septiembre de 2022. El contraste arquitectónico con Solana es significativo: Gasper de Ethereum logra seguridad y descentralización a través de un enorme conjunto de validadores (aproximadamente 900.000 o más, verificar en beaconcha.in en el momento de la redacción) a costa del rendimiento. Solana logra el rendimiento a través del mecanismo de reloj de PoH y la eficiencia de Tower BFT, pero con un conjunto de validadores sustancialmente menor.

Avalanche (C-Chain) utiliza el consenso Snowman, una variante de cadena lineal del protocolo de consenso de Avalanche. Snowman es probabilístico y basado en muestreo en lugar de ser un BFT determinista: los validadores muestrean repetidamente subconjuntos aleatorios de otros validadores para medir el acuerdo. Las cifras publicadas de rendimiento y finalidad varían según la fecha, la carga de trabajo y el método de medición, por lo que deben utilizarse fuentes primarias actuales para la comparación. El contraste arquitectónico es que Avalanche utiliza submuestreo repetido, mientras que Solana utiliza votación ponderada por Participar en staking construida en torno a una referencia de ordenación PoH.

Cardano utiliza Ouroboros Praos, la versión actual de la Mainnet de la familia de consenso PoS Ouroboros. Ouroboros fue el primer protocolo PoS demostrablemente seguro, publicado en medios académicos revisados por pares con pruebas formales de seguridad matemática. El diseño de Cardano prioriza explícitamente la corrección formal y las pruebas de seguridad sobre el rendimiento bruto. Los TPS reales en la Mainnet de Cardano son aproximadamente 250 (verificar en el momento de la redacción). El contraste de la filosofía de diseño con Solana es directo: Solana prioriza el rendimiento a través de innovaciones arquitectónicas; Cardano prioriza la demostrabilidad formal de las propiedades de seguridad mediante el rigor académico.

Polkadot (relay chain) utiliza BABE (Blind Assignment for Blockchain Extension) para la producción de bloques y GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) para la finalidad, logrando aproximadamente 1.000 TPS en la relay chain con una finalidad que oscila entre aproximadamente 12 y 60 segundos. La arquitectura de relay chain más parachain de Polkadot es fundamentalmente diferente del diseño de cadena monolítica de Solana, lo que hace que las comparaciones directas de rendimiento sean más complejas de lo que sugieren las cifras de la tabla por sí solas.

Todas las cifras son estimaciones orientativas. Las métricas de rendimiento varían según las condiciones de la red; los máximos teóricos representan la capacidad en condiciones ideales. Verifique las cifras actuales en la documentación oficial (docs.solana.com, ethereum.org, Solana Beach, beaconcha.in) antes de tomar cualquier decisión. El número de validadores cambia con frecuencia.

Fortalezas y limitaciones del modelo de consenso de Solana

La arquitectura de consenso de Solana ofrece ventajas medibles de velocidad y rendimiento sobre todas las principales blockchains de capa 1, pero esas ventajas conllevan compromisos reales en la descentralización y un historial de fiabilidad histórico que cualquier evaluación seria debe abordar con honestidad.

Fortalezas:

• Objetivos de confirmación de baja latencia. Solana puede proporcionar una confirmación optimista rápida, pero se debe distinguir entre el nivel de compromiso y la finalidad económica.
• Diseño de alto rendimiento. Los puntos de referencia históricos ilustran la capacidad arquitectónica, mientras que el rendimiento en vivo depende de la carga de trabajo, la contabilidad de votos, los validadores, la congestión y las versiones de software.
• Bajas comisiones de transacción. La alta capacidad de rendimiento significa que la competencia por las comisiones entre las transacciones es menor, manteniendo los costes en fracciones de céntimo para la mayoría de las operaciones.
• Reenvío de transacciones sin Mempool. El protocolo Gulf Stream de Solana elimina el problema de la sala de espera, reduciendo la latencia de confirmación al enrutar previamente las transacciones a los próximos líderes conocidos.
• Eficiencia energética. Proof of Stake no requiere computación intensiva en energía, lo que sitúa la huella energética de Solana en una categoría fundamentalmente diferente a la de Proof of Work de Bitcoin.

Limitaciones:

• Interrupciones históricas de la red. Solana experimentó múltiples paradas totales de la red entre 2021 y 2023, lo que generó preocupaciones reales sobre la fiabilidad que cualquier inversor o desarrollador debe sopesar.
• Menos validadores que Ethereum. El conjunto de validadores relativamente pequeño crea un perfil de descentralización diferente al de las redes con cientos de miles de validadores.
• Los altos requisitos de hardware crean una barrera de participación. Ejecutar un validador de Solana exige hardware de nivel de servidor que la mayoría de las personas no pueden permitirse ni operar, lo que limita quién puede participar directamente en el consenso.
• Dependencia de un único cliente de validador (antes de Firedancer). Hasta hace poco, casi todos los validadores de Solana ejecutaban el mismo cliente de software, lo que creaba un punto único de fallo si ese cliente tenía errores.
• Concentración de stake entre los principales validadores. Una parte significativa del total de SOL en staking está concentrada en un pequeño número de validadores, lo que afecta al coeficiente de Nakamoto.

¿Por qué se ha caído la red de Solana?

Las interrupciones históricas de Solana no fueron causadas por fallos en los algoritmos de consenso Proof of History o Tower BFT. El diseño del consenso en sí no se rompió. Las causas raíz documentadas de las principales interrupciones fueron el agotamiento de los recursos de software y errores de implementación: el spam de transacciones abrumando la capacidad de memoria de los validadores, errores de software en el cliente del validador que causaron bloqueos y el agotamiento de recursos provocado por eventos de alta demanda, incluyendo avalanchas de acuñación de NFT y picos de actividad de DeFi.

Eventos específicos ilustran el patrón. En septiembre de 2021, Solana sufrió una interrupción de 17 horas causada por una inundación de transacciones de un evento IDO que saturó la memoria de los validadores y provocó un Fork de la red que requirió un reinicio coordinado. En enero de 2022, una segunda interrupción significativa se derivó del agotamiento de recursos durante condiciones de alto rendimiento. Se produjeron múltiples eventos adicionales de degradación parcial a lo largo de 2022 (verifique las fechas y duraciones específicas en los informes post-mortem de la Fundación Solana al momento de escribir este artículo, ya que la lista de incidentes documentados se ha ampliado). La distinción entre estos eventos y un fallo del algoritmo de consenso es importante para evaluar la viabilidad a largo plazo de Solana: un algoritmo de consenso roto requeriría un rediseño del protocolo, mientras que el agotamiento de los recursos de software es un problema de ingeniería solucionable.

Las mejoras implementadas desde el periodo de máxima interrupción incluyen la adopción de QUIC como protocolo de red (sustituyendo al enfoque basado en UDP que era más vulnerable al spam), un sistema de calidad de servicio ponderado por el stake que prioriza las transacciones de los validadores con stake sobre el spam anónimo, y mejoras continuas en el software del cliente del validador. El cliente Firedancer, una implementación de validador independiente de alto rendimiento desarrollada por Jump Cripto, tiene como objetivo proporcionar una diversidad de clientes que evite que un solo error de software afecte a toda la red. Verifique el estado actual del desarrollo de Firedancer en fuentes oficiales al momento de escribir este artículo.

La frecuencia y la gravedad de las interrupciones representan una preocupación real de fiabilidad, no un inconveniente menor. Las redes que procesan transacciones financieras no pueden permitirse paradas no planificadas. Las mejoras realizadas desde los peores periodos de interrupción son sustanciales, pero el historial es parte de la evaluación que cualquiera que construya sobre Solana o posea SOL debería realizar con los ojos abiertos.

Descentralización y concentración de validadores: Solana tiene aproximadamente 1.500 o más validadores activos al momento de escribir este artículo (verifique el recuento actual en Solana Beach validator analytics). Ethereum tiene aproximadamente 900.000 o más validadores (verifique en beaconcha.in). La diferencia es sustancial y refleja la barrera de hardware para la validación en Solana: ejecutar un validador de Solana requiere aproximadamente 128 GB o más de RAM, almacenamiento SSD NVMe de alto rendimiento de 2 TB o más, y una conexión de red de al menos 1 Gbps (verifique las especificaciones actuales en docs.solana.com/running-validator al momento de escribir este artículo). Por el contrario, los validadores de Ethereum pueden ejecutarse en hardware de consumo junto con 32 ETH.

El coeficiente de Nakamoto de Solana (el número mínimo de entidades que tendrían que coludir para comprometer el consenso) ha oscilado históricamente entre aproximadamente 19 y 31 validadores, aunque esta cifra cambia con los cambios en la distribución del stake. Verifique el coeficiente actual en los informes de descentralización de la Fundación Solana o en Nakaflow al momento de escribir este artículo. Históricamente, los 20 principales validadores han controlado una parte significativa del total de SOL en staking (verifique el porcentaje de concentración actual en Solana Beach). La Fundación Solana opera un programa de delegación diseñado específicamente para distribuir el stake a validadores más pequeños y mejorar este coeficiente, proporcionando una contramedida estructural a la concentración. El umbral de seguridad de Tower BFT significa que un atacante necesitaría controlar más de un tercio de todo el SOL en staking para detener la red, y más de dos tercios para anular el consenso, un requisito de capital elevado que escala según lo concentrado que esté ese stake en la práctica.

Cómo participar: Staking y validación en Solana

Los titulares de SOL pueden participar en el Mecanismo de Consenso de Solana de dos maneras: operando un nodo validador directamente o delegando SOL a un validador existente. El primer camino requiere una inversión significativa en hardware y experiencia técnica. El segundo es accesible para cualquier titular de SOL con un monedero compatible.

Aviso legal: Este artículo tiene fines informativos y educativos únicamente. No constituye asesoramiento financiero, asesoramiento de inversión ni una recomendación para comprar, vender o mantener ninguna criptomoneda. Las inversiones en criptomonedas conllevan un riesgo significativo, incluida la posible pérdida del capital. Realice siempre su propia investigación y consulte a un asesor financiero cualificado antes de tomar decisiones de inversión.

Requisitos para ejecutar un validador de Solana

Operar un validador de Solana convierte al operador en el líder de los slots asignados y en votante para todos los demás slots. Los requisitos de hardware son sustanciales y han aumentado a medida que la red ha crecido. Verifique siempre las especificaciones actuales en la documentación oficial de validadores de Solana) antes de comprometerse con el hardware:

• CPU: Alto rendimiento en un solo núcleo; las recomendaciones de modelos específicos se actualizan en la documentación oficial.
• RAM: Se recomienda un mínimo de 128 GB; 256 GB o más para un mejor rendimiento.
• Almacenamiento: SSD NVMe de alto rendimiento; se recomiendan 2 TB o más.
• Red: Conexión mínima de 1 Gbps; se recomiendan 10 Gbps para un rendimiento competitivo.
• Participación en SOL (Stake): Suficiente stake autodelegado o stake delegado de la comunidad para que la operación sea económicamente viable. No hay un stake mínimo obligatorio por protocolo para ejecutar un validador, pero los validadores con un stake muy pequeño obtienen recompensas muy pequeñas.

Los requisitos de hardware han aumentado con cada actualización importante de la red. Cualquier persona que planee operar un validador debe presupuestar actualizaciones continuas de hardware y confirmar todas las especificaciones en la documentación oficial antes de comprar el equipo.

Cómo participar en staking de SOL: Staking nativo y líquido Options

Delegar SOL a un validador existente es el camino accesible para la mayoría de los participantes. La mecánica funciona de la siguiente manera.

Staking nativo: Utilizando un monedero compatible como Phantom o Solflare, cualquier titular de SOL puede delegar sus tokens a un validador de su elección. La delegación obtiene una parte de las recompensas por inflación de ese validador, proporcional a la cantidad delegada. El staking APY actual varía según los parámetros de inflación de la red y el total de SOL en staking (verifique en Solana Beach al momento de escribir este artículo antes de tomar cualquier decisión de staking). Existe un periodo de enfriamiento para retirar la delegación de aproximadamente dos épocas, lo que se traduce en aproximadamente cuatro a cinco días, antes de que el SOL delegado vuelva a ser líquido (verifique en docs.solana.com al momento de escribir este artículo).

Staking líquido: Protocolos como Marinade Finance (que emite tokens mSOL) y Jito (que emite tokens jitoSOL) permiten a los usuarios participar en staking de SOL manteniendo la liquidez. En lugar de bloquear SOL directamente con un validador y esperar el período de enfriamiento para acceder a él, los usuarios de staking líquido reciben un token líquido que representa su SOL participado en staking más las recompensas acumuladas, negociable en cualquier momento. Estos tokens de staking líquido forman parte de los protocolos DeFi que operan en Solana y conllevan su propio riesgo de contrato inteligente más allá de la economía subyacente del staking.

Al seleccionar un validador para la delegación, los criterios relevantes incluyen el historial de tiempo de actividad del validador, la tasa de comisión (el porcentaje de recompensas que el validador toma antes de pasar el resto a los delegadores) y la concentración de stake. Delegar a validadores más pequeños mejora la descentralización de la red y puede calificar para los beneficios del programa de delegación de la Fundación Solana.

Preguntas Frecuentes Sobre el Mecanismo de Consenso de Solana

¿Qué mecanismo de consenso utiliza Solana?

Solana utiliza un sistema de consenso híbrido que combina tres componentes: Proof of History (PoH), Tower BFT y Proof of Stake (PoS). PoH actúa como un reloj criptográfico que establece el orden de las transacciones. Tower BFT es el algoritmo de acuerdo que utilizan los validadores para confirmar bloques. PoS determina qué validadores participan y pondera sus votos por el SOL participado en staking.

Solana utiliza Proof of Stake como su capa de seguridad económica, por lo que llamarla una blockchain PoS es técnicamente preciso. Sin embargo, es incompleto. Proof of Stake por sí solo no explica cómo Solana alcanza el consenso. El mecanismo completo requiere Proof of History (el reloj criptográfico que establece el orden sin comunicación entre validadores) y Tower BFT (el algoritmo de votación que logra la finalidad). La descripción precisa: Solana utiliza un sistema de consenso híbrido PoH + Tower BFT + PoS.

Los puntos de referencia históricos informan un rendimiento sustancialmente diferente para Solana y Ethereum capa 1, pero las definiciones de transacciones, el tráfico de votos, la ejecución de capa 2, la disponibilidad de datos y los modelos de finalidad difieren. Utilice mediciones actuales y comparables y distinga la confirmación optimista de la liquidación finalizada o económicamente irreversible.

Las interrupciones históricas de la red de Solana fueron causadas por el agotamiento de recursos de software y errores de implementación, no por fallos en los algoritmos de consenso Proof of History o Tower BFT. Las causas documentadas incluyen el spam de transacciones que satura la capacidad de memoria de los validadores, errores de software en el cliente validador y agotamiento de recursos durante eventos de alta demanda como las acuñaciones de NFT y los picos de actividad de DeFi. La interrupción de septiembre de 2021 duró aproximadamente 17 horas y fue causada por la inundación de un evento IDO. Las mejoras desde el pico de interrupciones de 2021 a 2022 incluyen la red QUIC, la priorización de transacciones ponderada por stake y las mejoras continuas del cliente validador. Verifique el estado de fiabilidad de la red actual en el blog de la Fundación Solana en el momento de escribir esto.

Proof of History (PoH) es un mecanismo criptográfico de cronometraje inventado por Anatoly Yakovenko e introducido en su whitepaper de noviembre de 2017, "Solana: Una nueva arquitectura para una blockchain de alto rendimiento". PoH crea un registro continuo y verificable de cuándo ocurrieron los eventos encadenando secuencialmente las salidas hash SHA-256. No es un mecanismo de consenso. Es un reloj criptográfico que permite que el algoritmo de consenso real de Solana, Tower BFT, opere con muchas menos rondas de comunicación. Para obtener detalles completos, consulte la sección Proof of History anterior.

Anatoly Yakovenko, un antiguo ingeniero de Qualcomm, introdujo Proof of History en el whitepaper fundacional de Solana en 2017. Yakovenko cofundó Solana Labs con Greg Fitzgerald y Raj Gokal, quienes contribuyeron a la implementación más amplia del protocolo. PoH proporciona una referencia de ordenación verificable que puede reducir parte de la sobrecarga de coordinación temporal, pero no elimina la comunicación de consenso.

Solana tiene aproximadamente 1.500 o más validadores activos a la fecha de publicación; verifique la cifra actual en analíticas de validadores de Solana Beach para datos actuales. En comparación, Ethereum tiene aproximadamente 900.000 o más validadores (verifique en beaconcha.in). La diferencia en el número de validadores refleja diferencias en los requisitos de hardware: los validadores de Solana requieren equipos de grado de servidor con 128 GB o más de RAM, mientras que los validadores de Ethereum pueden ejecutarse en hardware de grado de consumidor junto con 32 ETH.

Tower BFT es el algoritmo de consenso de Solana, construido como una adaptación de PBFT que utiliza Proof of History como un reloj compartido. Los validadores emiten votos ponderados por stake sobre los bloques; un bloque alcanza la finalidad cuando los validadores que representan más de dos tercios de todo el SOL participado en staking lo confirman. Este umbral de supermayoría de 2/3+ significa que la red tolera hasta un tercio de los participantes ponderados por stake que actúan maliciosamente sin perder la integridad del consenso.

El staking de Solana es técnicamente similar a Delegated Proof of Stake (DPoS) en el sentido de que los poseedores de SOL pueden delegar a validadores sin ejecutar su propio nodo. Sin embargo, difiere de los sistemas DPoS tradicionales en un aspecto clave: no hay un conjunto fijo y elegido de validadores delegados. Cualquier validador puede atraer delegación del mercado abierto. Más precisamente, Solana utiliza un sistema PoS ponderado por stake con delegación abierta, que opera como la capa de seguridad económica sobre PoH y Tower BFT, en lugar de una arquitectura DPoS tradicional con un pool de delegados fijo.

Ninguna red es objetivamente mejor. Cada una toma diferentes compromisos arquitectónicos adaptados a diferentes casos de uso. Las mediciones históricas generalmente muestran un mayor rendimiento de la capa base y tarifas más bajas en Solana, mientras que el tiempo de confirmación depende del nivel de compromiso y las condiciones de la red. Ethereum tiene una comunidad de desarrolladores más grande y un amplio ecosistema de capa 2. El número de validadores por sí solo no mide la descentralización; la distribución del stake, la diversidad de clientes, la concentración de operadores y los requisitos de hardware también son importantes. La elección correcta depende de la aplicación y el modelo de riesgo.

Explore SOL en Bybit

Los lectores pueden revisar información actual del mercado de SOL) o comparar productos SOL Earn disponibles.). Bybit Earn es un producto centralizado y no debe describirse como staking nativo de validador de Solana; los términos, la custodia, la disponibilidad y los riesgos difieren.

• El mecanismo de consenso de Solana es un sistema híbrido: Proof of History (reloj criptográfico) + Tower BFT (algoritmo de acuerdo) + Proof of Stake (capa de seguridad económica). Ningún componente por sí solo constituye el mecanismo.

• Proof of History no es un mecanismo de consenso. Es una herramienta criptográfica de cronometraje que establece el orden de las transacciones antes de que los validadores se comuniquen, permitiendo a Tower BFT alcanzar el consenso con muchas menos rondas de votación que las implementaciones BFT estándar.

• Las interrupciones de la red de Solana fueron causadas por agotamiento de recursos de software, no por fallos en PoH o Tower BFT. El diseño del consenso no falló. Las mejoras que incluyen la red QUIC, la priorización de tarifas ponderada por stake y el cliente Firedancer tienen como objetivo reducir el riesgo de futuras paralizaciones.

• El consenso de Solana es más rápido que Ethereum capa 1 y Bitcoin, logrando la finalidad en menos de 1,3 segundos frente a los 12 a 15 minutos de Ethereum capa 1 y aproximadamente 60 minutos de Bitcoin, pero esta velocidad conlleva contrapartidas: menos validadores, requisitos de hardware más altos y preocupaciones sobre la concentración del stake.

• Cualquier poseedor de SOL puede participar en el mecanismo de consenso de Solana delegando SOL a un validador a través de staking nativo o protocolos de staking líquido. Ejecutar un validador directamente requiere una inversión considerable en hardware y experiencia técnica.

• Las cifras de rendimiento y el número de validadores cambian con las actualizaciones de red. Cualquier evaluación de la descentralización, el rendimiento (throughput) o los rendimientos del staking de Solana debe utilizar datos actuales de Solana Beach, Solscan y la documentación oficial de Solana en el momento de la decisión.

Para participar en el mecanismo de consenso de Solana, consulte las secciones de staking y validación anteriores o visite la documentación oficial de Solana en docs.solana.com.

Lecturas adicionales:

• Solana: Una nueva arquitectura para una blockchain de alto rendimiento:) Whitepaper de noviembre de 2017 de Anatoly Yakovenko
• Documentación oficial de Solana: especificaciones del protocolo, requisitos de hardware, guías de staking
• Análisis de validadores de Solana Beach: recuento actual de validadores, distribución de stake y estadísticas de red

Lecturas relacionadas

• Solana Proof of History
• Arquitectura de Solana
• Velocidad de Solana