- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

So an attacker can update the state and not let you move your funds.

its a non custodial exchange.

With roll_up we are limited at 500 tps because of data availability guarentees

we do 7500 per block with roll_up btw

is it 10k per block or per second for starkware?

I think

maybe someoen can double check that

@jbaylina I reduced the number of constraints required for 3, 4 and N bit lookup tables / constant MUX operations. See: https://github.com/Ethsnarks/ethsnarks-il/blob/master/python/snarkil/commands.py#L518 - for a 3bit lookup table it requires 4 constraints, for a 4bit lookup table it requires 10 constraints, 5 bit 22 constraints, 6bit 46, 7bit 96, 8bit 194 etc. - it does that using a recursive construction of 2bit lookup tables with an additional 2 constraints and 2 variables to select which output, and uses a linear combination as the output

I noticed that your MUX3 looks like it requires 11 constraints, and your MUX4 requires 17, and mine is a generalisation for 1 -> N bits where the number of constraints required is about

`(2**N)*0.75`

, there is possibly a way to reduce the number of constraints further - but I don't need lookup tables beyond 2-4 bits which seems to be the sweet spot
an EIP for a precompile to enable Pedersen commitments inside EVM (ewasm/ewasm-precompiles#25) has been posted: ethereum/EIPs#1829

and discussion thread, if anyone wants to give feedback: https://ethereum-magicians.org/t/precompile-for-general-elliptic-curve-linear-combinations/2581

and discussion thread, if anyone wants to give feedback: https://ethereum-magicians.org/t/precompile-for-general-elliptic-curve-linear-combinations/2581

Barry 12k tps is incredible! If you could make the most ideal changes to the ethereum codebase what would they be? The reason I ask that is im a developer for Expanse. idk if you are familiar but Expanse is the original fork of ETH. But that also means im in a unique position to give you the perfect environment for you to test your ideas in a less than sterile environment. So your test and experiments would be more like testing on the actual eth livenet but with out all of the expenses.

Hi guys, we (Loopring) just released our design doc for our DEX protocol 3.0 using zkSNARKs (using ethsnarks, thanks @HarryR !) and we'll open source the code some time next week. Take a look if you have some time, any feedback is welcome: https://medium.com/loopring-protocol/loopring-protocol-3-0-zksnarks-for-scalability-845b35a8b75b

hae you thought about proving times?

Are you going ot use ethsnarks to prove ?

Soo cool btw :)

Thanks a lot barry, that means a lot coming from you. :)

The main focus for now (and still is actually) is just getting everything working decently, we see the proving times more of an engineering issue that will be largely solved one way or the other in the near future (e.g. GPUs). This is certainly something we'll look into when we get there and nobody else has done it yet! The parallelization in libsnark seems to be not that great and having looked at the proving code doesn't even seem to be that well optimized in general, so we'll definitely look into different ways to generate the proofs. In any case, we'll support different block sizes so operators don't always have to generate proofs for 10Ms of constraints, as proving times get better we can add support for larger blocks so we can achieve maximum throughput.

The main focus for now (and still is actually) is just getting everything working decently, we see the proving times more of an engineering issue that will be largely solved one way or the other in the near future (e.g. GPUs). This is certainly something we'll look into when we get there and nobody else has done it yet! The parallelization in libsnark seems to be not that great and having looked at the proving code doesn't even seem to be that well optimized in general, so we'll definitely look into different ways to generate the proofs. In any case, we'll support different block sizes so operators don't always have to generate proofs for 10Ms of constraints, as proving times get better we can add support for larger blocks so we can achieve maximum throughput.

Loopring protocol 3.0 source: https://github.com/Loopring/protocols/tree/master/packages/loopring_v3

The circuit code was moved out of this repo ~2 weeks ago, further development will be done in a closed repo for now. If you're interested in the circuit code just check the history, it's pretty much still the same code as then, but improvements are still needed for it to be secure.

I will have a better review later on, I am equally as interested in seeing how people are using this stuff, and it's giving me renewed interest in fixing some things with Ethsnarks - hopefully will feed this back into tickets so I have some bits to do which will make biggest impact (while... not breaking things)

I can't add him :/

@kobigurk

this is an implementation of baby_jubjub in zokrates (by @GuthL ): https://github.com/GuthL/zkp_baby_jubjub_protocols

there now is baby_jubjub in the stdlib of ZoKrates as well:

https://github.com/Zokrates/ZoKrates/tree/master/zokrates_stdlib/stdlib/ecc

Hi everyone, I just began looking at roll_up as an interesting source of ideas for scaling and privacy. I can see how this adds to scalability, but does it do anything for privacy? I don't see how it can be used to hide, say, balances and account addresses in a transfer-of-value transaction. Thanks.