To summarize the first half of Zaki’s argument:
- The Comet network layer does not innately distinguish between validators and any other node
- The transaction propagation policy of every node is discretionary and private
- The gestalt behavior of such a system is highly opaque and vulnerable to attack
We are 100% aligned on these points. It’s a miracle this system has worked up until now. Everyone agrees the whole transaction ingress system needs to be replaced. The Skip Sentinel was such a bypass mechanism, and the in-protocol oracle system we are working on likewise provides a side-car to bypass Comet transaction intake. We have, and will continue to build systems that provide more robust ways to ingest transactions.
The part of Zaki’s argument I disagree with is that the networking layer + the EIP-1559 fee controller will have a reinforcing interaction that will further degrade the system. This argument hinges on a very nuanced premise that the timescale on which the fee controller reacts to information is of a different order than what the gossip system exposes to the validator. Let’s break down the possible scenarios to help with our intuition.
So under normal operation, the system should work as follows:
- mempool signals decreasing load, controller detects decreasing load → fees decrease
- mempool signals increasing load, controller detects increasing load → fees increase
It’s valid to say that in above system the response rate will lead to suboptimal fee pricing, but this is really the price one pays for in-protocol automation and a public fee oracle. In collaboration with the Osmosis team, we actually plan to augment EIP-1559 to reduce this economic leakage via an adaptive learning rate for fee repricing. You can read more about that here.
Ok so now the two scenarios Zaki is concerned about:
- mempool signals decreasing load, controller detects increase load → fees increase
- mempool signals increasing load, controller detects decreasing load → fees decrease
The first scenario is only possible if during times of low network activity the validator artificially stuffs blocks. In this case validators must pay to manipulate the fee, even if Comet assigns them to propose a series of consecutive blocks. If such an attack is happening, the behavior is also easily detectable because the gossip network is otherwise quiet.
The second scenario is the really the most concerning, and this is what Jacob has been raising a flag about recently. That the gossip layer can be overwhelmed, either by large messages or many small messages. Poor propagation may induce users or nodes to retry submission and further amplify network traffic. Now the only way the controller would fail to detect increased transaction load would be the chain being completely clogged and simply unable to complete a consensus round, in which case validators will have to coordinate to wall their nodes off from new transactions, manually clear their mempool, peer privately, and reload transactions from another source to recover. Alternatively, validators end up with a saturated mempool, but only a small portion of transactions can be used to construct a block. The proposer publishes an unfilled block, it’s accepted by the network, but fees decease because the in-protocol signal is that transaction demand is low. Recovery from this state would look similar to Comet failing to finalize rounds.
Now the concern is that the controller is pushing the fee down as all this is going on. And here I’d like to note that Skip’s version of EIP-1559 will have a global min fee that can be set by governance, so while this is a real failure mode, it’s no worse than what we have today and should be more robust unless the network is actively pushed into this state. For this reason I’ve tried to be careful to state that the proposed work is not a complete solution to the transaction supply chain problems faced by Comet and the Hub today, it is however a small step that chips away at one specific problem: repricing the cost of transaction inclusion given at least a directionally accurate indication of load.