Tower BFT

¿Qué es Tower BFT?

Tower BFT es el mecanismo de votación de consenso de tolerancia a fallos bizantinos de Solana optimizado para Proof of History.

En cripto, Tower BFT se entiende mejor como el sistema que ayuda a los validadores de Solana a votar por la bifurcación correcta, generar compromiso en torno a los bloques y hacer que las reversiones sean cada vez más costosas con el tiempo.

La documentación oficial de Anza sobre Tower BFT explica que Solana genera una fuente de tiempo mediante Proof of History y utiliza los slots como unidad de tiempo.

Cada slot puede tener un líder designado que puede producir un bloque.

Después, los validadores votan por la bifurcación que consideran que debe convertirse en la cadena válida con mayor peso.

Tower BFT no es lo mismo que Proof of History.

Proof of History proporciona un reloj criptográfico y una estructura de ordenación, mientras que Tower BFT utiliza esa estructura temporal para organizar los votos de los validadores, los bloqueos, la elección de bifurcaciones y el compromiso.

El whitepaper oficial de Solana describe Proof of History como una prueba para verificar el orden y el paso del tiempo entre eventos.

Tower BFT desarrolla esta idea al permitir que los validadores voten con bloqueos basados en el tiempo y medidos en slots.

En un glosario cripto, Tower BFT debe entenderse como la capa de consenso original de Solana de estilo BFT, que utiliza la temporización de Proof of History para reducir la sobrecarga de coordinación y respaldar una confirmación rápida de bloques.

Por qué es importante Tower BFT

Tower BFT es importante porque el consenso es el proceso que permite a una blockchain acordar un único historial compartido.

Sin consenso, los validadores podrían discrepar sobre qué transacciones ocurrieron, qué saldos son válidos y en qué bloques se debe confiar.

Solana se diseñó para ofrecer un alto rendimiento y baja latencia, por lo que su diseño de consenso debía evitar esperas innecesarias y un intercambio excesivo de mensajes.

Tower BFT contribuye a este objetivo al utilizar Proof of History como referencia temporal compartida antes de alcanzar el consenso completo.

El artículo de Solana sobre Tower BFT describe Tower BFT como una implementación personalizada de PBFT que aprovecha Proof of History como reloj previo al consenso para reducir la sobrecarga de mensajería y la latencia.

Esto es importante para los usuarios porque el consenso afecta a la confirmación de transacciones, las expectativas de finalidad, el comportamiento de los validadores y la fiabilidad de la red.

Es importante para los validadores porque las decisiones de voto pueden crear bloqueos que limitan las opciones de voto futuras.

También es importante para los desarrolladores porque la fiabilidad de las aplicaciones depende de comprender cómo se comportan los estados confirmados, finalizados y relacionados con bifurcaciones.

Es importante para los traders porque la finalidad rápida y la liquidación estable pueden afectar a depósitos, retiradas, actividad DeFi y riesgo de arbitraje en exchanges.

Por tanto, Tower BFT no es solo un detalle de los validadores, sino también parte de la infraestructura de mercado más amplia que respalda la actividad cripto basada en Solana.

¿Qué significa BFT?

BFT significa Byzantine Fault Tolerance, o tolerancia a fallos bizantinos.

Un fallo bizantino es un error en el que un participante puede comportarse de forma impredecible, incorrecta o maliciosa.

En los sistemas blockchain, esto podría significar que un validador está desconectado, es lento, deshonesto, vota dos veces, censura o produce mensajes contradictorios.

Un sistema de consenso BFT trata de mantener la red segura incluso cuando algunos participantes presentan fallos.

La seguridad significa que los participantes honestos no deberían finalizar historiales contradictorios.

La vitalidad significa que la red debería seguir avanzando cuando suficientes participantes honestos pueden comunicarse.

Tower BFT pertenece a la familia de diseños de consenso de estilo BFT porque se centra en los votos de validadores, la elección de bifurcaciones, los bloqueos y el compromiso ante posibles fallos.

No es una simple votación por mayoría según el número de validadores.

Solana utiliza votación ponderada por stake, lo que significa que los validadores con más stake delegado tienen mayor peso de voto.

La página oficial de validadores de Solana explica que los validadores reproducen el libro mayor, envían votos a cuentas de voto y que el clúster utiliza votos ponderados por stake para seleccionar un bloque cuando surgen bifurcaciones.

Tower BFT y Proof of History

Proof of History es la base temporal que diferencia a Tower BFT de muchos sistemas BFT tradicionales.

Los protocolos BFT tradicionales suelen requerir que los validadores intercambien más mensajes para acordar tiempos de espera y avanzar a través de vistas o rondas.

El diseño de Solana utiliza una secuencia verificable de cálculos para crear un registro compartido del tiempo y del orden.

El whitepaper de Solana afirma que Proof of History puede codificar el paso del tiempo sin confianza en un libro mayor de solo adición.

Esto proporciona a Tower BFT una forma de medir los bloqueos de voto en slots, en vez de depender únicamente de relojes locales y negociaciones repetidas.

En términos sencillos, Proof of History proporciona a la red una línea temporal compartida y Tower BFT utiliza esa línea temporal para organizar los votos de consenso.

Por este motivo, Tower BFT suele describirse como BFT optimizado para PoH.

La estructura de PoH, similar a un reloj, ayuda a los validadores a saber cuándo expiran determinados compromisos de voto.

También ayuda al protocolo a reducir la sobrecarga de comunicación, ya que los tiempos de espera pueden derivarse de la estructura temporal del libro mayor.

Para los usuarios, el resultado es un modelo de consenso diseñado para respaldar una confirmación más rápida que los diseños de consenso antiguos con un elevado intercambio de mensajes.

Tower BFT y los slots

Un slot es la unidad de tiempo de Solana para la producción de bloques y la votación de validadores.

En Tower BFT, los bloqueos y compromisos de voto se miden en slots.

La documentación de Anza sobre Tower BFT indica que cada slot tiene un líder designado que puede producir un bloque.

Un líder puede no producir un bloque, por lo que algunos slots pueden no contener bloques.

Los validadores observan los bloques y votan por la bifurcación que creen que debe convertirse en la bifurcación válida con mayor peso.

Dado que los slots crean una estructura predecible, los validadores pueden coordinarse en torno a una línea temporal compartida.

Un bloque está asociado a un slot y los votos pueden hacer referencia a bloques de una bifurcación.

Esto permite a Tower BFT conectar en un único proceso el tiempo, la rotación de líderes, la elección de bifurcaciones y el compromiso de los validadores.

La temporización basada en slots también es importante para la finalidad, ya que los votos repetidos en slots posteriores refuerzan el compromiso con slots anteriores.

Cuanto más vote un validador por bloques descendientes, más difícil será abandonar de forma segura la bifurcación anterior.

Tower BFT y los votos de los validadores

Los votos de los validadores son la acción central de Tower BFT.

Un voto comunica qué bloque o bifurcación respalda un validador.

La documentación de Anza sobre Tower BFT describe un voto como una firma del validador formada en torno a la identidad del validador y el hash del bloque por el que se vota.

Los votos no son simples opiniones.

Crean bloqueos que restringen por qué puede votar un validador a continuación.

Esto es importante porque un validador no debería poder votar libremente por una bifurcación y cambiar de inmediato a otra bifurcación conflictiva sin coste.

Si cambiar no tuviera coste, los validadores podrían comportarse de forma oportunista y debilitar la confianza en el libro mayor.

Tower BFT convierte el voto en un compromiso.

Ese compromiso se fortalece a medida que se acumulan más votos sobre la misma bifurcación.

El nombre «Tower» procede de esta estructura de compromisos apilados.

¿Qué es un bloqueo en Tower BFT?

Un bloqueo es un periodo durante el cual un validador tiene restringido votar por una bifurcación conflictiva.

La documentación de Anza sobre Tower BFT indica que un bloqueo se mide en slots e impide que un validador vote por otra bifurcación durante ese periodo.

El objetivo de un bloqueo es hacer que el validador asuma un coste de oportunidad por la bifurcación que respaldó.

Por ejemplo, si un validador vota por un bloque de una bifurcación, no puede votar inmediatamente por una bifurcación competidora que no incluya ese bloque como antecesor.

Si el validador quiere cambiar de dirección, puede tener que esperar a que expiren los bloqueos.

Esto hace que los votos sean más significativos, ya que tienen consecuencias futuras.

Los bloqueos también ayudan a los clientes a estimar el coste de reversión.

Un bloque más antiguo con un respaldo de bloqueos más profundo se vuelve más difícil de revertir porque los validadores tendrían que incumplir o abandonar compromisos mayores.

Esta es una de las principales formas en que Tower BFT convierte los votos a corto plazo en una mayor confianza en la liquidación.

En lenguaje sencillo, los bloqueos hacen que los validadores respalden sus votos con un compromiso ponderado por el tiempo.

Cómo se acumulan los bloqueos

Tower BFT utiliza una pila de votos recientes y sus bloqueos.

Cuando un validador sigue votando por descendientes de un voto anterior, el voto previo queda sujeto a un compromiso más profundo.

Los votos sucesivos pueden aumentar la duración del bloqueo y reforzar los compromisos más antiguos.

Esto crea una estructura de compromisos de voto similar a una torre.

Un voto reciente puede tener un bloqueo corto.

Un voto anterior que cuenta con muchos votos posteriores de bloques descendientes tiene un bloqueo más fuerte.

Esta estructura ayuda a los validadores a pasar gradualmente de un respaldo provisional a un compromiso más sólido.

También ofrece a los clientes una forma de razonar sobre lo costoso que sería revertir un bloque.

Cuanto más profunda sea la torre, más costoso será para los validadores incumplir sus compromisos.

Por eso Tower BFT está estrechamente relacionado con el comportamiento de compromiso y finalidad de Solana.

Tower BFT y la elección de bifurcaciones

Una bifurcación se produce cuando el libro mayor se ramifica en más de una posible cadena de slots.

Las bifurcaciones pueden producirse por retrasos de red, líderes ausentes, bloques competidores o porque los validadores ven los datos en momentos diferentes.

La documentación de Anza sobre la gestión de bifurcaciones explica que el libro mayor puede bifurcarse en los límites de los slots y que los validadores mantienen el estado de cada bifurcación.

Tower BFT ayuda a los validadores a ponderar estas bifurcaciones y, finalmente, seleccionar una.

Los validadores votan por la bifurcación que consideran válida y con mayor peso.

Los votos ponderados por stake ayudan a la red a converger en torno a una bifurcación.

Los bloqueos disuaden a los validadores de cambiar con frecuencia entre bifurcaciones conflictivas.

Esto hace que la elección de bifurcaciones sea más estable con el tiempo.

Una bifurcación con votos ponderados por stake más sólidos y bloqueos más profundos se vuelve más difícil de sustituir.

Para los usuarios, esto forma parte de la razón por la que una transacción se vuelve más segura a medida que recibe un compromiso mayor.

Tower BFT y las raíces

Una raíz es un slot que ha adquirido un compromiso suficientemente profundo para que el validador lo trate como permanente en la gestión local de bifurcaciones.

La documentación de Anza sobre la gestión de bifurcaciones explica que una raíz es un slot que ha alcanzado la profundidad máxima de bloqueo.

Una vez establecida una raíz, el validador puede eliminar las bifurcaciones que no se originen en esa raíz.

Esto mejora el rendimiento porque los validadores no necesitan conservar para siempre todas las bifurcaciones antiguas en memoria activa.

El establecimiento de raíces también ayuda a los validadores a centrarse en el historial de la cadena que ha acumulado suficiente compromiso.

En la práctica, las raíces son importantes porque ayudan a convertir un árbol de bifurcaciones complejo en un historial de cadena manejable.

Una raíz no significa que desaparezca todo riesgo teórico.

Significa que el validador considera que una reversión es suficientemente costosa o poco realista bajo supuestos normales.

El establecimiento de raíces conecta la seguridad del consenso con el rendimiento de los validadores.

Sin poda y establecimiento de raíces, la gestión de bifurcaciones podría resultar costosa e ineficiente con el tiempo.

Tower BFT y la finalidad

La finalidad significa que una transacción o un bloque se considera extremadamente improbable o prácticamente imposible de revertir según los supuestos del protocolo.

Tower BFT respalda la finalidad mediante votos repetidos ponderados por stake y bloqueos crecientes.

A medida que los validadores votan por descendientes, los bloques anteriores quedan cada vez más protegidos por compromisos de bloqueo.

Esto proporciona a usuarios y aplicaciones un nivel de confianza creciente a medida que más slots se construyen sobre una transacción.

La finalidad no es solo una etiqueta de interfaz de usuario.

Es una propiedad de consenso relacionada con los votos de validadores, el peso del stake, la profundidad de bloqueo y la elección de bifurcaciones.

En sistemas de estilo Solana, una transacción puede aparecer como procesada antes de alcanzar el nivel de compromiso más fuerte.

Las aplicaciones deberían elegir los niveles de compromiso según su tolerancia al riesgo.

Una cartera con operaciones de bajo riesgo puede aceptar una confirmación más temprana, mientras que una liquidación de alto valor puede esperar una finalidad más sólida.

Tower BFT es el mecanismo que sustenta este paso gradual desde una inclusión provisional hacia un compromiso más fuerte.

Tower BFT y la supermayoría

El respaldo de una supermayoría es importante en el consenso de estilo BFT.

En sistemas ponderados por stake, una supermayoría suele referirse a una gran fracción del stake activo total que respalda la misma cadena o decisión.

Los validadores de Solana no tienen todos el mismo peso porque el stake delegado afecta al poder de voto.

Esto significa que un validador pequeño y uno grande pueden emitir votos, pero sus votos no tienen el mismo peso de stake.

La página de validadores de Solana explica que el clúster usa votos ponderados por stake para seleccionar un bloque cuando surgen bifurcaciones.

Este diseño ponderado por stake ayuda a alinear la influencia en el consenso con el stake en riesgo.

También implica que la distribución del stake afecta a la descentralización y la resiliencia del consenso.

Si el stake se concentra, menos entidades pueden tener una mayor influencia práctica sobre la elección de bifurcaciones.

Si el stake se distribuye ampliamente entre validadores fiables, el consenso puede ser más resiliente.

Tower BFT depende tanto de las reglas del protocolo como de una participación saludable de los validadores.

Tower BFT y los conceptos de slashing

El slashing es una penalización por la que un validador pierde stake por un comportamiento demostrablemente perjudicial.

La documentación de Anza sobre Tower BFT aborda el castigo de los validadores que incumplen bloqueos al votar por una bifurcación no descendiente durante un bloqueo.

La idea central es que los validadores deberían afrontar consecuencias económicas por votos conflictivos que amenacen la coherencia.

Los conceptos de slashing son importantes porque convierten las reglas de consenso en incentivos económicos.

Si los validadores pudieran votar dos veces sin castigo, el protocolo tendría una protección más débil frente a historiales contradictorios.

En un diseño saludable de Proof of Stake, los validadores reciben recompensas por participar honestamente y son castigados o excluidos por conductas perjudiciales.

Tower BFT utiliza la idea de incumplimiento de bloqueo como una forma detectable de mal comportamiento en la votación.

Esto ayuda a que los compromisos de los validadores sean creíbles.

Normalmente, los usuarios no ven directamente los mecanismos de slashing en una cartera.

Sin embargo, la existencia de reglas aplicables a los validadores forma parte de la razón por la que el consenso ponderado por stake puede proteger la integridad del libro mayor.

Tower BFT y la vitalidad

La vitalidad significa que la red puede seguir produciendo y confirmando bloques.

Un sistema de consenso seguro pero que nunca avanza no sería útil para pagos, trading, DeFi o aplicaciones.

Tower BFT trata de equilibrar la seguridad con un avance rápido utilizando la temporización de Proof of History y los bloqueos de validadores.

El artículo de Solana sobre Tower BFT señala que Tower BFT prioriza la vitalidad frente a la coherencia en su diseño personalizado de estilo PBFT.

Esto no significa que se ignore la coherencia.

Significa que el diseño toma decisiones destinadas a mantener la red en funcionamiento bajo condiciones prácticas.

Los usuarios de criptomonedas se preocupan por la vitalidad porque una red activa puede procesar transferencias, swaps, órdenes, actividad de staking e interacciones con aplicaciones.

Los validadores se preocupan por la vitalidad porque un consenso bloqueado puede afectar a las recompensas, la reputación y la fiabilidad de la red.

Los desarrolladores se preocupan por la vitalidad porque las aplicaciones necesitan un procesamiento de transacciones predecible.

Tower BFT utiliza el reloj PoH y las reglas de bloqueo para respaldar el avance, mientras sigue haciendo costosos los historiales conflictivos.

Tower BFT frente a PBFT

PBFT significa Practical Byzantine Fault Tolerance, o tolerancia práctica a fallos bizantinos.

PBFT es un enfoque de consenso clásico que utiliza comunicación estructurada entre réplicas para acordar solicitudes pese a los fallos bizantinos.

Tower BFT se inspira en PBFT, pero adapta la idea a la arquitectura de Proof of History de Solana.

El artículo de Solana sobre Tower BFT indica que Solana implementa una derivación de PBFT, con la diferencia fundamental de que Proof of History proporciona una fuente global de tiempo antes del consenso.

Esto significa que Tower BFT no necesita gestionar los tiempos de espera de la misma forma que las rondas de mensajes tradicionales de estilo PBFT.

Proof of History ayuda a codificar el tiempo en el propio libro mayor.

Esto puede reducir la sobrecarga de mensajería y la latencia.

La contrapartida es que Tower BFT queda estrechamente vinculado a la arquitectura basada en PoH de Solana.

No es un módulo de consenso genérico y listo para usar que funcione de la misma forma en todas las blockchains.

Fue diseñado en torno a la arquitectura de alto rendimiento de Solana.

Tower BFT frente a Proof of Stake

Tower BFT no es lo mismo que Proof of Stake.

Proof of Stake describe cómo la influencia de los validadores y la seguridad económica están vinculadas a los tokens en staking.

Tower BFT describe cómo los validadores utilizan votos ponderados por stake, bloqueos y elección de bifurcaciones para alcanzar el consenso.

En Solana, estos conceptos funcionan conjuntamente.

Los validadores participan en el consenso y el stake que se les delega afecta al peso de sus votos.

Los stakers delegan stake a nodos validadores, y estos validadores votan sobre las bifurcaciones del libro mayor.

Proof of Stake proporciona el peso económico.

Tower BFT proporciona la lógica de votación y compromiso.

Proof of History proporciona la estructura temporal.

Comprender el consenso de Solana requiere ver conjuntamente las tres piezas, en vez de tratar una sola expresión como si describiera todo el sistema.

Tower BFT frente a Proof of History

Tower BFT y Proof of History se confunden a menudo porque están estrechamente vinculados.

Proof of History es un mecanismo verificable de retraso y ordenación.

Tower BFT es el mecanismo de votación y consenso que utiliza la temporización de Proof of History.

Proof of History ayuda a los validadores a acordar el paso del tiempo y el orden de los eventos.

Tower BFT ayuda a los validadores a acordar qué bifurcación debe seguirse.

Una comparación sencilla es que Proof of History es el reloj, mientras que Tower BFT es el proceso de votación que utiliza ese reloj.

El whitepaper de Solana indica que PoH puede utilizarse junto con algoritmos de consenso como Proof of Stake para reducir la sobrecarga de mensajería en una máquina de estados replicada tolerante a fallos bizantinos.

Tower BFT es un ejemplo concreto de esta idea dentro del diseño original de Solana.

Decir que Proof of History es todo el mecanismo de consenso es incompleto.

Decir que Tower BFT es independiente de Proof of History también es incompleto.

Tower BFT y los validadores

Los validadores son los participantes de la red que procesan transacciones, reproducen el libro mayor y votan en el consenso.

La documentación de validadores de Solana indica que los validadores constituyen la columna vertebral de la red al procesar transacciones y participar en el consenso.

Con Tower BFT, los validadores evalúan bloques, siguen bifurcaciones y envían votos.

Sus votos se ponderan según el stake delegado.

Un validador que vota correctamente de forma constante y permanece conectado contribuye a la fiabilidad de la red.

Un validador desconectado o con mala conectividad puede perder votos y reducir su eficacia.

Un validador que vota incorrectamente o incumple las expectativas de bloqueo puede amenazar la seguridad del consenso.

Por eso son importantes el rendimiento de los validadores, la conectividad, la calidad del software y la disciplina operativa.

Los usuarios que hacen staking de SOL participan indirectamente en el consenso al delegar en validadores.

Elegir cuidadosamente a los validadores puede favorecer la descentralización y la salud de la red.

Tower BFT y las transacciones de los usuarios

La mayoría de los usuarios no interactúa directamente con Tower BFT.

Un usuario envía una transacción desde una cartera o aplicación, y los validadores la procesan a través de la red.

Si la transacción se incluye en un bloque, los validadores pueden votar por la bifurcación de ese bloque.

A medida que se acumulan los votos y se profundizan los bloqueos, la transacción adquiere un compromiso más fuerte.

Por eso las carteras y aplicaciones pueden mostrar distintos estados de confirmación.

Una transacción puede aparecer rápidamente, pero una finalidad más sólida procede de un progreso adicional del consenso.

Para pequeñas transferencias cotidianas, una confirmación temprana puede ser suficiente en algunos casos de uso.

Para liquidaciones de alto valor, las aplicaciones pueden esperar un compromiso mayor.

Tower BFT es la razón por la que esos estados de compromiso tienen significado a nivel de protocolo y no son solo etiquetas de interfaz.

Los usuarios se benefician cuando el consenso funciona bien porque las transacciones se vuelven más fiables y más fáciles de confiar.

Tower BFT y DeFi

Las aplicaciones DeFi dependen de una liquidación rápida y fiable.

Un swap, una acción de préstamo, una liquidación o una actualización de liquidez solo es útil si la red puede acordar su orden y resultado.

Tower BFT ayuda a los validadores de Solana a converger en torno a un historial compartido del libro mayor.

Esto afecta a DeFi porque el orden de las transacciones puede influir en los precios, las garantías, las liquidaciones y el arbitraje.

Un consenso rápido puede respaldar experiencias de usuario DeFi más ágiles.

Sin embargo, los usuarios de DeFi deben seguir entendiendo que el procesamiento rápido no elimina el riesgo de contratos inteligentes, el deslizamiento, el riesgo de oráculo, el riesgo de liquidez ni el riesgo de que una transacción falle.

Tower BFT ayuda a la cadena a acordar el estado, pero no garantiza que cada operación DeFi sea rentable o segura.

Las aplicaciones deben seguir gestionando niveles de confirmación, reintentos, movimientos de mercado y controles de riesgo.

Para los desarrolladores, los supuestos de consenso forman parte del diseño de la aplicación.

Para los traders, la velocidad del consenso es solo una parte de la calidad de ejecución.

Tower BFT y las transacciones NFT

Las acciones de acuñación, compra, venta, transferencia y listado de NFT dependen del orden de las transacciones y de la liquidación.

Tower BFT ayuda a determinar el historial del libro mayor que registra estas acciones.

Durante acuñaciones populares de NFT, muchos usuarios pueden competir para enviar transacciones rápidamente.

El consenso debe seguir decidiendo qué transacciones se incluyen y en qué orden.

Una ruta de consenso rápida puede mejorar la experiencia de usuario, pero no garantiza que todas las transacciones se completen correctamente.

Una transacción de acuñación de NFT puede fallar si se agota la oferta, las comisiones son insuficientes, las instrucciones son incorrectas o el programa rechaza la acción.

Tower BFT ayuda a los validadores a acordar el estado final después de que la red procese las transacciones.

No determina si una colección NFT tiene valor o es legítima.

Los usuarios deberían verificar las fuentes oficiales de la colección, las direcciones de los contratos y el contexto del marketplace.

La seguridad del consenso respalda la liquidación, pero no sustituye a la debida diligencia.

Tower BFT y el trading

Los traders se interesan por Tower BFT porque la velocidad de liquidación y la finalidad afectan a la ejecución en el mercado.

Una confirmación rápida puede ayudar a los traders a mover activos, interactuar con protocolos DeFi y responder a cambios de precio.

Sin embargo, los traders no deberían tratar el consenso rápido como garantía de una ejecución sin riesgos.

Los resultados del trading siguen dependiendo de la liquidez, el deslizamiento, las comisiones, el enrutamiento de órdenes, la volatilidad del mercado y el diseño de la aplicación.

Una transacción puede procesarse rápidamente y aun así generar una mala operación si el mercado se mueve antes de la ejecución.

Una transacción puede confirmarse y aun así fallar porque no se cumplió una condición de un contrato inteligente.

Tower BFT respalda la capacidad de la red para acordar lo ocurrido.

No protege a los traders frente a una estrategia deficiente ni al riesgo de mercado.

Para operar con seriedad, los usuarios deberían combinar la comprensión del consenso con simulación de transacciones, límites de deslizamiento y gestión del riesgo.

El consenso es infraestructura de liquidación, no una señal de trading.

Tower BFT y los niveles de compromiso

Los niveles de compromiso son formas orientadas al usuario de describir el grado de confirmación de una transacción o bloque.

Aunque las interfaces pueden emplear etiquetas diferentes, la idea subyacente es que un mayor compromiso de los validadores implica mayor confianza.

Tower BFT contribuye al compromiso mediante votos, bloqueos y raíces.

Una transacción procesada recientemente puede tener menos compromiso que una transacción que cuenta con muchos votos posteriores.

Una transacción finalizada tiene una protección más fuerte frente a la reversión que una transacción observada recientemente.

Los desarrolladores de aplicaciones deberían elegir los niveles de compromiso en función del valor y el riesgo de la acción.

Una acción en un juego puede tolerar una confirmación más rápida, pero más débil.

Una gran liquidación financiera puede requerir una finalidad más sólida.

Los usuarios deben entender que no todas las confirmaciones son iguales.

Tower BFT es la lógica de consenso que da significado a un compromiso más profundo.

Tower BFT y el rendimiento de la red

El diseño de Solana busca un alto rendimiento, y Tower BFT es una parte de esa arquitectura.

Al utilizar Proof of History como fuente temporal, Tower BFT puede reducir parte de la sobrecarga de mensajes presente en diseños antiguos de estilo BFT.

Una menor sobrecarga puede ayudar a una red a alcanzar decisiones más rápido cuando las condiciones son saludables.

Sin embargo, el rendimiento no depende únicamente del consenso.

También depende de la propagación de bloques, la ejecución de transacciones, el hardware de los validadores, las redes, el almacenamiento, los mercados de comisiones y la demanda de las aplicaciones.

Tower BFT funciona junto con otros componentes de Solana que gestionan la producción de bloques, la propagación de datos, la ejecución y el almacenamiento del libro mayor.

Un cuello de botella en una parte del sistema puede seguir afectando a la experiencia de usuario.

Por eso el rendimiento de una blockchain debe entenderse como una cuestión de pila tecnológica completa.

Tower BFT ayuda al consenso a avanzar rápido, pero no es la única razón por la que la red puede procesar transacciones.

Es un componente esencial dentro de una arquitectura más amplia de alto rendimiento.

Tower BFT y el coste de reversión

El coste de reversión es el coste o la dificultad de revertir un bloque aceptado previamente.

La documentación de Anza sobre Tower BFT indica que el coste de reversión debe poder calcularse y debería aumentar de forma superlineal para los votos más antiguos.

Este concepto es importante porque los usuarios y las aplicaciones necesitan una confianza medible en la liquidación.

Un bloque que acaba de producirse puede ser más fácil de sustituir que un bloque enterrado bajo muchos votos bloqueados.

Tower BFT fortalece los compromisos antiguos mediante bloqueos acumulados.

Esto significa que revertir un historial más antiguo requeriría que más validadores incumplieran compromisos más fuertes o esperaran bloqueos más prolongados.

En un sistema Proof of Stake, las consecuencias económicas pueden hacer que dicho comportamiento sea costoso.

El coste de reversión no equivale a un simple recuento de bloques.

Depende de los votos de los validadores, el peso del stake, la profundidad del bloqueo y las reglas del protocolo.

Comprender el coste de reversión ayuda a explicar por qué la finalidad aumenta con el tiempo.

Tower BFT y los supuestos de seguridad

Tower BFT depende de varios supuestos de seguridad.

Supone que suficientes validadores ponderados por stake siguen el protocolo de forma honesta.

Supone que los validadores pueden comunicarse suficientemente bien para que la red siga avanzando.

Supone que las infracciones de bloqueo pueden detectarse y castigarse según el diseño del protocolo y de gobernanza.

Supone que la temporización de Proof of History es verificable y útil para coordinar el comportamiento de los validadores.

También depende de que el software cliente se implemente correctamente.

Ningún mecanismo de consenso es mágico.

Cada diseño establece contrapartidas entre velocidad, seguridad, vitalidad, descentralización, complejidad y riesgo de implementación.

Tower BFT se diseñó para los objetivos de rendimiento originales de Solana.

Sus puntos fuertes y débiles deben juzgarse en el contexto de la arquitectura de Solana, en lugar de como un sistema BFT genérico.

Tower BFT y Alpenglow

Alpenglow es un cambio importante propuesto para el diseño de consenso de Solana que resulta relevante al hablar hoy de Tower BFT.

La propuesta SIMD-0326 Alpenglow oficial indica que modifica el protocolo de consenso central, desde el diseño actual basado en Proof of History y TowerBFT hacia Alpenglow.

La misma propuesta afirma que Alpenglow busca una mayor resiliencia y un mejor rendimiento.

También indica que el protocolo de consenso TowerBFT actual tiene un tiempo de finalidad de 12.8 segundos y no cuenta con una prueba de seguridad, algo que la propuesta describe como preocupante.

Esto no significa que los usuarios deban interpretar Tower BFT como irrelevante.

Tower BFT sigue siendo importante porque explica la arquitectura de consenso original de Solana y el diseño que Alpenglow pretende sustituir.

Comprender Tower BFT ayuda a los usuarios a entender por qué Alpenglow es importante.

También ayuda a desarrolladores, validadores e investigadores a comparar el antiguo modelo de votación con bloqueos con diseños más recientes basados en voto directo y certificados.

Para mantener la precisión de un glosario, Tower BFT debe describirse teniendo en cuenta que la hoja de ruta de consenso de Solana está evolucionando.

Los usuarios siempre deberían consultar la documentación actual de Solana y Anza sobre el estado activo en mainnet de cualquier actualización de consenso.

Ventajas de Tower BFT

La primera ventaja de Tower BFT es que utiliza Proof of History como referencia temporal compartida.

Esto puede reducir la sobrecarga de comunicación en comparación con diseños BFT que deben coordinar tiempos de espera mediante más intercambios de mensajes.

La segunda ventaja es que los bloqueos hacen que los votos de los validadores sean significativos.

Un validador que vota por una bifurcación asume un compromiso basado en el tiempo.

La tercera ventaja es que los bloqueos acumulados proporcionan una forma de razonar sobre el coste de reversión.

Los bloques más antiguos con un compromiso más profundo se vuelven más difíciles de revertir.

La cuarta ventaja es que Tower BFT encaja en la arquitectura de alto rendimiento de Solana.

Fue diseñado para respaldar una confirmación rápida de bloques y la coordinación de validadores.

La quinta ventaja es que la votación ponderada por stake conecta la influencia en el consenso con el stake delegado.

Esto otorga a la capa económica un papel directo en la elección de bifurcaciones.

Limitaciones de Tower BFT

La primera limitación de Tower BFT es la complejidad.

Proof of History, los slots, los votos, los bloqueos, las raíces y la elección de bifurcaciones pueden ser difíciles de entender para usuarios y desarrolladores.

La segunda limitación es que la finalidad no es instantánea.

El compromiso se fortalece con el tiempo a medida que se acumulan votos y bloqueos.

La tercera limitación es que el diseño está estrechamente vinculado a la arquitectura de Proof of History de Solana.

Esto lo hace menos general que algunos protocolos de consenso diseñados en torno a supuestos diferentes.

La cuarta limitación es que la calidad del consenso depende del rendimiento de los validadores y de la distribución del stake.

Una conectividad deficiente, el tiempo de inactividad o el stake concentrado pueden afectar al comportamiento de la red.

La quinta limitación es que la propia propuesta Alpenglow de Solana identifica preocupaciones sobre rendimiento y pruebas de seguridad en el diseño heredado de TowerBFT.

Estas limitaciones explican por qué la investigación sobre consenso y las actualizaciones de protocolos siguen siendo temas activos en el ecosistema de Solana.

Malentendidos habituales sobre Tower BFT

El primer malentendido consiste en pensar que Tower BFT y Proof of History son lo mismo.

Proof of History es el mecanismo de temporización y ordenación, mientras que Tower BFT es el mecanismo de consenso de votos y bloqueos.

El segundo malentendido es pensar que Tower BFT equivale a Proof of Stake.

Proof of Stake proporciona influencia económica ponderada por stake, mientras que Tower BFT organiza votos y bloqueos.

El tercer malentendido es pensar que un procesamiento rápido siempre implica liquidación final.

Una transacción puede observarse pronto mientras que una finalidad más fuerte se desarrolla posteriormente.

El cuarto malentendido es pensar que los validadores pueden cambiar libremente de bifurcación.

Los bloqueos de Tower BFT restringen a los validadores de votar por bifurcaciones conflictivas durante los periodos de compromiso.

El quinto malentendido es pensar que los usuarios deben comprender todos los detalles de Tower BFT para utilizar Solana.

La mayoría de los usuarios solo necesita entender que un compromiso más fuerte implica mayor confianza.

Buenas prácticas para usuarios

Utiliza carteras y aplicaciones de confianza que muestren claramente el estado de las transacciones.

Espera a un compromiso más fuerte al mover activos de alto valor.

No supongas que mostrar una transacción rápidamente significa que se ha alcanzado la mayor finalidad posible.

Cuando sea necesario, comprueba el estado de la transacción mediante exploradores fiables o interfaces de aplicaciones.

Entiende que la congestión de red, el rendimiento de los validadores y los errores de las aplicaciones aún pueden afectar a la experiencia de usuario.

Evita enviar transacciones repetidas sin comprobar si se procesó la primera.

Utiliza controles de deslizamiento al interactuar con protocolos DeFi.

Mantén suficiente SOL para las comisiones de transacción al usar aplicaciones basadas en Solana.

No trates la velocidad del consenso como una garantía de beneficio en trading.

Utiliza la comprensión de la finalidad como parte de una gestión del riesgo cripto más amplia.

Buenas prácticas para desarrolladores

Elige niveles de compromiso en función del riesgo y valor de la acción de la aplicación.

No trates todas las transacciones observadas como si tuvieran la misma finalidad.

Diseña interfaces de usuario que expliquen claramente los estados pendiente, confirmado y finalizado.

Gestiona cuidadosamente los reintentos de transacción para evitar acciones de usuario duplicadas o conflictivas.

Supervisa el comportamiento relacionado con bifurcaciones y la coherencia de RPC al desarrollar aplicaciones de alto valor.

Utiliza proveedores de infraestructura fiables y múltiples fuentes de datos cuando sea adecuado.

Diseña aplicaciones DeFi teniendo en cuenta el deslizamiento, los cambios de estado y los tiempos de confirmación.

Prueba el comportamiento de la aplicación en condiciones de congestión y confirmación retrasada.

Mantente al día de las actualizaciones de consenso de Solana, incluidos los cambios relacionados con Alpenglow.

Los supuestos de consenso deben formar parte de la ingeniería de aplicaciones, no ser una consideración tardía.

Preguntas frecuentes

¿Qué es Tower BFT en términos sencillos?

Tower BFT es el sistema original de votación de validadores de Solana de estilo BFT que utiliza la temporización de Proof of History para ayudar a los validadores a acordar la cadena correcta.

¿Tower BFT es lo mismo que Proof of History?

No. Proof of History proporciona una estructura verificable de temporización y ordenación, mientras que Tower BFT utiliza esa estructura para los votos y bloqueos de los validadores.

¿Tower BFT es lo mismo que Proof of Stake?

No. Proof of Stake proporciona la capa económica ponderada por stake, mientras que Tower BFT proporciona la lógica de votación y elección de bifurcaciones.

¿Por qué se llama Tower BFT?

Se llama Tower BFT porque los votos de los validadores se acumulan con bloqueos crecientes, creando una estructura de compromiso similar a una torre.

¿Qué es un bloqueo en Tower BFT?

Un bloqueo es un periodo basado en slots durante el cual un validador no puede votar por una bifurcación conflictiva sin incumplir su compromiso anterior.

¿Qué es un slot en Tower BFT?

Un slot es la unidad de tiempo de Solana para la programación de líderes, la producción de bloques, la votación y la medición de bloqueos.

¿Qué papel desempeñan los validadores en Tower BFT?

Los validadores reproducen el libro mayor, evalúan bloques, votan por bifurcaciones y ayudan al clúster a elegir la cadena válida con mayor peso mediante votos ponderados por stake.

¿Qué hace Tower BFT durante las bifurcaciones?

Tower BFT ayuda a los validadores a ponderar bifurcaciones competidoras y comprometerse con una bifurcación mediante votos ponderados por stake y bloqueos.

¿Tower BFT proporciona finalidad instantánea?

No. La finalidad se fortalece con el tiempo a medida que se acumulan los votos y se profundizan los bloqueos.

¿Por qué Proof of History ayuda a Tower BFT?

Proof of History proporciona a Tower BFT una referencia temporal compartida que ayuda a aplicar tiempos de espera y bloqueos con menor sobrecarga de mensajería.

¿Qué es el coste de reversión en Tower BFT?

El coste de reversión es la dificultad o el coste económico de revertir un bloque después de que los validadores hayan generado compromisos de bloqueo sobre él.

¿Los usuarios pueden interactuar directamente con Tower BFT?

No. La mayoría de los usuarios interactúa mediante carteras y aplicaciones, mientras que los validadores gestionan en segundo plano la votación de Tower BFT.

¿Por qué deberían preocuparse los usuarios de DeFi por Tower BFT?

Los usuarios de DeFi deberían preocuparse porque el consenso afecta al orden de las transacciones, la fuerza de la confirmación, la confianza en la liquidación y la fiabilidad de las aplicaciones.

¿Cuál es la relación entre Alpenglow y Tower BFT?

Alpenglow es un rediseño de consenso propuesto para Solana que sustituiría el protocolo actual basado en Proof of History y TowerBFT por una arquitectura más reciente.

¿Sigue siendo importante entender Tower BFT?

Sí. Tower BFT es importante porque explica la arquitectura de consenso original de Solana y la referencia con la que se comparan las nuevas propuestas de consenso.

Conclusión

Tower BFT es el mecanismo de votación de tolerancia a fallos bizantinos de Solana optimizado para Proof of History.

Utiliza slots, votos de validadores, bloqueos, raíces y elección de bifurcaciones ponderada por stake para ayudar a la red a converger en un historial compartido del libro mayor.

Proof of History proporciona la estructura temporal compartida, Proof of Stake proporciona el peso económico de voto y Tower BFT proporciona la lógica de consenso basada en votos y bloqueos.

La idea principal de Tower BFT es que los votos de los validadores deben crear compromisos basados en el tiempo que se vuelven más fuertes a medida que se añaden más votos descendientes.

Este compromiso acumulado hace que los bloques antiguos sean más difíciles de revertir y aporta a los usuarios una mayor confianza a medida que las transacciones adquieren un compromiso más fuerte.

Tower BFT es importante para usuarios, desarrolladores, validadores, traders, protocolos DeFi y aplicaciones NFT porque el consenso afecta a la liquidación, la ordenación, la finalidad y la fiabilidad.

Sus puntos fuertes incluyen coordinación rápida, temporización basada en PoH, votación ponderada por stake y un coste de reversión calculable.

Sus limitaciones incluyen complejidad, finalidad no instantánea, dependencia del comportamiento de los validadores y las preocupaciones identificadas por nuevas propuestas de consenso como Alpenglow.

A medida que evoluciona la hoja de ruta de consenso de Solana, Tower BFT sigue siendo un término esencial para comprender cómo Solana combinó originalmente Proof of History con la votación de validadores de estilo BFT.

En un glosario cripto, Tower BFT debe entenderse como el mecanismo de consenso de Solana que convierte los votos de validadores en compromisos acumulados y basados en el tiempo para elegir bifurcaciones y reforzar la finalidad.