17 standards
Delivering transactions and blocks over IPv6 multicast, so one send reaches every listener instead of one connection per peer. This is the largest single cluster in the corpus and it is spread across three topics, which is exactly why it is hard to find without this page.
Also searched as IPv6, broadcast, MLD, group address, NACK, multicast group.
17 standards, spread across 3 of the 12 topics.
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
Filed under Transactions
Multicast is the main subject of these 15.
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.
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
One-to-many network delivery does not tell the sender when a piece went missing. This lets a receiver report exactly what it did not get, and the sender resend only that.
A receiver has to know which network group carries the slice of traffic it wants before it can subscribe. This has senders announce that mapping periodically, so a listener can join without being told out of band.
The same frame is useful for a transaction that already carries the details needed to validate it on its own. This defines that variant while leaving the header untouched, so existing readers still work.
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.
Clients need to know when a new block arrives, and polling for it wastes time and bandwidth. This pushes the block's summary to everyone listening as soon as it exists.
Knowing a subtree exists is not the same as having the transaction hashes in it. This defines a frame carrying those contents to everyone subscribed, so nobody has to request them.
The first transaction in a block is a special case, and it does not travel with the ordinary transaction stream. This says how it is carried and who receives it.
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
A client that only tracks block headers should not have to receive a whole block announcement to get one. This carries the eighty-byte header on its own.
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.
Sending many tiny transactions as separate packets spends more on overhead than on content. This packs the ones heading the same way into a single frame.
The address space carrying transactions was not designed to carry anything else, so a second kind of object has nowhere to go. This divides it into planes, giving each kind of object its own room.
These are about something else, and deal with multicast on the way.
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
Once a second kind of object has its own space, it needs a frame to travel in and a route back for submissions. This defines those wire forms.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic