Transaction Constraints

In this section, we describe the concrete constraints for the transactions.

• Confidential Transfer

Abstract

The transaction constraints consist of smaller pieces of constraints. There are three types of constraints we have as following.

Constraint Type	Checking Condition	Static or Dynamic
Common Transaction	Basic transactions object for example gas, signature and so on	Static
Confidential Transfer	Confidential transfer condition	Static
Confidential Smart Contract	Confidential smart contract condition	Dynamic

The Common Transaction checks the basic transactions constraints and used for every transaction. When the users transfer assets, they need to generate the proof satisfying both Common Transaction and Confidential Transfer constraints. This consists of static constraints so the condition that the proof needs to satisfy are always same so we can modularize easily. However, when the users execute the smart contract, they need to generate the proof satisfying both Common Transaction and Confidential Smart Contract constraints. This consists of static and dynamic constraints so the condition that the proof needs to satisfy are always different.

We would like to describe the constraints more detail and how we generate the proof for dynamic constraints.

Process

Every transaction needs to be attached the proof which satisfies the constraints. The proof is generated by proving key according to plonk protocol. The blockchain needs to setup the parameters and the user needs to generate key pair as following.

Item	Description
x	user private key
y	user public key
srs	setup parameters
s	randomness used for setup
setup()	setup function
F	field
G	elliptic curve group
g	elliptic curve generator
d	polynomial degree
pk	proving key
vk	verification key

Setup

Setup the paramaters used for generate and verify proof.

$$g ∈ G$$ $$setup(d, s) = [g, [s] g, [s^2] g, ... , [s^{d-1}] g] = (pk, vk)$$

Key Pair

Generate the key pair for sign the transaction.

$$x ∈ F$$ $$y = g^x$$

Common Transaction Constraints

Every transaction has common object items and this Common Transaction Constraints checks these condition. The transaction object items are following.

Item	Description
source	transactor
target	destination address
input	transaction data
value	message value
gasLimit	gas limit of transaction
gasPrice	gas price of transaction
nonce	user account nonce

The Common Transaction Constraints checks that the value, gasLimit and gasPrice are valid. We use following function to generate proof and signature.

Function	Description
enc()	ElGamal encryption
sign()	sign transaction with private key
prove()	proof generation

Encrypt Variables

First of all, the number should be encrypted by ElGamal.

$$enc(x, value, gasLimit, gasPrice, nonce) = value_{enc}, gasLimit_{enc}, gasPrice_{enc}, nonce_{enc}$$

Generate Proof and Signature

Generate the proof with proving key and prove that this common params satisfy the statement.

$$π = Prove(pk, statement_{common_constraint}[value_{enc}, gasLimit_{enc}, gasPrice_{enc}, nonce_{enc}])$$

Generate the signature with private key and prevent front-running attack.

$$σ = Sign(x, value_{enc}, gasLimit_{enc}, gasPrice_{enc}, nonce_{enc}, π)$$

Confidential Smart Contract

This Confidential Transfer Constraints checks that the users smart constract execution is valid. The condition that users proof needs to satisfy is different for each contracts so it's provided by Dapp owner as the same with that the Ethererum Dapp owner provides the ABI of smart contract. When the developers finish implementing the smart contract, the smart contract is compiled and output the Wasm binary and constraints metadata. The constraints metadata is the polynomials expressing the smart contract constraints. The users need the metadata, their secret key and srs when they generate the proof.