Transcoder service registry

[yondonfu]

Creates a smart contract registry for transcoders to publish service URI endpoints. Formalized proposal based on discussion in #6

[yondonfu]

Yeah if a hash of a TLS cert or a public key become requirements later on the contract might change to look something like this:

// This is the format that ENS uses to store secp256k1 public keys
// https://github.com/ethereum/EIPs/pull/619
struct PubKey {
    bytes32 x;
    bytes32 y;
}

// We can add additional fields in this struct in a future upgrade - we just cannot remove or serviceURI
struct Record {
    string serviceURI;
    PubKey tlsPubKey;
    bytes32 tlsCertHash;
}

mapping (address => Record) private records;

...

// Existing serviceURI functions omitted

// Batch setter for metadata fields
function setRecord(string _serviceURI, PubKey _tlsPubKey, bytes32 _tlsCertHash) external;
// New setter for TLS public key
function setTLSPubKey(PubKey _tlsPubKey) external;
// New setter for TLS cert hash
function setTLSCertHash(bytes32 _tlsCertHash) external;
// New batch getter
function getRecord(address _addr) public view returns (Record);
// New getter for TLS public key
function getTLSPubKey(address _addr) public view returns (PubKey);
// New getter for TLS cert hash
function getTLSCertHash(address _addr) public view returns (bytes32);

We could expose the batch setter to allow a transcoder to set all these fields with a single transaction while keeping individual setters so it can submit additional transactions to update individual fields if it needs to in the future.

[yondonfu]

Technical comments seem to have all been addressed so merging as draft (note: this will still be evaluated for inclusion at a future core dev meeting before it is actually deployed in a protocol upgrade)

[dob]

I know this is already merged. My one question is whether it's necessary to perform any on chain validation of the serviceURI value before setting it? If not then I guess we just need to suggest that the clients do their own validation so that they don't just blindly use whatever random bytes are stored as a serviceURI.

On the side of not doing any validation, I agree it's nice to keep this contract simple and cheap to use, in case orchestrators need to update their URI frequently.

[yondonfu]

I think client side validation of the service URI is preferable to on-chain validation since clients can fairly easily determine for themselves if a service URI is acceptable which avoids some additional costs of on-chain string comparison.

Re: this PR being merged - generally, I think continuing the conversation on these even after they've been merged as drafts is 👍 and if any changes need to be made later on a PR proposing the change can be created.