Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix typos, syntax and unnecessary space #46

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix typos, syntax and unnecessary space #46

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 40 additions & 40 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,86 +1,86 @@
# roll_up
# roll_up

[![Join the chat at https://gitter.im/barrywhitehat/roll_up](https://badges.gitter.im/barrywhitehat/roll_up.png)](https://gitter.im/barrywhitehat/roll_up?utm_source=share-link&utm_medium=link&utm_campaign=share-link)

Roll_up aggregates transactions so that they only require a single onchain transactions required to validate multiple other transactions. The snark checks the signature and applies the transaction to the the leaf that the signer owns.
Roll_up aggregates transactions so that they only require a single onchain transactions required to validate multiple other transactions. The snark checks the signature and applies the transaction to the leaf that the signer owns.

Multiple users create signatures. Provers aggregates these signatures into a snark and use it to update a smart contract on the ethereum blockchain. A malicious prover who does not also have that leafs private key cannot change a leaf. Only the person who controls the private key can.
Multiple users create signatures. Provers aggregate these signatures into a snark and use it to update a smart contract on the ethereum blockchain. A malicious prover who does not also have that leafs private key cannot change a leaf. Only the person who controls the private key can.

This is intended to be the database layer of snark-dapp (snapps) where the layers above define more rules about changing and updating the leaves

`roll_up` does not make any rules about what happens in a leaf, what kind of leaves can be created and destroyed. This is the purview of
`roll_up` does not make any rules about what happens in a leaf, what kind of leaves can be created and destroyed. This is the purview of
higher level snapps. Who can add their constraints in `src/roll_up.tcc` in the function `generate_r1cs_constraints()`

## In Depth

The system is base use eddsa signatures defined in [baby_jubjub_ecc](https://github.com/barryWhiteHat/baby_jubjub_ecc) base upon [baby_jubjub](https://github.com/barryWhiteHat/baby_jubjub). It uses sha256 padded with 512 bits input.
The system is base use eddsa signatures defined in [baby_jubjub_ecc](https://github.com/barryWhiteHat/baby_jubjub_ecc) base upon [baby_jubjub](https://github.com/barryWhiteHat/baby_jubjub). It uses sha256 padded with 512 bits input.

The leaf is defined as follows
The leaf is defined as follows.
```

LEAF
+----------------^----------------+
LHS RHS
+----------------+
Public_key_x public_key_y
+----------------+
Public_key_x public_key_y
```

The leaf is then injected into a merkle tree.
The leaf is then injected into a merkle tree.

A transaction updates a single leaf in the merkle tree. A transaction takes the following form.
A transaction updates a single leaf in the merkle tree. A transaction takes the following form.

```
1. Public key x and y point
2. The message which is defined as the hash of the old leaf and the new leaf.
2. The message which is defined as the hash of the old leaf and the new leaf.

MESSAGE
+----------------^----------------+
OLD_LEAF NEW_LEAF

3. the point R and the integer S.
3. the point R and the integer S.
```


In order to update the merkle tree the prover needs to aggregate together X transactions. For each transaction they check
In order to update the merkle tree the prover needs to aggregate together X transactions. For each transaction they check.
```
1. Takes the merkel root as input from the smart contract (if it is the first iteration) or from the merkle root from the previous
transaction.
2. Find the leaf that matches the message in the merkle tree.
NOTE: If there are two messages that match, both can be updated as their is no replay protection this should be solved on the next layer
this is simply the read and write layer, we do not check what is being written here.
3. Check that the proving key matches the owner of that leaf.
1. Take the merkle root as input from the smart contract (if it is the first iteration) or from the merkle root from the previous
transaction.
2. Find the leaf that matches the message in the merkle tree.
NOTE: If there are two messages that match, both can be updated as there is no replay protection this should be solved on the next layer
this is simply the read and write layer, we do not check what is being written here.
3. Check that the proving key matches the owner of that leaf.
4. Confirm that the signature is correct.
5. Confirm that that leaf is in the merkle tree.
6. Replace is with the new leaf and calculate the new merkle root.
7. Continue until all transactions have been included in a snark
5. Confirm that the leaf is in the merkle tree.
6. Replace it with the new leaf and calculate the new merkle root.
7. Continue until all transactions have been included in a snark.
```
The snark can then be included in a transaction to update the merkle root tracked by a smart contract.
The snark can then be included in a transaction to update the merkle root tracked by a smart contract.


## Data availabilty guarrentees
## Data availabilty guarantees

It is important that each prover is able to make merkle proofs for all leaves.
If they cannot these leaves are essentially locked until that information becomes available.

In order to ensure this, we pass every updated leaf to the smart contract so
that data will always be available.
that data will always be available.

Thus the system has the same data availability guarrentees as ethereum.
Thus the system has the same data availability guarantees as ethereum.

## Scalability

Gas cost of function call: 23368
Gas cost of throwing an event with a single leaf update : 1840

Although we don't use groth16 currently. This is the cheapest proving system to our knowledge.
Although we don't use groth16 currently. This is the cheapest proving system to our knowledge.

groth16 confirm: 560000 including tx cost and input data is ~600000.

The gas limit is 8,000,000 per block. So we can use the rest of the gas to maintain data availability.
The gas limit is 8,000,000 per block. So we can use the rest of the gas to maintain data availability.

8000000 - 600000 = 7400000

We find that 7400000 is the remaining gas in the block.
We find that 7400000 is the remaining gas in the block.

So we calculate how much we can spend on data availability

Expand All @@ -92,33 +92,33 @@ So we calculate how much we can spend on data availability
## Proving time

On a laptop with 7 GB of ram and 20 GB of swap space it struggles to aggragate 20 transactions per second. This is a
combination of my hardware limits and cpp code that needs to be improved.
combination of my hardware limits and cpp code that needs to be improved.

[Wu et al](https://eprint.iacr.org/2018/691) showed that is is possible to distribute
these computations that scales to billions of constaints.
these computations that scales to billions of constaints.

In order to reach the tps described above three approaches exist.
In order to reach the tps described above three approaches exist.

1. Improve the cpp code similar to https://github.com/HarryR/ethsnarks/issues/3 and run it on enterprise hardware.
1. Improving the cpp code similar to https://github.com/HarryR/ethsnarks/issues/3 and run it on enterprise hardware.
2. Implmenting the full distributed system described by Wu et al.
3. Specialized hardware to create these proofs.
3. Specialized hardware to create these proofs.


## Distribution

The role of prover can be distributed but it means that each will have to purchase/rent hardware in order to be able to keep up with the longest chain.
The role of prover can be distributed but it means that each will have to purchase/rent hardware in order to be able to keep up with the longest chain.

There are a few attacks where the fastest prover is able censor all other provers by constantly updating so the all competing provers proofs are constantly out of date.
There are a few attacks where the fastest prover is able censor all other provers by constantly updating so the all competing provers proofs are constantly out of date.

These problem should be mitigated or solved at the consensus level.
These problem should be mitigated or solved at the consensus level.


## Running tests
## Running tests

If you want to run at noTx greater than 10 you will need more than 7GB
to add a bunch of swap space https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

### Build everything
### Build everything

```
mkdir keys
Expand All @@ -130,7 +130,7 @@ cmake .. && make

### Run the tests

NOTE: Make sure you have a node running so the smart contract would be deployed and validate the transaction, you can use
NOTE: Make sure you have a node running so the smart contract would be deployed and validate the transaction, you can use
`testrpc` or `ganache-cli`

```
Expand Down