I'm not sure these worth saving as proper contracts (with ID assignment/ABI generation and all that stuff), that adds some overhead and nothing deletes them. Maybe we can store them separately? Or in some special contract? Or in NEO contract that knows about all of this anyway?

Another concern that I have is light nodes operating with headers. They should be able to verify blocks, so I don't think we can strip verification scripts from all of them.

Maybe we can do something like that:

• store these scripts in the NEO contract
• block 0 can go without verification script attached because even light nodes must generate it from configuration file with whole committee specified
• when there is a change in validators list, attach the script to the block that uses it first, light nodes pick the script from there and store it
• don't attach it to subsequent blocks signed by the same set of validators
• VerifyWitnesses can have some type-specific logic that wouldn't use contracts storage to get scripts for blocks and consensus payloads, using NEO contract instead, and vice versa for transactions --- using regular contracts and not using NEO contract

Although this creates some duplication, we'll have regular and "supplementary" verification contracts separation, they'll use a little less space (by the virtue of not having a real ABI) and they could be easily updated on validators change, deleting old scripts and adding new ones.

For some reason #1332 comes to mind also here.

In this way, the light node cannot verify the block headers. If we want to reduce the size of the block, we should study the aggregate signature scheme.

In this way, the light node cannot verify the block headers.

If I'm not missing something, the light node still has to walk through the whole chain of headers and if the first block using a new set of validators is to have a full verification script attached, I think it can be removed from the subsequent blocks using the same set of validators.

we should study the aggregate signature scheme.

We've done some experiments with BLS (quite a long time ago, based on 2.x code, there is still a branch hanging in our tree: nspcc-dev/neo-go@c691d37). It can be done and it works, but the performance characteristics of it are so weak that it's probably better to waste some space for the scheme we currently have. Probably @fyrchik can add a little more on that.

In this way, the light node cannot verify the block headers. If we want to reduce the size of the block, we should study the aggregate signature scheme.

Then now it possible to break a light node, because the cn can deploy and relay without verification script.

I will split the optimization of Consensus messages because it doesn't affect to light nodes.

We've done some experiments with BLS

And here is the link: #1085 (comment).