Billeteras y firmas

Curiosidad

1. ¿Por qué una transacción de Solana tiene una fecha de vencimiento?
2. ¿Qué es exactamente lo que se aprueba cuando un usuario firma una transacción con versión?
3. ¿Cómo puede una transacción hacer referencia a muchos más cuentas de los que enumera por completo?

Explorar

1. Las claves de Solana son pares de claves ed25519. La mayoría de las billeteras las derivan a partir de una frase semilla BIP39 utilizando la ruta de derivación m/44’/501’/0’/0’. Este estándar permite a los usuarios recuperar toda su identidad en diferentes software compatibles, siempre y cuando conserven el mnemónico original de doce o veinticuatro palabras. La clave privada permanece local; la clave pública funciona en la cadena como la dirección de la cuenta.
2. Una transacción enumera instrucciones específicas y las cuentas que afectan dichas instrucciones. Lo más importante es que incluye un hash de bloque reciente. Este hash funciona como mecanismo de vencimiento: si la transacción no se procesa en aproximadamente 150 bloques, es decir, en unos 60 a 90 segundos, el hash de bloque se vuelve obsoleto y la red rechaza la transacción. Los códigos únicos duraderos permiten a los usuarios firmar transacciones que permanecen válidas durante períodos más largos, utilizando un valor almacenado en una cuenta especial de códigos únicos en lugar de un hash de bloque reciente.
3. Firmar aprueba todas las instrucciones contenidas en la transacción. Una carga útil maliciosa puede transferir cuentas de tokens o cambiar sus configuraciones de autoridad sin que el usuario sea consciente de esas subinstrucciones específicas. Billeteras como Phantom, Solflare y Backpack simulan estas transacciones para ofrecer vistas previas legibles por humanos. Sin embargo, los usuarios aún pueden aprobar instrucciones dañinas a través de la «firma ciega», en la que se aceptan los datos brutos sin verificar su intención.
4. Las transacciones versionadas introducen tablas de búsqueda de direcciones, lo que permite que una sola transacción haga referencia a muchas cuentas mediante índices en lugar de listar todas las direcciones completas. Esta optimización reduce el tamaño en bytes de las operaciones complejas que involucran numerosas emisiones de tokens o posiciones. El compromiso es la complejidad; para comprender las direcciones resultantes es necesario decodificar los índices de la tabla según el estado actual de la cuenta a la que se hace referencia.
5. Las billeteras de hardware ofrecen un entorno aislado para firmar, con conexión a través de USB o códigos QR, para proteger las claves del malware del sistema anfitrión. Sin embargo, la seguridad depende de la integridad de la aplicación anfitriona que genera y muestra los datos de la transacción. Si el sistema anfitrión es comprometido, puede mostrar información maliciosa mientras el usuario firma lo que parece legítimo. Verificar todos los parámetros directamente en la pantalla del dispositivo de hardware mitiga este vector de ataque específico.
6. Para inspeccionar la estructura de una transacción, abra un explorador de bloques de Solana y seleccione cualquier transacción reciente que involucre una operación de múltiples pasos. Expanda la sección “Instrucciones” para ver cada llamada al programa por separado. Luego, examine la pestaña “Cuentas” para saber qué cuentas fueron leídas o escritas por cada instrucción. Compare esto con los datos brutos para comprender cómo la vista previa de la simulación se relaciona con los cambios reales en el estado.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Solana Documentation: Transactions and Durable Nonces
• Phantom Developer Documentation: Signing and Simulation
• BIP39: Mnemonic Code for Generating Deterministic Keys
• Solana Documentation: Versioned Transactions and Address Lookup Tables