Replies: 11 comments 7 replies
-
|
Different app chains will want different semantics for their tx dissemination. I think the best possible default would be that every validator registers an ip address that it will receive txs over. Http3 would be a good fit for standardized responses |
Beta Was this translation helpful? Give feedback.
-
|
Huge fan of (A) removing the mempool from CometBFT and (B) providing finer grain control over tx dissemination, preferably dictated by the app. WRT to default dissemination, my fear with public IPs is DoS attacks and flooding the ingestion endpoint. Perhaps if validators had a private network they can transmit txs amongst themselves and public endpoints that allow public facing agents to submit txs, i.e. a firewall or router. |
Beta Was this translation helpful? Give feedback.
-
|
I really like the idea of private networks that exist between validators, and have for a long time. I've been thinking that this private network should follow the established trust graph of the chain, I think validators could easily self-organize such a thing. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a noob here, but shedding some thoughts in case they're helpful. Do nodes not already have DoS protections built-in? My understanding was that the sentinel node architecture made it much more difficult to DoS the validator node itself. Separately, it seems like in most cases a node could have an in-memory cache of seen (account, nonce) duples, bypassing CheckTx with an extremely efficient cache check. For applications where expenditure scales with number of unique-nonce txs, this should make DoS cost-per-tx-checking-time very high. It seems like the role we're worried about losing from the mempool here is load balancing, which seems like it could be handled internally by the validator. |
Beta Was this translation helpful? Give feedback.
-
No, the idea is that if there exists a public ingress endpoint that validators expose, then that endpoint could be flooded with bogus txs, preventing honest txs for entering in a timely fashion. We could implement an ingestion service that sits atop the ingress endpoint, filtering out bogus txs, but that's more infra for validators to run, which is a downside.
What does this have to do with tx dissemination? The core idea here is how and what txs are gossiped and in what order. |
Beta Was this translation helpful? Give feedback.
-
Ah I figured that the main drawback of the new transaction dissemination method is that it leads the validator to receive a greater number of tx requests. Thus my thoughts on how to efficiently resolve that. |
Beta Was this translation helpful? Give feedback.
-
|
The core changes needs to remove the mempool is that CometBFT needs to provide an api the enables running check tx against the transaction and mechanism to call out to an external process when reeping txs for the block |
Beta Was this translation helpful? Give feedback.
-
|
new rpc design
Current state of block parts
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks everyone, |
Beta Was this translation helpful? Give feedback.
-
|
It should be understood that building a peer to peer system which is resistant to denial of service attacks while providing high quality UX for wallets, relayers, MEV searchers etc will have to be narrowly scoped. Ie. You might be able to build a reasonable system for Celestia data blobs or limit orders but there are no examples of a widely used general purpose p2p transaction propagation layer in any blockchain system. men-boost relayer build 99% of Ethereum blocks. Solana is 75% Gulfstream/25% Jito. Bitcoin users fiber |
Beta Was this translation helpful? Give feedback.
-
|
Espresso systems employs a CDN for fast point to point communication between validators but with a fallback mechanism that uses p2p gossip. Perhaps Comet could be inspired by a similar design |
Beta Was this translation helpful? Give feedback.
-
|
Adding this here #1565 |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, feedback is welcome on this PR #1585 about an ADR for a |
Beta Was this translation helpful? Give feedback.
-
|
Implementation of ADR 111 |
Beta Was this translation helpful? Give feedback.
-
Organization of a working group to explore mempool improvementsLogisticsWhere: CometBFT community call, calendar instructions available upon joining this Google group NotesWill be captured here. AgendaUnder construction Please don't hesitate to comment if any specific items should be added to the agenda. |
Beta Was this translation helpful? Give feedback.
-
|
The current mempool implementation displays a thundering herd problem when a CometBFT network is under sustained load due to contention on the ABCI mutex. I'm not really sure this should do into the baseline v1 mempool behavior so I'm instead documenting this here. Symptoms included increased round failures and empty blocks while the network is under heavy load. Here is a proposed mechanism to make some naive mitigations again this are. add a paramater for stopping max mempool size here What does the patch do? If there 1000 tx is the mempool, there are around be 1000 abci mutexs locks for abci recheck. |
Beta Was this translation helpful? Give feedback.
-
|
So, your suggestion is to move this check up in the stack, namely, when we receive the transaction at first. Actually, the check must preserved there in case we receive a transaction via RPC. This is a good idea. We should save some contention (acquiring locks) when we know that we can't accept a transaction. The question is that |
Beta Was this translation helpful? Give feedback.
-
|
"Instead we add a new msg type to the mempool reactor where the mempools sends messages to its's peers that says stop sending me txs for x blocks. The reactor should track what peers it sent this message to. If the peers keeps sending txs after recieving this message before the target height has been reached then drop the peer and blacklist them. So I think instead we setup a similar structure to the txSender structure where we track the height of the peers that. have sent a message that they are not receiving txs and wait the peer state has exceeded the target height before sending more messages. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The CometBFT mempool has a number of significant flaws.
It is both practically and conceptually broken.
The mempool layer is extremely inefficient. Each tx floods across the network being rebroadcast many times.
The mempool provides no mechanism to provide back pressure, prioritize dissemination or inform users about what fees are needed.
This essentially forms a dos vector by creating thundering herd problems that can slow block production.
It makes no sense to flood txs into the network when txs just need to be sent to the next proposer.
Beta Was this translation helpful? Give feedback.
All reactions