Building Web 3 Apps on Stacks
Introduction
The Internet as we know it today is broken. We have no power over our data and no native value settlement layer. Our data architectures are still based on the idea of stand-alone computers, where data is centrally stored and maintained on a server and sent or retrieved by a client, even though the Internet has been widely adopted for thirty years.
As learned in my previous article on What is Stacks?- A Beginner’s Guide, we know Decentralized blockchain technology is the solution to the problem. We also learned Bitcoin is the most secure and durable blockchain and Stacks make Bitcoin programmable.
The below picture depicts the present Internet era (Web2) vs.. the Decentralized Era (Web 3).
Crypto and Blockchain tech is complex, and there never existed an easy stack for application developers to build products for the user-owned internet. With ‘Stacks,’ anyone can build ‘Can’t Be Evil’ Web 3 apps with or without smart contracts.
In this blog, let’s learn all about building non-Defi user-focused Web3 apps on Stacks.
Note: Refer to my article “Understanding Clarity- The smart contract programming language” to learn about the native smart contracts used in Stacks.
The most significant advantage of the apps being built on Stacks is that they have zero friction, and an average person can use it without even knowing that it is a DApp(Decentralized Applications). Stacks make the blockchain programmable friendly for developers. Let’s dig deeper.
Traditional App Model Vs. Stacks Dapp model
For any application, there are always two main areas of focus as application developers.
- Identity management
- Storage management
App Model in traditional apps- Here, the developers have to maintain multiple layers.
Because of this structure in the traditional apps, the concerns are below from user and developer perspectives.
Whereas, in the Dapps built using Stacks, there are no such concerns at all.
Here there is no need for a separate database or userbase management. With the identity created on the blockchain, we can access all the apps within the ecosystem.
Now, let’s take a look at identity management in Stacks Blockchain.
Identity Management using Blockchain naming System (BNS)
We rely on naming systems in everyday life, and they play a critical role in many different applications. Be it a username, application name, or domain name; names play a key role. In the Stacks ecosystem, the naming/identity system is being managed by BNS.
Blockchain Naming System (BNS) is a network system that binds Stacks usernames to an off-chain state without relying on any central points of control. BNS is implemented through a smart contract loaded during the genesis block.
Names in BNS have three properties:
- Names are globally unique. The protocol does not allow name collisions, and all well-behaved nodes resolve a given name to the same state.
- Names are human-meaningful. Its creator chooses each name.
- Names are strongly owned. Only the name’s owner can change the state it resolves to. Specifically, a name is owned by one or more ECDSA private keys.
Now with the help of BNS, we can create identities such as test.id.stacks. Here, .stacks is called namespace(the top-level hierarchy of BNS system), followed by BNS names. In this case, it is .id. The last hierarchy is BNS subdomains, represented as a test here.
The important point to be noted here is that BNS namespaces and names are part of the blockchain consensus rules, whereas BNS subdomains are not part of the blockchain consensus rules.
To learn more about BNS, refer to the Stacks docs on BNS.
So, if subdomains are not part of consensus rules, how the off-chain name states are stored?
This is happening with the help of the Atlas network. Atlas is a part of BNS.
BNS allows each name to store a small amount of state — -on the order of 20 bytes. The size is so small because the state must be recorded to a public blockchain, where the cost per byte is high, and the blockchain protocol limits the size of transactions.
To compensate for this, Stacks developed an off-chain storage system that allows BNS names to bind and store a large number of states to each name in a way that preserves the security properties of having written that state to the blockchain.
Atlas's reference implementation currently allows up to 40kb of state to be bound to a BNS name instead of a measly 20 bytes. The 40kb of data is replicated to each BNS node, where it is stored forever.
Refer to the Stacks docs on Atlas to learn more.
So, with the help of BNS+Atlas, the identities are being managed efficiently in the Stacks blockchain. Now, let’s understand how Storage management is being handled.
Storage management using Gaia
Blockchains require consensus among large numbers of people so that they can be slow. Additionally, a blockchain is not designed to hold a lot of data. This means using a blockchain for every bit of data a user might write and store is expensive. For example, imagine if an application were storing every tweet in the chain.
The Stacks blockchain addresses performance problems using a layered approach.
- The base layer consists of the Stacks blockchain and the Blockchain Naming System (BNS). Here identities are created.
- Atlas — The identities correspond to routing data, and that is stored in Atlas Peer Network.
- Gaia Storage -Stacks uses the routing data to associate identities (domain names, user names, and application names) with a particular storage location in the Gaia Storage System's final layer.
Gaia Storage system
A Gaia Storage System consists of a hub service and storage resource on a cloud software provider. The storage provider can be any commercial provider such as Azure, DigitalOcean, Amazon EC2, etc.
When an identity is created, a corresponding data store is associated with that identity on Gaia. When a user logs into a dApp, the authentication process gives the application the URL of a Gaia hub, which then writes to storage on behalf of that user.
Applications will read/write data to the Gaia hub on behalf of a user (if and only if the user allows). The user himself can own the user Gaia hub or use the default storage space provided by Stacks. In Stacks default, a hub is used to store user data encrypted by the user’s public key. In this way, storage providers only see data blobs, not the data.
Understand Data Storage in Gaia
A Gaia hub stores the written data exactly as given. It offers minimal guarantees about the data. It does not ensure that data is validly formatted, contains valid signatures, or is encrypted. Rather, the design philosophy is that these concerns are client-side concerns.
Client libraries (such as Stacks.js) are capable of providing these guarantees. A liberal definition of the end-to-end principle guides this design decision.
When an application writes to a Gaia hub, an authentication token, key, and data are passed to the Gaia hub.
The token ensures the app has the authorization to write to the hub on the user’s behalf.
So, as an application developer, if a data crash happens at the application level, the developers have nothing to lose. From the user’s perspective, we are the owners of our data.
Now, let’s see how authentication works.
Authentication
An app and authenticator, such as the Stacks Wallet, communicate during the authentication flow by passing back and forth two tokens. The requesting app sends the authenticator a authRequest token. Once a user approves authentication, the authenticator responds to the app with a authResponse token.
These tokens are JSON Web Tokens, and they are passed via URL query strings.
The authenticator generates the app's private key from the user’s identity address private key and the app’s domain. The app private key serves three functions:
- It is used to create credentials that give the app access to a storage bucket in the user’s Gaia hub.
- It is used in the end-to-end encryption of files stored for the app in the user’s Gaia storage.
- It serves as a cryptographic secret that apps can use to perform other cryptographic functions.
Finally, the authenticator will always generate the same private key for a given Stacks address and domain during the authentication.
An important point to note here is that Users own the keys here, and the application developers have no clues to the password associated with a username. This way, it is more secure.
With this kind of structure, for application developers, there is no infrastructure cost and maintenance. This makes building ethical apps on Stacks much easier.
Examples of few Apps built on the Stacks blockchain
- BlockSurvey- Private and secure forms & surveys.
- Pravica — A new Era of Communication.
- Sigle — A decentralized blogging platform.
- Boom — A Wallet for STX and NFTs on Stacks 2.0.
Summary
Stacks ecosystem helps developers build an ethical web app, putting users in control of their identity and data. Data handling in the blockchain is a costly operation, and the more the data being stored, the more heavy the chain will be. Stacks addresses this issue with the help of 3 layers.
- The identity management is being managed by BNS smart contract in Stacks blockchain.
- The off-chain name state is being managed by a peer-to-peer network management Atlas.
- The Data is being handled in the Gaia storage.
Stacks helps application developers build ethical apps without worrying about scalability, data loss, or infrastructure costs with this structure.
At the same time, Stacks helps users to own their data and identity. Thus, Stacks is a perfect platform to build user-owned Internet.
Call-To-Action
Stacks ecosystem provides a dream toolset to build a new user-owned internet where “We as the Product” are becoming the “Owners of the future Internet”. There are already 300+ apps built on the Stacks blockchain. Let’s build a new user-owned Internet on Stacks!!
In the next blog of this series, let’s learn more about the native consensus algorithm of the Stacks blockchain “Proof Of Transfer”.
