Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add transaction info to the Block struct #722

Closed
bobbinth opened this issue Jun 2, 2024 · 2 comments
Closed

Add transaction info to the Block struct #722

bobbinth opened this issue Jun 2, 2024 · 2 comments
Assignees
Milestone

Comments

@bobbinth
Copy link
Contributor

bobbinth commented Jun 2, 2024

To support 0xPolygonMiden/miden-node#371, we need to modify the Block struct. Specifically, we need to make sure that information about which transactions updated a specific account is contained within the block.

One way to do it is to add something like transactions field to the BlockAccountUpdate struct. Specifically, this struct could look like so:

pub struct BlockAccountUpdate {
    account_id: AccountId,
    new_state_hash: Digest,
    details: AccountUpdateDetails,
    transactions: Vec<TransactionId>,
}

The reason for using Vec to keep track of transactions is that an account could be updated multiple times within a block and we need to keep track of all relevant transactions.

Another approach is to refactor the Block struct more radically so that it looks something like this:

pub struct Block {
    header: BlockHeader,
    batches: Vec<TransactionBatch>,
    proof: ExecutionProof,
}

pub type TransactionBatch = Vec<VerifiedTransaction>;

pub struct VerifiedTransaction {
    id: TransactionId,
    account_update: TxAccountUpdate,
    input_notes: InputNotes<Nullifier>,
    output_notes: OutputNotes,
}

Here, VerifiedTransaction is basically the same as the ProvenTransaction but without the proof and block_ref fields.

The benefit of this approach is that we retain all publicly available info about the transactions which went into the block. The downside is that the block becomes "heavier" because we keep info about "ephemeral" transactions. I am not yet sure which approach is better.

Effect on the BlockHeader

Regardless of the approach taken, we need to make sure that the BlockHeader structs contains a commitment to the transaction info. Specifically, given a block we need to make sure that a set of transactions mentioned in the block is consistent with the information in the block header.

For the first approach, this could be accomplished by changing batch_root to tx_hash which would be computed as a sequential hash of (transaction_id, account_id) tuples:

tx_hash = hash(transaction_id_0, account_id_0, ..., transaction_id_n, account_id_n)

This way, we'd be able to confirm that:

  1. No extra transactions were added added to BlockAccountUpdates and no transactions were omitted from them.
  2. Transactions were mapped to the accounts correctly.

For the second approach, we'd also rename batch_root into tx_hash, but now we'd only need to hash transaction IDs:

tx_hash = hash(transaction_id_0, ..., transaction_id_n)

This is sufficient because the VerifiedTransaction struct contains enough info to re-compute transaction_id based on other account update info and note commitments.

One potentially tricky aspect here would be to derive the note tree from the set of verified transactions. But I think if we assume that the output notes are inserted into the note tree in the order in which they appear in the list of transactions, and account for notes which were both created and consumed in the same batch, it should be doable.

@bobbinth bobbinth added this to the v0.4 milestone Jun 2, 2024
@polydez polydez moved this to In Progress in User's testnet Jun 3, 2024
@Dominik1999
Copy link
Collaborator

@hackaugusto @igamigo any thoughts on the two approaches?

@bobbinth
Copy link
Contributor Author

bobbinth commented Jun 7, 2024

Closed by #734.

@bobbinth bobbinth closed this as completed Jun 7, 2024
@github-project-automation github-project-automation bot moved this from In Review to Done in User's testnet Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants