Transaction Constraints
In this section, we describe the concrete constraints for the transactions.
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.