WTF is Char?

I'm going to talk to you about what Char is. Char is the sequencing layer for Bitcoin. What does that mean? We're going to make a piece of infrastructure that is going to be essential for the future of all layer twos running on Bitcoin.

​

In this talk, we're going to have three main components: the basics of why it exists, how our underlying architecture works, and then some work-in-progress problems that we're tackling.

​

First of all, why would anyone want to run Char? Inside the Bitcoin community, inside the layer two community, everybody is really an idealist. We're trying to make Bitcoin and layer twos on Bitcoin as cypherpunk as possible. But at the end of the day, you often still end up having centralized components that require some sort of trust assumption. At Char, we do not like that.

​

What Char is intending to do is be a platform that you can run that replaces some amount of trust. Here's what it looks like for somebody who is serving as one of these functionaries in Char. You lock up some Bitcoin for a few weeks. You become a member of a stake-weighted participant set. You start signing attestations. You form consensus with other participants. That consensus creates proofs of consensus that can be absorbed into a layer two application. And if you ever cheat, then you lose your money.

​

That's the basis of Char. We are a shared sequencing platform, which means that all apps and all layer twos in the ecosystem can use our same federation.

​

As an example of this, yesterday one of our teammates, Stu, gave a wonderful presentation on what it would look like to build an application. Here is a prediction market that he built that runs on top of Char.

​

How have we built this Char client? It's actually built directly inside of a fork of Bitcoin Core. The way that we've done this is to make a minimal inline set of logic changes that are all added via a plugin interface. We are almost identically Bitcoin Core. You could run a Char node with Char disabled and it would just look exactly like a Bitcoin Core node. But if you pass in some special arguments, then you are going to get supercharged with Char.

​

Under the hood, we have anchors and bonds. Anchors are identities for each staker. A bond is a certificate of deposit that you place. We have a CValidationInterface-based detection system that can ingest all the block data and figure out who has staked what. We then take those records of deposits and form them into epochs.

​

In each epoch, it is a set of participants who have a verifiable amount of Bitcoin that could be burned if they misbehave. We form these different groups over time. Every application in our ecosystem has some sort of ID. You just need to put that out there, some sort of address for each application, so that you can know where to get the data from.

​

Every time we have an epoch, we create a specific per-epoch ID for every domain, and then each participant in the network begins signing messages that are relevant for that specific channel. The information that is coming out is a verifiable record of the entire network committed to specific blocks of data for this application in a specific order.

​

The proof that we're exporting is specifically that if you were to ever get a conflicting committed piece of data for an application in a specific order, then a third of the network would have had to destroy their value in order for that to be a message that you've received, if you see two of them.

​

That's what we're talking about when we talk about verifiable consensus. You can verify that people would be destroying a heck of a lot of money if you were to ever be lied to.

​

Under the hood, we implement that by a deterministic nonce system from the MuSig paper. We use these to guarantee that if two conflicting statements are ever signed, it leads to a key being leaked. This is through a classic vulnerability in Schnorr signatures: if you ever reuse a nonce, it leaks your key. Because we use this deterministic nonce, that guarantees that if a nonce is ever revealed, we can find the intersection of the two lines and then reveal a key.

​

This whole slashing thing is really not magic. All that we're talking about is that Char creates publicly verifiable value at risk. If there is an equivocation, then you can be punished. We track through the epochs exactly how much value is at risk at any given moment over time, and that's how we bind our decisions and proofs against specific groups of people who can be punished.

​

That's really the core algorithm behind Char. In any consensus system, what you'll find is that it's not just everybody shouts and whoever shouts loudest gets consensus. Usually you have some way of finding a leader who can direct. This is not a leader as in someone who's in control. It's more like a guide.

​

We pick these leaders using a sampling algorithm that randomizes who's allowed to guide the network at any given time. We change that on every single message, essentially, of who's leading, and the whole network tries to follow them. If they are a bad leader, then the next leader is just moments away.

​

For the applications that are using this, generally they're using what's called a pre-commit architecture. A pre-commit architecture is where you are using the Char network for consensus for a bounded period of time between which you're posting state snapshots back onto Bitcoin.

​

The general architecture that a layer two uses is they want to post data to Bitcoin on some period. Let's say they want to post once a week. Between those weekly postings, where they post the state of their whole application, they want some amount of low-latency, verifiable consensus happening, and they would use Char for these verifiable state transitions between their posts back to Bitcoin.

​

If you don't want this architecture, in theory you can use Char and just have that be your only means of consensus. But proof-of-work checkpointing is a really great tool, and we think that most layer twos are going to use that, in particular because they are intending to make BitVM-like bridges to be able to trustlessly bridge, and those require commitments on chain.

​

Now maybe the fun part is what's left to do. All of what you've seen so far is stuff that we basically implemented, and we have a lot of things that we're planning on working on or wrestling with. If you were to join our team, you could help us figure those things out.

​

One question for us is that we're currently a dumb pipe architecture. That means we don't care what the data looks like. However, there are ways that we can maybe do not full validation, but a light amount of validation per application. This might streamline the way that layer twos can integrate, so that's something that we have under consideration.

​

Another open question that we're working on is where domains come from. How do you register and create a new domain? There are denial-of-service issues with this. If you can just create infinite domains, we have some mitigations that we're working on, but it's an open topic of research that we're going to pitch out to the wider layer two community: exactly how they want to register their layer twos and be able to read data from the network.

​

Compression is also another open topic that we're working on actively. The verifiable decisions that we produce from Char are actually quite large. Most of the layer twos that exist have their own bespoke compression technologies, usually based on zero knowledge proofs, to take some set of transactions and reduce the size of the data that needs to go back to be posted on chain.

​

We don't therefore provide our own native solution for that, but there are some approaches that we could take that would make our proofs natively smaller and would reduce the burden for layer twos to compress the decisions being exported out of Char.

​

The last open area that I want to talk about is a little bit more nuanced. I've been rushing to give a little bit more philosophy: the question of what gets sequenced and why. This is really a question of incentives.

​

Interestingly, in Char, there's sort of a natural market where stake holders, in a sense, are producing an amount of bandwidth that they themselves don't necessarily intend to use. Consumers, layer twos, want that bandwidth. It's an open question of how they should pay for it. Should they pay via Bitcoin? Should they pay through a token? Should they pay via being able to extract some sort of miner extractable value, where the act of sequencing itself is just something you can make money from doing by choosing what goes in?

​

There are a lot of different models that have been explored for this in the literature or prior art. There are sort of first-come, first-served free-for-all models. This is obviously bad for denial-of-service reasons. There are purchase models where you pay for every byte going in, maybe somewhat explicitly.

​

One thing that I want to talk about, which is maybe a new conceptual direction, is fields. I mean that in the physics sense of the word field, because we don't actually love tokens. We're kind of anti-token largely at Char, but we're trying to solve a real problem in bandwidth allocation.

​

Something that in our thinking we have observed is that tokens are kind of like particles, and everybody knows the particle-wave duality. But there are also fields as part of that story as well. In tokens, economic signals and incentives also kind of form a similar triad of concepts, where essentially in any system where you have waves, you have things that you could maybe interpret in another way as being a particle. It's a pattern inside of a wave. A waveform is a pattern, and then certain types of nodes within that pattern behave like particles.

​

Similarly for an economic system, you have signals and incentives, and then you have fixed points that behave like a token. In being anti-token, we've maybe arrived at a place where a token is an artifact of a real economic phenomenon happening. It's any time that you can discretely bundle something together.

​

This is an open area of research for us. Can we make our incentive system work more in the signal and incentive space, with a smart use of maybe a particulate charge that we're placing, to steer in a more probabilistic or stochastic way how every participant operates, without denial of service and without maybe some of the traditional problems that you have when you try to define your economic system token-first?

​

We want to focus on incentive, signal, field, and wave before we think about how those things become discretized. That's an open area of research that we're going for. For now, we're really just focused on building the best possible consensus primitives, and we'll worry about the behavioral sides as they become necessary.

​

Thanks everyone for coming out. I don't know if I have time for questions, but if I do, I'll gladly take some. Thank you.