Abstract

This document describes the background and design points around the remote signer implementations of GitHub PR#3791 and PR#3822

Remote signing is a new mode for go-livepeer, alongside the existing modes of the gateway, orchestrator, and redeemer. There are a few goals for remote signers:

Take on most of the gateway’s blockchain-related responsibilities, avoiding any hard Ethereum dependency for gateways. This will facilitate gateway implementations on other platforms such as Python, browser, mobile, etc.
Allow for third-party payment operators (”clearinghouses”) to relieve gateways of crypto custody and account management issues, allowing for separate payment in traditional currencies.
Improve the security posture of existing gateway operators by removing the Ethereum key from the hot path of processing untrusted media.

Background

The Livepeer gateway is currently a monolith: it has deep Ethereum integration to handle payments and the other logistics of operating on an blockchain, and a media processing protocol for AI and transcoding workloads.

Currently, writing an implementation of a Livepeer gateway requires deep familiarity with the Livepeer probabilistic micropayments (PM) mechanism. Very few developers actually understand PM in enough detail to implement correctly, which is one reason that go-livepeer is the only extant gateway implementation.

Beyond implementing PM, operating with PM at scale is also a challenge. One recent example: Ethereum price volatility has caused Daydream service reliability issues due to different nodes having a different view of the ETH-USD price. Debugging these types of issues is painful, and is one reason why there are very few gateway operators on the network.

Remote signing allows for separating the gateway’s Ethereum integration from its media responsibilities. This has two main implications:

Allows for someone other than the media operator to manage payments and crypto logistics, eg a clearinghouse. The media operator could then settle directly with the clearinghouse using a traditional currency, while leaving the underlying PM settlement mechanism intact for orchestrators.
Removing Ethereum requirement from the core media processing greatly simplifies gateway implementation, and makes it more likely we will see new forms of the gateway, eg embedded within end-user apps for better latency and control. Developers can integrate with the Livepeer network directly via native gateway SDKs. The network would not have to funnel all its traffic through a few centralized gateway providers; the success of the Livepeer network would no longer need to be tied to the success of those few providers.

Signing Hot Keys

Currently, the gateway must hold the Ethereum payment signing key in the same process that handles untrusted media coming from users. This is a security risk, as an exploit stemming from malicious input could result in the compromise of the payment signing key and lost gateway funds.

Moreover, the design of PM leads gateway providers to share a common key for all gateway instances, which increases the blast radius of any compromise.

Remote signing, by virtue of separating the Ethereum parts from the media parts, avoids this problem.

Design: Live AI

Remote signing will initially be implemented for Live AI (live-video-to-video) only. There are a few reasons for this:

Live AI is the use case that is seeing the most development and usage right now.
Minimizes risk to other workloads, especially transcoding.