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

feat(sequencer)!: implement bridge sudo and withdrawer addresses #1142

Merged
merged 21 commits into from
Jun 8, 2024

Conversation

noot
Copy link
Collaborator

@noot noot commented Jun 4, 2024

Summary

we want bridge accounts to be "upgradable"; ie. we want to be able to change the key which can control the bridge account without changing the bridge address from the rollup's point of view. with this change, we have a sudo key and a withdrawer key for each bridge account, which is set when the bridge account is initialized. the sudo key is able to change the sudo key and withdrawer key. the withdrawer key is the only key allowed to withdraw funds from the bridge account.

Background

see above

Changes

  • change InitBridgeAccountAction to contain a sudo_address and withdrawer_address which are set in state
  • change BridgeUnlockAction to have a bridge_address field which is the bridge address withdrawn from; it also checks if the signer of the tx is the bridge withdrawer_address and fail if not
  • implement BridgeSudoChangeAction which allows the bridge sudo key to change the bridge sudo and/or withdrawer keys
  • Ics20Withdrawals from bridge now also do a withdrawer key check like BridgeUnlockAction; bridge_address was added to the action in the case that the withdrawer differs from the bridge address
  • disallow Transfer from a bridge account, as BridgeUnlockAction or Ics20Withdrawal must be used.

Testing

unit tests

Breaking Changelist

  • InitBridgeAccount stores two new keys in state: the bridge sudo key and the bridge withdrawer key
  • a new action, BridgeSudoChangeAction is added
  • this is breaking on the sequencer state machine level.
  • however it should NOT be breaking on the protobuf level as nothing was removed, only new fields/messages were added, and the new fields added are allowed to be unset. if the fields are unset, it gets converted to a None in the native rust type.

@github-actions github-actions bot added proto pertaining to the Astria Protobuf spec sequencer pertaining to the astria-sequencer crate labels Jun 4, 2024
@noot noot marked this pull request as ready for review June 4, 2024 18:51
@noot noot requested review from a team, joroshiba and SuperFluffy as code owners June 4, 2024 18:51
@noot noot changed the title feat(sequencer): implement bridge sudo and withdrawer addresses feat(sequencer)!: implement bridge sudo and withdrawer addresses Jun 4, 2024
Comment on lines 174 to 177
// the address corresponding to the key which has sudo capabilities;
// ie. can change the sudo and withdrawer addresses for this bridge account.
astria.primitive.v1.Address sudo_address = 4;
// the address corresponding to the key which can withdraw funds from this bridge account.
Copy link
Member

Choose a reason for hiding this comment

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

Can we note in comments what happens if they are left a null?

@@ -27,6 +27,7 @@
"sequence_byte_cost_multiplier": 1,
"init_bridge_account_base_fee": 48,
"bridge_lock_byte_cost_multiplier": 1,
"bridge_sudo_change_fee": 24,
Copy link
Member

Choose a reason for hiding this comment

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

does this make this a hard fork requiring network regen change?

In general actually, we probably need an answer for this. We should be able to add actions with fees without regenesis of network

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes, this would be a hard fork. without hard fork logic this is a regenesis

// the new withdrawer address; unchanged if unset
astria.primitive.v1.Address new_withdrawer_address = 3;
// the asset used to pay the transaction fee
bytes fee_asset_id = 4;
}

message FeeChangeAction {
Copy link
Member

Choose a reason for hiding this comment

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

I believe we need a new entry for FeeChangeAction

/// - if the `bridge_address` field is not set
/// - if the `bridge_address` field is invalid
/// - if the `new_sudo_address` field is invalid
/// - if the `new_withdrawer_address` field is invalid
Copy link
Member

Choose a reason for hiding this comment

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

fee_asset_id can also be invalid?

Comment on lines +43 to +50
// check that the sender of this tx is the authorized withdrawer for the bridge account
let Some(withdrawer_address) = state
.get_bridge_account_withdrawer_address(&bridge_address)
.await
.context("failed to get bridge account withdrawer address")?
else {
bail!("bridge account does not have an associated withdrawer address");
};
Copy link
Member

Choose a reason for hiding this comment

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

similar to above, what about old bridge accounts and during sync this will fail for old unlocks

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

same as above, user would need to set their sudo/withdrawer addrs before using

@@ -24,6 +24,7 @@ impl Component for BridgeComponent {
async fn init_chain<S: StateWriteExt>(mut state: S, app_state: &Self::AppState) -> Result<()> {
state.put_init_bridge_account_base_fee(app_state.fees.init_bridge_account_base_fee);
state.put_bridge_lock_byte_cost_multiplier(app_state.fees.bridge_lock_byte_cost_multiplier);
state.put_bridge_sudo_change_fee(app_state.fees.bridge_sudo_change_fee);
Copy link
Member

Choose a reason for hiding this comment

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

It seems like this will break if we don't have a fee set in genesis so node could not sync with old genesis?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes, would need hard fork logic

Copy link
Member

@joroshiba joroshiba left a comment

Choose a reason for hiding this comment

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

Approved, with note that this will be major breaking change, requiring regensis and a dusk-8. Moving forward if we add actions with new fees I think we should simply disallow the action to be run if a fee has not been set. This provides a mechanism through which we can add a new action without changing the genesis.

@noot noot enabled auto-merge June 8, 2024 21:22
@noot noot added this pull request to the merge queue Jun 8, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 8, 2024
@noot noot added this pull request to the merge queue Jun 8, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 8, 2024
@noot noot requested a review from a team as a code owner June 8, 2024 22:59
@noot noot requested a review from quasystaty1 June 8, 2024 22:59
@github-actions github-actions bot added the cd label Jun 8, 2024
@noot noot added this pull request to the merge queue Jun 8, 2024
Merged via the queue into main with commit 29baa40 Jun 8, 2024
38 checks passed
@noot noot deleted the noot/bridge-accounts branch June 8, 2024 23:11
steezeburger added a commit that referenced this pull request Jun 10, 2024
* main:
  fix: ignore RUSTSEC-2021-0139 (#1171)
  chore(sequencer-relayer)!: remove functionality to restrict relaying blocks to only those proposed by a given validator (#1168)
  chore(metrics): update `metric_name` macro to handle a collection of names (#1163)
  fix(bridge-withdrawer): skip linting generated contract code (#1172)
  fix(core, sequencer): prefix removal source non-refund ics20 packet (#1162)
  chore(docs): add sequencer-relayer doc to specs (#1126)
  feat(bridge-withdrawer): sync logic (#1165)
  chore(withdrawer): replace contracts with `astria-bridge-contracts` submodule (#1164)
  feat(sequencer)!: implement bridge sudo and withdrawer addresses (#1142)
  feat(sequencer): implement refund to rollup logic upon ics20 transfer refund (#1161)
  feat(bridge-withdrawer): bridge withdrawer startup (#1160)
  feat(core, proto)!: add bech32m addresses (#1124)
  feat(withdrawer): bridged ERC20 token withdrawals (#1149)
  feat(sequencer-relayer)!: add chain IDs for sequencer and Celestia to config env vars (#1063)
  test(bridge-withdrawer): add submitter tests (#1133)
  chore: bump penumbra deps (#1159)
  feat(sequencer): implement `bridge/account_last_tx_hash` abci query (#1158)
  fix(withdrawer): use block subscription in batcher; send to destination_chain_address (#1157)
  fix(withdrawer): update AstriaWithdrawer to check that withdrawal value is sufficient (#1148)
  chore(ci): build bridge withdrawer images (#1156)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bridging cd proto pertaining to the Astria Protobuf spec sequencer pertaining to the astria-sequencer crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants