Benchmark

[AntoineRondelet]

Could someone add Chris as a reviewer please ? It looks like I can't find him... cc: @shapeshed

[HarryR]

This lines up with the numbers I got. Essentially the only real cost is the scalarmult operation which dominates the gas cost. It costs about 180k gas per ring link verification (4x scalarmult, plus other stuff). This scales linearly with the ring size.

Re verifying if a key exists, using a mapping instead of an array would be a better option, it should be a 1:1 lookup rather than a scan which scales linearly with the ring size, however it is difficult to cleanup afterwards (e.g. deleting storage) so it would be leaky.

See extra notes below.

Reflexions

+- There is a balance to find between ring denomination and ring size:

• • Privacy issue and side channel leaks for big denominations (bank transfer) --> If a bank wants to do a transfer of 100 million dollars through Mobius, then it might be possible for someone analyzing the blockchain to actually infer that this transfer has been done by some banks or "big fishs" that has done such a transfer, so banks might want to split big transfers into a huge set of small ones

Yup, this is why confidential transactions are necessary, see RingCT implementations. Denomination splitting isn't a particularly good way of doing it, and as you also pointed out it becomes a security nightmare to not leak info about total.value.

Need to have big rings --> Big rings are good for privacy but also harder to fill

• • Too large ring sizes can be hard to fill and Bob might need to wait for days for the ring to be complete (time problem)

Having to wait for rings to fill isn't a good way of doing it IMO, it introduces even more problems when dealing with timeouts, locked funds etc. The alternative model in my head is basically to just replicate the RingCT functionality, where each 'coin' is spent by providing a ring signature of it and some other coins (and doesn't require any 'filling' stage)

I can take some time to explain the specifics during the week.

[AntoineRondelet]

I see what you mean @Shirikatsu. However, Mobius is at the prototype stage, and is not ready at all for production use. This is explicitly stated in the first lines of the README. I'm not against letting the benchmark in its own branch, but I don't see the point to keep multiple branches where we know that none of them will serve in production. The goal here is to make Mobius easy to play with.

[shapeshed]

I get the aspiration to separate concerns here @Shirikatsu but actually the benchmarking is important since to be useful Mobius must implement the protocol and then optimise gas costs and transaction throughput. IMHO because of the use case the benchmarks are an important aspect of the project.

[Shirikatsu]

@AntoineRondelet I guess what I mean by 'production-ready' is for a more robust and flexibly testable benchmarking tool to be on master. I think you're right that it's probably ready given that we only want to be testing ring size of 4 for now. I've made a few fixes that should be reviewed.

[AntoineRondelet]

@Shirikatsu I see what you mean and I like having flexible software too. The problem here is that the RING_SIZE is hardcoded in the LinkableRing.sol (once again because the Mobius contracts are in the prototype stage). We could try and make it more flexible by adding a setter for the RING_SIZE through a function. However we would need to measure the risk that this new function could present (probably need to make it ownable to prevent any one from messing with the ring size and carrying out attacks...). If we decide to do it, this would be part of another PR. Here we introduced the ringSize global variable in the index.js running the benchmark. This helps having a bit more flexibility since anyone who would like to carry out benchmarks with different ring sizes would "only" need to:

1. Change the value of RING_SIZE in the LinkableRing contract
2. Change the value of ringSize in the index.js
3. Run: truffle migrate --reset to deploy the changes introduced in the contract.

Even thought this is not super beautiful to use global variables and static values, I think this is fairly "flexible", but not perfect I agree.

I'll close this PR for now. Please feel free to re-open it we you want