Livepeer中文白皮書(翻譯)

時間 2019-11-24

標籤 livepeer 中文白皮書翻譯简体版

原文原文鏈接

Livepeer Whitepaperhtml

分佈式視頻流媒體傳輸協議及經濟激勵git

Doug Petkanics doug@livepeer.org
Eric Tang eric@livepeer.org github

摘要算法

Livepeer項目旨在提供一種徹底去中心化、高度可擴展、加密Token激勵的實時視頻流網絡協議，併產生一種解決方案，該解決方案能夠做爲去中心化式開發（Web3）堆棧中的實況媒體層。此外，LIVEPER旨在爲任何現有的直播提供一種經濟高效的集中直播解決方案。在本文中，咱們描述了LIVEPELL協議——基於博弈的理論上安全的方法，用於激勵現場視頻直播網絡中的參與者。咱們提出的解決方案，去中心化工做的可擴展性驗證，以及防止無用的工做，試圖在通貨膨脹系統中的Token分配遊戲。編程

目錄安全

Livepeer Whitepaper

直播視頻棧

Livepeer協議

工做的驗證

關於TruteBIT的備註

攻擊

參考

注意：本文檔將繼續沿着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 期間容許有一個變化：對於任何候選的轉碼器，最低的提供價格/段被鎖定而且不能被移動，可是其餘轉碼器候選能夠向下調整它們的價格/段。這使他們可以匹配網絡上最低的報價，若是他們但願，以保證他們的股權加權份額的工做在網絡上。在這段時間內，他們不容許將報價上調。

這裏是一個轉碼器選項的示例狀態，在決定委託給誰時，委託人能夠查看該選項。

Transcoder ID	PricePerSegment	BlockRewardCut	FeeShare
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