Defining the Current Catscape
Now, to fully appreciate why atomic swaps are an interesting concept, it helps to first take a quick look at the current landscape of decentralized applications, smart contracts, and tokens.
If you take a microscope to decentralized applications (or DApps) you’ll quickly find that they are quite similar to the applications we all know and use today. In that, DApps and apps alike are both made up of similar bits of code that exist solely to react to real world events and user interaction in ways that are entirely pre-specified.
Often, the process of incepting either type of application is indistinguishable. Let’s say you have an application which allows known cat food manufacturers to bargain for its supply. In either application framework, there exists a similar set of logic constraints that are requisite in order to fulfill the tasks demand. Simply, this particular task requires predefined rule-sets for creating and distributing invoices, and creating and distributing supply-chain information.
In a traditional application, app developers simply organize these bits of logic into a few software packages and then host those packages on centrally controlled servers. When creating these types of centralized applications, it is common to end up with admin-defined access-controls. In a lot of cases, this pattern of central control allows for significantly higher throughput and permissions granularity than its decentralized counterpart.
So what of a decentralized application, then?
Decentralized applications would start with the same idea (to create a cat food manufacturing application) but after iterating through a similar development cycle, they deploy it into a decentralized context. However, the implications of this extend beyond the “where” the application is deployed — in decentralized contexts the important part becomes how the code can be interfaced with in this unconfined digital frontier.
Unlike centralized applications, DApps are intrinsically more accessible. In that, decentralized architectures expose environments that grant more fluent accessibility to third-party cats who also happen to be building in this new frontier (note: DApps are often permissionless, but this is not a constraint). That said, the more interesting aspect of DApp environments is that every application therein has a massively increased potential for composability. Figuring out how to harness this composability is often not obvious, but when done right it can unlock things not possible in their centralized counterparts.
When this power is wielded appropriately, it can be the cornerstone for other cat-repeneurs to create complimentary, yet independent, applications that result in mutual benefits for the entire cat ecosystem (such as a catnip dispensing smart contract that is triggered whenever the order book sees an influx of sales)!
Permissionless flavored composability is powerful — and understanding it will be important to the rest of this story.
Tokens and Smart Contracts
If you haven’t read my latest posts summarizing smart contracts, it’s a good place to get started. As a brief summary, smart contracts are a sub-technology of blockchain and decentralized applications. They operate based on financial-type inputs and execute on contract-like agreements.
Side note- A popular use of smart contracts for cats might be a catnip dispenser which, whenever the smart contract is fed 1 cat coin, a single bag of catnip is released.
Now that we’re on the topic of tokens, let’s make sure we understand some important points. Tokens, at least as they have been designed over the past few years, are often just smart contracts in and of themselves. Moreover, token contracts are consolidated ledgers of balances that can be updated when sent an initiating transaction.
Now, let me reiterate that last point, as this is extremely important to understand: most tokens will only ever exist within the context of their own smart contract. Tokens are consolidated to their own context.
This means that when you “transfer” one token from your account and to another (or to a Dapp’s smart contract), you are never actually sending it anywhere. Instead, the token stays within its own contract, only to update its internal ledger. Again, most tokens do not ever leave their contract’s context.
Did you catch that? No? One more time:
This is an issue. Decentralized applications are powerful because of their ability to be composable and to interact with other contexts, and so when we design them in a way that does not support this, we end up with a lot of wasted potential.
Now, you might be saying “wait. . . there are tons of tokens, and tons of decentralized applications that can use these tokens!”, and technically, that’s true. Most tokens can still be used with other smart contracts, even though they are self-contained. However, such interactions are neither fluent nor natural.
For the common cat, an example might help. By a large margin, the most common token standard is the ERC-20 token (but the same can be said for other token types such as ERC-223), and chances are, if you hear someone talking about a token, they are probably referring to this type. These tokens can be used in DApps in the following way:
- Start by “transfering” a token to a smart contract. This effectively increments the DApps token balance, but does not actually send the token from the token contract to the DApps contract.
- Interact with the DApp contract by sending another transaction to it using Ether along with the data associated with the function you want to trigger.
- The DApp contract checks the token contract’s ledger to see if it has a valid balance to perform the action
- If the balance is valid, it performs the action on the token. If not, it fails.
- When the user has finished interacting with the DApp they can proceed to “withdraw” their token. Doing such decrements the dapps balance and increments the users.
I assert the following: this is ridiculous AF. Step 2 means that the application will always require the cat to make two independent and manual transactions.
But all is not lost! An improved approach to token designs does already exist (and more have been proposed since).