Los recién llegados a Solana frecuentemente se confunden con la distinción entre un “owner” (propietario) y una “authority” (autoridad). Este artículo intenta aclarar la confusión de la manera más concisa posible.
Owner vs Authority
Solo los programas pueden escribir datos en las cuentas — específicamente, solo en las cuentas de las que son owner. Un programa no puede escribir datos en cuentas arbitrarias.
Por supuesto, los programas no pueden escribir datos en las cuentas de forma espontánea. Necesitan recibir una instrucción de una wallet para hacerlo. Sin embargo, los programas generalmente solo aceptarán instrucciones de escritura para una cuenta en particular desde una wallet privilegiada: la authority.
El owner de una cuenta es un programa. Una authority es una wallet. Una authority envía una transacción a un programa y ese programa puede escribir en la cuenta.
Todas las cuentas en Solana tienen los siguientes campos, que en su mayoría se explican por sí mismos:
- Public Key
- lamport balance
- owner
- executable (una bandera booleana)
- rent_epoch (puede ignorarse para cuentas exentas de renta)
- data
Podemos ver esto ejecutando solana account <our wallet address> en la terminal (con el validador de Solana ejecutándose en segundo plano):
Nota algo interesante: ¡no somos el owner de nuestra wallet! La dirección 111...111 es el system program.
¿Por qué el system program es el owner de las wallets, en lugar de que las wallets sean dueñas de sí mismas?
Solo el owner de una cuenta puede modificar la data en ella.
La implicación es que no podemos modificar nuestro balance directamente. Solo el system program puede hacerlo. Para transferir SOL fuera de nuestra cuenta, enviamos una transacción firmada al system program. El system program verifica que poseemos la clave privada de la cuenta, y luego modifica el balance en nuestro nombre.
Este es un patrón que verás con frecuencia en Solana: solo el owner de la cuenta puede modificar la data en la cuenta. El programa modificará la data en la cuenta si ve una firma válida de una dirección predesignada: una authority.
Una authority es una dirección de la cual un programa aceptará instrucciones si ve una firma válida. Una authority no puede modificar una cuenta directamente. Necesita trabajar a través de un programa que sea el owner de la cuenta que está intentando modificar.
Sin embargo, el owner siempre es un programa, y ese programa modificará la cuenta en nombre de otra persona si la firma para la transacción es válida.
Vimos esto por ejemplo, en nuestro tutorial sobre cómo modificar cuentas con diferentes firmantes.
Ejercicio: Crea un programa que inicialice una cuenta de almacenamiento. Querrás tener a mano la dirección del programa y las cuentas de almacenamiento. Considera agregar el siguiente código a las pruebas:
console.log(`program: ${program.programId.toBase58()}`);
console.log(`storage account: ${myStorage.toBase58()}`);
Luego ejecuta solana account <storage account> en la cuenta que fue inicializada. Deberías ver que el owner es el programa.
Aquí hay una captura de pantalla de la ejecución del ejercicio:
Cuando miramos los metadatos de la cuenta de almacenamiento, vemos que el programa es el owner.
Debido a que el programa es el owner de la cuenta de almacenamiento, es capaz de escribir en ella. Los usuarios no pueden escribir directamente en la cuenta de almacenamiento; firman una transacción y le piden al programa que escriba la data.
El owner en Solana es muy diferente del owner en Solidity
En Solidity, solemos referirnos al owner como una dirección especial con privilegios de administrador sobre el smart contract. El “owner” no es un concepto que exista a nivel del runtime de Ethereum, es un patrón de diseño aplicado a los contratos de Solidity. Un owner en Solana es mucho más fundamental. En Ethereum, un smart contract solo puede escribir en sus propias storage slots. Imagina que tuviéramos un mecanismo para permitir que un smart contract de Ethereum pudiera escribir en alguna otra storage slot. En términos de Solana, se convertiría en el owner de esas storage slots.
Authority puede referirse a quién desplegó un contrato y quién puede enviar transacciones de escritura para una cuenta en particular
Una authority puede ser un constructo a nivel del programa. En nuestro tutorial sobre Anchor signers, hicimos un programa en el que Alice podía deducir puntos de su cuenta para transferirlos a otra persona. Para saber que solo Alice puede enviar una transacción de deducción para esa cuenta, almacenamos su dirección en la cuenta:
#[account]
pub struct Player {
points: u32,
authority: Pubkey
}
Solana utiliza un mecanismo similar para recordar quién desplegó un programa. En nuestro tutorial sobre Anchor deploy, notamos que la wallet que desplegó un programa también puede actualizarlo.
Actualizar (upgrading) un programa es lo mismo que escribir nueva data en él — es decir, nuevo bytecode. Solo el owner del programa puede escribir en él (este programa es BPFLoaderUpgradeable, como veremos pronto).
Por lo tanto, ¿cómo sabe Solana otorgar privilegios de actualización a la wallet que desplegó un cierto programa?
Ver la authority de un programa desde la línea de comandos
Antes de desplegar el programa, veamos qué wallet está utilizando anchor ejecutando solana address en la terminal:
Toma en cuenta que nuestra dirección es 5jmi...rrTj. Ahora vamos a crear un programa.
Asegúrate de que solana-test-validator y solana logs se estén ejecutando en segundo plano, luego despliega el programa de Solana:
anchor init owner_authority
cd owner_authority
anchor build
anchor test --skip-local-validator
Cuando observamos los registros (logs), vemos la dirección del programa que acabamos de desplegar:
Recuerda, todo es una cuenta en Solana, incluyendo los programas. Ahora inspeccionemos esta cuenta usando solana account 6Ye7CgrwJxH3b4EeWKh54NM8e6ZekPcqREgkrn7Yy3Tg. Obtenemos el siguiente resultado:
Nota que el campo authority está ausente, porque “authority” no es un campo que las cuentas de Solana posean. Si te desplazas hacia arriba hasta la parte superior de este artículo, verás que las claves (keys) en la consola coinciden con los campos que enumeramos al principio del artículo.
Aquí, el “owner” es BPFLoaderUpgradeable111...111, que es el owner de todos los programas de Solana.
Ahora ejecutemos solana program show 6Ye7CgrwJxH3b4EeWKh54NM8e6ZekPcqREgkrn7Yy3Tg, donde 6Ye7...y3TG es la dirección de nuestro programa:
En el recuadro verde de arriba, vemos la dirección de nuestra wallet — la que se utilizó para desplegar el programa y la que imprimimos anteriormente con solana address:
Pero esto nos lleva a una pregunta importante…
¿Dónde almacena Solana la “authority” para el programa, que actualmente es nuestra wallet?
No es un campo en una cuenta, por lo que debe estar en el campo data de alguna cuenta de Solana. La “authority” se almacena en la ProgramData Address donde se almacena el bytecode del programa:
Codificación hexadecimal de nuestra wallet (la authority)
Antes de continuar, será útil convertir la codificación base58 de la ProgramData Address a una representación hexadecimal. El código para lograr esto se proporciona al final del artículo, pero por ahora le pedimos al lector que acepte que la representación hexadecimal de la dirección de nuestra wallet de Solana 5jmigjgt77kAfKsHri3MHpMMFPo6UuiAMF19VdDfrrTj es:
4663b48dfe92ac464658e512f74a8ee0ffa99fffe89fb90e8d0101a0c3c7767a
Ver los datos en la cuenta ProgramData Address donde se almacena el ejecutable
Podemos ver la cuenta ProgramData Address con solana account, pero también la enviaremos a un archivo temporal para evitar volcar demasiados datos en la terminal.
solana account FkYygT7X7qjifdxfBVWXTHpj87THJGmtmKUyU4SamfQm > tempfile
head -n 10 tempfile
La salida de los comandos anteriores muestra nuestra wallet (en hex) incrustada en la data. Observa que el código hexadecimal subrayado en amarillo coincide con la codificación hexadecimal de nuestra wallet (la authority):
El bytecode de un programa se almacena en una cuenta separada, no en la dirección del programa
Esto debería deducirse de la secuencia de comandos anterior, pero vale la pena declararlo explícitamente. Aunque un programa es una cuenta que está marcada como executable, el bytecode no se almacena en su propio campo de data, sino en otra cuenta (lo cual, de manera algo confusa, no es executable; simplemente almacena bytecode).
Ejercicio: ¿Puedes encontrar dónde el programa almacena la dirección de la cuenta que contiene el bytecode? El apéndice en este artículo tiene código que puede ser útil.
Resumen
Solo el owner de un programa puede cambiar su data. El owner de los programas de Solana es el system program BPFLoaderUpgradeable, por lo que, de forma predeterminada, la wallet que desplegó el programa no puede cambiar la data (bytecode) almacenada en una cuenta.
Para permitir la actualización de los programas, el runtime de Solana incrusta la wallet del deployer en el bytecode del programa. Se refiere a este campo como la “authority”.
Cuando la wallet que realiza el despliegue intenta actualizar el bytecode, el runtime de Solana verificará si el firmante de la transacción es la authority. Si el firmante de la transacción coincide con la authority, entonces el BPFLoaderUpgradeable actualizará el bytecode del programa en nombre de la authority.
Apéndice: conversión de base 58 a hexadecimal
El siguiente código en Python logrará la conversión. Fue generado por un chatbot y, por lo tanto, solo debe usarse con fines ilustrativos:
def decode_base58(bc, length):
base58_digits = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
n = 0
for char in bc:
n = n * 58 + base58_digits.index(char)
return n.to_bytes(length, 'big')
def find_correct_length_for_decoding(base58_string):
for length in range(25, 50): # Trying lengths from 25 to 50
try:
decoded_bytes = decode_base58(base58_string, length)
return decoded_bytes.hex()
except OverflowError:
continue
return None
# Base58 string to convert
base58_string = "5jmigjgt77kAfKsHri3MHpMMFPo6UuiAMF19VdDfrrTj"
# Convert and get the hexadecimal string
hex_string = find_correct_length_for_decoding(base58_string)
print(hex_string)
Aprende más con RareSkills
¡Consulta nuestro curso de desarrollo en Solana para aprender más temas sobre Solana! Para otros temas de blockchain, consulta nuestro bootcamp de blockchain.
Publicado originalmente el 11 de marzo de 2024