Comment on page
The current scale policy is based on a simple LIMIT OFFSET model. You might have seen something similar when doing pagination on the backend.
Each upkeep will perform a maximum number of operations equal to the limit. The limit must be calculated manually. There are several steps to do this:
- 1.Set upkeep's GasLimit (Chainlink's default: 5000000)
- 2.tx1Gas = gas used by transaction with 1 itteration (e.g 313301)
- 3.tx2Gas = gas used by transaction with 2 itterations (e.g 407000)
- 4.Calculate Delta = tx2Gas - tx1Gas (e.g delta=93699)
- 5.LIMIT = (UpkeepGasLimit - Tx1Gas) / delta (e.g (5000000-313301) / 93699)
- 6.LIMIT = FLOOR(50.01866) = 50
LIMIT (L) = const any INT > 0 aka itterations per Upkeep
OFFSET (O) = PrevOffset + L
LENGTH (N) = upkeeps.length
ACTIVE UPKEEP OPERATIONS (A) = i.e. upkeep.totalOrders; A <= L
Total A = 160
When the last created upkeep no longer has capacity for new operations, the load balancer will create an additional upkeep and increase the total throughput to limit*keepers.length . But for example when the number of operations drops to one, the initial upkeep will be responsible for its execution, but the total dApp throughput will never decrease again and upkeeps won't be deleted.
In the explanation of scaling, we moved away from our abstraction of trades and orders to allow you to understand the approach as well as reuse the architecture in any dApp that needs scaling to work correctly (for example, exceeding the GasLimit of an upkeep)
During the developement we've got some insights, so we can share them:
- Current load balancer PoC implementation is written on Golang, however the same functionality can be reproduced on smart contract side, which might be controlled by another Chainlink Automation then. That will increase decentralization and total dApp security level.
- Scailing policy might be changed from pessimistic constant Limit to GasLimit based. E.g create new upkeep if previous one used >51% of Gas Limit.