P-Token: o próximo grande avanço em eficiência da Solana

Introdução

Um dos fatores menos reconhecidos por trás da rápida adoção da Solana é sua abordagem segura, simples e padronizada para tokens. Ao contrário de muitas outras blockchains, criar um token na Solana não exige a implantação de um contrato personalizado. Em vez disso, tudo passa pelo programa SPL Token (também conhecido como Tokenkeg), amplamente auditado, testado em produção e originalmente implantado pela Solana Labs. Essa abordagem torna triviais ações comuns como cunhar, queimar e transferir tokens. Por exemplo, é possível implantar um token da Solana com um único comando de CLI.

O programa SPL Token é o programa mais utilizado na Solana, depois do programa System. Nos últimos seis meses, a criação semanal de novos tokens fungíveis por meio do programa SPL Token ficou, em média, entre 200.000 e 300.000. Isso representa um aumento de 20 vezes em relação a setembro de 2023, dois anos antes, quando a criação semanal de novos tokens SPL permanecia regularmente abaixo de 10.000. No total, com exceção de 2023, todos os anos desde o lançamento da Solana registraram um aumento significativo no número de novos tokens emitidos, como mostra o gráfico abaixo.

O crescimento das transferências de tokens SPL foi ainda mais acentuado. Nos últimos três meses, as transferências semanais ultrapassaram consistentemente 650 milhões, atingindo um pico de 867,8 milhões no fim de julho. Esse pico representa um aumento de 17,5 vezes em relação à mínima de 49,4 milhões de transferências semanais registrada no início de agosto de 2023.

Conheça o P-Token

P-token é um substituto direto e otimizado para computação do atual programa SPL Token, proposto pela primeira vez pela equipe da Anza em março por meio do SIMD-0266: programa de tokens eficiente. Ele oferece reduções substanciais no uso de unidades de computação (CU), mantendo total compatibilidade retroativa com os tokens SPL existentes. 

Como p-token replica exatamente o conjunto de instruções e os layouts de conta do programa SPL Token, ele pode substituí-lo diretamente. Isso significa que p-token não é um novo padrão de token. O código do cliente continua funcionando exatamente como antes. Assim, a transição gera ganhos significativos de eficiência sem exigir ajustes de aplicações ou usuários.

O esforço para adotar p-token está alinhado à iniciativa mais ampla da Solana de aumentar a eficiência de programas e frameworks, complementando o trabalho para ampliar a capacidade da rede — principalmente a meta de 2025 de duplicar o espaço disponível nos blocos.

O sucesso recente de AMMs proprietários na Solana demonstra o impacto de custos computacionais menores e as vantagens de programas altamente eficientes. Por exemplo, as atualizações de oráculos em plataformas como a HumidiFi foram hiperotimizadas para apenas 143 CUs. O Doppler, um novo programa de oráculo de código aberto da BlueShift, reduz ainda mais os custos, para apenas 21 CUs.

Pinocchio

O “p” de p-token significa Pinocchio, uma biblioteca otimizada, de alto desempenho e sem dependências para escrever programas da Solana, desenvolvida pela Anza. Pinocchio substitui o crate solana-program padrão, que usa amplamente tipos zero-copy para processar dados de instruções e contas. Com zero-copy, os dados não são duplicados em novos locais da memória durante operações de leitura ou gravação. Em vez disso, o estado é acessado diretamente por meio de ponteiros. Esse design proporciona uma economia computacional significativa ao evitar operações desnecessárias de memória, além de reduzir a sobrecarga de runtime.

Pinocchio também é no_std, ou seja, não depende da biblioteca padrão do Rust nem de alocações de heap, pois a Solana Virtual Machine (SVM) já fornece o ambiente de runtime. Isso simplifica ainda mais a execução e reduz as dependências, garantindo programas mais leves e rápidos.

Ganhos de eficiência

As CUs medem o custo de execução no runtime da Solana. A menor operação, como a soma de dois números inteiros ou uma operação bit a bit, consome 1 CU. Os programas são limitados a 200 mil CUs por instrução e 1,4 milhão de CUs por transação.

P-Token oferece melhorias expressivas de eficiência, reduzindo em cerca de 95% o consumo de CUs nas transações padrão de tokens SPL, um ganho de eficiência de 19 vezes. Essa execução mais rápida proporciona uma experiência mais fluida para o usuário. Ao mesmo tempo, a liberação de recursos computacionais permite incluir mais transações em cada bloco, aumentando diretamente o throughput da rede.

Hoje, as instruções do programa Token representam cerca de 10% do uso de CUs em todo o bloco. Ao reduzir o custo delas para apenas 5% dos níveis atuais, p-token pode diminuir essa participação de 10% para 0,5%, liberando mais 9,5% da capacidade do bloco para outras transações. P-token também beneficia programas downstream e melhora a composabilidade ao reduzir o uso total de CUs e o custo das invocações entre programas (CPI).

Abaixo estão dados que detalham a eficiência de CUs obtida pelas instruções de p-token em comparação com o atual programa SPL Token, apresentados em gráfico e tabela.

Outra otimização importante, possibilitada em grande parte por `no_std`, é a redução do tamanho do binário do programa de 131 KB para 95 KB.

Instruções adicionais

P-token propõe adicionar três novas instruções (`withdraw_excess_lamports`, `batch` e `unwrap_lamports`) ao programa de tokens que não existem no programa SPL Token original.

Retirada de lamports excedentes

Assim como na implementação atual do SPL Token-2022, `withdraw_excess_lamports` permite recuperar SOL excedente “preso” na conta de mint. Isso geralmente acontece quando um usuário envia lamports por engano para a conta de mint do token.

A retirada exige autorização da autoridade de mint, seja o signatário designado para contas de mint padrão ou a multisig para contas multisig. Como a maioria dos tokens SPL teve sua autoridade de mint revogada, a autorização pode ser fornecida usando a própria conta de mint como autoridade signatária, com a instrução assinada pela chave privada do mint.

Entre todas as contas de mint de tokens SPL, ~869.000 possuem mais SOL do que o limite mínimo de isenção de aluguel de 0,0014616 SOL. No total, isso equivale a 176.961,5 SOL bloqueados em contas de mint de tokens, avaliados em US$ 36 milhões pelo preço atual. As maiores quantidades de SOL bloqueadas em contas de mint de tokens geralmente estão associadas a memecoins, tokens legados e ativos blue chip importantes. A maior quantidade de SOL bloqueada na conta de mint de um único token pertence ao BOOK OF MEME ($BOME), uma memecoin, com 6.328 SOL. A adoção de p-token poderia permitir o desbloqueio desses saldos, proporcionando um ganho extraordinário para as equipes responsáveis por esses tokens.

Lote

A segunda nova instrução é `batch`, que simplifica as interações de CPI com o programa p-token. Em vez de invocar o programa de tokens várias vezes, `batch` permite executar um número variável de instruções de token em uma única chamada. Isso significa que o custo-base de CPI de 1.000 unidades é incorrido apenas uma vez, e não para cada instrução individual.

O resultado é uma redução substancial no uso de computação para protocolos que dependem de várias CPIs de token em uma única instrução, um padrão comum na DeFi da Solana. Por exemplo, um AMM pode realizar duas transferências em um swap, ou um depósito em um pool de liquidez pode envolver transferências e mints. Ao usar `batch`, os programas podem obter economias significativas de CUs nesses cenários.

Desembrulhar lamports

A instrução `unwrap_lamports` (adicionada recentemente em um PR separado) permite transferir lamports diretamente para uma conta de destino, eliminando a necessidade de criar contas temporárias de tokens nativos.

Antes, desembrulhar lamports de uma conta de SOL embrulhado exigia criar e depois fechar uma conta de token associada (ATA) para o destinatário. Com esta atualização, agora é possível transferir lamports diretamente de contas de SOL nativo, simplificando o processo.

Caminho rápido para instruções de transferência

A análise do uso do programa de tokens na mainnet mostra uma forte concentração em torno das instruções de transferência, que juntas representam quase metade de toda a atividade. As cinco instruções usadas com mais frequência são:

• transfer_checked (36,33%)
• transfer (13,22%)
• close_account (12,23%)
• initialize_account3 (9,98%)
• initialize_immutable_owner (9,78%)

Esse padrão de uso destaca uma oportunidade de otimizar ainda mais p-token para transferências e reduzir o consumo de CUs. Grande parte desse trabalho de otimização foi realizada por Cavey, da Temporal. Para uma análise mais detalhada da abordagem, assista à transmissão ao vivo dele no X.

Para obter esses ganhos, p-token introduz um entrypoint personalizado com um caminho rápido para instruções de transferência e atualiza o processador para priorizar `sync_native` e `initialize_immutable_owner`. Juntas, essas mudanças proporcionam melhorias significativas na eficiência de CUs, em linha com os padrões de uso observados.

Logs

Com a introdução de p-token, uma questão em aberto é se o comportamento atual de logs deve ser mantido. A versão mais recente da proposta recomenda remover os logs. Na Solana, os logs são o principal mecanismo para extrair dos programas dados de depuração, monitoramento e eventos. No programa de tokens existente, os logs são mínimos e se limitam a exibir o nome da instrução em execução. Por exemplo:

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

No entanto, essa linha de log aparentemente pequena, `Instruction: <name>`, custa cerca de 103 unidades de computação. Na prática, essa sobrecarga pode consumir quase tanta computação quanto a própria instrução. Por exemplo, os logs representam aproximadamente 40% da computação total necessária para uma transferência simples.

Além do custo, esses logs nem sempre são confiáveis. Eles podem ser truncados ou manipulados por injeção de logs, o que pode induzir parsers downstream ao erro. Por outro lado, removê-los por completo poderia interromper os fluxos de trabalho de desenvolvedores e aplicações que atualmente dependem deles.

A eliminação dos logs aumentaria a importância de as equipes publicarem IDLs para dar visibilidade ao comportamento dos programas. O Anchor, por exemplo, agora exige isso ao publicar IDLs para todos os novos programas por padrão, a menos que essa opção seja explicitamente desativada.

Auditoria

A auditoria do programa p-token já está em andamento para garantir total compatibilidade retroativa e segurança. Para que p-token seja adotado, ele deve seguir rigorosamente as instruções e os layouts de conta exatos do programa Token atual, replicando com precisão seu comportamento. Qualquer desvio representaria um risco, que está sendo tratado por meio de testes abrangentes e auditorias independentes.

Os auditores da Neodyme realizaram testes de equivalência reproduzindo duas vezes cada transação da mainnet dos últimos meses: uma com o programa de tokens original e outra com p-token. Os resultados confirmaram saídas idênticas e também demonstraram economias significativas de CUs.

De acordo com a análise, entre 3 e 11 de agosto de 2025, p-token teria reduzido a sobrecarga em 8,9 trilhões de CUs com os logs ativados e em 9,14 trilhões de CUs com os logs desativados. Esses números representam economias de 12,0% e 12,3% do uso total do espaço dos blocos, respectivamente.

P-token está passando atualmente por uma segunda auditoria da Zellic e por verificação formal da Runtime Verification.

Implementação

O processo planejado de implementação de p-token segue uma abordagem em etapas. Ele começa com a conclusão da auditoria, dos testes de fuzzing e da verificação formal. Em seguida, haverá uma votação de governança dos validadores sobre a adoção de p-token e a aceitação formal da SIMD 266. Depois disso, o recurso p-token será implantado no cluster e colocado atrás de um feature gate.

O programa será implantado primeiro em uma conta designada (ptokN…UkkZ2). Quando o feature gate for ativado no limite da época, o runtime de todos os validadores substituirá o programa de tokens existente (Tokenkeg…VQ5DA) pela nova implementação usando o Upgradable Loader v3.

Uma abordagem alternativa seria implantar o programa p-token em um novo endereço, o que exigiria a migração manual por usuários e aplicações. No entanto, esse caminho não é o preferido, pois provavelmente dificultaria a adoção e reduziria os benefícios gerais, já que muitos usuários hesitariam ou demorariam para fazer a transição.

Impacto econômico

A adoção de p-token faz parte de um conjunto de melhorias que devem ampliar drasticamente a capacidade geral da Solana, permitindo incluir mais transações em cada bloco. Outras atualizações importantes incluem duplicar o espaço dos blocos para 100 milhões de CUs e aumentar o limite de CUs por conta de 12 milhões fixos para 40% do bloco.

Atualmente, uma única conta está limitada a 12 milhões de CUs por bloco. Como mostra o gráfico da Anza abaixo, a conta mais disputada em cada bloco frequentemente atinge esse limite. P-token, por si só, dificultará que as contas cheguem a esse limite, reduzindo a frequência de gargalos em estados muito acessados.

Hoje, quase todas as transações incluem uma taxa de prioridade ou uma gorjeta da Jito para incentivar os validadores a incluí-las em um bloco. Como a prioridade é determinada pela taxa por CU, uma transação p-token, que consome menos CUs, deve, em igualdade de condições, receber maior prioridade pela mesma taxa ou gorjeta. No entanto, como todas as transações de tokens SPL serão beneficiadas pela atualização para p-token, o impacto geral sobre a priorização de transações ainda não está claro.

Conclusão

A adoção de p-token, caso seja aprovada em uma votação de governança, representa um grande avanço na eficiência e na escalabilidade da Solana. Ao reduzir drasticamente o uso de computação e simplificar as interações de CPI, ela fortalece a base do programa mais utilizado da rede e amplia a capacidade geral dos blocos. Se for bem-sucedido, p-token poderá servir como modelo para o desenvolvimento de versões otimizadas com Pinocchio de outros programas amplamente usados, como o programa Associated Token Account (ATA) e até mesmo o programa System, abrindo caminho para um runtime mais rápido e eficiente.

Outros recursos

• Repositório de p-token - GitHub
• Repositório de Pinocchio - GitHub
• Biblioteca de programas da Solana (SPL) - GitHub
• Calculadora de economia de SOL do p-Token - SendAI