On the Origin of Lisk

Published in

On The Origin of Smart Contract Platforms

16 min readMar 3, 2018

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at how Lisk could challenge the dominant platform, Ethereum.

Lisk evolved out of the now defunct Crypti blockchain project. On January 30, 2016 community manager Max Kordek and developer Oliver Beddows announced that they were leaving the project to create Lisk from a fork of the Crypti code. The new, fully open source, project would feature several improvements to the network, applications, ecosystem, and project management that would make Lisk more viable and sustainable. A few weeks after the initial announcement, Lisk conducted a four week long ICO that raised over 14,000 Bitcoin plus about 1000 Crypti. Crypti was accepted to provide “an escape route to a fresh project for the whole Crypti community.”

On May 24th 2016, just five months after the project announcement, the Lisk mainnet was launched, enabling investors to acquire and trade the native LSK token on exchanges. Kordek and Beddows then created the Zug based, non-profit Lisk Foundation to manage those funds, and the Berlin based for-profit Lightcurve to provide software and community development services to the foundation. On February 20, 2018 Lisk held a Relaunch Event to announce the completion of software development milestones, launch the Lisk Academy for blockchain education, and showcase a new product suite, website, logo, and brand identity for Lisk.

Lisk is the first project in this series that is actually not a smart contract platform. It is a blockchain application platform in which smart contract execution is an optional add-on service. The Lisk blockchain does not store application code, as is normally done with smart contract platforms, but supports a primitive (but extensible) set of predefined transaction types. While this architecture is significantly different from other projects that we’ve looked at in this series, Lisk is worth studying because the project is competing to become the global platform for decentralized applications (dApps).

Although Lisk already has a running blockchain, the project is significantly less mature than Ethereum. The blockchain application SDK, a key component that facilitates building decentralized applications on Lisk, was slated for release in 2017, but that release has been delayed due to unexpected architectural and code quality issues requiring rewrites of several key subsystems. Nonetheless, there is enough documentation on Lisk’s basic design to compare it to Ethereum.

This article will examine the technologies of both projects to assess whether Lisk can supplant Ethereum as dominant platform (and whether this series of articles will need to be renamed “On the Origin of Decentralized Application Platforms”). Let’s dive in.

Performance

A key performance advantage that Lisk currently has over Ethereum is that it uses Proof of Stake (PoS) consensus algorithm rather than Proof of Work (PoW). In PoS consensus, a node is granted the right to produce a block probabilistically based on the number of tokens it has staked, rather than by winning a race to solve computationally difficult puzzle, as in PoW. Since PoS nodes don’t burn computational resources solving puzzles, blocks can be produced at very tight, fixed intervals and significantly more transactions per second can be processed by relatively inexpensive nodes.

In PoW, attempting to increase throughput by increasing block size or shortening the average time between blocks (by reducing the puzzle difficulty) increases the probability of stales. Stales are valid blocks that lose the propagation race to another valid block mined around the same time, so they don’t end up in the canonical chain and produce no reward for their miners. Shorter block times result in more close races that will most often be won by well-connected, higher bandwidth miners. Over time this economic advantage weeds out less equipped miners and increases miner centralization. Ethereum’s PoW algorithm addresses this issue to some extent by including valid blocks that lose the race and rewarding their producers. This allows Ethereum to achieve higher throughput with somewhat lower, but still variable, block times.

Due to the scalability, environmental, and security issues inherent to PoW, a switch from PoW to PoS consensus is in the Ethereum roadmap. This switch has been slow to roll out, however, because PoS introduces several new challenges in securing the network. When entire chains can be easily and cheaply constructed, great care must be taken to ensure that block producers are financially incentivized to always follow the consensus rules.

Ethereum’s Casper family of PoS protocols are being rigorously constructed to address several known issues with PoS in a public blockchain context. They are designed to work in an open network in which all stakeholders can participate in consensus and any number can be considered adversarial. They make it expensive to attack the network by requiring consensus participants to make deposits, which can be forfeited for not following the protocol rules. The roll out of these protocols will happen in at least two phases. The first phase will continue to use PoW for block production but will overlay a PoS consensus algorithm to create economic finality on every 50th block. A later phase will replace PoW entirely with PoS, at which point increases in throughput will be realized.

Lisk implements a modified version of the Bitshares Delegated Proof of Stake (DPoS) consensus algorithm, which has some significant differences from Casper-style PoS. In DPoS most stakeholders don’t produce blocks, but instead vote their stake for delegates who do. Delegates are presumed honest by virtue of having been elected, and can ostensibly be voted out for dishonest behavior. Delegates share a portion of their earnings with stakeholders who vote for them. At the beginning of a round — a period in which 101 blocks are produced — the 101 delegates with the most stake voted for them are each allocated one 10 second slot in which to produce a block. The selection of delegates and allocation of slots is predetermined by the consensus rules using votes recorded on the blockchain.

In an open blockchain setting, DPoS has a number of well-known challenges associated with stakeholder voting such as low voter participation, insufficient individual incentivization, difficulty of voters staying informed, and centralization of voting power (in whales, pools, and exchanges). These are not just theoretical concerns; the Bitshares DPoS implementation was afflicted with voter apathy and now the same issues are playing out in Lisk. Under current conditions, control of all 101 delegates can be obtained with as little as 20% of the total stake. The Lisk Elite, a delegate pool that requires stakeholders to vote for all (currently 54) of its members in order to receive any rewards, has effectively created a perpetual delegate majority that is accumulating stake (and thus voting power) faster than the rest of the community combined, making it increasingly more difficult to vote out the cartel.

We discuss the issue of cartel formation in more detail in the Governance section below, but, with regard to performance, it should be clear that increasing transaction throughput with DPoS can introduce centralization and censorship issues that are antithetic to principles of an open public blockchain.

Scalability

The current scaling hurdle for Ethereum and most blockchain platforms is that every node has to process every transaction so transaction throughput cannot scale beyond the processing power of a single node. There has been a lot of research into mechanisms in which nodes only have to process a subset of transactions. Some of the more promising approaches include state channels, verifiable offchain computation, sharding, and sidechains.

Lisk addresses scalability by introducing sidechains as a fundamental component of the platform. The Lisk SDK is called a Sidechain Development Kit because it creates an independent sidechain for each application. Having each application run its own sidechain allows the network to scale by adding more transaction bandwidth as new applications are deployed. It also allows each application to set its own network parameters to best meet the needs of its use case.

Initially, Lisk sidechains will have to use the same consensus algorithm as the main Lisk network, so each sidechain will need a set of validators to secure it. Procuring enough validators to secure an application’s sidechain in perpetuity is the application developer’s responsibility. Ideally, the developer can create a transaction fee structure that attracts delegators and serves the needs of users. Otherwise, she can rent services from a pool of DPoS delegates found in the Lisk delegate marketplace. In any case, placing this operational burden on developers may limit participation to only those application builders that can adequately secure their sidechain. This would work against Lisk’s core value proposition to make it easy to build and deploy blockchain applications.

The total supply of delegates in the marketplace must continually grow in proportion to the number of applications, otherwise the cost to secure an application sidechain will rise (making the system even more exclusionary) and the overall security of Lisk sidechains will be reduced. According to Ethereum researchers, simply adding more chains has the following flaw: “an N-factor increase in throughput using this method necessarily comes with an N-factor decrease in security.” Although this formula may be overly pessimistic in assuming that the total capacity to validate transactions would not grow with the number of chains, it illustrates that there is a scalability for security tradeoff involved in adding an unlimited number of independent chains.

Awareness of this tradeoff has directly influenced the design of Ethereum’s sharding, a scaling solution similar to Lisk’s sidechains, but with some important differences. In Ethereum, each shard has its own sidechain, but there are a fixed number of sidechains that act more like extensions to the main chain than independent application-specific databases. The state of each shard’s sidechain is hashed and periodically recorded in the main chain, and all sidechains leverage the security of the main chain (i.e. the fork choice rule is based on the state hashes recorded in the heaviest fork of the main chain). In contrast, Lisk has a variable and unlimited number of application-specific sidechains that are secured independently of the main chain.

Shard sidechains are secured by a global pool of validators running the main chain consensus protocol (Casper PoS for Ethereum), similar to Lisk’s delegate marketplace. However, in Ethereum, validators aren’t contracted to work on specific shards; instead any participating validator can be randomly selected to secure any shard at any point in time. To accomplish this without requiring each validator to store the full state of each shard, transaction senders will have to provide pointers to the specific branches in the state tree that the transaction affects. The upside is that random assignment of validators to shards makes it impossible to attack the sharded system by compromising just a small number of validators on one specific shard. To compromise one shard the attacker must compromise enough of the global validation pool to compromise them all. Under Lisk’s current design, where the set of elected delegates assigned to a sidechain is publicly known and fairly static, compromising a single sidechain can be relatively cheap.

In theory, the independent functioning of Lisk sidechains would prevent security breaches, failures, and congestion in one application from affecting other Lisk applications. However, a key part of the Lisk vision is to enable “blockchain services” such as identity and smart contract execution that can be leveraged by other applications in the Lisk ecosystem. Such shared services would make it possible for congestion in one client to affect other clients by overloading the service, and for a security breach or failure in the service sidechain to affect a large number of client applications (more on this in the Security section below).

Ethereum’s initial sharding implementation will consist of 100 sidechains, so the increase in network capacity across all applications will initially be capped at 100x. Sharding is a scaling solution, however, because additional shards can be added as the capacity of the validator pool grows. Similarly, the growth of Lisk’s delegate pool capacity will determine the degree to which it can scale by adding new application sidechains. Whereas expansions of the Ethereum network with shard sidechains will come about through carefully controlled protocol upgrades, Lisk will add sidechains organically as applications are deployed.

If the demand for securing Lisk sidechains outpaces the growth of the delegate pool, we could see delegates allocating their resources to the most lucrative sidechains and leaving most other applications without adequate security. Max Kordek once wrote that the the biggest weakness of Lisk is sidechain security, “small dApps probably won’t have a chance long-term to attract enough nodes to secure them.” Although this form of natural selection might be an efficient way to allocate resources towards the best applications, it could lead to an application oligarchy that limits open participation.

Plasma is another Ethereum scaling solution that supports an unlimited amount of sidechains that are secured by smart contracts on the main chain. In Plasma, no assumptions are made about the honesty of block producers on the sidechain. If block producers misbehave, users can exit the sidechain and reclaim their funds on the main chain via the smart contract. Similarly, fraudulent exits can be challenged and blocked via the smart contract. Like all layer 2 mechanisms, Plasma requires users to pay careful attention to transactions on their sidechain and take swift action when necessary. The overall scalability of Plasma is limited by the capacity of the main chain to handle mass disputes. At the present time, Lisk sidechains are not secured by the main chain, but once they are deployed and experience is gained securing them, some kind of main chain adjudication could be introduced.

Plasma, sharding, and Lisk sidechains are all currently under development and their implementations could deviate significantly from current specifications. It’s not clear when any of these will be deployed but sharding and sidechains are key components of their respective project roadmaps. Once deployed, innovations can be rolled out more quickly without risk to funds stored in existing accounts because of the relative independence of sidechains from existing accounts in both projects.

Governance

At present, Lisk is still in its very early stages and thus all decisions about the main chain protocol are dictated by the core development team and Lisk Foundation. One might expect that Lisk sidechains will enable the possibility for application-specific governance models, but this topic is not currently covered in the Lisk documentation. The extent to which application developers can govern their own sidechains will be determined by the sidechain customization capabilities granted to them and their ability to get their software changes adopted by delegates.

The Lisk mainnet is secured by a set of 101 elected delegates. As mentioned above, the tenure of the Lisk Elite delegate group has caused significant consternation among community members regarding the distribution of rewards and transaction fees. Max Kordek has stated that the Lisk Foundation is concerned about the dominance of cartels and is forming a new Science Team to address this issue with protocol changes.

It will be interesting to see what types of protocol changes are deployed and to what extent these changes addresses the inevitable issue of cartel formation in an open blockchain context. The fact that all the necessary coordination to form a cartel can occur off chain makes it difficult to combat solely with on chain protocols.

One defense often proposed is for users to notice and coordinate (off chain) against the cartel, though the Lisk community is struggling with some real barriers to mounting this type of defense. However, the Lisk Ascend delegate pool, a group of verified Lisk contributors promising a more equitable distribution of block rewards to their constituents, is making headway. They are employing a pledge system to make it more cost effective for users to coordinate their votes and unseat the cartel. At the time of writing, Lisk Ascend has about 15% of the pledges it needs to be voted into forging positions, but that number appears to be growing steadily.

Ethereum’s Casper is attempting to address cartel formation at the protocol layer by heavily penalizing block producers who appear to be censoring other block producers. This approach can be effective in the context of Ethereum’s egalitarian (i.e. non-delegated) PoS model, where the only privilege afforded to participating stakeholders is producing blocks. Under these constraints the censorship of non-cartel blocks is machine detectable, though some false positives can occur when validators are simply offline versus being censored.

However, in Lisk’s DPoS, where block production rewards go to a small group of elected delegates who set the rules for participation and redistribution, cartels can accumulate wealth and power and shut out non-cartel members in ways that appear completely democratic and fair to machines. Allowing delegates to make rules with their delegated voting power provides powerful incentives for cartel formation that could not be addressed by protocol code. Imagine how the game of Monopoly would change if the banker were allowed to set prices and make rules versus being limited to just processing no fee transactions.

If on-chain voting enables a form of censorship that is undetectable by machines, and incentives to coordinate extend beyond mere block production, it’s unlikely that protocol changes alone will be able to completely disincentivize cartel formation. Without vigilant watch and significant off chain coordination, DPoS implementations on open public blockchains can end up functioning more like consortium chains where a high degree of trust must be placed in the elected group of delegates to benevolently wield their power. This is what we see playing out with the Lisk Elite and Lisk Ascend factions.

Unless the issues of voting in a representative democracy are miraculously solved (after nearly a century of game theory research and millenia of democracy have failed), platforms that use DPoS to gain transaction throughput at the expense of censorship resistance (or worse) are not likely to succeed in dominating the decentralized public blockchain space. In contrast, Ethereum, by limiting the capabilities of (non-elected) stakeholders to block production, may be able to effectively disincentivize cartel formation with protocols that govern the production of blocks.

Security

On April 19th 2016, Max Kordek wrote, “If a dApp fails, the Lisk network doesn’t even hiccup. However, if one smart contract fails at Ethereum, it can mean game over for Ethereum.” Two months later a hacker exploited a bug in the DAO contract and stole nearly 15% of all ETH in existence at the time. The theft was reversed by a controversial hard fork that led to a community split and the formation of the still vibrant Ethereum Classic platform. In July and November of 2017 two vulnerabilities in the Parity multisig wallet, which affected nearly 600 wallets and put over 500k ETH at risk, were exploited allowing funds to be stolen and frozen. There were no bailouts and no community splits for Ethereum in 2017. Although these hacks did not spell “game over” for Ethereum this time around, one has to wonder how much more ETH can be lost before the Ethereum platform goes extinct due to lack of security.

Max’s statement may be more relevant today than it was when bailouts were more acceptable in the Ethereum community. However, the premise of that statement — that a vulnerability in one Lisk application would not affect other Lisk applications because they run on separate blockchains — is false. The reason nearly 600 wallets were simultaneously affected by a single vulnerability is because they shared the same code, not the same blockchain. If each wallet instance existed on its own blockchain, all of them would have the same vulnerability to a single exploit.

Regardless of how applications are deployed they will share common code. Whether this be in the form of shared services, libraries, or even cut and pasted from other projects, software developers do not like to reinvent the wheel. Max Kordek writes, “The best part is, if you need one of these services in your Lisk blockchain app you don’t need to re-implement everything. You can just plug into third party technologies and leverage their functionalities from within your Lisk blockchain app.” Later in the same post, examples of such services are given: identity, storage, smart contract execution, and oracles. A vulnerability in any one of these could have severe consequences for all client applications simultaneously. For example, a compromise of the identity service that allowed an attacker to pose as anyone could allow that attacker to drain all accounts in all applications relying on that service.

It’s important to note that the currently proposed implementation for Lisk’s smart contract execution service is to use Ethereum. This implementation would expose all applications using that service to the same vulnerabilities that currently plague Ethereum. So it could be the case that a single vulnerability spells game over for Ethereum as well as all Lisk applications using the Ethereum-based smart contracts service.

Conclusion

Lisk is markedly different from other platforms covered in this series in that its focus is not on smart contracts; they are an add on service that will initially just leverage the Ethereum platform. Lisk’s focus is on addressing two key barriers to growing a vibrant blockchain application ecosystem: scalability and ease of application development. Lisk plans to scale using DPoS sidechains and to enable creators to build blockchain applications using a familiar language and a powerful SDK.

Lisk has a running blockchain, but the only application it currently supports is the transfer of tokens. When the remaining SDK pieces that allow applications to be developed are released and Lisk applications are built and deployed, we’ll know more about the viability of Lisk as a decentralized application platform. As Lisk grows, we’ll see how it addresses the issues related to voting and cartel formation in DPoS systems, whether it can attract enough validators to make sidechain scaling viable, and whether it can deliver on its promise to isolate faults and security breaches in applications that use shared blockchain services.

These are non-trivial problems that will likely require a sizable research effort and significant changes to the current architecture to solve. This effort must be comparable Ethereum’s, which is addressing similarly difficult challenges. At present, Lisk’s research and development efforts are not comparable to Ethereum’s, but Lisk is a well-funded project that is progressing quickly and pragmatically. It’s likely that Lisk R&D will ramp up significantly in the coming months.

At present Lisk is far behind Ethereum in deployed technology, research, and network effects with no signs of revolutionary ideas that would flip this. Lisk’s primary innovations — Scaling with sidechains and providing a pure Javascript development environment for building blockchain applications — are advances that Ethereum can approximate easily enough with sharding and improved development tools. If Ethereum is to see a mass migration of developers and applications, it will most likely be due to continued security breaches resulting in major losses of funds held in smart contracts. In this scenario Lisk would not be the likely place of refuge, especially if it uses Ethereum as a smart contract service.