In Solana's context, reentrancy refers to a scenario during a CPI call where the called program invokes back into the calling program (direct reentrancy) or into a shared mutable account via a third program (indirect reentrancy), potentially causing the calling program to re-execute logic with state that has been partially modified by the intervening CPI. The Solana runtime prevents direct same-program reentrancy at the VM level — a program cannot CPI into itself — but indirect reentrancy through mutable shared accounts is possible and can cause account-reloading vulnerabilities where a program's cached account data becomes stale. Programs should reload account state after every CPI that may have modified shared accounts and avoid assuming pre-CPI state invariants hold afterward.
Reentrância no Solana é diferente do Ethereum: como o runtime proíbe chamadas circulares entre programas, o risco real é de 'reentrância cross-program' via CPIs que modificam contas compartilhadas.
Ao fazer CPIs, recarregue contas que possam ter sido modificadas antes de continuar a execução. Verifique o estado atual, não o estado em memória que pode estar desatualizado.
Assumir que Solana não tem reentrância por proibir recursão direta. CPIs em cadeia podem criar padrões equivalentes se contas mutáveis forem compartilhadas entre programas.
Sua exploração
0 termos visitados no total