Saltar al contenido principal
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg

Objetivos del Mecanismo

Los mecanismos centrales de Livepeer están diseñados para:
  • Incentivar el comportamiento honesto entre los participantes (Orquestadores, Delegadores, Puertos de Entrada/Transmisores)
  • Escalar la capacidad de suministro al recompensar a los proveedores de infraestructura proporcionalmente
  • Asegurar la verificación de cargas de trabajo de video y IA fuera de cadena mediante una participación bloqueada
  • Desincentivar a los actores deshonestos mediante penalizaciones (slashing)

Características del Protocolo

Las características principales del Protocolo Livepeer incluyen:

Blockchain Base

All protocol state (bonds, delegations, votes, job payments, etc.) lives on Arbitrum. The LPT token is ERC-20-based and bridged between L1 and L2.The Arbitrum rollup finalizes via Ethereum; thus the underlying security is Ethereum’s.After Confluence (LIP-73), Ethereum mainnet now mainly serves as a historical source – new stake/votes are on Arbitrum only.

Consensus & Finality

Livepeer does not use its own consensus; it relies on Arbitrum’s optimistic rollup. Blocks (called rounds) occur roughly every 24 hrs, and after a ~7-day challenge window the state is finalized on Ethereum.This means trust assumptions are similar to other Ethereum Layer-2s: Arbitrum’s rollup validators and Ethereum miners secure the chain; fraud proofs protect against invalid blocks.

Security Model

Livepeer’s core contracts are on an Ethereum Layer-2 (Arbitrum One), which inherits Ethereum-level security via optimistic rollup.LPT stakers (orchestrators and delegators) provide economic collateral against misbehavior. Protocol rules penalize malfeasance by slashing stake (e.g. losing part or all delegated tokens).Off-chain video verification and optional arbitration ensure correct transcoding.

Node-Level Trust

Gateways/Broadcasters (clients) and orchestrators exchange signed data (video segments, “tickets,” job outcomes).These off-chain interactions can be audited (via perceptual hashes or full verification), so a bad actor’s forged data can be proven on-chain by a dispute mechanism.Orchestrators commit to jobs by staking, and any detected mis-transcoding can trigger an on-chain slashing penalty.

Actores del Protocolo

El Protocolo Livepeer define varios actores clave que participan en la red y realizan funciones específicas.
OrchestratorsOrchestrators are the main participants in the Livepeer Protocol. They are responsible for processing video and AI jobs, earning fees and rewards, and maintaining the network’s security and decentralization.
GatewaysGateways are the entry point for applications into the Livepeer network. They are the coordination layer that connects real-time AI and video workloads to the orchestrators who perform the GPU compute.
DelegatorsDelegators are LPT holders who delegate their tokens to an orchestrator of their choice. They share in the rewards and fees earned by the orchestrator, and also share in any slashing penalties.

Mecanismos del Protocolo

Livepeer se basa en Gateways (anteriormente Broadcasters), Orchestrators y Delegators para procesar cargas de cómputo en la red. El Protocolo Livepeer define varias reglas operativas clave para la red y sus actores. AI vs Video Mechanisms Los servicios de IA no participan en la misma distribución de recompensas ni en la elección de conjunto activo basada en rondas que los Orchestrators de video.
The video transcoding system and AI system are architecturally separate and operate independently.
Esta separación permite que los servicios de IA operen sin requerir staking de LPT, haciéndolos más accesibles mientras se preserva el modelo de seguridad del transcodificado de video mediante vinculación económica. Incentive Structure Comparison
ComponentVideo OrchestratorsAI Services

Detalles del Mecanismo

Tenga en cuenta que el Staking, las Recompensas y los Pagos operan de manera diferente para los pipelines de IA.

Rounds and Timing

The Livepeer protocol uses a round-based system, where each round represents a fixed-length epoch in blocks, to coordinate reward distribution and staking activities.Mechanism
  1. Rounds have a fixed length in blocks (configured in RoundsManager)
  2. New rounds must be initialized by calling initializeRound()
  3. Various protocol operations are only valid during specific times in a round
  4. Parameter updates are restricted during “locked” periods of a round
  5. Rewards can only be claimed once per round by a transcoder
FunctionsThe round system coordinates the protocol operations for:
  • Staking/Unbonding: Changes take effect in the next round
  • Reward Distribution: Calculated per round based on active stake
  • Parameter Updates: Restricted during lock periods
  • Earnings Claiming: Can only claim for rounds that have been initialised
Implementation MechanicsThis mechanism is implemented in the RoundsManager contract, which manages round lifecycle, including length configuration, initialisation tracking and locking periods that gate protocol operations.
  • roundLength state variable stores the number of blocks per round.
  • default configuration is 5760 blocks for mainnet deployments (~24 hours at 15-second block times)
  • development environment default is 50 blocks for faster testing
  • updated via setRoundLength() (governed by Controller owner)
  • roundLength state variable stores the number of blocks per round.
  • default configuration is 5760 blocks for mainnet deployments and 50 blocks for development environments
  • updated via setRoundLength() (governed by Controller owner)
Round Initialisation
function: initializeRound()
  • public function that can be called externally by any EOA to mark the start of a new round. Typically triggered by Orchestrators
  • advances the protocol epoch by updating current round number and round initialisation status
  • performs critical setup: stores block hash, sets active stake, snapshots stake for reward calculations and unlocks mintable rewards.
  • can only be called once per round and reverts if system is paused or round is not complete
Last modified on March 1, 2026