Question about v22 Election Container technicals


there is a LOT of misconceptions about what will v22 bring as a solution or a "patch" against those problems, for which exchanges closed transfers. (Maybe also misconceptions in my mind.)

I would like to write a more technical explanation, with "situations", that nontechnical people understand.

But I'm missing some necessary info.

Questions :

1. Unlimited for now. Are bucket sizes (number of waiting blocks) unlimited, or does it have similar functionality as "Bounded Block" proposal? If unlimited, is limiting planed to v22.1/v23 ? (please some proposal link if there is some emptying algo)
2. Irelevant. I misunderstood the usage of AEC. Valid transactions are in AEC to be broadcasted and globaly confirmed. There is no order, all of them wait for network. Max wait time is 5 minutes, then transaction goes back to bucket. nano-node/election.cpp at develop · nanocurrency/nano-node · GitHub Active Election Container (AEC) has limit, what I noticed from commits default 5000. Is the only way "out of it" by processing the block to confirmation (or fail) ? It has no functionality like "Bounded Block" proposal (throwing out low priority or old transactions)? (please some proposal link if there is some emptying algo)
3. Sorted by time, at bucket push. nano-node/prioritization.cpp at develop · nanocurrency/nano-node · GitHub LRU (or LRUxSize?) sorting is applied in bucket each Round Robin "pointer" looks at the bucket and then the best block(s) is added to AEC ?
4. One. nano-node/election_scheduler.cpp at develop · nanocurrency/nano-node · GitHub Maximum how many blocks are each RR added from one bucket? One, percentage, defined number, or max that fit into AEC ?
5. Irelevant. Is sorting also applied in AEC ? each RR ? LRU or LRUxSize? Meaning after adding new blocks, those with the best priority are processed first.
6. Yes, processing/validation is done before. In AEC is only global woting. After processing a block (confirming), that block does not have to stay in AEC, and frees up space ?
7. No. Can dependent blocks get into AEC at the same time, or only confirmable get to AEC? (account sends multiple transactions before confirmations, b1, b2 ,b3 ... b2 can not be confirmed before b1, so is dependent on it)
8. Yes AEC is freeing up at the speed of CPS ? (answer should be evident from previous questions. Just to be sure, and have explicit answer.)
9. Linear nano-node/prioritization.cpp at develop · nanocurrency/nano-node · GitHub RR goes linear order, or was some pyramid or curve RR implemented?
10. The same as CPS/128. AEC is populated every time a place is free. RR is in sync wit emptying AEC What is the estimate speed of one whole RR around all buckets ? Is it async from AEC/CPS, or each step waits until there is a free place in AEC ?
11. Sorted by last account moddified time nano-node/election_scheduler.cpp at develop · nanocurrency/nano-node · GitHub . That exists for ChangeRep and old blocks. NewAcc still unknown. How are NewAccount and ChangeRep blocks sorted in priority? For new Acc there is no previous timestamp, and ChangeRep is different functionality.
12. question 11. How will be old blocks (without timestamp) sorted in priority ? Only by account size ?

Most of the answers require knowledge of the code, and I'm not good in reading C++ .

Thanks for answers

1 Like

I had a wrong understanding what AEC really works. Qwahzi cleared up that, which helped me to understand what is written in c++ code, and answer my own questions.

(this might not be exact, but enough to visualize)

I'm leaving this post here, as it might help someone else to clarify inner workings.

There Is one last thing I don't understand from the code.

How are new account blocks ordered, or processed?
nano::prioritization::push() requires account_info.modified .