„Puffer ist ein dezentrales, natives Liquid Restaking-Protokoll (nLRP), das auf Eigenlayer aufgebaut ist“. Es hat in nur wenigen Tagen mehr als 600 Millionen USD an TVL (Total Value Locked) angezogen. Die Zugriffskontrolle ist eine wichtige Sicherheitsmaßnahme, um böswillige Operationen auf dem Protokoll zu verhindern.
In diesem Blog besprechen wir die gesamte Architektur des Zugriffskontrollmechanismus und dessen aktuelle Konfiguration im Puffer-Protokoll. Dies kann der Community helfen, das Protokoll besser zu verstehen. Bitte beachten Sie, dass das Analyseergebnis auf dem aktuellen Stand (Block 19177155, 07. Feb. 2024, 15:17:35 Uhr +UTC) auf Ethereum basiert.
Vertragsadressen
Die folgende Tabelle listet die in diesem Blog verwendeten Smart Contracts auf.
| Adresse | Implementierung | |
|---|---|---|
| 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 |
Architektur
Das gesamte Protokoll umfasst hauptsächlich zwei Smart Contracts, die mit den Vermögenswerten der Benutzer verbunden sind. Der erste ist PufferDepositor und der zweite ist PufferVault.
Die Hauptfunktion von PufferDepositor besteht darin, die Vermögenswerte der Benutzer entgegenzunehmen und sie dann in PufferVault einzuzahlen. Falls es sich bei den Einzahlungsanlagen der Benutzer nicht um stETH handelt, wird der Tausch in eine DEX automatisch vom Protokoll durchgeführt.
PufferVault ist der Hauptvertrag, der die Vermögenswerte der Benutzer hält. Er ist auch der Einstiegspunkt für Einzahlungen in EigenLayer. Die zentrale Zugriffskontrolle des gesamten Protokolls ist in diesem Smart Contract implementiert.
Zugriffskontrollmechanismus
Die gesamte Zugriffskontrolle ist durch die Nutzung des AccessManager-Moduls von OpenZeppelin implementiert. Der AccessManager Smart Contract verwaltet die Berechtigungen der PufferDepositor- und PufferVault-Verträge.
Der AccessManager definiert verschiedene Rollen, die unterschiedliche Adressen enthalten. Jede Rolle kann dazu berechtigt werden, verschiedene Funktionen innerhalb der AccessManaged-Verträge (d. h. PufferDepositor und PufferVault) aufzurufen. Der AccessManager unterstützt die verzögerte Ausführung einer bestimmten Funktion. Das heißt, wenn einer Adresse eine Rolle gewährt wird, kann spezifiziert werden, ob die von dieser Adresse in dieser Rolle ausgegebenen Vorgänge sofort oder mit einer Zeitverzögerung ausgeführt werden.
Aktuelle Zugriffskontrollkonfigurationen
Nichtsdestotrotz hängt die Wirksamkeit der Zugriffskontrolle von ihrer Konfiguration ab. Wir haben zahlreiche Fälle beobachtet, in denen eine fehlerhafte Konfiguration von ACL-Regeln (Access Control List) zu Sicherheitslücken geführt hat.
Um dies zu adressieren, haben wir die aktuelle Konfiguration des Puffer-Protokolls überprüft und präsentieren die Ergebnisse unten. Bitte beachten Sie, dass diese Ergebnisse nur den Status zum Block 19177155 (07. Feb. 2024, 15:17:35 Uhr +UTC) widerspiegeln.
Rollen
Unten finden Sie eine Tabelle, die die aktuellen Rollen innerhalb des Systems und die dazugehörigen Adressen aufführt.
| Rollen-ID | Adressen mit dieser Rolle | Verzögerte Ausführung | Hinweis |
|---|---|---|---|
| 0 | TimeLock 0x3c28b7c7ba1a1f55c9ce66b263b33b204f2126ea | Nein | ADMIN-Rolle |
| 1 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Ja, mit 604800 Sekunden (7 Tage) | Upgrade der Zielverträge (PufferDepositor und PufferVault) |
| 1 | Community SafeWallet 0x446d4d6b26815f9ba78b5d454e303315d586cb2a | Nein | Upgrade der Zielverträge (PufferDepositor und PufferVault) |
| 22 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Nein | Vermögenswerte an EigenLayer verschieben und Auszahlungsanforderung von EigenLayer initiieren |
Es gibt verschiedene Ausführungspfade, um Funktionen innerhalb des PufferVault-Vertrags auszuführen. Ein Pfad beinhaltet den TimeLock-Vertrag (mit der ADMIN-Rolle – wie in Pfad 1 in der Abbildung gezeigt), und der andere Pfad erlaubt den direkten Aufruf von Funktionen innerhalb des Vaults, wobei die Rolle dem Aufrufer zugewiesen ist. In beiden Fällen muss der Aufruf über den AccessManager erfolgen.
Typ I: Aufruf vom TimeLock-Vertrag
Beachten Sie, dass beim Aufruf einer Funktion vom TimeLock-Vertrag aus die zugewiesene Rolle ADMIN ist. Diese Bezeichnung ergibt sich daraus, dass aus Sicht des Vaults der Aufrufer der TimeLock-Vertrag ist, der die ADMIN-Rolle besitzt. Folglich integriert der TimeLock-Vertrag eine zusätzliche Ebene eines Mechanismus für die verzögerte Ausführung.
- Operation SafeWallet: Diese Komponente kann Funktionen innerhalb des Zielvertrags nach einer Verzögerung von 604.800 Sekunden (etwa 7 Tage) aufrufen.
- Community SafeWallet: Diese Komponente hat die Fähigkeit, sofort Funktionen innerhalb des Zielvertrags aufzurufen. Sie besitzt auch die Befugnis, jede ausstehende Ausführung in der Warteschlange, die von der Operation SafeWallet eingereicht wurde, zu stornieren.
- Pausing SafeWallet: Diese Komponente ist darauf beschränkt, den Zielvertrag anzuhalten (pausieren) und ist nicht autorisiert, andere Funktionen auszuführen.
Typ II: Direkter Aufruf des Vault-Vertrags
Die nachfolgende Methode beinhaltet den direkten Aufruf von Funktionen innerhalb des Vault-Vertrags. Es ist wichtig zu beachten, dass der AccessManager vorgibt, welche Funktionen von den Adressen aufgerufen werden können, die jeder Rolle zugeordnet sind.
| Rollen-ID | Zielvertrag | Zielfunktion |
| 1 | PufferVault | upgradeToAndCall(address,bytes)
0x4f1ef286 |
| 22 | PufferVault | depositToEigenLayer (0x008e0590)
initiateETHWithdrawalsFromLido (0x593961de) initiateStETHWithdrawalFromEigenLayer (0x402064a7) |
Sowohl die Operation- als auch die Community SafeWallet haben die Fähigkeit, die Funktion upgradeToAndCall direkt aufzurufen, um den Zielvertrag zu aktualisieren. Der Hauptunterschied liegt im Timing: Die Community SafeWallet führt diese Aktion ohne jede Verzögerung aus, während für die Operation SafeWallet eine Verzögerung gilt.
Darüber hinaus ist die Operation SafeWallet in der Lage, Funktionen, die Vermögenswerte in EigenLayer übertragen und Auszahlungsanforderungen initiieren, sofort auszuführen.
Aktualisiert am [08. Feb. 2024 10:02:59 Uhr +UTC]
Ein Vorgang zur Entfernung der Operation SafeWallet aus Rolle 1 wurde geplant. Dieser Vorgang soll nach Block 1707940908 ausgeführt werden, was einer geschätzten Verzögerung von etwa 7 Tagen entspricht. Die Simulation dieser eingereihten Transaktionen wurde mit BlockSec Phalcon durchgeführt.
- Die simulierte Transaktion in Phalcon Fork zur Ausführung der eingereihten Operation am 18.02.2024 um 17:59:07 (UTC), zehn Tage später.
- Die simulierte Transaktion zur Abfrage, ob die Operation SafeWallet noch Rolle 1 hat (gibt falsch zurück).
Aktualisiert am [16. Feb. 2024 20:10:23 Uhr +UTC]:
- Die Transaktion zur Entfernung der Operation SafeWallet aus Rolle 1 wurde ausgeführt. Wir können das Ergebnis von Etherscan überprüfen.
Safe Wallet-Konfigurationen
Die Konfiguration einer Safe Wallet beeinflusst ebenfalls die Sicherheit des Protokolls.
| Wallet | Eigentümer | Schwellenwert |
|---|---|---|
| 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 |
Aktualisiert am [08. Feb. 2024 10:02:59 Uhr +UTC]:
- Die Adresse 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 wurde aus der Operation SafeWallet entfernt, wodurch ihre Autorisierung auf 3/5 angepasst wurde.
- Eine Transaktion zur Entfernung von 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 aus der Community SafeWallet wurde initiiert und wartet derzeit auf die Multisig-Genehmigung durch die Community.
- Drei Wallets wurden aus der Pausing SafeWallet entfernt, was deren Konfiguration nun auf 1/9 anpasst.
Zusammenfassung
In diesem Blogbeitrag haben wir die Sicherheitsmechanismen überprüft, die vom Puffer-Protokoll verwendet werden. Insgesamt ist das Design des gesamten Berechtigungssystems umfassend.
Die Community sollte aktiv nach potenziellen Risiken Ausschau halten:
- Die Sicherheit der privaten Schlüssel der Eigentümer der Community SafeWallet ist von größter Bedeutung. Sollten drei private Schlüssel kompromittiert werden, könnte dies einem Angreifer ermöglichen, den Vault zu aktualisieren.
- Die Sicherheit abhängiger Protokolle, wie zum Beispiel EigenLayer, sollte ebenfalls aktiv überwacht werden.
