Daniel
Daniel
> Don't include VEs when writing to the WAL (what are the implications?) My preferred option. I think that we will have implications, since we check, in a ton of...
> Does the p2p.max_packet_msg_payload_size parameter No, messages are split into packets. A message can take multiple packets. So this is not a problem. Recall that we ship application snapshots, blocks,...
> So if it's possible to change the logic and not write the vote extensions to the WAL and no major implication would occur I am not 100% sure about...
A good solution is far from simple. The main point is that vote messages were assumed to be fixed size, but now we add the ability of making them a...
It could only be hard-coded, for now, based on the maximum WAL message size.
See https://github.com/cometbft/cometbft/issues/2547
> Something I do see clearly here is that I don't see any practical reason not to merge timeout_prevote and timeout_precommit into one single value. As the events these timeouts...
So, jumping here later. Timeouts should be based on the size of the messages they refer to. `timeout_propose` is strictly dependent on the typical block size, it should be computed...
But block times can still be arbitrarily long, due to failures, asynchrony, etc. So we probably still need to have the requirement of both time interval ("real" time) and blocks...
> is it possible to reject the block proposal if the timestamp of the proposed block is older than the last block committed ? Yes, there is a [safety check...