# Upgrade report
## Beforehand

Smart contracts are the backbone of our product; therefore, they require special attention regarding their stableness.

As we would with our skeleton, we would refrain from touching too much of them until it is needed, vital, I would even say.

We aim to blow the dust out of our aging smart contracts without altering them too much.

## Initial state

---
## Goal State

More about the steps that lead from the initial to goal state on [this report](https://hackmd.io/@jq8_nuoBQA-Vr1x4NMKxdw/SkCf3d_TY)

## Road to polygon
One of the first sparks that led to those changes was to follow our partners onto polygon and to prepare us for the road of blockchain agnosticism.

To achieve this, we need two things.

1. An instance of our smart-contact on polygon network
2. both instances of our smart contract on Ethereum and polygon should have a way to transfer currency between each other. That is the polygon bridge.

### Polygon bridge

The [Polygon bridge](https://wallet-dev.polygon.technology/bridge) is a solution to help transfer currency from Ethereum token to their Polygon relative.

Both sides should comply with a specific interface and have some roles settings for it to work. We’ll get that much detailed later.

Both Ether and Polygon’s smart contracts have to answer different interfaces.
We will address smart contracts to be deployed on Ethereum as *RootToken*.
We will address smart contracts to be deployed on Polygon Pos as *ChildToken*
We use this terminology because Ethereum is considered the Root chain and Polygon Pos the Child chain.
#### Role Based Access Control (RBAC)

Openzeppelin’s new version of RBAC is the standard for many smart contracts nowadays and is also for polygon pos’ smart contracts.
Designing our smart contract to be usable on the Polygon’s bridge means using Openzeppelin’s Access Control.

##### We did not change how we managed ownership.

Our smart contracts have been preserved from such massive change. We have added the new RBAC on the smart front-end contract as an extra to comply with Polygon’s bridge requirement. But we did not implement it further.
The only usage of this feature can be found in the Polygon’s bridge-related function.

##### Security through Roles.

Basically, RBAC offers a set of methods like

GrantRole(bytes Role, address User)
RevokeRole(bytes Role, address User)

And are used hand in hand with modifiers or with methods such as this:

contract exemple is AccessControl {
  bytes32 public constant EXEMPLE_ROLE = keccak256("EXEMPLE_ROLE");

  function mint(address to, uint amount)
    override
    onlyRole(EXEMPLE_ROLE) // OPTION 1
    external
    returns (bool ok)
  {
      require(hasRole(EXEMPLE_ROLE, msg.sender), "caller is not EXEMPLE"); // OPTION 2
    _mint(to, amount);
  }
}

(Only one of the two usage OnlyRole or require(hasRole) is needed here, the two of them are both in one function, for example purpose)

##### Polygon’s bridge Roles

* PREDICATE_ROLE
* DEPOSITOR_ROLE

Both of them are supposed to protect the function responsible for minting.
Predicate for Ethereum’s mint. Depositor for Polygon’s deposit.

Those roles are to be held only by Polygon’s chain manager contract proxy.

#### IPolygonPosRootToken

interface IPolygonPosRootToken {
  function mint(address user, uint256 amount) external returns(bool);
}

The only requirement for the RootToken is to have a function named mint.

This function has to be accessible only to the role “PREDICATE_ROLE” held by the `MintableERC20PredicateProxy` (polygon’s smart contract deployed on Ethereum)

#### IPolygonPosChildToken

interface IPolygonPosChildToken {
  function deposit(address user, bytes calldata depositData) external;
  function withdraw(uint256 amount) external;
}

The withdraw function is responsible for burning funds Polygon’s side to be re-issued on Ethereum.
This function is not restricted to any role. It’s open.

The deposit function is responsible for re-issuing the funds burned on Ethereum. As the IPolygonPosRootToken’s mint, this function is restricted only to one role held by a Polygon’s smart contract.
This role is the “DEPOSITOR_ROLE” held by the `ChildChainManager`.

#### The controller’s change

Because we have opened new functionality on our TokenFrontend, we had to connect them to the controller’s method. Some new frontend functionality didn’t have an accessible controller method; therefore, we’ve added a few.

##### burnFrom without caller.

We previously had only a burnFrom_withCaller method to erase funds. This method was heavy and required a signing mechanism to go through.
This was not usable for ChildToken’s withdraw method.

We created a more simple burnFrom function that does not require a signature.

## Dependencies

Upgrading from solidity 0.4.X to 0.8.X was easily done with only the solidity code of the smart contracts. But our project is only 50% solidity code. We use various tools to help users deploy, test, check, and interact with our smart contracts.

Those tools were also from when we first wrote our contracts, so they needed a minor update.


## Migrations

Migrations are our smart-contracts launch pad. They will ship our contracts up to the blockchain the right way.

We now have two deployments—one on the ether network and one on Polygon.

We should then pick the smart contract to be and not to be deployed on each network.

PolygonPosEUR is to be deployed only on Polygon’s network. In contrast, EUR is to be deployed on Ethereum’s network.

We need to control that we don’t deploy both for cost and efficiency.

## Steps to deploy and comply with Polygon Bridge

1. Deploy the smart-contract on Ethereum.
`~> truffle migrate --network=goerli`
2. Verify EUR smart-contract on Etherscan
`~> truffle run verify EUR --network goerli`
3. Grant PREDICATE role to Polygon chain manager
`~> truffle exec scripts/set-predicate-role.js --network=goerli AddressOf(EUR) AddressOf(ChainManager)`
4. Add Frontend address as system account
`~> truffle exec scripts/add-system-account.js --network=goerli AddressOf(EUR) AddressOf(EUR)`
5. Deploy the smart-contract on Polygon Pos
`~> truffle migrate --network=polygon_pos_mumbai`
6. Verify PolygonPosEUR smart-contract on Polygonscan
`~> truffle run verify PolygonPosEUR --network polygon_pos_mumbai`
7. Add Frontend address as system account
`~> truffle exec scripts/add-system-account.js --network=polygon_pos_mumbai AddressOf(PolygonPosEUR) AddressOf(PolygonPosEUR)`