Solana Prueba de Historial: Cómo Funciona PoH

Nota de precisión: El rendimiento de la red, el número de validadores, las tarifas, las características del protocolo, el soporte de carteras y las integraciones de terceros cambian con el tiempo. Trate las cifras desactualizadas como instantáneas históricas y verifique la documentación de origen primaria actual.

La Prueba de Historial de Solana es un mecanismo criptográfico de ordenación temporal, no un protocolo de consenso independiente. Funciona con Tower BFT y Prueba de Participación para ayudar a los validadores a ordenar eventos y acordar el ledger.

Descargo de responsabilidad: Este artículo tiene fines informativos y educativos únicamente. No constituye asesoramiento financiero ni de inversión. Las inversiones en criptomonedas conllevan riesgos significativos, incluida la posible pérdida del capital. Consulte a un asesor financiero cualificado antes de tomar decisiones de inversión.

Tabla de Contenidos

1. ¿Qué Es la Prueba de Historial? El Reloj Criptográfico de Solana Explicado
2. Cómo Funciona la Prueba de Historial: La Cadena de Hash SHA-256 Paso a Paso
3. Por Qué la Prueba de Historial Puede Reducir la Sobrecarga de Ordenación
4. Prueba de Historial vs. Prueba de Trabajo vs. Prueba de Participación: Una Comparación Directa
5. Cómo la Prueba de Historial Interactúa con la Arquitectura Completa de Solana
6. Limitaciones y Críticas de la Prueba de Historial: Una Evaluación Honesta
7. Preguntas Frecuentes Sobre la Prueba de Historial y Solana
8. Conclusión: ¿Es la Prueba de Historial una Innovación Genuina?

¿Qué Es la Prueba de Historial de Solana?

Proof of History (PoH) es un mecanismo criptográfico de registro de tiempo integrado en la blockchain de Solana que crea un registro verificable del orden y la sincronización de los eventos, sin requerir que los validadores se comuniquen constantemente entre sí para establecer cuándo ocurrió algo.

Una blockchain es un ledger distribuido donde los registros se enlazan criptográficamente y se mantienen en una red de participantes sin autoridad central. En cualquier blockchain distribuida, los nodos deben acordar dos cosas antes de confirmar una transacción: qué sucedió y cuándo sucedió. La mayoría de las redes dedican un esfuerzo computacional significativo a la segunda pregunta. La Prueba de Historial la responde criptográficamente, por lo que la red puede enfocar todo su ancho de banda en la primera.

Una distinción crítica a establecer de inmediato: la Prueba de Historial no es un mecanismo de consenso. El mecanismo de consenso real de Solana es Tower BFT. PoH es la capa de registro de tiempo de la que depende Tower BFT para operar de manera eficiente. Confundir ambos es el error más común en la cobertura de la tecnología de Solana, y este artículo lo corrige en todo momento.

La Prueba de Historial fue inventada por Anatoly Yakovenko, cofundador de Solana Labs y anteriormente ingeniero jefe en Qualcomm. Introdujo el concepto en un whitepaper de 2017 titulado Solana: una nueva arquitectura para una blockchain de alto rendimiento. La beta de la mainnet de Solana se lanzó en marzo de 2020, construida sobre la arquitectura descrita en ese whitepaper.

Solana es una blockchain de capa 1 de alto rendimiento cuyo token nativo es SOL. Su techo de rendimiento teórico, habilitado por la Prueba de Historial que funciona junto con varias otras innovaciones arquitectónicas, es una cifra teórica histórica de aproximadamente 65.000 transacciones por segundo (TPS). El rendimiento sostenido en el mundo real bajo condiciones de red típicas es sustancialmente menor, una distinción que este artículo aborda en detalle.

Si ha oído describir la Prueba de Historial como "lo mismo que la Prueba de Participación" o ha asumido que es el mecanismo de consenso de Solana, ambas formulaciones son incorrectas. La comparación completa y la relación precisa entre estos mecanismos aparecen en las secciones a continuación.

Cómo Funciona la Prueba de Historial: La Cadena de Hash SHA-256 Paso a Paso

La analogía del reloj criptográfico captura lo que hace PoH, pero para comprender por qué inversores y desarrolladores la consideran una innovación arquitectónica genuina, necesita ver cómo funciona realmente el reloj.

¿Qué Es una Función Hash Criptográfica? (El Bloque de Construcción)

Una función hash criptográfica toma cualquier entrada (una palabra, un documento, un registro de transacción) y produce una salida de longitud fija que es única para esa entrada y determinista. También es prácticamente imposible de revertir: conocer la salida no le dice nada útil sobre lo que entró. La salida se llama hash y funciona como una huella dactilar única para cualquier dato que la produjo.

Cambie un carácter de la entrada y la salida cambiará por completo e impredeciblemente. Esa sensibilidad a la entrada es precisamente lo que hace que el hashing secuencial sea una base confiable para el registro de tiempo.

La función hash específica que utiliza la Prueba de Historial es SHA-256 (Secure Hash Algorithm, 256 bits), el mismo algoritmo que asegura las transacciones de Bitcoin. SHA-256 es computacionalmente intensivo de ejecutar pero trivialmente rápido de verificar. Esa asimetría es central: producir un hash es lento, pero verificar uno es instantáneo. Esa propiedad es exactamente lo que hace que SHA-256 sea adecuado para la función de registro de tiempo de PoH.

La Cadena de Hash: Cómo PoH Codifica el Tiempo Criptográficamente

PoH funciona ejecutando SHA-256 en una secuencia ininterrumpida, donde cada salida se convierte en la entrada para el siguiente cálculo. Debido a que cada paso requiere tiempo de cómputo real e irreductible, la cadena de salidas constituye un registro verificable del tiempo transcurrido. Nadie puede fingir haber alcanzado el paso 500.000 sin haber computado realmente los pasos 1 a 499.999.

Piénselo como un cronómetro criptográfico. Cada tic del reloj es una salida SHA-256 registrada, y la cadena de tics prueba que ha transcurrido una cantidad específica de cómputo, y por lo tanto, una cantidad medible de tiempo, entre eventos.

Así es como funciona la secuencia:

1. El validador líder inicia la cadena. Un validador designado (el "líder" para esa ranura) ejecuta SHA-256 sobre una entrada inicial, que puede ser cualquier valor arbitrario o el hash de un bloque anterior.
2. Cada salida se convierte en la siguiente entrada. El hash resultante se retroalimenta en SHA-256 como la nueva entrada. Esta es la cadena. Cada enlace depende completamente del anterior.
3. Un contador de secuencia rastrea la posición. Cada iteración lleva un número de conteo: hash #1, hash #2, hash #347.891. Este contador es el número de tics del reloj.
4. Las transacciones se incrustan en la cadena a medida que llegan. Cuando una transacción entra en la red, el líder la aplica un hash en la secuencia en ese momento preciso. Los datos de la transacción se incorporan en la salida hash en esa posición de conteo específica.
5. La posición incrustada prueba la sincronización de la transacción. Una transacción con hash en la posición 347.891 ocurrió demostrablemente después de la posición 347.890 y antes de la posición 347.892. No se necesita ninguna marca de tiempo externa. La cadena en sí misma es la prueba.
6. Otros validadores verifican la secuencia. La verificación es rápida porque comprobar un hash lleva una fracción del tiempo que se tarda en producirlo. Un validador puede confirmar que toda la secuencia es válida sin volver a ejecutar todos los cálculos.
7. La cadena resultante es una línea de tiempo a prueba de manipulaciones. Alterar cualquier hash en cualquier posición invalida todos los hashes que le siguen, haciendo que el registro sea imposible de falsificar sin rehacer todo el trabajo posterior.

La analogía de la fotografía captura bien la propiedad de resistencia a la manipulación. Imagine tomar una foto cada segundo, donde cada foto incluye la foto anterior dentro del encuadre. Cualquiera que mire la foto #1.000 puede verificar la secuencia sin haber estado presente para cada disparo, porque cada imagen está criptográficamente anidada en la siguiente. Cambiar la foto #400 corrompería visiblemente todas las imágenes subsiguientes.

Esta cadena de hash secuencial es lo que los criptógrafos llaman funcionalmente similar a una Función de Retraso Verificable (VDF). Una VDF definida formalmente, como describieron Boneh, Bonneau, Bünz y Fisch en su artículo de 2018 publicado en CRYPTO (IACR ePrint 2018/601), es una función que requiere una cantidad de tiempo prescrita para calcularse, no puede paralelizarse para acelerar ese cálculo y produce una prueba que permite una verificación rápida. PoH logra el mismo efecto práctico a través del hashing secuencial SHA-256. No es formalmente una VDF en el sentido estricto de la teoría de la complejidad, pero la similitud funcional es precisa. Los investigadores académicos que describen PoH como «similar a una VDF» o «una VDF informal» están utilizando un marco preciso.

Fuente: Anatoly Yakovenko, "Solana: Una nueva arquitectura para una blockchain de alto rendimiento", 2017. Disponible en solana.com/solana-whitepaper.pdf

Esta cadena de marcas de tiempo criptográficas es lo que permite que la capa de consenso de Solana, Tower BFT, se salte las rondas de comunicación que ralentizan otras blockchains, porque el tiempo ya está probado.

Por qué la Prueba de Historial de Solana puede reducir la sobrecarga de ordenación

La fuente cita rangos históricos teóricos y observados de rendimiento, pero la Prueba de Historial por sí sola no produce una cifra de TPS. La combinación de transacciones, tráfico de votos, programación de tiempo de ejecución, hardware de validador, red, congestión y metodología de medición afectan el rendimiento reportado. Utilice mediciones en vivo con fecha para tomar decisiones operativas.

Las comparaciones con Visa, Ethereum o Bitcoin no son directas: cuentan eventos diferentes y utilizan modelos de confianza, liquidación y finalidad distintos. PoH es una parte del diseño de Solana, junto con Sealevel, Turbine, Gulf Stream, los mercados de tarifas y la infraestructura de validadores.

Cómo Tower BFT utiliza PoH para saltarse rondas de comunicación

La ganancia de velocidad de PoH no se trata de hacer hashing más rápido. Se trata de eliminar una categoría completa de comunicación que requieren los mecanismos de consenso tradicionales.

Los sistemas distribuidos que deben tolerar fallos bizantinos (participantes defectuosos o maliciosos) necesitan Tolerancia a Fallos Bizantinos (BFT): la capacidad de alcanzar un consenso incluso cuando algunos validadores están desconectados, envían información falsa o se comportan de forma adversaria, siempre que menos de un tercio de los validadores estén comprometidos.

Definición clave: Tolerancia a Fallos Bizantinos (BFT) se refiere a la capacidad de un sistema distribuido para seguir operando correctamente incluso cuando algunos participantes fallan o actúan maliciosamente. El concepto se origina en el Problema de los Generales Bizantinos, un experimento mental clásico de la informática de Lamport, Shostak y Pease (1982).

En los sistemas de consenso BFT tradicionales, los validadores deben intercambiar mensajes para acordar dos cosas antes de confirmar una transacción: qué sucedió y a qué hora sucedió. Acordar la hora generalmente requiere múltiples rondas de paso de mensajes a través de la red. A medida que aumenta el número de validadores, esta sobrecarga de comunicación crece cuadráticamente, lo que hace cada vez más costoso alcanzar un consenso rápidamente.

PoH proporciona una referencia de ordenación verificable que puede reducir parte de la coordinación de tiempo. No elimina la comunicación de consenso ni hace que una ranura sea equivalente a la finalidad económica. La confirmación optimista, la confirmación en cadena y la liquidación a nivel de aplicación utilizan diferentes umbrales y tiempos.

Sealevel y Gulf Stream: Velocidad más allá del reloj

PoH por sí solo no produce 65.000 TPS. Es la capa fundamental que hace posible las otras innovaciones de rendimiento de Solana.

Sealevel es el tiempo de ejecución de contratos inteligentes paralelos de Solana. Los contratos inteligentes son programas almacenados en una blockchain e invocados a través de transacciones. Mientras que la EVM de Ethereum procesa las transacciones secuencialmente, Sealevel puede ejecutar transacciones no conflictivas en múltiples núcleos de procesador. Este paralelismo proviene de las cuentas que cada transacción declara que leerá o escribirá; PoH suministra una referencia de ordenación pero no determina qué cuentas son independientes.

Gulf Stream es el protocolo de reenvío de transacciones sin mempool de Solana. En lugar de mantener transacciones no confirmadas en una cola de espera, Gulf Stream las reenvía al siguiente líder validador esperado antes de que se finalice el bloque actual, utilizando el programa del líder de PoH para saber quién es el siguiente. Turbine, el protocolo de propagación de bloques de Solana inspirado en BitTorrent, divide los bloques confirmados en paquetes más pequeños y los distribuye eficientemente por la red de validadores.

PoH es la base. Sealevel y Gulf Stream se construyen directamente sobre él, al igual que Turbine. La cifra de 65.000 TPS refleja todas estas innovaciones operando juntas, con PoH como la capa de ordenación de la que depende cada una.

Las aplicaciones ;DeFi<, incluidas las bolsas descentralizadas y los protocolos de préstamo, requieren un alto rendimiento de transacciones para funcionar a escala. La arquitectura habilitada por PoH de Solana hace posible que estas aplicaciones procesen miles de operaciones por segundo en la capa base, una capacidad que la mayoría de las blockchains de capa 1 actuales no igualan, aunque las soluciones de capa 2 en otras cadenas están reduciendo esta brecha para casos de uso específicos.

Para entender por qué importa esta arquitectura, ayuda comparar PoH directamente con los mecanismos de consenso con los que fue diseñado para trabajar.

Prueba de Historial frente a Prueba de Trabajo frente a Prueba de Participación: Una Comparación Directa

El punto estructural más importante antes de esta comparación: la Prueba de Historial no es un mecanismo de consenso. La Prueba de Trabajo y la Prueba de Participación son mecanismos de consenso. Comparar PoH directamente con PoW o PoS es como comparar un reloj con un sistema de votación. Resuelven problemas diferentes, y esa distinción moldea todo lo demás en esta tabla.

Nota: El TPS teórico de Solana representa la salida combinada de PoH, Sealevel, Turbine y Gulf Stream en condiciones óptimas. Esta cifra no se alcanza habitualmente en producción.

PoH frente a Prueba de Trabajo: Velocidad y Energía

La Prueba de Trabajo de Bitcoin y la Prueba de Historial de Solana abordan problemas diferentes, pero el contraste entre ellas en cuanto a rendimiento y energía es marcado. En PoW, los mineros compiten para resolver un rompecabezas computacionalmente intensivo. El ganador añade el siguiente bloque y recibe una recompensa. Esta competencia es intencionalmente costosa, ya que el gasto energético es lo que hace que revertir la cadena sea prohibitivamente caro. Bitcoin procesa aproximadamente 7 TPS como resultado directo de este diseño.

PoH no reemplaza el modelo de seguridad de PoW. Resuelve un problema diferente, el problema de la ordenación temporal, con muchos menos desperdicios computacionales. Solo un validador (el líder actual) produce la secuencia PoH en lugar de que todos los mineros compitan simultáneamente.

SHA-256 también se utiliza en el proceso de minería de Bitcoin, pero la aplicación difiere fundamentalmente. Los mineros de Bitcoin buscan un hash con propiedades específicas en una carrera competitiva. PoH de Solana ejecuta SHA-256 secuencialmente para producir un registro de tiempo, no para competir por nada.

PoH vs. Prueba de Participación: No es lo mismo

No, la Prueba de Historial no es lo mismo que la Prueba de Participación. Solana no utiliza PoH en lugar de PoS. Utiliza ambas simultáneamente, para diferentes propósitos.

La Prueba de Participación es un mecanismo de consenso en el que los validadores son elegidos para producir bloques en función de la cantidad de criptomoneda que han participado en staking como garantía. Ethereum cambió a Prueba de Participación en septiembre de 2022 con su actualización Merge. El PoS de Ethereum procesa aproximadamente entre 15 y 30 TPS en su capa base, con soluciones de capa 2 como Arbitrum y Optimism extendiendo el rendimiento efectivo considerablemente más allá de esa cifra.

Solana utiliza un sistema basado en PoS para la selección de validadores, que determina quién se convierte en el líder responsable de producir la secuencia PoH para una ranura dada. PoH proporciona entonces la ordenación temporal que Tower BFT utiliza para alcanzar el consenso. Los dos mecanismos son complementarios, no competidores. PoH es el reloj; PoS determina quién lo da cuerda.

Cómo interactúa la Prueba de Historial con la Arquitectura Completa de Solana

Para los desarrolladores que evalúan Solana como una plataforma, la pregunta no es solo qué hace PoH de forma aislada. Es cómo PoH encaja en la arquitectura completa de ocho innovaciones que Anatoly Yakovenko describió en su whitepaper de 2017, y qué exige esa arquitectura del hardware que la ejecuta.

Tower BFT: Uso del Registro PoH como Reloj de Votos

Tower BFT utiliza el registro de tiempo verificable de PoH para implementar un mecanismo de bloqueo de votos que sería imposible sin una secuencia compartida y confiable de ranuras.

Así es como funciona en la práctica. Los validadores en Solana emiten votos para bloques que consideran válidos. Cada voto está asociado con un número de ranura PoH específico. Tower BFT aplica una regla de bloqueo: una vez que un validador vota a favor de una ranura, no puede votar a favor de un fork conflictivo durante un número exponencialmente creciente de ranuras subsiguientes. Cuanto mayor es el bloqueo, más SOL participado en staking arriesga perder el validador por slashing si intenta votar en ambos lados de un fork.

Tower BFT puede aplicar estos bloqueos basados en el tiempo específicamente porque PoH proporciona una secuencia de ranuras verificable y compartida. Sin PoH, no habría una referencia común confiable para "la ranura 347.891 ocurrió antes que la ranura 347.892". El bloqueo de votos basado en el tiempo requiere un reloj confiable. PoH es ese reloj.

El calendario de líderes se determina con antelación utilizando ponderaciones de SOL participado en staking. Los validadores saben qué nodo se espera que produzca el flujo PoH y proponga un bloque para cada ranura entrante. Esta predecibilidad permite el reenvío consciente del líder antes de que el bloque actual se finalice, reduciendo la dependencia de un mempool global convencional sin eliminar la congestión, las caídas de transacciones, las tarifas de prioridad o el riesgo MEV.

BFT en el contexto de Tower BFT significa que la red tolera que hasta un tercio de los validadores actúen maliciosamente o fallen, mientras que aún así alcanza el consenso. La estructura de bloqueo exponencial garantiza que atacar la red a través de la manipulación de votos se vuelve geométricamente más costoso a medida que el período de bloqueo crece.

Sealevel: Cómo la Ordenación de Transacciones PoH Permite el Paralelismo

La mayoría de las blockchains procesan las transacciones en serie, una a la vez, porque sin un orden verificado no pueden determinar de forma segura qué transacciones pueden ejecutarse simultáneamente sin conflictos. Si dos transacciones intentan modificar el mismo saldo de cuenta, procesarlas en paralelo sin conocer su orden conlleva el riesgo de resultados de doble gasto.

Sealevel resuelve esto leyendo la cola de transacciones verificada de PoH y analizando los conjuntos declarados de lectura y escritura de cada transacción. Dado que cada transacción de Solana debe especificar de qué cuentas lee y a cuáles escribe, Sealevel puede identificar en el momento de la presentación qué transacciones son independientes. Las transacciones independientes (aquellas que tocan cuentas completamente diferentes) pueden ejecutarse simultáneamente en múltiples núcleos de procesador o hilos de GPU. Las transacciones interdependientes se ejecutan secuencialmente en su orden PoH verificado.

El papel de PoH es proporcionar la cola de transacciones ordenada y con marca de tiempo que Sealevel consume. Sin la ordenación verificada que produce PoH, la ejecución paralela requeriría una costosa sobrecarga de coordinación para evitar conflictos. Solana se refiere a sus programas en cadena como "programas" en lugar de contratos inteligentes en su documentación nativa, lo que refleja una distinción arquitectónica del modelo de ejecución de Ethereum, aunque el término "contratos inteligentes" es ampliamente entendido y utilizado en la industria.

Gulf Stream utiliza el calendario de líderes de PoH para enviar transacciones no confirmadas directamente a los próximos validadores líderes, y Turbine utiliza bloques ordenados por PoH como base para su árbol de propagación de bloques al estilo BitTorrent. Cada componente de rendimiento importante en la arquitectura de Solana depende de PoH como su base de ordenación.

Esta solidez arquitectónica es también la fuente de algunas de las críticas más significativas de PoH, específicamente las demandas de hardware que impone a los validadores.

Limitaciones y Críticas de la Prueba de Historial: Una Evaluación Honesta

La Prueba de Historial conlleva importantes contrapartidas arquitectónicas, y la más trascendental de ellas es la demanda de hardware que impone a los validadores que la ejecutan.

Altos Requisitos de Hardware de Validador y Presión de Centralización

Ejecutar un validador de Solana requiere hardware de servidor de gama alta: una CPU con un alto número de núcleos, un mínimo de 128 GB de RAM, SSD NVMe y conectividad de red de varios gigabits. La documentación de Solana recomienda especificaciones de hardware que cuestan entre $5,000 y $20,000 o más para ensamblar y operar.

Esta barrera de costes limita la participación en el conjunto de validadores a operadores bien financiados. Un nodo completo de Bitcoin puede funcionar en una Raspberry Pi que cuesta menos de $100. Un validador de Solana no puede. El resultado es una presión de centralización: cuanto mayor es el coste de participación, menor es el grupo de validadores potenciales y más concentrado se vuelve el poder de consenso de la red entre operadores institucionales bien financiados.

La presión de centralización es el encuadre preciso aquí, no la centralización completada. Solana ha mantenido aproximadamente entre 1.500 y 2.000 validadores activos, menos que el conjunto de validadores de Ethereum de varios cientos de miles de validadores, aunque el umbral de hardware más bajo de Ethereum implica diferentes requisitos económicos (se requieren 32 ETH para participar en staking). La Fundación Solana ha implementado programas de delegación de participación para apoyar a validadores más pequeños, pero el requisito de hardware subyacente impulsado por las demandas de rendimiento de PoH sigue siendo estructural, no incidental.

La contrapartida es deliberada: la arquitectura de Yakovenko prioriza el rendimiento sobre la accesibilidad, aceptando la presión de centralización como el coste del rendimiento. Si esa contrapartida es aceptable depende de lo que el evaluador valore más.

Interrupciones de Red: ¿Fue la Prueba de Historial la Culpable?

La Prueba de Historial en sí misma no fue la causa de las principales interrupciones de la red de Solana. Las interrupciones se debieron a inundaciones de transacciones spam que abrumaron la capacidad de cómputo de la red y a errores en el software del cliente validador.

Los incidentes documentados son específicos. En septiembre de 2021, la red de Solana experimentó una interrupción de 17 horas causada por una avalancha de transacciones generadas por bot durante la oferta inicial de DEX de Raydium. El volumen de transacciones spam abrumó la memoria de los validadores, provocando que los validadores fallaran y la red se detuviera hasta que se pudo organizar un reinicio coordinado. Otras interrupciones de red ocurrieron en enero de 2022 y mayo de 2022, cada una atribuible a combinaciones de ataques de spam y errores de software de validadores, en lugar de fallos en el propio mecanismo PoH.

La conexión arquitectónica honesta es la siguiente: el diseño de PoH prioriza el rendimiento sobre la gestión conservadora de recursos, lo que significaba que la red no tenía limitación de tasa incorporada ni prevención de spam basada en tarifas en el momento de esas interrupciones. Una red diseñada para 65.000 TPS debe manejar 65.000 TPS de tráfico entrante, incluido el tráfico malicioso. Las arquitecturas más conservadoras, al limitar el rendimiento, también limitan la superficie de ataque.

Después de 2022, Solana implementó varias respuestas de ingeniería: el protocolo de red QUIC para una ingesta de transacciones más resiliente, mercados de comisiones de transacción para hacer que el spam sea económicamente costoso y calidad de servicio ponderada por el stake para priorizar transacciones de validadores con un stake significativo. Estas medidas han mejorado considerablemente la estabilidad de la red.

El historial de interrupciones refleja la inmadurez de ingeniería en un sistema de alto rendimiento, no un defecto en el concepto de Proof of History en sí mismo, aunque ambos están arquitectónicamente conectados. Los inversores y desarrolladores que evalúan Solana deben comprender esta distinción con precisión.

Dependencias de sincronización de reloj

La cadena de hash secuencial de PoH depende de que los validadores mantengan relojes locales suficientemente precisos. Una deriva significativa del reloj entre validadores puede crear inconsistencias en el tiempo de las ranuras (slots), donde los validadores discrepan sobre a qué ranura pertenece una salida de hash determinada.

En la práctica, esto se gestiona mediante la sincronización estándar del Protocolo de Tiempo de Red (NTP), y la deriva del reloj no ha sido una fuente significativa de fallos en el mundo real. Representa una superficie de ataque teórica: un atacante sofisticado que pudiera manipular las señales de tiempo que llegan a un número significativo de validadores podría potencialmente interrumpir la asignación de ranuras. Esto se reconoce como una consideración de diseño en lugar de una vulnerabilidad crítica en el modelo de amenazas actual.

Preguntas Frecuentes Sobre Proof of History de Solana

Las siguientes respuestas abordan las preguntas más comunes sobre Proof of History, extraídas de patrones de búsqueda que reflejan lo que inversores, desarrolladores, investigadores y escépticos preguntan con mayor frecuencia.

¿Cuál es el propósito de Proof of History en Solana?

Proof of History crea un registro de tiempo criptográfico que permite a los validadores de Solana acordar el orden y el tiempo de las transacciones sin intercambiar mensajes de marca de tiempo entre sí. Al resolver la pregunta "¿cuándo sucedió esto?" criptográficamente, PoH libera a Tower BFT para que se centre únicamente en la pregunta "¿es esto válido?", reduciendo la sobrecarga de consenso y permitiendo el alto rendimiento de transacciones de Solana.

No. Proof of History es un mecanismo de cronometraje; Proof of Stake es un mecanismo de consenso para seleccionar qué validadores proponen bloques. Resuelven problemas diferentes. Solana utiliza ambos simultáneamente: PoH proporciona la secuencia de tiempo verificable que ordena las transacciones, mientras que un sistema basado en PoS determina qué validador produce el flujo de PoH para cada ranura. Confundir los dos es común en la cobertura de menor calidad de Solana, pero son componentes arquitectónicamente distintos.

Anatoly Yakovenko, cofundador y CEO de Solana Labs, introdujo Proof of History en un whitepaper de 2017 titulado Solana: Una nueva arquitectura para una blockchain de alto rendimiento. Antes de fundar Solana Labs, Yakovenko fue ingeniero principal en Qualcomm, donde trabajó en sistemas operativos distribuidos y algoritmos de compresión. La mainnet beta de Solana se lanzó en marzo de 2020.

El rendimiento teórico de Solana es una cifra teórica histórica de aproximadamente 65.000 transacciones por segundo en condiciones óptimas; el rendimiento observado en el mundo real generalmente oscila entre 2.000 y 4.000 TPS. La capa base de Ethereum procesa aproximadamente de 15 a 30 TPS, y las soluciones de Capa 2 extienden significativamente el rendimiento efectivo. La ventaja de velocidad de la capa base de Solana es estructural, impulsada por la ordenación temporal de PoH que permite la ejecución paralela y reduce la sobrecarga de consenso.

Las tres limitaciones principales documentadas son: altos requisitos de hardware para validadores (128 GB+ de RAM, SSD NVMe, red de varios gigabits, coste de hardware de $5.000 a $20.000+) que crean presión de centralización al excluir a participantes con menos recursos; problemas históricos de fiabilidad de la red, incluida la interrupción de 17 horas de septiembre de 2021 y múltiples paradas de red en 2022 causadas por ataques de spam y errores en el cliente validador; y la dependencia de la sincronización del reloj, donde una deriva significativa del reloj del validador representa una superficie de ataque teórica gestionada en la práctica mediante la sincronización NTP.

El máximo teórico de Solana es una cifra teórica histórica de aproximadamente 65.000 transacciones por segundo, como se describe en el whitepaper de Yakovenko de 2017. Esta cifra representa todas las innovaciones arquitectónicas de Solana operando a capacidad en condiciones de red óptimas. El rendimiento observado en el mundo real en condiciones típicas de red en vivo oscila entre aproximadamente 2.000 y 4.000 TPS. El techo teórico refleja el diseño arquitectónico; la cifra del mundo real refleja el rendimiento de producción.

Tower BFT es el mecanismo de votación y elección de bifurcación (fork-choice) ponderado por stake de Solana, construido en torno a las ranuras de PoH. Los validadores votan con bloqueos crecientes, lo que hace que las votaciones conflictivas sean costosas. No equipare una ranura objetivo con finalidad completa; verifique los niveles de compromiso actuales y los requisitos de la aplicación.

El mecanismo criptográfico en sí mismo, la cadena de hash secuencial SHA-256, es seguro. SHA-256 nunca se ha roto con éxito en entornos de producción y es considerado criptográficamente sólido por la comunidad de seguridad. La fiabilidad a nivel de red, incluidas las interrupciones de 2021 y 2022, es una preocupación separada de la seguridad criptográfica. La cadena de hash de PoH no se vio comprometida durante ninguna de las interrupciones de red de Solana; esos eventos fueron causados por agotamiento de recursos y errores de software, no por ninguna falla del protocolo criptográfico.

Sin PoH, los validadores de Solana necesitarían intercambiar mensajes de marca de tiempo antes de cada ronda de consenso para establecer el orden de las transacciones, como requieren los sistemas de consenso BFT tradicionales. Esta sobrecarga de paso de mensajes crece con el número de validadores y limita el rendimiento. PoH reemplaza esa comunicación con una prueba criptográfica: la cadena de hash demuestra el orden y el tiempo de los eventos, por lo que los validadores pueden proceder directamente a votar sobre la validez de las transacciones en lugar de primero negociar sobre el tiempo.

No. El hashing SHA-256 secuencial de PoH se ejecuta en un único validador líder designado para cada ranura, no en un campo de mineros compitiendo. No consume mucha energía de la manera en que lo hace la minería Proof of Work de Bitcoin, donde cada minero gasta simultáneamente potencia de cálculo compitiendo para encontrar un hash válido. El consumo total de energía de Solana es una fracción de la de Bitcoin. El coste del hardware asociado con los validadores de Solana es una preocupación financiera y de descentralización, pero es distinto de la cuestión del consumo de energía.

Solana es en sí misma una blockchain de capa 1. No se ejecuta sobre otra red de la manera en que lo hacen las soluciones de Capa 2 de Ethereum. Solana opera su propia blockchain independiente utilizando Proof of History para la ordenación temporal de transacciones y Tower BFT para el consenso, con SOL como su Token Nativo.

El código de Solana es de código abierto, lo que hace que el mecanismo PoH esté disponible para que otros proyectos lo estudien y adapten. En la práctica, PoH está profundamente integrado en la arquitectura completa de Solana. Tower BFT, Sealevel y Gulf Stream dependen de la secuencia de PoH. Extraer y aplicar PoH a una blockchain diferente requeriría reproducir gran parte de la pila circundante de Solana para lograr los mismos beneficios de rendimiento.

Explorar SOL en Bybit

Los lectores pueden revisar la información actual del mercado de SOL o el mercado Spot SOL/USDT.. Estos enlaces proporcionan acceso al mercado y no demuestran que Solana, un monedero o un protocolo de un Tercero sea adecuado para todos los lectores.

Conclusión: ¿Es el Proof of History una innovación genuina?

Proof of History es una innovación criptográfica genuina. El mecanismo de cadena de hashes SHA-256 resuelve un problema real en los sistemas distribuidos: demostrar el paso del tiempo sin confiar en un único reloj, de una forma que sea verificable por cualquier observador sin requerir la reejecución de todo el cómputo.

Las implicaciones en el rendimiento son reales. La ventaja de rendimiento de la capa 1 de Solana sobre otras cadenas de bloques principales es estructural, no accidental, y PoH es el mecanismo fundacional que lo hace posible. Los inversores que evalúen si esa ventaja es duradera deben sopesarla frente a los inconvenientes documentados: requisitos de hardware para validadores que crean presión hacia la centralización, un historial de fiabilidad de la red que incluye interrupciones graves y un diseño optimizado para el rendimiento que prioriza la capacidad de procesamiento sobre una resiliencia conservadora.

Esos inconvenientes son retos de ingeniería, no fallos fundamentales en el diseño criptográfico. La implementación posterior a 2022 de QUIC, los mercados de comisiones y la calidad de servicio ponderada por la acción de Participar en staking demuestra que el equipo de ingeniería de Solana ha abordado los fallos de fiabilidad más agudos. Si una mayor maduración alinea el perfil de fiabilidad con la promesa de rendimiento es una pregunta que responderá el historial operativo continuo de la red.

Un lector que haya estudiado este artículo puede ahora definir el Proof of History con precisión y explicar cómo la cadena de hashes SHA-256 produce un registro de tiempo verificable. Puede distinguir el PoH de los mecanismos de consenso como el Proof of Stake, articular por qué el PoH permite la ventaja de rendimiento de Solana y evaluar las limitaciones documentadas con el contexto adecuado. Esa es la visión técnica necesaria para evaluar la arquitectura de Solana por sus propios méritos.

La información de este artículo refleja documentación técnica disponible públicamente y está actualizada a fecha de publicación. Los protocolos de Blockchain y las métricas de rendimiento de la red cambian con el tiempo. Este contenido no está afiliado ni patrocinado por Solana Labs ni por la Solana Foundation.

Lecturas relacionadas

• Mecanismo de Consenso de Solana
• Arquitectura de Solana
• Velocidad de Solana: TPS reales frente a teoría