How to Make it Less Gas Intensive, Try to run mimcFeistel with 220,2,0,0

Sophia Smart Contract Development
#1

Hi,

Running below code will get out of gas error and with highest gas it only passes 6 rounds locally.

Try to run mimcFeistel function with values like 220,2,0,0 (for example) from below code

First is Rounds, Second left input, right input , k.

This is like one function and others are still to be fixed & attach with it. The max rounds I can run with it are 6

It is mentioned here Library functions must be implemented if declared. · Issue #86 · tornadocash/tornado-core · GitHub that it needs to be deployed in lower level functions and these are the direct instructions circomlib/mimcsponge_gencontract.js at master · tornadocash/circomlib · GitHub

While here is how they make script to deploy on ethereum the bytecode and abi tornado-core/compileHasher.js at 23543683f3af71783f8036c16fe9ad21369dc3dc · tornadocash/tornado-core · GitHub

Then this here is the solidity version of the hasher mimc.sol · GitHub

#2

Switch statements was resetting the values (which i think i am not using them correctly). So switching to if, else which makes it works with slight corrections.

But having a way to spot the error at runtime will be helpful

#3

@hanssv.chain @dimitar.chain The title is changed, Can you please take a look and let me know if there is a way to make it efficient, So i can run hasher on top of chain ?

Check OP

#4

Is there a way to perform low level instructions on FATE then form bytecode & deploy it ?

#5

Yes it can be made more efficient. But, if you can get it efficient enough I don’t know.

Two observations:

  1. Shouldn’t this be modulus something, right now you are creating humongously large numbers… With 6 rounds the largest number contains more than 27000 digits, that can’t be right (and it would never work in Solidity :joy: )
  2. If you want something to be efficient you should recurse over the list rather than trying to use a list as an array - it means sligthly adapting the algorithm but it should be reasonably straightforward.
1 Like
#6

Thank you @hanssv.chain ,
I will modify it accordingly.

1 Like
#7

Ah just checked, The largest number was 100,000+ that’s with setting round to 7 (0-6). Thanks for explaining.

1 Like
#8

@philipp.chain
When i try to run t5_now() at https://contracts.aeternity.art/ I receive result as null but through aeproject I get the result int with length 380.

entrypoint t5_now(): int = 
        let _t: int = 6936272626871035740815028148058841877090860312517423346335878088297448888663
        let t2_now: int = _t * _t
        let t4_now: int = t2_now * t2_now
        let t5_now: int = t4_now * _t
        t5_now
#9

@hanssv.chain Thank you for your earlier advice, mimcFeistel is working now

For dry-run even by setting gas fee too high ({ gas: 50000000, gasPrice: 20000000000 }), It cannot run twice but for the hasher to work, I need to run it twice for each input. If you run get_feistel_once() you will get the result even with a bit lower gas fee than above like 30000000 lesser might not work. But if you run get_feistel_twice() it always says Invocation failed: "Out of gas" even after setting gas like { gas: 59000000, gasPrice: 20000000000 } setting gas to 60000000 get me over the gas limit (cannot send actual tx, explained below). Should I cut the rounds (arrays in the list) to 1/4 or something similar ?

I am using aeproject @marco.chain. There are two errors related to it:

please do let me know If i am doing something wrong in above settings which can be made better

#10

Hi, sorry for the slow response I was out over the weekend.

I still think the code can be optimized quite a bit, looking at loopResult, which is where the processing is done. For example xl and xr always contain exactly i elements, and we always get(j, xl/xr), i.e. we only use the last element of the list. So no need to carry the whole list which would save you both from cons:ing at the end (<long_list> ++ [element]) and List.get which are both really inefficient.

My initial comment still applies though I’m not sure the code can be efficient enough, but let’s see.

3 Likes
#11

thank you @hanssv.chain

Your suggested optimization works & now even twice mimcfeistel provides the result with the same dry run fee that was able to provide it for once from the start.

1 Like
#12

@hanssv.chain @marco.chain
Mimcsponge Hasher now fully works on Aeternity’s Fate. You can run the test from

However, I removed the extra outputs and only accept required inputs for specific use case but it is easier to modify it, remove inputs require and add this from here ZoKrates/mimcSponge.zok at ba5150afb4a1ddd1604f7e3ca8d8dc0c5dff4031 · Zokrates/ZoKrates · GitHub

2 Likes
#13

Nice work @genievot !

2 Likes
#14

Thank you @MatthewHinton !

#15

@hanssv.chain

Can you please suggest something with MIMCSponge, Any other way to make it more efficient ? I need to run it atleast 40 times in a single call because of 20 Levels on Merkle Tree as to make it more similar to our target.

Merkle Tree: Merkle Tree Aeternity with MIMC hash as parameter · GitHub
Mimc Sponge: testings mimc sponge · GitHub

@marco.chain also consider this that if the possibility to make it more efficient becomes harder and I need to run it at this state with atleast 40 times in each call then can you suggest a way where I can send “Gas * 40” than the limit you and @philipp.chain mentioned ??

It might looks like a big deal but it could hardly be near 1 AE, right ?

#16

I’ll quote myself here - I’m not sure it is possible to get it efficient enough to compute 40 hash-values in a single transaction!? FATE is different from the EVM and while it is more efficient in many ways - pure computations like this is not one of those ways.

If you need a particular hash-function one way forward could be to have it implemented in the VM - this would make it more efficient and cheaper. If you look at the changes already made for the next hard fork we have added a similar hash-function (the Poseidon hash), but, yeah, that require a hard fork.

1 Like
#17

@hanssv.chain I understood it the first time you said but I need to try. Thank you.

I want to make the system live soon, Can you please suggest from available (different family) hash functions, sha3, sha2 & blake2b. Which one I should use (i can use addition and modulus instead of giving 2 inputs) ?

and also, Can you please tell When is the next Hard fork scheduled ? Like a guess even if exact date is not available to you. I will be prepared then to use correct family hash function for the update (if required).

1 Like
#18

Isn’t the problem with using a “normal” hash function that it will get very expensive to compute the ZK-proofs? But it was a long time since I did anything with this so I might be wrong.

Next protocol upgrade (a.k.a. hard fork) is not scheduled as far as I can tell. There are a couple of good improvements already implemented - perhaps most notably micro block packing - but I have not seen any discussion on actually upgrading the chain protocol - @dimitar.chain or @marco.chain maybe?

4 Likes
#19

The schedule of the next hard fork is not yet planned, we are still accumulating features for it. Bear in mind that currently our main focus is HyperChains, so our resources are dedicated mostly in this direction. Regarding next hard fork (it is called ceres) improvements, there will be a blog/forum post soon :slight_smile:

4 Likes