3 posts tagged with "bch"

The previous blog post provided a very high-level overview of the Web 3 Cash Stack architecture. This article descends into various implementations of that architecture that I, and other decentralized members of the PSF, are in the process of standing up.

If the images appear too small to read the text, click on them to open a larger version of the image.

While it looks lot busier, the image above has all all the same features as the simplified Web 3 diagram in the previous blog post. It's easier to describe how all the pieces fit together by walking through the three main layers of infrastructure:

• Global Back End Software
• Local Back End Software
• Front End Software

Global Back End​

The global back end is the part of the software stack that has changed the least. While the original Cash Stack has had steady improvements, it's basic architecture has changed very little in the last three years. What has changed is the emphasis on software further up the stack that interfaces with it, and putting the JSON RPC over IPFS on equal footing with the conventional REST API.

Whereas the focus has been on bch-api in the past, there is a new focus on the ipfs-bch-wallet-service as the primary way to interface with the back end infrastructure. bch-api, our Web 2.0 workhorse, isn't going anywhere. It's flexible and high-resolution REST API interface will always be preferred for Web 2.0 companies and exchanges. ipfs-bch-wallet-service compliements bch-api by simplifying the API to a few endpoints that are needed for common wallet use cases. It also provides this API over two interfaces:

• REST API over HTTP
• JSON RPC over IPFS

The JSON RPC over IPFS is what unlocks the real power of web3. Because IPFS automatically handles the networking and easily penetrates firewalls, the global back end software can use consumer hard drives, in normal desktop computers, using home internet connections. This directly competes with the cloud infrastructure needed by Web 2.0 apps, and drastically lowers costs. It also makes it easier for web3 community members to support one another, and improves decentralization.

In the image, two PSF servers are called out by their ipfs-coord names:

• bch-wallet-service-US-PDX
• bch-wallet-service-west-coast-canada

There are more than these two servers on the network, and more will be added in the future thanks to PSF bounties. Because these back end servers are interchangeable, the software higher up in the stack can choose one-of-many in order to achieve its goals. They all connect to a common 'bus', which is a subnetwork on IPFS, created by the ipfs-coord library.

The JSON RPC over IPFS interface lowers costs, improves decentralization, and improves reliability.

Local Back End​

The concept of a 'local' back end is a new concept introduced in the web3 Cash Stack architecture, and it's largely encompassed by a single piece of software: ipfs-bch-wallet-consumer. This is the mirror image of ipfs-bch-wallet-service.

Compared to the Global Back End, ipfs-bch-wallet-consumer is a very 'light' piece of software. It can run comfortably on low-power computing devices, like the Pi 400, with a minimal internet connection.

Eventually, ipfs-bch-wallet-consumer will automatically find and connect to the lowest-latency wallet service it can find on the IPFS network. All communication between the two pieces of software is end-to-end encrypted.

ipfs-bch-wallet-consumer provides a convenient, local REST API interface for programmers to develop against. This allows experienced Web 2.0 developers to leverage IPFS without needing to know anything about it or changing their workflow in any way. This single REST API interface is the only 'back end' software a front end developer needs to run.

An instance of ipfs-bch-wallet-consumer is made available as a public API at free-bch.FullStack.cash. This allows public access to the BCH blockchain for phone apps, random web apps, and the psf-bch-wallet command line wallet.

Front End​

The Web 3 Cash Stack article introduced four types of use cases:

• Exchanges/Companies
• Casual Users
• Hobby Developers
• Censored Users

Those four use cases are represented by the four front end software instances in the image below.

wallet.fullstack.cash is a great example of a Web 2.0 app that an Exchange or Company might build. It follows all the Web 2.0 best practices for scaling and a good user experience. This app connects to a cloud-hosted instance of ipfs-bch-wallet-consumer which in-turn connects to a dedicated instance of ipfs-bch-wallet-service. The use of IPFS in this case is superfluous to normal operation, but it does provide a way to 'fall-back' to the community infrastructure in an emergency. A form of 'failing gracefully'.

Up to this point, the PSF has not offered an Android or iOS version of wallet.fullstack.cash because the cloud infrastructure cost is much more expensive. Freeloaders of the REST API service can be avoided in the web app, but not in the phone app. But that is no longer a significant burden with this new architecture.

The phone app represents the 'Casual User' use case. An Android APK file will be offered soon that can be side-loaded to a phone. It will connect to free-bch.fullstack.cash for it's back end infrastructure. That server will load-balance connections between community 'global back ends'. The UX and performance of the app will depend on the community that supports it, and the burden will not be born by a single individual or company.

psf-bch-wallet is a command-line wallet app for Hobby Developers. Because it does not have a graphical user interface, it's much faster and easier to prototype new ideas and compose 'exotic' transactions. This app can connect to free-bch.fullstack.cash for it's back end, but is most flexible when using a local instance of ipfs-bch-wallet-consumer. It has commands to control the IPFS node inside ipfs-bch-wallet-consumer, to make it switch between different back end services. It gives the user complete control over their network connection.

gatsby-ipfs-web-wallet will soon be getting renamed to gatsby-ipfs-bch-wallet. This will be our IPFS-first wallet. The concept of IPFS-first is taken from the 'mobile-first' design philosophy, which took the emphasis off of desktops and moved it to smart phones. In the same way, IPFS-first takes the emphasis off the centralized REST API over HTTP, and moves it to the decentralized JSON RPC over IPFS.

This web wallet will be loaded from Filecoin, and be accessible from any IPFS-gateway, just like this blognp. It will load an IPFS node within the browser-based app, and connect to an instance of ipfs-bch-wallet-serverice directly. Because the app is so self-contained within IPFS, it will be difficult if not impossible to censor. It will be slower than wallet.fullstack.cash, but it should provide wallet accessibility to people in repressive countries that actively try to block their citizens from accessing the blockchain. This will cator to the Censored User use case.

There are many interpretations of Web 3, but a common thread in all of them is an emphasis on re-decentralizing the web. Web 1.0 was very decentralized. Web 2.0 was centralized. Web 3.0 will be re-decentralized.

In early 2021, I started to earnestly dig into the inner workings of IPFS, to answer one burning question: "What is the best way to decentralized back-end infrastructure?"

This blog is an example of a decentralized front-end app, delivered over IPFS, hosted on the Filecoin blockchain. That's great for a blog or a publisher. But to do really sophisticated business applications requires censorship-resistant access to databases, blockchains, and other back-end infrastructure. IPFS API was my first attempt to conceptualize how to wire back-end infrastructure over IPFS. Over the last year I've developed, configured, and re-configured the code and networking behind the Cash Stack in an attempt to find the best configuration.

This blog post summarizes my findings. It's my attempt to describe the path before me, the path I think that lies before the entire blockchain industry. Censorship is coming, and only the decentralized projects will survive. The Use Cases and software architecture in this post provide a map for projects to build a durable foundation of infrastructure.

Use Cases​

Before discussing the How, let me present the Why. I was trained to always remember the 'User Story' or the 'Use Case'. Why am I building what I'm building? What problem is it trying to solve? That's what the Use Case captures. Users that want to access blockchain infrastructure can be categorized into one of the following use cases:

Casual Users:​

• Familiar with installing a phone app or visiting a web page, but no significant technical knowledge.
• Web 2.0 is the most efficient for this. Latency and connectivity issues of IPFS are not appropriate.
• Not willing to pay money for service. Might be willing to sign up for an account, but would prefer not to.

Exchange or professional company:​

• Has money to spend on infrastructure.
• Needs isolated (not shared) infrastructure.
• Needs high-speed, cloud-based infrastructure. Expects the speed and good UX of Web 2.0.

Hobby Developers:​

• Does not have a lot of money to spend on infrastructure.
• May or may not have the ability to run their own full node and other back end infrastructure.
• Important to support because this is where a lot of innovation comes from.

Censored Users:​

• Lives in a country, or working within a company, that is actively trying to prevent them from accessing the blockchain.
• This user wants to circumvent the censorship and is willing to jump through more hoops than the Casual User.
• Not willing to pay money for service. Might be willing to sign up for an account, but would prefer not to.

Network Architecture​

Based on my research over the course of 2021, I will discuss different configurations of the Cash Stack. The first configuration uses strictly Web 2.0 principles. The other configuration blends in components that involve IPFS. Which configuration is appropriate, depends on the Use Case being considered.

Web 2.0​

Below is the 'Web 2.0' version described in this Cash Stack post. The centralized architecture is far more efficient and scalable than any 'Web 3.0' or decentralized architecture. It gave birth to the Saas Business Model. As far as blockchain is concerned, this architecture is the most appropriate for the Exchange use case. If there is an Exchange (or company) willing to pay the bills, they can financially sustain the preferred user experience (UX) of the Casual User use case.

The achilles heel of this model is censorship. It's fragile in the face of any censorship. There are well-established industry best practices for censoring this architecture. This architecture is not appropriate for the Censored User use case.

This architecture is also expensive. It's not practical to run this architecture from a home server. Cloud infrastructure is required in all but the most exceptional of cases. Cloud infrastructure has a monthly cost. Stop paying and the infrastructure disappears like smoke. Hobby Developers may be able to run this infrastructure at home, but they can not break out of the hobby-category without funding.

Web 3.0​

The Web 3.0 Cash Stack inserts two new blocks into the middle of the stack, which are mirror images of one another:

• IPFS Service Provider - Proxies the REST API over IPFS.
• IPFS Service Consumer - Proxies IPFS communication to a 'local' REST API.

By adding these two new pieces of software, it decouples the expensive 'global' back end infrastructure, and proxies it to a much less expensive 'local' back end REST API. This has several advantages:

• Because IPFS automatically handles the complex networking, it's much more pragmatic to run the expensive global back end infrastructure from a home internet connection. This reduces the greatest cost of the Web 2.0 model.
  
  
• By leveraging Circuit Relays, this architecture is extremely resistant to attempts at censorship.
  
  
• Because of the decoupling, the local back end is capable of using one-of-many instances of the global back end. It only needs to connect to one in order to succeed, and it can choose any instance on the network.

If implemented correctly, the performance should be acceptable to the Casual User use case. The extra layers adds some latency, but it provides much lower cost. Weather this architecture is appropriate for the Casual User use case depends on the specific application, but the trade-offs may be acceptable. If there is no company to pay for web 2.0 architecture, this web 3.0 architecture may be the only financially practical way to roll out an app for Casual Users.

This architecture really exceeds at the Hobby Developer and Censored User use cases. It should be noted that the 'local' REST API can be embedded entirely in a web browser. This allows Censored Users the convenience of loading an IPFS-based web page in their browser, to achieve the ability to circumvent whatever actor is attempting to censor them.

This is the most flexible architecture for the Hobby Developer. Developers unfamiliar with running back end infrastructure, who want to focus primarily on front end applications, can run a single, simple app to provide the local back end. Developers more comfortable with Dev Ops and running back end infrastructure, can provide the global back end infrastructure to the rest of the community, from the comfort (and cost-savings) of their own home. The Permissionless Software Foundation is offering Bounties to incentivize hobby developers to run this global back end infrastructure.

Software​

The descriptions above are abstract. This section is for developers that want to know the specific software implementing the architecture. The software running the Web 2.0 architecture is documented in this Cash Stack post. Here is the new software implementing the Web 3.0 architecture:

• ipfs-bch-wallet-service sits at the top of the global back end. It connects to bch-api, or to the infrastructure at FullStack.cash, and it proxies it over IPFS using a JSON RPC interface.
  
  
• ipfs-bch-wallet-consumer is the mirror image of ipfs-bch-wallet-service. They communicate over IPFS, and ipfs-bch-wallet-consumer provides local REST API endpoints for the front end to interact with.
  
  
• ipfs-coord is a core library used by both of the above software projects. This allows IPFS nodes to find one another, circumvent firewalls, stay connected, and communicate securely.
  
  
• minimal-slp-wallet is a JavaScript library that provides basic Bitcoin Cash wallet functionality. It can interface with a local instance of ipfs-bch-wallet-consumer via its REST API. This library is used by gatsby-theme-bch-wallet which you can interact with at wallet.fullstack.cash.

This is a fictional story about Bob and some software he set out to create. Bob is a libertarian. He loves gun culture and responsible gun ownership. He likes to drink unpasteurized milk. He's also a bachelor and would like to strike up a romantic relationship with someone in his local area.

Bob used to love the site Craigslist.org. He used to be able to trade guns, buy unpasturized milk, and peruse personal ads, but now he can’t do any of those things, because Craigslist removed them in order to comply with laws and veiled threats from the State. Bob would like to build a site just like Craigslist, but one that leverages decentralized technology, so that it doesn’t have any single point of failure for the State to shut down.

Bob is a competent software developer, but building a decentralized replacement to Craigslist is going to be a big undertaking. He doesn’t know how big, but feels pretty confident that he’s going to need help. He realizes he’s going to need to find other people like him. He needs to form a community that cares about the same thing he cares about.

Bob discovers the Permissionless Software Foundation, the PSF token, and the token-liquidity app that pegs the PSF token to BCH. He creates his own SLP token. Since he’s making a project for decentralized ads, he calls it the DAD token for Decentralized ADs.

Bob saw the crazy growth around the Spice token and other tipping tokens. He thinks that having a tipping token would be a great way to grow a community around his software idea. But he wants his token to have some kind of financial value, so that people take it seriously. He’s also fond of the PSF community and wants his token and community to be attached to this larger, like-minded community.

Bob decides to fork the token-liquidity app and use it to peg his DAD token to the PSF token with it. He’s talked to several members of the PSF that want to support his idea. They are willing to collectively stake $1,000 worth of PSF tokens to help him launch his idea. Armed with a seed fund of PSF tokens and a fork of the token-liquidity app, he adjusts the equations so that the initial value of his DAD token is $0.01 per token.

Bob is really happy with this setup. His token has a low price and low transaction fees, which makes it work great as a tipping token. It’s also loosely pegged to the PSF token, which means his project is financially connected to the bigger PSF community and even bigger cryptocurrency community. But the peg is pretty loose, so Bob and any other contributors have the potential to realize a lot of upside if their project is successful.

Bob goes about coding up his idea. He spends weeks working on it and gets a clunky proof-of-concept app up. He shows it off to the PSF community and talks about it to other cryptocurrency developers whenever he gets the chance.

Through these efforts, Alice learns about Bob’s project. She has her own reasons for wanting a decentralized clone of Craigslist, and starts contributing code to the DAD project, which benefits her own goals with the software. Bob is really happy to get high-quality code contributions from Alice. He tips her in the DAD token every time he merges a pull request. There is no formal agreement. Alice isn’t contributing code with the expectation of being paid. Bob is just tipping whatever he feels is appropriate, based on his own perceived value and what he thinks the project can afford.

Time goes on. Because of the partnership between the DAD project and PSF, the communities grow together. More developers like Alice join the project. Eventually the project improves the software to a point where it has a steady stream of users. Whenever a user places an advertisement on the platform, they pay some BCH, which goes to burn DAD tokens.

Bob runs his own site using the DAD technology, focusing on guns, unpasturized milk, and personal ads in his own state. Alice runs her own site using DAD technology, which focuses on trading cryptocurrencies. Other people run their own web apps leveraging the DAD technology, but they all have the DAD project in common.

The price of the DAD token starts to increase. At some point Bob starts to worry about the amount of money behind the token, and is concerned that he’s the only person holding the minting baton for making more DAD tokens. He reaches out to the PSF for help. The PSF helps him move the minting baton to a multisignature wallet, so that minting new tokens requires agreement of three-of-five of the top contributors to the DAD project. They also set up a multisignature ‘war-chest’ wallet to protect excess funds, so that all of the DAD project funds are not only in their token-liquidity app.

Bob feels a lot better. He’s found a way to share responsibility and liability with other top contributors that he’s built trust with. If the State decides to pick on Bob, or he needs to leave the project, the DAD project and its funds are safe.

More time goes on. Bob needs to step away from the project for personal reasons. He’s still happy to participate in the community, but he needs to significantly reduce the amount of time he spends on the project. Alice is still making great commits to the project, and agrees to take on the title of ‘maintainer’. The title isn’t too important because all funds are protected by multisignature wallets. If Alice ever needs to step away from the project too, she can easily pass on the ‘maintainer’ title to the next best contributor.

There is a steady stream of new improvements to the project, but certain areas are lacking, like dev-ops, unit tests, and documentation. These areas of work are tedious, and not nearly as fun as developing new features. Alice and Bob agree to focus their time on creating bounties to shore up the areas of the project that need more attention. They create tightly-scope code-bounties with the intention of generating small, easily-reviewable pull requests. Each bounty is tagged with a reward of DAD tokens. Alice and Bob share responsibility for creating new code-bounties and doing code reviews. They agree that whoever takes on the management and merging of a bounty gets 20% of the bounty in DAD tokens, to make it worth their time.

More time goes by. The individual contributions of Alice and Bob are less and less important to the DAD project as a whole. They've each realized significant upside from their contributions, and can take pride in making the world a better place. The DAD project takes on a life of its own. It has it’s own management of top-contributors, who direct the DAD token to balance intrinsic contributions to the code base with extrinsically motivated work on automated testing, reliability, and documentation.