Tx-dependency trie for parallel block production and validation

Edit: The "deferred ordering" array does not need deferred ordering. Nodes can keep meta-data about length at each trie branch, thus always know order. Much like a mapping in Golang has an order and you can run through it sequentially (with "range") and something similar could grab by index (Golang does not allow that but you could). An ability for keys to fetch their "order ID". Thus whenever mapping does not change (contracts make sure to use them that way), such ID can be used. Would work perfectly in my "video pseudonym parties". But requires the array/mapping is its own trie, and the generalized storage architecture described below fits for that.

Edit: Probably better to do dependency per transaction rather than storage slot, like Polygon is doing as NaturalCarob5611 pointed out. It avoids conflicts in ETH transfer dependency too. Transactions do storage slot I/O by 2-phase commit, try and run and whenever they request access to slot they take a form of "mutex". Shards keep track of what txID is waiting and which has mutex, and they sync this so all shards with mutex or in queue know it. If a deadlock happens, the shard processing the transaction then knows this directly, and then some rule to choose winner (the one to cause deadlock aborts or by txID). I am still not allowed to mention the elephant in the room in sharding as an Edmund with support of a Ligi threatens a ban if I do, but Polygon seems to be sharding correctly as well, that is, "internal" to the validator, which respects that the validator attestation is actually trust-based and any approach that does not respect that and assumes trustless will fail. But Polygon does not have a flat storage trie, and it seems certain types of "algorithms" that run well in a parallelized way might favor those, my dApp needs to register 10 billion people in 2 weeks (each "period" of 4 weeks) and "delayed ordering" array could allow that in parallel way + shuffling randomly, whereas current array has a bottleneck for writing to the length slot and that cannot be done in parallel, so I think the storage model has to be innovated for true parallel Ethereum.

I was recently threatened with a ban for mentioning one thing I think is neglected in scaling, so I assume I will not mention that here. But another important thing, is parallel contract execution. This is probably a topic many people here have expertise on since upwards 10 years, and thus something where those with expertise can share, or when there is unsolved problems, there can be discussion.

Ethereum in 2014 ordered all transactions in a block sequentially in the transaction-trie (sequence number as key in trie). It seems an upgrade from that to parallel execution could be the "transaction dependency trie". Where the keys are the number of dependencies (from 0 and upwards), and then each key stores a nested trie with the transactions. Block validators can them simply run transactions in order of dependencies.

This trie can be constructed based on read/writes of storage slots.

It also seems meaningful with the old flat storage trie idea, which I assume was always about parallelization. It could have "storage objects" that each contain a trie where the keys are storage slots, and storage slots can contain pointers to storage objects. Thus you can have mappings and arrays and such that can be operated on in parallel by shards (I will avoid mentioning my other idea on how such sharding should be organized, as I am threatened with a ban if I do, although it would be easier if moderation here could moderate itself to behave more in line with normal civil discourse). Such is quite easily shardable it seems, arbitrarily (and how arbitrary sharding is allowed, is in that idea I am not allowed to mention by the moderator Edmund with support from Ligi who has publicly threatened a ban if I do). The key is shards can easily collaborate on assembling the Merkle roots for such tries, and mange ranges of keys (based on most significant bits), this has always been a known property of Patricia Merkle Tries.

Why is parallelization important to me? Well I invented "video pseudonym parties" between 2015 and 2018 (Gavin Wood who alone built first version of Ethereum is currently approaching same idea and he calls it "proof-of-video-interaction") and it requires hundreds of thousands of transactions per second for 10 billion citizens. The whitepaper is public and published since 2018, it has been cited by MIT researched Bryan Ford in numerous publications, was in Frontiers and Bloomberg, and has been well known by "the community" (but it was originally invented together with a controversial organization).

Note, inter-shard "mutexes" (which will be in contract code most likely) is part of such coordination too, but again, me being forbidden from mentioning the elephant in the room on sharding does make it harder to have a technical discussion, and it would be good if the moderation here could overrule that moderator's threat. I do not see how it is productive to forbid mentioning the elephant in the room on sharding, it ought to make it impossible to move past that bottleneck.

Edit: The dependency trie probably needs storage slots nested under each transaction, and for multiple accesses sequential list, and then the transaction hash dependencies for each. The block validator has to run every transaction in parallel, but the dependency trie acts as implicit "mutex" for each point of contention, with no deadlocks as the block producer could run it. It is a bit complicated, but it seems it should work. The "number of dependencies" part in the trie can be skipped, it is meaningless. But it would be easier if I was not threatened with ban if I mention the elephant in the room in scaling, as it is important here in how the sharding is ideally organized (or, the only way it works in this current paradigm).