Skip to content
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

Merged
merged 19 commits into from
Sep 8, 2023

Conversation

vzotova
Copy link
Member

@vzotova vzotova commented Aug 25, 2023

Based on #102
Fixes #112
Refs #69

  • Renames StakeInfo and related interfaces
  • Changes node confirmation: Coordinator.setPublicKey is the source of node confirmations

@vzotova vzotova self-assigned this Aug 25, 2023
@cygnusv cygnusv changed the base branch from main to development August 29, 2023 09:51
@cygnusv cygnusv changed the base branch from development to main August 29, 2023 09:51

contract PolygonChild is FxBaseChildTunnel, Ownable {
contract PolygonChild is ITACoChildToRoot, FxBaseChildTunnel, Ownable {
event MessageReceived(address indexed sender, bytes data);
Copy link
Member

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)

@vzotova vzotova force-pushed the confirmation branch 9 times, most recently from 7ce559f to 69b22bc Compare September 1, 2023 02:52
@vzotova vzotova force-pushed the confirmation branch 4 times, most recently from d7c6265 to 6e91874 Compare September 1, 2023 03:05
@vzotova vzotova marked this pull request as ready for review September 1, 2023 20:51
@vzotova vzotova changed the title [WIP] Operator confirmation from Coordinator to TACo application Operator confirmation from Coordinator to TACo application Sep 1, 2023
@vzotova vzotova mentioned this pull request Sep 5, 2023

ParticipantKey memory newRecord = ParticipantKey(lastRitualId, _publicKey);
keysHistory[provider].push(newRecord);
// keysHistory[stakingProvider][-1].publicKey != _publicKey; // TODO it's a question
Copy link
Contributor

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.

Copy link
Member Author

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");
Copy link
Contributor

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?

Copy link
Member Author

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we uncomment it?

Copy link
Member Author

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);
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Member Author

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");
Copy link
Contributor

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

Copy link
Member Author

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:
Copy link
Member

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?
Copy link
Member

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.

Copy link
Member Author

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");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we uncomment it?

modifier onlySource() {
require(msg.sender == source, "Caller must be the source");
modifier onlyRootApplication() {
require(msg.sender == rootApplication, "Caller must be the root app");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Comment on lines +15 to +16
@click.option("--currency", default=ZERO_ADDRESS)
@click.option("--rate", default=0)
Copy link
Member

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

@cygnusv
Copy link
Member

cygnusv commented Sep 8, 2023

Merging this will also merge commits originally intended by #102 but that were incorrectly merged to the development branch (I didn't notice that PR was targeting development). No harm done anyway since this PR was always based on top of #102

@cygnusv cygnusv merged commit 3456fdc into nucypher:main Sep 8, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Many sources of data for StakeInfo
5 participants