dbft: detach dBFT extensible payloads verifier from dBFT engine

[qianhh]

Close #299 and #244.

The original extensible payloads verifier function has been simply separated. I'm not sure if the current position is reasonable. Everyone is welcome to offer suggestions.

[txhsl]

I'm OK with these modifications, but I think @AnnaShaleva may expect more about the extensible payload, since we haven't changed the basic logic.

[AnnaShaleva]

The original extensible payloads verifier function has been simply separated.

It doesn't solve neither #244 nor #299. Both these issues are not just about moving extensible-related code to a separate structure/file.

The purpose of #299 is to enable extensible payloads verification not only for CNs, but also for non-mining nodes. That's why it is suggested to abstract extensible verification service, but the key issue is that his service should be properly integrated with dbft network protocol to be active even on seed nodes (right now extensible sender is not verified by non-mining nodes):

go-ethereum/eth/protocols/dbft/pool.go

Line 94 in 3ac8c58

err = p.chain.IsAddressAllowed(m.Sender)

So probably it would be a good idea to make this service managed by blockchain itself, i.e. to make it a part of Eth blockchain API (right now it's bound to the activity of dBFT event loop).

The purpose of #244 is to implement per-block cache for extensible whitelist members and update this cache only when it's necessary (right now - only for those blocks when committee may be changed). This cache should work exactly the same way as in NeoGo, refer to the original issue for link and for initial implementation. Also, in NeoGo this cache is bound to the blockchain's block processing routine, since it's quite native to update the whitelist exactly after the block is processed by the chain. The same logic should be suitable for Eth.

[qianhh]

It doesn't solve neither #244 nor #299. Both these issues are not just about moving extensible-related code to a separate structure/file.

The purpose of #299 is to enable extensible payloads verification not only for CNs, but also for non-mining nodes. That's why it is suggested to abstract extensible verification service, but the key issue is that his service should be properly integrated with dbft network protocol to be active even on seed nodes (right now extensible sender is not verified by non-mining nodes):

go-ethereum/eth/protocols/dbft/pool.go

Line 94 in 3ac8c58

err = p.chain.IsAddressAllowed(m.Sender)

So probably it would be a good idea to make this service managed by blockchain itself, i.e. to make it a part of Eth blockchain API (right now it's bound to the activity of dBFT event loop).
The purpose of #244 is to implement per-block cache for extensible whitelist members and update this cache only when it's necessary (right now - only for those blocks when committee may be changed). This cache should work exactly the same way as in NeoGo, refer to the original issue for link and for initial implementation. Also, in NeoGo this cache is bound to the blockchain's block processing routine, since it's quite native to update the whitelist exactly after the block is processed by the chain. The same logic should be suitable for Eth.

Previously, I misunderstood the meaning. So, I'll first solve the #299 issue and incorporate it into the Eth blockchain API.

[AnnaShaleva]

incorporate it into the Eth blockchain API.

Note that it’s just an assumption, we need to check may be there’s a better place for this cache.

[qianhh]

I have completed the integration work. Now let's see if there are any areas that can be improved? @AnnaShaleva