NUEVO: Helius adquiere Light Protocol
¿Qué son las extensiones de tokens?
Blog/Investigación

¿Qué son las extensiones de tokens?

Ingeniero de experiencia del desarrolladorOwen Venter en XOwen Venter en LinkedIn
13 min de lectura

Los avances en el ecosistema de Solana han sido rápidos durante el último año y se están lanzando muchas tecnologías nuevas y emocionantes. Solana es reconocida por sus velocidades de procesamiento ultrarrápidas y sus bajas comisiones por transacción, pero incluso con estas ventajas siempre hay espacio para mejorar. Aquí entran las extensiones de tokens, un nuevo programa de tokens diseñado para mejorar la funcionalidad actual de los tokens en Solana. Veamos qué ofrece el estándar de extensiones de tokens al ecosistema de Solana.

El programa de tokens actual en Solana

Todos los tokens de Solana que no sean el token nativo $SOL se consideran tokens SPL. Esto incluye tanto tokens fungibles, como $BONK, como tokens no fungibles (NFT). El programa de tokens define funciones comunes para crear y utilizar tokens fungibles y no fungibles. Ofrece algunas funciones a las que los desarrolladores y usuarios finales ya están acostumbrados. Estas operaciones incluyen acuñar, transferir y quemar tokens. También permite actualizar y congelar tokens. Esto ofrece la posibilidad de congelar una cuenta de tokens e impedir cambios en su estado hasta que se descongele.

¿Qué son las extensiones de tokens y por qué son necesarias?

Puedes pensar en las extensiones de tokens como una versión nueva y mejorada del programa de tokens de Solana. Pueden gestionar tokens fungibles y no fungibles. Este nuevo programa conserva todas las funciones del programa de tokens anterior, pero ahora incluye un conjunto de funciones útiles diseñadas para mejorar la funcionalidad de los tokens en Solana. Estas nuevas funciones, que son la verdadera magia de Token2022, se presentan como extensiones.

Pero ¿por qué son necesarias las extensiones de tokens? A medida que Solana avanza, crece la demanda de funciones de tokens más complejas y adaptables. Aunque el programa de tokens actual de Solana ha cubierto las necesidades básicas de los tokens fungibles y no fungibles con un conjunto sencillo de funciones, esa simplicidad impone límites que pueden frenar la innovación. Los desarrolladores con ideas nuevas a menudo han tenido que bifurcar el programa de tokens para agregar las funciones necesarias, lo que dificulta su adopción generalizada. El modelo de programación de Solana exige incluir tanto programas como cuentas en las transacciones. Esto complica la creación de transacciones que involucran varios programas de tokens. Además, las billeteras y los programas on-chain deben confiar en cualquier programa de tokens que decidan admitir, lo que puede ser arriesgado. Ante este panorama cambiante, Solana presenta Token2022: un conjunto de funciones y mejoras adicionales diseñado para ampliar las capacidades de los tokens dentro del ecosistema.

Presentamos las extensiones: un paso evolutivo

Las capacidades revolucionarias de este nuevo estándar están en las extensiones disponibles, un conjunto de campos nuevos incorporados para cubrir distintas necesidades. En términos sencillos, una extensión en el contexto de las extensiones de tokens es una función o característica adicional que puede agregarse a un token para mejorar sus capacidades y utilidad. Las extensiones permiten que los creadores personalicen el comportamiento y las características de sus tokens según necesidades u objetivos específicos. Al crear un token, puedes elegir cualquier cantidad de estas extensiones. Analicemos algunas de las extensiones principales y su posible impacto en el ecosistema de Solana. Es importante señalar que no todas estas extensiones están disponibles actualmente.

Extensiones de acuñación

Estas son las explicaciones de cada extensión de acuñación:

1. Comisiones de transferencia

Aunque el programa de tokens existente no permite aplicar comisiones a las transferencias, el estándar de extensiones de tokens cambia esto al permitir configurar una comisión de transferencia en el nivel del protocolo. Este mecanismo introduce un nuevo grado de control financiero sobre las transacciones.

2. Hooks de transferencia

La extensión de hook de transferencia ofrece a los creadores de tokens una capa adicional de control sobre las transferencias de sus tokens. Esto resulta especialmente importante para gestionar los desafíos relacionados con las regalías de NFT. La extensión funciona al permitir que los creadores de tokens desarrollen programas personalizados que se ejecutan cada vez que se transfieren los tokens. Cuando se inicia una transferencia, el token se comunica con este programa personalizado, lo que permite ejecutar cualquier acción posterior.

3. Cierre de la acuñación

Las extensiones de tokens cubren una carencia importante del programa de tokens al permitir que una dirección elegida cierre las cuentas de acuñación, algo que antes era imposible. Esto se consigue inicializando la extensión MintCloseAuthority antes de inicializar la acuñación. Así, alguien distinto de la billetera con autoridad puede cerrar la acuñación de un token.

4. Tokens que generan intereses

Las extensiones de tokens incorporan una extensión InterestBearingMint que permite representar de forma diferente en la interfaz la cantidad de tokens e incluir los intereses acumulados. En esencia, esta función permite que los tokens «generen intereses», por lo que adquieren más valor cuanto más tiempo los conservas.

5. Tokens no transferibles (tokens Soulbound)

La extensión de acuñación NonTransferable permite crear tokens «Soulbound» que no pueden moverse de una billetera. Es ideal para logros o recompensas únicas. Estos tokens también pueden ser muy útiles como entradas para eventos, ya que no podrías enviar la entrada a otra persona.

6. Transferencias confidenciales

Las extensiones de tokens incorporan una nueva extensión de tokens confidenciales, conocida como transferencias confidenciales. Esta función de privacidad utiliza pruebas de conocimiento cero para cifrar los saldos y los importes de las transferencias de tokens SPL.

El objetivo general de esta extensión es mejorar la privacidad de los usuarios al centrarse en la confidencialidad, no en el anonimato. Como los saldos pueden sumarse o restarse, el estándar de extensiones de tokens necesita un esquema de cifrado que permita realizar estas operaciones matemáticas ocultas; el cifrado debe ser homomórfico. El cifrado homomórfico es una clase especial de esquema de cifrado que permite realizar determinados tipos de cálculos sobre datos cifrados sin tener que descifrarlos. De este modo, estos cálculos ocultos producen un resultado cifrado que, al descifrarse, equivale al resultado de aplicar las mismas operaciones matemáticas en texto sin formato. Las transferencias confidenciales usan el «cifrado ElGamal retorcido» para permitir operaciones matemáticas ocultas sobre texto cifrado.

Como dato adicional para quienes quieran profundizar, el cifrado ElGamal retorcido es una variante sencilla del esquema de cifrado ElGamal estándar en la que un texto cifrado se divide en un compromiso de Pedersen del mensaje cifrado y un identificador de descifrado que permite realizar operaciones matemáticas ocultas sobre el texto cifrado.

Las transferencias confidenciales se validan mediante protocolos Sigma, una clase específica de pruebas de conocimiento cero en la que una parte, quien demuestra, puede probarle a otra, quien verifica, que conoce un secreto sin revelar el secreto. Estos protocolos Sigma son necesarios para varias instrucciones incluidas en la extensión. Analicemos cada prueba:

Prueba de validez (de clave pública)

  • Verifica que una clave pública Twisted ElGamal tenga el formato correcto
  • Es como validar la «identificación digital» de otra persona antes de iniciar un chat seguro
  • Es necesaria para la instrucción ConfigureAccount

Prueba de validez (de texto cifrado)

  • Garantiza que el mensaje cifrado esté bien formado
  • Es como recibir una caja sellada: sabes que nadie la ha manipulado porque sigue sellada
  • Es necesaria para las instrucciones Withdraw, Transfer y TransferWithFee

Prueba de saldo cero

  • Demuestra que el texto cifrado Twisted ElGamal cifra el número cero
  • Es como comprobar que el saldo de tu cuenta bancaria es cero sin abrir la aplicación del banco
  • Es necesaria para la instrucción EmptyAccount

Prueba de igualdad

  • Confirma dos tipos de igualdad: entre dos textos cifrados ElGamal o entre un texto cifrado ElGamal y un compromiso de Pedersen
  • Es como tener dos cobertizos cerrados llenos de herramientas y demostrar que ambos contienen exactamente las mismas herramientas sin abrirlos
  • Es necesaria para las instrucciones Transfer, TransferWithFee, WithdrawWithheldTokensFromMint y WithdrawWithheldTokensFromAccounts

Prueba Sigma de comisión

  • Demuestra que una comisión de transferencia comprometida es correcta
  • Es como confirmarle a FedEx que pagaste los aranceles de tu paquete sin mostrar el importe exacto que pagaste
  • Es necesaria para la instrucción TransferWithFee

Prueba de rango

  • Confirma que un número cifrado se encuentra dentro de un rango determinado
  • Es como estimar la estatura de una persona y demostrar que tu estimación está dentro de un rango correcto sin revelar su estatura real
  • Solana utiliza Bulletproofs para estas pruebas. Puedes obtener más información en este artículo académico y en su implementación dalek

En resumen: estas pruebas de conocimiento cero se utilizan para validar que una parte conoce un secreto que otra puede verificar sin decirlo en voz alta. Los distintos tipos de pruebas garantizan que los saldos y las transferencias de tokens funcionen matemáticamente según lo previsto y de forma completamente privada mediante cifrado.

Solo el titular de la cuenta, que posee la clave de descifrado, puede ver su saldo en este sistema confidencial. Sin embargo, puede haber casos en los que un tercero externo necesite revisar los saldos, ya sea para fines de auditoría o de cumplimiento normativo. La extensión de tokens confidenciales lo permite mediante su sistema de auditor global. En este sistema, cada cuenta puede tener una clave de descifrado independiente, por lo que el titular puede dar acceso de lectura de forma selectiva a cuentas específicas. La acuñación, o la entidad que emite los activos, tiene una estructura de datos especial que puede incluir opcionalmente una «clave de cifrado del auditor» global. El código es el siguiente:

Código
Transfer {
  amount_sender: PKE::encrypt(pke_pubkey_sender, 10),
  amount_receiver: PKE::encrypt(pke_pubkey_receiver, 10),
  amount_auditor: PKE::encrypt(pke_pubkey_auditor, 10),
  range_proof: RangeProof,
  equality_proof: EqualityProof,
  ...
}

El parámetro amount_auditor es el importe de la transferencia cifrado con la clave pública de cifrado del auditor. Cualquiera que tenga la clave secreta del auditor puede descifrar amount_auditor y, por tanto, auditar los importes de las transacciones de una acuñación específica.

Si te interesa la seguridad, quizá hayas detectado un posible defecto en este diseño. Supongamos que Alice genera una prueba con respecto a su saldo cifrado. Al mismo tiempo, Bob envía tokens a Alice y su transacción se procesa primero. La transacción de Alice se rechazaría porque la prueba generada no reflejaría el nuevo estado actualizado de la cuenta. Este tipo de ataque, conocido como front-running, podría inutilizar la cuenta de Alice si Bob saturara continuamente la red con transferencias a su cuenta. Para evitar este tipo de ataque, el saldo cifrado de una cuenta se divide entre su saldo pending y su saldo available:

Código
let ct_pending = PKE::encrypt(pke_pubkey, 10);
let ct_available = PKE::encryption(pke_pubkey, 50);

Account {
    mint: Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB,
    owner: 5vBrLAPeMjJr9UfssGbjUaBmWtrXTg2vZuMN6L4c8HE6,
    encryption_key: mpbpvs1LksLmdMhCEzyu5UEWEb3dsRPbB5,
    pending_balance: ct_pending,
    account_balance: ct_available,
    ...
}

Todos los fondos salientes se restan del saldo disponible, mientras que los fondos entrantes se agregan al saldo pendiente.

Las transferencias confidenciales aún no están disponibles y la documentación de Solana correspondiente a las secciones de introducción y guía de inicio rápido sigue en desarrollo. Sin embargo, puedes seguir las tareas pendientes de las transferencias confidenciales en este issue de GitHub del repositorio solana-program-library. La documentación incluye un análisis detallado del protocolo, pero es importante señalar que no necesitas comprender su contenido para usar la extensión. El resumen sencillo de las transferencias confidenciales presentado en los párrafos anteriores debería ser más que suficiente para comenzar a utilizarlas cuando todo esté disponible.

Extensiones de cuenta

Estas son las explicaciones de cada extensión de cuenta:

1. Memo obligatorio en transferencias entrantes

Las extensiones de tokens incluyen una función para exigir memos en todas las transferencias entrantes. Los memos son básicamente mensajes breves on-chain. Esta función es similar a recibir una nota con un regalo para saber quién te lo envió y por qué.

2. Propiedad inmutable

La extensión ImmutableOwner agrega una capa de seguridad al impedir que la propiedad de una cuenta pueda reasignarse. Esta medida mejora la seguridad de las transacciones de tokens. Para entenderlo mejor, debemos analizar cómo se almacenan los tokens en el programa de tokens estándar. Normalmente, cuando quieres enviar un token a una billetera, el primer paso es crear una cuenta de tokens dentro de la billetera del destinatario para almacenar ese token. Esta cuenta se genera combinando la dirección de acuñación del token y la dirección de la billetera del destinatario. Todo funciona bien, salvo por el hecho de que, una vez creada la cuenta, su propiedad puede transferirse a otra persona. Con la extensión de propietario inmutable de Token2022, esto ya no será posible.

3. Estado predeterminado de la cuenta

La extensión DefaultAccountState permite que los creadores de una acuñación restrinjan el uso de los tokens al configurar todas las cuentas de tokens nuevas como congeladas de forma predeterminada. Esto ofrece una capa adicional de control sobre la distribución y el uso de los tokens. Significa que podrías recibir un token, pero no podrías hacer nada con él hasta que sus creadores lo permitan.

4. Delegado permanente

Con las extensiones de tokens es posible especificar un delegado permanente de cuenta para un token. En esencia, puedes designar a alguien, un delegado, que siempre tendrá autoridad para gestionar los tokens de una acuñación. Puede realizar acciones como transferir o quemar tokens. Si se usa esta extensión, la autoridad tendrá privilegios de delegado ilimitados sobre cualquier cuenta de esa acuñación. Esto puede ser muy peligroso, ya que ese delegado podría transferir o quemar tokens de la billetera de cualquier persona.

Extensiones de tokens frente a Ethereum y Binance Smart Chain (BSC)

Ethereum y Binance Smart Chain (BSC) ya han logrado avances importantes en el espacio DeFi, y hemos visto algunas funciones de las extensiones de tokens en tokens de esas cadenas.

Un ejemplo es SafeMoon en BSC, que introdujo una comisión del 10 % en cada transacción. El 5 % se redistribuye entre otros titulares de SafeMoon. Esto los anima a hacer HODL. El concepto de transferencias confidenciales mediante pruebas de conocimiento cero tampoco es nuevo. En Ethereum, proyectos como Aztec Protocol han explorado las transacciones privadas.

Aunque Solana tardó un poco más en ofrecer estas funciones, su velocidad superior y sus menores costos de transacción crean un entorno favorable para que las extensiones de tokens prosperen. Esto le da una ventaja competitiva frente a Ethereum y BSC.

Primeros usuarios de las extensiones de tokens

Los desarrolladores, las dApps y las billeteras deben adaptarse a estas nuevas funciones para aprovechar al máximo lo que ofrecen las extensiones de tokens. Estas son algunas de las primeras adopciones del nuevo programa:

$BERN / BonkEarn

$BERN, creado por la comunidad de $BONK, es uno de los primeros tokens desarrollados sobre el programa de extensiones de tokens. Actualmente, $BERN utiliza la extensión de comisión de transferencia para cobrar un 6,9 % en todas las transferencias. El equipo de $BERN usa esta comisión para recompensar tanto a los titulares de $BERN como a los de $BONK.

Desglose completo:

  • 5 % para la «comisión Bernzy Bonus», que se usará para recompensar a los titulares de $BERN
  • 1 % para comprar y quemar $BONK
  • 0,5 % para quemar $BERN
  • 0,3 % para el fondo de desarrolladores, destinado a pagar más comisiones y aportar liquidez al pool del token.
  • 0,1 % para la DAO de $BONK

Exchanges descentralizados

FluxBeam es un DEX de Solana que actualmente admite tokens creados con el programa de extensiones de tokens.

Billeteras

Backpack, una popular extensión de billetera, ya es compatible con las extensiones de tokens y Phantom pronto incorporará esta funcionalidad.

Herramientas

Ya están disponibles en FluxBeam las herramientas para acuñar tu propio token con el programa de extensiones de tokens.

RugCheck es una herramienta para analizar los mercados de tokens de Solana y distintos tokens. Ya permite verificar tokens creados con Token 2022.

Adopta el futuro

La incorporación de las extensiones de tokens representa un enorme avance en el recorrido web3 de Solana. Aporta una variedad de funciones nuevas y amplía las capacidades de las funciones existentes. Sus innovadoras extensiones no solo ofrecen a los creadores de tokens más control y flexibilidad, sino que también abren nuevas posibilidades en el espacio DeFi. Aunque otras blockchains ya ofrecen funciones similares, la ventaja de Solana en velocidad y costos, junto con las funciones de Token2022, la convierten en una competidora formidable en el mundo de las criptomonedas. A medida que sigue creciendo el apoyo de los primeros usuarios y de la comunidad en general, Token2022 está lista para mejorar y llevar el ecosistema de Solana a un nuevo nivel.

Suscríbete a Helius

Mantente al día con las novedades del desarrollo en Solana y recibe actualizaciones cuando publiquemos