The past couple weeks have been focused on getting a protocol release candidate ready for testnet and audit. One of the large challenges of releasing early in the blockchain world is that by default, it’s much harder to iterate on a blockchain based protocol than on proprietary, server side software. We can’t just deploy updates every time we fix a bug, as it may require everyone in the network to agree with the change or, at the minimum, to upgrade their software. Here’re some steps that we’ve been taking to prepare for this:
1. Communicate a well defined roadmap far in advance
This post, which addresses The Livepeer Network Phases outlines the progression from proof-of-concept testnet, to alpha-production network in the Snowmelt Phase, all the way through trustless, decentralized network in the Oceanic phase. This is being communicated early on, so that the community who participates in the project has an expectation of how we’ll get from point A to point B, and what kind of upgrades are expected to occur along the way.
2. Build contract upgrade mechanisms into the Livepeer smart contracts from day 1
Smart contracts running on Ethereum, like the Livepeer Protocol, are not upgradeable by default. That’s part of the point - what is deployed will run forever without anyone being able to modify or control it. So in order to actually support iteration and upgrades, you have to build custom solutions to potentially start and stop protocols, and migrate data and logic to new contracts. Over time you would like the mechanisms that actually have control over taking these actions to be decentralized, so that only the community can invoke these upgrades collectively.
We started with a survey of the various techniques using for upgrades. And we moved ahead with a first pass implementation of the proxy pattern. A solidity example of implementing this pattern can be found here, and may be a little technical for this post…but the takeaway should be that using this mechanism gives us the ability to fix small logic bugs and make minor adjustments during the early phases of the network without requiring major upgrades or forks.
3. Be aware of the path to full decentralization
The two areas where our network will need to progress through various levels of decentralization are verification of work, and governance for parameter and contract upgrades. For verification, this week we did an IPFS integration to back both an internal Livepeer verification service, as well as an external Oraclize verification service. The plan, as always, has been to move to a Truebit verificaiton service for full trustless decentralization when possible. On the governance side, the plan is to use the delegated staking as a starting point for required participation in param and contract upgrade proposals. We’ll take a cautious approach with enabling drastic upgrades via governance in the early days of testnets and protocol iteration.
Adaptive Bitrate Streaming
This week also saw a number of updates on the video side to increase the stability and reliability of adaptive bitrate streaming (ABS). On chain transcoding jobs can now request multiple video profiles, and the resulting ABS streams should be delivered through the network in a more efficient manner, reducing the load on the origin video server.
Livepeer For Beginners
The Livepeer For Beginners post that we wrote was helpful to a lot of people in understanding what Livepeer was all about. We did a follow up video where we talked through some of the details.
Community Spotlight
We did a quick Q&A with Livepeer contributor Chris Hobcroft. Thanks for your help, time, and contribution.
Josiah Savary joined the team to take on the awesome challenge of creating the tools and UIs to make Livepeer usable by the mainstream, beyond just command line and developer interfaces. Welcome aboard!