refactor: add batch multi proofing

[g4titanx]

todo:

• enable batch transactions in escrow and node
• tests, tests, tests, tests with batch proof payload

[g4titanx]

@ozwaldorf you could set eyes on this as well

[ozwaldorf]

Whats the usecase?

[g4titanx]

Whats the usecase?

for receipts in the same block, they basically share most of the receipts-trie path, so we bundle those shared nodes once and prove all the (path, receipt) pairs together. that cuts calldata/gas in comparison to separate proofs. and if you only have one receipt, you just pass 1 element arrays and it behaves exactly like a single proof flow

[ozwaldorf]

But to a user, what does this feature enable?

At first I didn't think there's much value here. Though after thinking on it, it might be beneficial to be able to process multiple transfers to fill a single escrow transfer (ie, a node uses 3 different transfers included in a batch through buildernet to transfer a total sum expected by the escrow)

Is this what's been implemented or is this multiple proofs for multiple escrow bonds?

[g4titanx]

But to a user, what does this feature enable?

At first I didn't think there's much value here. Though after thinking on it, it might be beneficial to be able to process multiple transfers to fill a single escrow transfer (ie, a node uses 3 different transfers included in a batch through buildernet to transfer a total sum expected by the escrow)

Is this what's been implemented or is this multiple proofs for multiple escrow bonds?

To a user, this means you can submit one bundled proof that contains several receipts from the same block, and the escrow will verify them all against that block header. if any of those receipts contains a Transfer log for the escrow’s configured token, recipient, and exact expectedAmount, the bonded executor can collect the payout.

what it doesnt do is: sum multiple transfers to reach the expected amount and it still looks for a single Transfer event that matches expectedAmount. also, it doesn’t support multiple concurrent bonds and the contract still tracks one bondedExecutor and one proof driven collect at a time.

this is mainly a gas/efficiency win for proving receipts (or reusing the same shared proof across multiple escrows if needed), it's nothing in any way a way to combine partial payments. but we could make it that

fill the escrow with multiple transfers that sum to the expected amount

And yeah we can actually implement this. If we are to do this, we can keep the shared block header and proof nodes, but allow N receipts/paths/logIndices and track which logs we validated and then we require all receipts be in the same block (or expand to multiple blocks if we add per‑block header/proof arrays). instead of stopping at the first matching Transfer, we can iterate all provided receipts/logs, sum amounts where tokenContract and to == expectedRecipient, and then require the total to reach expectedAmount and yes collection still happens once per bond, the bonded executor can present the batch and, if the sum matches, receive bond + reward + payment.