Tx_rollup: Various scenario to tests
This issue summarizes various scenarios to tests for transactional rollups (only for the protocol side):
Regression
Regressions tests to ensure that if the behavior is changed, it is catched.
Batch
-
check the minimum size for a batch -
check a random batch submission -
check the maximum default size for a batch -
check the minimum allowed size for a batch with a new protocol constant parameter -
check client command batch submission with an invalid rollup address
Inbox
-
check the maximum default inbox size -
check the maximum default inbox size with a new protocol constant parameter (? - see comments)
Commitment finalization
-
Test finalisation with no inbox -
Test finalization with an inbox without commitment -
Test finalization with a pending commitment but the refutation period time is too short -
Test a valid finalization on a pending commitment
RPCs
-
check the get_state
RPC with the initial state -
check the get_inbox
RPC with a non-empty inbox -
check the get_inbox
RPC with a level in the future -
check the get_inbox
RPC when the inbox was removed -
check the get_commitment
RPC with a level containing an RPC -
check the get_commitment
RPC with a level in the future -
check the get_commitment
RPC with a commitment removed
Scenarios
Batches
-
Test an origination with a single batch submission -
Test posting messages in several inboxes -
Test that a batch of message does not depend on the inbox size
Commitments
-
Test a valid commitment for a batch -
Test two valid commitments in a row -
Test committing twice on the same batch -
Test a commitment without predecessor while it should
To be validated
-
case where an unparsable batch is rejected (that is, is a no-op) -
case where a batch with an ill-signed transaction is rejected (that is, is a no-op) -
case where a batch with an operation having a bad counter is rejected (that is, is a no-op) -
case where: - append_message that triggers
Inbox_count_would_exceed_limit
- and the message that doesn't fit in the inbox is a deposit from L1
- what's the status of the L1 operation?
- append_message that triggers
-
what happens if we ask to withdraw and provide a quite big withdraw_index ? (see !4523 (comment 868018313) for more details) -
Test where there is more than one withdraw for a claimer in an inbox: -
in different batches -
in the same batch -
one of them is a failing deposit -
both are failing deposits
-
-
A test of three deposits of max_int, from the same source/contract (David working on these) -
to the same destination (fresh or not) -
to two different destinations (fresh or not) -
to three different destinations (fresh or not)
-
-
check a rejection where the computation yields a result similar to what's on-chain (? - see comments) -
test rejections with various errors in the apply function (parsing, invalid counter, ...) -
rejection tests where some commitments are orphan (same manager as rejected commitment or not) + try to withdraw funds -
max number of withdraws per batch: test the following case: (<- WIP) - the L1 node + an honest rollup node use a limit
L
of withdraws per batch - a malicious rollup node sends a batch that generates more than
L
withdraws and sends a commitment that certifies that this batch is correct - a rejection operation (sent for instance by the honest rollup node) should allow to reject the batch when evaluated on L1, because evaluating the batch should fail (with
Maximum_withdraws_per_message_exceeded
).
- the L1 node + an honest rollup node use a limit
-
add a test where the proof's size is above the limit -
bonds tests: https://hackmd.io/dozd_9L_Qz63C2elXurmyw?both -
state tests: reject a commitment whose predecessor has been removed from storage -
add tests where positions are negative ?
Edited by David Turner