In this RFC, we describe the changes needed for Rosetta to support the upcoming (pending community approval) Mina hardfork which contains zkApps.
The work entails supporting the existing legacy transactions with the new archive schema, adding support for the hardfork and zkapp transactions, and testing.
We wish for Rosetta to support zkApps and other changes present in the (pending community approval) Mina hardfork.
The desired outcome is fully updating the Rosetta implementation to support this hardfork and sufficiently test it.
The work encompassed in this upgrading can be broken down into four sections:
- Supporting existing legacy transactions with the new archive schema
- Handling the new zkApp compatible transactions
- Supporting hardforks
- Testing
The new archive schema has made a fundamental design shift to record balance changes at the per-block level of granularity rather than the per-transaction one. To read more about this change, see the associated RFC, 0045.
The changes needed for Rosetta to support these changes are outlined in the 0045 RFC under the "Changes to Rosetta" sub-heading.
To summarize, for the Account endpoint, the SQL queries can be simplified to merely a pending and canonical query to the new accounts_accessed table; we no longer need to inspect individual transactions.
For the Block endpoint, adjust the queries to not rely on the bits that are no longer present in the existing tables, and add a new SQL query to use the accounts_accessed table to pull the account-creation-fee parts.
zkApp Transactions will introduce many additions to our Rosetta implementation, but in an effort to keep the scope down, there are a few areas of Rosetta that will not support them.
Rosetta's spec demands that it be able to track all balance changes that result from transactions on the network; however, we don't need to be able to construct all such balances nor do we need to track balance changes that only involve custom tokens. In order to support custom tokens built on top of Mina we would need to both be able to broadcast zkApp transactions and also keep track of token changes.
As such, custom tokens are out of scope and thus the Rosetta Construction flow will not need to change. Instead, we will continue to support the existing legacy transactions.
The Data API will need to change to support zkApps.
Most of the changes will be localized to supporting new zkApps related Rosetta operations and putting them in a new type of Rosetta transaction.
These new transactions will be present in both the /block and /mempool endpoints.
Note: GraphQL queries for zkApp transactions can be generated programmatically as they are quite large.
Operations for zkApps
Operation types should be extended with new operations for all kinds of ways zkApp transactions can manipulate account balances (for each one-sided changes).
Luckily this is made extremely clear by the shape of the zkApps transaction structure.
The following intends to be an exhaustive list of those sorts of operations:
Zkapp_fee_payer_decZkapp_balance_change
Note that only balance changes that correspond with the default MINA token (token_id = 'wSHV2S4qX9jFsLjQo8r1BsMLH2ZRKsZx6EJd1sbozGPieEC4Jf' -- the base58check representation of the Field element "one") should be considered as changes here.
There are many new types of failures and they're per-party in zkApps transactions. These are enumerated in transaction_status.ml. They can be pulled from the zkapp_party_failures table in the archive database. Since the errors are already per-party, they're easily associated with operations on a one-to-one basis. These can be added verbatim to as "reason metadata" to those operations with a Failed label.
Changes will need to be made to /network/status such that the genesis block is the first block of the hardfork network (so it's index will be greater than 1; to be determined when we fork). This is important to be the true block height or else the archive data queries will be incorrect.
/network/list will remain unchanged as in the hardfork world the old network "doesn't exist".
Rosetta has a cli testing tool that must pass on this network.
See the Rosetta README.md for information on how to run this tool.
Ideally we can connect this CI as we've done in the past.
There are a series of shell scripts that can be manipulated to use the transaction construction tool in the src/app/rosetta folder. These should continue to pass: The README.md also contains information on these scripts.
More effort, but needed for tooling support
We considered including custom tokens, but it will be extra work and not really worth the effort at the moment as there are no widely used custom tokens (yet).
Our existing implementation of Rosetta and archive schemas.
Also see the Rosetta spec.
None at this time.