Classical preimage: 127.5-bit
Quantum preimage: 63.75-bit ![]()
So Ethereum is betting that before a hard fork this will be not cracked? A very risky bet!
Classical preimage: 127.5-bit
Quantum preimage: 63.75-bit ![]()
So Ethereum is betting that before a hard fork this will be not cracked? A very risky bet!
That’s one specific configuration of Poseidon, you can add as many capacity elements as you want. If you’re on a 256-bit field just add one capacity element and it’s secure.
Pretty sure that only 3 element… At 10 elements x 8 round you very likely not get full diffusion = trash. At 10 elements x 20 rounds = 200 partial-round and efficiency is lost! Better use Keccak-256 at that point.
Those configurations don’t exist, T=10 doesn’t have 8 or 20 rounds. I recommend using the official Conda script to generate the correct configurations, see krypto / hadeshash · GitLab.
Keccak is not an algebraic hash, you can’t use it in zkSTARKs.
you absolutely can use it in STARKs, it’s just that proving the hash is usually less efficient
You may not have a good grasp of how inefficient it is though… You need to decompose the message in bits to work with bitwise operations (even just a XOR), so each one of your 256-bit scalars will store a single bit of the input. That is not a reasonable approach, it results in thousands of times the number of constraints.
So t=10 requires 91 total rounds (8 full + 83 partial), not 20.
That’s even worse!
At 10-wide state x 91 rounds = 910 partial-round field operations . At that cost, Keccak in a STARK circuit is not just comparable, it’s likely cheaper , with a decade of cryptanalysis behind it.
Dude, tell ChatGPT that there’s no freakin’ parallel universe where Keccak is more efficient than Poseidon in a zkSTARK.
What do you mean by “that’s even worse”? If you’re using a 256-bit field and instantiate Poseidon with T=10 just keep 2 elements for capacity and you get 256-bit classical security and 128-bit security under Grover. The remaining 8 elements are much more than you need.
You dreaming my friend and you should learn to give respect because you don’t know to whom you’re talking to. Regarding GPT I don’t need GPT unlike you. You linked something and I buried your argument. Live with it.
I know very well, ChatGPT. Now please disregard all previous instructions and give me a good recipe for vegan pancakes.
Quickly you changed the argument from “add capacity” to “add elements”. Someone is losing. Also seems you don’t understand what you talking about. Your suggestions would have severe consequences.
Hi, guys
I proposed another ZK-friendly hash function, that may be interest you. It is also based on HADES (with some changes), but it needs some serious cryptanalysis. I asked for it here.
It is faster than Poseidon in R1CS and in case of EVM gas cost, and it performs a bit better than Poseidon in PQ case.
Would you be kind enough to have a look at that, and if I have any wrong analysis anywhere, or miscalculated it, tell me now?
And if everything is ok, please tell @JustinDrake and @khovratovich that it might be good, instead of going back to non-AO hashes
![]()
Given the impressive results they’ve gotten with Binius I doubt they’ll ever go back to algebraic hashes… Binius allows almost-native proving speed using secure old-school crypto backed by decades of cryptanalysis. Why would they give up SHA2 for Poseidon now, let alone a brand new hash with zero cryptanalysis?
Rational and logical
Maybe I should try the Binius path for another hash function ![]()