Recently, I read the post 25-second irreversible confirmations for instant payments by @sdlerner. He mentioned:
Bitcoin forwards a block by packing the block header with all the transactions contained in the block. This strategy, while being the most easy to analyze, is known to perform badly, both regarding block propagation latency and bandwidth usage. Since the transactions on a block are generally already known to the network, there is no benefit in transmitting them again.
The transactions included in the block could be replaced by a list of hashes. The receiving node could reconstruct the full block having the hashes of the known transactions, and reclaiming the unknown ones. The alternative is sending only the block header:
…Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time.Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time. This allows the header to spread over the network in less than a second. Nodes can then start mining an empty block on top of the header even if the transactions are still missing, during a fixed interval. After that interval, they resume mining in whatever block they were mining before.
(emphasis is mine) I’m not an expert on mining and network efficiency, but I could propose an improvement to this alternative, in Ethereum (where there are accounts). Instead of propagate only the block header, the miner could send an additional account predicate, P(acc), with the following property:
– P(acc) is true for every account involved in a transaction of the received block
An “account involved in a transaction” is the receiver account or the sender account. We must consider the receiver account because in Ethereum a receiver account could be a contract, and its appearance in a transaction implies that its state will be changed by the block execution. In a “only transfer” transaction, only the sending account can be considered “involved”. The key point: the receiver node (the node that receives the new block header and account predicate) CANNOT be sure about the state of the involved accounts. So, it cannot use them in new block.
But every account that not satisfies the predicate can be used in any transaction, to be included in a new block.
The improvement proposal is: instead of “start mining an empty block”, the receiver node can start mining on a new block with any pending transactions whose account DOES NOT satisfies the received predicate. Those account does not have their states affected by the still unknown transactions included in the block that has the just received block header. Then, they can be used in any new block. They states are the same after the incoming block execution than after its processing.
How to send such predicates? One option is to have a Bloom filter. Again, I’m not an expert on Bloom filters. but I can imagine a list of bits. As a concrete example, I could use 16 bits. If an account, included in a transaction of the new block, has a public key that ends with hexadecimal 0, the first bit is on. If an involved account public key ends with hexadecimal A, the eleventh bit is on. In this way, they can be false positives applying the filter, but every involved account satifies the predicate, and the receiver node never includes an invalid transaction in the next block to mine.
The length of this bit field could be optimized according to the mean number of transactions per block. If the number of transactions per block is around 16, then the length of bits could be 32, to have a great chance of having pending transactions in the receiver node that are candidated to be included in the new block to mine.
It can be this proposal adapted to Bitcoin and related mining process? I’m think it cannot. A bloom filter of transactions can be send, but then, the receiving block is not sure about what pending transactions are candidates to be mined, in an easy way. I think that a list of transactions hashes could be more effective than a Bloom filter.
I’m not sure if this proposal has any concrete benefits, but I feel it is an interesting path to explore.