12 standards
The arguments rather than the formats: how transaction processors, overlays and end users divide the work between them, and why that division is what lets the network grow. Nothing here is a wire format, and reading it first makes the wire formats make sense.
Also searched as scaling, throughput, Mandala, Mandala Network, Web 3.0, layers, topology.
12 standards, spread across 4 of the 12 topics.
Handling very high transaction volume means doing as much as possible at the same time, while some checks must still happen in order. This describes how that work is divided across the network so throughput rises without correctness slipping.
Filed under Transactions
Network architecture is the main subject of these 4.
Handling very high transaction volume means doing as much as possible at the same time, while some checks must still happen in order. This describes how that work is divided across the network so throughput rises without correctness slipping.
Talk about a decentralised web rarely says concretely what the pieces are or how they fit. This sketches one: wallets, indexes, browsers and payments, and where each belongs.
Discussions of network design tend to jump straight to mechanisms without saying who is doing what. This lays out a three-layer picture, with processors at the core, indexes in the middle and ordinary users at the edge, as a shared vocabulary for the rest.
Once the layers of the network are named, the next question is which pieces of a transaction belong to which layer. This works through where outputs, indexes and scripts sit and how they relate.
These are about something else, and deal with network architecture on the way.
Building tokens on Bitcoin tempts people to copy account-based designs from other chains, which fits badly. This argues that an unspent output is already the natural unit of ownership and should be treated as the token itself.
A miner interface gained wide adoption and an equal amount of criticism, with some of its uses pulling against how the network is meant to work. This sets out which of those uses are legitimate and which are not.
Some ways of tracking blockchain state require every participant to see every transaction, which stops working as volume grows. This argues that indexes watching only the slice they care about are both safer and able to scale.
The standard way for a device to say which network broadcasts it wants was designed for a handful of groups, not for blockchain traffic at scale. This examines where it falls short and what would have to change.
Sending every transaction separately to every interested party wastes enormous bandwidth when they all want the same data. This proposes delivering it once to everyone who has asked, using the network's own one-to-many delivery.
Splitting traffic across many network groups only works if everyone agrees which group is which. This assigns the address ranges, separating the groups carrying data from those carrying control messages.
Nothing tells a participant which slices of the traffic anyone else is actually carrying. This has each one announce what it holds, so the gaps become visible.
Early designs for tracking and coordinating transaction-based state tended to assume everyone needed to see everything, which does not match how most real applications actually share data. Teams building on top of transaction outputs had no shared way to think through when to keep an overlay open to everyone versus restricted to a known set of participants, so designs ended up copying patterns that did not fit their actual trust or privacy needs. This leaves developers without a clear mental model for choosing the right shape of network for their application.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic