On most blockchains, two blocks made at the same moment are a problem. One wins, the other is thrown away, and whoever made it spent the electricity for nothing. Keeping blocks slow is how those chains keep that from happening often.
We use an ordering rule that treats simultaneous blocks as normal rather than as a fight. All of them are kept, all of them earn, and the sequence is worked out afterwards from the same data everybody already has.
How it works
None of this requires you to understand graph theory. It requires one idea: a block can point at more than one thing.
In a single-file chain each block names one parent, so two blocks naming the same parent are rivals and one has to lose. Here a block names every recent tip it knew about. Two blocks made at the same instant are not in conflict, because neither is claiming the other's place.
Once blocks are in, a rule every node runs identically picks out a well-connected core of the graph and walks it to produce one sequence. The same data gives every node the same answer, so nobody has to be told the order by anybody.
A block that would have been an orphan on a single-file chain still holds transactions, still gets a place in the sequence, and still earns. That is the difference the animation above is showing: the same arrivals, wasted on one rule and kept on the other.
Most chains keep blocks slow because collisions are expensive for them. Take away the cost of a collision and the reason for the speed limit goes with it. That is why the genesis target is four to ten blocks a second rather than one.
Why balances work the way they do
There are two ways a blockchain can remember who owns what. One treats your balance as a pile of separate labelled amounts that you spend whole and get change back from, like handing over a twenty for a coffee. The other just keeps a number against your address and adds to it or takes from it.
The ordering rule we use says nothing about which of those you pick. The best-known chain built on it chose the first one, and that was its choice rather than a requirement. We chose the second, because a smart contract needs a place to keep things between one call and the next, and every tool a developer already owns assumes that place exists.
It costs us something to say that. The reference implementation we could otherwise have followed closely does it the other way, so this part gets built rather than adapted. It was the right call and it was not the cheap one.
ordering rule GhostDAG decided
how balances work accounts decided
reward split half to each lane decided
finality virtual chain +
pruning checkpoints decided
blocks per second target 4 to 10 measured on testnet
anticone limit from 24, likely up measured on testnet
pruning window — measured on testnet
confirmation depth — measured on testnetThe lower half of that list is not us being coy. Those four are properties of how fast blocks actually reach each other on a real network, and nobody can decide them by preferring a number. They come out of the first testnet, and when they do they get published.