Store endpoint: get_block_inputs

[Dominik1999]

@plafer to describe

[plafer]

This is analogous to #54, but instead provides the block builder with the data it needs to create a block. What this looks like isn't fleshed out yet; it will be after #36

[bobbinth]

Here is what I think could be the specifics of this endpoint:

Request {
    accounts: [list of account IDs to be modified in the proposed block],
    nullifiers: [list of nullifiers produced in the proposed block],
}

Response {
    block_header: [block header of the latest block in the chain],
    chain_peaks: [a list of MMR peaks for the current chain state],
    account_states: [latest account state hashes for all requested account IDs],
    account_proofs: <a partial Merkle tree with paths to all requested accounts in the account TSMT>,
    nullifier_proofs: <a partial Merkle tree with paths to all requested nullifiers in the nullifier TSMT>,
}

account_proofs and nullifier_proofs may be a bit more complex than what I described above. For example, for accounts, what we need are the paths in TSMT to a node which either contains the specified account or is sufficient to insert a new account. In the latter case, we may need to include (account_id, account_hash) tuple for the account which currently occupies the node.

We may also want to send information which maps accounts to node indexes in TSMT. We can derive this info from the other data in the response - but it would probably be much more efficient to send it directly.

The above also applies to nullifier proofs.

[bobbinth]

Most of this endpoint was implemented in #59. There are a few remaining things though:

• Add nullifier info to the response.
• Resolve a potential race condition (see store: add get_block_inputs RPC #59 (comment)).
• Make a potential update to how chain MMR peaks are returned (see Chain MMR commitment in block headers miden-base#305).

[hackaugusto]

@bobbinth I believe the nullifier was not included because it is blocked by this PR 0xPolygonMiden/crypto#211 , right?

[bobbinth]

@hackaugusto - correct. We decided to implement the end-to-end flow without handling nullifiers, and then come back and add handling of nullifiers.

[Dominik1999]

So, until 0xPolygonMiden/crypto#211 is merged, this issue is blocked?

[bobbinth]

So, until 0xPolygonMiden/crypto#211 is merged, this issue is blocked?

Yes. Or alternatively we can close this issue and open another issue which is more targeted and describes only the remaining work.

[Dominik1999]

Then let's close this issue and open another one.