The launch of Ethereum in 2014 provided the first ever public platform for coding of smart contracts. While this was a revolutionary development, the initial excitement failed to enable the widespread adoption of blockchain it seemed to promise. Part of the reason for this is because developers have struggled to solve issues such as scalability and interoperability.
Aelf aims to overcome these challenges, and one of the ways we are achieving this is by taking an entirely different approach to the operation of smart contracts. Although other platforms are now available, for the purposes of this article, we will contrast aelf with Ethereum as one of the best-known and well-used smart contract platforms.
Smart Contracts on Ethereum
Smart contracts work on the “if-then” logic, so once the contractual conditions are triggered, the transaction itself is recorded on the Ethereum blockchain. Ethereum operates on gas, so there must be enough gas left in each smart contract to complete the transactions within the smart contract itself. Furthermore, the miners must be willing to accept the gas price offered by the owner, for the smart contract to complete.
Assuming all these conditions are in place, then in principle, anyone can use Ethereum to run a smart contract for any purpose. However, it’s well known that Ethereum suffers bottlenecks at times of high throughput. For example, the network slowdown caused by the craze for CryptoKitties was so extreme that it even hit mainstream news outlets. At these times, the gas price also spikes due to increased demand.
The reason for these bottlenecks is because all Ethereum-based transactions, whether they are simple ETH trades or transactions within smart contracts, are all taking place on a single chain. In a blockchain environment, transactions are also often interdependent. The input of one transaction depends on the output of another having been successfully confirmed, particularly in a smart contract that has multiple conditions and steps to completion.
Ethereum overcomes this by requiring that all transactions are processed sequentially. However, sequential processing on a single chain causes bottlenecks like the case of CryptoKitties, because all transactions for all smart contracts and ETH trades must be confirmed in sequence by every node on the network.
Some in the blockchain community will call for increased block size, which would allow more transactions within a single block. The problem with this is that the more transactions that take place on the Ethereum blockchain, the bigger the ledger becomes. For a node operator, this increases the hash power needed to mine blocks.
There is a valid argument that increasing the block size will bloat the ledger to the extent that only large companies will be able to provide the hashing power needed for mining. This inhibits true decentralization and thus increases the risk of a 51% attack.
The Ethereum developer community is, therefore, exploring several solutions to overcome the scalability challenge, which is necessary if the system will continue to be viable as a smart contract platform. Some potential solutions are sharding, and the Plasma protocol, involving the use of child chains.
Resource Segregation with Smart Contracts on Aelf
While Ethereum is implementing child chains on Plasma as an extension to overcome its scalability challenge, aelf is incorporating the use of side chains as part of the initial design. Multiple types of smart contracts all running off a single blockchain prohibits scalability.
Furthermore, it fails to accommodate the myriad challenges faced by real-world businesses with different smart contract needs. Whereas some applications may require high throughput with fast confirmations, others would be willing to compromise on speed to attain the best possible security.
Therefore, aelf doesn’t have any smart contract functionality on the main chain, which is solely used for indexing side chains. Smart contracts are segregated by type onto different side chains. So, one side chain could operate smart contracts for registering and authenticating identity data, with a focus on security and privacy. Another side chain could operate a decentralized exchange, with fast transaction throughput.
Using Merkle Tree roots, these two side chains can communicate with one another via the aelf main chain. If the exchange side chain needs to verify the identity of a user, it can do so by requesting the Merkle Tree root of the particular block on the identity containing the user’s identity data. Through segregating smart contracts onto different side chains, each application can operate without interference from the rest of the network.
Aelf side chains also have the option to branch off into sub-chains. In this way, each side chain can operate as its own scalable and independent ecosystem dedicated to a particular function. This doesn’t need to be a single-application use; it can cover an entire industry. For example, there could be a side chain dedicated to insurance, with sub-chains containing smart contracts specifically programmed to manage processes like premium payments, claims, or self-insurance pools.
Overcoming the Scalability Challenge
Whereas some transactions will be interdependent, there is also a majority that can be confirmed independently of one another. Therefore, aelf separates transactions that are independent of one another into different groups.
Nodes on aelf can then confirm groups of transactions in parallel to one another. Interdependent transactions are confirmed sequentially only within their particular group. Parallel processing allows aelf to confirm transactions at a far faster rate than sequential processing on other blockchains.
Second generation blockchains such as Ethereum have brought many exciting developments to the blockchain space. However, the “one size fits all” approach has inhibited mainstream adoption from businesses which have multiple different needs in the real world. By segregating resources onto side chains, aelf is creating a highly adaptable and scalable ecosystem to deliver smart contract capabilities that serve the needs of modern businesses.
· aelf Telegram community: English, Türkçe, Español, 한국, 日本語, 中文，русский, العربية, Deutsch, Italiano, Français, हिन्दी, and Tiếng Việt,
· aelf Twitter
· aelf Facebook
· aelf YouTube
· aelf Instagram
· aelf Reddit
· aelf Medium (for the latest update and articles)
· aelf Github (complete aelf project codes)
For more information, visit aelf.io
