Popular Solutions using Algorand
A few standup apps that use Algorand are Republic, Securitize, El Salvador’s blockchain infrastructure, Marshall Island’s digital currency, Orion Protocol, and DUST Identity.
Consensus — Pure Proof of Stake
Pure Proof of Stake uses verifiable random function (VRF) as a weighted lottery where the weight is dependent on the number of ALGO’s someone owns.
VRF (Verifiable Random Function)
VRF performs cryptographic sortition to select committees to run the consensus protocol. There are three parts to VRF, keygen, evaluate, and verify.
Y, our random string is unique and pseudorandom, it looks random, but with the proof, you can verify it with the verification algorithm.
In Algorand, each user (Algo holder online) runs through the steps above. They hold a secret key SK (secret key) and VK (verification key), the VK is known publicly, all handled out of band. If these users want to participate in the committee to run the consensus, then they need to do the following:
- Compute Evaluate(SK, Qr) → (Y, ⍴). Here, Qr is a “magic” seed string available to everyone in the system.
- Check that Y falls within a specific range [0, P] that depends on the user’s stake in the system.
Algorand shared their VRF algorithm with Libsodium, check out the implementation below:
Below is the standardization on VRF by Sharon Goldberg, Moni Naor, Dimitris Papadopoulos, Leonid Reyzin, and Jan Včelák:
Don’t Fork With Me!
An interesting feature of Algorand is that it’s not forkable.
Side Note on Forking
Forking happens if two nodes get a valid block simulataneously and different users can’t agree on which block to take or an upgrade can’t be decided on. In these scenarios the chain splits in two and as new blocks are added to the chain one of them will get longer than the other. Eventually the longest one will stay and the shortest one will die off. When the shortest chain dies off, all the blocks in it, along with all the transactions will be considered invalid.
Forking is not a bad thing.
Algorand is built to prevent forks. It isn’t necessarily a positive feature, just another way of tackling the CAP theorem (Consistency, Availability, and Partition Tolerant). With blockchain networks like Solana, forks are created to rotate leaders quickly. Forking allows the network to process transactions quickly and keep moving when there are disagreements but sacrifices consistency in the process.
The benefit around this is there’s an assurance that transactions reach finality once they are complete (~5 seconds). In forkable networks, you need to wait after a certain amount of blocks (6 blocks is recommended in Bitcoin, which could be an hour) are added on top of the block your transaction is in to know it’s finalized.
How is Algorand Unforkable
Algorand is unforkable because two blocks can never be propagated to the chain at once because only one block can have the required threshold of committee votes.
Below are the steps in the Algorand Consensus Protocol:
- Proposal Phase
Every node loops through online accounts with valid participation keys and selects an account. Now an account is selected, the other nodes verify the account was selected.
2. Soft Vote Phase
The number of proposals are narrowed down, and the nodes verify the signed messages and validate the selection using a VRF proof. The account with the lowest VRF hash is chosen to propose the next block.
3. Certify Vote Phase
A committee of 1,000 verifiers is pseudorandomly selected to receive information about the new block. Their job is to verify the block and mark it as valid or invalid. If the quorum is reached, the block is added to the blockchain.
If Quorum Not Reached — Network enters recovery mode but doesn’t fork
The network would never fork instead it will enter the recover mode. In recovery mode recovery messages are sent out. Nodes will send these messages to signal to the network that it should either continue processing the last known block proposal or to propose a new block.
When a quorum of votes is received for either one of these messages, the system will revert to normal operation.
In the case of malicious behavior, the protocol may select a new leader. In the case of network outage, the current block will continue to be processed or a new block might be proposed.
Check out the video below to learn more about Pure Proof of Stake.
Or check out the white paper on the protocol:
https://www.algorand.com/Algorand%20Protocol.pdf
Storage
Internal Data Store in Nodes — SQLite
The ledger uses SQLite database as its internal store. This is where the algod process writes and reads data.
SQLite was chosen as it provides excellent storage performance, is embedded, lightweight, and fault-tolerant. Other databases might provide better indexing features — but these are not required for an algorand node.
A drawback behind using SQLite is the lack of control from a database standpoint. For instance, your flexibility would be limited if you wanted to optimize the database like add indexes, etc. It’s not a deal-breaker but something to ponder if you’re considering Algorand for government or financial projects where the organization has its database management strategies.
Relational databases are rare in the blockchain space. The norm is key-value databases (i.e., Bitcoin & Ethereum uses LevelDB, Solana & Polkadot uses RocksDB). These databases are lightweight and easy to scale out horizontally. The only other platform that uses relational databases is Corda R3.
Standalone REST API Data Store — PostgresSQL
Indexer is a separate binary outside the Algorand node that acts as a REST API interface. It retrieves the blockchain data from a PostgresSQL database and is connected using an Algod process running on an Archival Algorand node.
Below is an example of a query where we return the last 1000 transactions that exceeded ten microAlgos:
#/indexer/python/search_transactions_min_amount.pyresponse = myindexer.search_transactions(min_amount=10)# Pretty Printing JSON string
print(json.dumps(response, indent=2, sort_keys=True))
P2P Communication
Relay Nodes
Accounts do not exchange messages directly; instead, they propagate their messages to a relay node. The relay node is untrustworthy, so to work around that, we use an encoding. One thing to keep in mind is that the relay nodes are permissioned nodes. They are registered with the Algorand foundation’s SRV records. This nudges Algorand towards a more centralized approach.
Serialization — MessagePack
All messages in Algorand are encoded using MessagePack, a binary serialization format that allows exchanges in languages like JSON.
Communication Technology
The network operates in a mesh network using WebSockets over HTTP (TCP). Algorand probably chose TCP because it’s commonly supported and can handle tasks like prioritizing queued messages.
Transaction Pools
The transaction pool, also called the mempool in other networks, is where the transactions are held in memory and added into a block proposal.
A transaction pool prepares valid blocks for proposals and caches validated transaction groups.
At all times, the transaction pool maintains a queue of transaction groups slated for proposal. It checks that the transactions are properly-signed, the fees meet the minimum, and the state changes are consistent with the prior transactions in the queue. It does all of this work within a deadline; if it doesn’t finish by the deadline, it gets a buffer period it puts together an empty or partial block.
Fees
With every transaction, there’s a minimum transaction fee of 1,000 microAlgos or .001 Algos. On top of that, there is a fee per byte based on the estimated size of the transaction in bytes. If this fee is less than the minimum fee, it defaults to the minimum fee. To better understand the fees, you can use the SDK method suggested fee per byte (fee).
Check out the fee documentation below for details:
Minimum balance on Accounts
In Algorand, there is a required minimum balance of 100,000 microAlgos (today that’s ~$0.092373). If your transaction gets the balance below this minimum, it will fail.
FeeSink and RewardsPool
FeeSink is where all fees from transactions are sent. The FeeSink can only be spent towards the RewardsPool account. The RewardsPool account holds the Algos that need to be distributed as rewards to Algorand accounts in the protocol. As you can see in the code below, there’s a logic that only allows the FeeSink to send to the RewardPool.
This approach is slightly centralized, the reward pool is just one address on the Algorand network. Below is the reward pool for mainnet:
Processes for Nodes
There are two processes in Algorand, there’s KMD and Algod.
KMD (Key Manager Daemon) handles all interactions with spending keys, including signing transactions. Signing can also be standalone.
Algod is responsible for processing the protocol and interacting with SQLite to write records and implement REST API for reads.
Algorand’s Smart Contract Language
Algorand uses TEAL (Transaction Execution Approval Language) and REACH.
Algorand smart contracts like Ethereum smart contracts have an Algorand address and can hold Algorand Assets (ASA’s) and Algos.
Refer to the docs to learn more about smart contracts:
TEAL & PyTEAL
TEAL is an assembly-like language that’s processed in AVM (Algorand Virtual Machines). It’s a Turing-complete language that supports looping and subroutines has guardrails that limit the contract’s execution time using a dynamic opcode cost evaluation algorithm. You can either write TEAL or use pyTEAL to generate TEAL code.
In pyTEAL and TEAL programs, there are always two programs: the Approval Program and the other is the Clear Program. The approval program contains most of the business logic, and the clear program handles closing the account(s).
All communication with Algorand smart contracts is achieved through application transactions. Below are the six application transaction subtypes.
Approval Program
As you can see in the NFT smart contract example below, all the meat sits in the approval program.
Clear State
I pulled the smart contract above from Algo-Builder’s smart contract template:
Reach (.rsh)
Reach is a DApp framework that works with Algorand and Ethereum, most commonly used with Algorand. Reach aims at handling the whole experience, frontend, and backend. The backend is dealt with a file like index.rsh and the frontend in an index.mjs.
Get your hands dirty with Reach by running through the tutorial below:
Where does it sit in the Blockchain Trilemma
Decentralization
Standing up an Algorand is quite simple. You can even get away running on your laptop. Making it easier for several people to start running their Algorand nodes. Surprisingly, there aren’t many nodes running today, as of today, 1/31/21, there are only 1,427 nodes running. Giving that number some context, today, 1/31/21, there are 2,052 nodes running with Ethereum.
The relay nodes have to be registered with Algorand. In a truly decentralized blockchain, everyone and their mom should be able to run any node. Even though all these Relay Node participants are from different companies and countries, there is a point of centralization because they are all approved by the same organization.
Algorand has no minimum to participate in proof of stake, which allows anyone to participate in proof of stake. Every Algo token in Pure Proof of Stake (PPoS) (the consensus algorithm) is considered a lottery ticket. There’s a chance that the consensus would choose you with just one Algo, but the chances of being chosen increase with more “lottery” or Algos you have.
Scalable
With Algorand’s no-fork design and its use of SQLite, I don’t see how it can scale. This approach of approving one block at a time, transactions could pile up if there isn’t a consensus on what’s proposed, stalling the network.
Security
Because Algorand is unforkable, it’s highly secure, and transaction finality is everything regarding government and financial records.
The way they separate the processors, algod and kmd, makes the reads and writes secure. Key management should always be handled separately from other blockchain duties.
Algorand’s approach of not using spending keys to participate in consensus keeps the network secure. Instead, participants use a participation key and a collection of ephemeral keys to sign off on consensus activities like block proposals, votes, etc. This approach prevents double signing and protects spending keys from ever being jeopardized in the case of a compromised node.
Notes on Speed
Algorand is currently at around ~1,000 TPS, faster than Bitcoin and Ethereum, but not as fast as other 3rd generation blockchain networks like Solana. Algorand has proposed in their performance report that with block pipelining, they can reach 46,000 TPS, but we’ll need to wait for that implementation to deploy onto mainnet.
In terms of finality, Algorand wins; they have a finality of 2.5 seconds because it’s finalized as soon as the transaction completes. We don’t have to wait for additional blocks to be added to know it’s truly final because of its no forking design.
The Algorand Foundation pulled these performance metrics from their 2021 performance report:
If you like the post, then you can buy me coffee, thank you in advance!
If you’re obsessed now, dive in with these resources.
Official Repo
Algorand Metrics Dashboard
Official Algorand Forum
CoMakery Algorand Security Token
Algorand Smart Contract Architecture
Tutorial on Atomic Transfers on Android
New to trading? Try crypto trading bots or copy trading
