Algorand 2.0 — Technical Innovations and Use Cases
By Tobias W. Kaiser on ALTCOIN MAGAZINE
Being highly dependent on network effects, many state-of-the-art Layer 1 blockchain enterprises have realized that building a community of developers and combining them within an ecosystem is a quintessential step for sustainable growth. When choosing between different blockchain to build on, DApp developers should ask the question of what services a specific blockchain can offer them, compared to the others. Having by far the largest ecosystem, Ethereum seems like a natural choice, but is it really the best choice? Other blockchains may offer a rich environment of pre-built smart contract templates or built-in functionality that developers can profit from.
As the first-ever “pure” Proof-of-Stake blockchain, proposing and voting on blocks on Algorand does not require stake delegation or bonding in any form. Thus, Algorand attempts to solve the scalability trilemma, offering a good solution for scalability, security, and decentralization at the same time. Furthermore, this consensus mechanism makes all blocks immediately final, without the forks that regularly occur on Proof-of-Work blockchains. With their next development milestone, Algorand 2.0, many new features and functions are added to this blockchain ecosystem. This article provides a short description of newly implemented features and possible use cases of Algorand 2.0.
Smart Contracts at Layer 1
Blockchain primitives can, in a nutshell, be described as the building blocks for decentralized transactions. It is a somewhat vague term that can entail cryptographic concepts such as zero-knowledge proofs, standards such as ERC-20 and ERC-721, best practices, or smart contract templates. Algorand seeks to hard-code many of these primitives directly into their blockchain on Layer 1.
Implementing primitives on Layer 1 has many benefits over implementing them through smart contracts, as smart contracts are costly to execute and bugs in their implementation can lead to security loopholes. Algorand Smart Contracts on Layer 1 (ASC1) thus enjoy the same security and efficiency as regular single-transaction payments, while allowing a wide variety of use cases, such as publicly posting an asset for sale, crowdfunding, asset tokenization, or multisig wallets.
Algorand Standard Assets
In order to create a fungible ERC-20 token on Ethereum, developers need to write a smart contract that implements all of the functions defined in ERC-20, which makes the token compliant to this standard. While there are of course smart contract templates that developers can use, it still means that every ERC-20 token is governed by its own smart contract. As with any smart contracts, faulty implementations of ERC-20 tokens may create bugs that allow hackers to steal money.
In contrast, Algorand implements fungible and non-fungible tokens directly in Layer 1. This means that, rather than implementing a fungible token through a smart contract, anyone can use a standard solution to simply create a token on the Algorand blockchain.
The creator of a token (“token manager”) may optionally reserve some administrative power over the token through what is called Role Based Asset Control (RBAC). This can include the ability to force transactions or to freeze tokens in one or more accounts, similar to functions that may be added to token smart contracts, when required by a tokenomic model. Especially the latter option makes some interesting use cases possible. Not only can the token manager freeze the tokens of a user who is suspected of illicit conduct. The manager may also opt to freeze all accounts at the point of token generation, for example, to fulfill KYC/AML requirements before the tokens in an account are unlocked, or to unlock tokens once some kind of vesting period has passed. This makes it possible to launch security tokens that are fully compliant with any national or international regulation.
Note that RBAC is entirely optional. For simple fungible tokens, most token managers will likely opt to create a trustless token where they do not hold any centralized administrative power, but some business models may still rely on these options. Through the various RBAC options, standardized tokens can be created that are tailored to their specific use cases. The Algorand 2.0 protocol supports these standards for any type of asset on the Algorand blockchain. These can include fungible, non-fungible, restricted fungible and restricted non-fungible assets.
Atomic Multi-Party Transfers
Algorand also enables atomic transfers directly on their Layer 1. The most basic and common form of such a transfer is an atomic swap, i.e. two parties exchanging different assets. What is peculiar about atomic transfers on Algorand is that more than two parties can be involved in what is called an Atomic Multi-Party Transfer, or AMPT for short.
Imagine not two, but three parties who are involved in a circular atomic swap: user A wants to transfer an asset x to user B. In exchange, user B agrees to transfer an asset y to user C. In exchange, user C agrees to transfer an asset z to user A. Instead of having to write a smart contracts that holds all three assets in escrow, the users can instruct the Algorand blockchain to carry out all three transfers simultaneously.
Like ASC1, AMPTs has a vast array of potential use cases with multiple senders, receivers, or both. These can be 1-to-n transfers, such as airdrops, n-to-1 transfers, such as a crowdfunding round that is only successful once a certain amount is reached, or n-to-m transfers, as they happen on decentralized exchanges. Another benefit of AMPT which comes from a combination with ASA and ASC1 is ability to create a new, more fast and secure kind of decentralized exchanges on Algorand.
TEAL
ASC1 functionality is implemented using Algorand’s proprietary programming language, called Transaction Execution Approval Language. TEAL can essentially be seen as a light-weight assembly language for the Internet of Value, consisting of only 30 instructions. One of these instructions is the atomic transfer, which exemplifies the importance of AMPTs within Algorand’s technology stack.
Algorand has specifically designed TEAL not to be a Turing-complete language for security reasons. For example, the infamous DAO hack exploited recursive function calls to continuously siphon off Ether from a smart contract. By not allowing recursion and loops in TEAL, Algorand created a more secure smart contract language, that is nevertheless very powerful.
Conclusion
In addition to their unique pure Proof-of-Stake blockchain, Algorand adds more functionality to its Layer 1 with their 2.0 protocol update. Smart Contracts at Layer 1 implement a rich set of blockchain primitives, while Atomic Multi-Party Transfers and standardized assets can be managed on Layer 1 as well. The foundation for this is a powerful non-Turing-complete programming language called Transaction Execution Approval Language. Thus, many blockchain use cases can be carried out efficiently and securely on Layer 1 even without requiring developers help to write smart contracts.
