# TestingTheBlobs DevP2P issue on spam blobs found by Teku, and released as a PoC "evil-teku" here: https://github.com/tbenr/teku/tree/evil-blobs The procedure is as follows: - Instantiate a testnet with an evil-teku that has 100% of the validator keys, plus any other CL as the chain follower - At the time of the proposal, evil-teku sends an extra invalid signed blob sidecar 500ms before sending the signed block and the correct signed blob sidecars - The follower CL receives this extra sidecar and must not be disrupted by it and still follow the chain ## Hive tests Added as a test suite called "eth2-dencun-evil" here https://github.com/ethereum/hive/pull/838/commits/68d33a84826c3597464862937c7ad15f4e403f48 which is comprised by a single test case where the evil-teku is started with 100% of the validator keys and performs the action described before. ### Potential test cases Here's a list of the potential test cases that we should add to extend the coverage of the DevP2P scenarios regarding blobs, and every test case lists its requirements. A bare minimum requirement for all of these is having a tool that is capable of sending signed blob sidecars via DevP2P to all/most clients on demand. #### Extra invalid Blob Sidecars with invalid signature ##### Steps - Send random blob sidecars during the next time slot that contain the following information: - Valid head of the chain as `BlockParentRoot` - Correct `ValidatorIndex` for the slot - Random `BlockRoot` - Random `BlobIndex` (less than `MAX_BLOBS_PER_BLOCK`) - Random `Blob` with correct `KZGCommitment` and `KZGProof` - Incorrect signature ##### Verifications Verifies that the clients immediately discard signed blob sidecars with invalid signatures. ##### Requirements - Be able to send signed blob sidecars via devp2p - Be able to follow the head of the beacon chain - Be able to obtain the validator duties to obtain the correct validator index #### Extra invalid Blob Sidecars with valid signature, valid commitments ##### Steps - Send random blob sidecars during the next time slot that contain the following information: - Valid head of the chain as `BlockParentRoot` - Correct `ValidatorIndex` for the slot - Random `BlockRoot` - Random `BlobIndex` (less than `MAX_BLOBS_PER_BLOCK`) - Random `Blob` with correct `KZGCommitment` and `KZGProof` - Correct signature ##### Verifications Verifies that the clients are not disrupted by receiving extra blobs that do not point to the correct signed beacon block which will be later received from the actual proposer. ##### Requirements - Be able to send signed blob sidecars via devp2p - Be able to follow the head of the beacon chain - Be able to obtain the validator duties to obtain the correct validator index - Have the full validator key set to sign the blob sidecar with the correct proposer key #### Extra valid Blob Sidecars with valid signature, valid commitments, and valid block root ##### Steps - Send random blob sidecars during the next time slot that contain the following information: - Valid head of the chain as `BlockParentRoot` - Correct `ValidatorIndex` for the slot - Correct `BlockRoot` - Random `BlobIndex` (less than `MAX_BLOBS_PER_BLOCK`) - Random `Blob` with correct `KZGCommitment` and `KZGProof` - Correct signature ##### Verifications Verifies that the clients are not disrupted by receiving extra blobs that point to the correct signed beacon block that will be eventually be proposed by the actual proposer. ##### Requirements - Be able to send signed blob sidecars via devp2p - Be able to follow the head of the beacon chain - Be able to obtain the validator duties to obtain the correct validator index - Have the full validator key set to sign the blob sidecar with the correct proposer key - Be able to know at some point the block root of the block that the actual proposer will propose #### Extra valid Blob Sidecars with valid signature, invalid commitments, and valid block root (Evil-teku) ##### Steps - Send random blob sidecars during the next time slot that contain the following information: - Valid head of the chain as `BlockParentRoot` - Correct `ValidatorIndex` for the slot - Correct `BlockRoot` - Random `BlobIndex` (less than `MAX_BLOBS_PER_BLOCK`) (not sure about this one) - Random `Blob` with incorrect `KZGCommitment` and `KZGProof` - Correct signature ##### Verifications Verifies that the clients are not disrupted by receiving extra invalid blobs that point to the correct signed beacon block that the actual proposer will eventually propose. ##### Requirements - Be able to send signed blob sidecars via devp2p - Be able to follow the head of the beacon chain - Be able to obtain the validator duties to obtain the correct validator index - Have the full validator key set to sign the blob sidecar with the correct proposer key - Be able to know at some point the block root of the block that the correct proposer will propose ### About the requirements Hereby I list the each requirement for the aforementioned test cases, the complexity of each, and possible approaches. #### Be able to send signed blob sidecars via DevP2P The tool must be able to connect via DevP2P to the provided consensus clients and gossip over topic `blob_sidecar_{subnet_id}` on demand #### Be able to follow the head of the beacon chain The head of the beacon chain can be easily obtained by querying the Beacon API of any of the connected Consensus clients. #### Be able to obtain the validator duties to obtain the correct validator index The validator duties can be easily obtained by querying the Beacon API of any of the connected Consensus clients. #### Have the full validator key set to sign the blob sidecar with the correct proposer key This can be done in hive by making a copy of the full key set at the start of the testnet and providing it to the tool at startup. Similar thing for a devnet. #### Be able to know at some point the block root of the block that the correct proposer will propose Several options: 1) The external tool could use the Beacon API validator endpoint `/eth/v3/validator/blocks/{slot}` to query the next block to propose. Although this same endpoint is concurrently used by the validator client and not entirely sure if this could cause disruption. Another issue is that we could end up with a different block than the one that the actual proposer is going to propose. 2) Sit in-between the beacon node and the validator client as a proxy and wait for the `/eth/v3/validator/blocks/{slot}` call to snoop the information. Advantage of this method is that we can guarantee that the block root that the proper validator is going to sign is exactly the same we are going to use in the sidecars. ## Blobber tool This tool will be used in hive and configured to test scenarios described here. Link: https://github.com/marioevz/blobber