Genesis config: custom account types

[mmagician]

As part of the AggLayer integration efforts, we would like to have an ability to bootstrap the node with AggLayerBridge account in the genesis.
This would be a network account with a few items in storage, such as the bridge_owner (another account that's deployed at genesis time) - probably a multisig.
We further need the bridge contract's registry to point to a few AggLayerFaucet accounts (each with its own configuration). The faucet registry is another storage entry. The AggLayerFaucet accounts should also be deployed.

We could take either a very specialized approach here and add support for the three account types:

• AggLayerBridge
• MultisigWallet
• AggLayerFaucet

With one custom account type, a specialized approach might have worked. But IMO since we have three account types that we care about, it's better to have infrastructure in place that allows for specifying any custom account type at genesis.

[Mirko-von-Leipzig]

Is there some mechanism in place that let's a user define such an account, or do we need to design a schema for this here?

cc @drahnr

[bobbinth]

We do have an ability to instantiate account components from account package + initial storage data (see here). Account package can be read from a file package file, and the initial storage data can be read from a TOML file (this structure is currently being somewhat refactored by @igamigo and @mmagician).

But I think there are a couple of things missing:

• We don't have a declarative way to specify the full account - though, maybe just providing a list of packages and a single initial storage data file would work here, and this could be part of the genesis TOML file.
• We don't have a way of "templating" dependencies between accounts. That is, creating a bunch of independent accounts should be pretty easy, but I'm not sure yet how we'd specify that there is a bridge account, and it is owned by a multisig account. The main difficulty here is that to initialize the storage of the bridge account we need to know the ID owner account, but the ID of the owner would be computed only on account instantiation.

---

An alternative approach could be to generate account files (i.e., .mac files) separately using some build script (i.e., Rust code), and, in the genesis config allow to specify these files. My intuition is that this would be the simplest way to do it.

[Mirko-von-Leipzig]

An alternative approach could be to generate account files (i.e., .mac files) separately using some build script (i.e., Rust code), and, in the genesis config allow to specify these files. My intuition is that this would be the simplest way to do it.

This makes the most sense to me since almost any other approach would limit the combinations to whatever subset we want. And having genesis be configurable is useful for testing outside of production.

---

We currently allow specifying the official faucet, and then allow for any amount of wallets & faucet accounts. Allowing arbitrary account files in addition should be fairly straight-forward but maybe we should be careful here.

Does it still make sense for us to have a default genesis which caters for production usage? If its getting this complex (and e.g. multisig should probably be created out-of-band?) then it probably makes more sense for us to leave the current defaults in place as a way to spin up a simple node for testing and instead have our custom accounts generated once-off out-of-band?

Does devnet, and testnet, and mainnet all get all of these?

---

It would be good to have clarity on the accounts, what inputs they need, and which are the node's responsibility to generate at network bootstrapping. This will help figure out if we need a separate binary, or a separate node command to perform this out-of-band or if its simply a subfunction of our existing bootstrap command.

[bobbinth]

This makes the most sense to me since almost any other approach would limit the combinations to whatever subset we want. And having genesis be configurable is useful for testing outside of production.

I think this basically reduces to having two stages for deployment:

1. Run a script (Rust code) to generate the "custom" accounts. This would also update the genesis config file.
2. Then, run our current process.

Does it still make sense for us to have a default genesis which caters for production usage? If its getting this complex (and e.g. multisig should probably be created out-of-band?) then it probably makes more sense for us to leave the current defaults in place as a way to spin up a simple node for testing and instead have our custom accounts generated once-off out-of-band?

Yeah, I think the current approach could stay so that it is easy to spin up a test node that doesn't have Agglayer etc. contracts. But in production settings (including testnet, and potentially devent), we'd probably want to use the "more sophisticated" approach because even the native faucet would probably end up being a multisig.

Does devnet, and testnet, and mainnet all get all of these?

Mainnet and testnet for sure - but not 100% sure about devnet.

It would be good to have clarity on the accounts, what inputs they need, and which are the node's responsibility to generate at network bootstrapping. This will help figure out if we need a separate binary, or a separate node command to perform this out-of-band or if its simply a subfunction of our existing bootstrap command.

My initial thinking it would be a separate binary. The exact inputs are TBD, but here are my preliminary thoughts:

• Native faucet: most likely will be a multisig with keys generated out-of-band.
• AggLayer accounts, there will be several:
  • Bridge manager - to add/remove new faucets, configure bridge throttling parameters, pause the bridge in case of emergency. This will be a local multisig account.
  • Bridge operator - to update global exist roots of the bridge account. This will be a local account, probably a multisig (but also maybe singlesig).
  • Bridge - network account that would need to store account IDs of bridge manager/operator. This means, it would need to be created after the operator/manager accounts have been created.
• AggLayer faucets - these will be network faucets for commonly used assets that we'd want to create at genesis (e.g., ETH and USDC). These will need to have the bridge listed as their owners, but also, the bridge should have them registered. This means, the process of setting these accounts up would be: create the bridge account, create faucet accounts, update the faucet registry in the bridge account.

---

One other approach to mention: technically, everything besides the native faucet could be created after the genesis. We would need to run a script that deploys all these accounts, but there is nothing about them that requires them to be in the genesis block. Whether it is easier to do it this way vs. modifying the genesis creation procedure, I do not know.

[Mirko-von-Leipzig]

One other approach to mention: technically, everything besides the native faucet could be created after the genesis. We would need to run a script that deploys all these accounts, but there is nothing about them that requires them to be in the genesis block. Whether it is easier to do it this way vs. modifying the genesis creation procedure, I do not know.

The absolute simplest would be only having the native faucet in the genesis block. This is even simpler than what we currently have since we also allow specifying additional faucets and wallets.

But this makes creating a test setup for dApps a bit harder since they have to create, prove and submit transactions to get their state in. And wait for that state to commit etc. Since we already allow for multiple accounts (just specialized) I think we may as well keep that.

This does mean we need to accommodate a more complex native faucet which is generated out-of-band. Since that's already a requirement technically, then we may as well proceed with just a list of Accounts and never generate any accounts in the bootstrap command?

[Mirko-von-Leipzig]

@sergerad also raised an interesting question on how the validator can sign the genesis block. This would also have to occur out-of-band? And in the "simple" bundled node case, the validator would be part of the bootstrap process so signing should be possible..

[bobbinth]

@sergerad also raised an interesting question on how the validator can sign the genesis block. This would also have to occur out-of-band? And in the "simple" bundled node case, the validator would be part of the bootstrap process so signing should be possible..

Yes, I think for testing/development use cases we should generate the validator private key as a part of the bootstrap process and then we'd be able to sign the genesis block during this process as well.

For a more production-like deployment, I think signing of the genesis block could be semi-manual, but I hope we won't need to run such process more than a handful of times.

This does mean we need to accommodate a more complex native faucet which is generated out-of-band. Since that's already a requirement technically, then we may as well proceed with just a list of Accounts and never generate any accounts in the bootstrap command?

I think being able to specify a simple genesis state "declaratively" (i.e., the way we do it now) may be useful for testing/development scenarios - but I'll defer to @mmagician, @Keinberger, and @partylikeits1983 on this.

[drahnr]

How many account types do we anticipate to have for genesis states, practical terms? If it's only a handful, I'd prefer to model them explicitly and allow for the full-complexity for anything custom as an addition.

[bobbinth]

How many account types do we anticipate to have for genesis states, practical terms? If it's only a handful, I'd prefer to model them explicitly and allow for the full-complexity for anything custom as an addition.

For testing/development purposes, I think what we have now (basic wallet + fungible faucet with singlesig) is sufficient, I think.

For production (and testnet) purposes, we'd probably need 4 - 5 types, but I think the complexity is not the number of different types but that there are inter-dependencies between the accounts we'd want to deploy.

[drahnr]

We could enforce dependencies through ordering, such that any DAG can be represented. If we are looking at 4-5 types I am in favor of making an enum representation and explicit configuration rather than a complex setup process with multistep command invocations (iiuc).

[Mirko-von-Leipzig]

We could enforce dependencies through ordering, such that any DAG can be represented. If we are looking at 4-5 types I am in favor of making an enum representation and explicit configuration rather than a complex setup process with multistep command invocations (iiuc).

I think the problem is more that it will be several accounts that need to be aware of each other, one after the other.

As a fictional example, the account generation script would be non-trivial and would include many builders and templates.

let key = generate_key_pair();

let account_a = Account::builder()
    .with_code(..)
    .with_assets(..)
    .build()
    .unwrap();

let code_b = CustomAggScript::template()
    .with_fpi_root(account_a.code().mast_root())
    .inject_public_key(key.public())
    .other_stuff()
    .build()
    .unwrap();

let account_b = ...

// and so on with other accounts

Its also possible this would need iteration at a pace that is faster than what the node binary currently supports i.e. devnet would want to see changes pretty quickly to let us arrive at the right space.

---

NB: I'm just speculating with the above.

I'm not actually against specializing the genesis production, just stating that the node code will be less.. unstable if we just accept a list of prebuilt accounts.

[bobbinth]

I think the problem is more that it will be several accounts that need to be aware of each other, one after the other.

Yes - and there are also circular dependencies as well (e.g., the bridge needs to store account Ids for AggLayer faucets, and AggLayer faucets need to have the bridge set as their owner).

---

I think there are two primary ways we can go about this:

1. Pre-built the genesis with all the relevant accounts - in this case, we'd need to build the accounts beforehand and enable the ability to link to an arbitrary account file from the genesis config file.
2. Include the minimal set of accounts at genesis (e.g., potentially just the native faucet), and then run a script that would create all other accounts using regular transactions. A couple of cavities to this approach:
   a. We would still keep the current format of the config file to allow pre-creating wallets/faucets - primarily for dev/testing purposes.
   b. We would need to add some functionality to the genesis config file to allow specifying out-of-band keys for the native faucet.

Depending on how easy it is to support 2b, the amount of work may be comparable to the work needed to supporting approach 1.