Proof of History (PoH)

¿Qué es Proof of History (PoH)?

Proof of History (PoH) es un método criptográfico para llevar la cuenta del tiempo que crea un registro verificable del orden y el paso del tiempo entre eventos en una blockchain.En el ámbito cripto, Proof of History es más conocido como una tecnología fundamental utilizada por Solana para ayudar a los validadores a acordar el orden de las transacciones de forma más eficiente.

El libro blanco de Solana describe Proof of History como una prueba que permite verificar el orden y el paso del tiempo entre eventos.

A menudo se confunde PoH con un mecanismo de consenso completo e independiente, pero es más adecuado entenderlo como un reloj criptográfico que funciona junto con el consenso.Solana utiliza Proof of History junto con Proof of Stake y un sistema de votación de tipo Tower BFT para ayudar a los validadores a procesar bloques, votar forks y finalizar el registro.El principal problema que PoH intenta resolver es que las redes descentralizadas no comparten de forma natural un reloj fiable.En una red blockchain global, los validadores reciben mensajes en distintos momentos debido a la latencia, la geografía, las diferencias de hardware y la congestión de la red.Sin un método fiable de ordenación, los validadores deben comunicarse más a menudo para acordar qué evento ocurrió primero.Proof of History reduce esa carga de comunicación al incorporar una secuencia temporal verificable al registro.La forma más sencilla de entender PoH es que proporciona a la blockchain una cronología criptográfica que los validadores pueden comprobar sin confiar en un reloj convencional.

Cómo funciona Proof of History

Proof of History funciona ejecutando un proceso criptográfico secuencial que genera una cadena de hashes.Cada hash depende del hash anterior.Como cada paso depende del anterior, la secuencia no puede generarse toda de una vez en paralelo.Esto demuestra que se ha realizado cierta cantidad de cálculo secuencial entre dos puntos de la secuencia.

La explicación del reloj Proof of History de Solana describe PoH como una función de retraso verificable de alta frecuencia que registra un recuento y un resultado a lo largo del tiempo.

Los datos pueden insertarse en esta secuencia mediante su hash en el estado actual.Una vez insertados los datos, todos los hashes posteriores dependen de esa inserción.Esto significa que la secuencia puede demostrar que los datos existían antes de que se generaran los hashes posteriores.También puede ayudar a demostrar que los datos se añadieron después de que ya existieran hashes anteriores.Más adelante, los validadores pueden verificar la secuencia y comprobar si el orden es válido.

Proof of History como reloj criptográfico

Proof of History funciona como un reloj criptográfico, pero no es lo mismo que el reloj normal de un móvil, portátil o servidor.Un reloj convencional indica a los usuarios la hora real actual.Un reloj PoH demuestra que una secuencia de pasos computacionales se produjo en un orden concreto.Esta diferencia importa porque las blockchains no pueden confiar simplemente en la hora local de un validador.Un validador deshonesto o mal configurado podría afirmar que una marca de tiempo es falsa.Los retrasos de la red también pueden hacer que las marcas de tiempo no sean fiables entre distintas máquinas.

La documentación de sincronización de Anza explica que los nodos líderes de Solana marcan los bloques con pruebas criptográficas de que ha transcurrido cierto tiempo desde la última prueba.

La misma documentación explica que los validadores pueden verificar esas pruebas aunque los bloques lleguen en otro orden o se reproduzcan más adelante.Por tanto, PoH proporciona a los validadores una estructura temporal compartida basada en cálculos, en lugar de en la confianza en los relojes locales.Esto ayuda a que la red funcione más rápido porque los validadores necesitan menos comunicación de ida y vuelta para acordar el orden.

Proof of History y las funciones de retraso verificables

Una función de retraso verificable, o VDF, es una función que requiere una cantidad concreta de trabajo secuencial para calcularse, pero cuyo resultado es más fácil de verificar posteriormente.Proof of History suele explicarse como un proceso similar a una VDF de alta frecuencia.La característica importante es que no se puede predecir el resultado sin ejecutar realmente la secuencia.Como cada paso depende del resultado anterior, el proceso genera un retraso medible.Este retraso resulta útil como registro del paso del tiempo dentro del sistema blockchain.En el diseño de Solana, el proceso PoH utiliza una secuencia continua de hashes para crear una cronología.Más adelante, los validadores pueden comprobar el registro mediante una verificación paralela de distintas partes de la secuencia.Esto es importante porque generar la secuencia debería ser un proceso secuencial, mientras que verificarla debería ser mucho más rápido.Esta asimetría es similar a la de muchos sistemas criptográficos eficaces.Crear la prueba es difícil, pero para los demás es más fácil comprobar que es válida.

Proof of History frente a Proof of Work

Proof of History es distinto de Proof of Work.Proof of Work es un mecanismo de consenso en el que los mineros compiten por resolver problemas de hash y proponer bloques.Proof of History es un método de cronometraje y ordenación que ayuda a una red a demostrar cuándo ocurrieron unos eventos respecto a otros.Proof of Work utiliza los cálculos como coste de seguridad.Proof of History utiliza cálculos secuenciales como registro de orden temporal.En Proof of Work, muchos mineros compiten por encontrar un hash de bloque válido.En Proof of History, un líder produce una secuencia verificable que ayuda a ordenar entradas y transacciones.Una cadena PoW utiliza el trabajo acumulado para ayudar a decidir cuál es la cadena válida.Un diseño basado en PoH utiliza la secuencia PoH para respaldar la sincronización, la construcción de bloques y la votación de los validadores en un proceso más rápido.Ambos sistemas utilizan hashes, pero con objetivos distintos.PoW se ocupa principalmente de la seguridad económica y la competencia por los bloques, mientras que PoH se centra principalmente en el tiempo y el orden verificables.

Proof of History frente a Proof of Stake

Proof of History también es distinto de Proof of Stake.Proof of Stake es un mecanismo de consenso en el que los validadores bloquean stake y participan en la validación de bloques, las votaciones y la finalización.Proof of History no sustituye por sí solo al staking.Ayuda al proceso de validación al proporcionar a la red una estructura de ordenación más fiable.Solana suele describirse como una blockchain Proof of Stake que utiliza Proof of History como componente fundamental de sincronización y ordenación.En este modelo, el stake ayuda a determinar la influencia de los validadores y la programación de los líderes, mientras que PoH ayuda a organizar la cronología de las entradas.

La documentación de Anza sobre la rotación de líderes explica que los validadores seleccionan a los líderes previstos mediante un calendario de líderes y rechazan los bloques que no haya firmado el líder asignado al slot.

PoH ayuda a esos líderes a producir entradas ordenadas para los slots que tienen asignados.A continuación, los validadores verifican, reproducen y votan según las reglas de consenso del protocolo.PoS proporciona seguridad económica, mientras que PoH aporta una estructura temporal criptográfica.

Proof of History y los líderes de Solana

En Solana, los líderes son validadores asignados para producir entradas en determinados slots temporales.Un líder recibe transacciones, filtra las válidas, las ejecuta, las agrupa en entradas y las transmite a otros validadores.La secuencia PoH ayuda a ordenar correctamente estas entradas.El líder no se limita a afirmar que los eventos ocurrieron en un orden determinado.Los registra en la secuencia PoH para que otros validadores puedan comprobar el orden.Esto es importante porque los validadores pueden recibir paquetes de red en momentos distintos.En lugar de depender únicamente del momento de llegada, pueden comprobar el registro PoH del líder.La documentación de Anza sobre la generación de forks explica que los nodos se turnan para ser líderes y generar PoH que codifica cambios de estado.También explica que solo se aceptan las transacciones de un líder para cada slot.Esta estructura basada en líderes ayuda a Solana a procesar transacciones rápidamente y, a la vez, permite que los validadores comprueben el historial generado.

Proof of History y las entradas

En Solana, las entradas son lotes más pequeños de transacciones que se transmiten a los validadores.La documentación de sincronización de Anza explica que Solana puede dividir los bloques en lotes más pequeños llamados entradas y transmitirlos a los validadores en tiempo real antes del consenso del bloque.Este diseño difiere de los sistemas en los que los validadores esperan a que esté completo un bloque antes de realizar la mayor parte del trabajo.Los validadores pueden procesar las entradas de forma optimista a medida que llegan.El procesamiento optimista significa que pueden empezar a ejecutar y comprobar los datos antes de que el consenso definitivo se haya completado.Si posteriormente el consenso rechaza un fork, los validadores pueden revertir el estado.PoH hace posible este proceso más rápido porque las entradas están vinculadas a un orden verificable.Los validadores pueden procesar los datos con más certeza sobre su lugar en la cronología.Esto reduce el tiempo de inactividad y mejora el rendimiento.Sin embargo, también hace que el protocolo sea más complejo, ya que los validadores deben gestionar cuidadosamente los forks, las reversiones, las votaciones y la rotación de líderes.

Proof of History y los slots

Un slot es una unidad de tiempo durante la que un líder programado puede producir entradas.El calendario de líderes de Solana asigna de antemano validadores a los slots.Durante el slot que tiene asignado, se espera que el líder produzca el flujo PoH y agrupe las transacciones en entradas.La documentación de sincronización actual de Anza indica que la implementación vigente establece el tiempo de bloque en 800 milisegundos.La duración de los slots es importante porque la red necesita un ritmo predecible para la rotación de líderes, las votaciones y las confirmaciones.PoH ayuda a que estos slots sean útiles porque proporciona un registro criptográfico de los pasos transcurridos en la secuencia.Si un líder no produce entradas útiles, los demás validadores pueden seguir contabilizando el paso del tiempo mediante ticks o slots omitidos.Esto ayuda a que la red siga funcionando aunque algunos líderes estén desconectados, vayan lentos o pierdan la conexión.Los slots no son simplemente una métrica de velocidad para el usuario.Forman parte de la estructura temporal interna que conecta PoH, la rotación de líderes, los forks y las votaciones de los validadores.

Proof of History y los ticks

Los ticks son entradas PoH vacías que indican que ha transcurrido tiempo aunque no incluyan transacciones de usuarios.Son importantes porque la red necesita un registro temporal continuo, no solo un registro de los lotes de transacciones activos.La documentación de Anza sobre generación de forks explica que el flujo PoH incluye ticks que indican la actividad del líder y el paso del tiempo en el clúster.Si un líder no tiene transacciones que incluir, puede seguir generando ticks.Si un líder no está disponible o no transmite los datos, los validadores pueden contabilizar el tiempo previsto mediante secuencias compuestas solo por ticks.Esto ayuda a limitar los posibles forks y mantiene estructurada la rotación de líderes.Los ticks son como el latido de la secuencia PoH.No siempre representan actividad de los usuarios, pero ayudan a la red a medir el progreso.Esto resulta útil para las votaciones, las reversiones, la reproducción y la sincronización.Sin ticks, al registro le resultaría más difícil demostrar que han transcurrido intervalos vacíos.

Proof of History y Tower BFT

Tower BFT es el método de votación con bloqueo de votos de Solana, que funciona junto con la medición del tiempo de PoH.Los validadores votan sobre los forks y construyen una torre de votos que hace cada vez más costoso cambiar de fork con el paso del tiempo.

La documentación de Anza sobre Tower BFT explica que los validadores comunican mediante votos firmados qué fork consideran que tiene más peso.

También explica que los bloqueos se miden en slots y obligan a los validadores a asumir un coste de oportunidad al comprometerse con un fork.PoH es importante en este contexto porque Tower BFT depende de la medición del tiempo por slots y de una secuencia estructurada de eventos del registro.Los validadores utilizan votos para mostrar su apoyo a un fork.A medida que se acumulan votos, aumentan los bloqueos, lo que dificulta que los validadores cambien a forks contradictorios.Este proceso ayuda a la red a converger en un único historial aceptado.PoH no es el propio sistema de votación.Proporciona la estructura temporal que permite que el sistema de votación funcione de forma eficiente.

Proof of History y los forks

Un fork se produce cuando existen simultáneamente versiones distintas del registro.Los forks pueden aparecer en blockchains rápidas porque los líderes pueden perder datos, los validadores pueden recibir información en momentos diferentes o pueden producirse particiones de la red.Solana no espera a que todos los validadores estén de acuerdo con un bloque recién producido antes de producir el siguiente.

La documentación de Anza sobre la generación de forks explica que por ello los forks son habituales y que los validadores deben votar por uno de ellos hasta que el clúster finaliza una versión.

PoH ayuda a organizar los posibles forks porque las entradas de cada líder están vinculadas a la temporización de los slots y a la estructura de la secuencia PoH.Para cada slot, los validadores esperan entradas del líder programado.Los bloques o las entradas de un líder incorrecto pueden rechazarse.Si un líder omite su turno o falla, la red puede contabilizarlo mediante slots omitidos o historiales compuestos solo por ticks.Esto limita la forma de los posibles forks y ayuda a los validadores a reproducir el registro.PoH no elimina los forks, pero ayuda a gestionar su tratamiento de forma más estructurada.

Proof of History y el orden de las transacciones

La ordenación de transacciones es uno de los usos más importantes de Proof of History.Cuando muchos usuarios envían transacciones al mismo tiempo, la red necesita una forma de decidir cuáles llegaron primero y cómo deben procesarse.En los sistemas distribuidos tradicionales, acordar el orden puede requerir muchas rondas de comunicación.Estas comunicaciones llevan tiempo y pueden limitar el rendimiento.PoH reduce este problema al colocar las transacciones en una secuencia verificable.Una vez que una transacción o un lote de transacciones se registra en el flujo PoH, los validadores pueden comprobar su posición respecto a otras entradas.Esto no significa que los usuarios controlen su posición exacta en la cola.Los líderes siguen eligiendo qué transacciones válidas incluyen y cómo las agrupan, de acuerdo con las reglas del protocolo.Tampoco elimina todo el MEV ni todos los problemas de ordenación.PoH proporciona un registro del orden, pero la selección de transacciones y la equidad de ejecución siguen dependiendo del comportamiento general del protocolo y de los validadores.

Proof of History y el rendimiento de la red

Proof of History está diseñado para favorecer un alto rendimiento al reducir los retrasos de coordinación.Si los validadores ya disponen de una secuencia temporal verificable, necesitan comunicarse menos para acordar el orden básico de los eventos.Esto permite que el sistema integre de forma más intensiva el procesamiento de transacciones, la propagación de bloques, la reproducción y las votaciones.Un alto rendimiento es importante porque las aplicaciones cripto suelen necesitar una ejecución rápida y de bajo coste.El trading, los videojuegos, los pagos, los NFT, DeFi y las aplicaciones de consumo pueden verse afectados cuando las confirmaciones son lentas o las comisiones elevadas.PoH ayuda a Solana a impulsar un diseño en el que muchas operaciones se realizan en paralelo o mediante un proceso con una programación muy ajustada.Sin embargo, PoH no es el único responsable del rendimiento.También depende del diseño del runtime, la propagación de la red, el hardware de los validadores, los mercados de comisiones, la optimización del software, los patrones de acceso a cuentas y las reglas de consenso.PoH es una parte importante de una arquitectura blockchain de alto rendimiento más amplia.

Proof of History y el hardware de los validadores

PoH puede mejorar el rendimiento, pero también contribuye a que el entorno de validación de Solana sea exigente.Los validadores deben procesar grandes volúmenes de datos, verificar entradas, ejecutar transacciones, gestionar forks, votar y mantenerse sincronizados.Las cadenas de alto rendimiento suelen requerir hardware y redes más potentes que las cadenas más lentas.Esto genera un compromiso entre la velocidad y la accesibilidad para los validadores.Si los requisitos de hardware son demasiado altos, menos validadores independientes podrán participar.Si son demasiado bajos, es posible que la red no alcance el mismo rendimiento.PoH es en sí mismo un mecanismo de medición temporal, pero el diseño que lo rodea favorece procesos rápidos y cargas de trabajo exigentes para los validadores.Por eso, los usuarios que evalúen sistemas basados en PoH deben mirar más allá de las cifras de velocidad anunciadas.También deben analizar la distribución de validadores, los requisitos de hardware, la diversidad de clientes, la concentración del alojamiento y la fiabilidad de la red.Una blockchain rápida es más sólida cuando muchos validadores independientes pueden ejecutarla y verificarla de forma realista.

Proof of History y la finalización

La finalización significa que una transacción se acepta como liquidada conforme a las reglas de la red.PoH ayuda a procesar las transacciones rápidamente, pero la finalización sigue dependiendo de los votos de los validadores y de las reglas de consenso.En Solana, los validadores votan sobre los forks y el clúster finaliza una versión del historial mediante su proceso de consenso.El análisis de consenso de Neodyme describe Solana como una blockchain Proof of Stake en la que se asigna un líder para cada slot y la finalización depende de votos de validadores ponderados por stake.Los usuarios no deben pensar que PoH finaliza por sí solo las transacciones.PoH ayuda a establecer el orden de los eventos, mientras que la votación de los validadores ayuda a decidir qué fork se acepta.Esta diferencia es importante para los depósitos, las retiradas, los sistemas de trading, los bridges y las aplicaciones que necesitan una sólida certeza de liquidación.Una transacción puede aparecer rápidamente, pero distintas aplicaciones pueden utilizar diferentes estándares de confirmación.En transferencias de gran valor, los usuarios y desarrolladores deben entender los niveles de compromiso y los supuestos de finalización.Una ordenación rápida no equivale a una finalización absolutamente instantánea.

Proof of History y seguridad

Proof of History mejora la seguridad al hacer que la ordenación de eventos sea verificable y más difícil de falsificar a posteriori.Como la secuencia depende de hashes secuenciales, un atacante no puede reordenar libremente los eventos sin afectar a los resultados posteriores.Esto ayuda a proteger la integridad de la cronología del registro.Sin embargo, PoH no constituye por sí solo un modelo de seguridad completo.La red sigue necesitando validadores ponderados por stake, programación de líderes, votaciones, reglas de selección de forks, supuestos de slashing o sanciones, software correcto y participación honesta.PoH por sí solo no puede resolver los problemas derivados de fallos en el software de los validadores, las operaciones de red, la gobernanza o la ejecución de transacciones.PoH demuestra el orden y el paso del tiempo dentro del registro, pero no demuestra que todas las aplicaciones sean seguras.Un contrato inteligente malicioso, una transacción de phishing, un token fraudulento o una wallet comprometida pueden seguir perjudicando a los usuarios en una cadena basada en PoH.La seguridad cripto siempre se compone de varias capas.Proof of History es una capa de la arquitectura general de Solana.

Proof of History y descentralización

Proof of History puede favorecer la descentralización al reducir la cantidad de comunicación que necesitan los validadores para acordar el tiempo y el orden.Una menor carga de comunicación puede ayudar a un conjunto global amplio de validadores a procesar datos de forma más eficiente.Sin embargo, PoH por sí solo no garantiza la descentralización.Esta depende del número de validadores independientes, la distribución del stake, el funcionamiento de los calendarios de líderes, la facilidad para ejecutar el software de validación y la concentración de la infraestructura.Una red puede ser rápida y, aun así, tener problemas de descentralización si validar resulta demasiado costoso o si un grupo reducido controla demasiado stake.Una red también puede tener un reloj ingenioso y, aun así, depender de la coordinación social y económica para las actualizaciones y las decisiones de seguridad.Los usuarios deben considerar PoH una decisión técnica de diseño, no una prueba de que toda la red esté descentralizada.Un buen análisis de descentralización debe incluir la concentración del stake, el número de validadores, la diversidad de clientes, la geografía, el alojamiento, la gobernanza y la resistencia a la censura.PoH puede ayudar al sistema a escalar, pero la descentralización depende del ecosistema en su conjunto.

Ventajas de Proof of History

La primera ventaja de Proof of History es la ordenación temporal verificable.PoH permite a los validadores comprobar la secuencia de eventos sin confiar en una marca de tiempo convencional.La segunda ventaja es una menor carga de coordinación.Los validadores pueden procesar entradas ordenadas sin tener que comunicarse constantemente sobre el tiempo.La tercera ventaja es un procesamiento más rápido de las transacciones.Una secuencia verificable facilita la integración de procesos, el procesamiento optimista y las votaciones rápidas.La cuarta ventaja es una reproducción y auditabilidad mejores.Los validadores pueden reproducir el registro y verificar la secuencia PoH para comprobar que los eventos se ordenaron correctamente.La quinta ventaja es el respaldo a aplicaciones de alto rendimiento.Una ordenación rápida puede hacer que las aplicaciones DeFi, los pagos, los juegos, los NFT y las aplicaciones cripto de consumo respondan con mayor agilidad.La sexta ventaja es una programación más clara de los líderes.PoH utiliza slots, líderes y ticks para estructurar la producción de bloques.La séptima ventaja es un reloj interno más sólido para un sistema descentralizado.Este reloj se basa en cálculos criptográficos, no en la confianza en un único servidor horario.

Limitaciones de Proof of History

La primera limitación es que PoH no es un mecanismo de consenso independiente.Debe funcionar junto con las votaciones de validadores, la ponderación por stake, la selección de forks y las reglas de finalización.La segunda limitación es la complejidad.Los sistemas basados en PoH pueden ser más difíciles de entender para los usuarios y desarrolladores que los modelos de producción de bloques más sencillos.La tercera limitación es la exigencia de hardware.Los diseños de alto rendimiento pueden elevar los requisitos de recursos para los validadores.La cuarta limitación es que PoH no impide todos los tipos de ataques.Ayuda con la ordenación y la verificación temporal, pero no detiene el phishing, las aplicaciones maliciosas, el robo de claves privadas ni los contratos inteligentes inseguros.La quinta limitación es la dependencia del líder durante los slots.Si un líder programado funciona mal o no transmite los datos, la red debe gestionar slots omitidos, forks o mecanismos de recuperación.La sexta limitación es que la velocidad puede generar dificultades operativas.Las redes rápidas deben gestionar cuidadosamente los errores de software, la congestión de la red, el spam y la sincronización de los validadores.La séptima limitación es que los usuarios pueden interpretarlo mal.Muchas personas oyen «Proof of History» y dan por hecho que funciona como PoW o PoS, cuando en realidad es un componente criptográfico de otro tipo.

Proof of History y contratos inteligentes

Los contratos inteligentes de una blockchain compatible con PoH siguen dependiendo de la cadena base para ordenar las transacciones y actualizar el estado.PoH ayuda a determinar dónde aparecen las transacciones en la cronología del registro.A continuación, el runtime las ejecuta conforme a las reglas de los contratos inteligentes.Esto significa que PoH puede aumentar la velocidad con que se ordenan y procesan las interacciones con contratos inteligentes.Sin embargo, PoH no hace que los contratos inteligentes sean seguros automáticamente.Un contrato inteligente puede seguir teniendo errores, permisos inseguros, un diseño económico deficiente o instrucciones maliciosas.Los usuarios deben seguir comprobando las direcciones de los contratos, los programas de los tokens, las solicitudes de la wallet, las autorizaciones y la documentación oficial.Los desarrolladores deben seguir auditando los programas, probando casos límite, gestionando cuidadosamente las actualizaciones y protegiendo las claves de administrador.PoH mejora la estructura temporal de la cadena base, pero la seguridad de las aplicaciones sigue siendo una responsabilidad independiente.Una ejecución rápida puede mejorar las buenas aplicaciones, pero también acelerar las estafas.

Proof of History y MEV

MEV significa valor máximo extraíble y se refiere al valor capturado mediante la ordenación, inclusión o exclusión de transacciones.Como PoH ayuda a crear un orden de eventos rápido y verificable, está directamente relacionado con la circulación de las transacciones por la red.PoH puede hacer más transparente la ordenación a posteriori, pero no elimina toda influencia sobre ella.Los líderes siguen influyendo en las transacciones que incluyen durante sus slots.El enrutamiento de la red, las comisiones de prioridad, el spam, la latencia y el comportamiento de los validadores pueden afectar a la ejecución de las transacciones.Para los traders y los usuarios de DeFi, la calidad total de ejecución depende de más factores que el diseño temporal del protocolo base.Los usuarios deben tener en cuenta el deslizamiento, las comisiones de prioridad, las transacciones fallidas, la calidad del enrutamiento, la liquidez y posibles comportamientos adversos.Los desarrolladores deben diseñar aplicaciones resilientes a la ordenación rápida, las condiciones de carrera y la competencia entre transacciones.PoH es una potente herramienta de ordenación, pero la equidad en la ejecución es un reto más amplio para todo el ecosistema.La existencia de un reloj criptográfico no elimina la necesidad de diseñar teniendo en cuenta el MEV.

Malentendidos habituales sobre Proof of History

Un malentendido habitual es creer que Proof of History es lo mismo que Proof of Stake.Proof of Stake es el modelo de consenso económico, mientras que Proof of History es un sistema criptográfico de medición del tiempo y ordenación.Otro malentendido es creer que Proof of History sustituye a los validadores.Siguen siendo necesarios para verificar transacciones, votar sobre forks, ejecutar software de consenso y mantener la red.Otro malentendido es creer que PoH demuestra la hora exacta del día en el mundo real.PoH demuestra el orden relativo y el paso del tiempo computacional dentro del registro, no que un evento ocurriera en un segundo concreto del reloj convencional.Otro malentendido es creer que PoH hace imposibles los forks.Los forks pueden seguir produciéndose, pero PoH ayuda a estructurar el tratamiento de las entradas, los slots, los ticks y las salidas de los líderes.Otro malentendido es pensar que PoH finaliza por sí solo las transacciones.La finalización sigue dependiendo de los votos de los validadores, el consenso ponderado por stake y las reglas de selección de forks.

Buenas prácticas para los usuarios

Los usuarios deben entender que PoH es una característica del diseño de la red, no una herramienta de seguridad para su wallet personal.Deben seguir protegiendo cuidadosamente las frases de recuperación, las claves privadas y las hardware wallets.No deben dar por hecho que una confirmación rápida significa que una transacción no tiene riesgos.Deben comprobar los detalles de la transacción antes de firmar, ya que las cadenas rápidas también pueden ejecutar errores rápidamente.Deben verificar los enlaces oficiales de las aplicaciones y las direcciones de los tokens antes de interactuar con programas on-chain.Deben comprender los niveles de compromiso al depositar o retirar fondos a través de aplicaciones.Deben recordar que PoH no evita las estafas, el phishing, los tokens falsos ni los programas maliciosos.Deben estar atentos a las actualizaciones sobre el estado de la red durante periodos de congestión o actividad inusual.Deben hacer transferencias de prueba de pequeño importe al enviar fondos a una dirección o programa nuevo.Deben considerar PoH una característica de rendimiento y ordenación, no una garantía de seguridad de la inversión.

Buenas prácticas para desarrolladores

Los desarrolladores deben entender cómo afectan los slots, los líderes, las entradas, los ticks y los forks al comportamiento de las aplicaciones.Deben diseñar programas que gestionen con cuidado la ordenación de transacciones, el bloqueo de cuentas, la reproducción y los casos de fallo.Deben evitar dar por hecho que la ejecución rápida elimina la necesidad de realizar pruebas rigurosas.Deben supervisar cómo afectan las comisiones de prioridad, la competencia entre transacciones y la latencia a la experiencia de usuario.Deben diseñar aplicaciones que sigan siendo seguras cuando las transacciones llegan rápidamente o en un orden competitivo.Deben documentar los supuestos de confirmación para depósitos, retiradas, acuñaciones, liquidaciones y procesos de liquidación.Deben evitar almacenar datos privados sensibles on-chain solo porque la cadena sea rápida.Deben auditar los programas, gestionar cuidadosamente la autoridad de actualización y supervisar los cambios del runtime.Deben crear solicitudes claras en las wallets para que los usuarios sepan exactamente qué están firmando.PoH puede respaldar aplicaciones de alta velocidad, pero los desarrolladores siguen siendo responsables de que la lógica de las aplicaciones sea segura.

Preguntas frecuentes

¿Qué significa Proof of History?

Proof of History significa que una blockchain utiliza una secuencia criptográfica para demostrar el orden y el paso del tiempo entre eventos.

¿Proof of History es un mecanismo de consenso?

Por lo general, Proof of History no se considera un mecanismo de consenso completo e independiente, ya que funciona junto con las votaciones de los validadores y un consenso de tipo Proof of Stake.

¿Qué blockchain es conocida por Proof of History?

Solana es la blockchain más estrechamente asociada con Proof of History.

¿Por qué es importante Proof of History?

Proof of History es importante porque ofrece a los validadores una cronología verificable, lo que puede reducir la carga de comunicación y favorecer un procesamiento más rápido de las transacciones.

¿Cómo ordena las transacciones Proof of History?

Proof of History ordena las transacciones insertando datos en un flujo secuencial de hashes, en el que los resultados posteriores dependen de las entradas anteriores.

¿Proof of History es lo mismo que Proof of Work?

No. Proof of Work utiliza la competencia de minería para alcanzar el consenso, mientras que Proof of History crea una secuencia verificable de tiempo y orden.

¿Proof of History es lo mismo que Proof of Stake?

No. Proof of Stake utiliza activos en staking y validadores para alcanzar el consenso, mientras que Proof of History proporciona un reloj criptográfico que facilita la ordenación y la sincronización.

¿Qué es un tick PoH?

Un tick PoH es una entrada vacía que ayuda a indicar la actividad del líder y el paso del tiempo en el flujo PoH.

¿Qué es un líder de Solana?

Un líder de Solana es un validador programado para producir entradas durante un slot y registrarlas en la secuencia PoH.

¿PoH impide los forks?

No. PoH no impide todos los forks, pero ayuda a estructurar su generación, reproducción y las votaciones de los validadores.

¿PoH hace que las transacciones se finalicen al instante?

No. PoH facilita una ordenación rápida, pero la finalización sigue dependiendo de los votos de los validadores y las reglas de consenso.

¿PoH protege a los usuarios frente a las estafas?

No. PoH es un mecanismo de medición temporal y ordenación, por lo que los usuarios siguen necesitando proteger sus wallets, revisar las transacciones y actuar con diligencia al utilizar aplicaciones.

Conclusión

Proof of History (PoH) es un método criptográfico para llevar la cuenta del tiempo que ayuda a una blockchain a demostrar el orden y el paso del tiempo entre eventos.Es más conocido como componente fundamental de la arquitectura de Solana, donde funciona junto con Proof of Stake, la programación de líderes, las entradas, los ticks, los forks y las votaciones de validadores de tipo Tower BFT.PoH no es lo mismo que Proof of Work ni que Proof of Stake.Es un reloj criptográfico que ayuda a los validadores a acordar el orden de los eventos con menos carga de comunicación.Esto puede favorecer un procesamiento más rápido de las transacciones, un mayor rendimiento, la ejecución optimista, una reproducción eficiente y un proceso de liderazgo más estructurado.Al mismo tiempo, PoH no resuelve por sí solo todos los problemas de las blockchains.No elimina la necesidad de validadores, consenso ponderado por stake, reglas de finalización, selección de forks, software seguro, buena gobernanza ni contratos inteligentes seguros.Tampoco protege a los usuarios frente al phishing, el robo de claves privadas, los programas maliciosos o las malas decisiones de inversión.El principal valor de Proof of History es que proporciona a una red descentralizada una cronología verificable sin depender de un reloj centralizado.La forma más sencilla de entender PoH es que convierte el tiempo en un registro criptográfico, lo que permite a los validadores comprobar cuándo ocurrieron los eventos unos respecto a otros y procesar la actividad de la blockchain de forma más eficiente.