(Update) Registration of several bridge in RewardByBlock about poa-network-consensus-contracts HOT 10 CLOSED

@akolotov we have to decide who will have a permission to call addBridgeContract and removeBridgeContract functions. Do you have any suggestions about that?

from poa-network-consensus-contracts.

@varasev I have not found a part of code which allow to set the bridge contract. My understanding now is that it is done by the upgrading the whole RewarByBlock contract. Could addBridgeContract and removeBridgeContract be called in similar manner? It is up to you to implement the ability to control multiple bridge contracts in order to not spoil the current security model.

from poa-network-consensus-contracts.

My understanding now is that it is done by the upgrading the whole RewarByBlock contract.

For now, the value of bridgeContract constant may only be changed by changing the implementation of RewardByBlock. It is possible with VotingToChangeProxyAddress contract, so validators should vote for the change.

We could make another type of voting to add/remove bridge contract address to RewardByBlock. @igorbarinov what can you say about it?

An easier way is to allow these functions to be called only by some Multisig Wallet.

Or allow these functions to be called only by the MoC, for example, but I think it's not secure enough.

from poa-network-consensus-contracts.

What if we do in the same manner how it exists now:
So, instead of

    address public constant bridgeContract = 0x0000000000000000000000000000000000000000;

we will have

    mapping (address => bool) public bridgeContracts;
    bridgeContracts["0x1...a"] = true;
    bridgeContracts["0x2...b"] = true;
    bridgeContracts["0x3...c"] = true;

from poa-network-consensus-contracts.

Yes, we can make the addresses hardcoded. In the case when we want to add some new bridge contract, we can implement addBridgeContract that can be called by anyone but with hardcoded new address and can be called only once. For example:

function addBridgeContract() public {
    address newContract = "0x4...d";
    require(bridgeContracts[newContract] == false);
    bridgeContracts[newContract] = true;
}

The same is for removeBridgeContract:

function removeBridgeContract() public {
    address contractToRemove = "0x1...a";
    require(bridgeContracts[contractToRemove] == true);
    bridgeContracts[contractToRemove] = false;
}

addBridgeContract/ removeBridgeContract function will have to be called after RewardByBlock's implementation is upgraded.

from poa-network-consensus-contracts.

@akolotov Instead of addBridgeContract/removeBridgeContract we could have a single initBridgeContractAddresses as you suggested above:

function initBridgeContractAddresses() public {
    bridgeContracts["0x1...a"] = false; // removed bridge
    bridgeContracts["0x2...b"] = true;
    bridgeContracts["0x3...c"] = true; 
}

from poa-network-consensus-contracts.

To not to change the state of RewardByBlock contract we could just add the next getter in its implementation:

function isBridgeContract(address _addr) public pure returns(bool) {
    if (_addr == "0x1...a") return true;
    if (_addr == "0x2...b") return true;
    if (_addr == "0x3...c") return true;
    return false;
}

And use it inside onlyBridgeContract modifier:

modifier onlyBridgeContract {
    require(isBridgeContract(msg.sender));
    _;
}

from poa-network-consensus-contracts.

It is OK for me. How about ideas for implementation of mintedByBridge?

from poa-network-consensus-contracts.

I'll think about it and implement soon. There shouldn't be any difficulties.

from poa-network-consensus-contracts.

Done in #201.

from poa-network-consensus-contracts.