Malicious actor cause rebase to an old inflation multiplier
The protocol has a rebasing mechanism that allows to sync the inflation multiplier between both L1 and L2 chains. The call to rebase is permissionless (anyone can trigger it). Insufficant checks allow a malicious actor to rebase to an old value.\\n```\\n    function rebase(uint32 _l2Gas) external {\\n        inflationMultiplier = IECO(l1Eco).getPastLinearInflation(\\n            block.number\\n        );\\n\\n        bytes memory message = abi.encodeWithSelector(\\n            IL2ECOBridge.rebase.selector,\\n            inflationMultiplier\\n        );\\n\\n        sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);\\n    }\\n```\\n\\nA malicious actor can call this function a large amount of times to queue messages on `L2CrossDomainMessenger`. Since it is expensive to execute so much messages from `L2CrossDomainMessenger` (especially if the malicious actor sets `_l2Gas` to a high value) there will be a rebase message that will not be relayed through `L2CrossDomainMessenger` (or in failedMessages array).\\nSome time passes and other legitimate rebase transactions get executed.\\nOne day the malicious actor can execute one of his old rebase messages and set the value to the old value. The attacker will debalance the scales between L1 and L2 and can profit from it.
When sending a rebase from L1, include in the message the L1 block number. In L2 rebase, validate that the new rebase block number is above previous block number
debalance the scales between L1 and L2 ECO token
```\\n    function rebase(uint32 _l2Gas) external {\\n        inflationMultiplier = IECO(l1Eco).getPastLinearInflation(\\n            block.number\\n        );\\n\\n        bytes memory message = abi.encodeWithSelector(\\n            IL2ECOBridge.rebase.selector,\\n            inflationMultiplier\\n        );\\n\\n        sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);\\n    }\\n```\\n