A smart contract is a new self-executing contract where the terms of agreements between a buyer and a seller are written in programming code languages. Today, many experiments have been run by many sources for authentic smart contract development.
The new programming languages in smart contracts can give us some opportunities to build a better language. Ease in readability, manageable complexity, and common preventive bugs are some basic things that we can improve. Let us now know more about the improvements.
Improvement in readability
Smartness comes with ease in readability. Every smart contract developer shares the goal of making the language easily readable. Let us assume that you are going through a smart contract and encounter this solidity code:
|
(uint256 locked, uint256 spendable) = getBalances(msg.sender); require(amount <= spendable, "attempting to transfer too much"); |
If this code is a security token for a lockup period, then you will read getBalances(address) and find some things. ‘getBalances()’ gives the balances in reverse order. First, the balance is returned, but the code that we read will check the incorrect value of the amount. Another side-effect of ‘getBalances()’ is that it verifies the lockup expiration and updates the internal balances.
Now the antecedent code maybe like this:
|
var spendable uint256 var locked uint256 locked, spendable = spendable, locked from getBalances!(account: msg.sender) assert amount <= spendable, "attempting to transfer too much" |
Here, at the call site, lots of information is present now. The right side of the programming needs to attach the accurate names of the return value from getBalances!(). The exclamation signs in getBalances! develops from Scheme naming convention. The auditor of a smart contract development company finds out what state mutation the coding does.
Public function names require uppercase letters to start with, and private function names require lowercase letters. Mutating states also require special syntaxes like store! x = 5 for writing to a storage variable and call! … for making an external call.
Management of complexity
Over time, smart contracts get bigger and complicated. It also affects the readability of the contract. With the growth of the contract, the complexity of that contract also grows exponentially.
Large contracts can be broken into diminished and reusable classes. Classes adjoin storage and ways that act upon the storage. You can access only the public methods from outside the class. It makes it easy to analyze one class at a time to cross-check its behavior.
Now let us consider this solidity code:
|
contract SecurityToken { struct Account { uint256 lockedBalance; uint256 spendableBalance; uint256 lockupExpiration; } mapping(address => Account) accounts; function getBalances(address addr) internal returns (uint256 spendable, uint256 locked) { if (now >= accounts[msg.sender].lockupExpiration) { accounts[addr].lockupExpiration = 0; accounts[addr].spendableBalance += accounts[addr].lockedBalance; accounts[addr].lockedBalance = 0; } return (accounts[addr].spendableBalance, accounts[addr].lockedBalance); } ... } |
Bugs are present in the aforesaid code. Any smart contract service provider usually utilizes msg.sender rather than addr. It is a common confusion and happens over state access. A bug is not very hard to find in a small-sized code. But when a code gets bigger and complicated, the bugs cannot be easily found.
Now let us see an upgraded version of the programming:
|
contract SecurityToken { storage accounts map[address]Account ... } class Account { storage lockedBalance uint256 storage spendableBalance uint256 storage lockupExpiration uint256 func GetBalances!() (locked uint256, spendable uint256) { if block.timestamp >= lockupExpiration { store! lockupExpiration = 0 // We can improve on this too! More in a future example. store! spendableBalance += lockedBalance store! lockedBalance = 0 } return { locked: lockedBalance, spendable: spendableBalance } } } |
It is an Account class. No confusion will occur in detecting the Account we are working with. You can access only the data of the Account.
Prevention of common bug classes
If you have the experience, you may know that there are some types of bugs that create problems repeatedly. Wherever possible, smart contract development services try to prevent bugs of common classes.
Let us take an Account class coding where the following types of bugs are introduced:
class Account { storage lockedBalance uint256 storage spendableBalance uint256 storage lockupExpiration uint256 func GetBalances!() (locked uint256, spendable uint256) { if block.timestamp >= lockupExpiration { store! lockupExpiration = 0 store! spendableBalance += lockedBalance // Whoops! I forgot to zero out lockedBalance, so repeated calls // to GetBalances!() will keep increasing spendableBalance. } return { locked: lockedBalance, spendable: spendableBalance } } } |
You can present pooled values so as to tackle this kind of bug or issue. Well, pooled values function as double-entry accounting. When a value is sent or received, it must be subtracted or added to purposeful storage.
The below-mentioned operations are well-explained with the pooled values:
- Declaration: pool tokens define tokens as a new pool.
- Minting: a new pooled value is returned by mint! 5 tokens.
- Burning: burn! 5 tokens from foo reduces the value of foo by 5.
- Moving: balanceA <- 5 tokens from balance mitigates balanceB by 5 and elevates balanceA.
Conclusion
Smart contract creation has become a common and way of making agreements. Many multinational companies rely on this system for making agreements with other fellow companies. So, the creation of new and unique language for these smart contracts has also been a much popular field of work.
No comments yet