Contents
This article is rich in content on blockchain architecture, the advantages of building resilient decentralized systems where anyone can run a node, and the key takeaways for folks interested in novel approaches to scaling Stacks via appchains. Appchains are in the MVP state at the moment, with an overview and code available on GitHub, but have been an idea for scaling blockchains that continue to benefit from Bitcoin’s security for many years. Now, developers can try out the MVP code as well as a suite of Hiro developer tools for builders on Stacks. I hope you enjoy the unique and enlightening insights to building on Bitcoin from this interview!
— Gina Abrams:
Hello, and welcome to the Builder Series of Stacker Chats, where we connect with the amazing people building in the Stacks ecosystem. My name is Gina Abrams and I'm very excited to be joined by Jude Nelson today, Stacks core developer and research scientist at the Stacks Open Internet Foundation. Jude and I worked together prior to his joining the Stacks Foundation so I've been really looking forward to this conversation. We are going to start with Jude's background, dive into appchains and learn more about his work at the Stacks Foundation.
Thank you for being here, Jude. I would love to start with hearing a little bit more about your journey to actually joining the Blockstack team all the way back in 2015. What excited you about the project?
— Jude Nelson:
I remember back before Muneeb even got started with OneName, we worked together in the same lab in grad school. And that's about the time he got interested in trying to use blockchains to solve some difficult problems that existed at the time in social networks. Namely, how do you build a decentralized social network? And that's where OneName, the system that we called it, before it was called Blockstack came to be. He and Ryan Shea, his co-founder, were really interested in cryptocurrencies because in 2014, 2015, they were just starting to really take off.
OneName, the system that they had built, was a way to bind human readable usernames to Bitcoin wallets. So you would register a username, at the time it was on the Namecoin blockchain, and you could tie it to a Bitcoin address or an Ethereum address. There's a bunch of other slots you could put in. Same with social. You could put in social verifications to prove that you were who you say you were. Muneeb and I would talk about this periodically just because we knew each other already. And that started to turn into, he would invite me to come up to the OneName office in New York just to spend maybe a day, a week there.
At the time I was working on my thesis project which had nothing to do with cryptocurrencies at all, but I was finding myself in need of a system that did a lot of the things that OneName did. The system that I was building needed a single sign-on system, so you would have a username and it would bind your username to some credentials, some extra metadata information. But I didn't want to have that system reliant on a single administrative entity to control it, because my thesis project focused on doing things in the wide area where there's no center points of control.
That's what drew me ultimately to work on OneName, then called Blockstack because it solved this very particular problem I had with my thesis project.
"That was actually what clicked for me. You can use blockchains for things besides trying to build cryptocurrencies. "
For months prior to that revelation that I had [believed], and to be clear, I still maintain this today -- Bitcoin and other cryptocurrencies are victims of their own success. They're not going to replace dollars or national currencies, et cetera, just because they just don't have the bandwidth to do it.
Even if they did, the success story would be that they become just as heavily regulated as the SWIFT networking, which might be okay. I'm not here to judge or to say anything about the philosophy or the underlying ethos behind that. I'm looking at it purely from a distributed systems perspective.
I guess the other thing that came with that revelation that you can use blockchains for non-financial things is that it doesn't matter whether or not you believe that cryptocurrencies are going to become money or not. They're still valuable.
The thing that really underpins the value of Bitcoin to me is the fact that I can store some data in the blockchain, specifically in something called an OP_RETURN output, within a Bitcoin transaction. It's not a lot of space. It's 80 bytes per Bitcoin transaction, but the stuff you can do with that 80 bytes is worth a hell of a lot more than what Bitcoin currently would be valued at, if this was widely known, widely understood information. In fact, we exploit this very system now to build the Stacks blockchain, all of the Stacks metadata that's needed to reconstruct the Stacks blockchain is embedded in these little 80 byte fields.
So, if you think about it that way, a single Bitcoin transaction might be worth a whole Stacks block. So thousands of dollars. And that's just a single little tiny sliver of data. That could be what underpins Bitcoin's value in the long run. I don't know, but the point is though there's more to Bitcoin than just trying to replace dollars.
"There's more to Bitcoin than just trying to replace dollars."
— GA:
Absolutely. You've now been with the project over a number of years. Can you share more of the evolution of your journey in the Stacks ecosystem and where it's brought you, what you're working on today on the day-to-day?
— JN:
Sure. Back when I joined it was OneName, and the first task I had when I joined OneName officially was to port the system from Namecoin to Bitcoin. The story at the time was that Namecoin was going to be this replacement for DNS. And it still exists. The chain is still out there, but the thing that Muneeb discovered and he wrote about his PhD thesis, is that if your chain is not widely used or not nearly as popular as maybe the top few on Coinmarketcap, bad things can happen to that chain and no one's going to notice. So Muneeb noticed that Namecoin, a mergemined chain (what that means is that Bitcoin miners can submit their proof of work to the Namecoin chain and earn a Namecoin coin base as well. In theory, this makes it so that the Namecoin chain is secured by Bitcoin's hash power).
"What Muneeb discovered and reported in his PhD thesis is that merge mining doesn't work if you don't have all or nearly all of the Bitcoin miners participating in it. What he discovered is that Namecoin was actually controlled by a single Bitcoin miner at north of 60% hash power. So Namecoin was effectively 51% attacked for months and months at a time. And if that wasn't bad enough, no one noticed, no one cared."
So, that was like a penny drops moment for all of us thinking, oh, shit, we can't rely on these smaller blockchains because they can break. And we're SOL if they break. What are we going to do? Who's going to care? Who's going to spin up miners? The conclusion we drew from that is we really should build on the strongest blockchain that if something bad happens, everyone's going to notice and everyone's going to raise hell about it. And that's the interesting social aspect of building on Bitcoin. It's the chain with the largest number of users that you can now deputize to keep the system secure. It's like the system with the largest number of canaries will start screeching and then if something bad happens. You're not going to get that with a small blockchain.
So that's where the journey started. Like, okay, we have to build on Bitcoin. Everything must be built on Bitcoin because it is the most secure blockchain and moreover, we need to build it in a way so that if something else gets better than Bitcoin, we can switch to that very quickly. Hard lesson learned there. And that's when the system got ported from Namecoin over to Bitcoin, that's when the name changed from OneName to Blockstack, because at the same time we had noticed that the problems you need to solve in OneName, so not only binding names to this extra off chain metadata, you also need a way to store that metadata. You need a way to store profile pictures. The amount of data you might store per name can grow unbound.
So at about the same time as we built, and we ported the system over to Bitcoin, we had this other aha moment that, oh, hey, we have naming, we have storage, we have an underlying peer-to-peer network that replicates that data. This is looking less and less like a single application, OneName, and more and more like a platform, like a decentralized community owned platform.
And that's when we changed the name to Blockstack. The reason it was called Blockstack is because at the time, there was an up and coming cloud computing platform called OpenStack, which is supposedly meant to make it so that you can combine different types of one off services and turn them into a coherent cloud platform.
I'm not quite sure how they ended up in practice. It's pretty obscure now. I'm guessing it didn't quite work out that way, but at the time, that was the inspiration for the name Blockstack, a play on the word OpenStack.
That’s where we were up until the Stacks 2.0 world. Blockstack became this platform on which you can build these decentralized apps where users own their own data and their own identities. And Stacks 2.0 is a continuation of that story, but now they also own the means of computing, realized in our case through smart contracts. But the fundamental design networks are still the same.
We use Bitcoin to store hashes of metadata inside of OP_RETURNS. And we have this other system that takes care of replicating state to all of the stack specific nodes. It's just that we've now reached the, "Master design," as Muneeb likes to call it, where you're not only storing naming and storage routing information, you're storing whole programs written in clarity that can do things beyond just simple name registrations.
— GA:
That brings us to your work at the Stacks Foundation. Since you've been through this incredible evolution of the project, you've also touched a lot of the code within the ecosystem. What are some of the things that you're most focused on today?
— JN:
Right before we started this chat, I was working on making the mempool synchronization better. So that transactions have a much higher chance of making it to all of the Stacks nodes and pools as opposed to 50% of them, which is about where we're at right now. That said, the primary thing that I work on right now is still the Stacks blockchain. Specifically, I work on the parts that aren't Clarity. Aaron works mainly on Clarity, for example. Aaron and most of the other Hiro engineers interface with that. I work on the peer network, the block database, the chain state, the index over the chain state.
Recently, I released a prototype system of appchains, which is one of the handful of scalability solutions that are being considered for the Stacks blockchain. So yeah, I've touched most parts of the code base. I've worked on Gaia, I've worked on what was called blockstack.js at the time. Now it's called Stacks.js. I'm pretty sure some of my code is still in there. I've worked on CLI tooling for it. Wherever there's a need really is where I contribute.
— GA:
Awesome. Thank you. So that brings us to this idea and concept of appchains. This is something that you've been thinking about for a few years and almost working on as a side project. I'd love to hear a little bit more about appchains and the overview that you shared recently of the concept and some of the key takeaways for developers and users alike.
— JN:
Sure. So just a bit of background.
Blockchains by themselves don't scale. A blockchain cannot scale, is designed not to scale. It is the perfectly unscalable distributed system. That's okay though, because what you get by giving up scalability you gain in resiliency. So the fact that everyone in the world can run a Bitcoin node right now, for example, means that if you want to stop Bitcoin or break Bitcoin, you really have to attack a sizable portion of the internet itself, which is a tall order.
"Blockchains by themselves don't scale. A blockchain cannot scale, is designed not to scale. It is the perfectly unscalable distributed system."
And a lot of people would notice and be very upset by that, which in turn would lead to the attacker likely being stopped through some protocol external means such as elections, revolution, protests, et cetera. That's a good thing. The fact that everyone can get involved in your blockchain running a node is really what gives it its staying power. And that's an echo of the lesson learned by “you must build on Bitcoin” because that's going to have the most people who are upset when something breaks.
So blockchains not scaling means blockchains are highly resilient, but that doesn't mean that people are going to stop caring about scalability. Obviously, at any given point in time, there's going to be one or a handful of blockchains that are touting the “we have infinite block capacity. You should use us because we have free transactions.” And they inevitably fail when they get obscure. There's a graveyard of them. There's BigchainDB, and EOS isn't what it used to be. I think Solana is the popular one right now. Give it five years.
It's not that they're not trying. Their hearts are in the right place. It's just that the promise of blockchains is that anyone can run a node. And if you can't run a node, then why am I using a blockchain? There are way better ways to solve problems that blockchains solve if you can get rid of the requirement that users are expected to run nodes at home. So that's a bit of background. So blockchains by themselves cannot scale.
But if the set of blockchains that exist right now indicate anything, it is that there can always be more blockchains. Anyone can make an Altcoin. You just fork Bitcoin, you make a few changes, you fork Ethereum and make a few changes, write your own from scratch. Knock yourself out. Making Altcoins is a relatively straightforward, permissionless way to add more aggregate transaction capacity to the entire crypto space.
Leveraging that observation there, what appchains really are, is they're just more Stacks blockchains. Every appchain is a Stacks blockchain, same protocol, same transaction format, same clarity, everything. Only difference is that what Stacks brought to the table is this novel consensus protocol called PoX, which among other things, links a blockchain to an existing blockchain by making it so that you transfer and/or destroy tokens in the existing blockchain in order to mine blocks in your new blockchain.
"What appchains really are, is they're just more Stacks blockchains. Every appchain is a Stacks blockchain, same protocol, same transaction format, same clarity, everything."
That itself is what makes appchains tick. Each appchain is a PoX (proof of transfer) blockchain that has its own token, but it's mined by transferring or destroying tokens in an existing Stacks blockchain somewhere. So this mechanism of PoX is very generalizable. You can have the Stacks blockchain running with Bitcoin. You can have appchains, i.e., other Stacks blockchains running on top of Stacks. You can have appchains on those appchains, appchains on those appchains, and appchains on those appchains at infinitum.
Right now I think the prototype is capped at 2 to 32nd second power minus two possible appchains that can exist, which is about 4.1 billion. We can make that bigger down the road. We might have to make it bigger down the road. That'd be a wonderful problem to have if there are 4.1 billion appchains and we heavily need more chain identifiers. But the point is though, we're never going to run out. We can always make it so we just never run out. And through PoX, what that would mean is that all of these appchains are anchored fundamentally to Bitcoin.
The key innovation over having a whole set of appchains that anyone can go in and instantiate and set up much like how anyone can go and instantiate and set up an Altcoin, is that these appchains are still fundamentally secured by Bitcoin. And they come with all of these batteries included bits of technology, like the Stacks wallet would work with an appchain, the Stacks explorer would work with an appchain, et cetera, and so on and so forth. Moreover, because they're linked together through PoX, you have this really nice economics property that helps you reason about the security of individual appchains, which is super helpful for the users because when you send a transaction, you want some assurance that your transaction's going to stay on the main chain.
"The key innovation over having a whole set of appchains that anyone can go in and instantiate and set up much like how anyone can go and instantiate and set up an Altcoin, is that these appchains are still fundamentally secured by Bitcoin."
One thing that's currently not really talked about too much, but is there, if you want to go explore it, is you can tell what the price of the Stacks token (STX) is just by looking at the chain history of Bitcoin and Stacks. So, you can look at the sequence of miners sending Bitcoin transactions to attempt to mine Stacks blocks. You can count up how many Satoshis they've spent to do that. And you can look at the number of Stacks they would've earned by winning the block race. And you can reason to yourself, oh, the expected worth of the Stacks token in terms of Bitcoin is X, just by looking at the two chains.
Now you can do that with the appchains as well. I can say, oh, well, I have Stackeroos, let's say is the token on my appchain. I know how many STX each stackeroo is worth based on the mining activity on the Stacks chain. And because I know how many Bitcoins a Stacks token is worth, I now know how much Stackeroos are worth in Bitcoin. I heard it said by Patrick Stanley, for example, that Bitcoin has become this measuring stick now for everything that operates on top of Bitcoin, and that would include appchains.
So every time there is a new Bitcoin block mined, that creates a Stacks block and that in turn creates appchain blocks, which create more appchain blocks, which create more appchain blocks. And they all have tokens that are now measurable ultimately in the worth of Bitcoin.
So that gets us a few things. First of all, that gets us a way to reason about how economically secure each appchain is. I can reason about how much Bitcoin would have to be given up or equivalent worth of Bitcoin had to be given up in order to execute a reorg on my appchain and how deep a reorg I might want. And that in turn can inform me how many confirmations I should wait for my transaction to get mined.
If my transaction is worth X dollars, I want it to be a case that it costs more than X dollars to execute a reorg on the appchain I send it on.
The other nice thing about this property that Bitcoin drives the execution here of the Stacks chain and all of its appchains, is that it blows out of the water this idea that Bitcoin is a waste of energy. Bitcoin is not a waste of energy. It's simply underutilized. A single Bitcoin block now is responsible for triggering the creation of an unbound number of blocks in these other chains. So you can amortize now the energy spent that went into producing that Bitcoin block across all of these chains and come to the conclusion that you're actually getting a bargain.
"Bitcoin is not a waste of energy. It's simply underutilized."
Sure, Bitcoin chain might take the power of a small European country nowadays, but that power budget is being applied to potentially billions of computing networks. If you consider how much energy is required to power Facebook or Google, you might actually be getting a better deal there, or even if it's approximately the same deal, you can either put some hundreds of megawatts into a data center or a fleet of data centers. Or you can put the same hundreds of megawatts into mining Bitcoin in by extension all of these other chains, you might actually be doing the same amount of work in either case.
If anything, we're just making sure that Bitcoin is properly utilized instead of underutilized, which it's right now.
— GA:
Yeah, absolutely. And so you've shared examples with some of your work on appchains. One of them being an example of Facebook and people being able to potentially mine their own chains in a similar way that you might control who's posting on your wall or your feed. Could you walk us through this example? And also maybe if you could focus on that mental equation that you were just describing around that security versus cost trade off and how we might reason about it as someone who's either a developer or an end user and interested in how this might work.
— JN:
Yeah, sure thing. So I've said in the past this crazy radical idea that your Facebook wall might be its own blockchain. Let me unpack that. Back in the day, there was this social network called Diaspora. It was made as a response to the rise of Facebook and MySpace before it, where instead of having to trust a single entity withholding everybody's data, anyone can spin up their own pod that would just store their posts and that would federate with other people's pods, like your friends' pods and synchronize state that way.
I guess you could say the spiritual successor of Diaspora is Mastodon today. It kind of operates under the same principles. Anyone can run their own instance of Mastodon. Mastodon instances can federate with each other so that you can see an aggregate view of not only your Mastodon instance, but also your federated peers instances as well. In a similar vein but a completely parallel effort is Tim Berners-Lee's notion of Solid, where everyone can host their own data in their own solid server. There's been similar approaches to that, like tent.io, sandstorm.io. Those are a bit more obscure. I think some of them might be defunct by now.
But the core design principle of these systems in contrast with other social media is that you're expected to run your own web server and that web server's responsible for holding your own state, your own posts, your own pictures. And there's some way by which you can view everyone's, all of your friends' photos and pictures this way.
Taken through that lens, the key insight here is that the way in which the Stacks blockchain is designed is meant to supplant the need for web servers. If you look at how today, when you write a smart contract on the Stacks blockchain, and this is a deliberate design decision, you have a list of public functions in your smart contract. Now, those are mainly meant so that other smart contracts can call into your contract and you can compose smart contracts, but the real cool case from my perspective through this lens is that those public functions are also invokable in a read only fashion through the HTTP interface of the Stacks node. So what we've done is we've made it so your smart contract is also a CGI script. So that being said, it's a small little program that if you're building a web server, it's a program the web server runs to generate a webpage. And if you're sharing a web server, back in the '90s, this is pretty common. You might have your own home directory, you might have your own CGI scripts. So if you load up your homepage, your CGI scripts run, they generate the webpage, the people actually see, and you can have dynamic content that way.
By making it so smart contracts are also serving the same role as a CGI script, we've made it so the Stacks blockchain is a lot like a shared web server. In fact, it's exactly like a shared web server, it's just that instead of being a web server running under a single administrative domain, it's a replicated web server. Everyone can run a copy of it. They all stay in sync. There's a token in place that financially incentivizes miners to add new CGI scripts and process global state changes by means of mining transactions. So what that means is that the Stacks blockchain is also the Stacks web server at the same time. They're just dual roles here.
"By making it so smart contracts are also serving the same role as a CGI script, we've made it so the Stacks blockchain is a lot like a shared web server. In fact, it's exactly like a shared web server, it's just that instead of being a web server running under a single administrative domain, it's a replicated web server. Everyone can run a copy of it."
In the realm of appchains, what that means is that every appchain is also like a web server. In fact, the scalability story of appchains is a lot like the scalability story of the web itself. Just like how the web itself grew from there being one or a handful of big iron web servers that handled the bulk of a load for a company's website. Nowadays it's a cloud. You have an elastic fleet of these cheap servers that you just link together and they handle an unbound amount of request load. Similarly, appchains are like the cloudification of blockchains, in that you just add more and more of these small blockchains together in a way that the amount of transaction capacity and aggregate can grow unbound. And each of these blockchains might be small by themselves, but they serve a very narrow use case in the greater context of the set of blockchains that exist.
So with that said is if I wanted to build Diaspora today, if I wanted to build Mastodon today, it would make a lot of sense if I had, instead of a single web server to host my content, I would have a Gaia hub and a personal blockchain, that simply maintained the state that people would see when they load it. If you want to mine blocks on my blockchain, or if you want to send transactions against my blockchain, that's still the act of sending transactions or mining the blockchain in a general sense, you spin up a node yourself, it runs a replica, you aggregate transactions people send, you mine blocks, et cetera, but now you don't have to worry about running a web server anymore.
See, the problem with trying to make everyone run web servers is that most people don't, and understandably -- why the hell would you. I don't run a server at home. It's a pain in the ass. And this is like my bread and butter. I have a PhD in computer science, I don’t run a web server because I hate it. But running a blockchain is really easy because as long as one person somewhere is running your node, you're fine. And you can't get locked into that one person running a node because you can spin up your own node at any given point in time and it will download and install and maintain a replica so that even if the person who is originally running it goes offline, your chain is still live.
So just like how Bitcoin has 100% uptime since it's creation because at any given point in time, there's a few thousand nodes running replicas, that would similarly be the case with any blockchain in the Stacks ecosystem as well. So you now have this fleet of web servers that are all always, always online until no one's using them. And if no one uses them, no one cares if they're offline.
So that's really like the far north star goal I have for the appchains capability solution. We fulfill the promise of these decentralized services that came before us where everybody runs their own web server, but we're no longer making you run your own web server and we're no longer requiring that web servers as an administrative point of control exist in that capacity. They exist simply as long as there exists one user who's interested in keeping them alive.
"We fulfill the promise of these decentralized services that came before us where everybody runs their own web server, but we're no longer making you run your own web server and we're no longer requiring that web servers as an administrative point of control exist in that capacity."
— GA:
Very cool. Would the cost of mining an appchain be somewhat under the control of the person that is essentially setting it up, or what would be the factors that would go into that?
— JN:
Sure. So the Stacks blockchain right now is an open membership blockchain. Anyone can mine. All it requires is sending a Bitcoin transaction. Part of the reason why the mining criteria for Stacks are really simple, in addition to the whole ethos that we want anyone to be able to mine, its open membership system, system can fork to route around problems, is also like we can't actually do anything more than that. The Bitcoin scripting language is very simple. It doesn't let you have really powerful decision making primitives on deciding who can mine and when.
But this is not true in Clarity. When you mine an appchain on top of the Stacks blockchain, what you're really doing is you're sending transactions and Stacks which store the same things that would've gone into Bitcoin, but you're routing them to the Stacks chain through a Clarity smart contract. And that smart contract can do things well beyond what Bitcoin script can do. So for example, if I'm running a private blockchain that just maintains my posts, I could make a mining contract that requires that only I can mine. So it wouldn't matter if anyone else sent a block commit transaction, they'd be unable to mine. The smart contract would just say, no. Thanks for the money, but no.
Similarly, I could say anyone can mine, but I have to sign off on it. So other people can mine, but I have to approve it, and by approving it, I allow you to have your coinbase. I can do something like, no forks are allowed. By that, I mean there's no such thing as an undo button, if you lose a block, your chain just stops. You can't make progress. I could also make it so that forks are allowed anywhere. And moreover, I can just delete a fork entirely. For example, if I wanted to nuke my social history or if I wanted to go back and edit my social history, that could be realized by having a mining contract that permits me, the owner of that contract to make changes retroactively.
So there's a huge design space here. If you can write it in Clarity, it can be done. And that would let you determine the conditions under which blocks get mined. And you can be really arbitrary about it. You can say, the first thousand blocks are, anyone can mine, but after that, it's just me, or I could do the opposite. The first thousand blocks are just me and then after that, anyone, or I could say only Elon Musk is allowed to mine my chain besides myself, or I could say, it's a free for all on Fridays, but other than that, it's just me. Whatever you want. If you can write it in Clarity, you can make it happen. You can make your mining rules happen.
"If you can write it in Clarity, you can make it happen. You can make your mining rules happen."
— GA:
Very cool. Thank you. Could you compare some appchains to other projects' scalability solutions? I think that there's different concepts -- Cosmos has parachains, Avalanche has subnets, here's different sharding approaches. What might be some of the differences?
— JN:
I can't speak to the first two because I'm just not familiar with them. I think I could speak perhaps to sharding or to off-chain roll-ups, which I guess are the two most superficially similar systems. In appchains each chain has its own token and its own security budget. I think that's perhaps the biggest difference. We don't try to implement something like a two way peg, which is kind of what a side chain or a drive chain, or some types of roll-ups implement. Largely because, I guess because I see these things as web servers or decentralized web servers, it doesn't matter too much to me that there are different tokens. There actually probably should be because the token fundamentally represents a permission to write transactions to a particular chain.
So naturally, chains that are popular should have different tokens so that the people who operate those chains can realize the value that they have brought to the system by making it popular. It doesn't bother me at all. To some people that's a huge turnoff, to some people, the history of trying to do scalability systems like this, it matters a lot to these people that there's only one token and that token is manifest on both of these chains and that it's zero sum. You can't just mint more of the token. I don't care. There should be as many tokens as there needs to be. And that is the biggest contrast to off-chain roll-ups and side chains and drive chains and extension blocks, which is a Bitcoin thing that came and went. Appchains have their own tokens and that's okay.
To speak to sharding, the biggest difference between appchains and sharding, besides the multitude of tokens versus being a single token is that every sharding approach I've seen has this unfortunate property whereby if a shard breaks, suppose the nodes mining that shard all die, or the shard loses some data somehow, regardless of how that happens, it can happen. And it can be made to happen by somebody who really wants it to happen, who wants to just break the chain. It's not clear how the system recovers from that.
One of the promises of shard blockchain designs is that you could have a smart contract on shard A and it can do stuff, and shard B can access that smart contract and so can shard C. I can trade tokens that interact with contracts across all of these shards. And somehow it's supposed to work out. Somehow the state of shards A, B and C is supposed to stay in sync somehow. The people who build these systems, I've maybe just not seen the right documents for it, but they don't really have a good answer for what happens when shard A dies, or what happens when shard A gets reorged. If I have state on shard B and C that was dependent on shard A, does it get reverted somehow, or do we now have this causal inconsistency across the shards when a shard dies and you can't prove that the tokens that I traded on shard A, for tokens on shard B, should that trade still have gone through now that shard A is dead? It's unknown. Some approaches try to solve this by routing cross shard operations through a beacon chain or some central chain, but the problem with that is that then any cross shard operations are now bound by how fast they can go to the beacon chain, which is not very fast at all because as I mentioned earlier, blockchains can't scale. They don't scale.
So instead of trying to deal with that failure recovery problem, by making it so appchains have their own tokens and their own transactions, and just basically punting on this idea of there being cross appchain interactions in a seamless manner, we sidestep this problem altogether. If I have an appchain and it dies, no other appchain cares, it's fine. They're meant to come and go. Just like how, if on the web today, one web server dies, the rest of the web keeps on chugging without it and it doesn't matter. Maybe links break, but again, that's not really a show stopping problem to the web.
That said though, there's still space in the appchain design for things like cross appchain atomic swaps, just like there was space in blockchains today for cross chain atomic swaps. And that would be the way by which you have appchain to appchain interactions. Similarly because appchains have PoX, anything that you might do with Stacks and Bitcoin, like having custodian-less Bitcoin on Stacks, you could similarly have custodian-less Stacks on the appchain. So you might have this hierarchical integration whereby appchains can react to transactions on their host chains.
And similarly, the transactions that are permitted on the host chain to mine blocks are subject to prior state of the appchain just like how valid Bitcoin transactions that my Stacks blocks depend on the reward set in the Stacks chain today. So those types of hierarchical interactions are permitted in the same way that they're permitted today with Stacks and Bitcoin. But unlike the sharded designs, we don't care if appchains die, just like how Bitcoin doesn't care if Stacks dies or doesn't care that Stacks exist. Stacks doesn't care if appchains exist at all.
— GA:
Thank you. And so you just mentioned an area where further development could be made. I'm curious if there are any limitations or things that folks should keep in mind when approaching appchains?
— JN:
Sure. So just the web server analogy I think is still helpful here. If you have a web server yourself and you're trying to make it interact with state on someone else's web server, you're going to have to go out of your way to make that happen. There's nothing intrinsic to NGINX or Apache that makes it so that a database write will be replicated on somebody else's web server. You'd have to get the permission to do it. You'd have to set up some synchronization protocol behind the scenes. And that's all very explicit. That's something that's not the web server's problem.
I think that's very similar to appchains. If you want to make a smart contract on one appchain that takes actions to smart contracts that on other appchains, you're going to have some sort of relay mechanism to make that happen. And that's honestly okay. Anything that you might use to make that happen today between blockchains, if you want to trade for example, Ethereum for Solana, you would need an exchange. There has to be some intermediary that allows that trade to manifest on both chains. And that's largely how you would make inter-appchain interactions happen as well. That said though, we do have some strategies we can employ because all appchains behave the same way. They all support clarity. So if there exists a way at all, by which two appchains can interact, then that mechanism can be applied to all the appchains in existence.
I have a write up on one way in which I think subnets might go, that might address this problem. If you think of a subnet as a super lightning channel, whereby you have a bunch of users with a bunch of tokens locked up and then interacting through an off-chain relay mechanism, whereby eventually they may want to exit and in doing so, settle their balances by leaving the subnet, you might have something like that for appchains. You might even make it so that they're inter-appchain compatible just as long as you make sure that the act of exiting this super subnet ensures that the tokens that you're exiting with are sufficiently confirmed.
You'd look at the chain security budget to figure out how many confirmations you would need and everything should be fine unless someone's really trying to break the system, in which case you signed up for that risk in the first place. You could, for example, make it so that I might have a NFT chain, like I might have a StacksPunks chain at some point. And maybe I might want to trade a StacksPunks for a StacksPop, and that can be a separate chain. Now, if I know how much these two things are worth, for example, I could set up a protocol by which I lock my NFTs on both of these chains. There's a lightning tight mechanism that allows myself and other traders to exchange them offline. And later on I might exit by making it so that a StacksPunks that I did not own, I would now own. I could submit a proof to the StacksPunks chain that proves that I now own it, thanks to this off-chain interaction I've had. And likewise for the StacksPops.
What I would just need to make sure happens is if I know how expensive it is to reorg the StacksPunks chain or reorg the StacksPops chain, I would just make sure that the amount of money that I paid for those NFTs is less than the cost it would take to attack these chains before I would be allowed to exit on chain with my new NFTs.
— GA:
Cool. Thank you so much. You've mentioned this concept of 4.2 billion chains as the upper limit for appchains. Can you quantify and give us a little bit more of a mental picture around the extent to which appchains could scale transactions on Stacks and what the potential limits to transaction volume might be? I know it's in the proof of concept phase right now, but anything to keep in mind there?
— JN:
Sure. So, appchains are organized hierarchically. You have this notion of a host chain in the client chain, whereby this mining contract on the host chain allows miners of the client chain to submit block commits, and in doing so, build up a block history much like how miners of the Stacks chain use Bitcoin as the host chain for Stacks. So that said the Stacks chain has finite capacity like any other blockchain. So there's an upper limit on the number of appchains, like tier 1 appchains it could support, or degree one separation appchains, I think is what I call it in the doc.
Let's just say for sake of argument that's 10. It's probably more than 10. It's probably more like 100, but the point is it's not that big, but that doesn't really matter at the end of the day, because each of those 10 chains, if they have the same block limit as the Stacks chain, can host 10 more chains. Let's do some math here. If there's 10 chains, then that'll give you 100 chains right there. And then after that there could be 1,000 tier three chains, 10,000 tier four chains. You can support exponentially more chains, the further degrees of separation you are from Bitcoin.
That said though, even in the appchains proof of concept, you can change the block size of your appchain to be different from that of Stacks. Like in the demo one that I have running right now, it's twice as big. So maybe there could be a tier two appchain that can support 1,000 tier three appchains. And that could be fine. I actually think that at the end of the day, all of the chains that are not at the highest tier, are going to be responsible mainly for hosting chains. And that's totally fine. There might even be ones that are designed specifically to make it easy to host. There can be one that has a bigger block size specifically because it's optimized for hosting.
So anyway, the number of degrees of separation between Bitcoin and your appchain is going to just grow logarithmically in the total number of appchains. So if there's 4.2 billion appchains, there might only be nine degrees of separation between you and Bitcoin, if you're at the periphery here. And that's something that you could build a light client for, that's something that you could make relatively straightforward and relatively painless from a compute resources standpoint to use an SPV like protocol to verify that all of the chains that link your appchain to the Bitcoin chain are in sync. And you can calculate that economic budget I mentioned earlier, how costly it would be to attack any of these chains linking your chain to the Bitcoin chain.
And that in turn would inform you how many confirmations you need to wait to safely transact on your appchain. And that could be done without you even needing to run nodes for all of these intermediate chains. But even for whatever reason you did need to, that's still only a logarithmic number of chains you would have to run nodes for out of the entire set of appchains that exist. And that's really where the scalability comes from. You're on the right side of the exponent here.
— GA:
Thank you. As we're continuing to build on this concept of appchains and as folks play around with them more, there's just going to be a lot more excitement. Are there any things that we might look out for from the user experience perspective when considering a multi-chain world? I'm curious about your thoughts in terms of how this might play out.
— JN:
Sure. So, because each appchain also uses the Stacks chains protocols, the act of making a transaction for an appchain is no different really than making a transaction on the Stacks chain. The only thing you change is the chain ID field of the transaction, which is relatively straightforward to do. I haven't tried this on a ledger yet, but I would imagine that if a ledger app does not support sending transactions in the stack on appchains, it could be made to do so relatively easily, because again, you're just changing the chain ID. If you're building a wallet for the Stacks chain, it could easily be ported to an appchain by the same mechanism. You just make sure to use the right chain ID. I'm pretty sure a block explorer would just work unmodified because the event protocol that the Stacks node uses to propagate events to the block explorer is unchanged.
That's a feature. Appchains are meant to be as close to the behavior of the Stacks chain as possible. So if you get a developer tool or a user facing tool working on the Stacks chain, it should just work automatically with minimal modification on an appchain. That's meant to be a power multiplier. I want appchains to be very similar to the Stacks chain for this very reason.
The active instantiating and appchain is really easy. You just download and install the Stacks blockchain code base, and then there's a new command for running the Stacks node as an appchain. You write your mining contract, you deploy your mining contract. You can add custom boot code to your appchain so that you have some smart contracts that are specific to your app built in from the get go. And as long as you're running one seed node, which is something relatively straightforward to do, then you're just good to go after that.
"Appchains are meant to be as close to the behavior of the Stacks chain as possible. So if you get a developer tool or a user facing tool working on the Stacks chain, it should just work automatically with minimal modification on an appchain. That's meant to be a power multiplier."
People can spin up and run their own appchain nodes that will run replicas of your appchain. I've already seen this happen for the MVP that I have. There's at least one other appchain node out there talking to my seed node that I set up. And that's really cool to see. It shows that it's really just as painless as we have thought it would be. So for user tooling, making it so that your Gaia hubs, your BNS, name resolvers, all that tooling can just work automatically with appchains, same with wallets. There will be some work required to make all of Hiro’s tooling work with appchains, but it should be pretty small.
— GA:
Perfect. Thank you. And so what are the next steps in developing appchains? Is there a way that you'd prefer that folks give it a try or get involved?
— JN:
So like the MVP is meant to be that. It's a relatively painless way to start mining or start running a node. One thing I would love to do, if I can find the time to do it, is build a real app with an appchain, besides just having the chain running.
One concept I've been toying with is trying to build something like a subreddit on an appchain. Maybe it could be like the toy example I've shared around with a few engineers is this idea of there being a meme chain. What you would do is you could mine memes by making it so that the act of submitting a transaction is the act of attaching a meme to it, like just a URL to a meme sitting in a Gaia hub somewhere. And the act of your transaction getting picked up - and you would pay a transaction fee for this, but the act of it being picked up would give you a reward slot in the appchains PoX. So miners are mining memes and they're mining high quality memes because they want people to participate in the meming. And the people who submit the high quality memes end up getting a payout in the base token.
— GA:
That would be awesome. I would love to see this come to life. So we'll point people to your GitHub, to the MVP that's out there. Are there any other closing thoughts you'd like to share?
— JN:
Just remember blockchain don't scale. So if you ended up giving money to someone who claims blockchains can scale, I'm sorry, but you're not getting it back. You were the mark. That's okay. We've all been there. Blockchains don't scale.
The way in which we make sure that there's enough blockchain for everyone is to make more blockchains.
— GA:
Okay. All right. Thank you so much, Jude! If you enjoyed this chat, definitely make sure you're subscribed to the Hiro YouTube channel. Thank you so much.
