Livepeer’s Path To Decentralization

The aim of the Livepeer protocol is to incentivize the creation of a fully decentralized live video platform. In particular, Livepeer emphasizes open access to build and broadcast on a level playing field. Any machines speaking the protocol can join the network, use the network for its intended purposes of encoding and distributing live video, and participate in the economic opportunities that are presented to users who contribute compute or manual resources in service of the network. No central party or company needs to be relied upon for the continued operation of the network. Decentralization brings many benefits in general — and especially in the context of video which can leverage distributed computation and content delivery — but there are also many costs to decentralization such as the practical implementation challenges.

The Livepeer Whitepaper lays out the design for a system which is fully decentralized, but the path to getting there in reality will take significant collaboration from the entire Ethereum and decentralized tech communities over the course of multiple years. Still, there are many aspects of the Livepeer design which can deliver utility to users today, and can begin to be tested in the wild prior to full decentralization. And those results/data points can be used to make more informed decisions on the best way to progressively decentralize a system — no one knows what the right way to build a self-sustaining decentralized system is, and ideas that sound promising in theory do not necessarily map to success in practice. Livepeer wants to create the proper feedback loops so the community and network can learn and evolve

It would be a mistake to wait until all challenges in the decentralized tech space are solved prior to beginning to use and test Livepeer, so the community will be launching an alpha version on the Ethereum main net shortly called Snowmelt. This post lays out the current points of centralization or trust required in the system during the alpha, and the path to get from Snowmelt to a fully decentralized version of the protocol in the next 18–24 months.

Points of Centralization

There are three primary vectors to look at with regards to centralization:

• Technology — is Livepeer using trustless systems, or systems that rely on a single company or entity?
• Governance — how do decisions about the future of the protocol (including updates and changes) get made?
• Stake — are the participation rights in the network spread out amongst a large number of stakeholders?

Technology Centralization

There are two technical areas in which Livepeer is using semi-trusted solutions for the Snowmelt alpha, but will transition to trustless solutions in the future:

1. Verification of work
2. Incentivized and economically secured storage

Verification of work is important to the Livepeer protocol because if nodes are getting paid for transcoding video into different formats, the protocol needs to verify that they actually did that work correctly and didn’t just output 0-bytes or insert malicious frames of content into a stream. The good news is that Livepeer was designed from the beginning to do this trustlessly using a scalable commit-verify sampling method on top of another protocol called Truebit. The double-good news is that Livepeer has been collaborating closely with the Truebit team for a year, recently spent a week together at their Hacker House working on a proof of concept, and great progress is being made on getting the Truebit protocol to production. On the other hand, like many decentralized tech projects (Livepeer included), Truebit is not yet launched, tested, stable, and robust on the Ethereum main net. So if Livepeer relied fully on Truebit to launch, it wouldn’t be able to get out the door in short order.

Instead of relying on Truebit during the Snowmelt Alpha, the network will use a more trusted solution in which community members run verification servers for the good of the network. This is a solution which can easily be swapped out for Truebit using the same interface, at a later date. And in the meantime, there are additional, less-trusted solutions which have already experimented with and may be swapped in as well including Oraclize’s Computation Oracle, secure hardware, and even social-based verification.

On the “incentivized and economically secured storage” front, Livepeer seeks a solution where a user can write a piece of data to a storage network, and can guarantee with some degree of economic certainty that it will be available to be read by other users on the network. Livepeer’s verification protocol also makes use of this, as when Truebit needs to verify that encoding work was done correctly, the verifiers need to be able to read a piece of the input video from a storage network and know it will be there. Two such solutions that aim to fulfill this promise are Swarm and Filecoin — both of which allow you to make a payment to the network, get a receipt, and either access the file or a large insurance payment if the file isn’t accessible. However, neither of these protocols are in production yet either.

Instead, Livepeer’s Snowmelt phase will make use of the IPFS network. This actually is trustless, in that the node who requires verification to pass can host and serve the needed content into the IPFS network, however there is no economic guarantee that a bad actor can’t prevent the file from being accessed. Additionally, anyone with an interest in the Livepeer alpha running smoothly can run IPFS nodes and pin content to be served and accessible for a period of time, increasing the likelihood of seamless execution of the protocol. And of course, Livepeer can easily upgrade in future phases as guaranteed storage solutions come to production.

In production, the Livepeer protocol will severely penalize anyone who fails a verification, however when the service that’s verifying the work is trusted and centralized, the penalties will be far less severe if existent at all. This reinforces that the Snowmelt Phase is an alpha, and is intended as a developer preview. The community can test the economics and behaviors of the network with the correct interfaces, but shouldn’t expect the full, unnameable, and trustless reliability that will come in time. Still, the path to technical decentralization looks clear and blockers are being removed each week as the entire ecosystem makes progress.

Governance Centralization

Much has been written about governance in blockchain protocols. Topics covered include when and how to make upgrades, what to do when something goes wrong, what can and can’t be voted on and how those votes are carried out, and how funds get spent on the development of open software for both the core protocol and the ecosystem. These are deep topics which can span many posts of their own, so instead the focus here will be on governance during Snowmelt, and the path to decentralized governance. The areas that governance in Livepeer will focus on immediately include:

• Protocol upgrades
• Parameter updates
• Failsafes

First of all, please note that Livepeer is a very complex and ambitious protocol. The first version contains about 4000 lines of solidity code across 20+ smart contracts (not to mention 10,000 lines of tests and various client implementations and DApps). It will be one of the first versions of stake based validator selection and fee distributions to go live on Ethereum. There will be bugs. The economic models need to be tested and iterated on. As mentioned above, the technical systems themselves need to be migrated to more trustless solutions.

While Livepeer is in this super early alpha phase, each of the above governance transactions will be invoked via the core development team. The core team will seek a community consensus model through frequent, transparent communication and community interaction across a number of channels. However when there is a bug or well communicated feature enhancement, the core team can deploy a smart contract upgrade through the carefully built proxy-delegatecall contract upgrade mechanism. When one of the economic parameters seems out of whack and is incentivizing unintended behavior, the core team will be able to move that parameter, and in the event of something catastrophic (which as evidence shows is highly likely at some point in the early days of a system like this), the core team has the failsafe ability to pause the protocol, re-establish state, and launch an updated version.

These are all desirable characteristics for an early stage, highly iterative, software development process, but they are undesireable for a decentralized, trustless protocol. So how does Livepeer go from this in Snowmelt, to fully decentralized governance in the Delta release? There are a number of options to be considered, but one such candidate that is appealing is:

• Enact protocol upgrades via stake based voting
• Enact parameter change proposals via stake based voting
• Remove failsafes — use forks instead

Livepeer’s delegated stake based model lends itself very nicely to decentralized governance. Since users bond their tokens towards elected transcoders who have 24/7 commitment to the network, it is possible to ensure near 100% participation in every vote. When upgrade proposals or parameter change proposals are submitted, transcoders are required to vote, lest they get slashed. Their votes by default carry the full weight of all the stake delegated towards them, but any user who wishes to move their stake to another option in the vote can do so. There are no technical blockers beyond implementation to this being available, so if the community deems this the best path forward for governance, it’s a matter of building it.

Removing failsafes is also a question of when the network is ready. Forks are always an option, even from day 1, but they require far more coordination, state migration, and political process. In the early days, while there is less value tied up in the network (see next section), and the protocol is clearly labeled as a quasi-trusted alpha developer preview, everyone can transparently know what they’re participating in with regards to the core team’s ability to pause, fix major bugs, and keep the network running. However as the network matures, is battle tested, and trust in systems and governance is removed, the failsafe controls will be removed as well, leaving forks as the failsafe defense for anyone who doesn’t wish to opt in to an approved or rejected protocol or parameter upgrade proposal.

Centralization of Stake

The Livepeer network is not owned by any single party or company — it is run by all the participants in the network, or token holders, who all have incentives to do work and contribute value. It seeks stake based decentralization from the very beginning — the genesis state. At the same time, during the Snowmelt alpha, while Livepeer has some trusted and centrally controlled elements, the goal is for very little of the network stake to actually be liquid and tied up within the network. As the network is ready to become more and more decentralized over time, more and more of the token can be distributed and made liquid.

Stand by for more information to come soon about the initial stake distribution mechanisms coinciding with the launch of the network. The important thing to note is that while the goals are to distribute stake to various network participants over time — including node operators, developers, DPoS participants, core development team, broadcasters, etc — measures will be in place to ensure that the proportion of the total stake that any single parties have are maintained and balanced throughout the distribution period. Some centralized technology and governance mechanisms during an alpha, does not imply that liquid stake itself need be centralized.

In addition to the initial distribution, note that the Livepeer protocol itself mints new tokens to incentivize participation in the network, and any user who participates will earn these newly minted tokens as the network progresses, starting from day one.

The culmination of this ~24 month road to decentralization will result in an early network state in which all valuable participants of the Livepeer community have had a fair opportunity to earn initial stake in the network, so that they can participate and play their role as the network is ready to shed all aspects of centralization. With a fully distributed stake, decentralized governance, and decentralized technology, the Livepeer ecosystem should be poised to move forward in a fair, open, transparent, and trustless way.

For further updates on Livepeer, you should follow @LivepeerOrg on twitter and join the community chat.