"Puffer es un protocolo de reestaca líquida nativa descentralizado (nLRP) construido sobre Eigenlayer". Ha atraído más de 600 millones de USD en TVL (Valor Total Bloqueado) en tan solo unos días. El control de acceso es una consideración de seguridad importante para prevenir operaciones maliciosas en el protocolo.
En este blog, revisamos la arquitectura completa del mecanismo de control de acceso y su configuración actual en el protocolo Puffer. Esto puede ayudar a la comunidad a comprender mejor el protocolo. Tenga en cuenta que el resultado del análisis se basa en el estado actual (Bloque 19177155, 07 de feb de 2024, 03:17:35 PM +UTC) en Ethereum.
Direcciones de los contratos
La siguiente tabla enumera los contratos inteligentes utilizados en este blog.
| Dirección | Implementación | |
|---|---|---|
| PufferDepositor | 0x4aa799c5dfc01ee7d79 0e3bf1a7c2257ce1dceff | 0x7276925e42f9c4054af a2fad80fa79520c453d6a |
| PufferVault | 0xD9A442856C234a39a81 a089C06451EBAa4306a72 | 0x39ca0a6438b6050ea2a c909ba65920c7451305c1 |
| AccessManager | 0x8c1686069474410E624 3425f4a10177a94EBEE11 | - |
| TimeLock | 0x3c28b7c7ba1a1f55c9c e66b263b33b204f2126ea | - |
| Cartera Segura de Operaciones | 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Cartera Segura de la Comunidad | 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Cartera Segura de Pausa | 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
Arquitectura
El protocolo en su conjunto incluye principalmente dos contratos inteligentes relacionados con los activos de los usuarios. El primero es PufferDepositor y el segundo es PufferVault.
La funcionalidad principal de PufferDepositor es aceptar los activos de los usuarios y luego depositarlos en PufferVault. Si los activos depositados por los usuarios no son stETH, el protocolo realiza automáticamente el intercambio en un DEX.
PufferVault es el contrato principal que custodia los activos de los usuarios. También es el punto de entrada para los depósitos en EigenLayer. El control de acceso principal de todo el protocolo está implementado en este contrato inteligente.
Mecanismo de Control de Acceso
Todo el control de acceso se implementa aprovechando el módulo AccessManager de OpenZeppelin. El contrato inteligente AccessManager gestiona la autoridad de los contratos PufferDepositor y PufferVault.
El AccessManager define diferentes Roles, que contienen diferentes direcciones. Cada Rol puede ser asignado para invocar distintas funciones dentro de los contratos gestionados por el acceso (es decir, PufferDepositor y PufferVault). El AccessManager admite la ejecución diferida de una función en particular. Es decir, al otorgar un Rol a una dirección, se puede especificar si las operaciones emitidas desde esa dirección en ese Rol se ejecutan de inmediato o con un retardo de tiempo.
Configuraciones Actuales de Control de Acceso
No obstante, la efectividad del control de acceso depende de su configuración. Hemos observado numerosos casos en los que una configuración defectuosa de las reglas ACL (Lista de Control de Acceso) ha dado lugar a vulnerabilidades de seguridad.
Para abordar esto, hemos revisado la configuración actual del protocolo Puffer y presentamos los resultados a continuación. Tenga en cuenta que estos resultados solo reflejan el estado a partir del Bloque 19177155 (07 de feb de 2024, 03:17:35 PM +UTC).
Roles
A continuación se presenta una tabla que describe los roles actuales dentro del sistema y sus direcciones asociadas.
| ID de Rol | Direcciones con este Rol | Ejecución Diferida | Nota |
|---|---|---|---|
| 0 | TimeLock 0x3c28b7c7ba1a1f55c9ce66b263b33b204f2126ea | No | Rol ADMIN |
| 1 | Cartera Segura de Operaciones 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Sí, con 604800 segundos (7 días) | Actualizar los contratos objetivo (PufferDepositor y PufferVault) |
| 1 | Cartera Segura de la Comunidad 0x446d4d6b26815f9ba78b5d454e303315d586cb2a | No | Actualizar los contratos objetivo (PufferDepositor y PufferVault) |
| 22 | Cartera Segura de Operaciones 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | No | Mover activos a EigenLayer e iniciar solicitud de retiro de EigenLayer |
Existen diferentes rutas de ejecución para ejecutar funciones dentro del contrato PufferVault. Una ruta involucra el contrato TimeLock (con el Rol ADMIN — como se muestra en la Ruta 1 en la figura), y la otra ruta permite la invocación directa de funciones dentro del Vault, con el rol asignado al llamante. En ambos casos, la invocación debe pasar por el AccessManager.
Tipo I: Invocación desde el Contrato TimeLock
Tenga en cuenta que al invocar una función desde el contrato TimeLock, el Rol asignado es ADMIN. Esta designación surge porque, desde la perspectiva del Vault, el llamante es el contrato TimeLock, que posee el Rol ADMIN. En consecuencia, el contrato TimeLock incorpora una capa adicional de mecanismo de ejecución diferida.
- Cartera Segura de Operaciones: Este componente puede invocar funciones dentro del contrato objetivo después de un retraso de 604.800 segundos (aproximadamente 7 días).
- Cartera Segura de la Comunidad: Este componente tiene la capacidad de invocar funciones dentro del contrato objetivo de inmediato. También posee la autoridad para cancelar cualquier ejecución pendiente en la cola enviada por la Cartera Segura de Operaciones.
- Cartera Segura de Pausa: Este componente está restringido a pausar el contrato objetivo y no está autorizado a ejecutar ninguna otra función.
Tipo II: Invocación Directa del Contrato Vault
El siguiente método implica invocar directamente funciones dentro del contrato Vault. Es importante tener en cuenta que el AccessManager dicta qué funciones pueden ser invocadas por las direcciones asociadas a cada Rol.
| ID de Rol | Contrato Objetivo | Función Objetivo |
| 1 | PufferVault | upgradeToAndCall(address,bytes)
0x4f1ef286 |
| 22 | PufferVault | depositToEigenLayer (0x008e0590)
initiateETHWithdrawalsFromLido (0x593961de) initiateStETHWithdrawalFromEigenLayer (0x402064a7) |
Tanto la Cartera Segura de Operaciones como la de la Comunidad tienen la capacidad de invocar directamente la función upgradeToAndCall para actualizar el contrato objetivo. La distinción clave radica en el momento de ejecución: la Cartera Segura de la Comunidad ejecuta esta acción sin ningún retraso, mientras que la Cartera Segura de Operaciones está sujeta a un retraso.
Además, la Cartera Segura de Operaciones está equipada para ejecutar inmediatamente funciones que transfieren activos a EigenLayer e inician solicitudes de retiro.
Actualizado el [08-feb-2024 10:02:59 AM +UTC]
Se ha programado una operación destinada a eliminar la Cartera Segura de Operaciones del Rol 1. Esta operación está programada para ejecutarse después del bloque 1707940908, lo que corresponde a un retraso estimado de aproximadamente 7 días. La simulación de estas transacciones en cola fue realizada utilizando BlockSec Phalcon.
- La transacción simulada en Phalcon Fork para ejecutar la ejecución en cola el 2024-02-18 17:59:07 (UTC), diez días después.
- La transacción simulada para consultar si la Cartera Segura de Operaciones aún tiene el Rol 1 (devuelve falso)
Actualizado el [16-feb-2024 20:10:23 AM +UTC]:
- La transacción para eliminar la Cartera Segura de Operaciones del Rol 1 ha sido ejecutada. Podemos verificar el resultado en Etherscan.
Configuraciones de las Carteras Seguras
La configuración de una cartera segura también afecta la seguridad del protocolo.
| Cartera | Propietarios | Umbral |
|---|---|---|
| 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 |
Actualizado el [08-feb-2024 10:02:59 AM +UTC]:
- La dirección 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 ha sido eliminada de la Cartera Segura de Operaciones, ajustando su autorización a 3/5.
- Se ha iniciado una transacción para eliminar 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 de la Cartera Segura de la Comunidad y actualmente está a la espera de la aprobación multifirma de la comunidad.
- Se han eliminado tres carteras de la Cartera Segura de Pausa, ajustando ahora su configuración a 1/9.
Resumen
En esta entrada de blog, hemos revisado los mecanismos de seguridad utilizados por el protocolo Puffer. En general, el diseño de todo el sistema de permisos es integral.
La comunidad debe monitorear activamente los riesgos potenciales:
- La seguridad de las claves privadas de los propietarios de la Cartera Segura de la Comunidad es primordial. Si tres claves privadas se ven comprometidas, podría permitir a un atacante actualizar el vault.
- La seguridad de los protocolos dependientes, como EigenLayer, también debe monitorearse activamente.
