Livepeer Whitepaper
分布式视频流媒体传输协议及经济激励
Doug Petkanics [email protected]
Eric Tang [email protected]
翻译
Elnino Wang [email protected]
摘要
Livepeer项目旨在提供一种完全去中心化、高度可扩展、加密Token激励的实时视频流网络协议，并产生一种解决方案，该解决方案可以作为去中心化式开发（Web3）堆栈中的实况媒体层。此外，LIVEPER旨在为任何现有的直播提供一种经济高效的集中直播解决方案。在本文中，我们描述了LIVEPELL协议——基于博弈的理论上安全的方法，用于激励现场视频直播网络中的参与者。我们提出的解决方案，去中心化工作的可扩展性验证，以及防止无用的工作，试图在通货膨胀系统中的Token分配游戏。
目录
注意：本文档将继续沿着1.0部署Livepeer的路径进行更新。检查更改。
介绍和背景
在过去的几年中，去中心化网络的愿景已经开始实现，随着Ethereum等网络的出现，使得计算是可信任的，Swarm 和 IPFS/Filecoin，以实现去中心化的存储和内容分发，比特币和各种代币项目以促进p2p价值转移，以及去中心化的名称注册管理机构如Blockstack和ENS 为内容和身份提供人性化的名称。这些元素构成了分布式应用程序(DApps)的基础，以大部分静态或不常更新的Web或移动内容的形式构建，但目前DApps仍然缺乏以开放和去中心化的方式包含流媒体和数据的能力。Livepeer项目的目标是通过互联网去中心化直播视频。
Livepeer项目概述(https://github.com/livepeer/wiki/wiki/Project-Overview) 提供了一个很好的介绍当前视频在互联网上的状态。该白皮书将主要集中于Live对等的加密经济协议细节，而不是业务案例，但总而言之，该概述描述了以快速、集中和昂贵的方式增长的直播流的当前状态。另一方面，完全去中心化的P2P解决方案，其中节点贡献自己的计算和带宽的流式直播视频服务将更加开放和可扩展性，因为将没有限制的数量，可以提供的连接。
当然，这种技术在一定程度上是可用的，但到目前为止，还没有激励用户运行提供此功能的节点，也没有合适的资金来开发开放协议，这可以有利于整个互联网的发展。而不是一个集中的公司。然而，随着最近出现的密码Token供电协议[2, 3]，现在有机会同时激励用户向实时视频直播贡献计算和带宽，这与资助开放媒体服务的发展相一致。ER解决方案能够根据所有最新的标准和格式，以达到全范围的设备提供实时流视频。此外，传统上认为是Token供电协议的经济行为表明，为了使用Livepeer网络，直播发布者的成本可能比任何集中式解决方案的成本便宜。
随着LIVER对等技术和协议的交付，它将使用户能够参与以下流程：
- 在相机、电话、屏幕或网络摄像头上捕获视频并将其发送到Livepeer网络。
- 在网络中运行的节点将把它编码成所有必需的格式，以达到每一个支持的设备。运行这些节点的用户将通过ETH广播支付的费用来激励，并有机会通过协议Token来建立声誉，以赚取将来执行更多工作的权利。
- 网络上的任何用户都可以请求查看流，并且它将在近实时地自动分发给它们。
直播视频栈
直播视频的技术栈已经发展了多年，包含了很多层。直播发布者需要在视频源处捕获视频，与媒体服务器接口，以处理和将视频转换成多种不同的格式，通过网络分发视频，然后允许终端消费者以高感知质量播放视频。当人们思考这个堆栈时，也会出现一些经济问题，比如应该是直播发布者还是消费者，他们应该支付带宽来传输视频。
一个典型的实时流媒体平台需要支持H.264和VP8编解码器中的RTMP、HLS、MPEG DASH视频格式。新的编解码器如H.265/HEVC、VP9和AV1将在不久的将来变得更加流行，因为消费者变得更习惯于更高的视频质量。对于单独的HLS，苹果建议 比特率从145kb/s一直到7800 kb/s，以便服务于不同条件下不同类型的设备。所有这些都为直播视频增加了大量的复杂性和成本。
现有的去中心化开发堆栈（Web3）包含了对直播视频平台所需的一些层的解决方案，如文件传输和支付，但目前还没有解决方案，用于捕获和接口、转码和处理，以及现场视频的服务层。为此，Livepeer 介绍了 Livepeer Media Server (LPMS)—— 一个媒体服务器的开源实现，它提供了DAPP开发者和现有直播发布者所需的所有直播视频特定功能，以将实时功能构建到他们的应用程序中。在这里阅读更多。
作为一个独立的应用程序，任何开发人员都可以在LPMS之上构建一个实时应用程序，但是它仍然是集中式的，并且需要通过传统方式进行缩放。然而，当Livepeer的每个节点运行LPMS时，协议的经济激励确保这些节点将贡献其处理能力和带宽，在转码和分发实时视频的服务中，自缩放，现收现付网络。对于开发人员来说，他们可以简单地将他们的直播流发送到网络中，并将缩放，付款和媒体托管的实施细节提取出去即可。
Livepeer 协议
Livepeer协议定义了流媒体生态系统中的各种参与者如何以安全和经济合理的方式参与。协议需要解决的两个主要领域是直播视频从源到大量消费者的实际分发，以一种性能和可扩展的方式，以及鼓励以安全和博弈的方式参与网络的经济激励。虽然该白皮书将触及与经济协议重叠的实时视频分发本身，它将主要集中在后者，以证明安全性和经济一致。在最高级别，协议被设计为：
- 允许任何节点向网络发送直播视频，并可选地付费将其转换成各种格式和比特率。
- 允许任何节点请求来自网络的视频。
- 允许参与者在转码和视频分发服务中贡献他们的处理能力和带宽，并相应地得到补偿。
在一个区中心的网络中，参与者与他们所贡献的工作量成比例，需要确保安全的两大挑战是：
- 可以验证节点所做的工作是否正确？
- 节点被授予对网络贡献价值的实际工作，而不是为了试图不公平地获得Token分配而伪造的工作？
Livepeer协议被设计用于解决工作的验证和预防伪造工作，同时也为网络的自动可扩展性提供解决方案，并且随着时间的推移实现协议演进的治理。
视频片段
Livepeer中的媒体的核心单元是我们将称为段的部分。段是时间长度t的多路复用音频和视频的时间切片块。Livepeer网络中的每个段都是唯一的，并且包含加密证据，以验证直播发布者为这个特定的段打算这个特定的数据。每个流由许多连续的段组成，每个段包含一个序列号来标识它们的正确排序。一个段包含以下字段：
StreamID | 标识此段属于的源节点和流。 |
SequenceNumber | 该段属于原始流的顺序。 |
DataPayload | 表示该段中音频/视频的二进制元数据和数据。 |
DataHash | 数据有效载荷的哈希。 |
BroadcasterSignature | 来自 Priv(StreamID, SequenceNumber, hash(StreamID, SequenceNumber, DataHash)) 的一个签名，它可以用来证明和验证直播发布者声称这是这个独特片段的真实数据。 |
Livepeer协议通常使用段作为转码、分发和支付的工作单元。
Livepeer Token
Livepeer Token（LPT）是Livepeer网络的协议Token。但它不是交换Token的媒介。直播发布者使用以太币（ETH）在网络上播放视频。贡献处理和带宽的节点从直播发布者的收费形式获得ETH。LPT是一个标记Token，参与者想要在网络上执行工作，以协调工作如何分布在网络上，并提供工作将得到诚实和正确地完成的安全性。LPT有以下目的：
- 它作为一个结合机制，在一个委派证明的股份系统，其中的股权委托给转码者（或验证者）参与协议转码视频和验证工作。Token和由于协议违反而发生的潜在削减是必要的，以确保网络免受多个攻击。下面更多。
- 它通过与赌注和委托Token的数量成比例地通过网络进行工作，本质上是一种协调机制。
- 它是一个特定的账户单位，它形成了一个部门货币概念的基础，适用于未来将要引入的附加功能[4]。诸如DVR、封闭字幕、广告插入/货币化和分析等服务都可以插入到Livepeer生态系统中，并且潜在地利用STP LPT提供的安全性。
Livepeer Token的初始分配将被分配，以便利益相关者可以在网络中使用各种角色，然后根据算法编程的发布随着时间的推移发出附加Token。参见Token 分布 部分。
遵循以太坊和许多流行的ERC20Token [16] 的约定，LPT可以被10 ^ 18整除，更大的面值，比如LPT本身打算用于用户级别的交易，例如staking，以及用于协议计费的较小面值。
协议角色
在继续之前，让我们定义网络中的角色，以便讨论协议有一个共同的词汇表。Livepeer节点是运行Livepeer软件的任何计算机。
直播发布者 | Livepeer节点发布原始流。 |
转码器 | Livepeer节点执行将流转码为另一种编解码器，比特率或打包格式的工作。 |
中继节点 | Livepeer节点参与实时视频的分发和协议消息的传递，但不一定执行任何代码转换。 |
消费者 | 请求流的Livepeer节点，可能会查看它或通过网关将其提供给他们的应用程序或DApp的用户。 |
除了运行Liverpeer对等节点的用户所扮演的上述角色之外，协议还将参考以下系统。虽然我们使用某些特定的系统来引用可能的实现，但如果提供类似的功能和密码经济保证，也可以交换替代系统：
Swarm | 内容寻址存储平台。在验证过程中，可以通过SWEAR协议[1] [7, 12] 暂时保证数据在那里可用。（本文档中的注释我们指的是群，但是如果数据可用性可以以高概率保证），可以替代其他内容寻址的存储平台。 |
Livepeer 智能合约 | 基于以太坊网络的智能合约 [1]. |
Truebit | 黑盒验证协议，保证了计算链正确性（以高昂的代价） [6]. (http://truebit.io) |
下面是角色的可视化概述，以及它们在下面描述的工作验证过程中相互通信的方式。
*从直播发布者到转码器的部分，最终流向消费者。转码器确保他们有签名和证明工作参与工作验证程序。
关于转码器的注释： 转码器在Livepeer生态系统中扮演最关键的角色。他们是正在接受输入流并将其转换为多种不同格式并及时进行低延迟分发的人员。因此，它们受益于高可用性、高效、强大的硬件（潜在地具有GPU加速的转码）、高带宽连接和坚实的DevOps实践。转码器应该比其他网络参与者少得多，因为当他们从事对流进行转码的工作时，如果它们掉在网络上就不太理想了。虽然网络可以扩展以支持许多参与者扮演代码转码器的角色（并且赚取必要的Token分配），但这是大多数网络参与者委派的特殊角色，以确保为直播提供价值的可靠网络得到维护。更多关于这个代表团。
共识
Livepeer有两层共识系统。LPT分类帐和交易由底层区块链（如以太坊）担保。LPTToken或系统中的任何交易的任何转移都可以被认为是与基础的工作证明或股权链的证明相同的安全性。然而，第二层决定新生成的LPT的分布。这是由Livepeer智能合约管理的，并且由不同的参与者参与协议。虽然没有一致要求，但在接受和验证以前的区块方面，该协议定义的参与规则和条件下，演员将因未能履行自己的角色受到惩罚（削减）。
第二层次的共识管理新生成的Token是基于委托的股份证明（DPOS），灵感来自于系统，如Bitshares，Steem，Tendermint，和Casper [5, 9, 10, 11]。验证器在网络中的角色由转码器来扮演。任何用户都可以将他们的股份委托给代码转码器，后者需要在网络中执行代码转换作业，参与工作验证协议，并在特定的时间间隔调用链上的函数来验证这项工作。该协议将分发费用和新生成的token，并将削减行为不良的角色的股份。验证结果将在TwiteBIT完成验证之后通过Truebit记录在链上，因此直播发布者和转码器之间不会有争执的余地。
绑定+授权
在Livepeer，为了表示网络中的股份，节点必须结合一定数量的LPT。他们通过Bond()交易来完成交易，这将把他们在智能合约中的股份绑在一起，直到他们 Unbond()，在这一点上，他们将进入一个非绑定状态，该状态将持续到UnbondingPeriod。在完成 UnbondingPeriod 之后，他们可以撤回其LPT。
键合量用于将赌注委托给转码器。该网络在任何时候支持N个活动的转码器，这是一个可移动的网络参数。任何节点都可以表示它希望成为具有 Transcoder() 事务的转码器，并且该协议将在每个回合开始时选择具有最多累积的份额（其自身+来自其他节点的委托）的 N个 转码器，以及来自等待列表的一个随机转码器。
在Livepeer中，新生成的token与绑定的节点的数量成比例（减去费用），只要它们被委托给根据协议运行的转码节点。如果他们委托的节点不遵守和违反一个削减条件，则可以削减债券（减少一定百分比）。向转码器绑定和委托的节点也会接收转码器通过网络上的转码作业生成的部分费用。本质上，执行工作的节点赚取直播发布者为该工作支付的费用。
展望未来，当该文档使用术语“委托人”时，它指的是绑定节点将他们的股份委托给转码器候选，而不是将其作为转码器委托给他们自己。
综上所述，参与者选择结合他们的股份,理由如下：
- 参与向有效的转码器的委派，为网络提供巨大的服务，确保其对直播电台的价值。
- 以分配比例与持股比例建立声誉和未来的工作分配。
- 赚取来自转码器产生的费用。
- 他们可能希望成为转码器。
Transcoder()事务
一个节点通过提交一个Transcoder() 事务表明他们愿意成为一个转码器，它将公布以下三个属性：
- PricePerSegment：他们愿意接受的最低价格来转码一段视频
- BlockRewardCut：保税节点为转码服务支付的块奖励的百分比。（例2％，如果一个绑定节点在块奖励中接收到100个LPT，则向转码器接收2个LPT）。
- FeeShare：转码器愿意与委托给它的保税节点共享直播作业的费用百分比。（例如25％。如果一个代码转码器收到100个ETH的费用，他们将向保税节点支付25个ETH）。
转码器可以更新它们的可用性和信息直到下一轮代码转换之前的RoundLockAmount时间。这是作为一轮的百分比提供的。（示例10% == 2.4 小时）。他们可以改变这个信息，直到下一个代码转换回合持续1天之前的2.4小时。这使得保税节点有机会审查相对于其他转码器的费用分割和token奖励分割，以及基于他们计费和网络需求的费率的预期费用，并且如果他们愿意，可以移动他们的代理权益。在代码转换回合开始时（由对InitializeRound()的事务调用触发），该回合的活动转码器基于委托给每个转码器的总赌注确定，并且在该回合持续期间锁定和速率被锁定。
在RoundLockPeriod 期间允许有一个变化：对于任何候选的转码器，最低的提供价格/段被锁定并且不能被移动，但是其他转码器候选可以向下调整它们的价格/段。这使他们能够匹配网络上最低的报价，如果他们希望，以保证他们的股权加权份额的工作在网络上。在这段时间内，他们不允许将报价上调。
这里是一个转码器选项的示例状态，在决定委托给谁时，委托人可以查看该选项。
1 | 22 wei | 1% | 25% |
2 | 30 wei | 2% | 40% |
3 | 10 wei | 4% | 1% |
... | ... | ... | ... |
N | 14 wei | 0% | 2% |
注意价格：在这份文件中，我们列出价格/段。在现实中，Livepeer计划使用一个gas会计启发模型，其中有一个概念的单位的gas所需的某些工作参数的一个环节，如比特率，编码，帧大小等。价格/段是一个立场，激励是相同的，但实际上他们很可能是沟通中的价格/gas。
直播+转码作业
在网络上开放业务的转码器通过提交一个TranscodeAvailability()事务将他们的帽子投入到代码转换工作中。这表明它们的可用性，并将它们放入一个可用新提交的工作的转码器池中。
当直播发布者将其流提交到Livepeer网络时，它被赋予StreamID。这既充当唯一标识符，又包含源节点地址，以便节点知道如何请求和路由请求，以将该流消耗到原点。该流包含许多连续的Segments，如Video Segments 中所描述的。如果直播发布者希望网络将其流转换成所有的格式和比特率，以达到每个设备上的每个用户，那么第一步就是提交一个链上的转码作业事务。作业也被赋予唯一的ID，并且作业的输入数据包括：
TranscodingOptions 定义了输出比特率、格式、编码等，并且PricePerSegment列出了直播发布者将提供的价格。
一旦该事务被挖掘，下一个块哈希将被用于伪随机地确定为该作业选择的转码器。所有价格低于或等于所提供价格的转码器将被考虑，而块哈希模数的候选转码器（由它们的赌注加权）将决定所选代码转码器的索引。
在这一点上，直播发布者可以开始向转码器流视频片段，并且他们将参与以下协议。该协议还使用持久性存储解决方案，例如Swarm，作为工作验证过程的一部分。
预处理
- 直播发布者 -> Livepeer智能合约：在链上提交存款以支付全部转码作业的费用。这可以在以后的任何时候重新填写，但是如果存款在完成工作时逐渐用完，转码器可能会停止工作。
作业
- 直播发布者 -> Livepeer智能合约：工作(streamID, 选项, 价格/细分市场)
- 在链上创建作业请求，并在托管中放置一些ETH来支付工作费用。
- 该协议可以使用下一个块哈希来确定性地为该作业选择正确的转码器。
- 转码器> 播音员：发送输出流和收据，接受工作。
- 直播发布者> 转码器：发送流段，其中包含验证输入数据的签名。
- 转码器 执行转码，并使新的输出流可在网络上使用。
- 转码器：为转换工作的每一段存储一个转码收据。转码收据具有以下字段。
StreamID | 标识此段属于的源节点和流。 |
Sequence Number | 该段属于原始流的顺序。 |
Input Data hash | 输入段数据有效载荷的哈希。 |
Transcoded Data hash | 在对该段进行转码后输出数据的哈希。 |
Broadcaster segment signature | 来自 Priv(StreamID, Seq#, Dhash)的直播发布者的签名，可以用来证明和证实直播发布者声称这是这个独特片段的真实数据。 |
Transcoder segment signature | 来自转码器的所有上述字段的签名，证明该特定输出转码是在该特定输入上执行的。 |
每当转码器观察到它们不再接收片段时，它们可以调用 ClaimWork() 来声明它们的工作。
结束工作
- 转码器 -> Livepeer智能合约：调用ClaimWork(JobID, StartSegmentSeq#, EndSegmentSeq#, MerkleRoot)。转码器声称在链上他们已经在声明的代码段范围内执行了任务，所有代码转换接收数据的merkle根都提交给这些编码代码段的内容。
- 等待这笔交易被挖矿，并观察下一个块冲突。协议然后可以根据VerificationRate确定哪些段将被验证。
- 转码器 -> Swarm：使用SWEAR参数为将要通过验证挑战的片段写入输入数据有效载荷，以确保数据在那里足够长以进行验证（VerificationPeriod时间）。
- 转码器 -> Livepeer智能合约：为需要验证的每个细分市场提供链式转码声明，以及转码声明中每个细分市场收据的merkle证明。智能合同可以验证来自直播发布者和转码者的签名以确保所有必要的数据可用于进行验证，并且可以验证来自ClaimWork()的承诺的merkle根的merkle证据。
- 转码器 -> Truebit：Verify()。这是对Truebit智能合约的链接调用，转码者为挑战的段提供Swarm输入哈希。（关于下一节中的验证的更多信息）
- Truebit -> Livepeer智能合约：工作结果以连锁书写。这与转码者提供的转码声明结果进行比较。
- Livepeer智能合约：此时，Livepeer智能合约拥有确定转码器工作是否得到验证所需的全部信息。
- 如果验证正确，则用作Token分配算法和释放托管费用的输入。
- 如果不正确，那么转码器及其代码会削减FailedVerificationSlashAmount，直播发布者将退还。
直播发布者可以在任何点停止发送段，这实际上是一个EndJob()。
在这一点上，已经执行了转码，已经在链上声明了工作的证明，并且已经报告了对该工作的验证的失败或成功。所有的信息都在链上，以确定费用分配和token分配给转码器和委托人，或者在失败验证的情况下削减。让我们来看看工作是如何被验证的。
工作的验证
为了向那些声称已经执行转码作业的转码器分配费用，协议有必要确定该作业实际上是以高概率正确执行的。为此，Livepeer扩展了 Truebit 协议 [6]的研究，并使用。
Truebit通过让一名参与者（求解器）执行实际的工作来进行收费，在本例中为转码，然后让其他的参与者（验证者）验证工作以检测错误、出错或作弊。任务被分解成非常小的步骤，验证者检查求解器的工作，找到与预期的不同的第一步。然后，只有一个非常小的步骤需要在一个智能合约（裁定）的链条上进行，能知道哪一方正确地完成了工作。经济激励措施，包括强迫错误激励验证者的检查，确保不正确地欺骗或挑战是没有利润的，但发挥检查工作的作用是有利可图的。
该协议的缺点是，为了验证所有的工作，它的成本是原始工作成本的5-50倍。Livepeer使用Truebit作为一个黑匣子来验证片段，但是它只需要通过验证一小部分的片段来支付非常高的验证税，并且在失败验证的情况下使用slashing。在Livepeer中设置的VerificationRate决定了在Truebit中挑选特定片段进行挑战的频率，以及将工作提交到区块链之后的未来区块哈希的随机性，确定具体选择哪些片段。
如果通过块N中的 ClaimWork()调用提交工作，那么
如果 Sha3(N, BlockHash(N), Seg#) % VerificationRate == 0 那么段#必须验证。
转码器通过调用Verify() 事务为候选段提供链上的转码请求。Livepeer智能合约可以使用内部签名验证这些声明的真实性，并提供梅克尔证据，然后调用Truebit来验证这些片段。
Truebit求解者和验证者从持久的内容寻址存储系统（如Swarm）访问片段的输入数据。转码器负责验证Swarm中的段数据是否可用，并且可以选择查找SWEAR协议[5]中的收据，以确保持续一段时间，这足以让Truebit发挥出来。此外，他们可以自行运行Swarm节点，确保数据可用于Truebit验证。如果他们有理由相信数据在Swarm中不可用，他们可以提供它，或者只需调用先前可用数据上的 ClaimWork() 。
Truebit会将计算结果（成功或失败）写回到Livepeer智能合约中，然后将其用于协议中的奖励和削减计算。转码节点不能预测哪些段将被验证，并且在作弊或未能正确转码时会感受到以下处罚：
- 如果失败了来自Truebit的验证，则FailedVerificationSlashAmount将被削减。
- 如果他们未能提供转码声明并且在他们被要求的部分上调用Truebit，则MissedVerificationSlashAmount将被削减。
- 从直播发布者收取损失费用。
- 转码者不仅会被削减，而且他们的所有委托人也会被削减。他们会将这个帐户纳入他们决定由谁来委派的方式，而转码者可能会失去他们持有的有利可图的工作。
重要的是，只需将LPT放在一个有效的，诚实执行的代码转换器上就可以获得更多的利润，而不是欺骗并采取大幅度的惩罚措施，同时为不诚实的工作收取费用和令牌分配。仔细选择削减参数和验证率可以确保这一点。
关于TruteBIT的备注
虽然协议使用Truebit，以提供完全可信的验证工作，但在实践中可能需要使用可用的解决方案，以验证Truebit在TetrueBIT尚处于开发和测试阶段时可提供的不可信度。一些选项，按不可信程度排序，包括：
1. 基于Livepeer API的Oracle - Trust Livepeer验证计算。非常集中，对于测试之外的任何东西都不理想。
2. Oraclize Computation Service - 信任提供计算证明的公司，其整个声誉依赖于外部数据链上的证据，它没有被篡改。
3. 安全硬件包- 英特尔SGX或TownCrier等服务提供可信计算环境。相信他们的硬件实现是正确的和安全的。这可以去中心化和审核。
Token的生成
Livepeer是通货膨胀的，因为根据以下在Token 分发中传达的时间表，将会生成并分配一些新的Token。如果Livepeer中的所有角色按照协议运行，那么新生成的Token将按其绑定的股份（减费用）分配给用户。转码器具有调用 Reward()函数的作用，以便触发新的Token分配或削减，这可以从链上可用的所有数据计算出来。
每个转码器都需要每轮调用一次Reward() 。
- 确保一个有效的转码器正在调用Reward()。
- 确保转码器在本轮中尚未调用Reward()。
- 根据InflationRate 计算Token到铸币的数量，铸许多Token。
- 根据他们的BlockRewardCut计算转码器的剪切。
- 将此分配到转码器的保税桩中。
- 将剩余部分分发给委托人奖励池。
- 将Token的保税金额更新到该转码器。
未能调用Reward()会导致丢失一部分Token分配的直接后果，并且当由委托人为角色选择时，显示为转码器的信誉。
削弱
如前所述，削减的条件是：
- 未通过验证
- 当需要时不调用验证
- 不基于委托股份在平台内执行所需工作的比例份额
在以太坊生态系统中构建的一个好处是网络效应对你能够从其他协议（如TruteBIT和Swarm/SWEAR）上得到的好处。不幸的是，依赖于这些外部系统，它们自身具有外部依赖性和激励机制，这些协议中的一个缺陷或弱点可能导致Livepeer中的削减。
例如，如果Truebit验证作业在他们的队列中长时间地等待，而没有任何求解者或验证者声明它，那么在调用Reward()之前，Livepeer将无法及时看到该验证的结果。或者如果Swarm网络遭受分区，并且不能及时将文件传播到TreeBIT验证器，那么这也可能会造成问题。
这些风险可以通过激励这些角色由Livepeer协议的参与者在内部发挥作用来缓解，这些参与者可能发现它们最有利于作为Truebit验证者或Swarm节点。但另一种方法是在削减参数中引入概率阈值的概念。可选协议变量，例如VerificationFailureThreshold可以设置为表示只要节点通过了99％的验证，它们就不会被削减。这仍然是网络部署之前需要研究的另一个研究领域。
任何Livepeer协议参与者都可以检查并调用无法调用验证削减条件。有一个FinderFee，它指定了取景器将作为成功调用这种削减条件的奖励而获得的斜线量的百分比。
剩下的大笔资金将进入CommonPool，根据该协议的治理机制，该CommonPool可以被烧毁或分配给常见的用途，例如进一步的生态系统开发。
Token的分配
作为代表通过DPoS算法参与和执行网络工作能力的标记，最初的Livepeer标记分布将遵循需要广泛分布的起源状态的其他DPoS系统的模式。
Token的初始分配将在网络的起源和早期阶段分发给社区。接收者可以使用它来加入转码器或委托者的角色。一部分将被分配给在事业发生前为协议贡献前沿工作和金额的团体，另一部分将被赋予核心项目的长期发展。
在网络启动时，Token发放将根据通货膨胀时间表继续进行，相对于未完成的Token浮动，在每轮的InflationRate生成Token。由于Token与协议中所有保税参与者的利益成比例发行，因此它可以激励积极参与。参与者受到通货膨胀的“保护”，因为他们获得了相应的份额。只有坐在代币上而没有参与其中的非活动参与者，他们会看到他们的比例网络所有权被这种通货膨胀所冲淡。
InflationRate的初始目标将被设置，目的是激励约LPT的ParticipationRate 被绑定和积极参与[19)。例如，如果ParticipationRate为50％，那么奖励将存在一半的优秀代币保税。通货膨胀率将通过算法循环来提升参与目标。更高的通货膨胀率会更有利于保税，而更低的利率会导致更多的人选择流动性而不是参与。正是这种流动性偏好与网络所有权百分比之间的折衷，由于网络中的许多经济因素，应该找到均衡。
治理
在Livepeer协议中治理的作用有三个目的：
- 确定由不当行为节点削减的共同基金的燃烧或挪用。
- 调整网络参数，以确保健康、繁荣的网络，这对直播发布者是有价值的。
- 以去中心化的方式调用提议的协议更新。
本文档中引用的许多网络参数（如UnbondingPeriod, RoundLength, ParticipationRate, 和 VerificationRate）均可调整。可以提交对这些参数进行调整的建议，并且治理过程（包括转码器根据其委派的股份投票）将决定在协议中自动采用这些更改。治理的详细规范留给其他文档。 在这里看到更多。
攻击
本节包含了恶意参与者可能试图攻击Livepeer网络的各种方式的调查。我们使用一个理性攻击者模型，其中攻击者根据自己的经济利益作出决定。许多攻击通过无利可图地进行这种攻击而得到缓解，但我们也努力确保在最坏的情况下，网络遭受持续的无利可图攻击的效率降低，并且不会遭受失败。
共识攻击
如前所述，Livepeer生态系统中的一致性是由底层区块链平台（例如以太坊）提供的。51%的攻击，LivepeerToken和网络分叉的两个花费将需要相同的资源和攻击成本，如以太坊本身。
Livepeer是一个基于协议的协议，虽然转码器具有参与工作验证过程和Token奖励分配过程的作用，但实际上它们不具有验证或接受其他转码器工作的角色。没有一个链的概念，也没有验证以前的块。只是存在经济激励来验证自己的工作，并在轮到时分配自己的Token分配部分。因此，在远程攻击证明，风险无关和贿赂攻击等利益协议证明中看到的攻击不适用，因为没有机会尝试签署多个块或尝试创建来自较早状态的较长链。然而，人们应该意识到，随着潜在区块链迁移到股份证明，如果在Livepeer上实施这些攻击的好处超过了以太坊本身的攻击成本，这些攻击确实会威胁到Livepeer。
虽然依靠底层区块链的安全性对于防止共识攻击是很好的，但仍然存在一类质量和效率攻击可能会损害Livepeer网络。
DDoS
Livepeer中的拒绝服务有两种方式：
- 转码器可以尝试阻止或减慢直播发布者通过接受作业但拒绝转码将其编码流发送到网络。
- 直播发布者可以阻止转码器完成他们认为是通过拒绝发送段来分配的工作。
这两种攻击都有代价，可以减轻，稍微有点烦恼。
在第一种情况下，转码器必须支付索赔链上的可用性。如果他们不收取费用，因为他们没有做这项工作，那么他们就会把ETH扔掉。直播发布者可以重新提交任务并分配一个新的转码器。可扩展性的一个潜在选择是，协议可以按优先级顺序标识多个有效的转码器，而不是仅一个，这样一来，直播发布者可以在没有另一个链上事务的情况下继续前进。此外，关于接受的工作的所有统计数据和平均代码段的转码/作业等，都可以从链数据中计算出来，并且委托人将其作为输入来决定他们向谁委托。表现不好，失去你的角色。
如果直播发布者阻止转码器工作，这只是一个容量规划计算。代码转换节点可以维护并发作业的容量记录，作业处于活动/不活动状态的可能性，并确保它始终认为它可以处理它声称的作业。简单地忽略或调用拒绝发送段的节点上的EndJob()几乎不会伤害转码器。
无用的或者自消耗的转码器
如果转码器拥有足够的股份来维持其位置，他们理论上可以列出100％ BlockRewardCut，0％FeeShare，并收取高价PricePerSegment，以便他们永远不必做任何工作，但可以收集他们的Token分配。这是由CompetitivenessTolerance （竞争力容忍度）阻止的，要求他们贡献一定数量的有效工作。另外，由于参与转码器产生的协议的交易成本，他们只需将他们的代币放在与他们分享费用的有效转码器上就会更有利，而不是像一个无用的转码器那样工作将不收取任何费用。
一个输出无效输出的行为错误的代码转换器很快就会被削减，因为他们的股权被削减得太低而不能真正保住工作并接受任何工作。
转码器Griefing
如果一个直播发布者想要使协议对于转码器非常昂贵，它可以发送转码器非连续的段号。这是因为在单个事务中，转码器可以要求对连续数量的段编号进行工作，但必须进行许多事务才能在随机段编号范围内请求工作。这可以通过以下选项进行辩护：
- 转码器调用EndJob()，不费心做这项工作，也不想收取费用。
- 协议实现链分析或更好的分段请求编码，以减少与在单个呼叫中请求非连续段相关的费用。
- 简单地忽略分段，从不要求工作。
这种攻击对直播发布者来说成本很高，因为他们必须有一个存款，并提交工作链上，甚至分配到一个转码器在第一位。他们有能力使生活烦扰的转码器，并可能失去效率，但不会对网络造成损害。
链重组
当直播发布者向Livepeer智能合约提交作业时，协议使用当前区块哈希来确定哪个转码器将被分配作业。底层区块链的重组可能会导致混淆。尽管这不是直接的“攻击”，但转码器将有效一秒，然后在重组时，将不再有效。当检测到重组时，直播发布者可以将流重定向到新的有效转码器，或者协议可以检测包含在主链中的叔代码块，并且如果给定阈值内的叔代码块将使他们有效，具考虑转码器是有效的。
直播视频分发
本白皮书主要集中在确保实时视频正确转码的经济激励和协议，这对于支持自适应比特率流和每个设备都是必要的。但同样重要的是在整个网络中分配视频，以便能够以高质量和低延迟消费视频。分发的经济性依赖于BitTorrent流行的的tit-for-tat带宽核算，并通过诸如SWAP [13] 等协议进行扩展。作为简化，节点付费请求一段视频，节点获得付费以服务一段视频。如果一个节点已经有一个段并且可以将它提供给多个请求者，这是有利可图的。我们称这种类型的节点为中继节点。
当涉及网络中扮演不同角色的节点的带宽时，存在不同的激励机制。
- 消费者可能愿意交换上行带宽以将内容提供给额外的消费者，以换取自己能够免费使用视频。请参阅Webtorrent [14] 之类的系统。
- 直播发布者作为原始节点，可能希望为视频消费收费，或者可能希望补贴带宽成本，以便每个人都可以免费访问他们的视频。
- 只要有利可图，转码器和中继节点都愿意提供分配视频服务的带宽。这与传统CDN的作用相似。
利用Segments作为数据流经网络的核心单元，可以使用ETH作为结算基础来进行tit-for-tat的带宽记帐。我们借用的支票簿合同抽象的Swarm[6]作为链式结算通过的离线支付方式。包括雷电网络[15] 在内的生态系统未来的发展也可能允许支付渠道用于此目的。由于Token传输是协议的本地特性，因此也可以将与内容相关的定价直接嵌入到协议中。直播发布者可以直接对其时间或内容收费，并且节点将通过支付更高的价格/分段来选择进行该价值转移，该价格/分段将流回直播发布者。
需要注意的是，虽然带宽记帐可以用于运行仅通过网络传输视频片段以增加容量的中继节点（CDN），但这些节点完全是由内容的需求激励的，而不是由新的Token分配激励的。事实上，Livepeer的输出可以插入到传统的CDN（如Amazon S3，Cloudflare等）或去中心化式CDN（如IPFS或Swarm）中。这种用于视频段分配的P2P协议的开发本身将是优化和改善性能的持续机会。
P2P的CDN已经被证明可以减少原始CDN服务器上的80-98％的带宽需求[17]，去中心化网络中看到的token机制可以让利益相关者协调开发和维护今天存在的专有P2P CDN的开放版本。PPSPP协议[18]作为开放实施的可行候选，专注于提供实时内容。
至于Livepeer协议的密码经济学并非至关重要，详细信息不在此文件中，但感兴趣的人可以在此处 进行开发，并查看为将来的文件寻址纯粹的视频分配协议。
Livepeer项目涉及去中心化一到多个视频直播（多播）。这是最真实的媒体分发形式，因为它允许直播发布者以直接的方式直接与听众联系，不受事实的解释和旋转的影响。它给每个人提供了一个发言的平台。现有的集中式解决方案可能遭受审查，第三方对用户数据/关系/货币化的控制，以及围绕服务付费的低效成本结构。下面是应用程序和服务在Livepeer之上构建的一些逻辑用例。
对内容消费即付即用
通过将价值交易转移到协议中，现在直播发布者可以直接向观众收取其直播的费用，而不需要通过集中式平台对信用卡、账户或用户身份进行控制。这在教育（付费参加在线课程）、活动（支付观看音乐会或直播体育赛事）、娱乐（支付观看游戏者或表演者的直播流）以及许多其他用例中都有应用-都在保持观众的隐私，并允许他们只直接支付给直播发布者。
自动缩放社交视频服务
如今构建消费者视频服务面临的挑战之一是扩展基础设施以支持不断增加的流的需求和随着新用户的加入而不断增长的消费者数量。一个易于让开发者开始在Livepeer网络之上构建他们的视频解决方案的服务层，它将自动缩放以支持任何数量的流和观众，这将是一个值得欢迎的解决方案。授权媒体服务器，并有效地管理资源来处理尖峰。
不能现场直播的新闻业
目前的平台，如Twitter和Facebook提供惊人的现场视频解决方案，以达到广大观众，但他们也是第一个在各种政治冲突局势中被封锁或审查的对象。使用一个去中心化的网络，例如Livepeer会使它几乎不可能防止这个词真正出现在实时的实际情况中。
启动视频的DApps
去中心化应用（Dapp）开始出现，主要由以太坊生态系统驱动。然而，到目前为止，还没有一种可行的解决方案，在不使用集中式解决方案的情况下嵌入DAPP中的直播视频，或者基于WebRTC的约束来限制消费客户端的数量。通过将Livepeer引入到堆栈中，应用程序可以完全去中心化，但仍然包含大规模的实时视频，以及愿意使用它的许多用户。
总结
总之，Livepeer协议激励节点在转码和分发实时视频的服务中贡献他们的处理和带宽到网络。工作验证是通过在TtrueBIT协议上的可扩展扩展来解决的，Truebit协议激励节点正确地执行代码转换操作，以赚取它们的费用和Token分配，并保持其作为转码器的价值获取角色。通过股权分置奖励会计委派证明的经济学解决了网络的虚假化和虚假工作问题。在执行实际上没有实际需求的工作时，简单地将一个Token绑定到一个增值节点比在网络上支付费用来分配给其他委托人更加经济合理。
最终的结果是一个可扩展的即付即用网络，用于去中心化式视频直播- Livepeer寻求填补的web3堆栈中缺失的一层。
附录
Livepeer 协议参数参考
T | 秒段长度 | 2 seconds |
N | 能用的转码器数量 | 144 |
RoundLength | 选择新一轮转码器之间的时长 | 1 day |
InflationRate | 目前每轮LPT的目标通胀率（算法移动） | .04% (相当于 15%/year) |
ParticipationRate | token与流通盘的目标百分比 | 50% |
RoundLockAmount | 转码器的费率在轮次结束时锁定该比例的这个百分比，以便委派者可以相应地进行审查和委托，而不用担心最后一刻的费率变化 | 10% == 2.4 hours |
UnbondingPeriod | 进入无约束状态和撤回资金的能力之间的时间 | 1 month |
VerificationPeriod | 提交工作索赔后验证工作声明的最后期限。 这也是在去中心化存储解决方案中必须提供数据持久性接收的最短时间 | 6 hours |
VerificationRate | 将被验证的分段的百分比 | 1/500 |
FailedVerificationSlashAmount | 在失败验证（超出潜在的允许失败阈值）的情况下可以削减的百分比 | 5% |
MissedRewardSlashAmount | 在缺少一个区块奖励轮的情况下可以削减的百分比（也许只有在连续n次失败的情况下才会这样做） | 3% |
MissedVerificationSlashAmount | 在换码转器未调用验证的情况可以削减的百分比 | 10% |
CompetitivenessTolerance | 如果所有转码器总是可用并且设置相同的价格和费用，则他们将按照他们的股份获得相应的工作。 该参数设置了必须在此目标工作百分比内才能符合token分配的百分比。 这可以防止转码器相对于他们的股份做少量工作 | 90% （极端的例子，100个转码器和100,000个代码段，这意味着如果我只做了100个代码段（1000个代码段中的10％应该这样做)） |
*SlashingThresholds (TBD) | Placeholder to indicate that we may not slash on all failures, only if they exceed some threshold % of failure rate. | 占位符表明我们可能不会对所有失败进行削减，只要它们超过失败率的阈值百分比 |
VerificationFailureThreshold | 可以在不被削减的情况下失败的验证百分比。因为像Swarm/Truebit这样可能导致零星故障的外部依赖关系很有用 | 1% |
FinderFee | % of slash amount that the finder will receive as compensation. 发现者作为补偿的金额削减的百分比 | 5% |
SlashingPeriod | 在 VerificationPeriod 结束后，调用截取条件的最后期限 | 1 hour |
Livepeer协议事务类型
Bond() | 债券转码 |
Unbond() | 输入固定的 UnbondingPeriod 的解除绑定状态 |
Transcoder() | 宣布你的意图是一个转码器 |
ResignAsTranscoder() | 作为转码器辞去你的意图 |
TranscodeAvailability() | 该转码器目前可以接受另一份工作。 他们在池中随机分配新的工作提交 |
Job() | 提交链上的转码作业 |
EndJob() | 结束工作以放弃转码责任 |
Deposit() | 提交一份将被用来支付工作的链条上的定金 |
Withdraw() | 撤回存款和无担保股份 |
ClaimWork() | 结束转码工作，并声明哪些段可以证明您已经通过段范围和merkle根进行了转码 |
DistributeFees() | 转码器在验证后声明特定索赔的费用。 |
Reward() | 链上的所有验证是否会削减或分配Token分配。 只能由当前一轮活动的转码器调用，每轮一次 |
Verify() | 转码器提供了分段的转码声明，这些代码段将与来自ClaimWork()的merkle根的merkle证明一起验证。 显式调用Truebit来执行验证 |
InitializeRound() | 该事务需要在新一轮启动块之后调用一次以初始化新的活动转码器 |
UpdateDelegatorStake() | 这允许授权人从前几轮申请费用+Token分配。 它是通过非绑定和绑定自动调用的，但是如果委托者希望在不更改状态的情况下进行更新，它可以作为故障安全。 |
*GovernanceTransactions() | TBD |
参考
- Ethereum White Paper - Vitalik Buterin - Ethereum Wiki - https://github.com/ethereum/wiki/wiki/White-Paper
- 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 - Jason Teutsch and Christian Reitweisner - https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf
- 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
- Steem Whitepaper - Daniel Larimer, Ned Scott, Valentine Zavgorodnev, Benjamin Johnson, James Calfee, Michael Vandeberg - https://steem.io/SteemWhitePaper.pdf
- Introducing Casper "the Friendly Ghost" - Vlad Zamfir - https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/
- Tendermint Docs - Jae Kwon and Ethan Buchman - https://tendermint.com/docs
- Swarm - http://swarm-gateways.net/bzz:/theswarm.eth/
- Incentives Build Robustness in BitTorrent - Bram Cohen - http://bittorrent.org/bittorrentecon.pdf
- WebTorrent - https://webtorrent.io/
- Raiden Network - http://raiden.network/
- ERC20 Token Standard - https://github.com/ethereum/EIPs/issues/20
- Peer5 leverages viewers’ devices for a P2P approach to streaming video - https://techcrunch.com/2017/01/26/peer5-y-combinator/
- Peer-to-Peer Streaming Peer Protocol - https://tools.ietf.org/html/rfc7574
- Inflation and Participation in Stake Based Protocols - Doug Petkanics - https://medium.com/@petkanics/inflation-and-participation-in-stake-based-token-protocols-1593688612bf