Consenso na Solana

Insights práticos

• O papel da Proof-of-History (PoH) na sincronização: a PoH não é um algoritmo de consenso, mas uma ferramenta usada pelo mecanismo de consenso da Solana para sincronização. Da mesma forma, a Proof-of-Stake (PoS) não é consenso, mas sim um mecanismo de resistência a ataques Sybil.
• Transações de voto são necessárias para o consenso: os votos dentro dos blocos não são transações supérfluas usadas para inflar artificialmente as métricas de TPS. Se os votos fossem propagados apenas por gossip (comunicação informal peer-to-peer), poderiam surgir discrepâncias na forma como os validadores percebem o estado da Tower (de votos).
• A Solana tem duas regras principais de confirmação: uma para a seleção de forks no curto prazo (confirmação otimista) e outra para o consenso PoS completo, que garante finalidade (finalized/rooted). Clientes e usuários podem seguir essas regras de confirmação para obter as propriedades de segurança desejadas e personalizar a UX. Isso se reflete em dois níveis de compromisso: “confirmed” e “finalized”.
• Entenda o risco de censura: validadores e desenvolvedores devem conhecer o potencial de ataques de censura, nos quais um validador tenta interromper a sequência de produção de blocos. É importante entender a mecânica desses ataques e o papel do poder computacional e do stake em sua execução.
• Futuras atualizações do protocolo estão próximas: validadores e desenvolvedores devem se preparar ativamente para as próximas mudanças no mecanismo de consenso da Solana, como execução assíncrona e slashing programático.

Introdução

À medida que a atividade aumenta na Solana, várias camadas de sua stack são testadas em níveis sem precedentes. Muito já foi escrito e discutido sobre temas em alta, como mercados locais de taxas, mas o consenso na Solana foi ignorado por muito tempo. No entanto, o aumento da atividade e do interesse exige que a comunidade compreenda profundamente o consenso, pois crescem os incentivos para ataques maliciosos e os lucros de possíveis explorações.

O consenso é um dos aspectos mais importantes da Solana para a comunidade em geral compreender, pois determina como milhares de validadores chegam a um acordo sobre uma ordenação canônica das transações.

O consenso é estudado em sistemas distribuídos há muitos anos. O Problema dos Generais Bizantinos, escrito por Lamport, Shostak e Pease, foi publicado no início da década de 1980. Algoritmos de consenso como o RAFT são usados há muito tempo na web2. No universo cripto, a maioria dos algoritmos de consenso consiste em diferentes implementações do consenso BFT, incluindo Gasper (Ethereum), Tendermint (Cosmos), MonadBFT (Monad), HotShot (Espresso) e Narwhal/Tusk (Sui). 

Este artigo não tenta provar formalmente o mecanismo de consenso da Solana (TowerBFT). Em vez disso, busca explicar aos desenvolvedores e à comunidade em geral como o consenso funciona na Solana, já que, até agora, esse conhecimento está principalmente na mente dos colaboradores da Solana Labs e da Firedancer. Também discutimos algumas considerações sobre limitações e trade-offs.

Uma breve introdução ao consenso

O objetivo de um protocolo de consenso é estabelecer um acordo sobre as transações e suas ordenações relativas dentro de um bloco. Há dois tipos principais de protocolos de consenso usados para que os validadores de uma rede concordem com a ordenação canônica das transações:

• Protocolos de cadeia mais longa: esses protocolos, como o consenso Nakamoto do Bitcoin, tornam canônica a cadeia cuja construção exigiu o maior esforço computacional. Embora isso geralmente esteja relacionado à cadeia com o maior número de blocos, a descrição mais precisa é a cadeia que incorpora a maior quantidade de trabalho acumulado ou poder computacional.
• Protocolos do tipo BFT: a maioria dos protocolos PoS implementa uma versão de um algoritmo de consenso BFT. Esses protocolos, como o pBFT, dependem de limites para garantir vivacidade e segurança. Consistência e disponibilidade são duas garantias do teorema CAP, segundo o qual qualquer armazenamento de dados distribuído só pode oferecer duas das três garantias a seguir: consistência, disponibilidade e tolerância a partições.

Tanto os protocolos de consenso de cadeia mais longa quanto os do tipo BFT obtêm segurança de suas respectivas regras de confirmação. A segurança, composta por proteção e vivacidade, deriva de uma determinada regra de confirmação e não é uma propriedade da cadeia. Conforme definido pela Ethereum Foundation, uma regra de confirmação é “um algoritmo executado pelos nós que indica se determinado bloco está confirmado. Quando está, há a garantia de que o bloco nunca sofrerá uma reorganização, sob certas premissas, principalmente quanto à sincronia da rede e à porcentagem de stake honesto”.

No fim, tudo se resume a consenso social, definido pelas pessoas que escrevem o código dos clientes e expressam o que constitui segurança por meio de determinadas regras de confirmação.

A Proof-of-Stake adiciona outras camadas ao modelo BFT, exigindo que os participantes coloquem seu próprio stake em jogo. Os participantes são recompensados por seguir um conjunto de regras, mas podem sofrer slashing em casos de má conduta comprovada, como assinaturas duplas. Isso é chamado de segurança responsabilizável e permite que o protocolo identifique e puna nós maliciosos sem externalidades para os nós honestos. Isso não substitui o mecanismo de segurança fundamental dos protocolos de consenso BFT: a rede ainda precisa ter menos de um terço de nós desonestos para evitar uma paralisação e menos de dois terços para impedir a validação de transações falsas. O sistema baseado em stake impõe consequências a ações que possam interromper ou reduzir a eficiência da rede.

Há dois limites críticos em uma rede BFT desse tipo:

1. 1/3: se os nós desonestos representarem um terço ou mais do total, a rede poderá “parar”. Nesse cenário, esses nós podem simplesmente deixar de participar, impedindo que os demais alcancem a supermaioria de dois terços necessária para o consenso. Consequentemente, a rede não produz transações incorretas; ela deixa de produzir qualquer transação. Uma métrica popular, embora imprecisa, é o Coeficiente de Nakamoto, que representa o número mínimo de nós necessário para provocar uma falha de vivacidade, paralisando a produção de blocos.
2. 2/3: se os nós desonestos representarem dois terços ou mais do total, eles poderão agir em conluio para validar quaisquer transações que escolherem. Esse é o pior cenário possível: a rede deixa de funcionar corretamente e passa a processar transações conforme determinado pela supermaioria desonesta. Se uma parte adversária controlar mais de 67% do stake, ela poderá isolar um nó honesto, como o nó de uma grande corretora, por exemplo, a Binance. Esse isolamento poderia ser obtido por meio de conluio com um data center para restringir o tráfego de rede do nó. A entidade maliciosa poderia então fazer esse nó isolado finalizar um bloco criado por ela enquanto distribui simultaneamente um bloco conflitante ao restante da rede. Esse ataque explora a perspectiva limitada do nó isolado e pode levar a gastos duplos, pois o restante da rede e o nó isolado têm visões diferentes do estado on-chain.

Um ataque semelhante é viável até mesmo com um stake menor, acima de 33%, mas exigiria criar uma partição de rede, em vez de apenas isolar um nó. Nessa situação, o participante bizantino pode explorar a partição para manipular diferentes segmentos da rede com informações conflitantes, novamente criando o risco de gasto duplo e outras falhas de segurança.

Normalmente, um número maior de nós dificulta que qualquer parte corrompa uma parcela significativa o bastante para atingir esses limites, supondo que haja separação geográfica. No entanto, o desejo por uma rede maior muitas vezes entra em conflito com a eficiência. Um número maior de nós pode tornar o consenso mais lento devido ao aumento das exigências de transmissão de dados, pois a propagação dos votos leva mais tempo. Por isso, alguns protocolos impõem um limite máximo rígido ao número de nós.

Proof-of-History (PoH)

Embora a Proof-of-Stake (PoS) garanta o consenso em uma rede, a Solana incorpora a Proof of History (PoH) ao seu mecanismo de consenso PoS, permitindo a sincronização necessária para a produção contínua de blocos. Para isso, a Solana ignora slots cujos líderes são lentos ou não respondem, sem aguardar uma rodada sincronizada de consenso. A PoH não busca provar o momento exato em que um evento ocorreu, mas sim comprovar a sequência e a passagem do tempo entre os eventos.

Ao contrário do que muitos acreditam, a Proof-of-History (PoH) não é, por si só, um mecanismo ou algoritmo de consenso. Embora a implementação atual do consenso utilize aspectos da PoH, seria teoricamente possível removê-la e fazer pequenas alterações na implementação sem impedir o funcionamento do consenso na Solana.

O núcleo da PoH é um algoritmo simples de hashing semelhante a uma Verifiable Delay Function (VDF), embora tecnicamente não seja uma VDF. A Solana implementa isso usando uma função hash sequencial resistente à pré-imagem (SHA-256), executada continuamente e que usa a saída de uma iteração como entrada da próxima. Esse cálculo é executado em um único núcleo de cada validador.

Embora a geração da sequência seja sequencial e use uma única thread, a saída pode ser verificada em paralelo, permitindo uma verificação eficiente em sistemas com vários núcleos. Embora exista um limite máximo para a velocidade de hashing, melhorias de hardware podem oferecer benefícios adicionais de desempenho.

Considere um exemplo com quatro validadores na rede Solana: validadores A, B, C e D. Nesse exemplo, a programação de líderes pode determinar a sequência de produção de blocos como A - B - C - D. O validador A começa gerando um bloco em seu turno. Para isso, ele usa o mecanismo PoH, que executa iterativamente a função hash SHA-256 e forma uma escala de “ticks”. Esse processo de hashing cria um registro único e verificável do tempo decorrido, garantindo que o bloco do validador A reflita com precisão a passagem do tempo. Quando o validador A conclui seu bloco, chega a vez do validador B produzir o próximo, seguido pelo validador C.

Suponha que o validador C tente interromper a sequência emitindo um bloco fora de seu turno, com o objetivo de suceder diretamente o validador A e ignorar o validador B. Para ocupar de forma convincente o lugar do validador B, C precisaria replicar a sequência de hashes PoH que B teria produzido. Isso significa gerar uma sequência de hashes que represente o tempo que B levaria para produzir um bloco. Existe um limite físico para o desempenho de hashing em um único núcleo. Assim, sabemos que determinada quantidade de tempo transcorreu, pois há um número máximo de hashes que um computador pode gerar em um dado intervalo.

O validador C pode tentar censurar o validador B na programação de líderes gerando uma cadeia de blocos vazios a partir do fim de um bloco legítimo anterior, o bloco do validador A, sem incluir transações. Para censurar B com sucesso, C precisa cumprir duas condições. Primeiro, C precisa de poder computacional para processar a cadeia PoH vazia. Segundo, C precisa disseminar rapidamente seu bloco para um número suficiente de nós com stake, garantindo que ele seja aceito durante o slot designado ao próprio C e, assim, censurando B. Isso é mais rápido para um validador com alto peso de stake graças ao Turbine, que prioriza o fluxo de informações com base no peso de stake do validador.

Esse cenário de ataque é viável, mas a janela para uma censura bem-sucedida é limitada. O nó atacante precisa ter recursos computacionais consideráveis para hashing SHA-256 e uma quantidade significativa de stake, pois o número de blocos que ele pode gerar é proporcional ao seu stake.

Além de precisar alcançar a rede mais rápido que o nó A, C também precisa gerar o hash em alta velocidade. Esse ataque visa principalmente o cenário em que um validador designado como líder no slot n tenta censurar validadores de slots de liderança anteriores a n. O grau de censura que esse validador pode alcançar depende de seu stake, pois sua capacidade de criar slots de liderança está diretamente vinculada à quantidade de stake que possui.

O mecanismo PoH também garante que os blocos sejam produzidos em uma frequência consistente. Como cada validador pode verificar a sequência PoH de forma independente, não é necessária uma sincronização externa de tempo. A Ethereum, por exemplo, usa o Network Time Protocol (NTP) em cada bloco para o consenso. Na Solana, cada validador verifica de forma independente e endógena se cada bloco foi produzido no slot correto, sem usar um protocolo externo.

Tower BFT (o mecanismo de consenso da Solana)

O Tower BFT, mecanismo de consenso da Solana, opera depois que os shreds, ou blocos parciais, são propagados para outros validadores:

Como mencionado anteriormente, a Solana executa o Tower BFT junto com a Proof-of-History. O Tower BFT é um algoritmo de consenso semelhante ao pBFT, projetado para aproveitar os cálculos de relógio sincronizados da Proof-of-History. Isso estabelece um relógio universal em toda a rede e permite ignorar com eficiência os slots atribuídos a líderes lentos ou sem resposta. O processo elimina a necessidade de a rede passar por uma rodada síncrona de consenso para cada slot e permite a produção contínua de blocos, pois os validadores não precisam esperar que os blocos anteriores cheguem antes de construir o próximo.

Outro equívoco é acreditar que o mecanismo de consenso da Solana já implementa slashing programático. Embora o slashing esteja no roadmap, atualmente a rede para após uma violação de segurança e depende do consenso social para aplicar slashing quando necessário.

O mecanismo de consenso da Solana atribui diferentes graus de influência a diferentes nós. Os votos da rede não são iguais: eles são ponderados de acordo com o stake de cada nó e seguem os mesmos princípios de QoS ponderada por stake e do Turbine. Mantidas as demais condições, um nó com stake maior exerce mais influência sobre a definição do consenso canônico do que um com stake menor.

Por exemplo, em uma rede com quatro nós e um total de 100 unidades de stake, a distribuição e a influência podem ser as seguintes:

• O nó A tem 10 unidades de stake.
• O nó B tem 20 unidades de stake.
• O nó C tem 30 unidades de stake.
• O nó D tem 40 unidades de stake.

Nessa configuração, a capacidade de cada grupo de nós desonestos varia. Um único nó, como o nó D, poderia paralisar a rede apesar de representar apenas 25% do número total de nós, devido ao seu grande stake. Da mesma forma, uma combinação como os nós C e D poderia aprovar transações incorretas, mesmo representando apenas 50% dos nós, pois detém stake suficiente para influenciar o resultado.

O limite de um terço necessário para paralisar a rede pode ser atingido por nós desonestos, comprometidos ou bloqueados. Já o limite de dois terços para validar transações incorretas exige conluio ativo e não pode ser alcançado apenas bloqueando nós honestos. Portanto, atingir esse segundo limite é significativamente mais difícil. Isso ocorre porque é necessário corromper ou comprometer nós para que participem ativamente do esquema desonesto, em vez de simplesmente bloquear os nós honestos.

Contexto dentro dos slots

Na Solana, os líderes de slot recebem quatro slots consecutivos com duração total aproximada de 1,6 segundo (4 blocos x 400 ms por bloco). Os líderes são escolhidos no início de cada época (432.000 slots ou ~2 a 3 dias). A programação de líderes é escolhida aleatoriamente em relação ao peso de stake de cada validador.

O líder é responsável por construir e propor um novo bloco para cada slot atribuído a ele. Não há separação entre proponente e construtor, como existe no ecossistema Ethereum. Outros validadores atestam a validade de um bloco por meio de transações de voto, aplicando a regra de escolha de fork à própria visão local da ponta da rede Solana.

Os líderes precisam publicar os blocos dentro de um determinado intervalo de ticks PoH para que sejam válidos. Um bloco que não seja publicado nesse intervalo é considerado ignorado.

Considere o exemplo a seguir de uma programação de líderes com quatro participantes (A, B, C e D), na qual D tenta interromper a sequência. Se D tentar intervir durante o turno de C, precisará criar uma sequência de ticks PoH que efetivamente ignore o bloco de C, resultando em uma cadeia com esta aparência:

A - B - [C ausente] - D.

Em uma situação na qual o bloco de C esteja ausente, um D honesto precisaria gerar uma sequência PoH que cobrisse toda a duração do slot de C antes de iniciar o seu próprio. Isso faria o bloco de D parecer válido, pois ele sucederia o bloco de B depois do tempo reservado ao slot de C.

Enquanto D produz a sequência PoH correspondente ao slot de C, normalmente C estaria transmitindo seu bloco, conectado ao de B por uma sequência PoH apropriada. Isso leva a dois resultados possíveis:

• Se o cálculo PoH de D não for mais rápido que o de C: como C conclui seu bloco aproximadamente quando D começa a transmitir o próprio, a rede já terá visto o bloco de C e rejeitará o de D.
• Se D calcular a PoH mais rápido que C: D começará a transmitir seu bloco antes de C concluir o próprio. Mesmo assim, D precisaria ser consideravelmente mais rápido que C para afetar a sequência de forma significativa. Isso é improvável devido à alta velocidade e ao limite máximo relativamente semelhante dos recursos das CPUs usadas pelos validadores no cálculo SHA-256.

Nas duas situações, as chances de D substituir C com sucesso são mínimas. Além disso, se a tentativa de D de substituir C falhar, ele perderá a oportunidade de emitir um bloco em seu próprio slot. Emitir um bloco logo após B e tentar emitir outro depois de C constitui uma violação, pois cria dois blocos para o slot de D, o que resultaria em uma infração passível de slashing. Cada tentativa fracassada faz D perder sua própria oportunidade de produzir um bloco, indicando que essa estratégia dificilmente seria adotada por D. 

Do ponto de vista da rede, as intenções de D são indeterminadas. É difícil, se não impossível, diferenciar entre D simplesmente não ter visto o bloco de C, sem intenção de censurá-lo, e D ter pretendido censurar B. Por isso, esse comportamento não é facilmente detectável nem pode ser punido pela rede.

Transações de voto

O mecanismo de consenso da Solana depende de transações de voto para alcançar o consenso. As transações de voto ficam dentro de um bloco, mas recebem prioridade para não serem sobrepostas pelas transações comuns. Atualmente, a maioria das transações de um determinado bloco consiste em transações de voto:

No entanto, isso pode não ocorrer para sempre, pois a porcentagem de transações de voto em um bloco representa a relação entre a atividade e o número de validadores que participam do consenso. No futuro, as transações de voto poderão ser minoria em um determinado bloco.

As transações de voto são necessárias para o consenso — elas não são transações supérfluas usadas para inflar artificialmente as métricas de TPS. Se os votos fossem propagados apenas por gossip, uma comunicação informal peer-to-peer, poderiam surgir discrepâncias na forma como os validadores percebem o estado da Tower de votos. Essas discrepâncias poderiam fazer os validadores terem perspectivas diferentes sobre qual fork tem mais chances de ser o correto, levando a possíveis divergências à medida que tomam decisões gananciosas com base em informações incompletas ou inconsistentes. A produção contínua de blocos exige votação contínua, principalmente enquanto os blocos anteriores ainda estão sendo confirmados. Isso requer uma visão confiável e consistente do estado da Tower.

Assim como as transações comuns iniciadas pelos usuários, as transações de voto também precisam pagar a taxa-base (0,000005 SOL). Ela é paga pela identidade do validador, que precisa permanecer em uma hot wallet para assinar constantemente, enquanto a conta de voto é usada para consulta de contas e delegação.

Cada voto, assinado pelo validador, inclui a chave pública do validador e o hash do bloco no qual ele está votando.

Quando um validador recebe vários blocos para o mesmo slot, ele acompanha todos os forks possíveis até conseguir determinar o “melhor”. Os validadores executam localmente a função de transição de estado relevante, o que mudará com a execução assíncrona, e depois votam em novos blocos após o replay. Eles expressam seus votos em determinado fork por meio de transações de voto on-chain.

Em cada transação de voto, um validador publica votos com um período de lockout.  Esse lockout funciona como um mecanismo de compromisso, vinculando os validadores ao fork escolhido e impondo custos de oportunidade às suas decisões. Hoje, os lockouts não são impostos pelo runtime, mas pelo consenso social — violações recorrentes dos lockouts de votação muito provavelmente resultarão em slashing manual. É provável que o slashing programático por violação dos períodos de lockout seja adicionado em breve, pois deixar de receber créditos de voto não oferece um desincentivo suficiente.

O validador também assina um hash do bloco para cada bloco ancestral entre seu voto anterior e os blocos rooted/finalized. Isso é necessário para detectar blocos duplicados. Se um líder enviasse blocos distintos a cada nó, cada nó acabaria votando em um predecessor diferente para o mesmo slot. No entanto, em uma época composta por 65.000 slots, o tamanho de cada voto poderia chegar a 2 MB no cenário mais extremo. Isso ocorreria porque poderiam ser necessários hashes de 32 bytes para cada um dos 65.000 slots. Esse assunto será explorado com mais detalhes em uma publicação futura.

Os validadores gerenciam uma “Vote Tower”, uma pilha sequencial de votos na qual cada voto reforça um fork e é ancestral do fork acima dele na Tower. Adicionar um novo voto à Tower dobra os lockouts de todos os votos anteriores na pilha, aumentando progressivamente o compromisso e o período de lockout das decisões anteriores. O próprio processo de votação é regido por várias verificações: os validadores precisam respeitar os períodos de lockout dos votos anteriores; garantir que uma parcela significativa da rede, normalmente dois terços, também esteja comprometida com o mesmo fork; e obter uma maioria substancial, acima de 38%, de votos em forks alternativos antes de mudar para um novo fork.

Para um bloco no slot n, os votos de outros validadores além do líder começam a aparecer on-chain já em n+1. Não há subcomitês de votação — todos os validadores podem votar em todos os blocos. Esses votos aparecem primeiro nos blocos de outros validadores próximos, a um salto de distância, na árvore do Turbine. Os votos para o slot n podem aparecer até o slot n+512, pois um validador pode votar em qualquer slot cujo “hash do slot” ainda seja conhecido, e esses hashes são mantidos por 512 slots (crédito a Shinobi). Não há um limite máximo predeterminado em um bloco específico para o slot n. No entanto, slots rooted sobre os quais tenham sido construídos pelo menos 32 blocos contínuos deixam de aceitar votos e tornam-se finalized.

O esquema de votação tem algumas peculiaridades que não são totalmente impostas pelo runtime. Por exemplo, atualmente os validadores são incentivados a votar apenas em slots “rooted”, ignorando a ponta da cadeia, e isso não é punido pelo consenso. Assim, um validador pode continuar recebendo créditos de voto por forks com probabilidade extremamente alta de se tornarem canônicos sem contribuir para a ponta da cadeia nas operações reais de consenso. Isso já ocorre atualmente, com um validador apresentando “latência de voto” média superior a 68 slots. Um recurso proposto chamado Timely Vote Credits busca reduzir esse desalinhamento de incentivos.

Regra de escolha de fork da Solana

Assim como a Ethereum (LMD Ghost e Casper FFG), a Solana tem duas regras de confirmação: uma para a seleção de forks no curto prazo e outra para o consenso PoS completo que garante finalidade. Isso permite que usuários e clientes personalizem a UX usando diferentes regras de confirmação. Essas regras se refletem em dois níveis de compromisso: “confirmed” e “finalized”.

Blocos “confirmed”, também conhecidos como confirmação otimista, exigem que pelo menos 2/3 dos validadores tenham votado em um bloco específico por meio de transações de voto. Seria necessário aplicar slashing a ~4,6% do stake atual para possibilitar violações de finalidade. Blocos “finalized” exigem votos em pelo menos 32 slots subsequentes ou uma supermaioria (>2/3) dos votos. Um ataque malicioso exigiria aplicar slashing a mais de 1/3 do stake. Isso leva muito mais tempo do que nos blocos “confirmed”, pois é necessário esperar pelos blocos rooted 32 blocos antes para alcançar a finalidade completa.

Uma regra de escolha de fork permite que a rede chegue a um consenso sobre a ponta da cadeia. A implementação da Solana Labs trata a escolha de fork principalmente por meio de um arquivo Rust com ~4.600 linhas, apropriadamente chamado heaviest_subtree_fork_choice.rs. Ele fornece a lógica necessária para os validadores determinarem qual fork tem mais chances de se tornar canônico. Uma análise mais detalhada do código será apresentada em uma publicação futura, mas, em um nível bastante geral, a mecânica da escolha de fork funciona assim:

1. Os votos são adicionados com add_votes():

Esse processo percorre os novos votos, subtrai o stake das contas de voto dos slots antigos quando necessário e adiciona o stake aos novos slots votados.

2. generate_update_operations() é chamado para criar um lote de operações de atualização de forks:

Isso:

• Subtrai o stake do fork antigo
• Adiciona o stake ao novo fork
• Agrega o stake de cada fork até a raiz

3. process_update_operations():

• Chama mark_fork_valid()/invalid() quando necessário
• Chama aggregate_slot() em cada fork para atualizar os pesos
• Chama add_slot_stake()/subtract_slot_stake() para atualizar os stakes

4. aggregate_slot():

• Soma o stake de todos os slots filhos
• Encontra o fork filho mais pesado pelo peso de stake
• Encontra o fork filho mais profundo pela altura
• Propaga esses valores para cima a fim de encontrar o fork mais pesado e mais profundo a partir desse slot

5. select_forks():

• Retorna o fork mais pesado no geral para a produção de blocos
• Retorna o fork mais pesado descendente do último voto

O stake é adicionado ou subtraído com base nos votos, a agregação recalcula os pesos de baixo para cima em cada fork e a raiz com a subárvore de maior peso é escolhida como o melhor fork para construir e votar.

Probabilidade de inclusão

A probabilidade de inclusão de uma transação muda ao longo de seu ciclo de vida depois que ela atende aos requisitos necessários das respectivas regras de confirmação.

Embora os slots possam ser “ignorados”, como quando o líder está offline, a transação pode ser incluída em blocos futuros ou não ser incluída.

Os slots apresentados aqui são aproximações, mas buscam dar ao leitor uma ideia de quando os votos costumam se acumular. Além disso, isso é exclusivo para cada bloco: os blocos podem atingir os níveis de confirmação “confirmed” ou “finalized” após diferentes intervalos. O risco de reversão diminui monotonicamente durante o ciclo de vida da transação. Mesmo depois que um bloco se torna finalized (rooted), ele pode, em teoria, sofrer um fork por meio do consenso social e ser removido da cadeia “canônica”.

Áreas para pesquisas futuras e conclusão

Esta publicação destacou o funcionamento interno do Tower BFT, o mecanismo de consenso da Solana, e de outros mecanismos relevantes. Exploramos o papel da Proof-of-History, das transações de voto e da escolha de fork no contexto da Solana para criar um fork canônico que ordene as transações.

Há várias outras linhas de pesquisa e formalização desses mecanismos que podem ser exploradas, como:

• Pesquisadores da Ethereum quantificaram o valor de participar de Timing Games, nos quais os produtores de blocos esperam até o fim do slot para enviar seus blocos. Como esses jogos se apresentam quantitativamente na Solana? Eles já estão ocorrendo?
• A execução assíncrona está no roadmap para se tornar a principal mudança de protocolo de 2024. Quais são os possíveis vetores de ataque e as considerações de segurança relevantes para nós que apenas votam em forks existentes, em vez de calcular localmente as transições de estado?
• Atualmente, uma minoria significativa dos validadores (<20%) executa modificações do cliente da Solana Labs ou do Jito-Solana. Quais limites não regidos pelo runtime ou pelas regras de confirmação eles estão alterando?
• Implementação de slashing programático. Atualmente, fora do consenso social, há pouco incentivo econômico para não executar estratégias de negociação altamente lucrativas sem sofrer slashing.
• Como se comporta o desempenho do mecanismo de consenso da Solana ao executar dois clientes completamente diferentes, mesmo que ambos tentem seguir as mesmas regras de confirmação?
• Quais são os benefícios esperados dos subcomitês de votação para o desempenho e a redução do estado?
• Quais são os possíveis vetores de ataque ao reiniciar a partir de um slot confirmado de forma otimista, em vez de um slot finalized? Como soluções off-chain de terceiros, como corretoras, devem avaliar o uso da confirmação otimista ou da finalidade completa?
• Os fundos submetidos a slashing devem ser usados como seguro para transações incluídas em violações de segurança? Quais seriam a mecânica e os incentivos de um fundo de seguro denominado em SOL?

Nesta publicação, exploramos alguns dos mecanismos e limites implementados pela Solana em seu mecanismo de consenso e como eles se relacionam à produção típica de blocos pelos líderes nos slots atribuídos. O recente aumento da atividade na Solana oferece testes reais de vivacidade e segurança para esses mecanismos, com incentivos maiores para ataques maliciosos.

Agradecemos a anoushk (Tinydancer), dubbel06 (Overclock), Prithvi (Helius), Mert (Helius) e Jarry (Ellipsis Labs) pelas discussões e pelos comentários.