End user data verification

There is possbility that a data is tampered before it flows to Enigma network. In ethereum, a dApp user can verify that his dApp’s frontend inputs are the one being executed in the smart contract, by looking at the blockchain explorer (for example through etherscan) and looking at the transaction’s input data. With this, the user can verify that the application where he inserted his inputs didn’t manipulate his inputs. If the dApp is tampering the data before being executed on the blockchain, anyone can inspect the blockchain explorer and prove it from there.

With Enigma, data inputs flowing to the private contracts are encrypted. Let’s assume that data tampering inside the Enigma network is not possible through remote attestation provided by Intel SGX, so correctness is preserved throughout the computation process. How does someone, as an end-user of a dApp, in practice, verify his inputs is not tampered before going in the Enigma network? Is there a way?

I’m going to answer this based on the next version “discovery” although the same logic largely applies to MVT.

Sending a computation task to the Enigma network requires a taskId. The taskId is a hash of all the frontend inputs of the task: fn signature, args (unencrypted), bytecode, block number and user pub key: generateTaskId(fn, args, codeHash, blockNumber, userPubKey). Before submitting the task to the Enigma network, the dApp user must create a transaction on Ethereum that stores the taskId in a task record: createTaskRecord(taskId, options). The task record is also how dApp users would transfer ERC20 tokens to a payable function of an Engima secret contract.

The dApp user, or anyone else who knows the inputs, may verify them on chain (e.g. through EtherScan) simply by hashing out the taskId. For the worker nodes, generating the taskId from the task inputs in their enclave and verifying on chain is always required before computing a task.

The key differences with MVT are: 1) In MVT, all inputs are encoded in the Ethereum transactions. In Discovery, the Ethereum transaction contains the taskId to verify that inputs haven’t been tempered with. We want to store as little data on Ethereum as possible while keeping the inputs verifiable; 2) In MVT, the taskId hash is generated against the encrypted frontend inputs. In Discovery, we generate the hash from the clear frontend inputs, making the verification much easier.