Описание Livepeer

Livepeer (LPT) - это децентрализованная сеть транслирования видео, построенная на блокчейне Ethereum. Протокол обеспечивает рентабельные услуги широковещательной и потоковой передачи непосредственно на уровне видео стека Web 3.0.

Метрики LPT

Стоимость Livepeer сегодня составляет 4,55 долларов США, а объем торгов за 24 часа - 1 633 996 долларов США. В текущем рейтинге CoinMarketCap LPT находится на 241 месте с рыночной капитализацией 96 205 092 долларов США. В обращении находится 21 164 655 монет LPT из макс. объема эмиссии в 22 906 951 монеты LPT.

Лучшими биржами для торговли в Livepeer в настоящее время являются CITEX, Poloniex, Gate.io, 0x Protocol и Radar Relay.

Токен Livepeer

Токен Livepeer (LPT) - это токен протокола сети Livepeer. Но это не средство обмена токена. Радиовещательные компании используют эфир Ethereum (ETH) для трансляции видео в сети. Узлы, которые вносят вклад в обработку и пропускную способность, зарабатывают ETH в виде комиссионных от вещателей. LPT - это токен для стейкинга, используемый участниками, которые хотят выполнять работу в сети, чтобы координировать распределение работы в сети и обеспечить безопасность того, что работа будет выполнена честно и правильно.

LPT имеет следующие цели:

• Он служит механизмом связывания в системе делегированного подтверждения доли, в которой доля делегируется транскодерам (или валидаторам), которые участвуют в протоколе для перекодирования видео и проверки работы. Маркер и потенциальное сокращение, которое происходит из-за нарушения протокола, необходимы для защиты сети от ряда атак.

• Он направляет работу через сеть пропорционально количеству поставленных и делегированных токенов, по сути, служа механизмом координации.

• Это единица учета, специфичная для экосистемы Livepeer, которая формирует основу концепции SectorCoin, применимой к дополнительным функциям, которые будут введены в будущем [4]. Такие сервисы, как DVR, субтитры, вставка / монетизация рекламы и аналитика, могут подключаться к экосистеме Livepeer и потенциально использовать безопасность, обеспечиваемую стейкингом LPT.

Первоначальное распределение токенов Livepeer будет распределено, чтобы заинтересованные стороны могли выполнять различные роли в сети и использовать ее, а затем дополнительный токен будет выпущен в соответствии с алгоритмически запрограммированной выдачей с течением времени.

Следуя соглашениям Ethereum и многих популярных токенов ERC20, LPT будет делиться на 10 ^ 18, причем большие номиналы, такие как сам LPT, предназначены для транзакций на уровне пользователя, таких как стекинг, и меньшие номиналы.

Livepeer Protocol

Протокол Livepeer определяет безопасное и экономически рациональное участие различных участников экосистемы потокового вещания. Двумя основными областями, которые должен решить протокол, являются фактическое распространение видео в реальном времени от источника к большому количеству потребителей эффективным и масштабируемым способом, а также экономические стимулы для поощрения участия в сети безопасным и теоретико-игровым манера. Хотя этот технический документ будет касаться самого распространения видео в реальном времени, которое частично совпадает с экономическим протоколом, он будет в основном сосредоточен на последнем, чтобы продемонстрировать безопасность и экономическое соответствие. На самом высоком уровне протокол предназначен для того чтобы:

 • Разрешить любому узлу отправлять живое видео в сеть и, при желании, платить за его транскодирование в различные форматы и битрейты.

• Разрешить любому узлу запрашивать видео из сети.

• Разрешить участникам вносить свою вычислительную мощность и пропускную способность в обслуживание перекодирования и распространения видео и получать соответствующую компенсацию.

В децентрализованной сети, где участники вознаграждаются пропорционально выполненной ими работе, для обеспечения безопасности необходимо решить две большие проблемы:

• Можно ли проверить, что работа, которую выполняли узлы, была выполнена правильно?

• Награждаются ли узлы за реальную работу, которая привнесла ценность в сеть, в отличие от фальшивой работы, выполненной в попытке несправедливо получить распределение токенов?

Протокол Livepeer предназначен как для проверки работы, так и для предотвращения поддельной работы, а также предлагает решения для автоматической масштабируемости сети и встроенного управления для эволюции протокола с течением времени.

Транскодеры играют наиболее важную роль в экосистеме Livepeer. Именно они принимают входной поток и своевременно конвертируют его во множество различных форматов для распределения с низкой задержкой. Таким образом, они извлекают выгоду из высокой доступности, эффективного, мощного оборудования (потенциально с ускорением перекодирования с помощью графического процессора), соединений с высокой пропускной способностью и надежной практики DevOps. Транскодеры должны выполнять отток гораздо меньше, чем другие участники сети, поскольку, когда они берут на себя работу по транскодированию потока, выход из сети не является идеальным. Хотя сеть может масштабироваться для поддержки многих участников, играющих роль транскодера (и зарабатывающих необходимое распределение токенов), это особая роль, которая делегируется большинством участников сети, чтобы гарантировать, что надежная сеть, которая представляет ценность для вещателей, поддерживается.

Консенсус

Livepeer имеет двухуровневую систему консенсуса. Реестр LPT и транзакции защищены базовым блокчейном, такой как Ethereum. Любая передача токена LPT или любая транзакция в системе может считаться подтвержденной с той же безопасностью, что и базовое доказательство работы или доказательство блокчейна доли. Однако второй уровень диктует распределение вновь созданных LPT. Это регулируется смарт-контрактом Livepeer и участием в протоколе различных субъектов. Хотя, скажем, не требуется консенсуса в отношении принятия и проверки предыдущих блоков, протокол определяет правила участия и условия, при которых субъекты будут наказаны (сокращены) за невыполнение своей роли.

Этот второй уровень консенсуса, регулирующий вновь сгенерированный токен, основан на Delegated Proof of Stake (DPOS), вдохновленном такими системами, как Bitshares, Steem, Tendermint и Casper. Роль валидаторов в сети выполняют транскодеры. Любой пользователь может делегировать свою долю транскодеру, который затем должен выполнять задания по транскодированию в сети, участвовать в протоколе проверки работы и вызывать функции в цепочке через определенные промежутки времени для проверки этой работы. Протокол будет распределять комиссию и вновь сгенерированный токен, а также сокращает долю участников с плохим поведением. Результат проверки будет записан в цепочке через Truebit после того, как он выполнит проверку, поэтому не будет места для споров между вещателем и транскодером.

Связь + Делегирование

В Livepeer, чтобы указать долю в сети, узлы должны связать некоторое количество своего LPT. Они делают это через транзакцию Bond (), которая связывает их долю в смарт-контракте до тех пор, пока они не Unbond (), после чего они войдут в состояние несвязанности, которое будет длиться в течение времени UnbondingPeriod. После завершения периода отсоединения они могут отозвать свой LPT.

Связанная сумма используется для передачи доли Транскодеру. Сеть поддерживает N активных транскодеров одновременно, что является подвижным параметром сети. Любой узел может указать, что он хочет быть транскодером с транзакцией Transcoder (), и протокол выберет N транскодеров с наибольшей совокупной ставкой (их собственные + делегированные от других узлов) в начале каждого раунда вместе с одним случайный транскодер из списка ожидания.

Вновь созданный токен в Livepeer распределяется по связанным узлам пропорционально объему работы, которую они связали (за вычетом комиссий), при условии, что они делегированы узлам перекодирования, которые ведут себя в соответствии с протоколом. Связи могут быть сокращены (уменьшены на определенный процент), если узлы, которым они делегированы, не ведут себя и нарушают одно из условий сокращения. Узлы, которые связаны и делегированы Транскодеру, также получают часть сборов, которые Транскодер генерирует посредством заданий транскодирования в сети. По сути, узлы, выполняющие работу, зарабатывают гонорары, которые вещатели платили за эту работу.

В дальнейшем, когда в этом документе используется термин «делегатор», он относится к связанным узлам, которые делегировали свою долю кандидату на транскодер, вместо того, чтобы делегировать ее себе в качестве транскодера.

Таким образом, участники решили закрепить свою долю по следующим причинам:

• Участвовать в передаче полномочий эффективным транскодерам, которые предоставят сети отличный сервис, обеспечивая ее ценность для вещателей.

• Создать репутацию и распределение будущей работы в виде выделенного токена пропорционально ставке.

• Зарабатывать на транскодерах.

• Стать транскодерами.

Генерация токенов

Livepeer является инфляционным в том смысле, что новые токены будут генерироваться и распределяться с течением времени в соответствии с графиком, приведенным ниже в разделе Распределение токенов. Если все роли в Livepeer работают в соответствии с протоколом, то вновь созданные токены будут распределяться между пользователями пропорционально их связанной доле (за вычетом комиссий). Транскодеры выполняют роль вызова функции Reward (), чтобы инициировать выделение нового токена или сокращение, которое может быть вычислено на основе всех данных, доступных в цепочке.

Каждый транскодер должен будет вызывать Reward () один раз за раунд.

• Убедитесь, что активный транскодер вызывает Reward ().

• Убедитесь, что транскодер еще не вызвал Reward () в этом раунде.

• Вычислить количество токенов для монетного двора на основе InflationRate. Чеканите столько жетонов.

• Рассчитайте сокращение транскодера на основе его BlockRewardCut.

• Распределите это на связанную долю Транскодера.

• Распределите остаток в пуле вознаграждения делегатов.

• Обновите привязанное количество токенов к этому транскодеру.

Неспособность вызвать Reward () приводит к прямому следствию потери части выделенных токенов и ухудшению репутации транскодера, когда дело доходит до избрания делегаторами на эту роль.

Одним из преимуществ построения в экосистеме Ethereum являются преимущества сетевого эффекта, которые вы получаете от возможности строить поверх других протоколов, таких как Truebit и Swarm / SWEAR. К сожалению, полагаясь на эти внешние системы, которые сами по себе имеют внешние зависимости и стимулы, вполне возможно, что недостаток или слабость в одном из этих протоколов может привести к сокращению внутри Livepeer.

Например, если задание проверки Truebit находится в очереди в течение длительного периода времени, и ни один решатель или проверяющий не запрашивает его, Livepeer не сможет увидеть результат этой проверки вовремя до вызова Reward (). Или, если в сети Swarm возник раздел и не удалось вовремя передать файл верификатору Truebit, это также могло создать проблему.

Эти риски могут быть уменьшены за счет стимулирования выполнения этих ролей внутри компании участниками протокола Livepeer, которые могут счесть в своих интересах служить в качестве верификаторов Truebit или узлов Swarm. Но есть и другой подход, который вводит понятие пороговых значений вероятности для параметров сокращения. Дополнительные переменные протокола, такие как VerificationFailureThreshold, могут быть установлены, чтобы указать, что пока узел проходит 99% проверок, они, например, не будут сокращены. Это останется еще одной областью исследования, которую предстоит проработать до развертывания сети.

Невозможность вызвать условие косой черты верификации может быть проверена и активирована любым участником протокола Livepeer. Существует FinderFee, который указывает процент суммы косой черты, которую искатель получит в качестве награды за успешное выполнение этого условия косой черты.

Остальная часть сокращенных средств поступит в CommonPool, который может быть сожжен или выделен для общих целей, таких как дальнейшее развитие экосистемы, в соответствии с механизмом управления протокола.

Распределение  токенов

В качестве токена, который представляет возможность участвовать и выполнять работу в сети с помощью алгоритма размещения DPoS, первоначальное распределение токенов Livepeer будет следовать шаблонам других систем DPoS, которые требуют широко распределенного состояния происхождения.

Первоначальное распределение токена будет распространено среди сообщества на начальном этапе и на ранних этапах сети. Получатели могут использовать его для выполнения роли транскодера или делегата. Часть будет выделена группам, которые ранее вносили свой вклад в работу и деньги для протокола до его возникновения, а часть будет выделена для долгосрочного развития основного проекта.

При запуске сети выпуск токенов будет продолжаться в соответствии с инфляционным графиком, при этом токен будет генерироваться по InflationRate за раунд относительно неоплаченного количества токенов в обращении. Поскольку токен выпускается пропорционально доле всех связанных участников протокола, он служит для стимулирования активного участия. Участники «защищены» от этой инфляции за счет получения своей пропорциональной доли. Только неактивные участники, сидящие на токене, не привязывая его к участию, увидят, что их пропорциональное владение сетью будет уменьшено этой инфляцией.

Первоначальный целевой показатель для InflationRate будет установлен таким образом, чтобы он был направлен на стимулирование приблизительно показателя участия LPT к привязке и активному участию. Например, если коэффициент участия составляет 50%, тогда будут существовать стимулы для привязки половины выпущенного токена. Уровень инфляции будет изменяться алгоритмически каждый раунд, чтобы увеличить целевой показатель участия. Более высокий уровень инфляции приведет к увеличению количества токенов для привязки, а более низкий уровень приведет к тому, что больше людей выберут ликвидность, а не участие. Именно компромисс между предпочтением ликвидности и долей владения сетью должен найти баланс из-за ряда экономических факторов в сети.

Управление

Роль управления в протоколе Livepeer состоит из трех частей:

1. Определите сжигание или присвоение общих средств, которые были вырезаны из плохо функционирующих узлов.

2. Настройте параметры сети, чтобы обеспечить работоспособность и процветание сети, которая представляет ценность для вещателей.

3. Вызов предложенных обновлений протокола децентрализованно.

Многие сетевые параметры, упомянутые в этом документе, такие как UnbondingPeriod, RoundLength, ParticipationRate и VerificationRate, можно настраивать. Предложения по корректировке этих параметров могут быть представлены, и процесс управления, включая голосование транскодеров пропорционально их делегированной доле, определит принятие этих изменений автоматически в рамках протокола.

Транскодер

Узел указывает на свою готовность стать транскодером, отправляя транзакцию Transcoder (), которая публикует следующие три свойства:

• PricePerSegment: самая низкая цена, которую они готовы принять за перекодирование сегмента видео.

• BlockRewardCut: процент вознаграждения за блок, который связанные узлы будут платить им за услугу транскодирования. (Пример 2%. Если связанный узел должен был получить 100 LPT в качестве вознаграждения за блок, тогда 2 LPT на транскодер).

• FeeShare: процент сборов за широковещательные задания, которые транскодер готов разделить с подключенными узлами, которые делегируют ему полномочия. (Пример 25%. Если бы транскодер получил комиссию в размере 100 ETH, он заплатил бы 25 ETH связанным узлам).

Транскодер может обновлять их доступность и информацию до времени RoundLockAmount перед следующим циклом транскодирования. Предлагается как процент от раунда.

(Пример 10% == 2,4 часа. Они могут изменить эту информацию за 2,4 часа до следующего цикла транскодирования, который длится 1 день RoundLength). Это дает связанным узлам возможность анализировать распределение комиссий и вознаграждений за токены по сравнению с другими транскодерами, а также ожидаемые комиссии в зависимости от тарифа, который они взимают, и сетевого спроса, и при желании перемещать свою делегированную долю. В начале цикла транскодирования (запускаемого вызовом транзакции InitializeRound ()) активные транскодеры для этого раунда определяются на основе общей ставки, делегированной каждому транскодеру, и ставки и ставки фиксируются на время этого цикла.

В течение периода RoundLockPeriod допускается одно изменение: самая низкая предлагаемая цена / сегмент для любого из кандидатов-транскодеров заблокирована и не может быть перемещена, но другие кандидаты в транскодеры могут скорректировать свою цену / сегмент в сторону понижения. Это позволяет им соответствовать самой низкой предложенной цене в сети, если они хотят, чтобы гарантировать свою долю работы в сети, взвешенную по ставкам. Им не разрешается повышать предложенную цену в течение этого периода.

Ниже пример состояния параметров транскодера, который делегат может просмотреть, решая, кому делегировать.

Вещание + Работа по транскодированию

2. Транскодеры, открытые для бизнеса в сети, подтверждают свою  готовность для работы по транскодированию, отправляя транзакцию TranscodeAvailability (). Это указывает на их доступность и помещает их в пул транскодеров, доступных для выполнения вновь представленной работы.
3. Когда вещательная компания отправляет свой поток в сеть Livepeer, ему присваивается StreamID. Он служит как уникальным идентификатором, так и содержит адрес узла источника, чтобы узлы знали, как запрашивать и направлять запросы для использования этого потока в направлении источника. Поток содержит множество последовательных сегментов, как описано в разделе «Сегменты видео». Если вещатель хочет, чтобы сеть позаботилась о транскодировании их потока во все форматы и битрейты, необходимые для достижения каждого пользователя на каждом устройстве, то первым шагом является отправка транзакции задания транскодирования по цепочке. Заданиям также присваивается уникальный идентификатор, а входные данные для задания состоят из:
4. Задание (StreamID, TranscodingOptions, PricePerSegment)
5. Параметры TranscodingOptions определяют выходные битрейты, форматы, кодировки и т. Д., А PricePerSegment перечисляет цену, которую будет предлагать вещатель.
6. Как только эта транзакция будет добыта, следующий хеш-код будет использован для псевдослучайного определения транскодера, выбранного для этого задания. Будут рассмотрены все транскодеры с ценой ниже или равной предложенной цене, а модуль хеширования блоков - количество транскодеров-кандидатов (взвешенных по их ставкам) будет определять индекс выбранного транскодера.
7. На этом этапе вещательная компания может начать потоковую передачу сегментов видео на транскодер, и они будут участвовать в следующем протоколе. Протокол также использует решение для постоянного хранения, например Swarm, как часть процесса проверки работы.

Предварительная обработка

8. Вещательная компания -> Смарт-контракт Livepeer: вносит депозит в цепочку, чтобы покрыть стоимость полного задания по транскодированию. Его можно пополнить позже в любой момент, но Транскодер может прекратить работу, если депозит закончится, поскольку они постепенно получают деньги за проделанную работу.
9. Работа
10. 2. Вещатель -> Смарт-контракт Livepeer: задание (идентификатор потока, параметры, цена / сегмент)
11.  Создает запрос на работу в цепочке и помещает некоторое количество ETH на условное депонирование для оплаты работы.
12.  Протокол может использовать хэш следующего блока для детерминированного выбора правильного транскодера для этого задания.
13.  Транскодер -> Вещатель: отправлять выходной streamID и квитанцию о том, что задание принято.
14. Broadcaster -> Transcoder: отправлять сегменты потока, содержащие подписи, подтверждающие входные данные.
15. Транскодер выполняет транскодирование и делает новый выходной поток доступным в сети.
16.  Транскодер сохраняет подтверждение о транскодировании для каждого сегмента работы по транскодированию.

Окончание работы

18. Транскодер -> Смарт-контракт Livepeer: вызватьClaimWork (JobID, StartSegmentSeq #, EndSegmentSeq #, MerkleRoot). Транскодер заявляет в цепочке, что они выполнили работу с заявленным диапазоном сегментов, с корнем Меркла всех данных квитанции транскодирования для фиксации содержимого этих закодированных сегментов.

19. Подождать пока эта транзакция будет добыта, и наблюдайте за следующим хешем блоков. Затем протокол может определить, какие сегменты будут проверяться на основе VerificationRate.

20. Транскодер -> Swarm: Записать полезные данные входных данных для сегментов, которые будут оспорены посредством проверки, используя параметры SWEAR, чтобы гарантировать, что данные будут там достаточно долго для проверки (время VerificationPeriod).

21. Транскодер -> Смарт-контракт Livepeer: Предоставить заявки на перекодировку в цепочке для каждого сегмента, который необходимо проверить, вместе с доказательствами Меркла для квитанций для каждого сегмента в заявках на перекодировку. Смарт-контракт может проверять подписи от Broadcaster и Transcoder, чтобы гарантировать доступность всех данных, необходимых для проведения проверки, и может проверять доказательства Меркла на соответствие подтвержденному корню Меркла из ClaimWork ().

22. Транскодер -> Truebit: Verify (). Это onchain-вызов смарт-контракта Truebit, где транскодер предоставляет входной хэш Swarm для запрашиваемого сегмента. (Подробнее о проверке в следующем разделе)

23. Truebit -> Livepeer Smart Contract: Результат работы записывается в цепочку. Это сравнивается с результатом запроса на транскодирование, который предоставил транскодер.

24. Смарт-контракт Livepeer: на этом этапе смарт-контракт Livepeer содержит всю информацию, необходимую для определения, проверена ли работа транскодера. - Если проверка верна, используйте в качестве входных данных для алгоритма распределения токенов и освобождения депонированных сборов. - Если это неверно, то Транскодер и его стейкеры обрезаются FailedVerificationSlashAmount, а вещатель получает возмещение.

25. Вещатель может прекратить отправку сегментов в любой момент, что фактически является EndJob ().

На этом этапе транскодирование выполнено, доказательство работы заявлено в цепочке, и сообщается об отказе или успехе проверки работы. Вся информация находится в цепочке, чтобы определить распределение сборов и токенов транскодерам и делегатам или сокращение в случае неудачной проверки.

Проверка работы

Чтобы распределять плату между транскодировщиками, заявляющими, что они выполнили задание по транскодированию, необходимо, чтобы протокол с высокой вероятностью мог определить, что задание было действительно выполнено правильно. Для этого Livepeer расширяет исследования и использует протокол Truebit.

Truebit работает за счет того, что один участник (решатель) выполняет фактическую работу за определенную плату, в данном случае перекодирование, а затем дополнительные участники (верификаторы) проверяют работу, чтобы обнаружить ошибки, ошибки или мошенничество. Задача разбита на очень маленькие шаги, и верификаторы проверяют работу решателя, чтобы найти первый шаг, который отличается от ожидаемого. Затем смарт-контракт (судья) должен выполнить только этот очень маленький шаг в цепочке, который может сказать, какая сторона выполнила работу правильно. Экономические стимулы, в том числе принудительные ошибки для стимулирования проверки со стороны проверяющих, гарантируют, что мошенничество или опровержение невыгодно, но выгодно играть роль проверки работы.

Обратной стороной этого протокола является то, что он стоит в 5-50 раз дороже исходной работы, чтобы проверить всю работу. Livepeer использует Truebit в качестве черного ящика для проверки сегментов, но ему приходится платить этот очень высокий налог на проверку, проверяя только небольшой процент сегментов случайным образом и используя косую черту в случае неудачных проверок. VerificationRate, установленный в Livepeer, определяет, как часто конкретный сегмент должен выбираться для вызова в Truebit, а случайность будущего хэша блока после того, как работа была зафиксирована в цепочке блоков, определяет, какие именно сегменты выбираются.

Если работа фиксируется посредством вызова ClaimWork () в блоке N, то

Если Sha3 (N, BlockHash (N), Seg #)% VerificationRate == 0, то сегмент # должен быть проверен.

Транскодер предоставляет заявки на перекодировку в цепочке для сегментов-кандидатов, вызывая транзакцию Verify (). Смарт-контракт Livepeer может проверять подлинность этих утверждений, используя внутренние подписи и предоставляемые доказательства Меркла, а затем вызывать вызов Truebit для проверки только этих сегментов.

Решатели и верификаторы Truebit получают доступ к входным данным для сегмента из адресной системы хранения с постоянным содержимым, такой как Swarm. Транскодер отвечает за проверку того, что сегментные данные доступны в Swarm, и может дополнительно искать квитанции из протокола SWEAR [5], гарантируя постоянство в течение определенного периода времени, которого достаточно для того, чтобы Truebit разыгрался. Кроме того, они могут взять на себя запуск узла Swarm, гарантирующего, что данные доступны для проверки Truebit. Если у них есть основания полагать, что данные недоступны в Swarm, они могут предоставить их или просто вызвать ClaimWork () для ранее доступных данных.

Truebit запишет результаты вычислений (успешные или неудачные) обратно в смарт-контракт Livepeer, который затем можно будет использовать в вычислениях вознаграждения и сокращения в протоколе. Узел перекодирования не может заранее предсказать, какие сегменты будут проверяться, и в случае мошенничества или неправильного перекодирования будут ощущаться следующие штрафы:

• FailedVerificationSlashAmount будет сокращен, если они не пройдут проверку Truebit.

• MissedVerificationSlashAmount будет сокращен, если они не предоставят утверждения о перекодировании и не вызовут Truebit для сегментов, которые они должны были сделать.

• Утерян гонорар от вещателя.

• Мало того, что транскодер будет разрезан, но и все его делегаторы также будут разрезаны. Они учтут это при принятии решения о том, кому делегировать полномочия, и Транскодер может потерять свою прибыльную работу.

Важно, чтобы было выгоднее просто поставить LPT на действующий, честно работающий транскодер, чем обманывать и брать на себя строгие штрафы, при этом собирая комиссию и выделение токенов за нечестную работу. Тщательный подбор параметров сокращения и скорости проверки может гарантировать это.