EIP-1108 support

[naddison36]

Is there a version of the contracts that uses ECADD and ECMUL implemented in EIP-1108?

[benediamond]

as I understand this EIP, it will merely change the gas accounting of the EVM---the contracts won't change. thus we either need to wait until this EIP gets merged, or you can go into the geth params and change the precompile gas costs yourself. does this sound right?

[naddison36]

@benediamond you are correct. No contract changes are required. Here's the gas costs before and after the Istanbul fork is applied to my local Geth

	Before	After
Deposit	263,580	199,142
Transfer	16,839,076	5,104,954
Withdrawal	7,928,163	2,386,977

[benediamond]

Cool, thanks for doing this experiment. You can see how much better things are after the EIP.

Also, you can try this for larger anonsets, and see what kind of improvements you get from those...!

[naddison36]

How do I try with a larger anonsets? Is that just with more decoys?

[benediamond]

Yes. You can see in example in the later part of the readme. e.g., for anonset size 4 you need 2 decoys; for 8 you need 6; for 16 you need 14... etc.

[naddison36]

Here's the gas usage of transfers for different anonsets before and after the Istanbul fork

Decoys	Anonymity set	Saving	Before	After
0	2	70%	16,839,076	5,125,962
2	4	70%	19,544,408	5,767,062
6	8	69%	27,474,470	8,433,752
14	16	70%	44,573,980	13,565,718
30	32	70%	83,156,690	24,905,448

This was tested against Geth using the following genesis.json file

{
  "config": {
    "chainID": 8998,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "clique": {
      "period": 2,
      "epoch": 30000
    }
  },
  "nonce": "0",
  "difficulty": "0x400",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "coinbase": "0x0000000000000000000000000000000000000000",
  "timestamp": "0x00",
  "extraData": "0x00000000000000000000000000000000000000000000000000000000000000001563915e194D8CfBA1943570603F7606A31155080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x23c34600",
  "number": "0x0",
  "alloc": {
    "0x19E7E376E7C213B7E7e7e46cc70A5dD086DAff2A": {
      "balance": "10000000000000000000000000"
    },
    "0x1563915e194D8CfBA1943570603F7606A3115508": {
      "balance": "10000000000000000000000000"
    },
    "0x5CbDd86a2FA8Dc4bDdd8a8f69dBa48572EeC07FB": {
      "balance": "10000000000000000000000000"
    },
    "0x7564105E977516C53bE337314c7E53838967bDaC": {
      "balance": "10000000000000000000000000"
    }
  }
}

[benediamond]

excellent @naddison36, big thanks for doing this.

I think the major open question is whether anonset size 8 will fit under the block gas limit. I would be willing to make a push to optimize this the hell out of this thing, to make sure it does before Istanbul hits.

[naddison36]

Mainnet block limit is now just under 10m so in theory an anonset size of 8 will fit under the mainnet block limit. It'd cost around 1.50 USD at today's prices. Further optimisation would be good. I guess the best way to do that is to use more precompiled contracts but I have no idea if that's possible.

[benediamond]

Good to know, I hadn't realized the mainnet gas limit climbed a bit.

I think the main possibility to optimize this further is to replace the standard FFT algorithm with a variant which performs all operations in-place, and doesn't have to allocate O(N log N) stack-local memory. This should save a decent amount of gas.

This on the to-do list, also welcome external contributions :)