Testnet RPC Requirements

[frisitano]

Introduction

The purpose of this design specification is to outline the necessary JSON-RPC (Remote Procedure Call) endpoints required to support the limited functionality of the test network for the Miden Rollup. The primary objective / functional requirement of the test network is to enable users to send assets from one account to another. To achieve this goal we will outline the JSON-RPC endpoints required to achieve this goal.

We need four core endpoints:

• An endpoint to fetch block data for a specified block number (or hash).
• An endpoint to submit proven transactions.
• An endpoint to fetch the block number and note index for a particular note.
• An endpoint to fetch an inclusion proof for a note.

RPC Endpoints

Transaction Submission

Description: This endpoint allows a user to submit a client side proven transaction.

Method: submit_transaction

Parameters:

• serialized_transaction: The serialized client-side proven transaction object, representing the transaction to be submitted. The object should contain the following fields:
  • account_id: The account that the transaction was executed against.
  • initial_account_hash: The hash of the account before the transaction was executed.
  • final_account_hash: The hash of the account after the transaction was executed.
  • consumed_notes: A list of consumed notes.
  • created_notes: A list of created notes.
  • tx_script_root: The script root of the transaction.
  • block_ref: The block hash of the last known block at the time the transaction was executed.
  • proof: The proof of the transaction.

Please see the ProvenTransaction struct for more insight on this object.

Response:

• If the transaction is successfully submitted, return a transaction ID / hash or some other success response.
• If the transaction fails validation or encounters an error, return an appropriate error message in the JSON-RPC response.

Block Retrieval

Description: This endpoint is used to return information relating to a specific block.

Method: get_block

Parameters:

• block_number: The block number of the block to retrieve (alternatively this could be block hash and we would provide an additional RPC endpoint for fetching the block hash associated with a particular block number).

Response:

• If the block exists and is retrievable, return the block's header or the partially-materialised block.
• If the block does not exist or is not retrievable, return an appropriate error message in the JSON-RPC response.

Note Origin Retrieval

Description: This endpoint is used to retrieve the origin of a particular note of interest. I'm still uncertain if this should be the responsibility of the node or if there should be some third party relational db based component that indexes notes and their origin.

Method: get_note_origin

Paramaters:
We have two potential options:

• note_hash: the hash of the note we want to fetch the note origin for.
• note_metadata: the metadata of the note we are interested in.

Response:

• If the note is located we should return the block number and note index in the note merkle tree for the specified note.
• If the note could not be located then return an appropriate error message.

Note:
The note_hash and note_metadata may not be unique and as such this method may need to account for such cases.

Note Inclusion Proof Retrieval

Description: This endpoint is used to fetch a merkle inclusion proof for a specified note against a specific block reference such that the note can be authenticated in the transaction kernel.

Method: get_note_inclusion_proof

Parameters:

• block_ref: The latest known block the transaction is being executed against.
• note_block_number: The height of the block in which the note is included.
• note_index: The note index in the note tree for which the inclusion proof is requested.

Response:

• If the inclusion proof is successfully retrieved, return the proof in the JSON-RPC response. This response can be a serialized MerkleStore which contains both the MMR proof and the note Merkle tree proof.
• If the inclusion proof cannot be generated return an appropriate error message in the JSON-RPC response.

[hackaugusto]

That is great! I wanted to add a few points I think are also important, which are related to how these endpoints are implemented. IMO we should have these points in mind when choosing the stack and designing the endpoints:

1. Stateless endpoints
2. Great error reporting from the start
3. Support native and browser clients
4. Performant APIs

The points above are to make sure developers can build great apps with these APIs, which is important to create a great ecosystem. Here are the motivation behind some of the above points:

• For 1: Ethereum's filter API is an example of stateful API. APPs can register event filters, but if the Ethereum node is restarted the filters are lost, which breaks an app relying on it. In our case, that would be relevant for note filtering, so I think we should not support endpoints to register filters on the server side.
• For 4: This is to emphasize against 1., we can still have an efficient API that allows the server to filter data, for example the notes mentioned above. It is just that the cursor should be sent by the client on every request instead of installed on the server.

With the above in mind, I think that:

• We should use OpenAPI instead of JSON-RPC. It has builtin schemas to help detecting issues in the client side (point 2), and it also has some other benefits, for example, it is easier to have consistent naming conventions and there is already great tooling available
• We should support batching, for example, sending multiple transactions in a single request. This is good for performance, since it requires fewer HTTP(S) connections, and better for debugging, since the client can specify ordering among transactions (useful for network transactions that touch more than one account)
• We should support websockets. Because good error reporting tracks the state of a single transaction until it is confirmed, and without websockets the connection would be "lost" for the in-transit transaction, and would likely timeout before that is added to the rollup.

[bobbinth]

This looks great! Thank you! A few questions/comments:

Transaction submission

This is how I roughly thought about this as well. In the future, we could add execute_transaction method which could be used for executing public transactions.

One open question in my mind is what do we get back in the response. We currently don't have a notion of transaction ID or hash, and even if we did, this value could probably be computed by the user themselves. So, maybe just getting back success/failure is enough?

Regarding failures, I think we should check the following and return appropriate error codes:

• Initial account hash is outdates (i.e., the account is currently in a different state).
• Any of the input notes have already been consumed.
• The proof is invalid.

The first two would require lookups against account and nullifier databases. The third one would involve non-negligible computation (i.e., 5m - 15ms). So, we should think of these as potential vectors for DoS attacks. One way to mitigate these is to require clients to submit some PoW with the request. The core idea is to make the cost of a request for the client ~1000x higher than the cost for the node to reject an invalid request. But this is probably not something we'd do for the private testnet.

Block retrieval

This also agrees with how I was thinking about it. I do have a few suggestions/questions here:

On the request side, besides the block number, it might be good to be able to specify something like last to get info about the latest block.

On the response side, how were you thinking about partially materialized blocks? Or more generally, should we be able to specify which parts of the block to return? There could be a few options here:

1. By default we always get just the block header.
2. We could also request to get a "compacted block" which would contain such things as hashes of created notes, consumed nullifiers, hashes of updated accounts, proof etc. - but would not contain more detailed data about public notes/accounts.
3. We could request to get a full block: same as above + all detailed data about public notes/accounts.
4. We could specify various parts of the block we are interested in. For example, get hashes of all created notes and updated accounts, but data about proof or nullifiers (not sure if such a request would be useful - just listing it as an example).
5. We could specify some more sophisticated filters. For example, get block header + notes which match a certain tag (together with their authentication paths).

I think all of these could be quite useful, but the question is which of these would we need for the private testnet.

Note origin / inclusion proof retrieval

This one I still need to think though a bit more - but I did want to make a couple of comments:

The note_hash and note_metadata may not be unique

Note hash is actually unique - if it wasn't, nullifiers would not be unique either - which would mean only one of colliding notes could be consumed.

I do think we need a way to somehow retrieve notes by their tag - but how this should work requires more thinking.

Nullifier checks

I think we should provide an endpoint to check whether a given nullifier has been consumed. The endpoint for this could look like:

Method: check_nullifiers

Parameters

• A list of nullifiers (probably with some upper bound).

Response

• A list of consumed nullifiers, together with their authentication paths against the latest nullifier root.

One question here is if we want to provide block number as an extra parameter to look up the state of the nullifier DB at a given block. My thinking here is that it'll probably introduce a lot of complexity and benefit of providing this info by the node is marginal. Maybe this info could be aggregated by some 3rd-party services in the future.

[frisitano]

Is this how you were thinking about it as well?

Yes this is what I had in mind. Ideally we would use a WebSocket connection and the node would send the response back to the client once the transaction has been included in a block.

[bobbinth]

Ideally we would use a WebSocket connection and the node would send the response back to the client once the transaction has been included in a block.

This would work only in the centralized setting, right? Or is there a way to make it work in a decentralized setting as well?

[frisitano]

In a decentralised setting the rpc nodes would be run by community members and partners (you can explore the different websocket providers for polkadot and other substrate chains here for an example - https://polkadot.js.org/apps/?rpc=wss%3A%2F%2F1rpc.io%2Fdot#/explorer). They would provide the ability for users / clients to create WebSocket connections to submit and receive receipts of transactions.

[Dominik1999]

This is a very nice discussion. Cool to see the RPC endpoint come to life.

Some thoughts on the above:

Transaction submission

As you laid out, there might be different appropriate error codes, and we need to add more in the future. In addition to your error codes we might need to add some network-specific error codes. We could look at how Aleo implemented their RPC endpoint.

In addition, as a response, I would expect the RPC endpoint to tell me success/failure at submission and then, at some later point, another response when the transaction was executed against the databases/updated.

Block retrieval

For this endpoint, I am not sure if I understand why we need it for our private testnet. When we have an endpoint for get_notes_by_tag (as suggested by Bobbin in the next comment) and one endpoint to submit a transaction, then I am not sure what a Client uses this information for, especially if the client doesn't capture the state of the rollup locally, most of the information on the block will not be useful.

[Dominik1999]

In a decentralised setting the rpc nodes would be run by community members and partners (you can explore the different websocket providers for polkadot and other substrate chains here for an example - https://polkadot.js.org/apps/?rpc=wss%3A%2F%2F1rpc.io%2Fdot#/explorer). They would provide the ability for users / clients to create WebSocket connections to submit and receive receipts of transactions.

I think for now I would not think about the decentralized setting too much. I would stick to the simple case and a centralized operator providing an RPC endpoint.

[bobbinth]

One thing I'm trying to figure out how we can reduce the amount of data a node needs to keep as much as possible. Main reason is that in high-throughput scenarios storage requirements will grow very quickly. For example, at 1K TPS if we store historical data we'd need almost 10TB of storage per year. And at 10K TPS that would grow proportionally to 100TB/year.

Another reason is that most of this data is actually not needed to operate the network. Here we benefit both because of ZKPs and because we are a rollup and the benefit is that we don't need to download any historical data to know that the latest state is valid. So, to sync a new node, it may actually be cheaper to send the latest state than historical deltas which build up to this state.

For example, let's say there are 1B accounts in the system (for simplicity, let's assume that all of these are private accounts). Sending hashes of all these accounts to someone would require 40GB. At 1K TPS, if each block stores (acct_id, final_acct_hash) tuples for accounts which were updated in that block, we'd get to 40GB in under a month. So, basically, after about a month, it would be cheaper to send someone the full state of the account database than to send historical data which can be replayed to rebuild it.

To take a step back, with each block we probably want to include the following:

• Block header
• New states of updated accounts. For private accounts this would be just (acct_id, new_acct_hash) tuples. For public accounts this would also need to include storage/vault deltas.
• Nullifiers for all notes consumed by the block.
• Notes created in this block. For private notes this would be just (note_hash, tag, sender, num_assets). For public notes this would also include inputs, script etc.
• Potentially a set of transaction hashes for transactions executed in this block.
• A ZK proof that the block was computed correctly.

A lot of this data is needed by the node only for a relatively short period of time. Specifically:

• As mentioned above, per-block account updates are needed only until it becomes cheaper to send the entire state. The period here could be between a few months and a year.
• Nullifier data is needed only for the last 2 epochs (see here for more info).
• Ideally, information about private notes should be kept until users download relevant note origin data - though, unfortunately, I don't think there is a way to identify when that happens. For public notes, it should be kept until notes are consumed.
• List of transactions in a block is also relevant for a relatively short period of time (i.e., until the user checks if their transaction has been included in the chain) - though similarly to private notes above, I don't think we can identify when that happens.
• ZK proofs can probably be discarded as soon as the proof for the next block is generated.

So, I'm wondering if we should take the above considerations into account as we think through the RPC endpoints. Also, it seems to me that these endpoints will have 2 targets: clients (what we are thinking about now) and other nodes - and I wonder if we should look at them more comprehensively.

For example, to stay synced, a node may want to request the following data:

• All block headers after block $x$.
• Latest state of accounts for accounts updated after block $x$.
• All nullifiers created after block $x$.
• All notes created after block $x$.

If we want a node to be able to serve such requests, the node would need to have latest account states, nullifiers, and notes indexed by block number. For nullifiers and notes this would be similar to downloading data block-by-block, but for account latest states this would be somewhat different as we need only the latest state. One potential implication of this is that maybe we shouldn't promise the ability to retrieve detailed account data by block.

From the client perspective, I think that the things we want to do are:

1. Submit transactions - I think we already have a good solution for this.
2. Check if a submitted transactions has been included in a block - maybe we can do it via transaction receipts but I wonder if there is a solution which requires less overhead.
3. Check if there are notes available for us to consume and retrieve info needed for consuming them (i.e., the note origin data).
4. Check if a note has been consumed already - I think we have a good solution for this.

For number 3, I do think it is better to use tag than note hash (although maybe we can provide both). I'm imagining the following endpoint:

Method: get_notes_by_tag

Description: finds the first block with block_number greater than the specified block number where there is at least one note matching the specified tag and returns all notes matching this tag from the block.

Parameters:

• block_number - only blocks after this number will be queries.
• tag_min - minimum value of the tag.
• tag_max - maximum value of the tag. Initially, we could say that this must be equal to tag_min.

Response:

• chain_tip - number of the latest block in the chain.
• block_number - number of the block in which the first note matching the criteria was found.
• note_list - a list of notes found in the block where each note is a tuple (note_hash, sender, tag, num_assets, note_index).
• merkle_proof - a batch Merkle proof for all returned notes (i.e., Merkle paths with redundant nodes removed).

In the above, identifying the notes by (block_number, tag) shouldn't be too difficult as both of these are just 64-bit integers. Building a Merkle proof, however, could get pretty complicated - so, more analysis is needed on whether this endpoint is desirable as is.

[frisitano]

One thing I'm trying to figure out how we can reduce the amount of data a node needs to keep as much as possible. Main reason is that in high-throughput scenarios storage requirements will grow very quickly. For example, at 1K TPS if we store historical data we'd need almost 10TB of storage per year. And at 10K TPS that would grow proportionally to 100TB/year.

I think we should make a distinction here. Full nodes only need to store the most recent states - states associated with a few hundred of the most recent blocks but archive nodes should store the full historical state. A Geth archive node is approximately ~14TB right now.

Another reason is that most of this data is actually not needed to operate the network. Here we benefit both because of ZKPs and because we are a rollup and the benefit is that we don't need to download any historical data to know that the latest state is valid. So, to sync a new node, it may actually be cheaper to send the latest state than historical deltas which build up to this state.

Agreed, syncing block by block from genesis is inefficient. We should endeavour to implement something similar to snap sync and also have support for checkpoint sync.

• Ideally, information about private notes should be kept until users download relevant note origin data - though, unfortunately, I don't think there is a way to identify when that happens. For public notes, it should be kept until notes are consumed.

We can consider putting the responsibility of storing comprehensive note data onto the archive nodes. The trust assumption is that the network has at least one archive node that can provide this information to a client that makes a request.

So, I'm wondering if we should take the above considerations into account as we think through the RPC endpoints. Also, it seems to me that these endpoints will have 2 targets: clients (what we are thinking about now) and other nodes - and I wonder if we should look at them more comprehensively.

I think we need to make a distinction here. Typically clients (e.g. wallets, web apps etc) connect via RPC endpoints where as nodes (full nodes, light nodes and archive nodes) connect and sync via the peer-to-peer network (devp2p / libp2p). The RPC endpoints should be designed with clients in mind.

For example, to stay synced, a node may want to request the following data:

• All block headers after block x.
• Latest state of accounts for accounts updated after block x.
• All nullifiers created after block x.
• All notes created after block x.

If we want a node to be able to serve such requests, the node would need to have latest account states, nullifiers, and notes indexed by block number. For nullifiers and notes this would be similar to downloading data block-by-block, but for account latest states this would be somewhat different as we need only the latest state. One potential implication of this is that maybe we shouldn't promise the ability to retrieve detailed account data by block.

I think archive nodes should be able to provide detailed account data for an account at any block. A full node will only store detailed account data for the last few hundred blocks and then it'll be purged.

For number 3, I do think it is better to use tag than note hash (although maybe we can provide both). I'm imagining the following endpoint:

Method: get_notes_by_tag

Description: finds the first block with block_number greater than the specified block number where there is at least one note matching the specified tag and returns all notes matching this tag from the block.

Parameters:

• block_number - only blocks after this number will be queries.
• tag_min - minimum value of the tag.
• tag_max - maximum value of the tag. Initially, we could say that this must be equal to tag_min.

Response:

• chain_tip - number of the latest block in the chain.
• block_number - number of the block in which the first note matching the criteria was found.
• note_list - a list of notes found in the block where each note is a tuple (note_hash, sender, tag, num_assets, note_index).
• merkle_proof - a batch Merkle proof for all returned notes (i.e., Merkle paths with redundant nodes removed).

In the above, identifying the notes by (block_number, tag) shouldn't be too difficult as both of these are just 64-bit integers. Building a Merkle proof, however, could get pretty complicated - so, more analysis is needed on whether this endpoint is desirable as is.

Say we have notes with a specific tag created in blocks n and n+1, this method would only identify the notes associated with block n. I guess you could then execute another request starting at n to get the notes from n+1. Is this what you had in mind?

[bobbinth]

We should endeavour to implement something similar to snap sync and also have support for checkpoint sync.

Depending on a situation, we may be able to do something even simpler (i.e., no need to download any historical blocks at all).

I think we need to make a distinction here. Typically clients (e.g. wallets, web apps etc) connect via RPC endpoints where as nodes (full nodes, light nodes and archive nodes) connect and sync via the peer-to-peer network (devp2p / libp2p). The RPC endpoints should be designed with clients in mind.

Yeah - I think I mix the two together. We won't have a P2P network for private (or even public) testnet - but we probably should think about what endpoints we want to provide for those who want to keep track of the full chain (for indexing or other purposes) because it'll also dictate what data we want to store on the node and how we want to store it.

Say we have notes with a specific tag created in blocks n and n+1, this method would only identify the notes associated with block n. I guess you could then execute another request starting at n to get the notes from n+1. Is this what you had in mind?

Yes, I was thinking about this as a sort of "natural pagination". This is one of the reasons to include chain_tip. This way, if block_num == chain_tip we can know we got everything, but if not - then more requests are needed.

Thinking about it some more, I think it actually wouldn't be too difficult to support tag ranges (and probably even multiple tag ranges). A simplistic implementation would be just to store a vector of min/max note index for every block and traverse this vector starting at the position specified by block_num. The vector is going to be pretty small (i.e., a year worth of data probably fits into L3 cache) - so, lookups would be very quick. But as mentioned in the last comment, the complex part would be to build Merkle proofs.

[Dominik1999]

So, I'm wondering if we should take the above considerations into account as we think through the RPC endpoints. Also, it seems to me that these endpoints will have 2 targets: clients (what we are thinking about now) and other nodes - and I wonder if we should look at them more comprehensively.

To me, that doesn't sound relevant for our private and even public testnet. Am I missing something? I think it will take some time until we reach a decentralized network with >1k TPS.

Method: get_notes_by_tag

I really like this method. Would that merge the originally proposed methods 3) Note Inclusion Proof Retrieval and 4) Note Inclusion Proof Retrieval ?

I remember saying something similar in our call, but I forgot the reasons against it.

Check if a submitted transaction has been included in a block - maybe we can do it via transaction receipts but I wonder if there is a solution which requires less overhead.

Maybe here the Miden Node can send that info to the Client?

From the client perspective, I think that the things we want to do are:

Submit transactions - I think we already have a good solution for this.
Check if a submitted transactions has been included in a block - maybe we can do it via transaction receipts but I wonder if there is > a solution which requires less overhead.
Check if there are notes available for us to consume and retrieve info needed for consuming them (i.e., the note origin data).
Check if a note has been consumed already - I think we have a good solution for this.

I like this list, it sounds user-facing. For now, I would start with the client perspective and not include other nodes.

One other important point to me is, how we can abstract our rather complex model away from the user. Maybe we should think about that right from the start and now.

To stay simple, when I want to send money to Bobbin using e.g. PayPal, I just click send. Bobbin doesn't need to ask PayPal if there is a new payment to him. To the user, it might be quite strange to send money to someone but then the money is not in his account anymore but also not in the recipients.

Maybe in the backend, my PayPal App asks periodically if there is a new payment. But maybe the PayPal server also pushes this info, I don't know. But I think it will be important to think about UX or DevX right from the start.

Aztec is doing something similar here

[bobbinth]

To me, that doesn't sound relevant for our private and even public testnet. Am I missing something? I think it will take some time until we reach a decentralized network with >1k TPS.

For private testnet probably not relevant, but I think we should have the ability for other nodes to stream the whole blockchain from the operator.

Method: get_notes_by_tag

I really like this method. Would that merge the originally proposed methods 3) Note Inclusion Proof Retrieval and 4) Note Inclusion Proof Retrieval ?

I think there are still probably going to be 2 separate methods. In my mind, the two methods are:

• get_notes_by_tag - this returns Merkle paths which authenticate relevant notes against the block header of the block they were created in.
• Something else which will enable the client to sync up the partial MMR they store with the current state of the chain. Naively, this could be an endpoint which retrieves all block headers since a given block height. But we can probably do something better than that.

[bobbinth]

Some more thoughts on get_notes_by_tag:

• As I mentioned in the previous comment, I think this should return Merkle paths only for the note hash to block note root tree. That is, each returned entry should contain (tag, index, merkle_path, hash, sender, num_assets) tuple. This is slightly different from what I described above as before I was thinking we should merge all Merkle paths to remove redundant nodes. But now I think it might be better to just store fully materialized paths. It would mean a potentially significant storage overhead - but also should simplify processing of this data.
• We should send paths in a compressed form - meaning, for each path we send only nodes which are not roots of empty subtrees and we indicate which nodes are roots of empty subtrees using a simple bitmask (21 bits). We could also store paths in this compressed form.
• I'm also thinking that in the future, for public notes, additional note details would be included in the response as well. Though, there is an argument to be made that maybe there should be a separate method to retrieve note details for public notes.
• As mentioned in the previous comment, with this approach, we should define another endpoint which would allow the user to sync the latest state of MMR (naively by downloading all block headers - but probably there is something much better).

[Dominik1999]

Is it somewhere specified already what exactly a user needs to execute a transaction locally? Can we maybe build that in the tx kernel already and then we see what data and in which format is needed?

[frisitano]

Some more thoughts on get_notes_by_tag:

• As I mentioned in the previous comment, I think this should return Merkle paths only for the note hash to block note root tree. That is, each returned entry should contain (tag, index, merkle_path, hash, sender, num_assets) tuple. This is slightly different from what I described above as before I was thinking we should merge all Merkle paths to remove redundant nodes. But now I think it might be better to just store fully materialized paths. It would mean a potentially significant storage overhead - but also should simplify processing of this data.

I think we would also need to return the block number the note is created in such that we can authenticate the note against the correct block header in the chain MMR. When you say store fully materialized paths with the note data do you mean on the node or the client side or both?

• We should send paths in a compressed form - meaning, for each path we send only nodes which are not roots of empty subtrees and we indicate which nodes are roots of empty subtrees using a simple bitmask (21 bits). We could also store paths in this compressed form.

This sounds reasonable. I think we would only need to send the leaf value, non-empty sibling nodes and the bitmask. Everything else can be calculated client side. I think this is what you mean?

• As mentioned in the previous comment, with this approach, we should define another endpoint which would allow the user to sync the latest state of MMR (naively by downloading all block headers - but probably there is something much better).

An alternative would be to provide an endpoint that returns a Partial Mmr for a set of block numbers. Something like:

fn get_mmr_inclusion(block_ref: BlockNumber, target_blocks: Vec<BlockNumber>) -> PartialMmr

This would return a PartialMmr that provides the the data required to authenticate notes that were created in any of the target_blocks. The block_ref is the latest known block at the time of transaction execution. Maybe we don't expose the block_ref argument and instead just return the data against the latest block at the time of the request.

[bobbinth]

Is it somewhere specified already what exactly a user needs to execute a transaction locally?

Yes, we have the definition of CompiledTransaction and other related objects. There are a couple of things that still need to be specified - most important is how the user build note origin object.

[bobbinth]

I think we would also need to return the block number the note is created in such that we can authenticate the note against the correct block header in the chain MMR. When you say store fully materialized paths with the note data do you mean on the node or the client side or both?

Yes, I was thinking this would be included as a separate filed in the response. Basically, I'm imagining something like a BlockNotes object which consists of the following:

• Block number.
• (maybe) Note root - i.e., the root of the Merkle tree for all notes created in this block.
• min_tag and max_tag for this block.
• For all notes in the block the following records sorted by tag:
  • Note index in the block.
  • A fully materialized (compacted) Merkle path which resolves to the above root.
  • Note hash + metadata (tag, sender, num_assets).
  • Maybe additional details for public notes - though, as I think about it more, maybe that should be separate.

This structure could be stored on disk or in a database and it would be used to serve get_notes_by_tag requests. Basically, once we know that there is at least one note of interest in a given block, we we just need to do a binary search though this structure to identify which note records to send, no extra processing is needed.

This sounds reasonable. I think we would only need to send the leaf value, non-empty sibling nodes and the bitmask. Everything else can be calculated client side. I think this is what you mean?

Yes - exactly.

This would return a PartialMmr that provides the the data required to authenticate notes that were created in any of the target_blocks. The block_ref is the latest known block at the time of transaction execution. Maybe we don't expose the block_ref argument and instead just return the data against the latest block at the time of the request.

Yes - I think something like this could work. One thing I'm thinking about is that the client may already have a partial MMR from some point in the past. So, they may only need some incremental data to complete it (with inclusion proofs for some specific blocks). So, I'm wondering if there is some "delta" that the node can send which could be simpler both for the client and the node to process.

[frisitano]

Yes - I think something like this could work. One thing I'm thinking about is that the client may already have a partial MMR from some point in the past. So, they may only need some incremental data to complete it (with inclusion proofs for some specific blocks). So, I'm wondering if there is some "delta" that the node can send which could be simpler both for the client and the node to process.

I think this would be a nice optimisation but I don't think its a hard requirement for testnet. The naive version of sending the PartialMmr is probably sufficient and easier to implement.