Project Overview
The Livepeer project aims to deliver a live video streaming network protocol that is fully decentralized, highly scalable, crypto token incentivized, and results in a solution which is cheaper to an app developer or broadcaster than using traditional centralized live video solutions. In this document we present the core components of the Livepeer project: Livepeer Media Server, Livepeer Network, Livepeer Token, and Livepeer Protocol, and describe their role in creating a cryptoeconomically secure platform for live video broadcast.
For the technical details, security, and economic incentives of the Livepeer Protocol, please review The Whitepaper.
- Introduction to Livepeer
- Livepeer Media Server
- Livepeer Network
- Livepeer Token
- Livepeer Protocol
- Use Cases
- Conclusion
- References
The vision of the decentralized web has begun to be realized over the past couple years with the emergence of networks like Ethereum to enable trustless computing, Swarm and IPFS/Filecoin to enable decentralized storage and content distribution, Bitcoin and various token projects to facilitate p2p transfer of value, and decentralized name registries like Blockstack and ENS to provide human accessible names to content and identities [1]. These elements form the basis for decentralized applications (DApps) to be built in the form of largely static or infrequently updated web or mobile content, but at the moment DApps still lack the ability to include streaming media and data in an open and decentralized way. The goal of the Livepeer project is to decentralize live video broadcast over the internet. Right now live video broadcast is
A) Growing at a rapid pace, across many categories including social, events, IoT, and enterprise. This trend that is likely to accelerate with the introduction of VR and 4K, and the cheap availability of high quality video cameras embedded on every phone and device.
B) Centralized. Almost all live broadcasts over the internet run through centralized media servers, and then are distributed via centralized CDNs. WebRTC allows P2P video, but the computational requirements and bandwidth requirements required to serve to many users make it prohibitive to do a live broadcast to more than a couple clients over webRTC.
C) Expensive. It can cost upwards of $4500 to purchase a professional media server software license for one server or $500+/month to run a single cloud instance capable of processing and distributing a couple concurrent streams to a couple hundred users. Cloud services can cost even more. For large broadcasts like major sporting events, the publisher needs to buy up a large amount of the capacity of every CDN in existence, just to run one broadcast for a couple of hours [2].
A fully decentralized P2P solution, where nodes contributed their own computation and bandwidth in service of streaming live video would be more scalable, as there would be no limit to the number of connections that could be served. This technology is certainly available to a certain extent, but to date, there has been no incentive to get users to run nodes that provide this functionality, nor has there been proper funding for the development of an open protocol that can facilitate this in a way that benefits the entire internet rather than one centralized company. However, with the recent emergence of crypto token powered protocols [3, 4], there is now an opportunity to simultaneously incentivize users to contribute computation and bandwidth towards live video broadcast, in a way that aligns with incentivizing the development of an open media server solution capable of delivering live streamed video according to all the latest standards and formats required to reach the full range of devices. Additionally, the economic actions traditionally seen as a result of token powered protocols indicate that the cost to the broadcaster in order to use the Livepeer network could be cheaper than the cost of any centralized solution.
There are four components of the Livepeer project:
- The Livepeer Media Server
- The Livepeer Network
- The Livepeer Token
- The Livepeer Protocol
The Livepeer Media Server is an open source media server that is capable of taking input streams of live video and audio and transcoding them into alternate encodings, transrating it into different bitrates, and transmuxing it into different delivery formats. This is necessary so that a video, recorded in one format and bitrate, can now reach every screen on every device on every platform, each of which may have their own requirements about format and bandwidth restrictions.
There is no shortage of media server solutions on the market, however most are proprietary, developed and sold by a single company, are not open source, and come with high costs or licensing fees. The open source solutions are limited, and are typically incomplete, out of date, lack support, or require you to upgrade to proprietary service packages in order to receive the full set of features.
Since the Livepeer Media Server is a core component of an economically efficient protocol and network (see following sections), its development will be financed by the protocol itself. This will allow it to be fully open source and transparent, and as a result will benefit from community in the form of peer review, open discussion around features requests and bugs, and potentially community driven contribution.
The media server can be used as a standalone component in any media streaming application that anyone wishes to build using it, however it is truly powerful as a tool that is running within the Livepeer Network.
The Livepeer Network comprises a set of nodes that run the Livepeer Media Server and speak the Livepeer Protocol. The network operates primarily on two types of requests: publishing a stream, and requesting a stream. A publish request is a request to transcode a live video with certain parameters, and to serve the resulting video. A request is an attempt to access an existing live stream that is on the network.
When a node publishes a stream into the network, they can assume that the stream will be transcoded into whatever formats they request (and pay for), and that the network will scale to distribute the stream to as many nodes are requesting it.
Nodes will manage their own peer groups following a Kademlia style protocol [9]. Nodes will test their peers for latency and throughput capacity to ensure that streams can be relayed through the network with minimal delay. When a stream is requested from a node who currently isn’t yet consuming it, they will either pass on the request to a node who is already consuming it and has relay capacity, or they will become a relay node themselves, consuming the stream in order to pass it on to subsequent requesters. The protocol will dictate the routing procedure to follow for requesting a stream from the proper node and routing transcoding and verification jobs to the proper nodes.
A network with one broadcaster, four nodes consuming the stream, and two nodes relaying the stream without consuming it.
Before getting into the Livepeer token, it is worth noting that broadcasters pay to use the network in Ethereum's ETH. ETH is the medium of exchange token in the Livepeer network.
The Livepeer Token will be a protocol token for staking, used by those who want to perform work on the network, that serves the following purposes:
- It serves as a bonding mechanism in a delegated proof of stake system, in which stake is delegated towards transcoders (or validators) who participate in the protocol to transcode video and validate work. The token, and potential slashing that occurs due to protocol violation, is necessary in order to secure the network against a number of attacks. More below.
- It routes work through the network in proportion to the amount of staked and delegated token, essentially serving as a coordination mechanism.
- It is a unit of account that is specific to the Livepeer ecosystem, which forms the basis of a SectorCoin concept, applicable to additional functionality to be introduced in the future [5]. Services such as DVR, closed captioning, ad insertion/monetization, and analytics can all plug into the Livepeer ecosystem and potentially make use of the security provided by staking LPT.
The ledger of token balances and double spend prevention will be provided and secured by the underlying blockchain consensus mechanism. This will be an inflationary token in which new token is generated by nodes who run the Livepeer Media Server and perform transcoding, in proportion to the amount of work that they contributed to the network. Nodes who don't perform work correctly or attempt to cheat will have their token stakes slashed. This will have the effect of routing more future work, and fees, towards the nodes who have successfully performed work in the past.
Assuming competition amongst nodes to win broadcasting business and the associated fees in ETH, any increase in proportional amount of token, and hence future work, that can be earned for performing transcoding will equate to a drop in the cost that must be charged to the broadcaster. This creates a positive economic effect for broadcasters looking to transcode live video through the Livepeer Network.
The Livepeer Protocol specification will lay out the various roles in the Livepeer Network, the various transactions types supported, the cryptoeconomic security measures in place to prevent collusion, and the token distribution mechanics. The Livepeer Whitepaper provides all the technical details of the protocol and its incentives. As a high level summary, the Livepeer protocol will operate as follows.
Node - anyone who runs the full Livepeer software and participates in the protocol. All subsequent roles are also nodes.
Broadcaster - the node who is publishing a stream. They pay the network in ETH for transcoding services.
Transcoder - a node who is currently transcoding a stream into a newly formatted stream. They get paid for this service by the broadcaster, and increase their proportion of newly generated token. Transcoder is a special role that is delegated towards by other nodes. They not only transcode video, but also participate in the security protocol of verifying work and distributing new token. More below.
Consumer - a node who is consuming an output stream to watch the video or to serve it over a gateway to additional users outside of the protocol.
Relay node - a node who is merely passing on video without the intent of watching or serving it itself.
As described in the roles above, the value in the network will flow from the broadcaster to the transcoding nodes in ETH as payment for their services. The price that a transcoding node charges for a given transcoding configuration, will be advertised via the transcoding node, and the broadcaster can set the price they are willing to pay. Transcoding nodes and delegators also increase the portion of future work which will be routed towards them, and hence fees, by provably doing honest work.
Token will be generated by the protocol in order to reallocate the future work towards nodes who have staked and successfully performed work in the past, and away from those who have cheated or not performed work. Token will be distributed to transcoding nodes in proportion to the amount of work that they performed in transcoding streams, as well as to nodes who delegated their stake towards transcoding nodes who behaved correctly in proportion to their stake.
There are two levels of consensus in the Livepeer Protocol. The first, the state of the current ledger of the Livepeer Token balances, and validation of all transactions which transfer token from one account to another, is provided via the consensus algorithm in the underlying blockchain that the Livepeer token is issued on. As a token issued on an existing blockchain, balances and transactions will benefit from the same level of security as the blockchain's native token itself, secured by the hash power of the mining operations or underlying proof of stake algorithm.
The second level of consensus is unique to the Livepeer protocol, and will govern how the newly generated Livepeer Token is distributed in proportion to the amount of work that nodes in the network performed in order to transcode and verify live streams. This will operate on a delegated proof of stake consensus algorithm (DPOS) [6]. Transcoders will be elected to play a special role in the network consisting of two responsibilities:
- Run highly efficient and reliable hardware and networking setups to fulfill the demand for transcoding on the network.
- Including proof of proper transcoding transactions on chain, which the protocol will use as input to determine the allocation of newly minted Livepeer Token.
Essentially, transcoders will play an analogous role to block producers. They will earn a portion of the block reward for playing this role, and will be incentivized to act honestly, lest they lose the valuable position of holding this role.
Nodes will optionally stake their existing Livepeer token in order to elect a fixed number of transcoders, who will be expected to be running efficient hardware setups in order to perform the role of transcoding and verification of work performed on the network. Protocol determined network params will determine the number of transcoders, the number of verifications that must be performed on each stream, and the routing procedure to randomly route jobs to transcoders in a distribution relative to delegated stake. In return for staking token in order to participate in the election process, nodes will earn broadcasting fees.
The protocol will also determine the appropriate time periods required for staking, for withdrawing stake, and for casting and changing delegation amounts for transcoders. These tunable parameters will move to ensure that the network operates in a game theoretically secure manner that also keeps up with the demand for transcoding verifications across the network.
Verification of transcoding work will be accomplished using scalable extensions to the Truebit protocol. See the whitepaper. Transcoders will be responsible for claiming the work that they did on chain, and they'll be forced to pass verification of random segments of work in order to earn their fees and portion of block reward.
The goal of the above high level description is to provide the following incentives:
- Transcoding nodes want to transcode so that they can receive fees and increase their share of future work.
- Transcoding nodes don’t want to cheat at transcoding, because they will be caught and get their stake slashed by a higher amount than they can expect to gain by cheating.
- Nodes want to stake their token in order to earn fees and future work in proportion to their stake.
- Nodes want to vote for properly acting transcoders because it ensures the efficient performance of the protocol, therefore increasing the usefulness of the network.
While there is lots of research and design work to do in developing and submitting the Livepeer Protocol for peer review, there are three areas of deeper research which will have to be focused on in order to ensure that the network is as secure as possible.
- Computation verification (Proof of transcoding)
- Network efficiency and avoiding useless work
- On-chain scalability
Computation verification can be summarized by "ensure that the transcoding node actually outputted a correct transcoding of the original content." It would be bad if a transcoding node could accept a transcoding job, just output zero-bytes, and get credit for it in the process of earning fees and newly generated token. The Livepeer protocol will defend against this through the process of computation verification, as inspired by Ethereum Computation Markets, Truebit, and Computational Courts, however there are practical challenges to using these solutions today [7]. They are at various stages of concept to production readiness, there are many transcoding algorithms, which are computationally complex and not necessarily deterministic depending on parameters, and verifying these algorithms on chain may be prohibitively expensive or infeasible. Livepeer will contribute to the active research in these areas, and find the best solution that applies to the specific problem of proof of transcoding with a limited set of protocol enabled operations.
Whereas (debatable) useless work in Bitcoin or Ethereum occurs when miners broadcast empty blocks with no transactions included, useless work in the Livepeer network would consist of nodes broadcasting empty or useless video that no one wants to consume. Why would they do this? If nodes must transcode and distribute video in order to earn a portion of fees and future work, then incentives could exist for people to control the peer arrangement in the network, and broadcast useless video to do useless work to earn outsized portion of token. The network and protocol defend against this using a DPOS and token distribution scheme, along with randomized job assignment, which makes it more economically efficient to simply stake one's token towards a properly behaving node, then to attempt to self deal and split fees with other delegators. However further research will be conducted at techniques to mitigate this challenge, at the protocol and implementation level.
In an ideal world, the Livepeer Protocol would use evidence of every single transcoding job in order to compute the distribution of the newly minted token. Unfortunately, recording a transaction to include all of this data on chain would be both expensive, and not supported capacity wise by existing blockchain platforms. The Livepeer Protocol attempts to account for this by using random assignment of transcoders and random inclusion of transcoding evidence on chain, in order to fairly distribute the token in proportion to the amount of work done and stake bonded. However, as the network scales to support more concurrent streams, and more nodes playing the role of transcoder, there are weaknesses with this approach including lower probability of inclusion for nodes with less transcoding power, and more incentives to attempt to avoid unrewarded work for nodes with the ability to precompute or determine whether or not work is likely to be included. The more evidence that can be included on chain the better, and an active area of research within Livepeer will be on chain scalability to efficiently include more transactions and more data per transaction without increasing the cost to the network.
The Livepeer project is concerned with decentralizing one-to-many live video broadcast (multicast). This is the truest form of media distribution, as it allows a broadcaster to connect directly with their audience in a first-hand manner, free from alterations, after-the-fact interpretation, and spin. It gives everyone a platform to have a voice. Existing centralized solutions can suffer from censorship, third party control over user data/relationship/monetization, and inefficient cost structures around payment for the service. Here are some of the logical use cases for applications and services to be built on top of Livepeer.
With a transfer of value transaction baked into the protocol, it is now possible for broadcasters to charge viewers directly for the consumption of their live broadcast, without requiring a credit card, account, or control over user identity via a centralized platform. This has applications in education (pay to attend an online course), events (pay to view a concert or live sporting event), entertainment (pay to watch a gamer or performer's live stream), and many other use cases - all while preserving the privacy of the viewer, and allowing them to pay for only what they consume directly to the broadcaster.
One of the challenges of building consumer video services today is scaling infrastructure to support the demand for the growing number of streams and growing number of consumers as new users are added. A service layer that easily lets developers begin building their video solution on top of the Livepeer Network, which will automatically scale to support any number of streams and viewers as they go, will be a welcome solution to infrastructure developers who would otherwise have to continue provisioning servers, licensing media servers, and efficiently manage resources to handle spikes.
Current platforms such as Twitter and Facebook provide amazing live video solutions for reaching a large audience, but they're also the first to get blocked or censored in a variety of political conflict situations. Use of a decentralized network such as Livepeer would render it nearly impossible to prevent the word from getting out as to what is really going on on the ground in realtime.
Decentralized apps (DApps) are beginning to emerge, driven largely by the Ethereum ecosystem. However, to date there hasn't been a viable solution for embedding live video within a DApp without using a centralized solution or limiting the number of consuming clients based on the constraints of WebRTC. By introducing Livepeer to the stack, an application can be fully decentralized, yet still contain live video, at scale, to as many users as wish to consume it.
In conclusion, in the short term the Livepeer Project enables decentralized live video broadcast with incentives to the network for the first time, and in the long term the fact that the protocol is open and incentive based will result in a network which is cheaper to use for broadcasters than existing centralized solutions. The project is open for contributions on all fronts, so please don't hesitate to get in touch and get involved.
- Ethereum White Paper - Vitalik Buterin - Ethereum Wiki - https://github.com/ethereum/wiki/wiki/White-Paper
- http://m.sportsbusinessdaily.com/Daily/Issues/2016/02/19/Media/MLBAM-OTT.aspx
- Fat Protocols - Joel Monegro - USV Blog - http://www.usv.com/blog/fat-protocols
- Crypto Tokens and the Coming Age of Protocol Innovation - Albert Wenger - http://continuations.com/post/148098927445/crypto-tokens-and-the-coming-age-of-protocol
- The Case For SectorCoins - Eric Tang - https://medium.com/@ericxtang/case-for-sectorcoins-b70a7c820c2d#.7892n4a57
- Delegated Proof-of-Stake Consensus - Daniel Larimer - https://bitshares.org/technology/delegated-proof-of-stake-consensus/
- Truebit - Christian Reitweisner - https://medium.com/@chriseth/truebit-c8b6a129d580#.r19rtw81c
- swap, swear and swindle, incentive system for swarm - viktor trón, aron fischer, dániel a. nagy, zsolt felföldi, nick johnson - http://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf
- Kademlia: A Peer-to-peer Information System Based On The XOR Metric - Petar Maymounkov and David Mazieres https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf