Tower BFT

O que é Tower BFT?

Tower BFT é o mecanismo de votação de consenso de Tolerância a Falhas Bizantinas da Solana otimizado para Proof of History.

No mercado cripto, Tower BFT pode ser entendido como o sistema que ajuda os validadores da Solana a votar no fork correto, criar compromisso em torno dos blocos e tornar reversões cada vez mais custosas ao longo do tempo.

A documentação oficial do Anza Tower BFT explica que a Solana gera uma fonte de tempo por meio do Proof of History e usa slots como unidade de tempo.

Cada slot pode ter um líder designado que pode produzir um bloco.

Em seguida, os validadores votam no fork que acreditam que deve se tornar a cadeia válida mais pesada.

Tower BFT não é o mesmo que Proof of History.

O Proof of History fornece um relógio criptográfico e uma estrutura de ordenação, enquanto o Tower BFT usa essa estrutura temporal para organizar votos de validadores, lockouts, escolha de fork e compromisso.

O whitepaper da Solana descreve o Proof of History como uma prova para verificar a ordem e a passagem do tempo entre eventos.

O Tower BFT se baseia nessa ideia ao permitir que os validadores votem com lockouts baseados em tempo, medidos em slots.

Em um glossário cripto, Tower BFT deve ser entendido como a camada original de consenso em estilo BFT da Solana, que usa a temporização do Proof of History para reduzir a sobrecarga de coordenação e dar suporte à confirmação rápida de blocos.

Por que o Tower BFT é importante

O Tower BFT é importante porque o consenso é o processo que permite a uma blockchain concordar com um único histórico compartilhado.

Sem consenso, os validadores poderiam discordar sobre quais transações ocorreram, quais saldos são válidos e em quais blocos se deve confiar.

A Solana foi projetada para alta capacidade de processamento e baixa latência. Portanto, seu design de consenso precisava evitar esperas desnecessárias e troca excessiva de mensagens.

O Tower BFT contribui para esse objetivo ao usar o Proof of History como referência temporal compartilhada antes que o consenso completo seja alcançado.

O artigo da Solana sobre Tower BFT descreve o Tower BFT como uma implementação personalizada de PBFT que utiliza o Proof of History como relógio antes do consenso para reduzir a sobrecarga de mensagens e a latência.

Isso é importante para os usuários porque o consenso afeta a confirmação de transações, as expectativas de finalidade, o comportamento dos validadores e a confiabilidade da rede.

Isso é importante para os validadores porque as decisões de voto podem criar lockouts que limitam escolhas de voto futuras.

Isso é importante para desenvolvedores porque a confiabilidade dos aplicativos depende da compreensão de como os estados confirmados, finalizados e relacionados a forks se comportam.

Isso é importante para traders porque a finalidade rápida e a liquidação estável podem afetar depósitos e saques em exchanges, a atividade em DeFi e o risco de arbitragem.

Portanto, o Tower BFT não é apenas um detalhe dos validadores, mas também parte da infraestrutura de mercado mais ampla por trás da atividade cripto baseada na Solana.

O que significa BFT?

BFT significa Byzantine Fault Tolerance, ou Tolerância a Falhas Bizantinas.

Uma falha bizantina é uma falha em que um participante pode se comportar de forma imprevisível, incorreta ou maliciosa.

Em sistemas de blockchain, isso pode significar que um validador está offline, lento, é desonesto, vota duas vezes, censura ou produz mensagens conflitantes.

Um sistema de consenso BFT busca manter a rede segura mesmo quando alguns participantes apresentam falhas.

Segurança significa que participantes honestos não devem finalizar históricos conflitantes.

Vivacidade significa que a rede deve continuar avançando quando participantes honestos suficientes conseguem se comunicar.

O Tower BFT pertence à família de designs de consenso em estilo BFT porque se concentra em votação de validadores, escolha de fork, lockouts e compromisso diante de possíveis falhas.

Não se trata de uma simples votação por maioria baseada na quantidade de validadores.

A Solana usa votação ponderada por stake, o que significa que validadores com mais stake delegado têm maior peso de voto.

A página de validadores da Solana explica que os validadores reproduzem o ledger, enviam votos para contas de voto e que o cluster usa votos ponderados por stake para selecionar um bloco quando surgem forks.

Tower BFT e Proof of History

O Proof of History é a base temporal que torna o Tower BFT diferente de muitos sistemas BFT tradicionais.

Protocolos BFT tradicionais geralmente exigem que os validadores troquem mais mensagens para concordar com timeouts e avançar por visualizações ou rodadas.

O design da Solana usa uma sequência verificável de computação para criar um registro compartilhado de tempo e ordenação.

O whitepaper da Solana afirma que o Proof of History pode codificar a passagem do tempo sem confiança em um ledger somente de anexação.

Isso dá ao Tower BFT uma forma de medir os lockouts de voto em slots, em vez de depender apenas de relógios locais e negociações repetidas.

Em termos simples, o Proof of History dá à rede uma linha do tempo compartilhada, e o Tower BFT usa essa linha do tempo para organizar os votos de consenso.

Por isso, o Tower BFT é frequentemente descrito como BFT otimizado para PoH.

A estrutura do PoH semelhante a um relógio ajuda os validadores a saber quando determinados compromissos de voto expiram.

Ela também ajuda o protocolo a reduzir a sobrecarga de comunicação, pois os timeouts podem ser derivados da estrutura temporal do ledger.

Para os usuários, o resultado é um modelo de consenso projetado para oferecer confirmação mais rápida do que designs de consenso antigos, com grande troca de mensagens.

Tower BFT e slots

Um slot é a unidade de tempo da Solana para produção de blocos e votação de validadores.

No Tower BFT, lockouts e compromissos de voto são medidos em slots.

A documentação do Anza Tower BFT afirma que cada slot tem um líder designado que pode produzir um bloco.

Um líder pode não produzir um bloco, portanto alguns slots podem não conter blocos.

Os validadores observam os blocos e votam no fork que acreditam que deve se tornar o fork válido mais pesado.

Como os slots criam uma estrutura previsível, os validadores podem se coordenar em torno de uma linha do tempo compartilhada.

Um bloco está associado a um slot, e os votos podem se referir a blocos em um fork.

Isso permite que o Tower BFT conecte tempo, rotação de líderes, escolha de fork e compromisso dos validadores em um único processo.

A temporização baseada em slots também é importante para a finalidade, porque votos repetidos em slots posteriores aprofundam o compromisso com slots anteriores.

Quanto mais um validador vota em blocos descendentes, mais difícil se torna abandonar com segurança o fork anterior.

Tower BFT e votos dos validadores

Os votos dos validadores são a ação central do Tower BFT.

Um voto comunica qual bloco ou fork um validador apoia.

A documentação do Anza Tower BFT descreve um voto como assinado pelo validador e formado em torno da identidade do validador e do hash do bloco no qual se está votando.

Os votos não são apenas opiniões.

Eles criam lockouts que restringem em que um validador pode votar em seguida.

Isso é importante porque um validador não deve poder votar livremente em um fork e, logo depois, mudar instantaneamente para um fork conflitante sem custo.

Se a mudança não tivesse custo, os validadores poderiam se comportar de forma oportunista e enfraquecer a confiança no ledger.

O Tower BFT transforma o voto em um compromisso.

Esse compromisso se fortalece à medida que mais votos se acumulam no mesmo fork.

O nome “Tower” vem dessa estrutura de compromissos empilhados.

O que é um lockout no Tower BFT?

Um lockout é um período durante o qual um validador fica impedido de votar em um fork conflitante.

A documentação do Anza Tower BFT informa que um lockout é medido em slots e impede um validador de votar em outro fork durante esse período.

O objetivo de um lockout é fazer o validador assumir um custo de oportunidade de compromisso com o fork que apoiou.

Por exemplo, se um validador votar em um bloco de um fork, não poderá votar imediatamente em um fork concorrente que não inclua esse bloco como ancestral.

Se o validador quiser mudar de direção, talvez precise esperar os lockouts expirarem.

Isso torna os votos mais relevantes porque eles têm consequências futuras.

Os lockouts também ajudam os clientes a estimar o custo de reversão.

Um bloco mais antigo com suporte de lockout mais profundo torna-se mais difícil de reverter, pois os validadores precisariam violar ou abandonar compromissos maiores.

Essa é uma das principais formas pelas quais o Tower BFT ajuda a transformar votos de curto prazo em maior confiança na liquidação.

Em linguagem simples, lockouts fazem os validadores colocar um compromisso ponderado pelo tempo por trás de seus votos.

Como os lockouts se acumulam

O Tower BFT usa uma pilha de votos recentes e seus lockouts.

Quando um validador continua votando em descendentes de um voto anterior, o voto anterior se torna mais profundamente comprometido.

Votos sucessivos podem aumentar a duração do lockout e fortalecer compromissos mais antigos.

Isso cria uma estrutura de compromissos de voto semelhante a uma torre.

Um voto recente pode ter um lockout curto.

Um voto mais antigo que possui muitos votos descendentes posteriores tem um lockout mais forte.

Essa estrutura ajuda os validadores a passar gradualmente de um suporte provisório para um compromisso mais forte.

Ela também dá aos clientes uma forma de avaliar o quão custoso seria reverter um bloco.

Quanto mais profunda a torre, mais custoso se torna para os validadores violar seus compromissos.

Por isso, o Tower BFT está estreitamente ligado ao comportamento de compromisso e finalidade da Solana.

Tower BFT e escolha de fork

Um fork ocorre quando o ledger se ramifica em mais de uma possível cadeia de slots.

Forks podem ocorrer devido a atrasos de rede, líderes ausentes, blocos concorrentes ou validadores que veem dados em momentos diferentes.

A documentação do Anza sobre gerenciamento de forks explica que o ledger pode sofrer forks nos limites de slots e que os validadores mantêm estado para cada fork.

O Tower BFT ajuda os validadores a avaliar esses forks e, por fim, selecionar um deles.

Os validadores votam no fork que acreditam ser o mais pesado e válido.

Votos ponderados por stake ajudam a rede a convergir para um fork.

Os lockouts desestimulam os validadores a alternar frequentemente entre forks conflitantes.

Isso torna a escolha de fork mais estável ao longo do tempo.

Um fork com votos ponderados por stake mais fortes e lockouts mais profundos torna-se mais difícil de substituir.

Para os usuários, isso é parte do motivo pelo qual uma transação se torna mais segura à medida que recebe um compromisso mais forte.

Tower BFT e roots

Uma root é um slot que se tornou suficientemente comprometido em profundidade para que o validador o trate como permanente no gerenciamento local de forks.

A documentação do Anza sobre gerenciamento de forks explica que uma root é um slot que atingiu a profundidade máxima de lockout.

Quando uma root é estabelecida, o validador pode eliminar forks que não se originam dessa root.

Isso melhora o desempenho porque os validadores não precisam manter todos os forks antigos na memória ativa para sempre.

O estabelecimento de roots também ajuda os validadores a se concentrar no histórico da cadeia que acumulou compromisso suficiente.

Em termos práticos, as roots são importantes porque ajudam a transformar uma árvore de forks complexa em um histórico de cadeia administrável.

Uma root não significa que todo risco teórico desaparece.

Significa que o validador considera a reversão suficientemente custosa ou irrealista sob condições normais.

O estabelecimento de roots conecta a segurança do consenso ao desempenho do validador.

Sem eliminação de forks e roots, o gerenciamento de forks poderia se tornar caro e ineficiente ao longo do tempo.

Tower BFT e finalidade

Finalidade significa que uma transação ou bloco é considerado extremamente improvável ou praticamente impossível de reverter sob as premissas do protocolo.

O Tower BFT oferece suporte à finalidade por meio de votos repetidos ponderados por stake e lockouts crescentes.

À medida que os validadores votam em descendentes, blocos anteriores ficam cada vez mais protegidos por compromissos de lockout.

Isso proporciona aos usuários e aplicativos um nível crescente de confiança à medida que mais slots são construídos sobre uma transação.

A finalidade não é apenas um rótulo de interface.

É uma propriedade de consenso ligada aos votos dos validadores, ao peso do stake, à profundidade do lockout e à escolha de fork.

Em sistemas no estilo Solana, uma transação pode parecer processada antes de atingir o nível de compromisso mais forte.

Os aplicativos devem escolher níveis de compromisso com base na tolerância ao risco.

Uma carteira de baixo risco pode aceitar uma confirmação mais antecipada, enquanto uma liquidação de alto valor pode aguardar uma finalidade mais forte.

O Tower BFT é o mecanismo por trás desse movimento gradual da inclusão provisória para um compromisso mais forte.

Tower BFT e supermaioria

O suporte de supermaioria é importante no consenso em estilo BFT.

Em sistemas ponderados por stake, supermaioria geralmente se refere a uma grande fração do stake ativo total apoiando a mesma cadeia ou decisão.

Os validadores da Solana não têm todos o mesmo peso, pois o stake delegado afeta o poder de voto.

Isso significa que um validador pequeno e um validador grande podem ambos votar, mas seus votos não têm o mesmo peso de stake.

A página de validadores da Solana explica que o cluster usa votos ponderados por stake para selecionar um bloco quando surgem forks.

Esse design ponderado por stake ajuda a alinhar a influência no consenso ao stake em risco.

Também significa que a distribuição de stake afeta a descentralização e a resiliência do consenso.

Se o stake estiver concentrado, menos entidades poderão ter maior influência prática sobre a escolha de fork.

Se o stake estiver amplamente distribuído entre validadores confiáveis, o consenso poderá ser mais resiliente.

O Tower BFT depende tanto das regras do protocolo quanto de uma participação saudável dos validadores.

Tower BFT e conceitos de slashing

Slashing é uma penalidade em que um validador perde stake por comportamento comprovadamente prejudicial.

A documentação do Anza Tower BFT discute a punição de validadores que violam lockouts ao votar em um fork não descendente durante um lockout.

A ideia central é que os validadores devem enfrentar consequências econômicas por votos conflitantes que ameaçam a consistência.

Os conceitos de slashing são importantes porque transformam regras de consenso em incentivos econômicos.

Se os validadores pudessem votar duas vezes sem punição, o protocolo teria uma proteção mais fraca contra históricos conflitantes.

Em um design saudável de Proof of Stake, os validadores são recompensados pela participação honesta e punidos ou excluídos por comportamento prejudicial.

O Tower BFT usa a ideia de violação de lockout como uma forma detectável de comportamento inadequado de votação.

Isso ajuda a tornar os compromissos dos validadores confiáveis.

Normalmente, os usuários não veem a mecânica de slashing diretamente em uma carteira.

No entanto, a existência de regras aplicáveis aos validadores é parte do motivo pelo qual o consenso ponderado por stake pode proteger a integridade do ledger.

Tower BFT e vivacidade

Vivacidade significa que a rede pode continuar produzindo e confirmando blocos.

Um sistema de consenso que é seguro, mas nunca avança, não seria útil para pagamentos, trading, DeFi ou aplicativos.

O Tower BFT busca equilibrar segurança e progresso rápido usando a temporização do Proof of History e lockouts de validadores.

O artigo da Solana sobre Tower BFT afirma que o Tower BFT prioriza a vivacidade em relação à consistência em seu design personalizado no estilo PBFT.

Isso não significa que a consistência seja ignorada.

Significa que o design toma decisões destinadas a manter a rede em movimento sob condições práticas.

Usuários de criptomoedas se importam com a vivacidade porque uma rede ativa pode processar transferências, swaps, ordens, atividade de staking e interações com aplicativos.

Validadores se importam com a vivacidade porque um consenso paralisado pode afetar recompensas, reputação e confiabilidade da rede.

Desenvolvedores se importam com a vivacidade porque os aplicativos precisam de processamento previsível de transações.

O Tower BFT usa o relógio do PoH e regras de lockout para dar suporte ao progresso, ao mesmo tempo que torna históricos conflitantes custosos.

Tower BFT vs. PBFT

PBFT significa Practical Byzantine Fault Tolerance, ou Tolerância Prática a Falhas Bizantinas.

PBFT é uma abordagem clássica de consenso que usa comunicação estruturada entre réplicas para concordar com solicitações apesar de falhas bizantinas.

O Tower BFT é inspirado no PBFT, mas adapta a ideia para a arquitetura de Proof of History da Solana.

O artigo da Solana sobre Tower BFT afirma que a Solana implementa uma derivação do PBFT, com a diferença fundamental de que o Proof of History fornece uma fonte global de tempo antes do consenso.

Isso significa que o Tower BFT não precisa lidar com timeouts da mesma forma que rodadas de mensagens tradicionais em estilo PBFT.

O Proof of History ajuda a codificar o tempo no próprio ledger.

Isso pode reduzir a sobrecarga de mensagens e a latência.

A contrapartida é que o Tower BFT fica estreitamente conectado à arquitetura da Solana baseada em PoH.

Não é um módulo de consenso genérico e pronto para uso que funciona da mesma forma em todas as blockchains.

Ele foi projetado em torno da arquitetura de alto desempenho da Solana.

Tower BFT vs. Proof of Stake

Tower BFT não é o mesmo que Proof of Stake.

Proof of Stake descreve como a influência dos validadores e a segurança econômica estão vinculadas a tokens em staking.

Tower BFT descreve como os validadores usam votos ponderados por stake, lockouts e escolha de fork para alcançar consenso.

Na Solana, esses conceitos trabalham juntos.

Os validadores participam do consenso, e o stake delegado a eles afeta o peso de seus votos.

Os participantes de staking delegam stake a nós validadores, e esses validadores votam nos forks do ledger.

O Proof of Stake fornece o peso econômico.

O Tower BFT fornece a lógica de votação e compromisso.

O Proof of History fornece a estrutura temporal.

Entender o consenso da Solana exige observar as três partes em conjunto, em vez de tratar uma única expressão como o sistema inteiro.

Tower BFT vs. Proof of History

Tower BFT e Proof of History são frequentemente confundidos porque estão estreitamente ligados.

Proof of History é um mecanismo verificável de atraso e ordenação.

Tower BFT é o mecanismo de votação e consenso que usa a temporização do Proof of History.

O Proof of History ajuda os validadores a concordar sobre a passagem do tempo e a ordenação dos eventos.

O Tower BFT ajuda os validadores a concordar sobre qual fork deve ser seguido.

Uma comparação simples é que o Proof of History é o relógio, enquanto o Tower BFT é o processo de votação que usa esse relógio.

O whitepaper da Solana afirma que o PoH pode ser usado junto a algoritmos de consenso como Proof of Stake para reduzir a sobrecarga de mensagens em uma máquina de estados replicada tolerante a falhas bizantinas.

O Tower BFT é um exemplo concreto dessa ideia no design original da Solana.

Chamar o Proof of History de mecanismo de consenso completo é incompleto.

Chamar o Tower BFT de independente do Proof of History também é incompleto.

Tower BFT e validadores

Validadores são os participantes da rede que processam transações, reproduzem o ledger e votam no consenso.

A documentação de validadores da Solana afirma que os validadores formam a espinha dorsal da rede ao processar transações e participar do consenso.

No Tower BFT, os validadores avaliam blocos, acompanham forks e enviam votos.

Seus votos são ponderados pelo stake delegado.

Um validador que vota corretamente de forma consistente e permanece online contribui para a confiabilidade da rede.

Um validador offline ou mal conectado pode perder votos e reduzir sua eficácia.

Um validador que vota incorretamente ou viola as expectativas de lockout pode ameaçar a segurança do consenso.

Por isso, o desempenho, a conectividade, a qualidade do software e a disciplina operacional dos validadores são importantes.

Usuários que fazem staking de SOL participam indiretamente do consenso ao delegar a validadores.

Escolher validadores com cuidado pode apoiar a descentralização e a saúde da rede.

Tower BFT e transações dos usuários

A maioria dos usuários não interage diretamente com o Tower BFT.

Um usuário envia uma transação a partir de uma carteira ou aplicativo, e os validadores a processam pela rede.

Se a transação for incluída em um bloco, os validadores podem votar no fork desse bloco.

À medida que os votos se acumulam e os lockouts se aprofundam, a transação ganha um compromisso mais forte.

É por isso que carteiras e aplicativos podem exibir diferentes estados de confirmação.

Uma transação pode aparecer rapidamente, mas uma finalidade mais forte vem do progresso adicional do consenso.

Para pequenas transferências cotidianas, uma confirmação mais antecipada pode ser suficiente para alguns casos de uso.

Para liquidações de alto valor, os aplicativos podem esperar um compromisso mais forte.

O Tower BFT é o motivo pelo qual esses estados de compromisso têm significado no protocolo, em vez de serem apenas rótulos de interface.

Os usuários se beneficiam quando o consenso funciona bem porque as transações se tornam mais confiáveis e mais fáceis de confiar.

Tower BFT e DeFi

Aplicativos de finanças descentralizadas (DeFi) dependem de liquidação rápida e confiável.

Um swap, uma ação de empréstimo, uma liquidação ou uma atualização de liquidez só é útil se a rede puder concordar com sua ordem e resultado.

O Tower BFT ajuda os validadores da Solana a convergir para um histórico compartilhado do ledger.

Isso afeta o DeFi porque a ordem das transações pode influenciar preços, garantias, liquidações e arbitragem.

Um consenso rápido pode dar suporte a experiências de usuário responsivas em DeFi.

No entanto, usuários de DeFi ainda devem entender que o processamento rápido não elimina risco de smart contract, slippage, risco de oráculo, risco de liquidez ou risco de falha de transação.

O Tower BFT ajuda a cadeia a concordar com o estado, mas não garante que todas as negociações em DeFi sejam lucrativas ou seguras.

Os aplicativos ainda precisam lidar com níveis de confirmação, tentativas novamente, movimento de mercado e controles de risco.

Para desenvolvedores, as premissas de consenso fazem parte do design do aplicativo.

Para traders, a velocidade do consenso é apenas uma parte da qualidade de execução.

Tower BFT e transações de NFT

Ações de mint, compra, venda, transferência e listagem de NFT dependem da ordenação e da liquidação de transações.

O Tower BFT ajuda a determinar o histórico do ledger que registra essas ações.

Durante mints populares de NFT, muitos usuários podem competir para enviar transações rapidamente.

O consenso ainda precisa decidir quais transações são incluídas e em que ordem.

Um caminho de consenso rápido pode melhorar a experiência do usuário, mas não garante que todas as transações serão bem-sucedidas.

Uma transação de mint de NFT pode falhar se a oferta se esgotar, as taxas forem insuficientes, as instruções estiverem incorretas ou o programa rejeitar a ação.

O Tower BFT ajuda os validadores a concordar com o estado final após a rede processar as transações.

Ele não determina se a coleção de NFT é valiosa ou legítima.

Os usuários devem verificar fontes oficiais da coleção, endereços de contrato e o contexto do marketplace.

A segurança do consenso oferece suporte à liquidação, mas não substitui a diligência prévia.

Tower BFT e trading

Traders se importam com o Tower BFT porque a velocidade de liquidação e a finalidade afetam a execução de mercado.

A confirmação rápida pode ajudar traders a mover ativos, interagir com protocolos DeFi e reagir a alterações de preço.

No entanto, traders não devem tratar o consenso rápido como garantia de execução sem risco.

Os resultados de trading ainda dependem de liquidez, slippage, taxas, roteamento de ordens, volatilidade do mercado e design do aplicativo.

Uma transação pode ser processada rapidamente e ainda resultar em uma negociação ruim se o mercado se mover antes da execução.

Uma transação pode ser confirmada e ainda falhar porque uma condição do smart contract não foi atendida.

O Tower BFT dá suporte à capacidade da rede de concordar com o que ocorreu.

Ele não protege traders de estratégias ruins ou do risco de mercado.

Para trading sério, os usuários devem combinar a compreensão sobre consenso com simulação de transações, limites de slippage e gestão de risco.

O consenso é infraestrutura de liquidação, não um sinal de trading.

Tower BFT e níveis de compromisso

Níveis de compromisso são formas voltadas ao usuário de descrever o quão fortemente uma transação ou bloco foi confirmado.

Embora interfaces possam usar rótulos diferentes, a ideia subjacente é que um compromisso maior dos validadores significa maior confiança.

O Tower BFT contribui para o compromisso por meio de votos, lockouts e roots.

Uma transação processada recentemente pode ter menos compromisso do que uma transação que está atrás de muitos votos posteriores.

Uma transação finalizada tem proteção mais forte contra reversão do que uma transação recém-observada.

Desenvolvedores de aplicativos devem escolher níveis de compromisso com base no valor e no risco da ação.

Uma ação em um jogo pode tolerar uma confirmação mais rápida, porém mais fraca.

Uma grande liquidação financeira pode necessitar de finalidade mais forte.

Os usuários devem entender que nem todas as confirmações são iguais.

O Tower BFT é a lógica de consenso que dá significado ao compromisso mais profundo.

Tower BFT e desempenho da rede

O design da Solana busca alto desempenho, e o Tower BFT é uma parte dessa arquitetura.

Ao usar o Proof of History como fonte de temporização, o Tower BFT pode reduzir parte da sobrecarga de mensagens encontrada em designs mais antigos no estilo BFT.

Menos sobrecarga pode ajudar uma rede a chegar a decisões mais rapidamente quando as condições são saudáveis.

No entanto, o desempenho não depende apenas do consenso.

Também depende da propagação de blocos, execução de transações, hardware dos validadores, rede, armazenamento, mercados de taxas e demanda dos aplicativos.

O Tower BFT trabalha junto com outros componentes da Solana que lidam com produção de blocos, propagação de dados, execução e armazenamento do ledger.

Um gargalo em uma parte do sistema ainda pode afetar a experiência do usuário.

Por isso, o desempenho de blockchain deve ser entendido como uma questão de pilha completa.

O Tower BFT ajuda o consenso a avançar rapidamente, mas não é o único motivo pelo qual a rede pode processar transações.

Ele é uma peça central em uma arquitetura maior de alto desempenho.

Tower BFT e custo de reversão

O custo de reversão é o custo ou a dificuldade de reverter um bloco anteriormente aceito.

A documentação do Anza Tower BFT afirma que o custo de reversão precisa ser computável e deve aumentar de forma superlinear para votos mais antigos.

Esse conceito é importante porque usuários e aplicativos precisam de confiança mensurável na liquidação.

Um bloco recém-produzido pode ser mais fácil de substituir do que um bloco coberto por muitos votos com lockout.

O Tower BFT fortalece compromissos mais antigos por meio de lockouts empilhados.

Isso significa que reverter um histórico mais antigo exigiria que mais validadores quebrassem compromissos mais fortes ou aguardassem lockouts mais longos.

Em um sistema de Proof of Stake, consequências econômicas podem tornar esse comportamento custoso.

O custo de reversão não é o mesmo que uma simples contagem de blocos.

Ele depende de votos dos validadores, peso do stake, profundidade de lockout e regras do protocolo.

Entender o custo de reversão ajuda a explicar por que a finalidade aumenta com o tempo.

Tower BFT e premissas de segurança

O Tower BFT depende de várias premissas de segurança.

Ele pressupõe que validadores com stake ponderado suficiente seguem o protocolo de forma honesta.

Pressupõe que os validadores conseguem se comunicar bem o suficiente para que a rede continue avançando.

Pressupõe que violações de lockout podem ser detectadas e punidas de acordo com o design do protocolo e da governança.

Pressupõe que a temporização do Proof of History seja verificável e útil para coordenar o comportamento dos validadores.

Também depende de que o software cliente seja implementado corretamente.

Nenhum mecanismo de consenso é mágico.

Todo design faz concessões entre velocidade, segurança, vivacidade, descentralização, complexidade e risco de implementação.

O Tower BFT foi projetado para os objetivos originais de desempenho da Solana.

Seus pontos fortes e limitações devem ser avaliados no contexto da arquitetura da Solana, e não como se fosse um sistema BFT genérico.

Tower BFT e Alpenglow

Alpenglow é uma grande mudança proposta para o design de consenso da Solana, relevante ao discutir o Tower BFT atualmente.

A proposta SIMD-0326 Alpenglow afirma que ela altera o protocolo central de consenso do design atual baseado em Proof of History e TowerBFT para Alpenglow.

A mesma proposta afirma que o Alpenglow visa maior resiliência e melhor desempenho.

Também afirma que o protocolo atual de consenso TowerBFT tem um tempo de finalidade de 12.8 segundos e não possui uma prova de segurança, algo que a proposta descreve como preocupante.

Isso não significa que os usuários devam entender o Tower BFT como irrelevante.

O Tower BFT continua importante porque explica a arquitetura original de consenso da Solana e o design que o Alpenglow pretende substituir.

Compreender o Tower BFT ajuda os usuários a entender por que o Alpenglow é importante.

Também ajuda desenvolvedores, validadores e pesquisadores a comparar o antigo modelo de voto com lockout a designs mais novos baseados em voto direto e certificados.

Para fins de precisão em glossários, o Tower BFT deve ser descrito considerando que o roteiro de consenso da Solana está evoluindo.

Os usuários devem sempre consultar a documentação atual da Solana e da Anza para verificar o status ativo na mainnet de qualquer atualização de consenso.

Vantagens do Tower BFT

A primeira vantagem do Tower BFT é usar o Proof of History como referência temporal compartilhada.

Isso pode reduzir a sobrecarga de comunicação em comparação com designs BFT que precisam coordenar timeouts por meio de mais trocas de mensagens.

A segunda vantagem é que os lockouts tornam os votos dos validadores relevantes.

Um validador que vota em um fork assume um compromisso baseado em tempo.

A terceira vantagem é que lockouts empilhados fornecem uma forma de avaliar o custo de reversão.

Blocos mais antigos com compromisso mais profundo tornam-se mais difíceis de reverter.

A quarta vantagem é que o Tower BFT se encaixa na arquitetura de alta capacidade de processamento da Solana.

Ele foi projetado para oferecer suporte à confirmação rápida de blocos e à coordenação de validadores.

A quinta vantagem é que a votação ponderada por stake conecta a influência no consenso ao stake delegado.

Isso dá à camada econômica um papel direto na escolha de fork.

Limitações do Tower BFT

A primeira limitação do Tower BFT é a complexidade.

Proof of History, slots, votos, lockouts, roots e escolha de fork podem ser difíceis de entender para usuários e desenvolvedores.

A segunda limitação é que a finalidade não é instantânea.

O compromisso se fortalece ao longo do tempo, à medida que votos e lockouts se acumulam.

A terceira limitação é que o design está estreitamente ligado à arquitetura de Proof of History da Solana.

Isso o torna menos geral do que alguns protocolos de consenso projetados com premissas diferentes.

A quarta limitação é que a qualidade do consenso depende do desempenho dos validadores e da distribuição de stake.

Conectividade fraca, tempo de inatividade ou stake concentrado podem afetar o comportamento da rede.

A quinta limitação é que a própria proposta Alpenglow da Solana identifica preocupações sobre desempenho e prova de segurança no design legado TowerBFT.

Essas limitações explicam por que a pesquisa sobre consenso e as atualizações de protocolo continuam sendo temas ativos no ecossistema Solana.

Equívocos comuns sobre Tower BFT

O primeiro equívoco é pensar que Tower BFT e Proof of History são a mesma coisa.

O Proof of History é o mecanismo de temporização e ordenação, enquanto o Tower BFT é o mecanismo de consenso de voto com lockout.

O segundo equívoco é pensar que Tower BFT é o mesmo que Proof of Stake.

O Proof of Stake fornece influência econômica ponderada por stake, enquanto o Tower BFT organiza votos e lockouts.

O terceiro equívoco é pensar que processamento rápido sempre significa liquidação final.

Uma transação pode ser vista antecipadamente, enquanto uma finalidade mais forte se desenvolve posteriormente.

O quarto equívoco é pensar que validadores podem mudar de fork livremente.

Os lockouts do Tower BFT impedem validadores de votar em forks conflitantes durante períodos de compromisso.

O quinto equívoco é pensar que os usuários precisam entender todos os detalhes do Tower BFT para usar a Solana.

A maioria dos usuários só precisa entender que um compromisso mais forte significa maior confiança.

Boas práticas para usuários

Use carteiras e aplicativos confiáveis que mostrem claramente o status da transação.

Aguarde um compromisso mais forte ao mover ativos de alto valor.

Não presuma que a exibição rápida de uma transação significa que a maior finalidade possível foi atingida.

Quando necessário, verifique o status da transação por meio de exploradores confiáveis ou interfaces de aplicativos.

Entenda que congestionamento de rede, desempenho dos validadores e erros de aplicativos ainda podem afetar a experiência do usuário.

Evite enviar transações repetidas sem verificar se a primeira transação foi processada.

Use controles de slippage ao interagir com protocolos DeFi.

Mantenha SOL suficiente para as taxas de transação ao usar aplicativos baseados em Solana.

Não trate a velocidade de consenso como garantia de lucro no trading.

Use a compreensão sobre finalidade como parte de uma gestão de risco cripto mais ampla.

Boas práticas para desenvolvedores

Escolha níveis de compromisso com base no risco e no valor da ação do aplicativo.

Não trate toda transação observada como igualmente final.

Projete interfaces que expliquem claramente estados pendentes, confirmados e finalizados.

Lide cuidadosamente com tentativas de transação novamente para evitar ações duplicadas ou conflitantes dos usuários.

Monitore comportamentos relacionados a forks e a consistência de RPC ao criar aplicativos de alto valor.

Use provedores de infraestrutura confiáveis e múltiplas fontes de dados, quando apropriado.

Projete aplicativos DeFi considerando slippage, alterações de estado e tempo de confirmação.

Teste o comportamento do aplicativo sob condições de congestionamento e confirmação atrasada.

Mantenha-se atualizado sobre atualizações de consenso da Solana, incluindo mudanças relacionadas ao Alpenglow.

As premissas de consenso devem fazer parte da engenharia do aplicativo, e não uma reflexão posterior.

Perguntas frequentes

O que é Tower BFT em termos simples?

Tower BFT é o sistema original de votação de validadores em estilo BFT da Solana, que usa a temporização do Proof of History para ajudar os validadores a concordar com a cadeia correta.

Tower BFT é o mesmo que Proof of History?

Não. O Proof of History fornece uma estrutura verificável de temporização e ordenação, enquanto o Tower BFT usa essa estrutura para votos e lockouts de validadores.

Tower BFT é o mesmo que Proof of Stake?

Não. O Proof of Stake fornece a camada econômica ponderada por stake, enquanto o Tower BFT fornece a lógica de votação e escolha de fork.

Por que é chamado de Tower BFT?

Ele é chamado de Tower BFT porque os votos dos validadores se acumulam com lockouts crescentes, criando uma estrutura de compromisso semelhante a uma torre.

O que é um lockout no Tower BFT?

Um lockout é um período baseado em slots durante o qual um validador não pode votar em um fork conflitante sem violar seu compromisso anterior.

O que é um slot no Tower BFT?

Um slot é a unidade de tempo da Solana para agendamento de líderes, produção de blocos, votação e medição de lockout.

Qual é o papel dos validadores no Tower BFT?

Os validadores reproduzem o ledger, avaliam blocos, votam em forks e ajudam o cluster a escolher a cadeia válida mais pesada por meio de votos ponderados por stake.

O que o Tower BFT faz durante forks?

O Tower BFT ajuda os validadores a avaliar forks concorrentes e a se comprometer com um fork por meio de votos ponderados por stake e lockouts.

O Tower BFT oferece finalidade instantânea?

Não. A finalidade se fortalece ao longo do tempo à medida que os votos se acumulam e os lockouts se aprofundam.

Por que o Proof of History ajuda o Tower BFT?

O Proof of History fornece ao Tower BFT uma referência temporal compartilhada que ajuda a aplicar timeouts e lockouts com menor sobrecarga de mensagens.

O que é custo de reversão no Tower BFT?

O custo de reversão é a dificuldade ou o custo econômico de reverter um bloco depois que validadores construíram compromissos de lockout sobre ele.

Os usuários podem interagir diretamente com o Tower BFT?

Não. A maioria dos usuários interage por meio de carteiras e aplicativos, enquanto os validadores realizam a votação do Tower BFT em segundo plano.

Por que usuários de DeFi devem se importar com Tower BFT?

Usuários de DeFi devem se importar porque o consenso afeta a ordenação das transações, a força da confirmação, a confiança na liquidação e a confiabilidade dos aplicativos.

Qual é a relação entre Alpenglow e Tower BFT?

Alpenglow é uma reformulação proposta do consenso da Solana que substituiria o protocolo atual baseado em Proof of History e TowerBFT por uma arquitetura mais nova.

Ainda é importante entender o Tower BFT?

Sim. O Tower BFT é importante porque explica a arquitetura original de consenso da Solana e a base com a qual propostas mais novas de consenso são comparadas.

Conclusão

Tower BFT é o mecanismo de votação de Tolerância a Falhas Bizantinas da Solana otimizado para Proof of History.

Ele usa slots, votos de validadores, lockouts, roots e escolha de fork ponderada por stake para ajudar a rede a convergir para um histórico compartilhado do ledger.

O Proof of History fornece a estrutura temporal compartilhada, o Proof of Stake fornece o peso econômico de voto e o Tower BFT fornece a lógica de consenso de voto com lockout.

A ideia principal por trás do Tower BFT é que os votos dos validadores devem criar compromissos baseados em tempo, que se tornam mais fortes à medida que mais votos descendentes são adicionados.

Esse compromisso empilhado torna blocos mais antigos mais difíceis de reverter e dá aos usuários maior confiança à medida que as transações obtêm um compromisso mais forte.

O Tower BFT é importante para usuários, desenvolvedores, validadores, traders, protocolos DeFi e aplicativos de NFT porque o consenso afeta liquidação, ordenação, finalidade e confiabilidade.

Seus pontos fortes incluem coordenação rápida, temporização baseada em PoH, votação ponderada por stake e custo de reversão computável.

Suas limitações incluem complexidade, finalidade não instantânea, dependência do comportamento dos validadores e as preocupações identificadas por propostas de consenso mais novas, como Alpenglow.

À medida que o roteiro de consenso da Solana evolui, Tower BFT continua sendo um termo essencial para entender como a Solana combinou originalmente Proof of History com votação de validadores em estilo BFT.

Em um glossário cripto, Tower BFT deve ser entendido como o mecanismo de consenso da Solana que transforma votos dos validadores em compromissos empilhados e baseados em tempo para escolher forks e fortalecer a finalidade.