-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Operator confirmation from Coordinator to TACo application #114
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we uncomment it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uncommented and updated that check
|
||
if (amount != fromAmount) { | ||
info.authorized = amount; | ||
emit AuthorizationUpdated(stakingProvider, amount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks I'll add event OperatorConfirmed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO I'd just throw, but I have a bias for throwing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 | ||
reward_duration: 604800 # one week in seconds | ||
deauthorization_duration: 5184000 # 60 days in seconds | ||
verify: False | ||
rinkeby: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we uncomment it?
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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
@click.option("--currency", default=ZERO_ADDRESS) | ||
@click.option("--rate", default=0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to have defaults here? Are these default values actually allowed?
} | ||
} | ||
|
||
contract TestnetTACoChildApplication is AccessControlUpgradeable, TACoChildApplication { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
Based on #102
Fixes #112
Refs #69
StakeInfo
and related interfacesCoordinator.setPublicKey
is the source of node confirmations