lisk

Remember the joke about the two men in the woods who meet a bear – one says to the other, "I don't have to outrun the bear; I just have to outrun you."

Decentralisation is a relative term. We must also remember this is early days: the dial-up stage of the internet. Blockchain systems are arguably kosher as long as they can guarantee better decentralisation than traditional options, without burning as much electricity as Bitcoin does.

One alternative to proof-of-work is delegated proof-of-stake, where stakeholders vote on a set of delegates who are allowed to create blocks and establish consensus on the network. It attempts to solve one problem which affects other proof-of-stake protocols, whereby those with the most stake will tend to dominate the economics of the system, because in delegated proof-of-stake smaller stakeholders can always exert proportional influence by way of their votes.

A particularly strong and vibrant community stands behind Lisk, and one of the most hotly debated topics is its delegated proof-of-stake system. There are only 101 delegates forging new blocks at any one time. One way for delegates to provide their voters with an incentive is to pay them back a percentage of the LSK they generate from forging. Voting for pools that redistribute a percentage of their rewards is an easy way for delegated proof-of-stake network participants to realise additional value.

Full stack developer at Lisk, Will Clark, who studied philosophy at Oxford, finds the whole crypto-economics thing enthralling.

"There is this fundamental difficulty with proof-of-stake algorithms, where if you have enough stake then the assumption would be that you can do what you want. It's interesting because in terms of game theory, that would be the obvious conclusion.

"But things are a bit more complex in real life. So for example take one of the top Lisk delegates which is a pool: you vote for this delegate and then they share 75% of the proceeds with everyone who votes for it."

This pool also has a bunch of other registered delegates with even higher sharing percentages; Clark said you might expect that if everybody who voted for the original delegate voted for all the others, then they would just fill up all of the lower slots with all of these delegates from the same individual. "That hasn't happened," he said. "And it's kind of unclear why."

It seems that certain members of the Lisk network have formed special interest groups within the ecosystem. "From a game-theoretic viewpoint you would imagine these groups would be acting from self-interest," he said. "Obviously they want the network to do well because they benefit from the increase in token value associated with that. But they don't want members of other groups or other members of the same group to take over their forging position either."

"I think it's going to be interesting to see how this evolves over the next few years, especially if more money comes in from outside, which can always change the dynamics inside."

Lisk has been busy with its SDK and getting side chains implemented, but CEO Max Kordek has said more attention will also be directed at the consensus algorithm going forward.

Clark said: "One positive feature of Lisk's community which frustrates the game-theory perspective is that a lot of members are these passionate early adopter blockchain enthusiasts who take the state of decentralization of the network very seriously."

Something that Lisk decided to deal with now in order to increase voter participation was the need to introduce a dynamic fees system; with a fixed fee of 25 LSK, at one point it had become a prohibitive $500 to be a delegate, and to submit a vote transaction (1 LSK) was about $30. Generally speaking, Clark takes a philosophical view regarding the development of the various consensus systems.

"It's going to be really interesting to see which ones survive and which ones don't. I think it's quite possible that some systems could have a consensus algorithm that is discovered to be broken – or perhaps just strictly inferior to some other option.

"There are a lot of permutations with proof-of-stake options that you can make. While doing this fine tuning you might discover not do to things one way because another way is always better.

"But then there are also so many different use cases for blockchain that it's very plausible that multiple consensus algorithms will fill different uses."

Sidechains & ICOs

An exciting development is allowing projects running on sidechains to do initial coin offerings on Lisk.

"The idea is you will register your dapp with a certain transaction on the mainchain and then people can send Lisk funds on the mainchain to that account," said Clark. "Then you can reward them with tokens once your own network is running."

So will there be a token standard, the Lisk version of an ERC20?

"Sidechains will be their own separate thing, so it's up to you to define how that functions exactly. We provide a lot of default functionality and recommendation standards and stuff like that but if you want to replace it with your own thing then that's up to you."

Lisk's conception of sidechains is a way to grow a wide and multifarious ecosystem which can efficiently scale. Blockchains become rather unwieldy when everybody is running decentralised applications on the same chain and everybody's data has got to be in the same place, recorded by everyone and so on. A possible solution being explored by the likes of Ethereum is sharding.

"I think sharding is currently a huge unknown," said Clark. "It would be very cool to have a more efficient way of storing data. Having however many tens of thousands of nodes all keeping a record of the full Bitcoin blockchain is a super inefficient database, but the more replication you have the more security you have."

Clark said sidechains can be thought of as a type of sharding. There's not a single network but an ecosystem of networks and each individual network is responsible for storing some subset of the data. Then the extent to which some piece of data is replicated is dependent on how many people are interested in replicating that data.

"So the mainchain is presumably going to have a lot of replications and that's good because you want it to be really secure. Whereas some new dapp that nobody knows about only has five replications that are maintained by the original creator – and that's great because nobody else has to store that data," he said.

"More established dapps may have a lot more people saying 'keep this secure' so they will replicate it, or maybe they will be running some client applications and therefore interested in keeping a record of that data."

JavaScript developments

JavaScript gives Lisk an almost infinite potential in terms of future blockchain building. Being privy to such an enormous developer community also comes with some criticism. For example, JavaScript introduces non-deterministic features and people say its flexibility encourages insecure programming practices.

Clark, an expert on JavaScript, said: "We are incorporating more functional patterns into our code. It's very popular in the JavaScript community to go for more immutability and functional reactive programming; having all your state stored in one place so you can more easily keep track of it, and then just loop it through functions.

"Alongside that there are tools for adding strict types for example, which can catch a lot of otherwise basically undetectable bugs."

This is one of the next steps for Lisk Elements, which is Lisk's general-purpose JavaScript library. Clark said there are a couple of major developments coming up and one of them is to add a typing system. "That will basically be set up as the tester for the Lisk set of projects to help make it more secure.

"JavaScript is very friendly, and part of the reason for that is that you can basically do anything you want. That's great for people who are learning and getting used to programming languages, but it's not so great when you get some subtle type discrepancy that opens up a problem you can't really detect.

"We are aware of that kind of thing and the JavaScript community in general is working really hard on these problems.

"Regarding non-determinism, obviously we're not going to recommend people write their smart contracts using the full feature range of JavaScript! You need determinism in blockchain systems because everyone has to end up on the same page, but it might still make sense to use something that's JavaScript-inspired."