I want to make a pitch for a slightly heretical suggestion. I think that we should consider dropping the block-lattice structure and go to a traditional single-chain structure where blocks contain multiple transactions. First, some details:
- We would still have reps that vote, but they would vote on a transactions in batches. Multiple txs per block.
- Principle reps would take turns to propose a new block for all reps to vote upon. The order of reps to propose a block would be based on a canonical ordering of their nano address.
- In general, reps would aim to complete voting on a batch of transactions every 1 second. That means that once a vote is complete and a batch is cemented, if more than one second has passed, then reps would immediately begin voting on the next batch. If less than a second has passed, then the next rep in line would wait a fraction of a second before posting up the next block for voting.
This would have a number of advantages.
First, the one second block time provides two things. (1) when you send a transaction, you expect it to be voted on within 1-2 seconds. Effectively, you get the UX of "instant" confirmation. (2) it puts a cap on the amount of bandwidth that nodes will need for processing votes. This should make the protocol much more bandwidth efficient.
Second, it removes the need for two confirmations per transaction. Since transactions happen in a canonical order on a single chain, sending and receiving are no longer separate events, so we don't need a second "receive" block to establish the order that funds are received. Again, this improves bandwidth efficiency by halving the number of transaction events happening in the system. Together, these first two advantages should make it much more viable for the average person to run a node.
Third, this makes it much more viable to trustlessly bootstrap a node. Because changes in vote weight only get applied once a whole new batch is processed, the node can actually know the correct vote weight distribution at any point in the ledger history. This means it is actually possible to replay the transactions and votes and be guaranteed to get the same final ledger state as everyone else. Currently, it is theoretically possible for ledger processing to encounter a race condition and end up in a state inconsistent with other nodes, as I have written about here: Does asynchronous processing of "change" blocks mean that block confirmation is non-deterministic? - #3 by fatalglory
Fourth, moving to a single chain means that the protocol can use "block height" as a rough proxy for "time" that is guaranteed to be in consensus among nodes. This makes it much easier to implement some of the time-as-a-currency (TaaC) proposals that have been floating around for TX prioritisation.
This seems to me like a lot of great advantages. But I'm sure there are important disadvantages too. I share these thoughts here in the hopes that someone will point them out. Is there any super important reason why Nano cannot move to a single-chain architecture and gain the advantages above?