O que é um program derived address (PDA)?

Program Derived Addresses (PDAs) são contas na blockchain Solana que têm propriedades especiais. Usar PDAs corretamente pode tornar o desenvolvimento de dApps Solana rápido e eficiente, já que elas ajudam na comunicação entre programas.

Este artigo vai explicar o que são PDAs, quais problemas elas resolvem, como funcionam e como são diferentes de outras contas no modelo de contas da Solana.

O que é uma program derived address (pda)?

Uma Program Derived Address é uma conta na blockchain Solana que não tem uma chave privada. Como uma PDA não é uma chave pública, o endereço da conta é encontrado usando o ID do programa, uma função de hash SHA-512, um array de seeds e uma seed especial chamada bump.

O que é uma conta padrão na Solana?

Uma conta padrão da Solana tem tanto uma chave privada quanto uma chave pública (32 bytes cada), que juntas formam um keypair de 64 bytes, situado em uma curva elíptica (ED25519). Para que o keypair seja válido, ele precisa estar nessa curva.

Aqui está uma representação de uma curva elíptica ED25519:

Como os program addresses são derivados?

PDAs exigem três componentes principais:

1. Parent Program ID - o ID do programa pai que cria a PDA
2. Seeds - um array de strings
3. Bump Seed - garante que a PDA não tenha uma chave privada

Criar uma Program Derived Address válida requer pegar o ID do programa pai e o array de seeds, e passá-los por uma função de hash SHA-512.

Em cerca de 50% dos casos, no entanto, o resultado desse hash é um keypair que está sobre a curva elíptica ED25519. Como PDAs não têm chave privada, Program Derived Addresses não podem estar sobre a curva elíptica. Para impedir que PDAs tenham chaves privadas, uma seed especial de bump é usada para "empurrar" o resultado do hash para fora da curva.

O bump seed é simplesmente um número, começando em 255. Caso, mesmo com o bump seed, o resultado do hash ainda esteja sobre a curva, a função de hash é executada novamente, com um bump equivalente a 254, depois 253, e assim por diante, até que o resultado gerado não esteja sobre a curva.

Nota: As seeds podem ser qualquer string arbitrária, mas os desenvolvedores as usam em um contexto específico das variáveis de estado do programa pai para criar estruturas parecidas com hashmaps.

Quais problemas as PDAs resolvem?

Program derived addresses simplificam a confirmação de transações ao gerar assinaturas de transação de forma programática, ajudando serviços trustless, como contas DeFi, a funcionar sem problemas.

Aqui está um exemplo hipotético de caso de uso para PDAs.

Considere um programa Solana que permite ao usuário definir um NFT como sua foto de perfil (PFP) padrão. O programa será composto por dois programas:

1. O programa PFP - cria contas para armazenar a foto de perfil selecionada pelo usuário
2. O programa Core - atua como um proxy entre as entradas do usuário e o programa PFP

Para que o programa PFP atualize a foto de perfil selecionada de um usuário, ele precisaria usar sua chave privada para assinar uma transação que mudaria a foto de perfil do usuário. No entanto, isso também significaria que o programa precisaria armazenar sua chave privada on-chain.

Um programa Solana não pode usar sua chave privada para assinar uma transação em seu próprio nome, porque a própria chave ficaria armazenada on-chain, visível para todos. Se isso acontecesse, a chave privada poderia ser usada para assinar transações em nome do programa e mudar a foto de perfil de qualquer usuário.

Imagine que o programa PFP fosse responsável por gerenciar milhões de tokens SOL. Uma falha desse tipo se tornaria um grande hack. Program Derived Addresses resolvem esse problema.

Por que as PDAs são importantes?

Program Derived Addresses desempenham um papel fundamental na programação Solana porque ajudam na comunicação entre diferentes programas (Cross Program Invocations) e podem funcionar como um hashmap para armazenar dados específicos que seu programa pai pode atualizar e alterar facilmente.

1. Armazenamento das variáveis de estado de um programa

PDAs permitem que desenvolvedores Solana armazenem e rastreiem uma variável ou um conjunto de variáveis relacionadas a um usuário específico. O melhor caso de uso de uma PDA é armazenar variáveis de estado ou dados para seu programa pai, já que, por padrão, ela autoriza o programa pai a fazer alterações em seu nome.

2. Usar PDAs como hashmaps

Mapping representa um conjunto de pares chave-valor, e é usado para encontrar facilmente informações associadas a uma chave. No desenvolvimento em Solana, as seeds de uma PDA e as strings corretas podem ser usadas para alcançar o mesmo resultado.

Vamos voltar ao nosso exemplo anterior da foto de perfil da carteira.

Assim que um usuário seleciona a PFP de sua carteira, o programa PFP pega a imagem selecionada e o endereço do usuário, e os usa como 'seeds' para criar uma PDA que armazenará a escolha do usuário.

Assim que a Program Derived Address é encontrada com sucesso pelo algoritmo de hash, sua chave pública é 'mapeada' para o endereço do usuário e o avatar NFT escolhido.

O recurso de hashmap pode ser aproveitado ainda melhor fornecendo outra PDA como terceira seed. Podemos pegar todas as fotos de perfil disponíveis e armazená-las em uma PDA separada, passando cada foto de perfil como sua seed, e acabamos com uma PDA que armazena todas as fotos de perfil.

Agora, quando um usuário vem e escolhe sua foto de perfil, a PDA vai parecer um hashmap, porque as seeds são passadas de forma que, ao observá-las, você saiba que, dentre um conjunto de fotos de perfil (a PDA do grupo PFP), o endereço de um usuário que passamos como primeira seed escolheu a foto de perfil que passamos como segunda seed.

Esse exemplo pode ser expandido para criar estruturas de hashmap ainda mais profundas.

3. Cross program invocations

Cross Program Invocations (CPI) é o processo de um programa chamar uma função em outro programa. CPIs são úteis porque permitem uma melhor composabilidade de código.

Voltando ao nosso exemplo, digamos que um usuário queira mudar sua foto de perfil de um Degen Ape para um avatar da Solana Monkey Business.

Veja o que acontece por baixo dos panos:

Ao fazer login em sua carteira, o contrato core vai pegar o endereço do usuário (chave pública) e procurar uma PDA já criada, cujas seeds incluam a chave pública do usuário.

Depois de encontrá-la, o programa core vai invocar uma função no programa PFP chamada 'changePFP()' (isso é uma Cross-Program Invocation), que aceitaria como argumento a PDA que já foi 'selecionada' pelo programa Core.

Assim que a função é chamada, a PDA selecionada vai verificar se a conta que está 'solicitando' a mudança é seu programa pai. Se houver uma incompatibilidade, a transação será rejeitada, porque somente um programa pai pode modificar os dados de uma PDA.

Como o programa PFP é o pai da PDA selecionada, ele terá permissão para mudar a foto de perfil selecionada do usuário de um Degen Ape para um avatar SMB.

Program Derived Addresses permitem que seus programas pais assinem em seu nome e podem ser usadas para armazenar o estado de um programa, hashmaps e em cross-program invocations. PDAs são um tópico fundamental no universo da programação Solana, que possibilita um desenvolvimento de dApps rápido e eficiente.

Perguntas frequentes sobre program derived address

Ao trabalhar com Program Derived Addresses, pode ser útil entender como a Solana lida com transações e dados. Os dois tipos principais de contas são executáveis e não executáveis.

O que é uma conta executável?

Contas executáveis, também conhecidas como programas, são semelhantes a um smart contract da Ethereum — um trecho de código que muda seu estado quando uma conta interage com ele.

O que é uma conta não executável?

Contas de dados não executáveis são usadas simplesmente para armazenar dados (por exemplo, a quantidade de SOL que a conta possui, NFTs, saldos de tokens, etc.), ou seja, as variáveis de estado de um programa.

Como o armazenamento de dados de programas na Solana é diferente dos smart contracts da Ethereum?

Uma diferença fundamental entre Ethereum e Solana é como o armazenamento de código executável é organizado. Smart contracts na Ethereum já vêm 'prontos' com um storage onde o smart contract armazena todas as suas variáveis de estado. Em comparação, programas na Solana não têm armazenamento pré-construído, mas possuem contas de dados separadas que mantêm as diversas variáveis de estado que desejam armazenar e referenciar.