Foguetes, ameaças quânticas, zeros e uns: Dean Little e a forja da verdade da Solana

Introdução

Blockchains são construídas sobre mentiras. Ou melhor, mentiras educadas, manifestadas em camadas de abstração. Há um mundo que o desenvolvedor vê, repleto de SDKs, APIs e frameworks que prometem velocidade e segurança. A realidade é muito mais complexa, cheia de registradores, syscalls e bytecode — uma realidade na qual apenas os mais obstinados ousam entrar. Na prática, toda abstração gera overhead, e todo compilador esconde a verdade.

Dean Little passou a carreira navegando por essas mentiras, buscando a verdade ao soldar circuitos e gravar EEPROMS. Com Bitcoin, ele criou pools de mineração, kernels de GPU e ferramentas de SPV, mantendo-se o mais próximo possível da máquina e conhecendo o potencial dos sistemas distribuídos, que na época nunca conseguiam entregar tudo o que prometiam. Então, ele encontrou a Solana, onde é conhecido por sua heresia: escrever assembly à mão, desrespeitar compiladores e abusar de syscalls — não porque seja divertido, mas porque velocidade é verdade.

Como cientista-chefe da Zeus Network, ele implementou do zero todo o protocolo do Bitcoin sobre a Solana, permitindo o fluxo contínuo de liquidez em BTC. E, em uma demonstração à prova de trolls contra o FUD quântico, desenvolveu um cofre de assinaturas únicas de Winternitz capaz de migrar dezenas de milhares de ativos por segundo, enquanto outros apenas sonham em chegar a seis.

Mas Dean também é professor. Da Turbin3 à Blueshift e ao seu trabalho recente em DevRel para a equipe de mercados de mandarim e cantonês da Solana Foundation, ele conduz desenvolvedores a um mundo que a maioria jamais verá. Ele ensinou centenas de desenvolvedores a lançar projetos on-chain, muitas vezes em seus próprios idiomas e começando do zero. Sua tensão é constante: elevar as pessoas com abstrações e depois empurrá-las para baixo, em direção à máquina.

Eu queria entender o que significa viver nessa tensão — entre educação e experimentação, abstração e assembly, escrever código para humanos e escrever instruções para máquinas. Esta entrevista trata desse diálogo e do que significa falar diretamente com a máquina quando todos os outros falam sem realmente se comunicar com ela.

Esta conversa foi editada e condensada para maior concisão.

Entrevista

Origens e visão de mundo

Ichigo: Muito antes da Solana, você consertava hardware, gravava EEPROMs e escrevia sistemas de controle embarcados para foguetes. Como trabalhar tão próximo do hardware — literalmente com ferros de solda e firmware — moldou sua visão de mundo como criador?

Dean Little: Aprendi a soldar quando tinha cerca de dez anos. Cresci mexendo com microprocessadores e microcontroladores, depois passei para o desenvolvimento web e mobile, até finalmente entrar em uma startup de foguetes na Noruega.

Trabalhar com sistemas embarcados críticos ensina algumas coisas realmente importantes. A primeira é a atenção aos detalhes — porque, se algo falhar, tudo pode dar muito errado muito rápido. A segunda é a simplicidade: sistemas simples, rápidos e fáceis de entender geralmente são melhores do que algo excessivamente complicado. E a terceira é pensar de forma adversarial.

Para mim, trabalhar nos controles de lastro de foguetes oceânicos significa perguntar constantemente: o que acontece se este controlador falhar? Como detectamos a falha? Quais redundâncias temos? E se nosso controle de atitude estiver errado e acharmos que estamos apontando para cima quando, na verdade, estamos apontando para baixo? Isso força você a projetar para a falha, em vez de presumir que tudo sempre funcionará.

Outra coisa que você aprende é a não confiar cegamente no trabalho dos outros. Isso se aplica a software e hardware. Fabricantes de hardware mudam especificações, o setor de compras pode adquirir a peça errada por acidente e, de repente, nada funciona. Há tantas coisas que podem dar errado, e basta um pequeno erro para todo o sistema falhar. Essa mentalidade permanece comigo desde então.

A partir daí, sua carreira rapidamente levou você ao Bitcoin. Você trabalhou com pools de mineração, kernels de GPU, ferramentas de SPV e, mais tarde, com a Twetch. O que esses anos trabalhando na infraestrutura do Bitcoin ensinaram sobre a criação de sistemas distribuídos em escala e sobre as limitações das blockchains naquela época?

Comecei a trabalhar em tempo integral com desenvolvimento de Bitcoin por volta de 2017. Desenvolvi em várias blockchains — Bitcoin, EOS e algumas outras que eram populares na época. Comecei apenas usando Bitcoin, mas, quando as taxas dispararam, ele basicamente se tornou inutilizável. Aquela foi a primeira grande onda do varejo entrando em cripto, e percebi que, quando as taxas disparam, a blockchain se torna inútil.

Essa experiência me fez repensar o chamado “trilema da escalabilidade”. Sinceramente, é um problema inventado e sem sentido. Mesmo em 2017, conseguíamos enviar fotos de 4 MB para qualquer lugar do mundo em menos de um segundo. Parecia ridículo acreditar que blockchains não poderiam escalar além de blocos de 1 MB. A limitação não era a física — era o design.

Como a camada base do Bitcoin é tão restrita, você é obrigado a inovar de outras formas. Acabei mergulhando profundamente em Secp256k1 e criando soluções para ocultar resultados de execução em assinaturas. Era uma espécie de computação verificável rudimentar, muito antes de ZK realmente começar a ganhar força.

Esses anos me ensinaram que administrar uma empresa de Bitcoin é, na verdade, administrar uma empresa de infraestrutura. O protocolo do Bitcoin consegue fazer muita coisa, mas o software do node é limitado. O modelo UTXO é ótimo para paralelização, pois o estado é segregado, assim como nas contas da Solana, mas é péssimo para estado compartilhado e indexação. Por outro lado, o modelo de contas da Ethereum é ótimo para estado compartilhado, mas péssimo para paralelização. O que fez sentido para mim na Solana foi seu modelo de contas segregadas — ele combina a paralelização do UTXO com a usabilidade do modelo de estado global da Ethereum.

Minha principal conclusão desses anos foi que sistemas falham com frequência e, portanto, devem ser projetados para falhar de forma controlada, não catastrófica. Você nunca deve simplesmente aceitar limitações. Deve desafiá-las de maneiras criativas nas quais as pessoas ainda não pensaram. Essa é a filosofia que levei para o meu trabalho na Solana.

Hoje, muita gente na comunidade Solana conhece você como o cara que escreve assembly e desrespeita compiladores. Por que permanecer tão próximo da máquina? Por que não se concentrar mais em melhorar abstrações de alto nível, já que é nelas que a maioria dos desenvolvedores vai criar?

Ao contrário do que muitos acreditam, contribuo para o Anchor, o Pinocchio, o Agave, o Alpenglow — basicamente tudo. Trabalhei com criptografia, SIMDs e programas de baixo nível em toda a stack.

A principal questão no desenvolvimento da Solana é que tudo fora dos programas on-chain e da infraestrutura exige permissão. É quase impossível conseguir que meus PRs sejam incorporados a qualquer repositório oficial. Mas programas on-chain? Posso fazer tudo o que o sistema acidentalmente permitir. Nada me impede nesse espaço. Ele não exige permissão. Posso continuar melhorando tudo e mandando muito bem.

Então, a questão é: se você olha para o meu trabalho, vê a qualidade dele e o que fiz pelos programas on-chain, e quer que isso aconteça em outras camadas da stack, comece a incorporar meus PRs, haha.

Quanto ao assembly, francamente, o compilador faz um trabalho péssimo, e as pessoas que trabalham nele não estão fazendo muito melhor. Elas nunca dedicaram tempo para realmente ouvir seus clientes finais, que são os desenvolvedores. Por isso, tivemos que criar nossa própria toolchain independente para facilitar nossas vidas.

Infelizmente, a maioria dos devs é meio mediana. Não digo isso de uma forma ruim, mas eles não são como Cavey, eu ou os feras da Ellipsis DeFi, que realmente sabem escrever coisas de altíssimo desempenho. Somos esse pequeno e estranho subconjunto de devs que sabe levar o sistema ao limite no nível mais baixo e torná-lo melhor para todos os outros.

Nosso feedback poderia ser extremamente valioso, mas, na maioria das vezes, não é levado a sério. Então, acabamos inovando naquilo que ninguém pode nos impedir de tocar — e isso é a VM. É por isso que, nesse aspecto, permaneço próximo da máquina.

Inovações e contribuições técnicas

Falando sobre trabalhar em diferentes partes da stack — entre Zeus, Jupiter e seu tempo livre —, você criou e integrou alguns primitives criptográficos avançados. Criar qualquer tipo de criptografia on-chain sempre foi notoriamente difícil na Solana. Como será o futuro da criptografia na Solana? E, além de gritar para que as pessoas incorporem os PRs, haha, como podemos facilitar a criação de primitives mais avançados por outras pessoas?

Minha visão é que, alguns anos atrás, tínhamos várias equipes de ZK prontas para desenvolver na Solana. Basicamente dissemos a elas: “Sim, isso está chegando”, mas então a Firedancer apareceu e disse: “Não, não vamos incorporar isso”, e tudo foi adiado. Algumas dessas equipes haviam captado recursos e literalmente não conseguiam operar seus negócios porque não tinham os primitives criptográficos on-chain necessários, então foram forçadas a ir para outro lugar. Foi muito difícil. Tratar devs dessa forma é errado. Os primeiros clientes do protocolo são os devs — se você não cuidar deles, nada será criado, e o varejo não terá nada para usar.

Então eu simplesmente disse: tudo bem, vou resolver por conta própria. Fui lá, hackeei a syscall de recuperação Secp256k1 e basicamente fiz jailbreak na curva inteira. Agora é possível usar assinaturas Schnorr, compromissos de Pedersen, Bulletproofs, multiplicação arbitrária de curvas elípticas e até endereços Taproot ajustados, tudo sem uma única mudança no protocolo e por apenas cerca de 25.000 CUs. Isso foi feito por uma pessoa, no tempo livre. Lancei mais protocolos criptográficos do que a Anza, certo? Imagine o que poderia acontecer se isso fosse realmente incentivado. Imagine se o desenvolvimento fosse mais aberto.

O engraçado é que a maioria das pessoas nem percebe o tamanho desse avanço. Vou a uma conferência e conto para alguns caras da Arcium o que criei. Eles dizem: “Isso é incrível”. Mas, fora talvez nós dez que realmente entendemos cripto(grafia) nesse nível na Solana, ninguém percebe.

E quanto à Anza — são boas pessoas, mas só têm um criptógrafo, Sam Kim. Embora ele seja muito bom, acho bastante preocupante que ninguém mais na Anza saiba nada sobre criptografia. Eles me chamaram para atuar como revisor na atualização Alpenglow. Estou revisando o código do Sam e, em sua maior parte, ele é bom e tem ideias sensatas. Acho positivo que estejam acolhendo e aproveitando as habilidades de outra pessoa. Mas, no fim das contas, a Anza provavelmente nunca será realmente boa nisso. São necessárias várias empresas concorrentes, cada uma com alguma sobreposição, mas também com suas próprias especialidades. Não faz sentido a Anza tentar fazer tudo. O que realmente precisamos é diversificar o desenvolvimento do núcleo.

Você acha que é mais uma questão cultural? Por exemplo, a Ethereum tem L2s inteiras dedicadas a ZK, como ZKsync ou StarkWare. A Solana simplesmente descartou ZK como uma ideia vaga de escalabilidade? Algo como: preferimos extrair o máximo do hardware, então esse será nosso foco principal — vamos escalar a blockchain dessa forma. E, embora ZK não precise necessariamente ser usado na Solana apenas para escalabilidade, ele foi descartado como se servisse somente para isso e agora está em uma posição estranha?

Acho que as ferramentas não são boas. Não há nenhum tutorial sobre como usá-las. A Blueshift vai adicionar alguns — só estamos tentando incorporar as partes de SIMD Little Endian. Depois que isso for incorporado, lançaremos um template de ZK fácil de usar e com ótimo desempenho, além de alguns tutoriais, porque queremos facilitar a criação de projetos e a compreensão de como tudo funciona.

O problema atual é que ir do zero ao Hello, World! na Solana é um processo completamente absurdo. Se você olhar a Sui, seguir a documentação por cinco minutos, terá um Hello, World! funcionando. A Solana não tem isso. Essa é a diferença entre a Mysten Labs contratar cerca de dez pessoas que entendem de criptografia e a Anza contratar uma, certo?

Minha visão é que existe a percepção de que a Solana Foundation carece muito de entendimento técnico sobre praticamente tudo. A concepção de tecnologia deles só vai até a comercialização, certo? Além disso, eles terceirizam para a Anza a tarefa de pensar nessas coisas. A ideia é que, se a resposta diz que algo é bom, então deve ser bom. Na maioria das vezes, a realidade é que a resposta é boa em termos de desempenho, mas não muito boa em nenhum outro aspecto.

A Foundation presume que tudo está indo muito bem. Mas a experiência dos devs é algo como: “É difícil de usar”. É doloroso para caramba para quem sabe mais do que as pessoas que implementam as coisas no nível do protocolo, faz o trabalho voluntário, mas não consegue que seu trabalho seja levado a sério. É como: “Ah, não sei, eles não têm o selo mágico da Anza, então vamos ignorá-los e evitar o risco reputacional de incorporar um PR da comunidade”. Acho que é por isso que você percebe que luto tanto e defendo tanto os devs de código aberto — para acabarmos com isso, porque acho que há muita gente na comunidade enviando PRs realmente bons. Claro, há muito conteúdo ruim gerado por AI e muita porcaria, mas também há muitas pessoas realmente boas que merecem atenção. É uma blockchain, uma rede distribuída — não deveríamos precisar de algum tipo de selo da Anza para contribuir. Eles deveriam simplesmente assumir a responsabilidade de valorizar código de qualidade, independentemente de terem escrito esse código ou não.

Apesar de tudo isso, falando mais sobre inovação e criptografia, você também criou um cofre resistente à computação quântica na Solana usando assinaturas únicas de Winternitz. O que inspirou esse projeto e como você imagina sua evolução no futuro, talvez quando as ameaças quânticas se tornarem mais concretas?

Sinceramente, começou com um tweet, haha. Um maximalista de Bitcoin publicou no fim do ano passado: “A Solana será a primeira vítima da computação quântica”. Li aquilo e pensei: “Beleza, cara. Se um dia precisarmos migrar pessoas de uma criptografia vulnerável à computação quântica para uma criptografia segura, nossa blockchain consegue fazer mais de 50.000 migrações por segundo. A sua faz umas seis. Quem realmente vai se dar mal primeiro?”

Então eu simplesmente disse: que se dane, vou fazer isso acontecer.

Dez dias depois, lancei o cofre Winternitz e respondi citando o tweet dele, tipo: GG.

Essa foi a motivação — alguém dizer que não era possível. Eu já pensava em esquemas de assinatura pós-quântica havia algum tempo, mas aquilo me fez seguir em frente.

E funcionou. Você pode armazenar fundos em uma PDA fora da curva, usar o cofre Winternitz e, não importa o que aconteça — seja uma reversão do ledger ou ataques quânticos interferindo nas assinaturas dos líderes —, pelo menos em qualquer versão para a qual fizermos rollback, seus fundos estarão seguros. Não é uma solução definitiva, mas é um bote salva-vidas perfeito.

Se você administra um fundo com milhões ou bilhões em LSTs ou SOL em staking e, de repente, adotar segurança pós-quântica se torna uma exigência regulatória, isso deixa de ser um obstáculo à adoção. Você não precisa atualizar o protocolo. Simplesmente funciona.

No momento, criei um firmware para Ledger que gera essas assinaturas, além de uma carteira e um aplicativo web. A Blueshift provavelmente vai trabalhar para transformar isso em algo mais amigável ainda este ano. Obviamente, ainda não é urgente, mas a questão é: a opção já existe hoje. Esse é o avanço.

Na verdade, é muito engraçado. Toly me mandou uma DM no dia seguinte. Brincando, ele disse: “Cara, achei que, quando os computadores quânticos surgissem, eu teria que me aposentar discretamente”. Eu respondi: “Haha, não, cara, não se aposente. A gente te protege”.

Falando em Bitcoin, você é cientista-chefe da Zeus Network, onde basicamente implementou do zero todo o protocolo do Bitcoin sobre a Solana. Quais foram os maiores desafios para conseguir isso? E você imagina um futuro em que outras blockchains sejam reimplementadas sobre a Solana?

Essa é uma pergunta muito interessante. Da mesma forma que as assinaturas Winternitz eram extremamente caras em termos computacionais, mas ainda assim mal cabiam em uma única transação, o Bitcoin está nesse mesmo ponto ideal. Ele é sofisticado o suficiente para permitir coisas como provas de SPV, mas ainda é primitivo o bastante para que a Solana, uma plataforma mais avançada e de maior desempenho, possa pegar aquilo e colocar dentro disto.

Com blockchains de segunda geração, como a Ethereum, é mais complicado. Elas são muito menos primitivas e bem mais complexas. Então, a questão passa a ser: a Solana consegue continuar ficando mais rápida e, ao mesmo tempo, alocar cada vez mais recursos a transações individuais?

No momento, ainda é difícil, embora não seja impossível. O principal elemento ausente hoje para compatibilidade com EVM é a syscall BigModExp. Se a ativássemos, acho que poderíamos chegar bem perto da paridade total com a Ethereum no nível da VM, o que é meio absurdo de imaginar.

Mas a pergunta maior é: por que se dar ao trabalho?

Com Bitcoin, a resposta é óbvia: ele tem trilhões em valor, é o padrão-ouro do dinheiro e é primitivo o suficiente para que a Solana consiga replicá-lo de forma limpa.

Ethereum? Nem tanto.

“Dinheiro ultrassônico” é um meme. Por um breve momento, o orçamento de segurança da Solana chegou a superar o da Ethereum. Isso torna a Solana um dinheiro ultrassônico? Fazer o wrapping de ETH na Solana não gera nem de longe tanto valor quanto fazer o wrapping de BTC.

Então, sim, acho que o Bitcoin foi o primeiro alvo certo. Era tecnicamente viável e economicamente relevante. À medida que a Solana continuar melhorando, talvez vejamos outras blockchains sendo reimplementadas também. Mas, sinceramente, quanto maior o desempenho da Solana, menor a necessidade de se preocupar com outras blockchains.

A capacidade de incluir toda essa funcionalidade em uma única transação é muito interessante. Recentemente, atualizações ultraeficientes de oráculos despertaram sua obsessão, e você levou os limites adiante com o Doppler e suas atualizações de 21 CU. Como esses feitos de baixo consumo de CU demonstram a vantagem da Solana sobre outras blockchains? Vimos desenvolvimentos semelhantes em outras blockchains com gas golfing, mas quais possibilidades exclusivas a Solana oferece?

Oráculos são um estudo de caso muito interessante porque todos meio que os consideram um problema “resolvido”.

Voltando cerca de um mês, Cavey pegou meu programa noop e atingiu 100.000 transações por segundo na mainnet. Foi legal. Agora vamos ver se conseguimos ir além. Mais especificamente, 100.000 atualizações de oráculo por segundo na mainnet.

Se isso for possível, acaba completamente com toda essa narrativa de “precisamos de tempos de bloco menores para competir com a Binance”. Se você consegue atualizar um oráculo cem mil vezes por segundo, quem se importa com atualizações da Binance a cada 20 milissegundos?

Esse é o verdadeiro objetivo da hiperotimização. AMMs proprietários já estão usando algo parecido com esse estilo de atualização — não exatamente a mesma coisa que estou publicando, mas quem sabe, sabe. No momento, eles incorporam essa lógica profundamente em suas estratégias de negociação.

Com o Doppler, não há muitos motivos para manter essa complexidade dentro dos programas. A atualização do oráculo pode simplesmente ser removida por completo e executada separadamente.

O tamanho também é mínimo. O oráculo Doppler tem apenas cerca de 480 bytes. Estou até preparando um SDK em TypeScript para que os devs possam implantar suas próprias versões personalizadas diretamente do TypeScript, sem precisar tocar em Rust. Basta definir um schema Borsh, publicá-lo e começar a disparar atualizações de oráculo a toda velocidade. Obviamente, devs de Rust podem fazer a mesma coisa, mas acho interessante que até um desenvolvedor TypeScript agora possa acessar esse nível de desempenho usando assembly hiperotimizado nos bastidores.

Quanto aos casos de uso: oráculos de aleatoriedade, perpétuos, AMMs de oráculo e AMMs proprietários — todos se beneficiam. Mas isso também vale para coisas como canais de pagamento ou escalabilidade em L2. Se você consegue abrir e fechar canais praticamente sem custo, isso é enorme. Basicamente, você não precisa mais de um programa Anchor gigantesco e opressivo apenas para atualizar um oráculo.

Abstração, assembly e IBRL

Considerando sua reputação por escrever assembly, você acha que a maioria dos desenvolvedores deveria realmente mexer com isso? Ou é uma daquelas coisas em que apenas algumas pessoas levam os limites adiante para que todas as outras possam criar com segurança nas camadas superiores da stack?

Acho que todos deveriam aprender pelo menos um pouco. George Hotz, provavelmente o melhor programador vivo, diz que todos deveriam aprender Python, C e assembly.

Se você não entende assembly, não entende o que o compilador realmente está fazendo. Se não entende C, não valoriza todas as facilidades que Python oferece. Não acho Python tão bom assim, mas Rust, por exemplo, é uma linguagem muito expressiva que pode ser usada tanto em alto quanto em baixo nível. É uma excelente escolha.

Então, sim, eu diria para aprender um pouco de assembly e Rust. Em algum momento, você também terá que aprender TypeScript se quiser criar frontends. No fim das contas, você está criando produtos para pessoas e, se seus usuários são desenvolvedores, TypeScript acaba entrando no seu radar, goste ou não.

Quando comecei a escrever assembly na Solana, literalmente ninguém fazia isso. Criei as ferramentas, publiquei exemplos e agora algumas centenas de pessoas já experimentaram. Talvez umas dez sejam realmente boas. Algumas até escreveram programas mais impressionantes do que os meus. É principalmente uma questão de dedicar tempo para fazer acontecer.

A maior parte do que faço envolve coisas pequenas, elegantes, de altíssimo desempenho e com uma única finalidade — situações em que vejo o potencial de reduzir o custo de execução em 100 vezes. Meu papel é mais explorar, inspirar e deixar que outras pessoas levem o trabalho adiante. Neste estágio, não ganho muito promovendo tudo o que crio, então prefiro destacar os outros, retuitar o trabalho deles e ajudá-los a construir sua própria reputação.

Então, sim, acho que todos deveriam pelo menos aprender assembly. É um ótimo exercício. Mas, ao mesmo tempo, também é verdade que um pequeno grupo de pessoas trabalhando intensamente no nível mais baixo pode criar melhorias das quais todos os outros se beneficiam.

Se você analisar a grande maioria das melhorias feitas no Pinocchio nos últimos seis meses, todas vieram de otimizações em assembly. Febo fez a triagem de cada PR como um verdadeiro monstro e conseguiu incorporar coisas realmente boas. Veja o p-token, por exemplo — é o mesmo conceito.

Você considera a programação de baixo nível não apenas uma escolha técnica, mas talvez algo mais ideológico?

Sim, acho que é as duas coisas. Por que as pessoas querem colocar um JPEG no Bitcoin? Há algo primitivo e intrinsecamente interessante em usar esse sistema extremamente limitado para algo que ele nunca foi projetado para fazer. É meio hilário e também meio bonito.

A curiosidade termina quando você para de fazer perguntas.

Então, se você é uma pessoa curiosa, o destino lógico da sua curiosidade provavelmente será algo como: “Escrevi algo em TypeScript que consumia um programa Anchor. Como o Anchor funciona? Como as macros funcionam? Como Rust funciona? Como assembly funciona?”

Talvez você comece então a mergulhar no compilador Rust, depois no MIR, no LLVM IR e em como ele é compilado para eBPF. Depois, pergunta o que é eBPF e lê sobre seu assembly. Por fim, você se vê encarando o bytecode bruto e percebe que pode eliminar alguns bytes porque o compilador não otimizou algo automaticamente. Esse é o destino lógico dessa investigação. Sem dúvida, há um aspecto ideológico nisso.

Você também trabalha com a Solana Foundation, ajudando equipes que falam mandarim e cantonês a começar, depurar e desenvolver. Você trabalha com todas essas equipes e as ajuda tornando as coisas mais simples e acessíveis. Ao mesmo tempo, é conhecido por defender o assembly e abusar de syscalls. Como você concilia essa tensão? Como equilibra levar os desenvolvedores para mais perto do hardware com a necessidade prática de integrá-los por meio de abstrações de alto nível?

Se você observar a Blueshift, basicamente criamos um continuum que vai do iniciante ao especialista. Minha visão é simples: você obtém o nível de desenvolvedores para o qual oferece treinamento. Se você só ensina Anchor ou TypeScript, atrai apenas o tipo de dev que acha isso suficiente. Mas, se começa a falar sobre eliminar unidades individuais de computação com assembly escrito à mão, atrai devs de outro calibre — pessoas que realmente entendem o significado dessas palavras.

Nossa estratégia com a Blueshift é mirar primeiro no meio da curva. É onde estão os números e onde você obtém o melhor ROI. Depois, movemos essas pessoas para a direita, ajudamos a elevar o nível delas e, por fim, temos um exército de devs competentes que podem voltar e apoiar o lado esquerdo da curva — os iniciantes absolutos.

Dessa forma, é muito mais escalável. Eu poderia passar horas todos os dias ensinando iniciantes a fazer CPI no Token Program, algo presente em 90% de todos os programas da Solana. Ou posso treinar cem pessoas para fazer o mesmo, e cada uma delas pode integrar outras cem. É assim que se escala.

Queremos acolher as pessoas em qualquer nível em que estejam e continuar deslocando-as para a direita. Blueshift, Solana Foundation — o objetivo é o mesmo.

Educação, transferência de conhecimento e comunidade

Falando sobre a Blueshift, você foi cofundador dela e da Turbin3, ambas com fortes missões educacionais. Que futuro você imagina para essas iniciativas?

Não havia muita coisa na Turbin3 quando entrei. Cheguei, escrevi todos os programas do currículo e comecei a coordenar tudo. Acho que conduzi três ou quatro turmas e treinei todas as pessoas que hoje são professores. Em nove meses, saímos do zero até o ponto em que consegui me substituir com um bom treinamento, e já não restava muito para eu fazer. Capacitar pessoas com um bom treinamento mostra que existe um efeito de crescimento contínuo e escalável.

O problema é que eles recebem mil inscrições por trimestre e rejeitam talvez 800 ou 900 pessoas. Quem entra passa por um curso de seis semanas e precisa comparecer às aulas três vezes por semana. No final, não recebe um certificado nem nada que comprove a conclusão — talvez confirmem sua participação, talvez não. Mas seis semanas é muito tempo para esperar que nada dê errado na sua vida. Seu cachorro pode ficar doente, você precisa levá-lo ao veterinário e perde algumas aulas; de repente, fica para trás e é excluído. Bootcamps tradicionais exigem muito tempo e dinheiro para funcionar e, na verdade, não são otimizados para os melhores devs. Você está ajudando pessoas que nem precisavam do bootcamp e só necessitavam de um ponto de partida para a carreira, ou provavelmente está conduzindo pela mão pessoas que não conseguiriam terminar sem esse apoio constante. Nenhum desses caminhos realmente escala a integração de desenvolvedores da forma que a Solana precisa hoje.

Então, a pergunta mais adequada é: como pegar as 800 ou 900 pessoas rejeitadas pelos bootcamps e dar uma oportunidade àquelas que realmente são capazes?

Com a Blueshift, a resposta foi criar um aprendizado autodirigido de alta qualidade. Se você consegue acompanhar o material, pode concluí-lo no seu próprio ritmo e receber um NFT como comprovante. Tudo é de código aberto, e incentivamos ativamente pull requests da comunidade, além de destacar as pessoas no Twitter para ajudar a promover e impulsionar suas carreiras. As pessoas enviam melhorias, nós as incorporamos, e isso torna toda a plataforma melhor.

Em vez de dizer: “Desculpe, você não entrou. Boa sorte na próxima vez”, dizemos: “Aqui está o currículo. Vá lá e mande ver no seu próprio ritmo”. Já temos aulas traduzidas para oito idiomas, então as pessoas podem organizar meetups ou bootcamps em qualquer lugar do mundo. A Superteam pode usar. A Forma pode usar. No final, você tem um padrão objetivo: as pessoas conquistam o mesmo NFT, você sabe em que nível elas estão e pode contratá-las ou desafiá-las de acordo com isso.

A Blueshift resolve todos esses problemas concentrando-se nos devs motivados e capazes de acompanhar um aprendizado autodirigido de alta qualidade. Aceitamos que, se abrirmos tudo como código aberto, as pessoas serão mais críticas, e isso permitirá que a sabedoria da comunidade se destaque. Assim, incorporamos seus PRs e acabamos com a melhor plataforma e o melhor conteúdo educacional disponíveis.

Você basicamente já respondeu isso de forma implícita, mas, para deixar mais explícito: você vê a educação de desenvolvedores mais como um problema de tradução — tornar ideias complexas mais acessíveis —, como um problema de bootcamp — levar rapidamente muitas pessoas a um nível básico — ou como algo completamente diferente?

Sim, o principal problema da educação de desenvolvedores hoje é que os recursos que disponibilizamos gratuitamente são uma porcaria. Muitos estão desatualizados. Basicamente, todo mundo escreve em Anchor ou Pinocchio. Ninguém usa solana_program. Tudo fica desatualizado muito rápido. Então, com tudo em código aberto, podemos criar rapidamente e com cuidado um bom conteúdo e mantê-lo atualizado. Parece que ninguém mais realmente quer fazer isso, então nós vamos fazer porque ninguém mais quer.

Até Mert percebeu isso seis meses atrás, quando conversávamos sobre o assunto. Do ponto de vista dele, era bom que alguém tivesse decidido se importar com esse problema. E quem seria melhor do que nós, certo? Tenho o privilégio de ser um dos devs mais influentes desse espaço. Tudo é de código aberto. Não temos nenhuma vantagem defensável, haha. Não recebemos um subsídio gigantesco da Foundation — nós mesmos nos financiamos. Fizemos tudo sozinhos, e nossa única vantagem é a execução.

A educação é um continuum. Você precisa encontrar as pessoas onde elas estão com coisas desafiadoras o bastante para que aprendam algo, mas fáceis o suficiente para que consigam entender e se sintam à vontade, voltando sempre. Depois, você começa a despertar a obsessão delas e movê-las para a direita. Acho que faço isso bem, então a Blueshift é a plataforma definitiva para despertar obsessões técnicas. De repente, você pensa: “Que porra é essa? Por que estou escrevendo assembly agora?”

O Discord da Blueshift também oferece serviços de DevRel para ajudar as pessoas a desenvolver seus projetos quando ficam travadas. O mais importante é que nem sou eu quem responde à maioria das perguntas — é a comunidade. E isso é muito melhor do que o StackOverflow ou qualquer outra coisa porque há uma comunidade forte e participativa.

Como será o futuro da Blueshift?

O futuro da Blueshift é basicamente composto por dois produtos: Coursera e LeetCode. Já temos uma versão razoável — na verdade, melhor do que razoável, mas não ideal — desses dois produtos, porém ela precisa melhorar. Estamos trabalhando em uma V3, então tudo ficará muito melhor.

Queremos ser extremamente eficazes em atender devs capazes de acompanhar um aprendizado autodirigido. E, sinceramente, esse é o tipo de dev que prefiro ter no ecossistema.

Quero pessoas que simplesmente arregacem as mangas e tentem. Queremos facilitar isso ao máximo, oferecendo bons recursos. Então, não vamos desperdiçar o tempo delas com porcarias desatualizadas, dependências quebradas e coisas do tipo.

O objetivo final é ter uma plataforma em que as pessoas possam aprender aquilo que lhes interessa sem serem limitadas a uma única área e, depois, comprovar esse conhecimento concluindo diferentes desafios.

Perguntas rápidas

Que música você tem ouvido ultimamente enquanto escreve assembly?

Haha, geralmente death metal.

Qual é a melhor syscall para abusar na Solana?

secp256k1_recover

Você preferiria escrever C# ou Java pelo resto da vida?

Não.

O que é melhor: um modelo baseado em UTXO ou em contas?

Um UTXO vale mais.

Se tivesse recursos ilimitados, qual iniciativa educacional dos seus sonhos você lançaria amanhã?

Blueshift mais IRL.

Qual é uma dica para ensinar conceitos de baixo nível da Solana a novos devs sem assustá-los?

Humor autodepreciativo.

Conclusão

Em um mundo de abstrações de alto nível e da aceitação delas como “realidade” para atrair as massas, Dean Little se destaca como uma ponte rara — um alquimista de baixo nível que forja ferramentas com os elementos mais básicos para erguer os outros sobre seus ombros. Sua jornada, dos foguetes à proliferação de atualizações de oráculo hiperotimizadas, revela o ethos de um criador. Um ethos inflexível em sua busca pela verdade: projete para a falha, inove contra os limites e nunca confie cegamente em nada.

Seja trazendo cofres quânticos à existência pela força da vontade ou escalando a Blueshift para despertar a obsessão da próxima geração de desenvolvedores excepcionais da Solana — que, com sorte, poderão se apoiar nos ombros de gigantes e não terão que mastigar tanto vidro quanto o restante de nós —, Dean personifica o fogo do purista, temperado pelo calor da comunidade. É um lembrete de que o verdadeiro progresso não consiste apenas em jogar mais lenha na fogueira, empilhando camada sobre camada — trata-se de remover essas camadas para revelar o zumbido das máquinas e ensinar outras pessoas a dançar com ele.

Enquanto a Solana avança em alta velocidade para seu próximo salto — seja a paridade completa com EVM, o Alpenglow ou 100.000 atualizações de oráculo por segundo —, o trabalho de Dean sussurra um desafio para todos nós: por que se contentar com mentiras educadas quando você pode soldar sua própria realidade? Se a curiosidade é a faísca, pessoas como Dean são o combustível.

Mergulhe de cabeça, abuse de uma syscall, sobrecarregue uma transação com funcionalidades complexas e, quem sabe, talvez você saia com seu próprio bote salva-vidas quântico.