# Implemention decisions
[TOC]
## Each chain to handle its state
- `PolygonRollupManager` currently manages the state for each new chain attached
- That data is no longer necessary on the `PolygonRollupManager` since any chain misbehaviour will be detected by the pessimistic proof
- Only necessary data related to pessimistic program statre will be stored on the `PolygonRollupManager`, but still will be inside the `RollupData` struct to not break any possible tool/app the used that struct (unused parans will be set to 0)
- chainAddress
- chainID
- lastLocalExitRoot
- rollupTypeID
- verifierType
- lastPessimisticRoot
- Each chain will not depend on the `PolygonRollupManager` to do anything on its state

## Attaching new chains to the aggLayer
- new function `addChainToAggLayer` will be created to add new chains to the agglayer
- This appraoch maintains compatibility with previous ways to create rollups since previous call `createNewRollup` will be still callable
- It starts moving to a future version/naming where chains manage its own state/consensusImplemention/upgrades
- It clearly separates previous versions (< v0.3.0) vs new ones (>= v0.3.0)
- In future versions, when all the rollups will convert to new version, it will be jusgt a matter of removing the `createNewRollup` function

## Maintain rollupTypes
- Backwards compatibility in this version
- Help to not break any application that rely on rollupTypes struct

## VerifyPessimisticProof
- it's signature will change in order to support v0.3.0 custom autheticators with a new field, `customChainBytes`
- This call will also support veryfing old autheticators
- There will be only one entry point for verification to make life easier to the aggLayer
- SC will handle properly which verifierType is being verified and it will load the correct interface depending on the verifierType

## Add re-entrant checks on the PolygonRollupManager
- Long term goal is to freely open the insertion of the `authenticator_implemention` address
- re-entrant attacks could be done since `calls` will be doing with custom data into `authenticator_implemention` addresses
- Therefore, security mechanism will be also added in this version
- it will also prevent any mistake/error when whitelisting `authenticator_iimplementation`

## Whitelisted `authenticator_implementation`
- Not allow any implemention to be submitted
- Polygon's still has some control over them since it will be upgradeable
- Long term vision in to completelly open it
- Short term: add all possible firewalls at SC level
- Polygon to whitelist `authenticator_implemention` (ecdsa & fep)
- ==TODO==: Two rollupTypes(ecdsa & FEP) or manage `default_auth_vkeys` within the `AggLAyerGateway`
- new function `upgradeVKey()` for a given rollupType
- Discussion:
- two rollup types
- does not change current procedure to add rollups and/or to upgrade them
- differentiate between ECDSA and FEP easily (getConsensuHash to ask PolygonRollupManager the rollupTypeID and then, get the `auth_vkey`)
- one rollup type
- who manages the defaults `auth_keys` ?
- could be another contract or the `AggLayerGateway.sol`
- abstarcts the `default_vkey` onto another contract
- how a rollup chooses one key or another ?
- kind of a CONSTANT in the implementation

## Managing auth_vKey
- Each chain will be able to select if it relies on polygon's vKey management or its own
- Chain will be able to select between those two
- Polygon's will update the `auth_vKey` for all the chains at the same time
- update should happen at rollupType level (or AggLayerGateway)
- consensus to automatically (based on proof SP1 selector) switch over `auth_vkeys`
- add value when updating SP1 Version (because the selector of the proof indicates the SP1 verifier to select)
- but if just the circuit is changed, there is no value since you need to update the auth_vkey anyway and the proof selector will not change
-------------
-------------

# Managing updates
## pp_vkey
- only one version maintained
- not expected to be upgraded quite often
- possible to execute the transaction without synchronizing componenets
- aggLayer 4byte selector
- proof:
- proof[0:4]: 4 bytes selector aggLayer
- proof[4:X]: proof to forward to the verififer
- SP1Verififer
- proof[4:8]: 4 bytes selector SP1 (kept as a sanity check. Could be set to 0x00000000)
- proof[8:X]: Plonk proof

| name | smooth upgrade | selector aggLayer |
|:-------:|:--------------:|:-----------------:|
| pp_vkey | yes | 4 bytes |

mapping(bytes4 => aggLayerRoute) public aggLayerRoutes;

struct aggLayerRoute {
    address verifier; // SP1 Verififer. It contains sanity check SP1 version with the 4 first bytes of the proof. proof[4:]
    bool frozen;
    bytes32 pp_vkey;
}

## auth_vkey
- let each chain to manage its `auth_vkey`
- provide initial implementation
- 4 bytes selector chosen by the chain to choose its `auth_vkey`
- embeded in the `customChainData`
- it can delegate the `get_auth_hash` function

mapping(bytes4 => authRoute) public authRoutes;

struct authRoute {
    bytes32 hash_plonk_vkey;
    bytes32 auth_vkey;
    bool frozen;
}

## default_auth_vkey
- `auth_vkey` provided by aggLayer
- 1 version maintained
- not expected to be upgraded quite often
- with the `plonk_vkey` we will avoid forcing to upgrade
- attached to the `auth_hash`
- attached to the `auth_implementation`
- after the chain is created --> it decides if it want to follow the default values or not
- or create two rollupTypes --> one that follows the default, another that does not folow the default
- when the chain is created, it is decided

## default_auth_implementation
- `get_auth_hash` attached to `default_auth_implementation`

## Open questions
- How a chain determines that uses the default?
- just when the chain is created (rollupType + BeaconProxy)
- once the chain is created --> let the chain choose
- `defaultRoute = true`
- Upgrade implementation
- rollupTypes
- add function to upgrade several rollupTypes in the samne solidity function
- getAuthHash si part of the implementation. Only delegate this execution to the aggLayer is basically changing the circuit, so it will imply a new implementation (if any other param is modified)
- Upgrade implementation
- rollupTypes: default (Beacon --> not needed since there will not be so mant changes) & no-default (as usual)
- proxy change from Beacon to Transparent ? the other way around ?

# Carlos thoughts
- approach that I would follow:
- `auth_vkey` and `plonk_vkey` could be proxied to the `AggLayerGateway`
- one simple parameter in the chain storage. `useDefaultValues`
- create two rollupTypes: ecdsa & FEP
- chain decides to use default values or not
- use rollupTypes if any upgrade is needed on the implemention
- for convinience, create a function that updates several rollups at the same time
- why ?
- delegating also the `getAuthHash` to the `AggLayerGateway` is basically delegating the implementation
- we can opt for doing the Beacon rollupType in order to upgrade all at the same time
- I think it is overkill since mid-term we will be moving into the aggLayer-storage so it is most probably not be used
- We already have a mechanism to upgrade rollups and I do not expect so many chains in the short/medium-term
- We can add a new function to upgrade multiple rollups (to a new rollupType) for convinience
- Easy migration from v0.2.0 to v0.3.0 (using rollupTypes)

# Ignasi's thoughts
- I feel that most of the chains will relay in the gateway to handle their auth keys, the ones that will decide to handle their own keys will be none or low so it's good to do a first approach where most of the logic is supported by the ALGateway, it can be upgraded in the following versions
- In this first versions let's keep relying in rolluptypes for upgrades
- **About beacon proxy**: Maybe it's not that overkill, we can just deploy a fresh new beacon proxy when a rollup is upgraded to ALGatway rollup type following this:
- The rollup will have a new address so we will ahve to update the mapping `rollupAddressToID`
- Update RollupData for the rollup accordingly
- It will lose all the storage stored in the proxy but maybe it's not a problem because Authenticators handle storage completely different so there won't be problem with migration (nothing to migrate at all I think)
- Once a rollup has upgraded to Authenticator won't be posible to go back