Thoughts on the Mempool Issue and Upgrading

[danda]

@aszepieniec thx for the writeup and proposal. I’m glad to see this is becoming a top priority.

@aszepieniec

Presently, there is no code for keeping track of fees bound to the node’s own wallet for mempool transactions. Adding this mechanism would go a long way towards addressing the problem. And while I support adding that mechanism, I think it is treating a symptom and not the cause. Keeping track of collected fees does not present a compelling answer to the question why it is worth collecting those fees in the first place – particularly, given the other potential applications of the requisite proving power.

From a more profound point of view, the issue stems from resource contention. It requires proving power to Upgrade transactions and it requires proving power to produce block proposals. The same proving power cannot be applied towards both tasks simultaneously, and therefore it has to choose. Presently it is more profitable to produce block proposals, so that’s what provers end up doing.

I believe the dynamics/incentives of the system are such that only a very small number (perhaps even 1) composer will typically be dominating block composition. Moreso if they dynamically adjust the guesser fraction to be close to avg over the last N blocks.

I don’t see that as a problem at all. Because there is a market and even the composer with fastest hardware must keep the guesser fraction high or risk losing the block reward to another composer.

What it means though is that other network participants with reasonably beefy hardware should realize it is more profitable to upgrade transactions.

But critically, this is only true if they are not performing wasteful work duplicating the work of other nodes. So, as I’ve been saying since day 1, it is important for the network’s health that a mechanism is found to help proof-upgraders to coordinate so that we get close to a situation where only one upgrader works on each transaction that needs to be upgraded.

It is has been suggested previously that we can simply leave that to the market and treat it as an out-of-band issue for neptune-core. I think that may be true in the long run, but who knows how long that might be. As such, I think it is in the best interest of the project to create a “best effort” solution now that may not be theoretically perfect but is “good enough” to make it profitable for nodes to dedicate resources to upgrading.

I have suggested such a simple mechanism for this a couple times in the past, before mainnet even. The latest is here. To date, I haven’t received any meaningful feedback about the suggestion. Note that this does not require any change to the mining logic, and no hard or soft fork.

@aszepieniec

One does not expect transactions to suddenly disappear from it for no good reason. However, putting the blame for this issue on the mempool risks misdiagnosing the root cause.

right. The fundamental issue I still see is that neptune-core is wasting available resources by duplicating upgrade work across nodes, and that is both an unprofitable strategy and a very inefficient one for getting transactions upgraded and confirmed. For this reason, I suggested to either add a coordination mechanism before mainnet launch (my preference) or add “send-rate” training wheels; the latter course was chosen and by the way are coming off pretty soon.

@aszepieniec

In principle higher fees could solve this issue.

We need to get things working at a decent level of efficiency before considering higher fees to be a solution. ie, there’s low hanging fruit here.

@aszepieniec

I propose the following perspective, and matching architectural and configuration changes.

• Block production consists of three steps, not two. The three steps are upgrading, composing, and guessing. Going forward, we should characterize upgrading as the first step in a three-step mining process.

Ok cool. It’s great to have a writeup of the problem but even better to have concrete proposal(s) to fix it.

The first thing I notice about this proposal is that it changes the mining dynamics and would thus appear to require a fork. I don’t see that as a big problem at this early stage, but I would like to have a discussion of the tradeoffs and merits of this proposal vs the much simpler scheme I proposed before that does not require any changes to mining.

The biggest question of course is: what problem(s) does this solve that the earlier proposal does not?

@aszepieniec

Separate mine loop into compose loop and guess loop; and add upgrade loop. Only one loop can be active at any one point. (Want to run more than one? Do it on multiple machines.)

I 200% agree the mining loop should be refactored. I think I would need more convincing that a node should only be allowed to do one of the 3. If it proves unpopular, miners will simply run a fork of neptune-core (or custom software) that behaves how miners want it. So I think that limitation only makes sense if it clearly aligns with incentives and feedback, and I don’t see that case has been made.

@aszepieniec

Just as Composers compete against each other with more profitable block proposals, so too do Upgraders compete against each other with more profitable aggregated transactions. The objective of the Upgrader is to ensure that at any point in time, the most profitable (for the next stages of block production) synced transaction in circulation is one he collects fees from.

I might’ve missed it, but I don’t remember seeing anything in this proposal about upgraders coordinating to avoid duplicating eachother’s work. If we have 100 tx in the mempool that need upgrading, and we have 50 proof upgrading nodes available, it’s both wasteful and unprofitable if any 2 or more of those nodes start upgrading the same transaction. So they are not competing with eachother unless and until there are more proof upgraders available than transactions in the mempool. And until then, and perhaps after, coordination is the most profitable strategy for them individually and collectively.

@aszepieniec

Upgrade any transactions that makes economical sense (this includes performing Mergers), and broadcasts the result. There is a discussion to be had about how to select Upgrade jobs. Optimizing for profit is a poor strategy because competing Upgraders might do the same. Probably a good idea to strike a balance between profitability and randomness.

I’m going to beat the same drum again. Selecting which upgrade job to work on is the core of the problem. And it does’t make any sense to select a Tx to upgrade that another node is already upgrading. and the only way to know that is to coordindate about it. I think that without solving that, we haven’t really solved anything.

@aszepieniec

How do these changes address the issue(s)?

I think this proposal is a step in the right direction, but needs to include coordination (somehow) before it can be said to fully address the issues(s).

@aszepieniec

Ultimately the throughput capacity is limited by the block size and the number of Upgraders on the network

That statement is incomplete. Consider the two extreme cases:

1. all proof upgraders upgrade each tx
2. only one proof upgrader ever performs work for a given tx.

The throughput capacity of the network will be very different for these two scenarios.

(2) is clearly more optimal, and any design should attempt to achieve it, or get near it, at least while Tx outnumber upgraders.