Como a Velas funciona: Proof of History, EVM e staking delegado

Para entender a Velas, pense em três blocos: um jeito rápido de ordenar eventos, um jeito de os validadores chegarem a acordo e um ambiente para rodar contratos inteligentes. A Velas herdou os dois primeiros da Solana e acrescentou uma camada de execução compatível com o Ethereum. Veja como as peças se encaixam.

Proof of History: um relógio para a rede

Em muitas blockchains, os nós perdem tempo discutindo o que aconteceu primeiro. A resposta da Solana é o Proof of History: uma cadeia de hashes em que cada etapa prova que passou algum tempo desde a anterior. Pense num cronômetro compartilhado, feito de matemática. Como todo nó consegue verificar a ordem em vez de negociá-la, os blocos saem em frações de segundo. A Velas herdou esse desenho do código da Solana, e por isso os tempos de bloco são curtos. Dá para acompanhar a altura do bloco atual no explorer nativo.

Tower BFT e a votação dos validadores

Ordenar não é o mesmo que concordar. Os validadores ainda precisam votar em qual bifurcação vale. O Tower BFT é o protocolo de votação, uma variação da tolerância a falhas bizantinas que usa o relógio do Proof of History para tornar cada voto progressivamente mais difícil de reverter. Cada voto prende o validador a uma bifurcação por um período crescente, então trocar de lado fica caro. Uma transação fica mais segura à medida que mais votos, ponderados pelo stake, se acumulam sobre o bloco dela.

Delegated proof of stake (dPoS)

Validadores precisam de stake para participar, mas você não precisa manter um servidor para ganhar uma fatia. Quem tem VLX delega as moedas a um validador de confiança. O validador vota com esse peso e fica com uma comissão das recompensas; o restante vai para os delegadores. Delegar não transfere a propriedade: suas moedas continuam na sua conta de stake e você pode redelegar depois. O site oficial mostra o número de validadores e o total em stake. Uma rede saudável tem muitos validadores, sem nenhum operador dominante. A página de validadores ensina a avaliá-los e o guia de staking mostra o passo a passo.

A EVM embutida

A Ethereum Virtual Machine é o ambiente que executa bytecode Solidity. A Velas embute uma ao lado do runtime nativo. Uma transação enviada a um endereço EVM é processada por esse lado, com os mesmos métodos JSON-RPC que as ferramentas do Ethereum esperam, como eth_getBalance. É por isso que carteiras como a MetaMask se conectam só com a configuração da rede. O RPC público do lado EVM é aberto, e o nosso rastreador o consulta direto do seu navegador. Veja os passos em compatibilidade EVM.

Dois mundos de endereços

Essa dualidade é ao mesmo tempo o diferencial e a curva de aprendizado. Se você só usa o lado EVM, ele se comporta como mais uma rede compatível com Ethereum. Usuários avançados e validadores é que lidam com o lado nativo.

Um exemplo prático

Imagine que você enviou VLX de uma corretora para a sua carteira. Se o saque foi para um endereço 0x, o rastro aparece no explorer EVM; se foi para um endereço nativo, aparece no explorer nativo. Procurar no explorer errado é a causa mais comum de "minha transação sumiu". Antes de entrar em pânico, confira o formato do endereço.

Onde entra a IA

Os materiais da Velas falam em delegated proof of stake com IA. Na documentação, isso aparece como apoio de aprendizado de máquina ao consenso, por exemplo na avaliação do comportamento de validadores, e não como um chatbot dentro da rede. Separamos o que é verificável do que é marketing no artigo sobre IA.

O que velocidade significa de verdade

"Até 75 mil TPS" aparece no site oficial. É um teto de projeto em condições ideais, não a carga média do dia a dia. Para o usuário, o que importa é outra coisa: quanto tempo até a transação confirmar e quanto ela custa. Em condições normais, ambos são bons na Velas. Veja números em taxas e velocidade e comparações em Velas x Solana.

Limites a ter em mente

Um código bifurcado precisa acompanhar as melhorias do projeto original, e a Solana evoluiu rápido desde o fork. A equipe da Velas mantém sua própria versão, então recursos e correções de segurança chegam no ritmo dela. A rede também depende de os validadores permanecerem online. Nada disso é sinal de alerta por si só, mas são motivos para conferir a atividade recente do projeto na documentação e na página de notícias antes de depender dele.

Como os blocos chegam ao usuário

Juntando as peças, o caminho de uma transação é simples de descrever. Você assina na sua carteira, a transação é enviada a um nó e repassada ao validador que produz o bloco naquele momento. O relógio criptográfico ordena o evento, os demais validadores votam e, conforme os votos se acumulam, a transação ganha mais certeza de que não será revertida. Do ponto de vista de quem usa, o que se vê é uma mudança de status no explorer, de pendente para confirmada.

Vale notar que o termo "confirmada" pode ter graus diferentes em redes derivadas da Solana, já que a certeza aumenta com o número de votos. Para pequenas transferências, a primeira confirmação costuma bastar; para valores altos, muita gente prefere esperar mais. Se você depende de uma corretora para creditar o depósito, é ela quem decide quantas confirmações exige.

Por que a arquitetura importa para o usuário comum

Pode parecer detalhe técnico, mas a arquitetura explica coisas do dia a dia: por que existem dois formatos de endereço, por que um explorer não encontra o que o outro encontra e por que a rede depende tanto de validadores sempre online. Entender isso evita os erros mais comuns de quem começa, como enviar para o formato errado ou procurar uma transação no lugar errado.