Skip to main content

RFC 0048: Rosetta Zkapps

Original source: 0048-rosetta-zkapps.md

Summary​

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.

Motivation​

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.

Detailed design​

The work encompassed in this upgrading can be broken down into four sections:

  1. Supporting existing legacy transactions with the new archive schema
  2. Handling the new zkApp compatible transactions
  3. Supporting hardforks
  4. Testing

Legacy Transaction Support​

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.

Handling zkApp transactions​

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.

Construction API​

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.

Data API​

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:

  1. Zkapp_fee_payer_dec
  2. Zkapp_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.

Supporting hardforks​

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".

Testing​

Rosetta CLI​

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.

Test-curl​

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.

Drawbacks​

More effort, but needed for tooling support

Rationale and alternatives​

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).

Prior art​

Our existing implementation of Rosetta and archive schemas.

Also see the Rosetta spec.

Unresolved questions​

None at this time.