Planning - Truebit/Livepeer Prototype

[dob]

I wanted to kick off this thread so we can plan what we'd like to accomplish with the Truebit team on the Livepeer/Truebit prototype work on February 21st and 22nd. (Related to #1)

Goal: Get a working prototype of verification of transcoding work using a TruebitVerifier working.

Challenges

1. Setting up the Truebit environment.
2. Getting the systems integrated.
3. Isolating our "Job" code, which is essentially a binary that performs transcoding on video.
4. Compiling this code for execution on the Truebit VM (WASM), or creating a custom verification game implementation. We need more info here.

I think that for 3+4 to be accurate and production ready is far beyond the scope of the 2-3 days that we spend together.

My initial instinct would be to consider the prototype successful if we can do verification of work on some reduced Job binary, which has something to do with the underlying libraries that we use for transcoding. So for example, we write a simple C program that links with the underlying library that does some sort of much more trivial transcode job, like just rescaling the video from the input profile to one single target profile.

If we can compile this for the Truebit VM and run a version of our protocol that accepts this option as the only transcode profile, and then verifies it correctly, that would be a HUGE win, and good starting point for the collaboration going forward.

Open to other ideas and thoughts as to what we need to do to plan for this. @j0sh what do you think about this goal, and potentially preparing a much more simple "program" for us to use as the sample transcoding job as we try the first integration?

[j0sh]

Our transcoder and segmenter already have single entry points in C, so wrapping those up for use by the Truebit VM would hopefully be as straightforward as it gets, and likely the same amount of work for a 'simpler' program with ffmpeg and friends.

Without knowing too much about Truebit, the present challenge seems to be in getting ffmpeg built for wasm and other external considerations such as I/O. There are some other folks that have attempted the feat, which we can look to: https://github.com/bgrins/videoconverter.js/issues/43

[yondonfu]

After some discussion with the Truebit, we ended up with the following goals for an initial proof of concept:

• Compile a WASM binary for a program with similar functionality to the ffprobe -i <file> command that outputs the video/audio metadata for a given input video segment. The metadata would include fields such as bitrate, framerate, resolution,etc. The binary would then return a video profile identifier that matches the computed metadata
• Wrap the above WASM binary with https://github.com/TrueBitFoundation/emscripten-module-wrapper so that information about calls and memory changes can be recorded and used for verified computations.
• Create a repo that isolates the verification portion of the Livepeer protocol. This would include a slimmed down version of the JobsManager contract that will serve as the entry point for a user acting as a transcoder to kick off an external call to provide a computation task to a Truebit contract.
• The repo would use a hardcoded video profile identifier and would contain 2 video segment files: 1) a video segment file that matches the hardcoded video profile and 2) a video segment file that does not match the hardcoded video profile. 1) will be used in the scenario where a user passes verification and 2) will be used in the scenario where a user fails verification
• Be able to pull the input data required by the WASM binary from IPFS to be used during off-chain computation

The workflow of the proof of concept would look something like the following for video segment 1:

1. Upload the WASM binary to IPFS and set the associated IPFS hash as the globally defined variable codeHash in the JobsManager contract
2. User uploads video segment 1 to IPFS and gets the IPFS hash
3. User calls verify() in the JobsManager contract with the IPFS hash for video segment 1 and also sends a payment to fund the Truebit task
4. JobsManager contract calls the Truebit contract with codeHash, the IPFS hash for video segment 1 and the hardcoded video profile. Step 3 and this step constitutes a user acting as a task giver in the Truebit system
5. A Truebit solver pulls down the WASM binary using codeHash, runs it using https://github.com/TrueBitFoundation/ocaml-offchain and the data pulled from IPFS using the IPFS hash for video segment 1
6. If a Truebit verifier also runs the WASM binary using the off-chain interpreter and challenges the solver, a verification game is played
7. Whether verification game is played or not, eventually Truebit calls back into the JobsManager contract using the receiveVerification() function with the video profile identifier output generated from the WASM binary
8. The JobsManager contract compares the received video profile identifier with the hardcoded video profile identifier in the contract

When the proof of concept is completed, it will ideally follow the above flow, but as a first step in that direction we can set up the contract scaffold in a repo so that the Truebit team can understand what our contract interface looks like and how we can include the Truebit contracts into that repo. Separately, we can create a wrapped WASM binary that can accept data input when run through the off-chain interpreter.

[sinahab]

Here's a diagram showing the high-level flow.

[hswick]

We have a new dispute resolution layer interface that can help decouple some of these pieces. Specifically the receiveVerification callback in Step 7 isn't great. It is more of a relic from scrypt-interactive.

interface IDisputeResolutionLayer {
    function status(bytes32 id) public view returns (uint); //returns State enum
    function commitChallenge(address solver, address verifier, bytes32 spec) public returns (bytes32 gameId);
}

It seems the Livepeer contract is acting as what we would call the IncentiveLayer, but I guess in future versions this would have its own box at some point. Essentially, the IncentiveLayer can expect to interact with a dispute resolution layer that implements the above interface. Ideally, even this detail will be abstracted away by Truebit, and the Livepeer contract can simply interact with it.

Instead of the callback, the dispute resolution layer provides a status code for the verification game which is denoted by an Enum

enum State { Uninitialized, Challenged, Unresolved, SolverWon, ChallengerWon }

Then your "Incentive Layer" acts upon (slash or don't slash) based on the status code.

commitChallenge is fairly straightforward it states who is playing the verification game, and a hash of the parameters of the verification game, and then it returns a gameId (commitChallenge is called in Solidity).

This way a Livepeer transcoder is simply running a process to track all of the tasks it has started, and deal with them in a concurrent fashion.

[yondonfu]

@hswick Thanks for the update! I like this new interface.

In the case where the Livepeer contracts are used as a custom incentive layer, the transcoder could play the role Solver and if the verification game resolves to SolverWon at the dispute resolution layer nothing would happen within the Livepeer protocol, but if the verification game resolves to ChallengerWon at the dispute resolution layer, another actor (likely the challenging verifier that won the game) would trigger the slashing function in the Livepeer contracts that would check the status of the game and the transcoder would be slashed within the Livepeer protocol.

[hswick]

@yondonfu that is a good understanding of how the interface works. I'm not sure if not slashing the challenger is a good idea though. There would be no consequences to people spamming verification games. The typical Truebit incentive layer does slash the verifier if they lost the game.

Edit: Didn't realize Livepeer had its own slashing as part of its own protocol. So it looks like you all wouldn't be using the IDisputeResolutionLayer interface, but rather a IIncentiveLayer interface that we need to work on.