# Transaction Constraints

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

- [Confidential Transfer](./2_1_confidential_transfer.md)
- [Confidential Smart Contract](./2_2_confidential_smart_contract.md)

## 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.