Sheaves, roughly speaking, give us a neatly bound mathematical bundle of information that comes from many distributed agents that have overlapping perspectives but may disagree on that overlap. One simple example of a system with an effective sheaf-theoretic description is a room with several sensitive thermometers in different points in the room. They will inevitable yield slightly different readings. What is the best way to mathematically organize this information? How do you pick one temperature to be the “right” temperature of the room? Sheaves have been singled out as the best structure for such situations. They tell us how to “glue” local information into global information, and if we can’t do that, tells us what is obstructing us from doing so. From a data-centric blockchain perspective, you pick one thermometer at random and claim that that is the temperature of the whole room. From the agent-centric Holochain perspective, you record all of the temperatures recorded, and keep track of which groups of thermometers agree or disagree.

Some overlapping sensors. Sheaves tell us how to think about data that is organized like this and glue local data together into global data.

A sheaf associates to every region of some space some sort of data. You could imagine the region as being the sensor range of a radar, so the sheaf associates the radar reading to the region of space that the radar sweeps. If you have several radars with overlapping ranges, each plane flying in an overlap will be seen by two or more radars. If you watch each radar sweep individually, it can be hard to tell when two radars are looking at the same plane. But if we glue the data from the radars together, we can look at one complete map. Sheaves give us a precise prescription on how to do this gluing process in pretty much any possible context where gluing makes sense. Sheaves have a very general definition, which inspires confidence that in any randomly chosen context where a notion of gluing exists, a sheaf-theoretic description of that gluing exists.

f and g are different sensors, and this diagram describes how they overlap and glue. From A Category Theoretical Approach to the Concurrent Semantics of Rewriting, by Heindel.

I have spoken with several other mathematicians and physicists who have spontaneously aligned in thinking that sheaves seem like the right way to describe consensus protocols for distributed systems. This is one of the problems we will be focusing on at the Second Statebox Summit. I don’t know anybody that claims to have a good understanding yet of how to do this, just a collective feeling that it is the right way to do it. By the end of this article, I hope I will have conveyed some sense of what sheaves are, what they are capable of, and drum up support for the mission to A L I G N T H E S H E A V E S. Creating infrastructure-critical technology requires the utmost due diligence, and a little math goes a long way.

What is the ultimate point of this endeavor? I cannot claim an ultimate point, but at least divulge some very good reasons for doing so. The entire blockchain and friends’ space is lacking a ground-level mathematical foundation. One open arena on which you can pit all possible technologies against each other in the pit and compare them directly, apples to apples. For the most part, arguments in this space rest on hundred year old game-theoretic arguments and there is no way to directly say that one thing is better at a given task than another. Sheaves, we predict, will ultimately give us a rigorous way to do one part of this task, namely comparing different consensus models (or more generally, local consensus models a la Holochain which theoretically has Nakamoto etc. consensus as a special case).

Knowing how to do this will ultimately allow us to build provably-correct code. Anybody who has followed the cryptocurrency space for awhile has seen stories of incorrectly written smart contracts causing people to lose millions of dollars. This is simply unacceptable and wide scale adoption can never happen if that remains a possibility. We must be able to prove that code performs as expected, and furthermore be able to do this with automated theorem provers. This is not an impossible goal, but to avoid making the article too long and speaking about that which I know little about, I will not elaborate further.