Transcoder metadata registry

[yondonfu]

There are a few benefits from enabling a transcoder to publish additional metadata about itself on-chain besides its reward cut, fee share and price per segment:

• A transcoder can advertise a human-readable name that delegators can reference instead of an ETH address. Client side tools can be used under the hood to resolve these human-readable names back to their corresponding ETH addresses
• A transcoder can publish a URI that can be used by a broadcaster to establish a connection off-chain. This is a requirement for an orchestrator based HTTP networking protocol.
• A transcoder can publish a public key (either the public key corresponding to its ETH address or another public key corresponding to a private key that it owns) that can be used in various off-chain cryptographic protocols

Creating a human-readable name for a transcoder's ETH address can be accomplished using an ENS subdomain registry (ex. transcoders can use register names under the transcoder.eth domain - @dob has already built a proof of concept for this that allows the Livepeer explorer to display ENS names instead of ETH addresses).

Although the other two points could be accomplished via an upgrade to the BondingManager contract to add additional fields, they can actually instead also be accomplished using additional resource records in ENS. The URI can be set as a text record and the public key could be set as a a public key record in a default public resolver that all names registered under the transcoder.eth domain would point to. Using ENS for metadata lookups instead of including metadata fields in the BondingManager contract helps avoid introducing any additional complexity into an already complex BondingManager contract, avoids a potentially hairy contract upgrade process and offers flexibility in the future to introduce additional metadata for transcoders that might be useful to have access to on-chain.

Two additional contracts would be introduced: TranscoderRegistry and ENSTranscoderRegistrar. The existing global PublicResolver which allows name owners to set the values for various resource records would be used. ENSTranscoderRegistrar would be owned by TranscoderRegistry - this ownership structure might be necessary to allow transcoder to both register a name and point the name to the default PublicResolver in an atomic transaction because in the default PublicResolver only the owner of the name is allowed to set the resolver for a name, so in this case TranscoderRegistry is the actual owner of the newly registered name, but the ETH address resource record will point to the address of the transcoder that is registering a name (this isn't purely necessary, but is more of a UX optimization so users wouldn't have to submit multiple transactions to accomplish the same goal). Setting the URI value for a text record could also happen in the same atomic transaction if a register() function in TranscoderRegistry allows for it.

An additional requirement is the ability to perform reverse lookups using an ETH address to retrieve its associated ENS name. ENS supports reverse resolution using a ReverseRegistrar so users could register a reverse record mapping ETH addresses to ENS names which then can be used to lookup additional resource records (i.e. URI, public key). The upside of using the default reverse resolution functionality is that there is no additional implementation necessary. However, the downside is that users have to submit an additional transaction just to register a reverse record. An alternative would be to add a reverse lookup mapping in the TranscoderRegistry contract so that users can register a name and associated resource records and enable reverse lookups using a ETH address in a single atomic transaction.

Clients will be able to perform lookups with these contracts (free) to resolve transcoder addresses into human-readable names for applications like the Livepeer explorer and to lookup the URI necessary for establishing a connection during a transcode job within the broadcaster-transcoder workflow.

Note: although this issue makes references to transcoders, everything described in this issue is also applicable for orchestrators within an orchestrator based networking protocol where orchestrators and transcoders are distinct entities.

[dob]

Definitely in favor of the transcoder metadata living within a separate registry on chain rather than in the BondingManager itself. And yes, the reverse resolution is going to be more immediately important than the name -> address resolution which wouldn't have any immediate use outside of wallets right now, which is a little peripheral to Livepeer protocol itself.

The decision of conforming to ENS or not comes down to usability for a transcoder. If we can expose a simple interface that allows easy updates from the transcoder account, then it's all good - though if users are required to interact with a separate service + tools in order to interact with the metadata store, then I think we'd be better off just throwing up a simple registry contract that's more Livepeer native.

[j0sh]

Thanks for writing this up! For clarification, would the ENS metadata lookup would be done in two steps? address -> ENS name -> metadata ?

While reading up about ENS, it seems that the current registrar is still provisional and is slated to be replaced by a permanent registrar. The concerning part is the possibility that all users would have to re-register their names after the permanent registrar is put in place. This writeup is from two years ago; I'm not sure if there's more up-to-date information.

Generally I support the idea of putting the metadata outside the BondingManager, but the specter of a large migration with ENS gives me pause. This might not be a concern for smaller parts of the protocol, but this registry would be in the middle of all our broadcaster-transcoder flows. Using ENS now means we could be committing to a significant maintenance obligation down the road.

Just one more small thing that I don't quite understand, probably due to my unfamiliarity with Ethereum contracts: why does there need to be a a split between TranscoderRegistry and ENSTranscoderRegistrar?

[yondonfu]

For clarification, would the ENS metadata lookup would be done in two steps? address -> ENS name -> metadata

If we went that route - yeah.

Generally I support the idea of putting the metadata outside the BondingManager, but the specter of a large migration with ENS gives me pause.

I believe the potential migration would only apply to users that own names under the top-level .eth domain because the rules for owning/purchasing under that top-level domain are currently dictated by the initial registrar. So, the owner of transcoder.eth could potentially be affected. However, I think any users that register names under the transcoder.eth domain would be unaffected because the rules for owning/purchasing names under this subdomain would be dictated by its own registrar and not the initial registrar for the .eth top level domain.

why does there need to be a a split between TranscoderRegistry and ENSTranscoderRegistrar?

This isn't strictly necessary, but was just a proposed idea - by having the TranscoderRegistry contract be the actual owner of names we could atomically register a name and set a public resolver for the registered name from a single function in the TranscoderRegistry contract as opposed to having users register names with the ENSTranscoderRegistry and then submit a separate transaction to set the resolver for the newly registered name (the ENS registry keeping track of name to resolver mappings enforces that only the owner of the name can set the address of the resolver to be used for a name).

With all this being said, after thinking about this for a little, I think it makes more sense to just create a Livepeer specific off-chain lookup (to differentiate between a registry that contains information that might be required by other contracts - the metadata in this registry would be primarily serve an informational purpose for clients) registry contract that does not integrate with ENS for now since our priority at the moment is address to metadata lookups as opposed to the name to metadata lookups that ENS supports (ENS supports reverse lookups as well, but requires additional configuration/transactions by the user).

Meanwhile, this registry would be more focused on Livepeer protocol specific metadata namely a service URI (i.e. for orchestrator networking communication). We can make this registry upgradeable to support future additions and reverse lookup of an ENS name in the future as well.

The interface for the contract would look something like

contract Registry is ManagerProxy {
    struct Record {
        string serviceURI;
    }

    // Setters would only change state for the caller
    function setServiceURI(string _serviceURI) external;
    function getServiceURI(address _addr) public returns (string);
}

and it would be registered with the Controller.

[yondonfu]

Formalized proposal created in #9 Any additional feedback encouraged to take place there!

[yondonfu]

Merged proposal in #9