feat(raiko): support pacaya fork

[smtmfft]

• align with pacaya protocol for meta data
• get blocks in batch mode and check native proof in batch mode
• impl batch of batch proof (now contract only support this)
• enable calldata txlist
• support force inclusion
• [NO NEED] integrate preflight API (code included here but not tested, maybe should create a separated PR for it)
• devnet test
• sgx hekla deployment
• ontake compatibility: pacaya changes the public input format of ontake's verifier, must test.

Gaiko

https://github.com/taikoxyz/gaiko

• implement&align with pacaya protocol
• integrated into raiko
  • docker build
  • makefile
  • CI/CD

[keroro520]

Proving Batch request is similar to proving Aggregation request. I am considering a workflow for proving Batch request:

1. Accept BatchRequest{ batch_id } from HTTP
2. Obtain batch and parse into l2_block_numbers
3. Construct a AggregationRequest { block_numbers: l2_block_numbers }
4. Return prove_aggregation(AggregationRequest)

This way can make the code simpler. What do you think?

[keroro520]

In order to add support for proving batch aggregation, I intend to create a new kind of proof request structure:

pub struct BatchMetadata {
    pub batch_id: u64,
    pub l1_inclusion_block_number: u64,
}

pub struct BatchProofRequest {
    // adding new field
    pub batches: Vec<BatchMetadata>,

    // old fields
    pub network: String,
    pub l1_network: String,
    pub graffiti: B256,
    #[serde_as(as = "DisplayFromStr")]
    pub prover: Address,
    pub proof_type: ProofType,
    pub blob_proof_type: BlobProofType,
    #[serde(flatten)]
    pub prover_args: HashMap<String, Value>,
}

BatchProofRequest is similar to ProofRequest, yet it is specifically designed for batch processing. This new structure eliminates the distinction between single-batch and aggregation-batch requests, and make the handling process more simplified.