When Brian Armstrong started Coinbase, he made a very contrarian decision: He bet that a centralized approach to building a crypto exchange would result in a better user experience in the short-run, and therefore outcompete more decentralized approaches. Today it seems obvious since you couldn't even build a decentralized exchange back then, but at the time it was heresy.
The decision to build a centralized crypto product was so contentious that Brian broke up with his first co-founder over it. In the long run, practicality tends to triumph, but in the short run it can be difficult to put aside ideology in favor of it.
Today, we are here to argue for a similarly-heretical viewpoint: We believe that most of the computation that smart contracts are built for today will happen off-chain in centralized but composable smart services, as we will describe them.
Blockchains will still be useful for storing assets and content, but we believe computation will move almost entirely off-chain. This is because smart services will allow web2 developers to build without having to learn any new programming languages, will allow native inter-chain communication and composability, and will scale much better than smart contracts. These benefits come at the expense of some centralization and trust compared to smart contracts, but we believe developers, and the market more broadly, will strongly prefer smart services to smart contracts in spite of this.
Smart Contracts are Hard
Today, if you want to write Web3 applications, most people in the space will tell you to write smart contracts. To write them, you won't just have to learn a new programming language, like Solidity or Rust, but you'll have to adapt to a whole new "event-driven" programming paradigm that is rife with gotchas. After you've learned how to write code and deal with all the gotchas, you still have to minimize storage because smart contract chains are not equipped with robust, cost-effective storage and indexing capabilities. And even then, once you have a working smart contract, it's limited to a single blockchain. An Ethereum smart contract can't directly call an Avalanche or Solana smart contract, and vice versa.
Smart contracts are really hard for most developers, and we think they've made the barrier to entry for getting into Web3 much higher than it needs to be. What's more, the lack of interoperability and composability across chains has further hindered what developers can build.
We call this new paradigm smart services, and we believe they will come to power the vast majority of Web3 applications, effectively replacing smart contracts as the dominant way for developers to build. Why? Because, as we will discuss, smart services do a much better job of maximizing developer accessibility, interoperability, composability, and scalability than smart contracts do.
On-Chain vs Off-Chain: The Epic Debate
Before going into the details behind smart services, it's important to note that, at a high level, smart services trade off decentralization and censorship-resistance for enhanced developer accessibility, cross-chain interoperability, composability, and scalability. This really hits on a more existential question for the blockchain space, which is:
When is it useful to use a blockchain vs doing things on a centralized web2 server?
As time wears on, more and more of crypto is starting to move off-chain. Even with NFTs, which are a recently-popular blockchain-based product, the image/video content is nearly always stored off-chain, and auctions are generally all done off-chain as well. But where will this trend lead us? For example, will Instagram one day host NFTs in a totally-centralized way, the same way they host images and videos today? We don't think so -- not quite at least.
Generally, as the future of Web3 unfolds, we think that assets and content will be stored on-chain, while computation will move off-chain, effectively rendering smart contracts far less useful than they are today. For example, we believe your tokens, your NFTs, and your social graph will benefit significantly from being on-chain. But computation-based services that allow you to lend, trade, stake, etc. will move off-chain into smart services. In light of this, there are a few reasons we believe blockchains will continue to be useful:
- Censorship-resistance. When assets and content are stored on a blockchain, no one company or app can freeze someone's assets or censor their voice. This seems to imply that users will prefer to have important assets like their tokens ultimately stored on a blockchain, even if they use smart services for computations like swaps, crowdsales, or loans.
- Portability. Although smart services can interoperate via Web2 APIs, putting your assets on a blockchain virtually guarantees that they will be accessible to you and to third-party developers forever. It also means that a token or post on one smart service will show up in all other smart services in much the same way assets like Bitcoin can move between cryptocurrency exchanges today.
- Overcoming regulatory constraints. By eliminating reliance on a centralized party entirely, blockchains can sometimes satisfy regulatory requirements that centralized services cannot. For example, issuing tokens or NFTs on a blockchain can provide extra protection against securities law concerns.
Given the above, one might reasonably ask: What will smart contracts remain useful for if a lotcomputation moves into off-chain smart services? Generally, we think smart contracts will be useful in defining new standards for assets and content, such as ERC-20 (tokens) or ERC-721 (NFTs). If you want to do something with an Ethereum token, for example, you will still hit an ERC-20 smart contract on the Ethereum blockchain to move assets around, even if the fancier computations are happening in your smart service. However, as time wears on, it is important to note that smart contract blockchains will start to compete with custom-built blockchains like DeSo that outperform smart contract implementations on efficiency. Thus, while smart contracts will likely remain useful vehicles for discovering new blockchain-based products, we think there is a significant risk that apps in need of high throughput will eventually shift their assets and content to blockchains that customize themselves to the scaling needs at hand.
What is a Smart Service?
Smart service might seem like a fancy term, but we're really just referring to a simple centralized web service that conforms to a certain set of basic constraints. These constraints, as we will discuss, allow for discoverability and interoperability between smart services regardless of which underlying blockchains they're tapping into. We list these constraints below. Any web service that satisfies the bullets below would count as a smart service, regardless of whether it's written as a NodeJS server or using a popular web framework like Django:
Concrete Example #1: A Token Swap Smart Service
The best way to understand the smart service framework is to walk through a couple of simple examples.
Imagine you want to implement a smart service that allows someone to deposit ETH and immediately have that ETH exchanged for DESO, and vice versa. Below is what this smart service would look like:
Once a smart service like this is defined, anyone can call it to swap ETH for DESO and vice versa. All you need is the domain name, desoethswapper.com, and then the /get-info call tells you how to use the service. Once you know how to use the service, you simply send funds with the appropriate metadata to one of the smart service's blockchain addresses, which you can get from the /get-address endpoint.
What's more, the behavior of a swapper smart service can be standardized to the point where any smart service that identifies itself as a swapper in its /get-info call can be composed with any other smart service. For example, anyone can spin up a Uniswap-like aggregator smart service that combines all the swapper smart services into a clean UI. Then, if you want to swap currency A for currency B, the Uniswap-like smart service can route your trades through whatever smart services clear your order the most efficiently.
Concrete Example #2: A Crowdsale Smart Service
Suppose you have an ERC-20 token that you've created, let's call it $MYDAO, that you want to sell in some clever fashion for DESO. That is, you want people to deposit DESO into your smart service and get $MYDAO coin out of it. What would such a smart service look like?
- trigger(metadata) would be called on each deposit, and would fulfill the user's purchase. Its logic would look as follows:
Clearly, arbitrarily complex crowdsales can be implemented by simply modifying the trigger( ) function. Moreover, these crowdsales can clearly span multiple blockchains, meaning that someone could raise money for their project using ETH, even if what they're selling is a DESO token, and vice versa.
Deploying Smart Services
Because smart services can be written and deployed in any language, there is technically no required way to deploy one. You can deploy a web service however you want, and as long as its API is accessible on the internet, other smart services will be able to discover and interoperate with it.
Such a platform can enforce that code that is deployed matches what is actually running in the smart service, yielding even stronger guarantees than smart contracts today, the majority of which are closed-source. Competition among smart service hosting providers should be highly-competitive and thus fairly decentralized in the long run in much the same way web2 hosting is today.
Concrete Example #3: An ERC-20 Smart Service
As discussed, because smart services are more centralized than smart contracts, we think they will initially be preferred for computation rather than assets and content. This means that an ERC-20 token may still be better off on a blockchain like Ethereum or DeSo (via DAO coins), since that would make the balances of its holders portable and censorship-resistant.
The above being said, just to highlight the power of smart services, we think it is important to note that even an ERC-20-like standard could be defined entirely as a smart service that implements standard token transfer functions as REST API endpoints (/total-supply, /balance-of, /allowance, /transfer, /approve, and /transfer-from).
If your smart service implemented this set of endpoints, your smart service could then integrate seamlessly into a Uniswap-like "aggregator" smart service to allow trading of your smart service's token. You could then plug the Web2 domain name of your smart service into the Uniswap smart service, and the Uniswap smart service would know how to call the standardized REST API endpoints of your smart service in order to enable trading.
Again, the Uniswap smart service would not be bound to a particular blockchain. It could theoretically allow trading across a diverse array of assets across chains in a totally agnostic way. Moreover, an ERC-20 that is defined entirely as a smart service would not be subject to high gas fees that ETH-based ERC-20 tokens are subject to.
A Note on Layer-2 Solutions
Smart services outperform smart contracts on developer accessibility, interoperability, composability, and scalability at the expense of centralization. We believe that this makes smart service much more appealing to developers, which makes it highly likely that the killer apps will start to be built on smart services going forward, rather than smart contracts. Once this starts to happen, we believe blockchains will be used predominantly to store assets and content with computation moving off-chain into smart services.