Getting a Protocol To The Mainnet

Those who have been following Livepeer for awhile know that the project has been iterating for almost a year, and hitting a number of milestones on the path to launching a fully decentralized live video broadcasting network. In March, Livepeer demonstrated peer to peer streaming built on top of Swarm and web3 technologies through a proof of concept release. In May, Livepeer published its technical protocol details in the Livepeer Whitepaper. In September, Livepeer launched an internal test network, which introduced incentives and security to the system running on a private Ethereum blockchain. While there’s a long roadmap ahead, the goal remains to launch Livepeer on the Ethereum Mainnet in short order. At that point the network should be useable and scalable for video broadcast, and the project can begin to decentralize, and move beyond just the core team and contributors to a whole network of stakeholders who are incentivized to participate in different roles.

Yet on the path to the mainnet deployment, it has become clear that there are a number of challenges that Livepeer, and many other decentralized protocol projects will face. Some such areas are:

• Protocol Upgrades — Mechanics and Invocation Methods
• Parameter Tuning
• Genesis
• Forkability

The designs that these projects implement and put in place around these challenges will have long reaching implications in the governance, decentralization, and iteration flexibility going forward. In a perfect world, one could hope that a project could be deployed on a blockchain requiring zero upgrades, having perfect mathematically calculated and self-updating parameters, with a simple genesis state and easy forks. But those who have shipped software know that the project is never done, and even Bitcoin which was as close to perfect on all these accounts from the get go as could be hoped, has still required quite a bit of iteration and protocol enhancement over the years.

While each of these areas is critical, it’s also important to note that even though these are common across projects, they have very little to do with the core value that any one project may be trying to deliver. Easy forkability does little to lower the latency on a p2p live video stream for example. If decentralized projects can leverage common practices, libraries, and frameworks for addressing these issues, then they can spend less time building around these areas, and more time focused on the core tech that’s unique to their ecosystem.

The rest of this post includes some thoughts on how Livepeer is approaching the above challenges in an effort to get the protocol to mainnet as soon as possible.

Protocol Upgrades
Protocols that are deployed as Ethereum Smart Contracts may need to be upgraded to add additional functionality, or they may need to be upgraded because things go wrong — bugs, security vulnerabilities, or incorrect economic assumptions. It’s important to recognize that this may be necessary and to prepare for it in advance. It’s also important to distinguish between the technical implementation of “how the upgrade occurs” from the governance question of “how the upgrade process gets invoked.”

With regards to the technical details of how to upgrade a complex set of smart contracts that are immutable on the blockchain, we started out doing a survey of various mechanisms. This reddit post shares a high level summary of the approaches that we found. In short, there are options for deploying new versions of the contracts and migrating state, separating state from logic and only deploying logic upgrades in new contracts without needing to do migrations, and more complex proxy/forwarding methods. Each trades off ease of implementation and execution, continuous liveness of the protocol, and governance concerns.

Livepeer has implemented the proxy/forwarding pattern in which all calls come into a simple smart contract that stores state and forwards calls to the logic contracts using DELEGATECALL. The details are a little technical for this post, but this allows Livepeer to upgrade logic without needing to migrate data in many cases, so the protocol can run continuously.

As to how protocol upgrades get invoked, the goal is of course decentralization. Entire blockchain projects are built just to address the governance of protocol upgrades. Users and stakeholders should have a choice. And this is where the ability to fork comes in, which will be addressed later. In the early phases of the network, while the community is observing behavior and potentially reacting to any bugs or exploits, it is likely that upgrades can be enacted by a multisig, in order to move quickly and mitigate issues. As the protocol moves beyond alpha and beta in the later phases of the network, this can be migrated to the stake based governance which enforces required voting amongst transcoders, that the project is striving for. Absent critical bugs, protocol upgrades should be communicated well in advance, well tested, and designed to give users a choice whether to move along and migrate to the latest version. A well defined project roadmap that the community comes together to design and take part in can help prepare the ecosystem for the expectation of upgrades at certain milestones.

Parameter Tuning
There are a number of parameters in Livepeer, and all protocols, which are set with a best effort — hopefully rooted in some sort of mathematical or economic reasoning tied to the incentives of the protocol, but possibly selected somewhat arbitrarily. These numbers may need to move over time if they prove to be incorrect or lead to less than desirable behavior. Some examples in Livepeer include:

• Verification rate — what % of segments of transcoded video get challenged and verified?
• Slashing amounts — what % of your bonded stake does a transcoder lose if they cheat and output incorrect live video?
• Inflation rate

Verification rate is dependent on external factors that will change over time, such as the cost to invoke the Truebit smart contracts for verification of work, the price of gas on the Ethereum blockchain, and how much the network tolerates potential inefficiencies. For something like this, it makes sense to move via governance, in order to avoid full protocol upgrades. Again, in the early days enactment via a multisig may make sense, but decentralized stake based enactment is the goal in later phases.

Inflation rate is interesting, because unlike a system like Bitcoin, which is meant to be used as currency, Livepeer is used for video broadcast and is meant to be staked in order to participate in the quality and security protocol that ensures a useful network. Therefore the inflation rate moves as a target to incentivize proper participation depending upon market conditions. This is a parameter that can likely move algorithmically without human or governance intervention, depending on the current participation rate.

Genesis
As a stake based system, for Livepeer to truly be as decentralized as it aims to be, it is important that the token be distributed widely at the genesis state of the network. Else, the few stakeholders would be able to gain a majority of all issuance of future token through inflation, because only stakeholders who bond and actively participate will earn inflationary token rewards.

Standby for more to come on the procedure for token distribution, but note that it will be important that the distribution coincides with the launch of the live network, and a period of time for stakeholders to bond and delegate effectively to a decentralized set of a participants in time to kick off the live network. Some projects have referred to this time period as “the delegation game.”

Enough has been written about token distribution mechanics, but not enough has been written about the technical mechanics for setting up the genesis state of the network. For projects that seek a large amount of participation through bonded stake (potentially over 50% or 66% targeted participation), how the network gets “started” can have long reaching effects for the balance of decentralization in the early days.

Forkability
It was mentioned previously that users should have a choice in the protocol that they participate in, and whether or not they move along with protocol upgrades or not. In a traditional native blockchain protocol such as Bitcoin or Ethereum, users can make this choice via a fork — copying and then modifying the protocol code to enact the changes they believe in. In a protocol like Livepeer this is also possible. However, it’s both complicated and made easier by the fact that Livepeer runs as smart contracts on the Ethereum block chain.

The complications are introduced via the upgrade mechanisms that were mentioned above. If the protocol undergoes an upgrade, depending on the implementation, the previous version of the protocol may cease to work. (This is because only one version of the protocol can “own” the token and mint new ones via inflation mechanics). This alone, would not be aligned with giving users a choice.

However, it’s also made easier in certain ways due to the smart contract implementations. The Livepeer smart contracts are open source of course and can be redeployed many times over on the main network. This still leaves the challenge of copying state over to the newly deployed contracts from the currently running protocol, but fortunately Livepeer implements a “GenesisManager” contract which can be used to set initial state. While there would be some work in supporting a fork, this could be automated via state snapshots and migration scripts.

—

In summary, Livepeer prioritizes decentralization. It’s a goal that the project has laid the groundwork for and will work towards as quick as possible over time. Like all projects trying to launch and get to the mainnet however, it will have to balance the ability to test, iterate, collect feedback, and deliver on the roadmap, with the benefits that decentralized governance and upgrade mechanisms will bring. If you have feedback, ideas, solutions, or common approaches related to any of the above areas, don’t hesitate to jump in and let us know. We’re open to collaboration opportunities on standardizing some of these practices for use across many decentralized protocols running on Ethereum.

For further updates on Livepeer, you should follow @LivepeerOrg on twitter.