Smart contracts increase the level of autonomy of the organization’s workflows. When using the same network protocol and even the same contract code, situations of different levels of autonomy can occur. Therefore, it is important to understand what type of workflow this contract will support.

Smart contracts can be used for two types of tasks in the Ethereum network:

Support of outside world’s workflows with the use of Blockchain technology; Creation of autonomous workflows.

Illustration 1: Support of outside world’s workflows.

Illustration 2: Autonomous workflow.

Using a smart contract to support the outside world’s workflows, we are achieving decentralization of computing and storing data processes involved in the user’s transaction. The result is building trust in the project if the user trusts the workflow algorithms, the oracle and the network protocol.

In the case of an autonomous workflow, the result of converting the user’s input data into the output data by a smart contract is done exclusively by the embedded algorithm. Accordingly, the user’s trust in the project depends on the trust in the workflow algorithms and the network protocol.

A simple example with a token

For example, let us consider a regular token’s smart contract and a token’s smart contract with emission. The main difference between these two tokens is in the presence/absence of the emission function.

Lines 15 -21:

function emission(uint _value) onlyOwner

{

// Overflow check

if (_value + totalSupply < totalSupply) throw;

totalSupply += _value;

balances[owner] +=_value;

}

A token whose emission fulfills Externally owned account (EOA), will be a smart contract, supporting an external workflow.

A token, whose emission is implemented at the moment of its creation and is not controlled by anyone later on, will be a smart contract that provides an autonomous workflow for the user.

An example with the alembic

Let us consider two situations. There is interaction of one token’s contract with another through the alembic contract in each of the two situations, i.e. you send Token 1 to the alembic contract that burns Tokens 1 and emits Tokens 2.

Illustration 3: An example with the alembic smart contract

Situation 1. Alembic with autonomous workflows.

Let us consider two tokens’ contracts with emission and an alembic contract. Let us execute initial emission in each one of them as follows:

Token 1. Initial emission of 10 000 tokens.

Token 2. Initial emission of 50 000 tokens.

After that, we will assign the alembic contract to be the owner of both tokens and assign a proportion of 1 to 5. Accordingly, the alembic contract when receiving N Tokens 1 will have to burn them and emit N * 5 Tokens 2. An vice versa, when N Tokens 2 are burned, N * 1/5 Tokens 1 have to be emitted.

After the alembic smart contract is given the emission functions of both tokens, we are in a situation where no input or output uses any data from the environment in its work. This example reflects a completely autonomous process of tokens and the system as a whole interaction.

Illustration 4: An example with the alembic smart contract (autonomous workflow)

Situation 2. Alembic with an oracle’s influence on the whole system.

Let us perform similar actions at the start, as in situation 1, but we let the user account remain Token 1 emitent.

Illustration 5: An example the alembic smart contract (workflow with an oracle as part of the scheme)

What can we say about the scheme where oracle is included for Token 1 emission? The oracle influences the workflow of Token 1’s smart contract.

Illustration 6: The influence of oracle on Token 1’s smart contract.

But if we take a closer look at the process of interaction between tokens through the alembic, we see that the actions of the oracle immediately and directly affect Token 2 processes.

If in situation 1, with correctly selected initial emissions of Token 1 and Token 2 and the correct conversion coefficient in the alembic, we obtained a completely stable system:

State 1:

10 000 Tokens 1

50 000 Tokens 2

State 2:

0 Tokens 1

100 000 Tokens 2

State 3:

20 000 Tokens 1

0 Tokens 2

State 4:

10 000 Tokens 1

50 000 Tokens 2

Then in situation 2, the actions of the oracle can result in an infinite number of variants of the system’s behavior. Hence the interconnection of tokens and the presence of the oracle that affects Token 1 turns the entire system into support of the surrounding world’s workflows, where the stability of the system depends on the oracle’s behavior. Therefore, users need to trust not only the smart contract algorithms and protocol, but also the oracle in this situation .

Illustration 7: Whole system’s dependency on the oracle’s behavior.

A complex workflow model using smart contracts

The organization can use multiple smart contracts, some of which implement an autonomous workflow and some support external workflows. There is an extreme and, in my opinion, the most complex scheme of interaction, which demonstrates the case when one smart contract participates in various workflows, while some of these workflows are autonomous and others depend on the oracle.

Illustration 8: An example of 2 types of workflows interaction, using the same smart contract.

The illustration above shows the work model of the organization using the “Ether bank” contract in order to safekeep payments for insurance events of the participants in the farmers insurance contract based on weather data from the oracle.

That said, other users can interact directly with the “Ether bank” smart contract in order to safekeep their funds.

As a result of it, if the “Ether Bank” contract is implemented by the farmers insurance system, this contract participates in a workflow depending on the oracle — and therefore for the farmer, “Ether Bank” supports the workflow from the outside world.

Illustration 9: The “Ether bank” contract supports the outside world’s workflow.

From the point of view of direct users of the “Ether bank” contract, this contract supports an autonomous workflow.

Illustration 10: The “Ether bank” contract supports an autonomous workflow

On the path of DAO

A decentralized autonomous organization has to use autonomous workflows in order to maintain its own workflows. The oracle for DAO is a way to reduce the society’s dependence on the usual regulators of organizational processes that can turn into autonomous. This way, DAO does not depend on oracles, but rather provides tools which enable some part of the workflow becoming autonomous.

Glossary