Sovereign Audit remediations

[ignasirv]

The following PR implements de remediations for the audit.
It also fixes a security issue found aposteriori of the audit:

• At sovereign contracts, for the context of a sovereign chain that also has FEP (full execution proofs) there is the possibility to insert arbitrary GER, make claims, and restore previous GER and get the transition proved.
  To avoid this behavior, the following remediations have been implemented:
  • The address that can insert GER and the address that can remove GERs is different, opening the possibility to set zero address to remove GERs functionality, specialy designed for FEP chains
  • A function unsetMultipleClaimedBitmap to unset claims from the bitmap has been implemented -> IMPORTANT to audit with careful, it makes tricky bit operations. Can only be called by bridgeManager
  • Many functions from main bridge contract are being overwritten at sovereign contract removing some unnecessary checks int the sovereign context. This has been done to reduce bytecode length to 24kb and make de sc deployable
  • Function setSovereignTokenAddress has been removed for bytecode length performance improvement
• Due to this new changes, the bytecode exceeds the limit for a smart contract to be deployed, so some functions from PolygonZkEVMBRidgeV2 has been overwritten. They have been overwritten without some checks only necessary for bridges that are being deployed on L1, which is not the case.
• The scripts and tests have been updated accordingly

[invocamanman]

this comment might not be right?¿ we coudl have a timelock or multisig for it, ( could improve the comment with it)

[ignasirv]

What do you mean? I understood that in case of a FEP chain, this address has to be zero. Indeed, if it's not zero can be a multisig but what happens with the comment?

[sonarcloud]

Quality Gate passed

Issues
20 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
31.2% Duplication on New Code

See analysis details on SonarQube Cloud