Nimbus t8n accept malicious withdrawals

[winsvega]

Ideally this should be parsed from block rlp. but in t8n env.json defines the block input.
the test is about to see what happenes if withdrawals comes in invalid format. full test is run on hive. (where a block imported as rlp on test blockchain)

however nimbus t8n processed this input:
address is supposed to be 20 bytes.

    "withdrawals" : [
        {
            "index" : "0x0",
            "validatorIndex" : "0x0",
            "amount" : "0x2710",
            "address" : "0x00c94f5374fce5edbc8e2a8697c15331677e6ebf0b"
        }
    ],

[winsvega]

Hm still calculate the state root on invalid input. The confusion is that this withdrawal record comes to t8n as json. In mainnet it is parsed from rlp. What I want to test is that malicious encoding of withdrawals in block rlp throws an exception

http:https://retesteth.ethdevops.io/results/log//2023-04-25-1682399235-nimbus.txt

[winsvega]

the t8n should report an error on malicious input

info: (InvalidBlocks/bc4895-withdrawals/withdrawalsAddressBounds_Shanghai, fork: Shanghai, block: 2)
info: (InvalidBlocks/bc4895-withdrawals/withdrawalsAmountBounds_Shanghai, fork: Shanghai, block: 2)
info: (InvalidBlocks/bc4895-withdrawals/withdrawalsIndexBounds_Shanghai, fork: Shanghai, block: 2)
info: (InvalidBlocks/bc4895-withdrawals/withdrawalsValidatorIndexBounds_Shanghai, fork: Shanghai, block: 2)

like this input

"withdrawals" : [
        {
            "index" : "0x0",
            "validatorIndex" : "0x0",
            "amount" : "0x2710",
            "address" : "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421112233445566"
        }
    ],

those tests are verifing what are the allowed limits for index, validatorIndex, amount, address fields.
is it u32, u64, u256 for value fields.
and also address should only be valid fixed hash 20 size.
the best way to check is to enocode withdrawals object provided to t8n as json into RLP and decode it using withdrawals from RLP deserialization. using the core logic.

[jangko]

This already fixed, I cannot reproduce it