Este guia serve como referência para desenvolvedores que desejam implementar builds verificados para seus programas na Solana. Vamos abordar o que são builds verificados, como usá-los, considerações especiais e melhores práticas para garantir a autenticidade do seu programa na blockchain.
O que são builds verificados?
Builds verificados garantem que o programa executável que você implanta na rede Solana corresponde ao código-fonte em seu repositório. Com isso, desenvolvedores e usuários podem ter confiança de que o programa em execução na blockchain corresponde exatamente à base de código pública, promovendo transparência e segurança.
O processo de verificação envolve comparar o hash do programa na blockchain com o hash do programa compilado localmente a partir do código-fonte. Isso garante que não haja discrepâncias entre as duas versões.
Embora um build verificado não deva ser considerado mais seguro que um build não verificado, o build permite que os desenvolvedores verifiquem por conta própria se o código-fonte corresponde ao que está implantado na blockchain. Usando o código-fonte, um desenvolvedor pode então validar o que o código executa ao enviar uma transação.
O pipeline de builds verificados foi concebido e é mantido pela Ellipsis Labs e OtterSec. Para mais detalhes, siga o guia no repositório original de builds verificados e o processo de verificação de build diretamente na suíte de ferramentas Anza, quando suportado.
Como funciona?
O processo de verificação é feito comparando o hash do programa na blockchain com o hash do programa construído localmente a partir do código-fonte. Você constrói seu programa em um ambiente controlado usando a CLI Solana Verify e Docker. Isso garante que o processo de construção seja determinístico e consistente em diferentes sistemas. Depois de ter o executável, você pode implantá-lo na rede Solana. Durante o processo de construção, uma PDA do programa verify será criada. Esta PDA contém todos os dados necessários para verificar o programa. A PDA contém o endereço do programa, URL do git, hash do commit e os argumentos usados para construir o programa.
Usando os dados na PDA, todos podem executar o comando do programa verify localmente e verificar se o programa foi construído a partir do código-fonte fornecido. Então todos podem verificar por si mesmos de forma completamente confiável ou podem executar sua própria API de verificação mantida pela OtterSec para fornecer um ponto de acesso fácil para os usuários verificarem a verificação. Você já pode ver essas chamadas de API sendo usadas no Solana Explorer e SolanaFM, entre outros lugares.
Por que devo usar builds verificadas?
O uso de builds verificadas proporciona os seguintes benefícios:
-
Segurança: Garante que o programa em execução na blockchain corresponde ao código-fonte, evitando alterações maliciosas.
-
Transparência: Permite que outros usuários e desenvolvedores validem que o programa na blockchain é confiável, comparando-o com a base de código pública.
-
Confiança: Aumenta a confiança do usuário, pois as builds verificadas demonstram que o comportamento do seu programa na blockchain está alinhado com seu código público. Ao construir programas verificáveis, você minimiza os riscos associados à execução de código não autorizado ou malicioso. Também garante que você siga as melhores práticas e ofereça aos pesquisadores de segurança uma maneira fácil de entrar em contato com você. Além disso, carteiras e outras ferramentas podem permitir transações do seu programa mais facilmente desde que esteja verificado.
-
Descoberta: quando você fornece uma compilação verificada do seu programa, todos podem encontrar seu código-fonte, documentação, SDK do programa ou IDL e também podem facilmente entrar em contato com você via GitHub caso haja algum problema.
Como criar compilações verificadas?
Para criar compilações verificadas, você precisará seguir estas etapas:
Resumo:
- Faça commit do seu código em um repositório público
- Construa uma compilação verificada no Docker
- Implante a compilação verificada
- Verifique o programa implantado na API pública
Se você verificar seu programa que não foi compilado em um contêiner Docker, provavelmente falhará porque as compilações de programas Solana não são determinísticas em diferentes sistemas.
Instale o Docker e o Cargo
Instale as ferramentas necessárias, garantindo que você tenha o Docker e o Cargo instalados. O Docker fornece um ambiente de compilação controlado para garantir consistência, e o Cargo é usado para gerenciar pacotes Rust.
- Docker: Siga os passos no site do Docker para instalar o Docker para sua plataforma. Depois de instalado, certifique-se de que o serviço Docker esteja em execução seguindo este guia adiante.
- Cargo: Se você ainda não tem o Cargo instalado, pode instalá-lo executando o seguinte comando:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Instale a CLI Solana Verify
A CLI Solana Verify é a principal ferramenta usada para verificar compilações. A CLI Solana Verify atualmente é mantida pela Ellipsis Labs e pode ser instalada usando o Cargo.
Você pode instalá-la executando:
cargo install solana-verify
Se você precisar de uma versão específica da CLI, pode fixar a versão com:
cargo install solana-verify --version $VERSION
Se desejar, você pode instalar uma versão diretamente de um commit específico:
cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2
Preparar projeto
Para verificar contra um repositório, ele precisa ter um ficheiro Cargo.lock
no diretório raiz do seu repositório. Se tiver apenas um programa no seu
repositório e um ficheiro cargo.lock na raiz, pode ir diretamente para o
próximo passo e compilar o seu programa.
Se o seu programa estiver numa subpasta e tiver um workspace Rust, precisa de
criar um ficheiro Cargo.toml de workspace no diretório raiz do seu
repositório.
Pode usar este exemplo de Cargo.toml como predefinição:
[workspace]members = ["program/programs/*"]resolver = "2"[profile.release]overflow-checks = truelto = "fat"codegen-units = 1[profile.release.build-override]opt-level = 3incremental = falsecodegen-units = 1
Certifique-se de que o seu programa está no array workspace/members e que o
Cargo.toml do seu programa tem o nome lib correto configurado.
Importante é o
lib name, não o nome do pacote!
Algo como isto:
[package]name = "waffle"version = "0.1.0"edition = "2021"[lib]name = "waffle"crate-type = ["cdylib", "lib"][dependencies]solana-program = "2.1.0"
Neste repositório pode
ver um exemplo de um workspace com um programa numa subpasta. Note também que
quando o programa está numa subpasta, mais tarde precisará adicionar esta pasta
como --mount-path ao comando verify-from-repo.
Neste repositório você pode encontrar um exemplo de Anchor. Neste repositório você pode encontrar um exemplo de Rust nativo.
Com este ficheiro Cargo.toml no lugar, pode então executar
cargo generate-lockfile para criar um ficheiro de bloqueio e continuar para
compilar o seu programa.
Compilando programas verificáveis
Para compilar o seu programa Solana de forma verificável, navegue até ao
diretório que contém o ficheiro Cargo.toml do seu workspace e execute:
solana-verify build
Isso copiará seu ambiente para um contêiner Docker e o compilará de maneira determinística.
Certifique-se de que implementa efetivamente a compilação verificada e não a sobrescreve acidentalmente com
anchor buildoucargo build-sbf, pois estes provavelmente não resultarão no mesmo hash e, portanto, a sua verificação falhará.
Para projetos com vários programas, você pode compilar um programa específico usando o nome da biblioteca (não o nome do pacote):
solana-verify build --library-name $PROGRAM_LIB_NAME
Este processo garante compilações determinísticas e pode levar algum tempo, especialmente em certos sistemas (por exemplo, MacBook M1) porque está sendo executado dentro de um contêiner docker. Para compilações mais rápidas, é recomendado usar uma máquina Linux com arquitetura x86.
Depois que a compilação for concluída, você pode recuperar o hash do executável usando o seguinte comando:
solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so
Implantando programas verificáveis
Depois de compilar seu programa e recuperar seu hash, você pode implantá-lo na rede Solana. É recomendado usar uma solução de assinatura múltipla ou governança como o Squads Protocol para implantações seguras, mas você também pode implantar diretamente com:
solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc
Uma taxa de baixa prioridade adequada atualmente pode ser solicitada ao seu provedor rpc, por exemplo Quicknode.
Para verificar se o programa implantado corresponde ao executável compilado, execute:
solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID
Você pode ter diferentes versões implantadas em diferentes clusters Solana (ou seja, devnet, testnet, mainnet). Certifique-se de usar a URL de rede correta para o cluster Solana desejado contra o qual você quer verificar um programa. A verificação remota só funcionará na mainnet.
Verificando contra repositórios
Para verificar um programa contra seu repositório público, use:
solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH
Enquanto executa a compilação verificada no diretório do seu programa, ao executar
verify-from-repoé necessário adicionar a flag--mount-path. Este será o caminho para a pasta que contém oCargo.tomlcom o nome da biblioteca do seu programa.
Este comando compara o hash do programa na blockchain com o hash executável construído a partir do código-fonte no hash de commit especificado.
No final, o comando perguntará se você deseja carregar seus dados de verificação na blockchain. Se fizer isso, o Solana Explorer mostrará imediatamente os dados de verificação do seu programa. Até que seja verificado por uma compilação remota, ele será exibido como não verificado. Aprenda como verificar seu programa em uma API pública no próximo passo.
Se desejar fixar a verificação a uma versão específica, pode adicionar a flag
--commit-hash ao comando.
Verificar com API pública
Finalmente, você também pode verificar diretamente o programa com qualquer pessoa que esteja executando a API de verificação:
solana-verify verify-from-repo --remote -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Recomenda-se usar um URL de RPC pago, caso contrário poderá encontrar limites de taxa dos RPCs gratuitos. Portanto, em vez de
-umdeve usar--url yourRpcUrlpara uma verificação mais confiável.
A flag --remote envia uma solicitação de compilação para a API da OtterSec,
que aciona uma compilação remota do seu programa. Quando a compilação é
concluída, o sistema verifica se o hash na blockchain do seu programa
corresponde ao hash do artefato de compilação gerado a partir do seu
repositório.
O padrão é a API da OtterSec.
Certifique-se de escolher sim quando for perguntado se deseja carregar os dados de verificação na blockchain. Isso é usado pela API para verificar que você carregou os dados de verificação.
Você também pode acionar um trabalho remoto manualmente usando:
solana-verify remote submit-job --program-id <program-id> --uploader <address>
Onde o uploader é o endereço que tem autoridade para escrever no PDA. Isso deve ser a autoridade do programa na maioria dos casos. Se o seu programa é controlado por um multisig, continue na parte verificação multisig deste guia abaixo.
Isso enviará um trabalho para a API OtterSec e você poderá verificar o status do trabalho com:
solana-verify remote get-job-status --job-id <job-id>
Depois que a verificação for concluída com sucesso, o que pode demorar um pouco, você poderá ver seu programa como verificado na API OtterSec para programas individuais e no Solana Explorer, SolanaFM, SolScan e eventualmente também no site mantido pela comunidade SolanaVerify.org mantido por 0xDeep e na API de programas verificados OtterSec e finalmente no Painel Dune de Programas Verificados contribuindo para um ecossistema Solana mais saudável.
Como verificar seu programa quando ele é controlado por um Multisig como Squads
Para que a verificação remota funcione, você precisa escrever os dados de verificação em um PDA assinado pela autoridade do programa. Se seu programa é controlado por um multisig, você pode exportar esta transação de escrita PDA e enviá-la através do Squads Protocol ou outra solução multisig de sua escolha.
1. Construir o programa verificável
Primeiro construa o programa:
solana-verify build
Isto criará uma compilação verificável usando um contentor docker com a versão
da Solana especificada no ficheiro Cargo.lock.
2. Implantar o programa
solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too muchsolana program deploy target/deploy/verify_squads.so
Para o resto deste guia de multisig, usaremos um ID de programa de exemplo
6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD.
3. Commit e verificação contra o repositório
Uma vez feito isso, commitamos o projeto para o github. Aqui está um exemplo: https://github.com/solana-developers/verify-squads
Opcional: veja se consegue verificar localmente primeiro (este comando usa o ID
de programa de exemplo 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD):
solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
Apenas para garantir que seus parâmetros estão corretos.
4. Transferir a autoridade do programa para o multisig
Se você ainda não transferiu a autoridade do seu programa para o multisig e copiou a autoridade do multisig. Você precisará dela na próxima etapa.
5. Exportar transação PDA
Quando tem a autoridade do programa localmente, é solicitado que carregue os
dados de compilação na blockchain ao usar o comando
solana-verify verify-from-repo.
Como você não pode fazer isso quando está usando um multisig, você precisa exportar a transação PDA manualmente e depois acionar a transação através do Squads.
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0
Isto retornará uma transação em base58. Se você quiser uma transação codificada
em base64 para usar num inspetor de transações, pode usar --encoding base64.
P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D
6. Enviar transação através do Squads
Vá para o construtor de transações do Squads e importe a transação codificada em base58. Certifique-se de que na simulação a transação tenha apenas uma chamada para o programa de verificação osec e o programa de orçamento do computador e nada mais!
7. Enviar trabalho de verificação remota
Uma vez que a transação para o Squads foi bem-sucedida, você pode enviar o trabalho remoto:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD--uploader <your program authority>
É isso! Você verificou seu programa contra um repositório público e enviou um trabalho remoto para a API da OtterSec. Agora você deve poder ver isso refletido no explorador da Solana e em outros lugares.
8. Atualizando o programa (Opcional)
Quando você atualiza seu programa, precisa exportar uma nova transação PDA e enviá-la novamente através do Squads.
Fazendo uma atualização no programa:
solana-verify buildsolana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50
Em seguida, transfira essa autoridade do buffer para o multisig ou crie diretamente o buffer com a autoridade do multisig.
solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
9. Exportar e enviar nova transação PDA
Não se esqueça de fazer commit das suas alterações no github. Exporte a transação de atualização PDA novamente:
solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Envie a transação através do Squads novamente.
Você pode ver um exemplo de transação aqui.
Em seguida, envie para outra compilação remota:
solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K
Deve resultar em algo como isto:
Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.✅ The provided GitHub build matches the on-chain hash. On Chain Hash:96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 ExecutableHash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7edCheck the verification status at:https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Joburl: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3
Parabéns, você verificou seu programa após uma atualização multisig!
Verificar a partir da imagem docker
Você também pode verificar seu programa usando uma imagem docker executando o seguinte comando:
solana-verify verify-from-image -eexamples/hello_world/target/deploy/hello_world.so -iellipsislabs/hello_world_verifiable_build:latest -p2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn
Este comando carrega a imagem armazenada em
ellipsislabs/hello_world_verifiable_build:latest e verifica se o hash do
caminho executável no contentor é o mesmo que o hash do programa na blockchain
fornecido ao comando. Como a build já foi carregada numa imagem, não há
necessidade de uma reconstrução completa do executável, o que pode demorar muito
tempo.
O Dockerfile que cria a imagem
ellipsislabs/hello_world_verifiable_build:latest pode ser encontrado no
repositório da Ellipsis Labs
/examples/hello_world.
Abaixo está a saída esperada:
Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network"https://api.mainnet.solana.com" against program ID2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:"examples/hello_world/target/deploy/hello_world.so"Executable hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executablematches on-chain program data ✅
Exemplo de build verificada
Aqui está um exemplo de verificação de um programa de exemplo com o ID
FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv usando o código-fonte deste
repositório:
solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
Por padrão, o comando verify-from-repo usa o último commit no ramo principal.
Você também pode definir um commit específico caso queira continuar a trabalhar
no repositório usando o parâmetro commit-hash:
--commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
Finalmente, você também pode verificar o programa diretamente na API da OtterSec:
solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --remote --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e
O comando --remote envia uma solicitação de build para a API da OtterSec, que
inicia uma build remota do seu programa. Quando a build é concluída, o sistema
verifica se o hash do seu programa na blockchain corresponde ao hash do artefato
de build gerado a partir do seu repositório.
Programas populares que já estão verificados
Phoenix
solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1
Resultado final:
Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9On-chain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9Program hash matches ✅
Squads V3
solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf
Note que precisámos especificar o
library-nameporque o repositório Squads inclui múltiplos programas. Usamos a flag--bpfporquesquads_mplfoi previamente verificado com Anchor.
Resultado final:
Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205cOn-chain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205cProgram hash matches ✅
Drift V2
solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift
Resultado final:
Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828On-chain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828Program hash matches ✅
Marginfi V2
solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta
Resultado final:
Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5On-chain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5Program hash matches ✅
Perguntas frequentes
Minha verificação está falhando. O que devo fazer?
Verifique estes problemas comuns:
- Assinante incorreto: Confirme que seu assinante é a autoridade de
atualização do programa executando
solana program show YourProgramId - Sem PDA on-chain: Execute
solana-verify verify-from-repo -ume selecione SIM quando solicitado. Sem fazer upload do PDA, a API não consegue recuperar seus metadados de verificação. - Incompatibilidade de dados do PDA: Atualize seu PDA se você reimplantou seu programa. Os dados do seu PDA devem corresponder ao programa implantado.
- Hash de commit incorreto: Crie seu PDA usando o hash de commit exato que você implantou
- Diferenças no ambiente de build: Use Docker com solana-verify ao criar seu PDA
O hash do meu build local não corresponde ao hash on-chain. Por quê?
Isso geralmente significa:
- Você está usando versões diferentes das toolchains Rust/Solana
- Suas dependências foram atualizadas entre builds
- Você não fez o build em um container Docker
- Você fez checkout do commit errado
Corrija isso fazendo o build com solana-verify build no Docker usando o commit
exato que você implantou.
Quanto tempo levará minha verificação?
Espere estes prazos com base no tamanho do seu programa:
- Programas simples: 1-5 minutos
- Programas complexos: 5-15 minutos
- Programas muito grandes: Até 30 minutos
Acompanhe seu progresso usando o endpoint de status do job.
Meu programa é imutável (sem autoridade de atualização). Como posso verificá-lo?
Se seu programa não tem autoridade de atualização ou foi tornado imutável antes de você poder criar um PDA, temos um endereço autorizado para esta situação. Entre em contato conosco em contact@osec.io, e nós o ajudaremos a verificar seu programa.
O que é o PDA e por que é importante?
Seu PDA (Program Derived Account) possibilita a verificação sem necessidade de confiança:
- Armazenamento On-Chain: Armazene seus metadados de verificação (URL do
repositório, hash do commit, parâmetros de compilação) on-chain em um PDA de
propriedade do programa Otter Verify
(
verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC) - Vínculo Criptográfico: Seu PDA é derivado do endereço do seu programa, criando um vínculo imutável aos seus dados de verificação
- Confiança Descentralizada: Qualquer pessoa pode ler seu PDA e verificar seu programa de forma independente
Por que devo criar o PDA antes de usar a API?
A API funciona apenas com PDAs on-chain porque:
- Sem necessidade de confiança: A API rejeita dados arbitrários - ela usa apenas o que sua autoridade de atualização armazenou on-chain
- Mais Simples: Basta fornecer o signatário + program_id; a API obtém todo o restante do seu PDA
- À prova de adulteração: Seu PDA cria um registro imutável que qualquer pessoa pode verificar de forma independente
- Prova de Propriedade: Seu signatário deve ser a autoridade de atualização, provando criptograficamente que você controla o programa
Com que frequência devo verificar meu programa?
Verifique seu programa:
- Após cada implantação ou atualização
- Quando você atualizar seu repositório de código-fonte
- Não se preocupe em reverificar caso contrário - a API reverifica automaticamente todos os programas a cada 24 horas
O que acontece quando atualizo meu programa?
Siga estas etapas após atualizar:
- A API detecta sua atualização e remove a verificação do seu programa.
- Atualize seu PDA com novos metadados de verificação:
solana-verify verify-from-repo -um \--program-id YourProgramId... \https://github.com/your-org/your-program
- Envie uma nova solicitação de verificação usando sua autoridade de atualização
- A API verificará sua nova versão em relação ao PDA atualizado
Importante: Sempre atualize seu PDA usando sua autoridade de atualização com o novo hash do commit para o programa atualizado.
Posso confiar nos resultados da verificação?
Sim - o sistema foi projetado para ser sem necessidade de confiança e verificável de forma independente:
O que o Torna Confiável:
- PDA On-Chain: Seus metadados de verificação ficam on-chain, não controlados por nenhuma autoridade central
- Prova de Autoridade de Atualização: Apenas a autoridade de atualização do seu programa pode criar/atualizar o PDA
- Verificação Independente: Qualquer pessoa pode verificar lendo seu PDA e
executando
solana-verifylocalmente - Re-verificação Contínua: A API re-verifica automaticamente todos os programas a cada 24 horas
Entenda Estas Limitações:
- A verificação confirma que a fonte corresponde ao deployment - NÃO que seu código é seguro
- Sempre revise o código antes de interagir com programas
- Verificado ≠ auditado ou seguro
- Verifique o repositório e o commit no PDA para confirmar que é de uma fonte confiável
Como posso verificar um programa de forma independente?
Verifique qualquer programa você mesmo lendo seu PDA on-chain e executando a verificação localmente:
Passo 1: Leia o PDA On-Chain
# Install solana-verify if you haven'tcargo install solana-verify# Get the PDA datasolana-verify list-program-pdas --program-id YourProgramId...
Passo 2: Verifique Localmente
# Verify using the repository and commit & other arguments from the PDAsolana-verify verify-from-repo \--program-id YourProgramId... \https://github.com/your-org/your-program--commit-hash <commit-hash>... (other arguments from the PDA)# Confirm the hash output matches the on-chain program hash
Isto prova:
- Os metadados do PDA são autênticos (armazenados on-chain)
- O código-fonte no repositório do PDA corresponde ao programa implantado
- Você não precisa confiar na API - verifique tudo você mesmo on-chain
Outra pessoa pode verificar meu programa sem permissão?
Sim, é por isso que exigimos que o signatário seja a autoridade de atualização. Nós apenas consideramos a verificação válida se o signatário for a autoridade de atualização.
O que preciso para criar builds verificáveis?
Instale estas ferramentas:
- Docker (para builds determinísticos)
- Cargo (gerenciador de pacotes Rust)
- Solana Verify CLI:
cargo install solana-verify - Um repositório Git público com seu código-fonte
Posso verificar repositórios privados?
Não - a verificação requer código-fonte público:
- Seu PDA armazena uma URL de repositório público que qualquer pessoa pode acessar
- A verificação sem confiança depende do acesso ao código público
- Os usuários precisam ler seu código-fonte para entender o que seu programa faz
- O objetivo principal é permitir que os usuários verifiquem independentemente se o código-fonte corresponde à implantação
Repositórios privados quebram o modelo de confiança central do sistema de verificação.
Como verifico um programa controlado por Squads Multisig?
Siga estes passos para programas controlados por multisig:
# 1. Build and deploy normallysolana-verify buildsolana program deploy <your-program.so> --program-id YourProgramId...# 2. Verify locally first - confirm the hash matchessolana-verify verify-from-repo -um \--program-id YourProgramId... \https://github.com/your-org/your-program# 3. Export the PDA creation transactionsolana-verify export-pda-tx \--program-id YourProgramId... \https://github.com/your-org/your-program# 4. Execute the PDA transaction through your Squads Multisig interface# 5. After multisig execution, trigger remote verificationsolana-verify remote submit-job \--program-id YourProgramId... \--uploader YourMultisigAddress...
Crítico: Sempre verifique localmente (passo 2) para confirmar que o hash da build corresponde antes de exportar a transação do PDA.
Conclusão
Usar builds verificadas na Solana garante a integridade e confiabilidade dos seus programas na rede e permite que desenvolvedores encontrem seus SDKs diretamente a partir de um Solana Explorer. Ao aproveitar ferramentas como a Solana Verify CLI e o Docker, você pode manter builds verificáveis e seguras que se alinham com seu código-fonte. Sempre tome as precauções necessárias para usar ambientes consistentes e considere soluções de governança para upgrades e implantações seguras.
Segurança + Aviso
Embora as builds verificadas sejam uma ferramenta poderosa para garantir a integridade dos seus programas Solana, ela não é completamente sem confiança na configuração padrão. As imagens docker são construídas e hospedadas pela Solana Foundation.
Esteja ciente de que você está construindo seu projeto em uma imagem docker baixada e que toda a sua configuração é copiada para essa imagem docker para a construção, incluindo informações potencialmente sensíveis.
Se você quiser ter uma configuração completamente sem confiança, pode construir as imagens docker você mesmo e hospedá-las em sua própria infraestrutura. Dessa forma, você pode ter certeza de que as imagens docker não foram adulteradas. Você pode encontrar os scripts para criar suas próprias imagens docker no repositório de Verified builds e pode bifurcá-lo e executar as github actions você mesmo ou validar que elas estão corretas.
Além disso, para a verificação remota, você está confiando na API da OtterSec e no Solana Explorer até certo ponto.
A API ou o Solana Explorer podem potencialmente exibir informações incorretas se comprometidos.
Se você deseja ter uma configuração completamente trustless, pode executar a
API de Verificação
você mesmo ou executar a verificação do programa localmente usando o comando
verify-from-repo utilizando os dados de verificação on-chain que são salvos em
um
PDA
que é derivado da autoridade de implantação do programa e do
programa de verificação.
O programa de verificação é implantado pela equipe OtterSec e ainda não está congelado, portanto pode ser atualizado a qualquer momento.
A Solana Foundation, a OtterSec e a equipe da Ellipsis Labs não são responsáveis por quaisquer perdas ou danos que possam ocorrer ao usar o pipeline de builds verificados.
Security.txt para programas Solana
Além dos builds verificados, você também pode adicionar um arquivo
security.txt ao seu programa. No futuro, uma vez implementado, o
security.txt conterá a chave pública do verificador para fácil acesso aos
dados de verificação armazenados no PDA de verificação. O PDA contendo todas as
informações necessárias para construir e verificar um programa é derivado do
endereço do programa e da pubkey do verificador. Por padrão, esta é a mesma
pubkey que construiu e implantou o programa. Mas também pode ser outra pubkey
que pode ser especificada no security.txt.
O recurso security.txt permite que desenvolvedores incorporem informações de
contato e segurança diretamente em seus contratos inteligentes Solana. Inspirado
pelo securitytxt.org, essa abordagem fornece uma
maneira padronizada para pesquisadores de segurança entrarem em contato com os
mantenedores do projeto, mesmo que conheçam apenas o endereço do contrato.
Por que usar security.txt?
Para muitos projetos, especialmente os menores ou privados, identificar os
desenvolvedores apenas pelo endereço do contrato pode ser difícil e demorado.
Incorporar um arquivo security.txt no programa garante que os pesquisadores de
segurança possam facilmente entrar em contato com as pessoas corretas,
potencialmente prevenindo exploits e garantindo relatórios de bugs oportunos.
Como implementar security.txt
Para adicionar um security.txt ao seu programa Solana, siga as seguintes
etapas:
Adicione a dependência solana-security-txt ao seu Cargo.toml:
[dependencies]solana-security-txt = "1.1.1"
Use a macro security_txt! no seu contrato para definir suas informações de
segurança. Você pode incluir detalhes de contato, URLs do projeto e até mesmo
uma política de segurança. Aqui está um exemplo:
#[cfg(not(feature = "no-entrypoint"))]use {default_env::default_env, solana_security_txt::security_txt};#[cfg(not(feature = "no-entrypoint"))]security_txt! {name: "MyProject",project_url: "https://myproject.com",contacts: "email:security@myproject.com,discord:security#1234",policy: "https://myproject.com/security-policy",// Optional Fieldspreferred_languages: "en,de",source_code: "https://github.com/solana-developers/solana-game-preset",source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",source_release: "",encryption: "",auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",acknowledgements: "Thank you to our bug bounty hunters!"}
Uma vez que as informações de security.txt estejam incorporadas no seu
programa, elas podem ser facilmente consultadas por ferramentas como o Solana
Explorer, garantindo que seus detalhes de contato e segurança estejam
disponíveis para qualquer pessoa que deseje relatar possíveis problemas.
Melhores práticas
-
Use Links: Para informações que provavelmente mudarão (por exemplo, detalhes de contato), é recomendado vincular a uma página web em vez de codificá-las diretamente no contrato. Isso evita a necessidade de atualizações frequentes do programa.
-
Verificação: Antes de implantar, verifique o formato e o conteúdo usando a ferramenta
query-security-txt, que pode validar tanto programas onchain quanto binários locais:
query-security-txt target/bpfel-unknown-unknown/release/my_contract.so
Ao incorporar informações de contato de segurança diretamente no seu contrato, você facilita que os pesquisadores entrem em contato com você, promovendo melhor segurança e comunicação dentro do ecossistema Solana.
Este é um exemplo de como o security.txt aparece no Solana Explorer
O projeto security.txt é mantido pela
Neodyme Labs
Você pode verificar o status de verificação e navegar pelos programas verificados em verify.osec.io.
Is this page helpful?