I want to know what is the logic for generating block-related account sets？

[RuiQi857]

Our chain is an Ethereum layer 2. The consensus protocol and some configuration levels are different from Ethereum, but the data structure and RPC interface are consistent with Ethereum. However, we encountered a strange problem in the process of generating proof: through code, we learned that zeth will query the proof of the block-related address. In a specific block, there is a transaction that calls the ERC1967Proxy contract, and then it appears in the account associated with the block. We understand that it should not appear. The address on our chain represents the block producing node. It does not have an Account on the chain, so getProof will always trigger Account Not Found errors, which has troubled us for a long time. If it is convenient, can you help us answer it?

Thank you very much! ! ! !

In addition, if we skip this "special" account, will it affect the subsequent generation and verification of MPTNode?

[linear]

ZETH-29 I want to know what is the logic for generating block-related account sets？

[nishuzumi]

I guess that if the status of that address has not changed, skipping should not be too much of a problem. Is this caused by the use of clique?

[RuiQi857]

Okay, for similar precompiled contract addresses like 0x..01, zeth will also call getProof rpc, but this batch of addresses will also trigger Account not found exceptions on our chain (code: -32000, message: Account not found, data: None), is it also possible to skip by using address whitelisting?

[nishuzumi]

I recommend that you provide a 1wei value for each of these addresses in the Genesis file when creating the chain, which should bypass this problem

[RuiQi857]

Our consensus is PBFT, and similar to clique, it will also take turns to block, so is this the reason?

[nishuzumi]

As long as the address is present in the execution, it will always be getProof

[RuiQi857]

Ask more, zeth will also check the Proof for the address used in the failed transaction (such as the contract address where the deployment failed), but this address does not exist on the chain. Account Not Found will also appear in the same way. Is this right? Can it be optimized?