Overall I think this is clearly a directionally positive proposal, but discretizing time + more explicit auctions seems to allow for better expressivity in bids and further reduce the latency advantage. As noted by @bbuddha:
This policy doesn’t necessarily get rid of the incentive to colocate with the sequencer.
Searchers likely care less about being first with respect to time and care more about being first with respect to other searchers, and it seems like a “continuously” growing ledger like Arbitrum’s doesn’t get some of the nice levers in this respect that a “discontinously” growing ledger like Ethereum does (for example running auctions between blocks at a delay beyond which colocation would matter).
There’s still an explicit advantage here to faster transaction submission, encouraging centralization, co-location, latency spending etc. (albeit reduced). That would be further removed if the bid’s position were to be entirely unlinked from submission/receipt (i.e., just based on fee within the bucket). Seems helpful to have more expressive auctions as noted in @sxysun follow-up comments to the FBA-FCFS post. Conditional payments like coinbase.transfer, reverts, etc.
Regarding your plans to make this forward compatible with decentralized sequencing:
-
How would you then plan to cycle sequencers if time is treated as continuous? Cycle leader after X # of transactions sequenced, with every node reporting their perceived exact score for every transaction? And the leader sequences based on the averages of all the scores submitted to them and average of times submitted? Seems a bit tougher, I’m a bit unclear on the plan here.
-
It seems easier for the FBA-FCFS style individual nodes reporting a partial ordering to the leader who then aggregates these into a weak ordering of unordered batches in it, then have the leader just resolve the intra-batch ordering via auctions wouldn’t it?.
I’m also not tied to the 500ms fwiw, probably fine to be longer.