"Puffer é um protocolo descentralizado de restaking líquido nativo (nLRP) construído sobre o Eigenlayer". Ele atraiu mais de 600 milhões de dólares em TVL (Total Value Locked) em apenas alguns dias. O controle de acesso é uma consideração de segurança importante para prevenir operações maliciosas no protocolo.
Neste blog, revisamos toda a arquitetura do mecanismo de controle de acesso e sua configuração atual no protocolo Puffer. Isso pode ajudar a comunidade a entender melhor o protocolo. Observe que o resultado da análise é baseado no status atual (Bloco 19177155, 07 de fev de 2024, 03:17:35 PM +UTC) na Ethereum.
Endereços dos contratos
A tabela a seguir lista os contratos inteligentes utilizados neste blog.
| Endereço | Implementação | |
|---|---|---|
| PufferDepositor | 0x4aa799c5dfc01ee7d79 0e3bf1a7c2257ce1dceff | 0x7276925e42f9c4054af a2fad80fa79520c453d6a |
| PufferVault | 0xD9A442856C234a39a81 a089C06451EBAa4306a72 | 0x39ca0a6438b6050ea2a c909ba65920c7451305c1 |
| AccessManager | 0x8c1686069474410E624 3425f4a10177a94EBEE11 | - |
| TimeLock | 0x3c28b7c7ba1a1f55c9c e66b263b33b204f2126ea | - |
| Operation SafeWallet | 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Community SafeWallet | 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Pausing SafeWallet | 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
Arquitetura
O protocolo como um todo inclui principalmente dois contratos inteligentes relacionados aos ativos dos usuários. O primeiro é o PufferDepositor e o segundo é o PufferVault.
A principal funcionalidade do PufferDepositor é aceitar os ativos dos usuários e depositá-los no PufferVault. Se os ativos depositados pelos usuários não forem stETH, a troca em uma DEX é realizada automaticamente pelo protocolo.
O PufferVault é o contrato principal que mantém os ativos dos usuários. Ele também é o ponto de entrada para depósitos no EigenLayer. O controle de acesso principal de todo o protocolo é implementado neste contrato inteligente.
Mecanismo de Controle de Acesso
Todo o controle de acesso é implementado utilizando o módulo AccessManager da OpenZeppelin. O contrato inteligente AccessManager gerencia a autoridade dos contratos PufferDepositor e PufferVault.
O AccessManager define diferentes Papéis (Roles), que contêm diferentes endereços. Cada Papel pode ser atribuído para invocar diferentes funções dentro dos contratos AccessManaged (ou seja, PufferDepositor e PufferVault). O AccessManager suporta a execução atrasada de uma função específica. Isso significa que, ao conceder um Papel a um endereço, é possível especificar se as operações emitidas por esse endereço neste Papel são executadas imediatamente ou com um atraso de tempo.
Configurações Atuais de Controle de Acesso
No entanto, a eficácia do controle de acesso depende de sua configuração. Observamos inúmeros casos em que uma configuração incorreta das regras de ACL (Lista de Controle de Acesso) levou a vulnerabilidades de segurança.
Para resolver isso, revisamos a configuração atual do protocolo Puffer e apresentamos os resultados abaixo. Observe que esses resultados refletem apenas o status do Bloco 19177155 (07 de fev de 2024, 03:17:35 PM +UTC).
Papéis (Roles)
Abaixo está uma tabela descrevendo os papéis atuais no sistema e seus endereços associados.
| ID do Papel | Endereços com este Papel | Execução Atrasada | Observação |
|---|---|---|---|
| 0 | TimeLock 0x3c28b7c7ba1a1f55c9ce66b263b33b204f2126ea | Não | Papel ADMIN |
| 1 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Sim, com 604800 segundos (7 dias) | Atualizar os contratos alvo (PufferDepositor e PufferVault) |
| 1 | Community SafeWallet 0x446d4d6b26815f9ba78b5d454e303315d586cb2a | Não | Atualizar os contratos alvo (PufferDepositor e PufferVault) |
| 22 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Não | Mover ativos para o EigenLayer e iniciar solicitação de retirada do EigenLayer |
Existem diferentes caminhos de execução para executar funções dentro do contrato PufferVault. Um caminho envolve o contrato TimeLock (com o Papel ADMIN – conforme mostrado no Caminho 1 na figura), e o outro caminho permite a invocação direta de funções dentro do Vault, com o papel atribuído ao chamador. Em ambos os casos, a invocação deve passar pelo AccessManager.
Tipo I: Invocação a partir do Contrato TimeLock
Observe que ao invocar uma função a partir do contrato TimeLock, o Papel atribuído é ADMIN. Essa designação ocorre porque, da perspectiva do Vault, o chamador é o contrato TimeLock, que possui o Papel ADMIN. Consequentemente, o contrato TimeLock incorpora uma camada adicional de mecanismo de execução atrasada.
- Operation SafeWallet: Este componente pode invocar funções dentro do contrato alvo após um atraso de 604.800 segundos (aproximadamente 7 dias).
- Community SafeWallet: Este componente tem a capacidade de invocar funções dentro do contrato alvo imediatamente. Ele também possui autoridade para cancelar qualquer execução pendente na fila submetida pelo Operation SafeWallet.
- Pausing SafeWallet: Este componente está restrito a pausar o contrato alvo e não está autorizado a executar nenhuma outra função.
Tipo II: Invocação Direta do Contrato Vault
O método seguinte envolve a invocação direta de funções dentro do contrato Vault. É importante observar que o AccessManager determina quais funções podem ser invocadas pelos endereços associados a cada Papel.
| ID do Papel | Contrato Alvo | Função Alvo |
| 1 | PufferVault | upgradeToAndCall(address,bytes)
0x4f1ef286 |
| 22 | PufferVault | depositToEigenLayer (0x008e0590)
initiateETHWithdrawalsFromLido (0x593961de) initiateStETHWithdrawalFromEigenLayer (0x402064a7) |
Tanto o Operation quanto o Community SafeWallet têm a capacidade de invocar diretamente a função upgradeToAndCall para atualizar o contrato alvo. A principal distinção está no tempo: o Community SafeWallet executa essa ação sem nenhum atraso, enquanto o Operation SafeWallet está sujeito a um atraso.
Além disso, o Operation SafeWallet está equipado para executar imediatamente funções que transferem ativos para o EigenLayer e iniciam solicitações de retirada.
Atualizado em [08 de fev de 2024, 10:02:59 AM +UTC]
Uma operação com o objetivo de remover o Operation SafeWallet do Papel 1 foi agendada. Esta operação está prevista para execução após o bloco 1707940908, o que corresponde a um atraso estimado de aproximadamente 7 dias. A simulação dessas transações enfileiradas foi realizada usando o BlockSec Phalcon.
- A transação simulada no Phalcon Fork para executar a execução enfileirada em 18/02/2024 17:59:07 (UTC), dez dias depois.
- A transação simulada para verificar se o Operation SafeWallet ainda possui o Papel 1 (retorna falso)
Atualizado em [16 de fev de 2024, 20:10:23 AM +UTC]:
- A transação para remover o Operation SafeWallet do Papel 1 foi executada. Podemos verificar o resultado no Etherscan.
Configurações das Safe Wallets
A configuração de uma safe wallet também afeta a segurança do protocolo.
| Carteira | Proprietários | Limite |
|---|---|---|
| 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] | 3 |
| 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] | 3 |
| 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] [0xaACA1eDbb656206Ce2a82Da7d7BD3e1Bb8138F22] | 1 |
Atualizado em [08 de fev de 2024, 10:02:59 AM +UTC]:
- O endereço 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 foi removido do Operation SafeWallet, ajustando sua autorização para 3/5.
- Uma transação para remover 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 do Community SafeWallet foi iniciada e está aguardando aprovação multisig da comunidade.
- Três carteiras foram removidas do Pausing SafeWallet, ajustando agora sua configuração para 1/9.
Resumo
Nesta publicação do blog, revisamos os mecanismos de segurança utilizados pelo protocolo Puffer. No geral, o design de todo o sistema de permissões é abrangente.
A comunidade deve monitorar ativamente os riscos potenciais:
- A segurança das chaves privadas dos proprietários do Community SafeWallet é fundamental. Se três chaves privadas forem comprometidas, um atacante poderia ser capaz de atualizar o vault.
- A segurança dos protocolos dependentes, como o EigenLayer, também deve ser monitorada ativamente.
