Operator confirmation from Coordinator to TACo application#114
Operator confirmation from Coordinator to TACo application#114cygnusv merged 19 commits intonucypher:mainfrom
Conversation
contracts/xchain/PolygonChild.sol
Outdated
|
|
||
| contract PolygonChild is FxBaseChildTunnel, Ownable { | ||
| contract PolygonChild is ITACoChildToRoot, FxBaseChildTunnel, Ownable { | ||
| event MessageReceived(address indexed sender, bytes data); |
There was a problem hiding this comment.
This event was removed in a previous commit of my sync branch, since the bridge can't process events in the _processMessageFromRoot callback (see commit b2ea8d9 description)
For both Ethereum Mainnet - Polygon Mainnet and Ethereum Goerli - Polygon Mumbai. See https://wiki.polygon.technology/docs/pos/design/bridge/l1-l2-communication/state-transfer/#prerequisites
Instead of setting the child tunnel with setFxChildTunnel(), which could be prone to front-running.
This way they can grant/revoke updaters, which is useful for testnets, and the admin can revoke themselves if the updaters list is considered final.
Based on the FlatRateFeeModel script
…ed contract, makes child app upgradeable,
Update the x chain deploy script for full TACO test
7ce559f to
69b22bc
Compare
d7c6265 to
6e91874
Compare
6e91874 to
5bce831
Compare
|
|
||
| ParticipantKey memory newRecord = ParticipantKey(lastRitualId, _publicKey); | ||
| keysHistory[provider].push(newRecord); | ||
| // keysHistory[stakingProvider][-1].publicKey != _publicKey; // TODO it's a question |
There was a problem hiding this comment.
I'm in favor of adding this check and preventing unnecessary updates. Allowing this update could trigger some confusing behavior (emitting events, other contract calls, etc.). I think it also prevents confusion on the operator's part - Why would they make an unnecessary update? Could be an operator error.
There was a problem hiding this comment.
agree, but coordinator updates will be in some future PR, here just to not forget
| function setCoordinator(address _coordinator) external onlyRole(DEPLOYER_ROLE) { | ||
| require(coordinator == address(0), "Coordinator already set"); | ||
| require(_coordinator != address(0), "Coordinator must be specified"); | ||
| // require(_coordinator.numberOfRituals() >= 0, "Invalid coordinator"); |
There was a problem hiding this comment.
I see this require is commented out, but I wanted to ask what would motivate this check. Does Coordinator need to be in a certain state (has at least one completed ritual) to be considered a valid Coordinator in the app? Why? Is there some data/state dependency? between the two?
There was a problem hiding this comment.
similar checks in other places work as proof that provider contract has proper abi (or at least one method)
There was a problem hiding this comment.
Uncommented and updated that check
|
|
||
| if (amount != fromAmount) { | ||
| info.authorized = amount; | ||
| emit AuthorizationUpdated(stakingProvider, amount); |
There was a problem hiding this comment.
I noticed that we're emitting an event here. AuthorizationUpdated, but we're not emitting any events in confirmOperatorAddress. Whos is the consumer for the AuthorizationUpdated event?
There was a problem hiding this comment.
thanks I'll add event OperatorConfirmed
There was a problem hiding this comment.
apparently it was already added in that commit bef7fa1
| } | ||
| require(info.authorized > 0, "No stake associated with the operator"); | ||
| // TODO maybe allow second confirmation, just do not send root call | ||
| require(!info.operatorConfirmed, "Can't confirm same operator twice"); |
There was a problem hiding this comment.
IMHO I'd just throw, but I have a bias for throwing
There was a problem hiding this comment.
Throw will allow to use same tx again, and I don't think it would be good. If tx succeeded then you can't use it twice in a bridge
| reward_duration: 604800 # one week in seconds | ||
| deauthorization_duration: 5184000 # 60 days in seconds | ||
| verify: False | ||
| rinkeby: |
There was a problem hiding this comment.
Do we still need rinkeby at all? Can we remove it?
| address stakingProvider = stakingProviderFromOperator[_operator]; | ||
| StakingProviderInfo storage info = stakingProviderInfo[stakingProvider]; | ||
| require(info.authorized > 0, "No stake associated with the operator"); | ||
| // TODO maybe allow second confirmation, just do not send root call? |
There was a problem hiding this comment.
Perhaps I don't get the complete picture - but this makes sense to me. If already confirmed, no need to notify root application as opposed to the require failing.
There was a problem hiding this comment.
this question more to coordinator. If Coordinator will know when to do confirmation (once per bond) or not, more like for future
| function setCoordinator(address _coordinator) external onlyRole(DEPLOYER_ROLE) { | ||
| require(coordinator == address(0), "Coordinator already set"); | ||
| require(_coordinator != address(0), "Coordinator must be specified"); | ||
| // require(_coordinator.numberOfRituals() >= 0, "Invalid coordinator"); |
contracts/xchain/PolygonRoot.sol
Outdated
| modifier onlySource() { | ||
| require(msg.sender == source, "Caller must be the source"); | ||
| modifier onlyRootApplication() { | ||
| require(msg.sender == rootApplication, "Caller must be the root app"); |
| @click.option("--currency", default=ZERO_ADDRESS) | ||
| @click.option("--rate", default=0) |
There was a problem hiding this comment.
Does it make sense to have defaults here? Are these default values actually allowed?
| } | ||
| } | ||
|
|
||
| contract TestnetTACoChildApplication is AccessControlUpgradeable, TACoChildApplication { |
Based on #102
Fixes #112
Refs #69
StakeInfoand related interfacesCoordinator.setPublicKeyis the source of node confirmations