O que são os níveis de compromisso da Solana?

O que são os níveis de compromisso da Solana?

Os níveis de compromisso da Solana são uma forma padronizada de medir o consenso da rede sobre determinado bloco ou transação. Ao consultar um nó RPC da Solana para verificar o status de uma transação ou os dados de uma conta (por exemplo, getTransaction), você pode especificar um nível de compromisso para indicar o grau de finalização desejado para os dados. A Solana usa esse nível de compromisso para permitir que os clientes equilibrem latência e certeza: um compromisso menor oferece respostas mais rápidas, enquanto níveis de compromisso maiores dão aos desenvolvedores garantias mais fortes de que o estado não será revertido.

A Solana define três níveis principais de compromisso (em ordem decrescente de finalidade):

Finalized

O nível mais alto de certeza, indicando que o bloco foi confirmado por uma supermaioria do stake (≥66 %) e que pelo menos outros 31 blocos confirmados foram construídos sobre ele, dando ao slot o lockout máximo de 32 votos. Uma transação finalized é efetivamente irreversível.

Confirmed

Um nível intermediário no qual uma supermaioria do stake (≥66%) votou no bloco, mas ele ainda não foi finalizado por um período mais longo de votação contínua que dificulta sua reversão. Isso costuma ser chamado de confirmação otimista e oferece uma forte garantia de que a transação está no “fork principal”, ou cadeia canônica.

Processed

Processed significa que a transação acabou de ser processada por um líder e incluída no bloco mais recente conhecido pelo nó. No entanto, esse bloco talvez ainda não tenha recebido nenhum voto do cluster como um todo. A transação ainda pode ser descartada se o bloco não acabar no fork majoritário.

Esses níveis representam etapas do ciclo de vida de uma transação. 

Uma transação recém-enviada passa de Processed → Confirmed → Finalized à medida que mais participantes da rede observam e votam no bloco que a contém, e blocos subsequentes são construídos sobre esse bloco. Um compromisso maior indica que mais nós concordaram com a inclusão da transação, reduzindo o risco de fork ou reversão. 

Vamos analisar cada nível em detalhes.

Nível de compromisso Processed

Uma transação se torna Processed assim que um nó validador (ou seja, o líder atual) a inclui em um bloco. Esse é o primeiro reconhecimento: a transação foi recebida e incorporada ao estado do ledger localmente.

As principais características do nível Processed incluem:

• Incluída em um bloco: a transação está em um bloco produzido por um validador.
• Sem garantia de fork majoritário: esse bloco pode ou não acabar no fork majoritário (mais longo/pesado)
• Resposta mais rápida: fornece uma resposta imediata de que a transação foi processada por um nó. Isso é útil para atualizações rápidas no cliente (por exemplo, exibir uma transação pendente na interface de uma carteira).
• Sem segurança completa: nessa etapa, não há garantia de que outros validadores tenham visto ou votado no bloco. O cluster ainda pode “pular” esse bloco ou substituí-lo por um fork alternativo. Em outras palavras, Processed = incluída, mas ainda não confirmada por outros.

Exemplo de bloco Processed: 

Suponha que Alice envie uma transferência na Solana. Assim que o líder atual a adiciona a um bloco (slot N), a transação é marcada como Processed. A carteira de Alice pode exibir imediatamente a transação como pendente/processada. 

No entanto, se o bloco desse líder não for aceito pela maioria dos validadores (por exemplo, se o líder estiver lento ou offline e outro fork assumir), a transação de Alice poderá desaparecer (ou seja, ser descartada), pois o bloco processado não passou a fazer parte da cadeia principal.

Nível de compromisso Confirmed

Um nível de compromisso Confirmed indica que o bloco da transação foi aceito pela supermaioria do cluster e muito provavelmente está na cadeia canônica. Tecnicamente, “confirmed” significa que ≥66% dos validadores, ponderados pelo stake, votaram diretamente nesse bloco. 

Principais características:

• No fork majoritário: o bloco que contém a transação é reconhecido como parte do fork majoritário do ledger. Isso significa que a rede considera esse bloco como canônico.

• Votos da supermaioria: pelo menos dois terços do stake total votaram para confirmar o bloco. Esses votos são coletados pelo mecanismo de gossip da Solana, o que significa que os validadores transmitiram e observaram votos para esse bloco em toda a rede. Essa etapa utiliza a confirmação otimista, introduzida na Solana v1.3, que permite aos nós tratar um bloco como confirmado assim que uma supermaioria vota nele (mesmo antes de ser finalizado).

• Baixo risco de reversão: com consenso de 66% ou mais, é altamente improvável, embora não impossível, que um fork conflitante substitua esse bloco. Na prática, todos os validadores honestos se comprometeram com esse bloco, a menos que ocorra uma grande reorganização. Nenhum bloco confirmado foi revertido nos cinco anos de história da Solana.

• Mais rápido que Finalized: o status confirmed geralmente ocorre pouco depois (em um ou dois segundos) de determinado bloco ou transação ser marcado como processed, pois os validadores votam rapidamente em novos blocos. Ele não aguarda muitos blocos subsequentes. Portanto, confirmed oferece um bom equilíbrio entre velocidade e confiança em condições normais.

• Finalidade otimista: em muitos casos, os desenvolvedores tratam uma transação confirmed como essencialmente final para a maioria dos fins práticos, devido ao consenso rápido da Solana. No entanto, ainda existe uma pequena possibilidade de reversão até a finalização.

Exemplo de bloco Confirmed: 

A transação de Alice no exemplo anterior se torna Confirmed quando os validadores do cluster votam no bloco N. Na prática, se os validadores dos próximos slots (N+1, N+2 etc.) votarem e reconhecerem o bloco N, atingindo o limite de 66%, a rede marcará o bloco N como confirmed. A carteira de Alice já pode exibir a transação ao usuário como confirmada com segurança. 

A probabilidade de a transferência de Alice ser revertida nesse momento é muito baixa (isso só ocorreria em caso de um fork raro ou de um problema na rede). Isso é semelhante a “N confirmações” em outras cadeias, mas, na Solana, baseia-se na votação por stake em vez de um número fixo de confirmações de bloco.

Nível de compromisso Finalized

Uma transação se torna Finalized quando uma supermaioria vota em seu bloco e um número suficiente de blocos adicionais é construído sobre ele. No contexto do consenso da Solana, isso corresponde ao bloco alcançar o lockout máximo, normalmente depois de 32 votos (slots) consecutivos o confirmarem. Finalized é o nível de compromisso mais forte e oferece o maior grau de certeza de que a transação não será revertida. 

As características de Finalized incluem:

• Bloco irreversível: o cluster reconheceu esse bloco como finalizado, o que significa que ele foi enraizado no estado do ledger. Os validadores não o reverterão, e ele é efetivamente permanente.

• Supermaioria + lockout: assim como em Confirmed, pelo menos 66% do stake endossou o bloco. Além disso, 31 ou mais blocos confirmados subsequentes foram adicionados depois dele. Em outras palavras, a rede construiu uma cadeia profunda sobre esse bloco, atingindo a profundidade de lockout na qual uma reorganização é inviável.

• Lockout máximo (32 votos): o mecanismo Tower BFT da Solana dobra exponencialmente o período de lockout dos votos. Quando um bloco acumula 32 votos na torre (o que significa que permaneceu na ponta do fork por mais 32 slots), ele atinge o lockout máximo e é finalizado. Nesse momento, qualquer validador que tentar votar em um fork alternativo estará violando as regras de consenso.

• Mais seguro, confirmação mais lenta: a finalização geralmente ocorre algum tempo depois dos níveis processed e confirmed (cerca de ~10–20 segundos em condições normais, pois 32 slots de ~400 ms cada ≈ 13 segundos). Essa é a compensação pela certeza de Finalized. Ao aguardar a finalização, os clientes eliminam todo o risco de a transação ser descartada ou revertida, ao custo de latência adicional.

• Confirmado + blocos construídos sobre ele: outra forma de entender a finalização é que se trata de um bloco confirmed que foi enterrado sob muitos outros blocos. Todos os nós honestos bloquearam comprovadamente esse bloco como parte do ledger permanente.

Exemplo de bloco Finalized:

A transação de Alice atinge o status Finalized depois que a rede continua produzindo blocos além do slot N. Suponha que, até o slot N+32, uma supermaioria dos validadores tenha votado em cada bloco sucessivo até N+32 (sem que nenhum fork assumisse). O bloco N (com a transação de Alice) agora está finalizado. 

Nesse momento, a transação de Alice é absolutamente permanente no ledger da Solana — mesmo que ela espere algum tempo, o estado que inclui sua transferência não mudará. 

Qualquer aplicação que exija finalidade forte (como uma corretora liberando fundos) já pode agir com segurança com base nessa transação. Vale destacar que, se um invasor tentasse revertê-la, precisaria controlar mais de 1/3 do stake e violar o consenso.

Níveis de compromisso obsoletos

Versões anteriores da Solana (antes de 2021) disponibilizavam níveis de compromisso adicionais que, desde então, foram descontinuados em favor dos três níveis acima.

Para fins de referência, veja os termos legados e como eles correspondem aos níveis atuais:

• recent – Obsoleto; equivalente a Processed. Na documentação mais antiga, “recent” se referia simplesmente ao estado mais recente conhecido pelo nó.

• single e singleGossip – Obsoletos; equivalentes a Confirmed. Esses termos se referiam a confirmações envolvendo um único validador ou realizadas por gossip, o que corresponde à definição de confirmed.

• root e max – Obsoletos; equivalentes a Finalized. “Root” se referia ao estado enraizado e finalizado no cluster, enquanto “max” indicava o lockout máximo — ambos significavam, na prática, finalized.

Hoje, os desenvolvedores devem usar apenas processed, confirmed ou finalized ao especificar um nível de compromisso. Desde a v1.5.5, a API JSON-RPC da Solana usa esses termos como padrão e trata os termos obsoletos como aliases dos níveis correspondentes. 

Além disso, se nenhum compromisso for especificado em uma solicitação RPC, o padrão será Finalized (ou seja, por padrão, o nó retorna o estado com o maior nível de finalização).

Diferenças entre os níveis de compromisso

As diferenças entre Processed, Confirmed e Finalized podem ser entendidas em termos de quanto da rede reconheceu a transação e da probabilidade de ela ser revertida. A tabela abaixo (adaptada da documentação oficial da Solana) resume as principais diferenças:

Em resumo, Processed significa apenas que a transação está em um bloco (nada além disso). Confirmed significa que o cluster concordou com esse bloco (votos da supermaioria), mas ele ainda está próximo da ponta da cadeia. Finalized significa que o bloco está em uma parte profunda da cadeia, com muitas confirmações — tão profunda que ele é efetivamente imutável.

Outra forma de entender a diferença é pela probabilidade de a transação permanecer no ledger canônico ao longo do tempo. 

Imediatamente após o processamento, a probabilidade não é de 100% (há possibilidade de fork ou falha). Depois da confirmação por mais de 66% do stake, a probabilidade de inclusão aumenta consideravelmente. Quando a transação é finalizada com dezenas de blocos sobre ela, a probabilidade de inclusão chega a ~100%. 

Isso é ilustrado no gráfico abaixo, que mostra como a probabilidade de finalização de uma transação aumenta à medida que mais slots passam e o nível de compromisso sobe:

A probabilidade de uma transação ser incluída na cadeia canônica final aumenta com o tempo. Inicialmente, no slot n (transação processada), existe algum risco de a transação ser “ignorada” ou excluída por um fork. Com a confirmação otimista (confirmed), a probabilidade de inclusão aumenta rapidamente à medida que os validadores votam. Depois que um número suficiente de forks consecutivos é construído sobre ela (finalized), a probabilidade de reversão se torna praticamente zero. Isso demonstra a redução do risco de reversão à medida que o nível de compromisso aumenta.

Como a Solana determina os níveis de compromisso?

Entender como o consenso da Solana funciona “nos bastidores” ajuda a explicar por que esses níveis de compromisso existem:

Proof of History (PoH) e produção de blocos

Os líderes da Solana produzem blocos em rápida sucessão (um líder por slot, com slots de ~400 ms). As transações são transmitidas para uma cadeia de hashes de Proof of History (PoH), formando entradas em um bloco. Os blocos se propagam rapidamente pela rede por meio do Turbine (o protocolo de propagação de blocos da Solana). Quando um líder produz um bloco com sua transação, esse bloco é propagado imediatamente, mas ainda não está confirmado — o que corresponde à etapa Processed.

Votação (Tower BFT)

A Solana usa um algoritmo de consenso BFT chamado Tower BFT. Os validadores (cada um controlando uma parte do stake) votam nos blocos que, na opinião deles, devem se tornar a próxima parte do ledger. Os próprios votos são transações da Solana e incluem o conceito de lockout. Sempre que um validador vota em um bloco no slot N, ele fica sujeito a um lockout. Se depois votar em um fork conflitante, poderá perder a capacidade de votar por algum tempo. 

Esses lockouts dobram exponencialmente a cada voto sucessivo no mesmo fork (1, 2, 4, 8... slots de lockout) e atingem o limite de 32 votos. Se um validador votou 32 vezes seguidas em um fork (o que significa que o bloco de 32 slots atrás ainda faz parte do fork mais pesado), esse bloco está em lockout máximo. Esse mecanismo incentiva os validadores a permanecer no fork majoritário e finalizar os blocos.

Confirmação (confirmação otimista)

Quando um bloco é produzido, os validadores transmitem votos para ele. Assim que uma supermaioria (≥66%) do stake vota em um bloco, os nós da Solana consideram esse bloco confirmado de forma otimista. Esse é o nível de compromisso Confirmed. Isso ocorre rapidamente, muitas vezes em um ou dois slots após o bloco, porque os votos se propagam por gossip. 

É importante observar que a implementação da Solana não exige que se espere até o bloco ser enraizado no ledger; ela confia no voto da supermaioria como um sinal otimista de que esse bloco acabará sendo finalizado (desde que menos de 33% do stake não se comporte de forma indevida). 

Por isso, o processo é chamado de confirmação otimista: sob as premissas normais de tolerância a falhas bizantinas (no máximo 1/3 desonesto), o voto de uma supermaioria significa que o bloco não será invalidado. Para um fork substituí-lo, mais de 33% dos validadores teriam de votar em uma cadeia alternativa, o que viola essas premissas.

Finalização (enraizamento de um bloco)

À medida que novos blocos continuam sendo produzidos e recebendo votos, cada bloco confirmado avança para uma posição mais profunda no fork. Quando um bloco acumula votos em 32 slots consecutivos depois dele, atinge o lockout máximo. Nesse momento, a rede enraíza o bloco, marcando-o como finalizado e irreversível. A finalização significa que o bloco está pelo menos 31 blocos atrás da ponta e nunca foi abandonado em favor de outro fork. Todos os nós passam a considerar esse bloco como parte do histórico imutável (o estado do ledger até esse slot fica congelado). 

Na prática, o compromisso Finalized corresponde, por analogia, a “o bloco tem ≥32 confirmações” em uma cadeia PoW, mas a Solana consegue isso por meio de votos com bloqueio temporal, e não por confirmações de prova de trabalho. A regra dos 32 slots é uma consequência do design do Tower BFT (lockouts dobrando até 2^32) e oferece uma garantia matemática de finalidade sob a premissa de tolerância a falhas de 1/3.

Escolha de fork e reversão

O consenso da Solana avalia os forks continuamente. Os validadores usam um algoritmo de seleção do fork mais pesado (com base no peso de votação do stake) para decidir sobre qual fork construir. Se um bloco for processado apenas por um subconjunto de validadores e não receber votos, outro fork poderá substituí-lo. É por isso que uma transação Processed pode ser descartada. 

Depois que um bloco é confirmado por 2/3, um fork alternativo precisaria ter mais de 1/3 do stake apoiando-o para vencer, o que é muito improvável e indicaria comportamento malicioso. 

Após a finalização, um fork que reverta esse bloco é essencialmente impossível sem uma falha catastrófica do consenso. Mesmo que a rede parasse ou sofresse um ataque, reverter slots finalizados exigiria coordenação fora das regras do protocolo.

Para resumir os mecanismos: Processed = bloco produzido (PoH), mas ainda sem votação ampla; Confirmed = os votos do cluster (Tower BFT) atingiram uma supermaioria no bloco (consenso otimista); Finalized = o bloco permaneceu como “raiz” da cadeia depois de muitos outros votos (finalidade absoluta do consenso). O design da Solana garante que blocos confirmados sejam finalizados após um curto intervalo, proporcionando confirmação rápida e, posteriormente, finalidade absoluta.

Casos de uso de cada nível de compromisso para desenvolvedores

Escolher o nível de compromisso adequado é essencial ao desenvolver na Solana. Diferentes aplicações têm diferentes requisitos de velocidade e certeza. 

Veja casos de uso comuns e práticas recomendadas para cada nível:

Use Processed para respostas imediatas e operações não críticas

Os desenvolvedores podem usar o compromisso Processed em cenários nos quais a velocidade é fundamental e algum risco de reversão é aceitável. Por exemplo, durante o desenvolvimento e os testes, talvez você queira uma confirmação instantânea de que uma transação foi recebida por um validador. 

Aplicações com interface de usuário (como carteiras ou jogos) podem exibir uma transação de forma otimista assim que ela for processada para melhorar a experiência do usuário (por exemplo, mostrando o estado “pendente”). 

No entanto, como não há garantia de que as transações processadas permanecerão no ledger, esse nível não é recomendado para fluxos críticos em produção. Se for usado, deve ser reservado para transações de baixo valor ou não críticas, nas quais uma possível reversão não causaria problemas graves.

Use Confirmed para a maioria das transações

O nível Confirmed geralmente é o padrão recomendado para muitos casos de uso na Solana. Ele oferece uma forte garantia de sucesso com impacto mínimo na latência. 

Por exemplo, uma aplicação DeFi realizando um swap de tokens ou um usuário transferindo fundos geralmente dependerá do status confirmed: depois que a transação for confirmada, a aplicação poderá tratá-la como concluída em condições normais. Esse nível reduz significativamente a possibilidade de uma transação ser descartada em comparação com Processed. A prática recomendada é usar o nível de compromisso Confirmed, especialmente ao consultar blockhashes recentes e enviar transações, pois ele oferece um equilíbrio melhor entre latência e segurança.

Use Finalized para transações críticas e de alto valor

Quando é necessária certeza absoluta, como em movimentações de ativos de alto valor, bridges entre cadeias ou confirmações de depósitos em corretoras, os desenvolvedores devem usar o nível de compromisso Finalized. Isso é comum em cenários nos quais até mesmo um risco mínimo de reversão é inaceitável. 

Por exemplo, uma corretora pode esperar a finalização de uma transação antes de creditar um depósito na conta de um usuário, evitando qualquer possibilidade de uma reorganização posterior desfazer o depósito. 

Outro uso ocorre após uma série de transações: você pode garantir que o estado final esteja finalizado antes de considerar uma operação complexa como concluída (por exemplo, em um processo de auditoria ou liquidação que exija o estado final do ledger). 

Os desenvolvedores devem estar cientes de que exigir um compromisso Finalized adiciona latência e, sob carga intensa na rede, pode aumentar a probabilidade de expiração da transação, pois você está efetivamente esperando que o hash de um bloco mais antigo seja finalizado. Finalized deve ser usado com cuidado, apenas nas transações mais críticas, quando a segurança adicional compensa a latência.

Em resumo, Processed é usado principalmente para respostas rápidas e fora de produção; Confirmed é a opção preferida para a maioria das operações, pois equilibra segurança e desempenho; e Finalized fica reservado para situações nas quais você realmente precisa de finalidade garantida apesar da espera. 

Muitas aplicações usam uma combinação: atualizam a interface em Processed, consideram a operação concluída em Confirmed e registram o resultado quando chega a Finalized.

Impactos na confiabilidade, no desempenho e na segurança das transações

A escolha do nível de compromisso tem consequências diretas para a confiabilidade (a transação permanecerá no ledger?), o desempenho (latência) e a segurança (risco de gasto duplo ou problemas de fork):

Confiabilidade

Níveis de compromisso maiores aumentam a confiabilidade de que uma transação foi registrada permanentemente. Uma transação finalizada tem confiabilidade próxima de 100% quanto à sua permanência no ledger (exceto em circunstâncias extraordinárias), enquanto uma transação confirmada tem confiabilidade muito alta, mas inferior a 100%, e transações processadas têm confiabilidade menor. 

Como observado anteriormente, cerca de ~5% das transações podem acabar descartadas quando se considera apenas processed (devido à alternância entre forks), enquanto confirmed reduz esse risco para quase 0%. 

Em aplicações críticas, usar o compromisso finalized elimina o risco de sua transação estar em um fork que será descartado posteriormente.

Desempenho (latência)

Existe uma compensação clara entre a rapidez com que você recebe uma confirmação e o nível de compromisso. 

A confirmação Processed é quase instantânea (dentro do tempo do bloco, muitas vezes em menos de um segundo). 

Confirmed adiciona um pequeno atraso (cerca de um ou dois slots, talvez ~0,5–1 segundo extra) para coletar os votos dos validadores. Ainda é muito rápido e, na prática, costuma ser imperceptível para os usuários. 

Finalized adiciona o maior atraso, pois a transação só será reportada como finalizada depois que aproximadamente 30 ou mais blocos subsequentes forem produzidos. Normalmente, são necessários ~10–20 segundos para atingir a finalidade. 

Durante períodos de congestionamento da rede ou produção lenta de blocos, esse atraso pode ser maior. Portanto, exigir um compromisso Finalized pode prejudicar a experiência do usuário e o throughput se usado em excesso. Se uma aplicação aguarda a finalização, ela precisa considerar esse tempo adicional. No entanto, isso não significa que a própria transação demora mais para ser executada on-chain; significa que o cliente espera mais tempo para garantir que ela foi finalizada. Enquanto isso, a Solana continua processando novas transações.

Throughput e expiração

Há um impacto sutil importante sobre a expiração de transações e o uso de blockhashes. As transações da Solana incluem um blockhash recente e são válidas por apenas ~150 slots após esse blockhash. 

Se você solicitar um blockhash finalized para assinar sua transação, esse blockhash será mais antigo (porque finalized fica atrás da ponta), e você terá menos slots restantes antes que a transação expire. Isso pode aumentar a possibilidade de expiração se a rede estiver congestionada e sua transação não for processada rapidamente. 

Usar um blockhash mais recente (Confirmed) oferece uma janela maior. A recomendação oficial é usar Confirmed para getLatestBlockhash, reduzindo o risco de expiração. 

Portanto, usar Finalized no preflight ou no blockhash pode reduzir ligeiramente o tempo disponível para sua transação ser selecionada, afetando a confiabilidade sob carga. 

Em resumo, um compromisso Finalized pode comprometer parte da vivacidade sob carga intensa: você ganha certeza, mas possivelmente ao custo de mais timeouts de transações quando a rede está perto de sua capacidade máxima.

Segurança

Do ponto de vista da segurança (por exemplo, prevenção de gasto duplo e proteção contra forks), Finalized é o mais seguro. 

Depois da finalização, reverter uma transação exigiria que mais de um terço do stake total agisse de forma maliciosa, o que provavelmente seria detectado e punido. 

Confirmed é muito seguro em condições normais (um invasor precisaria criar um fork conflitante e convencer mais de 33% dos validadores a apoiá-lo depois que uma supermaioria já tivesse votado, o que é extremamente improvável sem um grande ataque coordenado). 

No entanto, existe um cenário teórico em que, se alguns validadores (pouco menos de 33%) retivessem votos ou se um fork estivesse no limite, um bloco confirmed poderia ficar órfão. Porém, o design da Solana (confirmação otimista) pressupõe uma maioria honesta para evitar isso. 

Processed oferece a menor segurança: até que os votos sejam registrados, não há garantia de que qualquer outro validador sequer saiba da transação. Um líder malicioso poderia até incluir uma transação e depois não transmitir o bloco corretamente, entre outras possibilidades. 

Portanto, não se deve depender de Processed para nenhuma confirmação crítica para a segurança (ele funciona mais como uma “notificação” de que o processo começou). 

Em resumo: Finalized > Confirmed > Processed em termos de segurança contra forks e gasto duplo.

Uso do compromisso em leituras e gravações

Ao ler o estado da Solana (por exemplo, verificar o saldo de uma conta via RPC), você também especifica um nível de compromisso. Se usar o nível de compromisso Processed para uma leitura, poderá ver dados muito recentes, mas eles podem vir de um fork que não foi finalizado. Usar Finalized para leituras oferece consistência absoluta (o estado aceito por todos), mas os dados podem estar alguns slots atrasados. Na maioria dos casos, usar Confirmed para consultas de estado oferece um bom equilíbrio, assim como ocorre com as transações. Isso evita que você tome decisões com base em um fork que pode ser revertido. 

Para solicitações de gravação (ou seja, o envio de transações), o compromisso é relevante principalmente para determinar como a biblioteca cliente aguarda a confirmação. Um padrão comum é enviar uma transação com determinado preflightCommitment (que pode simular a TX com base no estado mais recente) e depois usar confirmTransaction com o mesmo nível de compromisso. Os desenvolvedores podem optar por aguardar uma confirmação finalized, se necessário.

Para apresentar números concretos: com base em medições recentes, a Solana processou uma transação em ~0,4 segundo, atingiu o estado confirmed em ~0,6 segundo e alcançou a finalização em ~13 segundos. 

Se sua aplicação — por exemplo, um aplicativo de pagamentos — não puder esperar ~13 segundos por transação, use confirmed, que ainda oferece segurança robusta. 

Se você estiver movimentando um valor alto entre cadeias, pode optar por esperar os ~13 segundos completos para ter certeza absoluta. Por outro lado, se estiver desenvolvendo algo no qual a velocidade é essencial e um pequeno risco é aceitável, como a atualização otimista de uma interface, poderá usar o status processed para oferecer uma experiência rápida ao usuário.

Conclusão

Os níveis de compromisso da Solana — Processed, Confirmed e Finalized — são um recurso essencial que permite aos desenvolvedores ajustar o equilíbrio entre velocidade e certeza para cada transação.

Processed fornece resultados imediatos, mas incertos; Confirmed oferece uma garantia quase final em um ou dois segundos (suficiente para a maioria das aplicações); e Finalized oferece finalidade absoluta após algum tempo adicional. 

Nos bastidores, esses níveis correspondem ao avanço do consenso da Solana: desde a produção de um bloco, passando pela votação de uma supermaioria, até seu enraizamento no ledger com lockout máximo.

Ao desenvolver na Solana, é essencial escolher o nível de compromisso adequado para cada tarefa:

• Use compromissos menores para respostas rápidas ou ações não críticas
• Use confirmed em operações padrão que exijam velocidade e segurança
• Use finalized nos casos em que nada além da finalidade total seja aceitável

Cada nível afeta a confiabilidade da inclusão da transação e o tempo de espera. 

Ao entender o significado técnico (66% dos votos, 32 blocos, forks e lockouts) e seguir as práticas recomendadas mais recentes, os desenvolvedores podem obter o desempenho prometido pela Solana sem sacrificar a consistência e a segurança de suas aplicações.

Recursos adicionais

• Documentação da Solana – Configuração do compromisso de estado, Tabela de status de compromisso
• Blog da Helius – Consenso na Solana (mecanismos de consenso e finalidade)