Thank you @web3nodes for starting this discussion and @Thogard for the thoughtful and thorough response.
I’d appreciate some perspective on the following points. This feels like a pretty big change.
In an ideal world, I’d like to -
1 -Understand the severity of the problem on the network, particularly user impact
Is this causing a significant degradation of service to users?
2 - Understand the risk/reward benefit of the proposed change
The proposal states that the network performance shouldn’t be impacted in a detrimental way. Is that what the testnet proved?
3 - See this tested on a testnet run by the validator set or have the full internal testnet results published for review.
Depending on the above, I could see a few paths forward -
A - Proceed with the original proposal, at least as a temporary solution to the issue
B - Proceed with an alternate proposal, i.e. different block interval and wiggle time durations or increasing validator hardware requirements
C - Do nothing for now, while a more complete and deterministic analysis is conducted
Right now, I don’t feel I have enough information to make an informed decision one way or another.