Part 8: Blockchain Contracts

08.08.2023

This episode focuses on smart contracts. After reading through the article, you will have a basic understanding of smart contract functionality, use cases, composition, and history. I want to give you an edge in the knowledge that will set you apart from the standard smart contract crowd; this part also describes Live contracts.

Introducing smart contracts

In most cases, Smart Contracts are similar to paper contracts of the analog world, but instead of ink on paper, they are written as digital text in computer-readable code. In the same way, a local computer program can be run by selecting it in the operating system; a smart contract can be triggered by calling a method on the contract using a blockchain transaction (TX). The 'program' that the contract executes is stored on a node, which is part of a peer-to-peer (P2P) network of servers. The smart contract is distributed with hundreds of copies over hundreds of nodes that, with other parts, create a blockchain network. When executed, both the programs in your PC and blockchain smart contracts (also programs) do what they have been designed to do, assuming there are no software bugs.

These contracts are usually eternal, meaning they are not "closed" and deleted after execution. Some can be programmed to "self-destruct" after use, but that's not usually how they operate.
Once most nodes confirm, a transaction cannot be reverted, rolled back, or modified.
Using an interface such as MetaMask, a smart contract is triggered using a blockchain transaction that connects to a node.

"In the end, a smart contract is nothing more than the exact same piece of code that's executed on many (hundreds) of computers that all calculate the exact same result." - Arnold Daniels

A minimalistic smart contract example

Storage, written in Solidity

pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) public {
storedData = x;
}
function get() public view returns (uint) {
return storedData;
}
}

The mathematical birthday party invitation quest

The Smart kid wants to invite his friends from kindergarten to his birthday party, but only the smart ones who know how to count. To resolve this conundrum, he decides to ask the kids in consideration, "Does one plus one equal two?"
If they're correct, they'll get invited. His dad, however, has a different method in mind…

Father: Let's do things a little bit differently. Instead of asking if they agree with our result individually, we will do it as a smart contract.

Son: Like a smart-what?

Father: Instead of saying "1 + 1 = 2" and asking others if they agree, you will distribute a few paper letters to your friends with the "1 + 1 = ?" message and let others calculate the result for themselves. When they solve it, they will tell us their result. We will be observing their participation and counting right and wrong answers.

Son: That way, we find out who can count like me and could be a good friend for my birthday party on Friday.

Father: Exactly! Here are some pencils and paper; let's create a paper for each of your potential friends; tell them to solve it after they count to 10, then get back to me.

Son: Heyyyy my potenti… friends! Let's play a counting game!

A few moments later…

Father: We know the result is 2; let's see how your friends handle this…

Scotti calculates 2.

Unikum also calculates 2.

Gimp has also calculated 2, even though it took him a long time.

Then, out of the blue, JohnDoe finishes his calculation and shouts, "1 + 1 is 3!".

Father: See? Play with other cool kids from the block and leave JohnDoe to eat rocks.

Smart contract use cases

DeFi is a cryptocurrency use case that has recently been attracting significant attention. DeFi refers to financial services that use smart contracts, which for example:

Automatically execute transactions if certain conditions, agreed to by all involved parties, are met.
Executes "smart-contract-B-plan" operation for the participants who decided to break out of the contract agreement while providing the agreed-upon outcome to the remaining valid participants. An example of this scenario could be five persons staking their tokens on a platform. By the time of their staking, they obtain staking rewards. When the staking period is over, they can move their assets from the staking contract (or the contract does this by itself). Suppose one of those five participants decides to withdraw their stake in the middle of the staking period, which was set by the contract. In that case, they consciously act against the contract and will be given a penalty, also known as slashing.

Smart contracts are automated consensus-relaying agreements that do not need intermediaries, such as banks or lawyers, and use online blockchain timestamping and identities as proof of authority instead. The beauty of a smart contract is that it can hold value (for instance, by holding SOV tokens on the RSK blockchain) and is enforced automatically by the blockchain's full nodes and miners when the pre-set contract conditions are met.

Let's assume a simple example with a crowdfunding platform. Some investors (also known as "backers") want to support a project that requires money to be realized. If the project is funded and successful, the investors will likely gain a hefty return on their investment. Using the decentralized trust mechanism of smart contracts, the crowdfunding platform provides backer insurance of sorts, where a significant chunk of the funds are locked and released in tranches only when the team reaches a promised milestone. If the funding goal is unmet or the project's team does not deliver the promised results, the invested money is returned to the backers. Oracles provided information that the team had already run out of the time they claimed to use to fulfill their roadmap's targets.
In addition, smart contracts ensure that backers' money goes directly to the crowdfunding platform, the project team, and nowhere else.

On top of all this, smart contracts can also define possibilities. In the chess game example featured in Episode 1, smart contracts could fuel an application that reads the game record and designs a playable possibility for each move while simultaneously monitoring the piece's current state or position on the playing field. As a result, the observer could, for instance, see highlighted fields around the figures of his choice that would indicate his possibilities on where and how to move his pieces in accordance with the game rules. If both players bet on themselves (staked something in the contract) before the game started, this smart contract would award a prize to the winner after the checkmate.

Other real-world adaptations:

Banks -> to issue loans or to offer automatic payments
Insurance companies -> to process certain claims
Postal companies -> for the payments on delivery

Main benefits of smart contracts:

Immutable: Thanks to the decentralized distribution and the blockchain's consensus mechanic, the purpose of smart contracts can not be changed or modified; they do only what they were initially created for.
- Exceptions:
  1. Some contracts can be changed by design. These are generally referred to as "upgradeable smart contracts."
  2. Any user can change a smart contract. However, this will cause either a hard or soft fork, resulting in the user (and any user who adopts the same change) splitting off from the rest of the network. An example would be how Ethereum changed The DAO smart contract and split off Ethereum Classic.
Protected by the blockchain architecture: The output of the contract is validated by all users participating in the network. Therefore, a single person cannot force the contract to do something else since the other users would detect this attempt and mark it invalid.
Not enforcing themselves or executing themselves: Smart contracts are collectively executed by all network miners, who include transactions modifying the state of a smart contract in their blocks, and enforced by full network nodes, which audit each block to ensure it is compliant with the blockchain's consensus rules. Thus the miners and nodes execute the state transition functions and enforce the rules of every contract the same way they do with the underlying blockchain protocol of a particular network.

The states of these contracts and these state transitions have value only as long as all participants in the blockchain believe they have. An example could be, again, the miners of the Ethereum network. They decided by a large portion of the votes that the state of the blockchain on Ethereum Classic was not valuable to them and decided to abandon it.

Eliminating the influence of third parties: Thanks to their design, there is no possibility for any party to breach the agreement. This means that there is no need for a trusted third party, no bankers, no lawyers, and no judges. However, in certain cases, this can be problematic (which is where live contracts come in).
They run as quasi-Turing complete programs: There is a specific finality in their execution, and they do not risk looping infinitely.

Transaction execution

An example of a token-swap on uniswap.

Smart contracts always do what they were designed for, and the transaction initiator pays the associated transaction fee.
If all conditions were met, nobody interfered with the contract, and additional global conditions ( trader's slippage <= market volatility) were met -> the transaction is executed.

Examples:

A successful swap between two tokens happened with market volatility lower than your maximal slippage rate. The user pays for the associated transaction fee.
Tokens were returned to a staker after the end of the staking period with additional tokens from the reward pool for keeping the tokens staked for its complete staking period.
ICO investors obtained tokens from the crowdfunded project. These new tokens are obtained in exchange for a pre-agreed amount of RBTC users sent to the crowdfunded project address (the crowdfunded project pays fees).
If somebody interfered with the contract and the contract thus didn't fulfill its original purpose due to non-compliance, or additional global conditions were not met -> the "smart-contract-B-plan" is executed for the interferer in its original design and:**

For the interferer:

penalty or slashing is possible
loss of the stake

NOTE: Any penalties, slashings, and losses can only occur if the contract is executed. Such penalties, like the slashing in case of early unstaking, are rules set on the smart contract level. Hence, it's to be considered a successful execution according to the contract rules.

For a user who did not interfere with the contract but the global (or smart contract) conditions were not met (thus, not always the user's fault)):

The contract is not executed for its original purpose, and assets stay in the current wallet. The user pays for the associated transaction fee, which is usually considerably less than the fee for a successful execution.

Examples:

A swap of two tokens for a certain price in a volatile market ended unsuccessfully because the asset's value changed more than a trader's slippage could tolerate. The user didn't lose any assets but paid the fee for the associated transaction.
A staker chooses to un-stake before the staking period ends, resulting in losing 15 % of his vested assets while obtaining no reward from the reward pool.
ICO investors obtained their original funding asset back from the crowdfunded project because the project could not deliver. This information is provided to the smart contract by oracles. Oracles provided information that the team had already run out of the time they claimed to use to fulfill their roadmap's targets. A smart contract receives this information from the decentralized oracle and then automatically returns the collected money to the investors (the unsuccessful project pays fees - additional penalties are based on the contract design).

In the scenario where two parties in agreement fulfilled their obligation to the smart contract, thus the predetermined conditions have been met, the contract will be executed as originally designed. When a party decides not to meet the predetermined conditions and wants to break the contract, the part of the contract code of our aforementioned staking example will be executed in a way that benefits the party that was in the right and penalizes the party who walked away from the contract. That's the typical description of the legal-ish type of smart contract, where both (or several) parties are required to stake a value that will be transferred to a counterparty if one of the parties doesn't stand for what was agreed upon. This particular smart contract setup is not universal and can be written in a way that fits any use case or possible scenario.

In the blockchain world of late 2018, ICO smart contracts (where a user got a direct amount of tokens for the ETH amount they sent into the ICO contract) were trendy. Then, consider the Uniswap decentralized exchange. Each of their swaps between two crypto assets triggers a smart contract that delivers the new asset to the buyer's wallet and removes the asset they paid with.

Smart contracts are not responsible for subtracting the fee and funneling it to the provider of the liquidity pool and miners and stakers of the native blockchain. This part is mostly handled at the base protocol layer of a particular chain.

Since smart contracts are completely digital, rule-based, and configured as machine-readable algorithms, they automate much of the data mechanics on the blockchain and remove the need for the middle-man third party. Smart contracts never execute themselves; they must always be triggered from the outside by a blockchain transaction. Often, if a function is supposed to be executed under certain conditions, these functions are executable by anybody. Take the liquidation of margin trade positions as an example. The contract cannot liquidate the position without being triggered. But because anyone can initiate a liquidation, anyone can make sure that the system behaves as expected. It does not depend on a single party doing the liquidations. For such crucial functions, there's often an economic incentive for the executor. Liquidations, for example, offer the liquidator the option to purchase the position's collateral for a discounted price.

Smart contracts gained even more attention during the movement to free financial assets from the yoke of intermediaries - a movement also known as decentralized finance or DeFi. And that's the space where smart contracts, because of their ability to make crypto-asset lending possible, found their greatest demand in 2021.

Do all blockchains have smart contracts?

Even though smart contracts may appear to be a fundamental aspect of every blockchain, some, such as Bitcoin, do not support them as the Ethereum blockchain does. Still, it is possible to add this functionality through a sidechain, the use case of which can be imagined as a software "extension" or a "plug-in" for a particular chain. This "plug-in" enhances the use of the native chain while keeping the original setup untouched. In the case of Bitcoin, the RSK sidechain "plug-in," even though it is difficult to find a proper metaphor here, is bound to their Bitcoin blockchain and provides 100% on-chain settlement.

The RSK side-chain is Ethereum virtual machine (EVM) compatible, which allows for the execution of smart contracts code. Simply said: All the things that can not be handled on Bitcoin directly can be adapted and brought to the Bitcoin ecosystem through Bitcoin sidechains.

RSK sidechain:

The RSK sidechain is a standalone blockchain pegged to Bitcoin, which uses BTC as the main currency and inherits the Proof of Work security by Bitcoin miners.
Transactions are verified through a process called "merge mining." Merge mining happens by mining on BTC and RSK simultaneously.
The native currency on RSK (rBTC) is pegged to the Bitcoin digital currency and can be moved in and out of RSK trustlessly by using the integrated 2waypeg. 1Rbtc = 1Btc always.
The transaction fees are paid in rBTC, the BTC-pegged token.

Difference between a sidechain and Layer-2 solution:

Layer 2 generally relies on the security of the main chain, while a sidechain has its own security properties.

Sidechain provides 100% onchain settlement, pegged to a different mainchain.
Layer 2 (L2) signs transactions off-chain and settles a fraction of it onchain.

More about sidechains in chapter 10 of this series. Now, let's get back to smart contracts.

History of smart contracts

These contracts were first introduced as "Ricardian Contracts'' in 1994 by Nick Szabo, a computer scientist, legal scholar, and cryptographer. The term "smart contract" was first introduced long before the invention of Bitcoin, but it underwent a long gestation period of inactivity and disinterest since there was no platform that could enforce a smart contract, until the advent of Bitcoin blockchain technology in 2009. Nick Szabo intended to use a distributed ledger to store contracts.

The smart contract concept is rooted in basic contract law. Usually, the judicial system adjudicates contractual disputes and enforces terms, but it is also common to have a different arbitration method, especially for international transactions. With smart contracts, a program enforces the contract built into the code. Smart contracts have been gaining popularity over recent years. Most notably, Ethereum (one of many ICOs on Bitcoin - the first was Mastercoin) has made it a basic tenet of their blockchain's power to program smart contracts using a special language called Solidity. This exponential growth of smart contract usage was a major contributor to the DeFi boom that started in the summer of 2020.

Determinism in smart contracts

Smart contracts must be deterministic because each network node must find the same result when given the same input for a contract method. Otherwise, each node that executes the contract method to validate the transaction would end with different results, and no consensus would be possible. For this reason, some smart contract programming languages do not allow using functions that round numbers or generate randomness. Even though this is not a rule of thumb, the most famous language for writing smart contracts, Solidity, doesn't allow the use of these functions that would lead to a non-deterministic result.

For a smart contract to be considered valid on the blockchain, it must achieve consensus across the network's decentralized nodes. Non-deterministic functions pose a challenge to this consensus. For instance, using external data sources like weather measurements from different probes in London on April 14, 2022, introduces variability since these probes might report slightly different temperatures. An oracle relaying this type of external data into a smart contract could result in non-deterministic outcomes due to these discrepancies. Similarly, system-specific timestamps can vary, leading to inconsistent execution results. Thus, ensuring smart contracts operate deterministically is crucial for upholding the decentralized framework's integrity and trust within blockchain technology.

However, it is possible to round numbers in Solidy, but it is not possible to create true randomness. No computer can. It's always pseudo-random because it's an algorithm creating it, and an algorithm is just following rules. A random number generator always needs to be fed with a seed. That's where the problem for smart contracts lies. You can't use data on the contract as input because it's publicly available information (also, if the variable is private -> because it needed to be set at some point). You can't use user input because the user can then compute the result in advance and manipulate the outcome; you can't use the timestamp as input if considerable funds are at stake because miners can influence the timestamp.

Example:

Using the fixed set of rules, the `Math.round` function rounds 0.499999… down to 0 and 0.5 up to 1.

`Math.floor` always rounds down.
`Math.ceil` always rounds up.

It is possible to write functions for doing the same with solidity since the Numbers are always rounded the same way.

Let's take a token like SOV as an example now:

SOV has 18 decimals, but SOV is an integer on the contract. The contract knows that the last 18 digits are supposed to be the decimals, so, if you would like to round, let's say to 2 decimals, you will look at the 3rd decimal and establish the result from there:

if it's 5 or larger, you round the number up
else you round the number down

An example of such code:

function roundTo2Decimals(uint number){

number = number / 10^15; //assuming 18 decimals

if ((number + 5) / 10 > number / 10) number = number + 5;

return number / 10 * 10^16;

}

Smart contracts ensure that the result is always deterministic. So, no random number generator is built because it would generate a different number each time the code is executed. This means that no one would be able to verify if a miner was computing the correct result or not.

Functions that can produce randomness, and as such, are forbidden in Solidity by design:

`Math.random()` function:
- No functions in Solidity deliver a different result on each call because of the non-deterministic results described earlier in this series. The contract must always deliver the same result on each machine at any point to be validatable.
Rounding numbers up or down:
- There are no built-in 'round,' 'floor,' or 'ceiling' functions in Solidity, but you can very easily create your own functions for it.
Not built-in for Solidity, but provided in the form of libraries:
- `Date()`
- `Time()`

Lisk is an example of a project that used a non-deterministic programming language for writing smart contracts. They used JavaScript, a popular, powerful, and easy-to-use language that allows for the potential for human error in writing smart contracts. If the above-mentioned functions are not handled with utter vigilance, they can completely wreck your contracts and their purpose, which is to deliver a deterministic output.
- For the record, team Lisk warned developers to use their documentation properly.

The power of Solidity and other deterministic languages is that developers don't even have to care about being correct about final determinism in their contracts in the first place. It's simply because they could use no non-deterministic functions in the language by default.

Smart contracts and blockchain oracles

Oracles are an interesting concept directly related to smart contracts. In the blockchain world, oracles are like data workers, which put the off-chain data (data stored out of a blockchain) on a blockchain (on-chain). Because smart contracts can't use off-chain data directly, they need the help of oracles, which store this data on-chain first.

Oracles deliver a real-world representation of information, such as:

An identity - is this identity allowed to participate in crypto lending?
Certificate information - is the certificate still valid?
A temperature - is the temperature guaranteed by a certificate still present in a transport truck?
The current cost of a stock or crypto - vital information for all decentralized and centralized exchanges
An election vote status - inability to sum votes from all regions until all region-collected votes are counted
Many other cases...

and they can also have an agent-like property that directs the smart contract to behave in a certain way.

Example of cooperation between smart contracts and oracles: Permission to join DeFi crypto lending based on US residency. This will be decided by a smart contract which will obtain information about user-sensitive information always stored off-chain using a centralized oracle. The decentralized oracle will publish a list of addresses of identities allowed to participate in the DeFi crypto lending contract. An oracle concerned with a user's ability to participate in crypto lending will check:

an off-chain identity using the information provided during KYC (verifying passport or driver's license)
an on-chain identity utilizing the user's blockchain address through a cryptographic challenge by requesting a public key pair signature (each address has its private/public key pair)

As the authority, the smart contract can determine if this user can participate in crypto lending based on checking their identity.

Types of blockchain oracles

Oracles can be arranged into various classes based on their intended purpose. There are centralized and decentralized oracles. Then some oracles put information into smart contracts and oracles that take the info out of them. We can distinguish them even further based on the input they are using. The next category of oracles is whether their information intake is based on software or hardware solutions. The two current inputs for blockchain oracles are obtained from devices for data digitization, such as scanners or various types of sensors, or directly from the internet. We need to mention that this classification is not finite. Combining different applications and technologies makes it possible to obtain variations, such as software centralized inbound oracles.

The following classification summarizes the commonly used types of blockchain oracles:

Classification of oracles

Transmitter or Receiver of information:

Inbound - Flow of information from an external data source to a smart contract
Outbound - Flow of information from a smart contract to an external data source

The data source of information:

Software - obtaining information from the Internet
Hardware - obtaining information from reading or scanning devices

Organizational structures for reaching trust:

Decentralized - attempting to reach trustlessness by distributing trust between multiple participating nodes.
Centralized - single source of information, single source of failure.

Types of oracles

Human oracles are especially useful in decisions where subjectivity is involved.
Unnamed oracles are anonymous computer nodes working for the network to retrieve data from where they've been precisely told and deliver it to the requestor independently.
They provide a way to feed smart contract data without the need for human intervention.
In contrast to human oracles, they are purely objective.

Contract-specific oracles are oracles bound to a specific smart contract.

Live contracts as an addition or alternative to smart contracts

What is a Live contract?

Much like smart contracts got into the general consciousness because Ethereum was designed to operate with them, Live contracts are getting public attention via utilization on the LTO Network blockchain. While a smart contract has been designed as a program operating on the blockchain and readable by computers, a Live contract is described as deterministic graphs produced by finite-state machine algorithms, readable by humans and computers. It is a way for two parties to communicate with each other and encapsulates rules and conditions essential to doing business on a blockchain into a single unit. Since the Live contract is in the secure environment provided by a blockchain, they can act as guides and validators.

To make Live contracts easily understandable for computers and humans, they are split into several units. The parts that are considered simple and safe can be executed by computers in the same way smart contracts are. Other parts can and should be left to human interpretation.

A Live contract provides a dynamic method for defining logic on the blockchain, similar to a smart contract. However, the purpose of a Live contract is not just to determine the state of a process but to actively instruct humans and computers about the steps it contains. In other words, a Live contract is a workflow - a sequence of related steps or processes necessary to complete a particular task. Think of it this way: a workflow has rules, where a specific action triggers another action, and so on. A workflow is essentially the general template of a business process.

Example:

Consider a workflow of a simple lease agreement approval, in which a document gets:

drafted
approved
signed

The process we need to define is a specific workflow instance, such as the lease agreement between parties A and B, which was drafted by an employee of B company, approved by the B company CEO, and signed by both parties. A workflow always contains and follows certain logic that acts as the rules and pointers for a particular workflow.

Workflow logic example:

The signing of a document can only come after the document is drafted and approved.
If the document is rejected instead of approved, the process is taken back to the drafting phase of the agreement, followed by a new signing request.

To summarize this:

Workflow + workflow rules = Live contract
DEMO

Difference between Live and Smart

Live contracts define both on-chain and off-chain action. So, when comparing it with oracles, it defines what an oracle should do.
Smart contracts are intended for automated execution; they deal with absolute truths.
This includes the value put on the blockchain by an oracle. In a live contract, there is no absolute truth, only actions and claims by actors.
Live contracts model the current procedure of payment and verification by the counterparty. It provides the tools to automate this by integrating existing systems. It's also easy to escalate the payment flow if needed.
Smart contracts are good at dealing with on-chain (cryptocurrency) payments but can't handle off-chain payments well.

When should you go for Live, and when should you go with Smart?

Smart contract or Live contract diagram - LTO Network, 2019 (click for larger image)

Demonstration of a game played on a blockchain using the Smart and Live contracts

Imagine that we encoded the rules of chess into smart contracts. Smart contracts validate whether the moves you are about to take on the chessboard are valid. The problem with smart contracts is that they were designed to be easily readable by computers, not humans. In a situation when you would want to play blockchain chess with somebody who is not able to read smart contracts nor is familiar with the exact rules of Chess, you would have to provide an application to your opponent that would read those smart contracts for them and display playable possibilities from the current position. The player would see highlighted fields determining his options for a valid move.
The problem that occurs is that we cannot be sure that the paper rules, which we used to code the Chess game using smart contracts, are in sync with those put into a blockchain. Also, we can't say for certain that we read and understood the paper rules correctly before using this knowledge to write the chess-move smart contracts. What if we use an old or unsupported edition of the Chess rules for programming Chess? Smart contracts, as designed, would then allow a forbidden move as valid or call an invalid move as correct.

This is where finite state machines, which create a backbone of Live contracts (sometimes combined with smart contracts combined and oracles) come into play. Using this language, you can create graphs that humans and computers understand.

As a result:

a computer can play a validator role and thus eliminate the error made by the human factor
human chess masters can validate the correctness of a contract written code that specifies the rules.

These graphs can display the player's current state and show the allowed steps from their positions. Oracles would validate that the chess game uses the most updated official rules. Now, instead of having a combination of a blockchain, paper rules, and smart contracts, you can encode and encapsulate all of this into a single Live contract.

However, one critical element would have to be implemented, the last piece, which would seal the whole play of the deterministic chess game using the blockchain. This aspect is called a multi-signature. If two players play a friendly chess game while sharing a table in the same room, there is no big problem. If this was a tournament where human factors can influence the game, both parties must validate and sign a record of each move. By doing so, a player would create a record of their move and a record of the move their opponent has made. This procedure would be followed by adding a player signature to the record, acting as a timestamp. The opponent would do the same. If both records were identical, they would fit into each other and create a block of data called blockchain chess-round-one.

As the game continues, the recordings of gaming events are linearly stored in a sequential order that establishes a blockchain. Now imagine a situation where one of these players needs to leave the room for a moment, and the opponent uses this opportunity to tamper with the current game's state in their favor by modifying a move they made four moves back. Thanks to the blockchain architecture and the way blockchain handles attempts to manipulate the chain's history, the cheating player's next move would automatically disqualify them since their next move would not be in harmony with the history of the moves they already did and recorded. That's an important fact: every action on the blockchain carries the history of previous efforts. This information is then handed over to the upcoming block, keeping the game record accurate, ordered, and protected.

Use this analogy for certification sharing or real estate contracts, and you have a model where a blockchain can make the world a more trustworthy place to live.