The Keys to Successful Token Implementation

Challenges laid down to blockchain students in Swiss competition

Christoph Mussenbrock, co-founder of Etherisc, has recently delivered a lecture about implementing token payments, as part of the Blockchain and Internet of Things (BIOTS) program at the Swiss Federal Institute of Technology in Zürich. He used his experience in building Etherisc’s Flight Delay DApp and the Decentralized Insurance Protocol to create his lecture and provide two challenges to students as part of the BIOTS program.

Christoph shared some lessons learned in developing and deploying a large-scale complex smart contract system comprising seven interacting contracts. “You can assume that anything that can go wrong, will go wrong,” he noted. “Always assume that your contracts will be attacked, and you will lose money if you don’t apply utmost care. This is not like your normal development process, where some bugs can be tolerated.”

The Etherisc smart contract system — built upon the de-facto standard Solidity language — is the starting point for the upcoming standardized decentralized insurance framework. It allows for a wide class of parametric insurance products and a very short time to market due to separation of concerns and encapsulation of product-specific parts in pluggable components.

An architecture of the Flight Delay DApp

To demonstrate it, Christoph took the students through the basics of the Flight Delay payout transaction. The steps included making a query, raising an event, then consulting with a flight table oracle to see if the flight was delayed or not. The oracle then puts the information on blockchain, makes a callback, and triggers a payout if required.

The business logic and data storage are separated, so in case of a product upgrade, the individual parts of the smart contract can easily be updated, too.

Preventing problems throughout the transaction process

Christoph noted that the notorious “owned patterns” have been extended to a complete access control system, which ensures that all the contract functions can only be called by properly authorized other contracts or addresses. Cryptoassets are held only in the Ledger Contract, which is highly protected, so even if some component has a weakness, the funds are still safe in the separate Ledger Contract.

The onlyOwner modifier checks if the contract is called by the owner

To avoid the potential problem of paying out a claim more than once, Christoph described the state machine logic, which is the backbone of the business processing engine. Each transaction has states like active, expired, or paid out. (Expired would describe a transaction, in which the flight was not delayed, no payout was made, and the contract had expired.) State transactions are only allowed in predefined paths, and this protects from double payouts.

Challenging the students

As part of the BIOTS course, instructors were to provide challenges to the students. Christoph instructed his students to build a token payment system (rather than simply having a payout made in Ether) and to figure out a way to evaluate a new token being generated by a new blockchain company.

Students were challenged to create token payments and staking

To address the first part of the student’s task, he described how giving someone else the power to move tokens from an account could be a simple process that’s analogous to writing a check. He urged the students to look at the ERC20 token standard and its extensions, especially the approve and transferFrom functions which implement the cheque function in the ERC20 compliant token.

Upgradeability as core concept

It is often said that “immutability” is a core concept behind blockchain, which in Christoph’s opinion is not true. If taken literally, no transfer of funds would be then possible. Actually, the only immutable part of a blockchain are the already mined blocks. The “current state,” including the balances of all accounts, and, in case of Ethereum, the data, which is stored in the smart contracts, is “mutable” from transaction to transaction. Within the von Neumann architecture, code and data are first-class citizens and share the same fate. Thus, it is quite natural to build smart contract systems, where you can modify the code. “But the code is immutable, ” some may argue.

In the Etherisc Smart Contract System, smart contract functions are rarely called directly. Instead, before calling another smart contract, the calling contract performs an address lookup in a contract registry to learn about the currently valid version of the called contract, which can be changed programmatically — surely, only with the appropriate access rights.

Thus, contracts can be “upgraded” by simply deploying a new version, changing the registry, and the new contract will be called from that time on. If desired, the old contract can be removed by self-destruction.

While upgrading code is easy, database upgrades come at high costs. If you ever need to migrate a large database, you may face two problems. Firstly, storing the new data is expensive, and, secondly, you can’t simply loop over two million records.

Etherisc is working on an architecture, in which database contracts can be linked to the updated versions. According to Christoph, “blockchain is not, say, a MySQL database, in which you can simply add a field. You should not alter your architecture too much.”

Christoph also lauded the transparency that comes with this potential difficulty. “If a traditional insurance company changes their software system, nobody knows,” he pointed out. “But if we change our software system, everybody knows. This is the difference between blockchain and classical IT infrastructure that fits our values of transparency and fairness.”

Stability is another virtue

Christoph also explained the use of token staking as a very fundamental mechanism to incentivize processes, similar to traditional service-level agreements, where promises are made to deliver certain services in specific times and at specific quality levels. “With an insurance policy, there are many people who need to cooperate in specific ways,” he said, “so we need a mechanism to incentivize people to deliver this services in time.”

As far as evaluating a token, he mentioned the twin parameters of transaction volume and average holding time as drivers for a token price. A high transaction volume implies a strong value for the token, but if no one is actually holding it, the token will have no value. This is a direct consequence of the fundamental equation of exchange. However, if people are incentivized to hold some tokens, simple supply-and-demand principles kick in, velocity is decreased as demand and value are increased.

Want details? Watch the video!