# PeerDAS Testing in EEST Note this ignores `engine-osaka` test cases. We should try get this up to date before the fork. ## EEST Test Updates `tests/cancun/eip4844.../` already contains a bunch of blob tx tests. These need be updated to use actual kzg proofs? In addition to these tests, we should create a `tests/osaka/eip7594.../` path that can contain negative blob tx tests, and any more interesting positive blob txs that are not covered in `tests/cancun/eip4844.../`. Some negative examples: 1) Basic RLP corruption txs. 2) Omit the blob bytes array for a blob tx. Should get an rpc error. 3) Incorrect blob body length, i.e doesn't equal 4096 x 32 bytes. `INVALID_BLOB_LENGTH` like tx error (I think we have this in EEST). 4) Flip one byte in the KZG commitment, client should derive the commitment from the blob and compare, then error. `INVALID_KZG_COMMITMENT` like tx error. 5) Flip one byte in the KZG proof, client should derive the commitment, reverify against proof and reject. `INVALID_KZG_PROOF` like tx error. 6) Mutation/combination of 3 - 5 cases. Order of rejection should be from 3 to 5. I.e if we mess with the length, commitment and proof, the client should reject for an invalid length. 7) 2 txs duplicate blob versioned hash. Send one accepted, second is rejected, `INVALID_BLOB_HASH` like tx error etc. Get blobs should return the 1st tx. ## Execute Updates While I think through the process for the execute changes, we would now do the following? - initial`engine_getBlobsV1` -> expect null: - i.e with empty array, get back `[]`. - quick way to check clients return correctly. - `eth_sendRawTransaction` -> wait appropriate time. - if test contains a negative test tx, then validate exception. - `engine_getBlobsV1` -> validate response. - We should maybe consider always or sometimes calling with a bad hash to makes sure we get that back as null, alongside the valid hashes in the correct order. - `engine_getBlobsV1([goodHash, badHash, goodHash])` -> `[ BlobProofV1, null, BlobProofV1 ]`. - if test contains a positive test tx: `getPayloadV4` -> `newPayloadV4` -> VALID. Afaik all of the above EEST test additions/updates can be run in execute. Ideally we run this in hive CI for devnet 1, using execute hive mode. We should improve the logging here to be more granular. ## New Fixture Oppurtunity (consume)? Should we create a new fixture for PeerDAS that does the same as execute. It would contain a list of tx/s. Some with a single blob tx or multiple, and some with a mix of blob/non-blob txs. The fixture would also contain the appropriate `getBlobsV1` input data, and then the expected valid response/s (clients handle mempool differently). It would obviously require clients to implement a runner to consume them. But we could additionally run this in consume as an alternative or addition to execute. We could use these fixtures within a consume like simulator. As we precompute all valid possible responses from `getBlobsV1`, the overhead might not be too bad. ## Chain Reorgs Check that if we send blob txs, then reorg, the blob txs are still there. Maybe good to add to consume like scenario. ## Blob Sidecar Retention in ELs We should also test for blob retention in the tx pools. So send some blob txs. Then spam a bunch of dummy blocks. Call getBlobs at the block before rentention ends and after it ends. We can set the retention period in clients with: `--blob.sidecar.retention=4` etc. - Check when we set this to 1, keep the blob through exactly one new block, and chcek prune on the second. - Also when set to 0, i.e prune immediately on block import.