P-Token: el próximo gran avance en eficiencia de Solana

Introducción

Uno de los factores menos valorados detrás de la rápida adopción de Solana es su enfoque seguro, sencillo y estandarizado para los tokens. A diferencia de muchas otras blockchains, crear un token en Solana no requiere implementar un contrato personalizado. En su lugar, todo funciona mediante el programa SPL Token auditado exhaustivamente y probado en producción (también conocido como Tokenkeg), que Solana Labs implementó originalmente. Este enfoque facilita acciones comunes como acuñar, quemar y transferir tokens. Por ejemplo, puedes implementar un token de Solana con un solo comando de CLI.

El programa SPL Token es el programa más utilizado en Solana, aparte del programa System. Durante los últimos seis meses, la creación semanal de nuevos tokens fungibles mediante el programa SPL Token ha promediado entre 200,000 y 300,000. Esto representa un aumento de 20 veces respecto a dos años antes, en septiembre de 2023, cuando la creación semanal de nuevos tokens SPL se mantenía regularmente por debajo de 10,000. En general, excepto en 2023, cada año desde el lanzamiento de Solana ha registrado un aumento considerable en la cantidad de nuevos tokens emitidos, como muestra la siguiente gráfica.

El crecimiento de las transferencias de tokens SPL ha sido aún más pronunciado. Durante los últimos tres meses, las transferencias semanales han superado de forma constante los 650 millones y alcanzaron un máximo de 867.8 millones a finales de julio. Este máximo representa un aumento de 17.5 veces respecto al mínimo de 49.4 millones de transferencias semanales registrado a principios de agosto de 2023.

La llegada de P-Token

P-token es un reemplazo directo y optimizado para cómputo del programa SPL Token actual. El equipo de Anza lo propuso por primera vez en marzo mediante SIMD-0266: Programa de tokens eficiente. Reduce considerablemente el uso de unidades de cómputo (CU) y mantiene compatibilidad total con versiones anteriores de los tokens SPL. 

Como p-token replica exactamente el conjunto de instrucciones y las estructuras de cuentas del programa SPL Token, puede sustituirlo directamente. Esto significa que p-token no es un nuevo estándar de tokens. El código del cliente sigue funcionando exactamente igual, por lo que la transición aporta importantes mejoras de eficiencia sin exigir ajustes a las aplicaciones ni a los usuarios.

El impulso para adoptar p-token coincide con el esfuerzo más amplio de Solana por mejorar la eficiencia de los programas y frameworks. Esto complementa el trabajo para aumentar la capacidad de la red, en especial el objetivo de 2025 de duplicar el espacio de bloque disponible.

El éxito reciente de los AMM propietarios en Solana demuestra el impacto de reducir los costos de cómputo y las ventajas de los programas altamente eficientes. Por ejemplo, las actualizaciones de oráculos en plataformas como HumidiFi se han hiperoptimizado hasta consumir solo 143 CU. Doppler, un nuevo programa de oráculos de código abierto de BlueShift, reduce aún más los costos, hasta solo 21 CU.

Pinocchio

La “p” de p-token representa a Pinocchio, una biblioteca optimizada, de alto rendimiento y sin dependencias para escribir programas de Solana, desarrollada por Anza. Pinocchio reemplaza el crate solana-program estándar, que utiliza ampliamente tipos zero-copy para gestionar datos de instrucciones y cuentas. Con zero-copy, los datos no se duplican en nuevas ubicaciones de memoria al leerlos o escribirlos. En su lugar, se accede al estado directamente mediante punteros. Este diseño permite ahorrar una cantidad considerable de cómputo al evitar operaciones de memoria innecesarias y también reduce la sobrecarga en tiempo de ejecución.

Pinocchio también es no_std, lo que significa que no depende de la biblioteca estándar de Rust ni de asignaciones en el heap, ya que Solana Virtual Machine (SVM) proporciona el entorno de ejecución. Esto simplifica aún más la ejecución y reduce las dependencias, lo que permite crear programas más ligeros y rápidos.

Mejoras de eficiencia

Las CU miden el costo de ejecución en el entorno de ejecución de Solana. La operación más pequeña, como sumar dos enteros o realizar una operación bit a bit, consume 1 CU. Los programas tienen un límite de 200 mil CU por instrucción y 1.4 millones de CU por transacción.

P-Token ofrece mejoras drásticas de eficiencia y reduce aproximadamente un 95% el consumo de CU de las transacciones estándar de tokens SPL, lo que equivale a una eficiencia 19 veces mayor. Esta ejecución más rápida mejora la experiencia del usuario. Además, liberar capacidad de cómputo permite incluir más transacciones en cada bloque, lo que aumenta directamente el rendimiento de la red.

Actualmente, las instrucciones del programa Token representan alrededor del 10% del uso de CU de todo el bloque. Al reducir su costo a solo el 5% de los niveles actuales, p-token puede disminuir esa proporción del 10% al 0.5% y liberar un 9.5% adicional de capacidad del bloque para otras transacciones. P-token también beneficia a los programas posteriores. Mejora la componibilidad al reducir el uso total de CU y el costo de las invocaciones entre programas (CPI).

A continuación se muestran, en una gráfica y una tabla, los datos que detallan la eficiencia de CU obtenida por las instrucciones de p-token frente al programa SPL Token actual.

Otra optimización destacada, posible en gran medida gracias a `no_std`, es la reducción del tamaño del binario del programa de 131 KB a 95 KB.

Instrucciones adicionales

P-token propone agregar al programa de tokens tres instrucciones nuevas (`withdraw_excess_lamports`, `batch` y `unwrap_lamports`) que no están presentes en el programa SPL Token original.

Retiro de lamports excedentes

Al igual que la implementación actual de SPL Token-2022, `withdraw_excess_lamports` permite recuperar el exceso de SOL “bloqueado” en la cuenta de acuñación. Esto suele ocurrir cuando un usuario envía lamports por error a la cuenta de acuñación del token.

El retiro requiere la autorización de la autoridad de acuñación, ya sea el firmante designado para las cuentas de acuñación estándar o la multifirma para las cuentas multifirma. Como la mayoría de los tokens SPL tienen revocada su autoridad de acuñación, también se puede proporcionar autorización mediante la propia cuenta de acuñación como autoridad firmante. En ese caso, la instrucción se firma con la clave privada de la cuenta de acuñación.

De todas las cuentas de acuñación de tokens SPL, ~869,000 tienen más SOL que el umbral mínimo de exención de renta, que es de 0.0014616 SOL. En conjunto, esto equivale a 176,961.5 SOL bloqueados en cuentas de acuñación de tokens, con un valor de $36 millones de USD al precio actual. Las mayores cantidades de SOL bloqueadas en cuentas de acuñación de tokens suelen estar vinculadas a memecoins, tokens antiguos y activos importantes de primera categoría. La mayor cantidad individual de SOL bloqueada en la cuenta de acuñación de un token corresponde a BOOK OF MEME ($BOME), una memecoin, con 6,328 SOL. La adopción de p-token podría permitir desbloquear estos saldos y generar una ganancia inesperada para los equipos responsables de estos tokens.

Lote

La segunda instrucción nueva es `batch`, que agiliza las interacciones CPI con el programa p-token. En lugar de invocar el programa de tokens varias veces, `batch` permite ejecutar una cantidad variable de instrucciones de tokens en una sola llamada. Esto significa que el costo base de CPI de 1,000 unidades se paga una sola vez y no por cada instrucción individual.

El resultado es una reducción considerable del uso de cómputo para los protocolos que dependen de varias CPI de tokens en una sola instrucción, un patrón común en DeFi de Solana. Por ejemplo, un AMM podría realizar dos transferencias en un swap, o un depósito en un pool de liquidez podría incluir tanto transferencias como acuñaciones. Al usar `batch`, los programas pueden lograr ahorros significativos de CU en estos escenarios.

Desenvolver lamports

La instrucción `unwrap_lamports` (agregada recientemente en un PR independiente) permite transferir lamports directamente a una cuenta de destino, lo que elimina la necesidad de crear cuentas temporales de tokens nativos.

Antes, desenvolver lamports desde una cuenta de SOL envuelto requería crear y luego cerrar una cuenta de token asociada (ATA) para el destinatario. Con esta actualización, los lamports ahora pueden transferirse directamente desde cuentas de SOL nativo, lo que simplifica el proceso.

Ruta rápida para instrucciones de transferencia

El análisis del uso del programa de tokens en mainnet muestra una fuerte concentración en las instrucciones de transferencia, que en conjunto representan casi la mitad de toda la actividad. Las cinco instrucciones más utilizadas son:

• transfer_checked (36.33%)
• transfer (13.22%)
• close_account (12.23%)
• initialize_account3 (9.98%)
• initialize_immutable_owner (9.78%)

Este patrón de uso revela una oportunidad para optimizar aún más p-token para las transferencias y reducir el consumo de CU. Cavey, de Temporal, aportó gran parte de este trabajo de optimización. Para conocer el enfoque en profundidad, consulta su transmisión en vivo en X.

Para conseguir estas mejoras, p-token introduce un punto de entrada personalizado con una ruta rápida para las instrucciones de transferencia y actualiza el procesador para priorizar `sync_native` y `initialize_immutable_owner`. En conjunto, estos cambios ofrecen mejoras importantes en la eficiencia de CU, en línea con los patrones de uso observados.

Registros

Con la introducción de p-token, una pregunta pendiente es si debe mantenerse el comportamiento actual de los registros. La versión más reciente de la propuesta recomienda eliminar los registros. En Solana, los registros son el mecanismo principal para extraer de los programas datos de depuración, monitoreo y eventos. En el programa de tokens existente, los registros son mínimos y se limitan a mostrar el nombre de la instrucción que se ejecuta. Por ejemplo:

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

Sin embargo, esta línea de registro aparentemente pequeña, `Instruction: <name>`, cuesta alrededor de 103 unidades de cómputo. En la práctica, esa sobrecarga puede consumir casi tanto cómputo como la propia instrucción. Por ejemplo, el registro representa aproximadamente el 40% del cómputo total necesario para una transferencia simple.

Además de su costo, estos registros no siempre son confiables. Pueden truncarse o manipularse mediante inyección de registros, lo que podría engañar a los analizadores posteriores. Por otro lado, eliminarlos por completo podría interrumpir los flujos de trabajo de desarrolladores y aplicaciones que actualmente dependen de ellos.

Eliminar los registros aumentaría la importancia de que los equipos publiquen IDL para ofrecer visibilidad sobre el comportamiento de los programas. Por ejemplo, Anchor ahora exige esto: publica IDL de forma predeterminada para todos los programas nuevos, a menos que se desactive explícitamente.

Auditoría

La auditoría del programa p-token ya está en curso para garantizar la seguridad y la compatibilidad total con versiones anteriores. Para que p-token se adopte, debe respetar estrictamente las instrucciones y las estructuras de cuentas exactas del programa Token actual y reproducir con precisión su comportamiento. Cualquier desviación supondría un riesgo, que se está abordando mediante pruebas exhaustivas y auditorías independientes.

Los auditores de Neodyme realizaron pruebas de equivalencia reproduciendo dos veces cada transacción de mainnet de los últimos meses: una con el programa de tokens original y otra con p-token. Los resultados confirmaron salidas idénticas y también demostraron ahorros considerables de CU.

Según su análisis, entre el 3 y el 11 de agosto de 2025, p-token habría reducido la sobrecarga en 8.9 billones de CU con los registros habilitados y en 9.14 billones de CU con los registros deshabilitados. Estas cifras representan ahorros del 12.0% y el 12.3% del uso total del espacio de bloque, respectivamente.

P-token se encuentra actualmente en una segunda auditoría por parte de Zellic y en un proceso de verificación formal por parte de Runtime Verification.

Implementación

El proceso de implementación previsto para p-token sigue un enfoque por etapas. Comienza con la finalización de la auditoría, las pruebas fuzzing y la verificación formal. Después, los validadores votarán sobre la adopción de p-token y se realizará la aceptación formal de SIMD 266. Luego, la función de p-token se implementará en el clúster y quedará detrás de una puerta de activación.

El programa se implementará primero en una cuenta designada (ptokN…UkkZ2). Cuando se active la puerta de activación en el límite de la época, el entorno de ejecución de todos los validadores reemplazará el programa de tokens existente (Tokenkeg…VQ5DA) por la nueva implementación mediante Upgradable Loader v3.

Un enfoque alternativo sería implementar el programa p-token en una dirección nueva, lo que obligaría a los usuarios y las aplicaciones a migrar manualmente. Sin embargo, esta opción no es la preferida, ya que probablemente dificultaría la adopción y reduciría los beneficios generales, pues muchos usuarios dudarían o tardarían en hacer el cambio.

Impacto económico

La adopción de p-token forma parte de un conjunto de mejoras destinadas a ampliar drásticamente la capacidad total de Solana, lo que permitirá incluir más transacciones en cada bloque. Otras actualizaciones importantes incluyen duplicar el espacio de bloque a 100 millones de CU y aumentar el límite de CU por cuenta de 12 millones fijos al 40% del bloque.

Actualmente, una sola cuenta está limitada a 12 millones de CU por bloque. Como muestra la siguiente gráfica de Anza, la cuenta con mayor contención de cada bloque alcanza este límite con frecuencia. P-token por sí solo hará que sea más difícil que las cuentas alcancen este límite, lo que reducirá la frecuencia de cuellos de botella en estados con mucha demanda.

Actualmente, casi todas las transacciones incluyen una tarifa de prioridad o una propina de Jito para incentivar a los validadores a incluirlas en un bloque. Como la prioridad se determina según la tarifa por CU, una transacción de p-token que consume menos CU debería, en igualdad de condiciones, recibir mayor prioridad por la misma tarifa o propina. Dicho esto, como todas las transacciones de tokens SPL se beneficiarán de la actualización de p-token, aún está por verse el impacto general sobre la priorización de transacciones.

Conclusión

La adopción de p-token, si supera una votación de gobernanza, representa un gran avance para mejorar la eficiencia y escalabilidad de Solana. Al reducir drásticamente el uso de cómputo y agilizar las interacciones CPI, refuerza la base del programa más utilizado de la red y amplía la capacidad total de los bloques. Si tiene éxito, p-token podría servir como modelo para desarrollar versiones optimizadas con Pinocchio de otros programas de uso generalizado, como el programa Associated Token Account (ATA) e incluso el programa System. Esto abriría el camino hacia un entorno de ejecución más rápido y eficiente.

Recursos adicionales

• Repositorio de p-token - GitHub
• Repositorio de Pinocchio - GitHub
• Solana Program Library (SPL) - GitHub
• Calculadora de ahorro de SOL de p-Token - SendAI