135
When programmable blockchain in the form of smart contracts first appeared on the scene it was not clear how they would be used. Accordingly the protocols and languages were designed to be general purpose and familiar. It wasn't yet clear that token creation and management would be at the heart of most dapps and so little or no specialized support for them was made available. Instead they followed the lead of most non-crypto financial software and managed assets with the notion of 'accounts'. This idea seemed like a natural fit for a blockchain ledger.
It turns out that managing accounts is tricky. To help make sure things work out OK the financial industry uses double entry accounting where every transaction is recorded in at least two ways so that checking logic can assure that the accounts remain balanced. A lot of smart contracts use this same approach, but things get tricky if state is managed by the smart contract since smart contracts are reentrant. To further improve resiliency some protocols introduce triple entry and even quadruple entry accounting into their systems. All of this extra logic means that coding projects mushroom in size which has the drawback of increasing the potential for subtle errors even if tens or hundreds of thousands of dollars are spent on independent code audits. The time and expense to create working code suggests that the underlying model is not particularly effective.
As the smart contract use cases became clearer over time some new ideas started emerging to make programs more reliable. A key idea is called "asset oriented programming" (which is also known as "resource oriented programming".) The idea was first featured in 2018 by the obscure 'flint' programming language out of Imperial College. Flint would make assets first class types that the compiler and runtime can reason about and protect with safety checks during compilation and during the operation of the smart contract. The resulting code is generally atomic and can prevent reentrancy bugs, double spending, unauthorized access to the assets and more. Here is a relevant Medium article:
Flint: A New Language for Safe Smart Contracts on Ethereum.
A fresher example based on an entirely new protocol was put forward in 2020 in the Cadence language for the flow protocol which you can read about in the article entitled Resource-Oriented Programming: A Better Model for Digital Ownership. This paper covers a gamut of advantages for this approach including flexible ownership, better handling of state information, capability-based security and the end of reentrancy bugs.
The new Radix protocol with it's forthcoming Scrypto language incorporates asset oriented programming. A recent claim from the project leader is that Scrypto will extended the concepts demonstrated in the Cadence language. Details have not emerged yet however they have published some videos about Scrypto that show why Asset-oriented programming has the potential to be both simpler and safer for smart contract developers. See the article entitled What is the Radix Engine V2? and the embedded video links for an overview.
In my view if asset oriented programming together with other means for improving the correctness and security of smart contracts leads to better user experiences while saving significant time and money for code development and audits, then that could trigger a cosmic shift in the world of DeFi and other smart contract based systems. I am keeping my eye on Radix and Scrypto to see how this plays out.
Photo by Karolina Grabowska from Pexels
