Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    barryWhiteHat
    @barryWhiteHat
    I am still waiting to see more details on this. Do they have code?
    David Phan
    @davidp94
    I don't think they will disclose it -- even in alpha - Let's wait and see
    barryWhiteHat
    @barryWhiteHat
    Its important to note that they do not provide data availability guarentees here
    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?
    David Phan
    @davidp94
    10k per block (assuming 8M gas per block on ethereum)
    barryWhiteHat
    @barryWhiteHat
    I am pretty sure we can beat that with roll_up and an efficient hash function let me do the math
    barryWhiteHat
    @barryWhiteHat
    Yeah so we can do way more than that. Because we only use 500k gas per proof and they use it all.
    We can do 16 proofs per block. So 7500 * 16 = 120000 transactions per block.
    I think
    maybe someoen can double check that
    HaRold
    @HarryR
    @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
    HaRold
    @HarryR
    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
    Jordi Baylina
    @jbaylina
    If the inputs are constants this is reduced...
    HaRold
    @HarryR
    so with constant inputs, your MUX3 is 4 constraints, and your MUX4 is?
    cdetrio
    @cdetrio
    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
    HaRold
    @HarryR
    Christopher Franko
    @FrankoCurrency_twitter
    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.
    Brecht Devos
    @Brechtpd
    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
    barryWhiteHat
    @barryWhiteHat
    Nice
    hae you thought about proving times?
    Are you going ot use ethsnarks to prove ?
    Soo cool btw :)
    Brecht Devos
    @Brechtpd
    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.
    Alex Gluchowski
    @gluk64
    Great work, Brecht!
    HaRold
    @HarryR
    @Brechtpd awesome! I've been following Loopring for a while
    Brecht Devos
    @Brechtpd
    Ah, that's great to hear! Loopring isn't the most well known project, with 0x being the much more well known project doing similar tech as us. Hopefully this gets better in the future. :)
    barryWhiteHat
    @barryWhiteHat
    @Brechtpd do you have code for this published ?
    Brecht Devos
    @Brechtpd
    @barryWhiteHat Not yet, the code will be made public this weekend. Will post a link when we do.
    Brecht Devos
    @Brechtpd
    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.
    zillerium
    @zillerium
    hi
    HarryR @HarryR is poking through the source code - it is interesting nontheless to see how much you accomplished and I am happy :D
    Brecht Devos
    @Brechtpd
    @HarryR Thanks for looking at the code! If you find something strange/dumb/dangerous or have any other thoughts please let me know! You're far more knowledgeable about some of this stuff than me.
    HaRold
    @HarryR
    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)
    Brecht Devos
    @Brechtpd
    Awesome, that's great to hear!
    barryWhiteHat
    @barryWhiteHat
    Can we add @weijiekoh who is planning to do a trusted setup for a mixer.
    I can't add him :/
    Koh Wei Jie
    @weijiekoh
    Hi! Can anyone add me to the trusted setup group please?
    Felix Leupold
    @fleupold
    Done
    Stefan
    @stefandeml

    @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

    Kobi Gurkan
    @kobigurk
    Nice!
    HaRold
    @HarryR
    how are you doing with # of constraints etc?
    alexpArtos
    @alexpArtos
    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.
    barryWhiteHat
    @barryWhiteHat

    It does not add anything to privacy @alexpArtos

    Their are plans to add something more here. But that requires recursive snarks and putting more data on chain.

    alexpArtos
    @alexpArtos
    Thanks for confirming, Barry.
    barryWhiteHat
    @barryWhiteHat
    No probs. What are you working on/ planning to work on ?
    alexpArtos
    @alexpArtos
    probably something similar to Zether. Privacy of transactions in the account/balance model, but also in a scalable way. Most of the solutions I see are in the UTXO model.