A slightly heretical proposal: moving from block-lattice to a single-chain architecture

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?

1 Like

Nodes can already vote for 12(?) transactions at a time, and with stored votes you'd drastically improve voting efficiency and bootstrapping. I don't think you have to re-implement leader selection or formal transaction grouping ("blocks") to achieve the benefits you are looking for.

Given that principle reps can join or leave at any time (and PR determinations are local, based on perceived online vote weight), and the current protocol has no real sense of time, how would you do leader selection, block creation, and transaction ordering consistently and accurately? I think you'd still need multiple votes (confirmations) per block (group of transactions), especially in situations where there is block contention. E.g. nodeA thinks repA is the current leader and creates blockY1 referencing blockX, but nodeB thinks repB is the current leader and creates blockY2 also referencing blockX (discarding blockY1 because it doesn't think repA is actually a PR)

1 Like

I'm not sure if I'm understanding your points accurately, so please correct me if I'm wrong.

If I am understanding correctly, then it sounds like a misunderstanding of what I am proposing. An example might help. To avoid confusion, I will refer to "batches" rather than "blocks" (where a "batch" contains multiple transactions and some metadata, analogous to a "block" in Bitcoin).

Say we have a batch (batch 1) which contains 100 transactions. This batch was proposed by Rep A and once changes in vote weight caused by those 100 transactions are accepted, then the vote weight distribution becomes [Rep A: 20%, Rep B: 40%, Rep C: 40%].

The weight determinations are no longer local. They are based on the resulting weight after the most recent batch is confirmed. So everyone can see the new weights and see that the last batch was proposed by Rep A.

Since A proposed the last batch, everyone now expects a new batch to be proposed by Rep B and then voted on by Reps A, B and C.

Suppose that Rep B goes offline when it is their turn to propose a batch. After a grace period, Rep C will assume Rep B is not going to propose a batch and Rep C will step in and propose a batch of their own. If Rep B comes back online and proposes a batch at the same time, then there will be two alternative batches (batch-B and batch-C). The normal fork-resolution voting process will take place and one of these two batches will be confirmed while the other is rejected.

In theory, any Rep can propose a batch at any time. No one ever becomes the "leader" and is given the authority to unilaterally decide on the next batch that will be confirmed. Behaving reps will refrain from proposing batches until it is their turn. If misbehaving reps try to propose batches, then they will be subject to a fork-resolution by vote, using the weights from the last confirmed batch (and generally be rejected).