You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is proof of concept repository intented to demonstrate the ability of layered approach in smart contract development to encapsulate security tasks to the layers that act as middleware.
3
+
This is proof of concept repository intended to demonstrate the ability of layered approach in smart contract development to encapsulate security tasks to the layers that act as middleware.
4
4
5
5
## Concept
6
6
7
7
Provide a wrapper(s) to the contract only entry point (i.e. `fallback()`) access management.
8
8
9
-
Make each wrapper eligible to receive complete information data (`msg.*` fields) via standartized API. Rely on wrappers to revert transactions per their internal logic conditions.
9
+
Make each wrapper eligible to receive complete information data (`msg.*` fields) via standardized API. Rely on wrappers to revert transactions per their internal logic conditions.
Layer contracts are separate middlewares that are agnostic from a particular protected contract and can accept a configuration from the caller as well as message fields and analyze them. If layer is failing to validate inputs it must revert.
15
+
Layer contracts are separate middlewares that are agnostic from a particular protected contract and can accept a configuration from the caller as well as message fields and analyze them. If layer is failing to validate inputs it must revert.
16
16
17
-
Such architectural decision allows for each layer to be managed by independedent security provider. Such can be upgraded and managed orthogonally and accomodate large amount of secured contracts.
17
+
Such architectural decision allows for each layer to be managed by independent security provider. Such can be upgraded and managed orthogonally and accommodate large amount of secured contracts.
18
+
19
+
#### Initialization
20
+
21
+

22
+
23
+
#### Operation
24
+
25
+

18
26
19
27
## Implementation
20
28
21
-
In this proof of concept a simple rate limiter is implemented which limits number of transactions a method can be called during one block, reducing ability to drain contract funds.
29
+
In this proof of concept a simple rate limiter is implemented which limits number of transactions a method can be called during one block, reducing ability to drain contract funds.
22
30
23
31
[LayeredProxy](https://github.com/peersky/smart-contract-layers/blob/main/src/LayeredProxy.sol) contract is modified version of TransparentUpgradeableProxy which adds a layered pattern that is defined by [LibAccessLayer](https://github.com/peersky/smart-contract-layers/blob/main/src/LibAccessLayers.sol) in form of a [modifier](https://github.com/peersky/smart-contract-layers/blob/main/src/AccessLayers.sol)
24
32
@@ -27,20 +35,3 @@ Contract protecting the implementation only needs to implement a [ILayer](https:
27
35
Drainer contract calls victim number of times defined by Drainer function input.
28
36
29
37
In the particular implementation rate is limited to 10 transactions per block and can be tested by `pnpm test`
30
-
31
-
### Benchmarking
32
-
33
-
Given by hardhat compiler with settings as per hardhat.config.ts. Rate limits adjusted for each column (not testing reverted gas consumption).
34
-
Tested consumption of Drainer `drain(address payable victim, uint256 cycles)` function.
35
-
36
-
Benchmark is given for RateLimiting functionality assuming that drain function can have different `cycles` argument
37
-
38
-
| First Header | gas used (cycles=1) | delta from fixture |
0 commit comments