Announcing breakthrough advancements in using zkSNARKs for Proof of Video Transcoding

Jun 4 · 7 min read

Ram Penke, Devadutta Ghat, and Taras Shchybovyk

A few months back, we shared our initial research into performing on-chain video transcode verification using zkSNARKs. Today, we are super excited to announce and demonstrate breakthrough advancements in our quest to perform on-chain proof of transcoding verification.

We have successfully implemented an on-chain proof of transcoding that uses a smart contract to verify proof of transcoding. This is achieved by using a verifiable outsourced computation circuit which constructs mechanisms for proving correct execution of proof of transcoding and generates zero knowledge succinct proofs.

In this initial implementation, we’ve accomplished verifiable outsourced SSIM computation using ffmpeg and TinyRAM and the corresponding smart contracts that use the precompiled contracts from EIP196 and EIP197.

There’s a lot to unpack here, so lets go over step by step. Here is a quick refresher on the path we took to get here.

Proof of Transcoding (PoT) using bitstream analysis — as described in the VideoCoin Whitepaper

Our first implementation of PoT was based on analyzing a part of the video bitstream and performing a bit precise matching of the GoP.

This had a major drawback — encoders had to be homogenous. This meant that only one type of encoder could ever be used on the network and any small drift in encoder versions would cause a lot of problems on the network with false positives on PoT failures.

2. Perceptual Hash-based Proof of Transcoding

In our second iteration which we demonstrated during our Testnet Launch, we showed how PoT can be performed with perceptual hash functions. You can read all about it here, including detailed performance benchmarks.

The problem here was that the verifier node needed access to the source stream, which while not unreasonable, meant that the verifier node had to establish a connection with the source

3. Zero Knowledge Transcode Verification with zkSNARKS

In February, we published our first attempts to remove the need for having a verifier node and perform all transcode verification on-chain. In this initial implementation, we were using pHash from the stream.

You can read all about our first publications here

zkSNARKs for VideoCoin Proof-of-Transcode

zkSNARKs(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a very powerful tool for verification of outsourced computation. The the correctness of computations can be verified without having to re-execute it.

Core support for zkSNARKS in Ethereum is enabled through precompiled contracts EIP196 and EIP197 that provide elliptic curve operations for addition, scaling and pairing check. Refer[4],[5] for details of the Ethereum precompiled contracts.

VideoCoin uses zkSNARKs for proof-of-transcode by using a video quality metric called SSIM(Structural Similarity Index). zkSNARKs facilitates to move compute intensive proof calculations off-chain and light-weight on-chain verification in a smart-contract. Refer [7] for detailed description of zkSNARks and for a lighter reading refer to the blog post [12]

zkSNARKs uses Elliptic curve pairing for homomorphic hiding / encoding / encryption. In addition to elliptic curve pairing, a stage in the zk-SNARKS involves translation of computations into polynomials called a Quadratic Arithmetic Program (QAP). Computations are first converted to an Arithmetic circuit. An arithmetic circuit consists of gates computing arithmetic operations like addition and multiplication, with wires connecting the gates.

The following diagram shows an overview of video-coin proof-of-transcode using zkSNARKS. We use SSIM generated by the proof system from a macroblock at random offsets in the committed transcoded stream.

The proof-of-transcode includes the following modules:

Library for Setting up Transcode proof system

Computation (algorithm) that performs the following

Extracts MBs at random offsets
Decode MBs
Calculate SSIM
Compare with reference SSIM

Key Generation

Generation of Proving Key
Generation of Verification Key
Solidity Contract template

2. Library for proof generation:

Extraction of witness (public and private inputs) which consists macroblocks from source and transcoded streams.
Proof generation using the witness and proving-key

3. A smart contract that performs the following:

Maintains escrow records for video segment transcode requests. Each escrow record contains the precomputed challenge supplied by the client library along with mining reward amount,\
Smart-contract also contains the zkSNARKS verification keys and algorithm embedded (which uses Ethereum precompiled contracts)\
The call from the miner(prover) assembles the input&witness from the supplied arguments and retrieving the encrypted values from the escrow records corresponding to the segment. If the verification is successful, it transfers the reward to miner’s account.

Performance and scalability of proof-of-transcode

The zero-knowledge feature of zkSNARKS property allows the prover to hide details about the computation from the verifier in the process, and so they are useful for both privacy and performance. This enables a embedding verifier in a smart-contract and offload most of the computation to prover. As the smart-contract runs on all the blockchain nodes and prover runs only on one client, this helps achieve scalability.

Implementation Overview

Our implementation uses libsnark and front-end libraries

An ffmpeg based custom tool retrieves the macroblocks from the streams and feeds it to the proof generation system.

The following diagram (excerpted from [26]) shown below gives a an overview of libsnark stack:

Key generation, proof generation and verification

zkSnarks includes three steps:

A one-time setup phase where required Computation is transformed to zkSNARKs prover key and verification key through several internal steps that include Algebraic circuit generation, R1CS and QAP. It also includes generation of random values that are used in generation of the keys and discarded (anyone accessing these random values, if not properly discarded, can create attacks).
Proof generation that uses proving key generated in the previous phase, public input and private secret that prover knows as part of performing computation. This proof is sent to the verifier.
Verification processes uses verification key, proof and public input and performs verification based Elliptic Curve homo-morphing.

TinyRAM

TinyRAM [23] is used to support general computations written in high level languages. So, we can apply macro-block decoding as tinyRAM program to get computational proofs. To achieve this we have to go though few steps:

Macro-block decoding algorithm should be converted into tinyRAM assembly code.
Assembly code should be generated into small circuits that checks correct execution.
After feeds those circuits into zkSNARK to generate the proofs.

Performance

We used the core implementation of SSIM from x264 and adapted for Pepper compiler [24]

Verification time for all cases ~5 ms.

Demo

Key-pair generation — one-time action
Normal behavior — transcoder acts as a normal node -
Low-quality attack — transcoder decodes video with lower quality rates than was requested
Wrong stream attack — transcoder uses different video for proof generation
No transcode attack — transcoder pretends original video as transcoded