[keccak] Alternative implementations

[Brechtpd]

Description: https://hackmd.io/NaTuIvmaQCybaOYgd-DG1Q?view

Contains two (~three) different approaches to do keccak:

• bit implementation: does keccak on the bit level
• packed implementation: does keccak by packing multiple bits together and uses lookups to do the transformations. The multi variant can use multiple rows/internal round to reduce the number of columns, but because of that it is a little bit less efficient than the non multi variant (~5%) . This variant is similar to the current approach followed, but the implementation is quite a bit different.

The current code should be good enough to compare performance between the different implementations.

[CPerezz]

Review for the approach 1: Bit solution

So far it looks nice an simple. I would say a couple of things:

• The naming used is a bit poor and does not help to understand what's what (b bits, c bits etc...).
• The generation of the witness could be more automatic if we build methods as the KeccakRow generators for example as associated fns of KeccakCircuit.
• There are some commented code parts on Theta gate lookups generation which I'm not sure they should stay or are just missed things.

Also, as mentioned. We need to take into account that #659 will imply that the RLC is not longer a witness we provide to the circuit and rather just a value we "compute and can pass over to other circuits" via lookups.

Aside from all that. Awesome work with this @Brechtpd I'm super impressed! Will continue with the packed and multi_packed reviews.
And from these, we should just pick the most performant and make some estimations to see if we should try to optimize more before going for the full impl with padding + table etc..

[CPerezz]

Why not just use a Fixed or Constant for q_end?

[Brechtpd]

I guess q_end is a bad name. The goal is for it to be used to mark the end of one keccak hash so a new keccak hash can be started. So where this will be set to 1 will change depending on the inputs.

[CPerezz]

As said above. Why can't this be also fixed?

[AronisAt79]

zkevm-circuits PR#634 keccak bench results

1. packed_multi_keccak_bench

Cloud instance specs

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   46 bits physical, 48 bits virtual
CPU(s):                          96
On-line CPU(s) list:             0-95
Thread(s) per core:              2
Core(s) per socket:              24
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz
Stepping:                        7
CPU MHz:                         2999.998
BogoMIPS:                        5999.99

RAM: 192 Gb

Result

test packed_multi_keccak::tests::bench_packed_multi_keccak_circuit_prover has been running for over 60 seconds
End:     Packed Keccak Multi Proof generation with 19 rows .........................390.956s
Start:   Keccak Proof verification
End:     Keccak Proof verification .................................................41.143ms
test packed_multi_keccak::tests::bench_packed_multi_keccak_circuit_prover ... ok

max RAM at ~ 35Gb

2. packed_keccak_bench

Cloud instance specs

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   46 bits physical, 48 bits virtual
CPU(s):                          96
On-line CPU(s) list:             0-95
Thread(s) per core:              2
Core(s) per socket:              24
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
Stepping:                        7
CPU MHz:                         2499.998
BogoMIPS:                        4999.99


RAM: 388 Gb

Result

test packed_keccak::tests::bench_packed_keccak_circuit_prover has been running for over 60 seconds
End:     Packed Keccak Proof generation with 19 rows ...............................2170.731s
Start:   Keccak Proof verification
End:     Keccak Proof verification .................................................97.567ms
test packed_keccak::tests::bench_packed_keccak_circuit_prover ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 6 filtered out; finished in 2190.35s


max RAM at ~ 190Gb

3. bit_keccak_bench

Cloud instance specs

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   46 bits physical, 48 bits virtual
CPU(s):                          96
On-line CPU(s) list:             0-95
Thread(s) per core:              2
Core(s) per socket:              24
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
Stepping:                        7
CPU MHz:                         2499.998
BogoMIPS:                        4999.99


RAM: 388 Gb

Result

test bit_keccak::tests::bench_bit_keccak_circuit_prover has been running for over 60 seconds
End:     Bit Keccak Proof generation with 19 rows ..................................1819.173s
Start:   Keccak Proof verification
End:     Keccak Proof verification .................................................175.432ms
test bit_keccak::tests::bench_bit_keccak_circuit_prover ... ok

max RAM at ~ 255Gb

PR634-packed_keccak_bench.log
PR634-packed_multi_keccak_bench.log
PR634-bit_keccak_bench.log

[AronisAt79]

@CPerezz @ChihChengLiang bench results in previous comment ^^^^

[Brechtpd]

Awesome, thanks a lot for this @AronisAt79! Results are quite a bit differently than I expected.

Some extra context for these benches:

1. packed_multi_keccak_bench

Uses 5 rows/internal round (assuming default settings were used, the main feature of this implementation is that the number of rows/internal rounds can be chosen) and so hashes 136 bytes/125 rows. In the bench 2**19/125 = 4194 keccak hashes are done in 391s giving 10.72 keccak_f/s. This circuit in this configuration uses ~200 columns.

2. packed_keccak_bench

Uses 1 row/internal round and so hashes 136 bytes/25 rows. In the bench 2**19/25 = 20971 keccak hashes are done in 2170s giving 9.66 keccak_f/s. This circuit uses ~800 columns. Surprises me that it's a bit slower than the packed_multi version... EDIT: Oh I see the packed_multi one was run on a CPU that was 3GHz vs 2.5GHz for this one, that makes sense then.

3. bit_keccak_bench

Uses 1 row/internal round and so also hashes 136 bytes/25 rows. In the bench 2**19/25 = 20971 keccak hashes are done in 1819s giving 11.53 keccak_f/s. This circuit uses ~2000 columns. This result is much closer to the packed implementations than I expected and I expected this one to be quite a bit faster. (EDIT: I can do 4 hashes/s for a circuit with 2**14 rows on my 10 year 4-core cpu, so seems like something on the prover doesn't scale as it should with many more cores (and better cores). I would expect this circuit to do something like 20 keccak hashes/s on the bench pc).

Pending and future prover optimizations should improve all of these quite a bit still.

All columns given as an estimate because the actual number of columns depends on the circuit height. The circuits automatically builds themselves to use the biggest lookup tables possible so that the number of lookups (and so also the number of columns required for those lookups) is reduced as much as possible.

[CPerezz]

@Brechtpd the only issue I see with the packed approaches is the big amount of RAM required. Considering specially that the bit approach performs better (at least now) than the others consuming less resources.

I'd also edit your prev message to say that they're not hashes/s but keccak_f's/s or permutations/s.
As the hash itself does not have a magnitude since the input can have any size.

Aside from that, as we commented in the past, we will check with the authors of Caulk whether it can help us to bring down these lookup costs and how could we integrate it within halo2.

[Brechtpd]

The implementations are now complete, but I will spend a bit more time cleaning up the code some more (and incorporating the feedback above).

[CPerezz]

Hey @Brechtpd is it clean now so that we can go for a merge here?
What do you think??

[Brechtpd]

Can be merged whenever you want for me. I will still do some changes to make things better, but like discussed that can be done in a follow up PR.

[ChihChengLiang]

I added some comments. @CPerezz Feel free to merge if we want to avoid conflict for halo2 upgrade. I still want to do more reviews, but I can add comments post-merge.

[ChihChengLiang]

Should this be EVM word(256 bits) or Keccak word(64 bits)?

[Brechtpd]

I think everywhere I talk about words they are keccak words (because keccak doesn't directly have anything to do with EVM words I think it should be clear from context, or at least I hope so).

[ChihChengLiang]

The type Word here is pub type Word = U256; from zkevm-circuits/eth_types. Can we define a type Word = u64 and replace U256 with it?

[Brechtpd]

Something >u64 is needed here because this will pack all 64 sparse bits into a single field element. With each sparse bit taking up 3 bits, the full packed word needs to be stored in at least 64*3 = 192 bits. Though I'm not sure anymore why I don't simply do all the math on a Field value directly, will see if it's easy to switch to that instead.

[CPerezz]

LGTM with the current status.

I would merge this to prevent massive conflicts once the halo2 update PR is merged here.
I encourage anyway to keep the work of cleanup. And probably we should consider to start with the entire circuit as I attempted in #542