Velocidade de engenharia: por dentro da equipe de performance da Anza com Alessandro Decina

Introdução

O tecno-otimismo é, sem dúvida, o espírito cultural da Solana. A crença irrestrita em velocidade, progresso e inovação sem limites está por trás de cada pull request enviado para a mainnet. O mantra é IBRL: Aumente a largura de banda, reduza a latência. É, em partes iguais, uma imposição da engenharia, um símbolo de pertencimento cultural e uma prece secular. Se o Bitcoin é uma catedral dedicada à permanência e o Ethereum é uma ágora da neutralidade, a Solana é uma pista de corrida: um domínio de velocidade mecânica e mensurável.

Mas essa velocidade nunca desce dos céus em um diff perfeitamente comentado. Ela é extraída, lapidada e trazida à existência por quem ousa passar o dia inteiro olhando para código. Poucos fazem isso com mais afinco do que Alessandro Decina, originalmente um mestre do GStreamer que encarava buffers de vídeo engasgando como uma afronta pessoal. Hoje, ele lidera a equipe de performance de quatro pessoas da Anza, um time cuja ideia de “autocuidado” é eliminar barras amarelas de um trace de validator às 3h da manhã. O dia a dia deles consiste em analisar flame graphs, eliminar fluxos de trabalho inteiros e reescrever código de produção testado em batalha, porque tudo o que pode ser otimizado acabará sendo otimizado.

Eu queria entender o que significa viver nessa velocidade. Então, conversei com o próprio Alessandro Decina para descobrir como ele continua tornando a blockchain mais rápida que existe ainda mais rápida. A entrevista a seguir é uma autópsia da velocidade. Falamos desde os dias em que ele trabalhava com pipelines multimídia até as salvaguardas culturais que permitem que quatro engenheiros entreguem mais do que organizações inteiras.

A conversa foi editada e condensada para oferecer mais clareza e concisão.

Entrevista

Origens e visão de mundo

Ichigo: Voltando um pouco no tempo, seu primeiro amor foi o GStreamer e os pipelines multimídia. Quais foram as maiores lições sobre latência daquela época? O que a busca por áudio e vídeo em tempo real ensinou a você sobre reduzir milissegundos no Agave?

Decina: Primeiro, parabéns por me stalkear, haha. Trabalhei no GStreamer por uns 15 anos, talvez um pouco mais. Foi lá que aprendi literalmente tudo o que sei. Comecei a contribuir com o projeto quando ele era open source e estava apenas começando. E tive muita sorte, porque acabei me aproximando do fundador na época. O cara era, sei lá, 15 anos mais velho do que eu e era muito bom. Tipo, esse cara está na Wikipédia — provavelmente é inteligente. Não como eu, que finjo ser inteligente. O cara simplesmente decidiu: “É, tanto faz, vou ensinar de graça tudo o que sei para você.” E foi assim que comecei a trabalhar nisso.

É engraçado falarmos agora de baixa latência enquanto trabalhamos na Solana, porque isso não é baixa latência de jeito nenhum. Quando você fala de processamento de áudio, DPSs e hardware multimídia, o que fazemos na Solana tem uma latência altíssima. Se qualquer áudio ou vídeo tivesse um tempo de resposta de 400 milissegundos, estaria basicamente quebrado. Isso não funciona.

Em algum momento, comecei a trabalhar com drivers Linux e hardware que faz codificação e decodificação de vídeo e áudio. Muitas das coisas que faço hoje são basicamente iguais às que fazia naquela época. Quando você trabalha com hardware, latência significa que existe uma fila em algum lugar. Você encontra essa fila. Tenta minimizá-la, deixando-a o menor possível, e garante que ela nunca fique sem dados.

Por exemplo, o trabalho com XDP que estou fazendo agora é muito parecido com o funcionamento dos ring buffers de áudio. Até nesta chamada que estamos fazendo agora, há vários pacotes chegando fora de ordem. Existe um ring buffer em algum lugar reordenando todos eles, e você definitivamente quer garantir que ele não fique sem dados.

Parece que venho fazendo o mesmo trabalho há 20 anos.

O mesmo de sempre, só muda o dia, por assim dizer. Porque também notei que você trabalhou no Spotify e teve um pouco de Firefox —

Ahh, não, essa parte do Firefox foi apenas um trabalho de integração para um hackathon. Haha, sou tão velho que escrevi a tag de vídeo original do Firefox que usava GStreamer.

Caramba, haha. Então todos os caminhos levam de volta ao GStreamer?

O GStreamer realmente me ensinou programação multithread. É por isso que estou neste ecossistema. Há pessoas que escrevem Assembly e fazem todo tipo de hack de baixo nível. E eu penso: sim, faço isso há muito tempo. E aprendi que, a menos que você tenha uma linguagem com um sistema de tipos robusto e um bom compilador, acaba dando um tiro no próprio pé. Tenho certeza de que dá para tornar algo ligeiramente mais rápido com Assembly, mas eu realmente quero Rust.

Quero que o compilador Rust me diga: você é um idiota — isso não vai funcionar porque há um bug aqui. Antes do Rust, eu sentia que era 10% engenheiro de software e 90% depurador de carne e osso. Eu só ficava depurando coisas. Então, acho que o GStreamer e meu amor por Rust são os motivos pelos quais comecei a trabalhar na Solana. Rust estava ganhando popularidade, não havia muitos empregos que permitissem trabalhar com isso em tempo integral, e eu havia decidido que só trabalharia com Rust.

Estou velho demais para escrever C. Não quero uma linguagem sem segurança de memória. Não quero perder meu tempo. Então, é isso, aqui estou.

Muito bom. Quando você fez a transição, tinha alguma concepção equivocada sobre sistemas descentralizados antes de trabalhar no código de validator? O que convenceu você de que a arquitetura da Solana realmente poderia escalar?

Na verdade, acabei entrando na Solana quase dois anos tarde demais porque estava ocupado trabalhando no compilador Rust. Alguém da Solana que estava começando a trabalhar na máquina virtual enviou um e-mail dizendo: “Ah, estou fazendo a mesma coisa. Parece que você está um pouco mais avançado, venha trabalhar conosco.” Não respondi porque analisei o Bitcoin e depois o Ethereum e percebi que era possível executar coisas, mas você tinha 10 TPS. Não parecia um projeto sério, certo? Não dá para fazer nada do mundo real com 10 TPS.

Então, quando recebi esse e-mail, não respondi. Só pensei: certo, esse pessoal de cripto ainda não está falando sério.

Toly entrou em contato dois anos depois, e eu conferi o preço do SOL. Pensei: certo, eu deveria ter aberto aquele e-mail, haha. Dessa vez, acabei conversando com ele. Antes da conversa, ele me mostrou um código. Eu olhei e, para ser sincero, o código era horrível. Era um código Rust muito ruim.

Mas depois conversei com Toly sem pesquisá-lo no Google, então não fazia ideia de quem ele era. Ele era inteligente e disse todas as coisas certas. Disse que estávamos construindo aquilo. Naquele momento, fazíamos de determinada forma. Obviamente, não era o estado da arte, mas a ambição era escalar junto com o hardware. Construiríamos a blockchain de melhor performance e, então, o gargalo passaria a ser o hardware. A ideia era que, quanto mais hardware você acrescentasse, mais aquilo escalaria.

E isso me convenceu. Parecia que não era apenas um bando de fanáticos por blockchain se masturbando com a ideia da Terceira Guerra Mundial… Eu me interesso pela tecnologia. Sou uma das poucas pessoas de cripto que realmente estão nisso pela tecnologia.

A Solana tem essa cultura de engenharia em que a tecnologia é fortemente influenciada pelo tecno-otimismo — toda aquela cultura de Aumentar a largura de banda, reduzir a latência. Como você vê isso pessoalmente? Como isso influencia o dia a dia na Anza?

Para mim, o Ethereum tem, fundamentalmente, uma mentalidade de escassez. Eles pensam: certo, encontramos algumas barreiras e vamos buscar formas de contorná-las. Vamos inventar toda essa infraestrutura para lidar com o que, em essência, são lacunas de conhecimento que temos e que sentimos ser impossíveis de corrigir, certo?

Já nós, sinto que somos o oposto. É como: certo, existe um problema. Não existem problemas insolúveis, exceto aqueles que violam as leis da física. Essa é simplesmente uma enorme diferença cultural.

Se algo está quebrado, apenas dizemos: certo, vamos sentar. Vamos analisar um pouco e entender quais são os problemas. Vamos conversar com os traders e os formadores de mercado. Vamos descobrir quais são os problemas deles. Recentemente, encontramos alguns problemas muito concretos. E corrigimos a maioria. Sinceramente, em dois ou três meses, podemos corrigir todos eles.

Há muitas coisas que não funcionam hoje na Solana. Sabemos quais são e nunca paramos para dizer: “Temos a solução perfeita! E agora, para avançar, precisamos inventar algo novo ou pesquisar e fazer outra coisa.” Não — são problemas concretos. A maioria deles é realmente idiota.

E não tivemos nenhuma interrupção recentemente. Pessoalmente, acho que isso é um sinal baixista, certo? Porque algumas pessoas começaram a ficar um pouco conservadoras. Sabemos que podemos ir muito mais rápido. Sabemos que podemos ter blocos de 100 milhões de CU amanhã, certo? Só precisamos fazer algumas coisas em modo speedrun. E eu sou a favor de fazer speedrun de tudo.

Fundamentalmente, sabemos — não precisamos de um roadmap para saber — que podemos multiplicar a performance atual por dez. Vemos como fazer isso. Sabemos como fazer. Ou já escrevemos o código e ele ainda não está totalmente pronto, ou já escrevemos o código e não podemos implantá-lo porque ainda há alguns casos extremos que precisam ser corrigidos. Mas sabemos exatamente o que fazer.

Sabemos como escalar isso.

Engenharia de performance

Falando do trabalho de performance, acho que muita gente realmente não sabe que a Anza tem uma equipe dedicada a isso. Ela passa meio despercebida. Conte um pouco sobre a estrutura da equipe. Como ela se diferencia das outras equipes de engenharia da Anza?

Certo, temos equipes diferentes na Anza. Temos o pessoal de consenso, que agora está concentrado no Alpenglow. Temos o pessoal de redes, focado principalmente no Gossip. Há o pessoal do AccountsDB, que basicamente só trabalha no banco de dados de contas. Há a equipe de produção de blocos, que trabalha no scheduler. E, claro, todas as outras equipes das quais estou me esquecendo.

A diferença da equipe de performance é que trabalhamos em tudo. Fazemos profiling, encontramos um gargalo e perguntamos às equipes relevantes se elas têm tempo e conhecimento especializado porque, às vezes, encontramos problemas que nem todo mundo consegue corrigir. Por exemplo, quem trabalha com consenso não é necessariamente a melhor pessoa em programação de baixo nível, porque sua especialidade está em outro lugar. Nesses casos, normalmente entramos e corrigimos o código para eles.

Portanto, não trabalhamos apenas em uma coisa. Simplesmente encontramos o próximo gargalo. Sincronizamos aproximadamente a cada duas semanas e decidimos onde estamos, o que precisamos fazer em seguida e como tornar a próxima versão mais rápida.

Outra grande diferença é que a Anza costuma contratar pessoas inteligentes. Se você não conhece Rust, tudo bem. Se não conhece programação de baixo nível, tudo bem. Presumimos que, se você é inteligente, podemos ensinar a maioria dessas habilidades durante o trabalho. Para a equipe de performance, costumo contratar pessoas que realmente tenham experiência com o kernel ou outras coisas de baixo nível, por causa do tipo de gargalo que estamos encontrando agora.

Por exemplo, no banco de dados de contas, há alguns problemas algorítmicos que precisamos corrigir. Mas*,* o motivo pelo qual, na versão 2.3, o banco de dados de contas está cerca de dez vezes mais rápido do que há dois meses é que simplesmente corrigimos a forma como ele faz I/O. E você precisa saber como isso funciona para torná-lo mais rápido. Se você tem apenas um entendimento de alto nível sobre bancos de dados, não sabe realmente como os discos funcionam e não precisa saber como o kernel agenda solicitações de I/O.

Então, pessoalmente, para a equipe de performance, costumo contratar mais pessoas de baixo nível. Mais uma vez, nem me importo se elas conhecem Rust, mas quero que tenham trabalhado com C ou C++ em outras coisas de nível mais baixo.

O motivo de não ser muito conhecido que existe uma equipe de performance é que basicamente começamos em dezembro. Fui contratado originalmente para trabalhar no compilador, mas migrei para performance por volta da interrupção de março de 2024 e comecei a otimizar as coisas. As pessoas não ficaram muito felizes porque um dia eu simplesmente disse que trabalharia no que quisesse. Então, sim, haha, elas não ficaram felizes, mas depois tivemos resultados muito bons. Então vieram até mim e disseram: “Certo, pensando bem, você quer contratar mais pessoas para fazer isso?” Em dezembro, oficializamos a iniciativa de performance e criamos a equipe.

Para ser sincero, sou parcial, mas a equipe de performance é, sem dúvida, a melhor equipe da Anza.

Não duvido, haha. Quantas pessoas fazem parte da equipe?

Somos quatro em tempo integral, mas tenho feito piadas no Twitter sobre Brooks e algumas outras pessoas entrarem porque comecei a compartilhar meu profiler mais amplamente. Até cerca de dois meses atrás, apenas o pessoal de performance tinha acesso ao profiler. Agora, todos têm. Por exemplo, desde que dei o profiler ao Brooks, ele faz mais trabalho de performance do que eu, haha. Ele ficou completamente viciado. Agora só fica tornando tudo mais rápido.

Então, extraoficialmente, agora temos Brooks e alguns outros caras que também fazem bastante coisa de performance. Mas somos quatro trabalhando nisso em tempo integral.

Ao trabalhar com performance, que “indício” você procura durante o profiling e que a maioria dos engenheiros não perceberia? Como decide o que precisa ser otimizado?

Há algumas coisas realmente óbvias. Quando comecei a analisar o Agave, por exemplo, passávamos muito mais tempo dentro do kernel do que executando código no espaço do usuário, o que é ridículo. Não somos um tipo de aplicação de baixo nível. Se fôssemos um framework multimídia, faria sentido fazer a maior parte do trabalho no kernel porque, no fim das contas, você precisa enviar as amostras para o hardware. Mas o único trabalho realmente de baixo nível que fazemos é o Turbine.

Normalmente, o maior indício quando começo a fazer profiling é ver muito amarelo nos meus flame graphs, porque isso significa que estamos passando tempo demais no kernel. Provavelmente quer dizer que alguém está usando alguma API de alto nível que parece inofensiva, mas que, por baixo dos panos, é simplesmente atroz em termos de performance.

No último ano, reduzimos em cerca de dez vezes a quantidade de memória usada pelo Agave porque, em geral, encontramos sempre o mesmo problema. Quando você faz alocações de memória demais, em algum momento precisa começar a interagir com o kernel. É possível ver essa interação no profiler. Você olha e pensa: certo, de onde isso vem? Percebe que essa cadeia fica debulhando a memória o tempo todo. Você rastreia tudo até o ponto em que há rotatividade e alocação excessiva de memória e corrige o problema.

Há algumas coisas mais difíceis. Por exemplo, encontramos um problema fundamental de design que estou corrigindo. Como se sabe, a Solana usa pipelines e tem diferentes estágios, e tudo deveria ser paralelizado para que as coisas fossem executadas simultaneamente.

Na prática, devido à forma como tudo foi arquitetado, temos um design de pipeline, mas também temos muitas interrupções nesse pipeline. Portanto, temos diferentes estágios, mas não maximizamos o throughput de todos eles por causa de bugs idiotas de design que introduzem latência em diversos pontos. Essa latência é aquilo de que as pessoas normalmente reclamam quando não conseguem enviar transações ou quando dizem que há jitter no sistema. Esse jitter não é causado por nada fundamental nem pelo hardware — somos apenas nós fazendo as coisas de forma abaixo do ideal.

Mas, para ser totalmente franco, os tipos de coisa em que trabalhamos são idiotas. Há alguns bugs extremamente óbvios, e estamos simplesmente corrigindo esses bugs óbvios.

Como você decide se esses bugs justificam microbenchmarks ou uma reprodução completa do tráfego da mainnet?

Acho que a maioria dos problemas de performance que temos vem do fato de que as pessoas escreveram microbenchmarks. Tornaram os microbenchmarks mais rápidos. Testaram cada um isoladamente. E então, quando você junta tudo no Agave, nada funciona como nos microbenchmarks.

Então, pessoalmente, digo às pessoas: não usem microbenchmarks para absolutamente nada. Até mesmo reproduzir transações é algo que fiz talvez três vezes no último ano. Porque, mesmo quando você reproduz o tráfego da mainnet, não o reproduz exatamente na mesma velocidade que teria ao executar de fato o tráfego da mainnet, então muitas coisas mudam.

E isso é parte do motivo pelo qual estamos tornando a inicialização muito mais rápida, porque, caso contrário, é irritante ter que esperar meia hora toda vez que você quer ver se a sua correção funciona.

Quando você chega ao estágio em que estamos com o Agave, não pode mergulhar em uma toca de coelho por causa de apenas um componente. Talvez seja um trabalho intelectualmente interessante, mas é completamente inútil sem considerar o sistema inteiro. Isso não promove nenhum avanço real.

Então, ao analisar o sistema inteiro, por que reescrever o Turbine para usar XDP é algo tão importante?

Eu trabalhava com redes logo antes da Solana. Estava em uma startup que faz inspeção profunda de pacotes. Basicamente, ela intercepta todo o tráfego que chega a uma NIC, analisa em tempo real para interromper fluxos maliciosos e depois o reinjeta no kernel. Basicamente, havíamos escrito uma pilha TCP e UDP inteira no espaço do usuário usando Rust, Tokio e, claro, XDP.

Quando entrei na Anza, era óbvio que, em algum momento, precisaríamos usar XDP. Quando o Firedancer começou, eles disseram: “Vamos começar com uma implementação do Turbine em XDP”, e eu disse que era idiota. Não fazia sentido. Leva muito mais tempo fazer isso porque XDP é objetivamente uma API terrível. Portanto, você quer evitar usá-la pelo máximo de tempo possível, até que as rodas literalmente se soltem.

Então você pensa: ah, [censurado], agora preciso usar XDP, que foi o que aconteceu conosco. Estávamos trabalhando para eliminar todos os outros gargalos do pipeline até o dia em que começamos os testes de carga e vimos o Turbine parar completamente de funcionar.

Então pensamos: certo, isso claramente não é mais viável. E eu realmente me esforcei muito para não usar XDP porque já o havia usado e sabia como era horrível. Tentei criar uma implementação do Turbine baseada em io_uring. Então encontrei alguns bugs no io_uring. Comecei a corrigir esses bugs. Ainda tenho alguns patches de kernel que quero enviar, mas, em algum momento, percebi: certo, não posso dizer a todos os nossos operadores de validator que usem meu kernel personalizado para executar a Solana.

Vou ter que usar XDP, e foi o que fizemos. Agora funciona.

A resposta é: você encontra o próximo gargalo e o corrige. E continua corrigindo todos os gargalos que encontra. Você pode pensar nos problemas de amanhã quando o amanhã chegar. Esse é o meu lema. Você poderia se preocupar apenas com o amanhã, mas o presente seria uma droga. O presente é uma droga na Solana. Os blocos são pequenos demais, o Turbine acrescenta latência demais, o scheduler ainda tem problemas. Precisamos corrigir as coisas hoje. Caso contrário, não haverá amanhã para avançarmos tão rápido.

Como vocês se protegem contra regressões de performance? Como se coordenam com o Firedancer?

Regressões de performance são uma luta. Pessoalmente, faço profiling de alguma coisa no Agave todos os dias, pelo menos algumas vezes por dia, e frequentemente temos regressões porque escrever código performático é um trabalho. Você precisa saber escrever código performático. Se escrever código Rust, ele será, em média, mais performático do que código Node.js, Python ou qualquer outra coisa. Mas se você trabalha, por exemplo, no AccountsDB, onde lida com coleções de milhões de itens, não pode simplesmente escrever código. É difícil criar algoritmos e trabalhar com grandes conjuntos de dados de forma eficiente.

Então, ocasionalmente temos regressões. Até cerca de um mês atrás, eu basicamente gritava com todo mundo, haha. No caso do Brooks com o AccountsDB, acho que em algum momento ele me odiou. Temos uma ótima relação, mas, até um mês atrás, basicamente metade das nossas interações era eu gritando com ele porque alguma coisa estava mais lenta no AccountsDB.

Para o protocolo, trabalhar com o Firedancer melhorou isso porque sinto que muitas partes do protocolo acabaram crescendo organicamente em resposta a diferentes desafios. O desenvolvimento do protocolo começou com uma ideia; eles a colocaram em produção e, como acontece com a maioria das ideias, ela não funcionou de primeira. Então começaram a acrescentar coisas por cima. Muitas dessas coisas eram ideias realmente ruins em termos de performance.

Por exemplo, no Gossip, havia algo chamado epoch slots, com o qual o cluster basicamente transmitia para todos quais validators tinham visto quais slots. E, casualmente, seis meses atrás, enquanto analisava outra coisa, notei que esse recurso de epoch slots consumia mais tempo de CPU do que a execução das transações. Em termos de largura de banda, consumia quatro vezes mais do que o Turbine. Era apenas um patch aleatório construído sobre o protocolo em algum momento para mitigar um problema.

Então, isso não acontece mais. E é, em parte, graças ao Firedancer. Agora, quando alguém faz uma proposta, precisamos trabalhar com o Firedancer. Obviamente, eles estão criando outro cliente, haha, então precisam planejar o trabalho. Precisam decidir quanto tempo levaria para implementar a proposta. Qual é a prioridade disso? Então eles questionam, para o bem ou para o mal, muitas ou quase todas as mudanças que fazemos. E são muito bons em contestar mudanças realmente ruins.

Quando o Turbine for lançado com XDP, se você tivesse um mês sem reuniões nem conflitos, com liberdade total para trabalhar no que quisesse, qual seria a primeira parte do Agave que você otimizaria ou cuja arquitetura reformularia?

Eu realmente quero — literalmente sonho com isso — reescrever o AccountsDB há uns dois anos. Só sei que, se começar, isso vai consumir literalmente um ou dois meses da minha vida. E, neste momento, não é a melhor forma de usar meu tempo. Mas vou fazer isso. Continuo tentando pressionar o Brooks a fazer, mas, se ele não fizer, eu farei em algum momento.

Desenvolvimentos futuros

Olhando para o futuro, com recursos planejados como Async Execution ou Multiple Concurrent Leaders, qual seria a maior dor de cabeça para a equipe de performance?

Instintivamente, odeio async. O modelo atual é muito simples. Você recebe algumas transações, faz o replay delas muito rápido e depois vota. Conceitualmente, é muito fácil. Async torna o design mais difícil, mas também melhora muito a experiência real de usar a chain.

Também odeio o design do Multiple Concurrent Leaders, haha. Entendo que, principalmente se você quiser fazer trading de alta velocidade, precisa de vários líderes. Não há alternativa. Mas, pessoalmente, isso não acontecerá por pelo menos 12 meses. Então não quero me distrair demais.

É importante que tenhamos Alpenglow em um ano, mas também é importante chegarmos a cem milhões de CUs no próximo mês. Precisamos nos concentrar em tornar rápido o que temos agora, porque Alpenglow é código novo e Multiple Concurrent Leaders é código novo. Há incógnitas desconhecidas. Digamos que, por qualquer motivo, o Alpenglow acabe atrasado como o Firedancer. E então? Continuaremos com a chain lenta e de merda que temos agora? Não, precisamos nos concentrar em ser rápidos hoje.

Conselhos sobre engenharia de performance

Quais recursos você recomendaria para alguém com experiência em Rust que queira começar a programar com foco em performance e fazer profiling?

Primeiro, recomendo usar um bom profiler, algo que não existe hoje, haha. Mas espero lançar o meu em breve. E realmente acho que a melhor forma de aprender qualquer coisa é praticando em algo com que você realmente se importa.

Então, meu conselho para quem quer aprender a trabalhar com performance é encontrar um software que usa todos os dias e adora, fazer profiling e torná-lo mais rápido, porque muitos softwares são muito lentos. Até muitos softwares rápidos podem ficar muito mais rápidos. Os computadores são realmente rápidos. E, por serem tão rápidos, é muito fácil fazer algo lento sem nem perceber.

A forma como vejo muitas pessoas ficarem viciadas nisso é encontrando algo que usam e fazendo profiling — torne-o mais rápido, envie pull requests e garanto que eles serão aceitos. Você vai ficar completamente viciado.

O kernel é apenas mais uma dependência. Quando você trabalha em algo e usa uma biblioteca, é provável que, em algum momento, precise examinar a biblioteca se algo não funcionar, estiver lento ou qualquer outra coisa. O kernel é apenas mais uma biblioteca. Então,, leia o código do kernel. O código do kernel é um dos mais simples que já vi. Se você olhar o scheduler do kernel, conceitualmente, ele é mais simples do que o scheduler que temos na Solana.

Mas vá ler o código do Linux. É C, não é o ideal, e qualquer coisa que mexe com hardware costuma ser amaldiçoada, haha, mas a maior parte da Solana não trabalha diretamente com o hardware. Encontre coisas genéricas que você usa todos os dias, como uma syscall, Tokio ou código de sistema de arquivos. É muito fácil. Apenas leia. Se passar uma semana lendo, você aprenderá como faria com qualquer outro código. E vai se sentir um gênio do caralho. Vai pensar: ahh, agora consigo trabalhar no kernel, sabe?

Qual é a melhor forma de começar a contribuir hoje?

Minha preferência é entrar no Discord e acessar o canal de desenvolvimento do Discord da Solana Tech. Por exemplo, há um cara que vem trabalhando em algumas coisas de rede e que, outro dia, simplesmente começou uma conversa sobre o código da TPU. E, para ser sincero, ele entende melhor como esse código funciona do que a maioria das pessoas na Anza. Você pode contribuir. E, se for tão bom quanto esse cara e me enviar patches, vou fazer o merge deles.

Não fazemos muito desenvolvimento interno e fechado. Então, se você não vir um pull request em um trecho de código que considera lento, que conhece bem,, e quiser corrigi-lo, fale comigo no Discord. Criaremos uma issue, atribuiremos a você e você fará a correção.

Quero que as pessoas me enviem patches. Realmente quero expandir nossa comunidade por meio do envio de patches.

Perguntas rápidas

Qual foi o bug mais difícil que você eliminou este ano?

Uma compilação incorreta de um código de ponto flutuante que estava bloqueando a versão 2.2 há apenas alguns meses. Não foi o mais difícil, mas foi o mais tedioso, porque precisei passar dias apenas lendo código Assembly.

Que música você ouve repetidamente enquanto analisa flame graphs?

Normalmente house ou techno minimalista. Stephan Bodzin costuma ficar no repeat.

Qual é a sua distribuição Linux favorita?

Debian, com certeza. É a única que não é extremamente irritante, haha.

Qual é a melhor otimização que virá com o Alpenglow?

Não vamos executar votos. As transações de voto são [censurado]. E é muito bom que todo esse processo de votação não use mais transações.

O que você acha de ZK?

É uma ótima tecnologia, mas sinto que ainda está muito na fase de pesquisa para escalar blockchains. Então, não tenho muito interesse.

Julho de 2026, daqui a um ano: qual é a sua previsão para o tempo de slot?

Pessoalmente, e espero que seja antes disso, quero ter slots de 200 milissegundos. Vivo dizendo ao Toly que ele precisa transformar isso em meme até que se torne realidade. Então, espero que já tenha acontecido até lá. Acho que conseguimos fazer isso até hoje. Considero que seria o mínimo, no sentido de que qualquer valor acima disso seria um fracasso, mas podemos chegar abaixo disso.

Quando o Agave atingirá o fatídico milhão de TPS?

Haha, não vou dar uma resposta rápida para essa. Vivo perguntando às pessoas: “De onde virá esse milhão de transações?”

Chegaremos a um milhão de TPS quando as pessoas tiverem um milhão de TPS para enviar, mas infelizmente não acho que isso acontecerá tão cedo. Eu disse que, se o Agave não chegar a um milhão de TPS até outubro, pedirei demissão. Então talvez eu tenha que improvisar uma demo enganosa, haha.

Conclusão

Alessandro Decina representa o coração pulsante da cultura de performance da Solana — uma busca incansável por velocidade, fundamentada em engenharia pragmática, e não em perfeição teórica. Sua equipe de performance entrega muito mais do que seu tamanho sugeriria, encontrando e corrigindo os “bugs idiotas” que, juntos, se acumulam e causam lentidões sistêmicas.

Em um mundo no qual muitas equipes se perdem em grandes visões arquitetônicas, a equipe de performance da Anza mantém o foco absoluto nos gargalos que estão diretamente à sua frente. Analisar, identificar, corrigir, repetir. É um trabalho sem glamour que produz resultados impressionantes: uma blockchain que realmente escala com o hardware, em vez de contorná-lo.

A conversa acima revela uma verdade fundamental sobre a construção de sistemas de alta performance: velocidade não depende apenas de algoritmos inteligentes ou hardware de ponta. Ela exige um compromisso cultural de nunca aceitar o “bom o bastante” quando o “excelente” é tecnicamente possível. Para a Solana, isso significa que slots de 200 milissegundos, Async Execution, Multiple Concurrent Leaders e mais de um milhão de TPS sustentados não são apenas marcos técnicos — são inevitáveis.