Introduction
The Livepeer protocol is the backbone for video streaming public infrastructure. As usage of the infrastructure increases, a few questions naturally arise:
- How will the protocol rules and parameters change over time in order to ensure that the infrastructure can evolve to serve the needs of video streaming applications?
- Given that the infrastructure is powered by a community of service providers (i.e. orchestrators/transcoders) and capital providers (i.e. delegators), how can the preferences and opinions of these entities be factored into the decision making process for changing protocol rules and parameters?
- Given that the infrastructure is used by a community of service requesters (i.e. broadcasters), how can the preferences and opinions of these entities be factored into the decision making process for changing protocol rules and parameters?
The above questions can be captured in a single more general question:
How is the Livepeer protocol governed?
In the first 2 years of the Livepeer protocol’s existence, the core development team responsible for the creation of the first version of the protocol also took on the responsibility of upgrading the protocol to better meet the requirements of video streaming applications. At the moment, the governance of the protocol is driven by the core development team as the BDFL (benevolent dictator for life). In order to realize the vision of video streaming public infrastructure that can serve the needs of all video streaming applications around the world, it is crucial for protocol governance to be driven by stakeholders that make the infrastructure possible in the first place.
An ideal governance system will distribute power to stakeholders that contribute to and enable the existence of the protocol allowing them to autonomously change protocol rules and parameters. Designing such a system that serves the needs of stakeholders in every possible future scenario at a single point in time is a herculean task and likely impractical.
However, as a community, we can still strive towards such a system by establishing a collection of tools, social processes and social norms along with an extensible technical system that can adapt to future needs. Rather than thinking about protocol governance as a problem that needs to be solved at a single point in time, we can think about protocol governance as a project that requires continual maintenance and improvement over time. With this mindset, we can establish incremental governance milestones — each of these milestones would improve stakeholders’ ability to exercise voice and influence the evolution of the protocol.
In the rest of this proposal I will:
- Describe milestones in a governance roadmap proposal
- Describe the components of the first milestone which is focused on decentralization of knowledge, LIPs and polling
Milestones
1. Decentralization of Knowledge, LIPs and Polling
The goals for this milestone are:
- Disperse knowledge of the protocol such that a larger portion of the community is capable of evaluating technical and economic proposals to change the rules and parameters of the protocol
- Formalize the LIP (Livepeer Improvement Proposal) process as the community accepted process for creating, discussing and evaluating technical and economic proposals
- Create a polling application that allows tokenholders to signal their approval/disapproval of LIPs
This milestone will establish a collection of tools, social processes and social norms that will start to give stakeholders a greater voice in protocol governance. While at this stage stakeholders will still depend on the core developers to execute protocol changes and to safeguard user value if a protocol bug is discovered, these tools, processes and norms will help stakeholders better understand why and how a decision was made thereby creating more transparency and holding core developers more accountable to other stakeholders.
In the short term, the artifacts created in this milestone will enable initial steps for stakeholders to express preferences and opinions in order to influence protocol change decisions. After this milestone, these artifacts will continue to be useful for bringing the community into the conversation around improvements to protocol governance structure and also as building blocks for rich and thoughtful community dialogue that is a crucial component of any effective governance structure.
2. Extensible Governance System
The goals for this milestone are:
- Deploy a technically extensible governance system that can be used to update the parameters and code of protocol smart contracts
- There should be a clear path for upgrading the governance system to give stakeholders control over the system
At the moment, a core developer owned multisig has admin privileges in the Controller contract giving the core developers the ability to update contract code and parameters. A technically extensible governance system would:
- Enable on-chain rules for how code/parameters can be updated. At the moment, there are no on-chain enforceable protections for stakeholders because the code/parameters can be updated immediately by the core team. An example of a potential rule is requiring a time delay for all code/parameter updates to give all stakeholders a clear view on pending updates and to also allow stakeholders that disagree with an update to exit (i.e. unbond and liquidate staked tokens) prior to the execution of an update on-chain.
- Facilitate more complex updates to the contracts by allowing multiple code/parameter updates to be bundled into a single on-chain action. This can reduce the complexity and number of steps required for a protocol upgrade that consists of multiple proposals. The Streamflow upgrade required many on-chain actions that had to be sequentially executed. For these types of planned major upgrades, bundling the execution of a set of proposals into a single on-chain action can simplify the upgrade process.
- Facilitate future changes to the governance structure. A governance contract would replace the current core team multisig as the “owner” of the Controller contract. While the governance contract will still give privileges to the core team multisig to perform code/parameter updates in this milestone, on-chain rules (see the first point above) will determine how/when these updates can be made. Then, in the following milestone, the governance contract can give privileges to perform code/parameter updates to a binding voting contract.
The motivation behind this milestone is not to immediately implement a sophisticated binding voting system, but rather to establish the technical foundation that allows for a variety of sophisticated binding voting systems to be implemented in the future.
3. Binding Voting System
The goals for this milestone are:
- Upgrade the governance system to use a binding voting system to approve or reject changes in the protocol smart contracts
This milestone will enable stakeholders to coordinate changes to the protocol without any special privileges afforded to the core developers. There is a wide design space for binding voting systems. Some interesting areas of exploration include:
Weighting rules in a token weighted voting system
- 1T1V (1 token 1 vote) is a popular mechanism as it offers Sybil resistance by attaching a cost (of acquiring tokens) to voting, but there is room for experimentation with how to weight an account’s token holdings. For example, conviction voting computes vote weights as a function of the time an account is committed to a vote
- Since stake delegation is already a first class concept in the protocol, it could also be used in a voting system to allow delegators to delegate their vote weight to orchestrators
Proposal spam prevention
- If there is no cost for proposal creation, then an attacker could spam the governance system with proposals that tokenholders would need to constantly vote on
- One approach to spam prevention is to attach a cost to proposal creation. This is the approach used in Cosmos governance
Collateralized delayed execution
- Instead of requiring a vote for every on-chain protocol change, there could be collateral required for each proposed change that is queued for execution after a time delay. Prior to the end of the time delay, anyone can challenge the proposal by putting up their own collateral which would trigger a vote which would determine if the proposal is accepted (challenger loses their collateral) or rejected (proposer loses their collateral)
- A challenge based mechanism creates a fast track process that does not require a vote for non-contentious proposals while still allowing stakeholders that care deeply about a proposal to trigger a vote for contentious proposals
- The Aragon Agreements blog post illustrates this concept in the context of agreements formed between members of a decentralized autonomous organization (DAO)
These design ideas among others can be explored with the open participation of stakeholders to determine the most appropriate binding voting system design for this milestone.
4. Future
The previous milestone will be the first time when stakeholders will be able to have full autonomous control over changes to the protocol smart contracts. However, the system deployed as a part of the previous milestone will likely still need to change over time. There are a number of interesting mechanisms to explore such as futarchy and quadratic voting. All of these mechanisms will be possible to experiment with and it will be up to the stakeholders to decide which ones best suit the governance needs of the protocol.
The First Milestone
Decentralization of Knowledge
Decentralization of knowledge is critical for a well functioning governance system because stakeholders need to be able to evaluate the merits and risks of technical and economic proposals in order to make an informed decision about whether a protocol change should be made or not. If all the knowledge about the technical and economic implications of a change is held by a single party, then the governance system will not empower stakeholders to exercise voice regardless of how technically/game-theoretically sound the mechanics of the system are.
Today, the core development team is the center of protocol knowledge creation. However, that knowledge is not well dispersed across the community of stakeholders. While any effort to disperse knowledge to more stakeholders is going to be an on-going project, we can start the process in this first milestone with a public education initiative. Examples of potential projects for this initiative are:
- An accessible education series explaining how the protocol governance process works in this first milestone
- More use of the forum and Github research repository for idea sharing and informal peer review
- A technical blog post series on how certain protocol features work
- Core developer office hours to discuss protocol topics
LIPs
Livepeer Improvement Proposals (LIPs) describe standards and specifications for changes to the protocol. The original goal for the LIP process was to serve as the standard process by which a change to the protocol would be created, discussed and deployed. However, since the creation of the process, the only participants in the process have been core developers and the process was not used at all for the Streamflow protocol upgrade.
Moving forward, the LIP process can ensure that stakeholders have an understanding of the lifecycle of technical and economic proposals. The process will provide guidelines for creating and discussing proposals. Without guidelines for proposals, the community would be flooded with poor quality proposals hampering stakeholders’ ability to have high quality debates about the merits and risks of proposals. The process should produce LIPs that can be considered for adoption and that can be the subject of polls as described below.
Polling
A polling application for tokenholders would give the core development team access to another signal from the community in addition to the signals sent by those that participate in the LIP process. While tokenholders are only a subset of stakeholders in the community, they are a large subset of the community so it is important to understand their preferences.
Some desirable properties for the polling application include:
- Auditable. A third party should be able to audit the results of a poll to establish confidence that votes were tabulated correctly. This will help establish legitimacy around the results of a poll.
- Open source. While this application will primarily be used by the core developers in this milestone to aggregate tokenholder preferences, the hope is that it can eventually be deployed by any community member that wishes to propose a poll on a proposal. Additionally, an open source codebase also helps with auditability.
- Informative. The application should provide the necessary information for a tokenholder to make an educated decision when casting a vote. This might include the proposal text itself along with a summary of merits, risks and links to relevant discussions.
Conclusion
In this proposal I described an initial set of milestones for a governance roadmap and high level details for the first milestone including:
- A public education initiative to help decentralize knowledge
- A revamp for a formalized LIP process to create, discuss and build consensus around technical and economic proposals
- A polling application that can be used to gauge tokenholder sentiment about a particular proposal when deciding whether to adopt it or not
More details around designs for the first milestone projects will be available soon. In the meantime, all feedback is welcome!
