proposal: Unified Scheduler

[ryoqun]

Problem

conceived as outlined at #23548, my idea improves replay time 2x as evidenced at #27666, but it still lacks any design doc for others to review/evaluate it.

(my draft pr stack is too deep; hopefully, i think i can pop them one-by-one, starting from this one.)

Summary of Changes

context #23548

[apfitzge]

I can definitely see that this may be the case for replay, but is it for banking as well? Still learning all the different parts of banking, but I thought one of the main benefits of batching for banking is that we record to PoH less often which is more efficient.

@carllin, any thoughts here?

[ryoqun]

I thought one of the main benefits of batching for banking is that we record to PoH less often which is more efficient.

that concern is correct, however...:

• poh recorder's lock contention can be reduced significantly (even can be eliminated maybe) once there is only a single unified thread recording to it. (ie. the scheduler thread)
• also, scheduler can just buffer txes to record to poh until lock conflicting tx is encountered.

that said, I thought main benefits of batching would be AccountsDb locking overhead reduction.

[apfitzge]

this seems more fair from the user perspective, but it may not yield the best fee-collection results for validators. A greedy validator will not adhere to this and we have no way to enforce it.

Just making a note, not saying it shouldn't be your goal; it may be the case that you can make some optimizations this way which does result in higher throughput and fee-collection!

[ryoqun]

this seems more fair from the user perspective, but it may not yield the best fee-collection results for validators. A greedy validator will not adhere to this and we have no way to enforce it.

yep. greedy validator will just seek to mev revenue, rather than fee-collection maximization, considering relatively cheap tx fees. cc: @buffalu

Just making a note, not saying it shouldn't be your goal; it may be the case that you can make some optimizations this way which does result in higher throughput and fee-collection!

yep, i'll write that reasoning down later for any scrutinization.

[buffalu]

mev tries to maximize fees collected. have a feeling fully respecting priority payment won’t maximize fees

[apfitzge]

I've talked with @taozhu-chicago about this, likely we'll want to move the QoS checks for account limits up into the scheduler:

1. scheduler will already be looking at accounts locked by the tx, so easy to fit in per-account so we could track account costs as we schedule
2. this could allow us to drop lower-priority tx early in the scheduling stage so we don't even add them into the scheduling structures

good goal to have, but if we inlcude these changes we probably won't have to deal with 1m pending txs on the same address

[apfitzge]

ah, but this would conflict with your goal of "no estimator/prediction" 😅

[apfitzge]

what does this mean?

[ryoqun]

this: #23837

note that this proposal is way more futuristic than even this unified scheduler thing.

[apfitzge]

Not sure O(n) isn't going to be possible w/ guaranteeing priority order.
Simplest case I can think of is n tx all write-locking account A that we receive in a batch in random order. Even building a simple priority queue wiil be O(nlogn).

[ryoqun]

(1/2)

[ryoqun]

(2/2)

[Huzaifa696]

"Hello! I have a question about transaction patterns. In the third paragraph of the document, It says, "when seen from the viewpoint of the on-chain state, a very few of its addresses can be highly contended." I was wondering if you could give me an estimate of what "a very few" means in terms of the total transactions that a particular leader is processing.

For instance, if a leader is handling 6,000 transactions per second that involve a total of 30,000 accounts (chosen arbitrarily), would it be reasonable to assume that, on average, around 300 of these accounts, or 0.1%, are in conflict with each other?"