Observations At the Four Year Mark of a Web3 Protocol Build
A little over four years ago Eric Tang and I began diving deeply into the world of blockchain enabled technologies, and were inspired by the web3 vision of a more decentralized, user-sovereign internet infrastructure. We published many of our early ideas and open source development work at dappbench.com, and laid out the vision and technical research for Livepeer — a protocol, incentive model, and open source software which could enable an open video infrastructure that was far more scalable, reliable, and cost effective than the centralized services that existed in the web2 world.
In the years that we’ve been at work, we’ve accomplished a lot with Livepeer: An alpha network was launched, ownership was distributed to the early network operators through contributory participation, a community of active stakeholders was formed, Ethereum scaling issues were addressed through a series of upgrades including a new micropayments mechanism, governance was decentralized amongst the community of stakeholders, a commercial offering to focus on onboarding demand to use the video streaming infrastructure was launched at Livepeer.com, and users have begun to realize the value of the network for their live streaming applications.
With zero focus on speculation, liquidity, or exchange, we’ve always put our heads down and done to work to enable a sound technical infrastructure that meets the needs of real users. And while the above progress, enabled by the team and community, is an incredible start, there’s still a long way to go to truly achieve Livepeer’s full potential. The four year mark in a blockchain project, as signified by the four-year Bitcoin halving cycles, offers a good symbolic moment to reflect on some of the key observations and lessons learned, and to look forward toward what needs to be done to truly fulfill the vision. Let’s take a look at some of the observations that we’ve seen along the way, including a look at generating demand for crypto networks, the importance of targeted token distribution mechanics, governance’s role in extensibility and iteration, and web3 vs web2 expectations.
If you build it, will they come?
Authors and implementers behind blockchain based protocols tend to receive a lot of early validation of their idea — often buoyed by speculative interest in the underlying token that powers the protocol. The token hopefully has a very sound role to play in the bootstrapping of the supply side of the network, and so this validation and the resulting participation in order to acquire it can result in a jumpstart to overcoming the chicken and the egg problem. This is very powerful, and when combined with impressive sounding value propositions like dramatic cost-reductions, open access, near infinite scalability, and self-sovereignty, one might think that users would come running. But this early supply-side validation and theoretical promise of the value props should not be confused with proof of product-market fit on the demand side of the marketplace.
For the demand side to arrive, there are often requirements for highly usable software with great user experience, crypto-abstraction, customer education, onboarding, and support. When looking at applications like DeFi protocols, the bar for these may be lower as the protocol functionality consists of a few simple actions such as transfer, deposit, or withdraw, largely acted upon by crypto-native users. But as you get into the infrastructure world, requiring web2 developers to build applications on top of web3 protocols, these requirements get steeper and steeper, and often resemble the works that traditional companies undertake.
At Livepeer, we recognized this early on after the first round of protocol development, and made the decision to build a company that could provide not only the software required to leverage the superpowers of the Livepeer network, but also conduct the business activities to meet the enormous video streaming industry’s existing needs and workflows, in adopting new technology that delivered on this promise. This company, represented by the product at Livepeer.com, exists side by side in a mutually beneficial relationship with the open protocol — much like Bitcoin+Coinbase or Ethereum+Consensys have undoubtedly contributed to the success and growth of the other.
Over time, as other companies adopt the technology, either as users of Livepeer.com initially, or by building upon the open source software themselves, they’ll see the potential of the order of magnitude cost reductions and increased scalability of Livepeer, and have the opportunity to build their own businesses that leverage this infrastructure advantage. But it’s clear that in the boostrapping phase, if you build a complex open protocol, the users are unlikely to come unless you support them along the way.
Who has the token?
When a token design is sound it should make its way into the hands of the users who value it the most, and ideally those would be the same users who can use it to participate in the various ways that optimally help the network. In a PoW network this begins with the miners, earning the token for providing security, and it makes its way to users who value it for their own purpose at a market price. In a work-token network, ideally a large amount of it is earned by those providing valuable work and acquired by those looking to enter and compete with these users to provide additional services for which there is demand or substandard geographic coverage.
Nearly three years into Livepeer’s mainnet experience, there are definitely several observations about what was intended, what went well, and what still needs to be addressed by the community with regards to the token flows out of the protocol.
First of all, as background, the Livepeer Token (LPT) was initially distributed through an open access MerkleMine algorithm, and continues to be distributed through the network towards those who run nodes to provide video encoding, and delegate towards them to provide security and QA by routing work towards those whom are performing well. One thesis was that the steps required to MerkleMine at scale — devops, scripting, blockchain interaction, server administration — were similar to those required to run a node and perform video transcoding on the network. This would create a set of initial users well equipped to run an effective Livepeer network, and as they would all now have an incentive for the network to succeed, they would take their job seriously. Furthermore, another thesis was that as nodes were competing to earn fees (paid in ETH), delegators would move their stake around towards those who were performing very well and sharing back a portion of their fees, and this stake movement would actually make it cost-ineffective to run a node if one was not performing well at video encoding.
What have we seen happen? Well, much of the above has been correct — the stakeholders want to see the network succeed, they take their job seriously, and they contribute where they can. But often these contributions come in the form of crypto-speculative contributions — building tools and alerts and reports around inflationary staking rewards, participating in community calls around protocol governance and economics, and reliably calling the necessary transactions each day to earn the rewards along the way. As fees have begun to flow into the network for real usage amongst users, in modest but meaningful amounts, what we have not seen is intense competition to earn these fees amongst the operators, and hence we have not seen an arms race to run the best possible GPUs in the most in-demand locations to earn video encoding work.
Why is this? It is simply because with the current network economics, the rewards from LPT inflation appear much greater than the fees in the ETH that can be earned, to incentivize this behavior. LPT flows to nodes whether they perform scalable video encoding work or not, and until the fee grow significant in both comparison, and in absolute value, delegators likely won’t penalize these actors for their more passive node operation.
This is likely one of the most urgent areas for the community to address.
While difficult to reward video encoding work trustlessly in an ungameable way through the protocol itself, there are a number of options the community can consider to ensure that token flows to those who are running GPUs in a scalable manner, backing a reliable Livepeer network, to service the growing demand and fees coming through Livepeer.com and other sources. This is a wide design space including inflation funding through staking, grants, protocol economic updates, incentivized reward programs, and more.
How can such updates be made to a decentralized and open protocol? This brings us to the next lesson…
The criticality of decentralized governance
A complex protocol needs to evolve over time in order to achieve resilience, security, and find product market fit. However with a bootstrapped supply side stakeholder base, who have made economic decisions to enter, participate in, and exit the network under a certain set of rules and assumptions, these evolutions present risk and uncertainty. If these evolutions are handed down by a single central authority on what may appear to be a whim, this risk and uncertainty can be too much to bear.
Instead the protocol evolutions need to be driven as a result of community consensus, via a clear process, and an ability to exit for those who chose to do so rather than continue participation under the updated rules of the game.
At Livepeer, the early days of the alpha were centrally iterative by design — to ensure bug fixes, protect user value, and ensure reliable functionality of the network. But as soon as it was clear that there would need to be economic iteration on the core incentives to participate in the protocol itself, it was clear that decentralized governance was necessary as a pre-requisite, to allow the stakeholders to arrive at these decisions together.
The tools and process that Livepeer uses to do so can be read about here, but largely consist of a very well defined (off-chain and on-chain) process, a principles statement, and the technical mechanisms to carry out the will of the community. While slower to go through a consensus building process than to unilaterally deploy updates, this process serves as the launching pad for the community being able to evolve into the mature, robust, secure, and useful protocol that it has the potential to, in a way that brings the entire community along for the ride — and without bringing the community along for the ride, there is no utility or potential in the network that is worth participating in in the first place.
Meeting existing industry where they are while also building for the web3 enabled future
Finally, I’d like to share some perspective on building for existing industry versus building exclusively for web3.
Four years ago it appeared that web3 as a development platform for complex decentralized applications (DApps) was closer than it really was. While we have seen killer micro-dapps around use cases like capital formation, DAOs for governance and treasury management, other emerging DeFi based money legos, we have yet to see the consumer social experiences that have been envisioned to free us from the ad-centric attention economy business models of FANG platforms.
Here I still have hope, and there are many inspirational signals that we’re turning the corner with the right building blocks in place for this new class of experiences and economies to come to life. Things like Skynet, Filecoin, Livepeer, NuCypher, and The Graph are moving from alphas to production-ready application infrastructure. But the developers building on them are being lazy if they think that the decentralized clone of Twitter or Facebook or Twitch will disrupt the existing versions. Instead, we’ll need new experiences imagined that leverage the benefits these platforms provide that make them unique — the lower cost structures, the open access, the ability to natively embed money, incentives, and economics into the applications to create more aligned financial incentives between creators, consumers, and the platforms themselves. This will take product vision, entrepreneurial fortitude, and luck. But with the influx of talented people flowing into the space, it’s only a matter of time before we see these.
That said, in the case of Livepeer, we’re determined not to just sit on our hands and wait around for the emergence of DApps. Our value propositions of order-of-magnitude cost reduction of centralized video infrastructure providers, elastic scalability, open access, and the high reliabilities enabled by global redundancies are applicable to the $70B streaming industry today. While the project and company still have work to do to fulfill these promises, especially on the reliability side due to the complex nature of the technology, we’re meeting the industry where they are today. We’re building tools that enable Livepeer to fit into existing video workflows and technologies, and not requiring video developers to drop an entire stack to run blockchain aware, crypto-funded nodes — this would be a nonstarter.
This is what web3 impact on the real world looks like. And we’re beginning to see the positive results of years of work. Fully web3-based decentralized integrations will come, and are already beginning to launch.
— — — — — —
In today’s fast paced technology world, four years is a long time to be thinking about and building one thing that is just now beginning to deliver on its promise. But in web3 we’re still in the infrastructure phase, and building a reliable base layer for the next phase of connective technologies takes time. Doing it alongside an amazing team and community has made each day a fun new challenge, and I look forward to the next four years of putting the above learnings to work, as we go from build, to adoption, to growth, to disruption.
