← Latest papers
🔢 mathematics

Monotone Erasure Codes

This paper introduces monotone erasure codes to support arbitrary trust assumptions in distributed systems, providing efficient construction algorithms for linear variants and demonstrating their application in creating communication-efficient, generalized asynchronous verifiable information dispersal (AVID) protocols for blockchain consensus.

Original authors: Vivien Bammert, Annalisa Cimatti, Orestis Alpos, Giuliano Losa, Christian Cachin

Published 2026-05-22
📖 5 min read🧠 Deep dive

Original authors: Vivien Bammert, Annalisa Cimatti, Orestis Alpos, Giuliano Losa, Christian Cachin

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a precious, secret recipe for the world's best cake. You want to store this recipe in a way that if some of your friends forget their notes or get lost, you can still reconstruct the full recipe from the remaining friends.

The Old Way: The "One-Size-Fits-All" Approach
Traditionally, systems used a method called Erasure Coding (like Reed-Solomon codes). Think of this as cutting your recipe into 10 equal slices and giving one slice to each of your 10 friends. The rule was simple: "If you have any 6 friends, you can put the slices together and bake the cake."

This works great if you assume any 4 friends might disappear. But what if your friends aren't all the same?

  • Friend Alice lives in a stormy area and often loses her mail.
  • Friend Bob is very reliable but has a tiny mailbox.
  • Friend Charlie is super reliable and has a huge mailbox.

The old "10 slices, need 6" rule is inefficient here. It treats Alice (who often fails) the same as Bob. If Alice loses her slice, you might not have enough slices from the others to bake the cake, even if you have plenty of reliable friends. You might end up giving Alice a huge slice just to be safe, wasting space, or giving Bob a tiny slice that isn't enough.

The New Idea: "Monotone Erasure Codes"
This paper introduces a smarter way to cut and distribute the recipe, called Monotone Erasure Codes. Instead of a rigid rule like "need 6 people," this system respects a Trust Map (or Access Structure).

Think of the Trust Map as a custom instruction manual that says:

  • "If you have Alice, you must also have Bob and Charlie to make it work."
  • "But if you have just Bob and Charlie, that's enough!"
  • "If you have David and Eve, you need a third person, but it doesn't matter who."

The system assigns different-sized pieces of the recipe to different friends based on this map:

  • Alice (unreliable) might get a very small piece (or even no piece at all) because the system knows you can't rely on her alone.
  • Bob and Charlie (reliable) get larger, more critical pieces.
  • David and Eve get medium pieces.

The magic is that no matter which group of friends shows up, as long as they form a "valid team" according to the Trust Map, they have enough total information to reconstruct the whole cake. If they aren't a valid team (e.g., just Alice and a random stranger), they can't do it.

How They Built It
The paper offers two main ways to build these custom codes:

  1. The Fast Builder: This method takes your Trust Map (described as a logic tree of "ANDs" and "ORs") and quickly cuts the recipe into pieces. It's fast and works for any map, but sometimes it wastes a little bit of space (like cutting a slice slightly too big just to be safe).
  2. The Perfect Builder: This method uses a bit of math (Linear Programming) to find the exact smallest pieces possible for your specific Trust Map. It's like a master chef calculating the precise millimeter of dough needed for each friend to minimize waste. This is the most efficient but requires more calculation time.

They also found a special case called Partitioned Access Structures (like the Stellar network, where nodes are grouped into organizations). For these, they built a super-efficient algorithm that finds the perfect piece sizes very quickly.

Putting It to Work: The "GAVID" Protocol
The paper doesn't just stop at storing the recipe; it shows how to use these codes to send messages across a chaotic, asynchronous internet where people might be lying or slow.

They created a new protocol called GAVID (General Asynchronous Verifiable Information Dispersal).

  • The Old Way: Used to only work if you knew exactly how many people might fail (e.g., "at most 3 liars").
  • The New Way (GAVID): Works with the complex Trust Map. It allows a sender to scatter the recipe pieces to the network. Even if some friends are lying or slow, as long as a "valid team" (a Kernel) of honest friends collects the pieces, they can verify the recipe is real and reconstruct it.

Why This Matters
In the world of blockchains and distributed systems, not all computers are created equal. Some are more trustworthy than others. This paper provides the mathematical tools to stop treating everyone the same. It allows systems to be more efficient (storing less data) and more robust (handling complex trust relationships) by tailoring the data distribution to the specific reliability of each node.

In Summary:

  • Old Code: "Need 6 out of 10 people, no matter who they are."
  • New Code (Monotone): "Need a specific combination of people based on who you trust. Give more data to the reliable ones, less to the unreliable ones."
  • Result: A smarter, more efficient way to store and share data in systems where trust varies.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →