Guardrails: Tx and Block Validation

[sergerad]

Context

Following from #613, we are moving forward with the design and implementation of transaction and block validation (guardrails) and deferred proving of blocks.

See this comment for context on deferred block proving. The TLDR is that signed (validated), unproven blocks will be sent to the store. The store will then be responsible for proving blocks.

Scope

The following changes will be required to complete this piece of work:

Validator

• Transaction submission, re-execution, and storage.
• Block submission, validation, and signing.

Block Producer

• Updated flow for deferred proving.
• Integration with Validator.

Store

• Updated flow for deferred proving.
• Integration with remote prover.

Network Transaction Builder

• Integration with Validator.

Out of Scope

Miden Client changes will need to be covered in a separate issue.

Miden base changes will be handled in separate issues such as 0xMiden/protocol#2009.

Error Scenarios

The new flows pertaining to the Validator and deferred block proving create the following new error scenarios that we must handle:

Transaction validation failure

• Proven transactions are not able to be re-executed upon submission to the Validator.
• Prevents subsequent Block validation because invalid transactions will be present in them. ❌

Block validation failure

• Blocks are not able to be validated and signed upon submission to the Validator.
• Prevents Block proving. ❌

Block proving failure

• Creates a desync scenario between clients that rely on validated / signed blocks. ❌

Plan

The work will be sliced into the following iterations:

• Define full flow of transactions and blocks involving the Validator and deferred block proving.
• Update miden-base types for block signing and deferred proving.
  • feat: Refactor block types for signatures and deferred proving protocol#2012
  • feat: Add public key to Block Header protocol#2128
• Create Validator component and integrate with RPC for transaction submission.
  • feat: Validator component #1293
  • feat: Integrate RPC with Validator for transaction validation #1457
• Integrate NTB with Validator.
  • Integrate NTB into validator flow #1309
• Add transaction validation logic to Validator.
  • In memory: feat: Add block validation logic against validated transactions (in-memory) #1460
• Add block validation endpoints and logic to Validator.
  • feat: Validate and prove blocks #1381
  • feat: Validator block signatures #1426
  • Validated transactions check in block validation: feat: Add block validation logic against validated transactions (in-memory) #1460
• Add key generation / handling for node bootstrap / genesis.
  • feat: Validator block signatures #1426
• Move block proving from block producer to the store
  • feat: Move block proving to the Store #1579
• Add persistence layer to Validator.
  • feat: Validator database #1614
• Verify that Validator is sufficiently decoupled from Node
  • Validator as separate process works
  • Validator going down does not stop Node, can serve read requests
  • Node resumes normal functioning when Validator is brought back up
• Implement secure key backend.
  • feat: KMS BlockSigner #1677
• Deploy Validator as separate instance to node.
  • chore: Add validator service file #1638
  • With secure key backend
  • Devnet
  • Testnet

[sergerad]

Validation, Signing, and Proving Flow

sequenceDiagram
    participant Client
    participant RPC
    participant Validator
    participant BlockProducer as Block Producer
    participant Store
    participant RemoteProver as Remote Prover
    
    Note over Client, Validator: Transaction Submission
    Client->>RPC: SubmitProvenTransaction()

    Note over RPC, Validator: Transaction Validation

    RPC->>RPC: Validate transaction
    RPC->>Validator: Submit transaction
    Validator->>Validator: Validate transaction
    Validator->>Validator: Store transaction
    Validator->>RPC: Accepted
    RPC->>Client: OK
   

    Note over BlockProducer, RPC: Block Building
    RPC->>BlockProducer: Forward valid transaction
    BlockProducer->>BlockProducer: Build proposed block

    Note over BlockProducer, Validator: Block Validation
    BlockProducer->>Validator: Proposed block
    Validator->>Validator: Check block validity using stored tx info
    Validator->>BlockProducer: Signed block header
    BlockProducer->>BlockProducer: Signed Block
    BlockProducer->>Store: Signed block

    Note over Store, RemoteProver: Block Proving
    Store->>RemoteProver: Signed block
    RemoteProver->>Store: Block proof
    Store->>Store: Proven block

Loading

[sergerad]

@bobbinth I think it might make more sense for the block producer to submit signed blocks for proving, rather than the store doing it.

[bobbinth]

Thank you for putting this together! A few comments:

1. After block producer sends a proposed block to the validator, the validator sends back just a block header (with signature) for this block (not the full signed block). The block producer would then build the signed block independently (from proposed block and block header).
2. The block prover sends back not a proven block, but jus the proof. The store would then combine the proof with the signed block to get the proven block.

Transaction validation failure

• Proven transactions are not able to be re-executed upon submission to the Validator.
• Prevents subsequent Block validation because invalid transactions will be present in them. ❌

Block validation failure

• Blocks are not able to be validated and signed upon submission to the Validator.
• Prevents Block proving. ❌

This should be handled "organically" with the current flow. If the block producer doesn't get a signature from the validator, it just reverts the proposed block (similar to how it would do it now if some error occurs during proven block construction).

Block proving failure

• Creates a desync scenario between clients that rely on validated / signed blocks. ❌

This is a new failure mode. It will basically be equivalent to a "reorg" though, we probably would want to try proving a block a couple of times before deciding that it cannot be proven and discarding all blocks built after the offending block. As a potential improvement on this, we could try to re-insert transactions from discarded blocks into the mempool - though, this would not be easy.

• Update block-producer for block validation and deferred and integrate with Validator. Update Store to perform block proving.

This would probably be a couple of PRs - the first one could do something very basic (i.e., in case of failure, retry, and then stop the chain so that we could fix it manually) and then we could improve on it in subsequent PRs.

@bobbinth I think it might make more sense for the block producer to submit signed blocks for proving, rather than the store doing it.

I'm not sure this will work as this would mean that blocks won't be visible to users until proven. Assuming proving takes 20+ seconds, we won't be able to have 2-second block times.

[sergerad]

I'm not sure this will work as this would mean that blocks won't be visible to users until proven.

Can the block producer not store signed blocks for the purpose of RPC etc to read?

[bobbinth]

Can the block producer not store signed blocks for the purpose of RPC etc to read?

It's possible, but unless I'm missing something, it would be way more complex than having the store orchestrate proof generation:

• The block producer would need to keep an in-memory data structure which basically replicates the store so that it can serve all RPC requests.
• The RPC will need to decide which request to forward to the store and which to the block producer. And we'll need to handle the case where during the request a block may be committed to the store and RPC may not know about it yet.
• Vast majority of requests are likely to be for most recent blocks, and so we'll need to somehow make sure that the block producer does not get overwhelmed with basically serving the lion's share of RPC requests - while at the same time not slowing down batch/block production.