A critical exception has occurred:
Message: pr 5988 is already merged; quitting
(cc @alita-moore, @mryalamanchi)

External links should not be included

Sounds good. Will update, thanks for the review

External links should not be included

Fixed

I do have a couple of concerns with this EIP proposal:

1. On which field is this going to be implemented? As there's a lot of BLS and BN curves and you'll need to have a pre-compile for each of them. Which seems unfeasible and not practical at all.
2. The security parameters will change depending on the field on which you're working with and the security of the curve, bit size etc...
3. You can implement Poseidon with different Arity parameters. So basically there's an infinite amount of permutations that can be added. And doesn't make sense that this is enforced by a precompile as many companies or users might find the precompile worthless.

Yeah this is the main difficulty of this precompile. There are multiple options there with different tradeoffs on usability / practicality vs flexibility mainly. will try to expand more on those options.
Happy if you have some suggestions.
Maybe we can start with a precompile including all common configurations in the industry. Then we need to think about the upgradeability of the precompile, should it go only through hard fork, or should we design a mechanism to add configurations dynamically.

Maybe we can start with a precompile including all common configurations in the industry. Then we need to think about the upgradeability of the precompile, should it go only through hard fork, or should we design a mechanism to add configurations dynamically.

I guess this is maybe my concern which is to understand if this as a precompile will imply a significant benefit.
Poseidon pre-compiles would only make sense to verify hashes of MPT inclusion checks or to be able to use Poseidon in proof Transcripts for example. (Semaphore for example could benefit a lot from that. As the circuits would use Poseidon and the tree is build on the top of the Patricia trees. So is not tied to keccak logic at all.

Poseidon would really be useful if implemented in the Patricia trees directly. In the ETH database itself. But it's a slow hash when computed outside of circuits. So not really worth it at all.
Outside from the ZK world it doesn't bring any features at all that are different from keccak and in fact is significantly slower and has a lot of field-dependant configuration parameters.

So a pre-compile that includes it would not be really useful from my perspective. Would be really tricky to code, with A LOT of use cases to take into account and also, with a lot of fields to code it with. (Unless you constrain it to be able to be used only with fields implemented on pre-compiles so BN256 only).

Aside from that concern, there's another one that is also significant. And it's the fact that if the roadmap that Vitalik shared continues to move forward, "The Verge" will arrive. And once we move to vector commitments, the sparseness of the tree will imply that very few hashes need to be performed. And, therefore, people might prefer vector commitment verification pre-compile helpers rather than an specific hash function that was included some time ago.

I would appreciate if you could share the motivations to add the pre-compile since maybe aside from helping Merkle trees build inside contracts, anyone else will get a benefit due to implications that I ignore :)

Thanks a lot!

Maybe we can start with a precompile including all common configurations in the industry. Then we need to think about the upgradeability of the precompile, should it go only through hard fork, or should we design a mechanism to add configurations dynamically.

I guess this is maybe my concern which is to understand if this as a precompile will imply a significant benefit. Poseidon pre-compiles would only make sense to verify hashes of MPT inclusion checks or to be able to use Poseidon in proof Transcripts for example. (Semaphore for example could benefit a lot from that. As the circuits would use Poseidon and the tree is build on the top of the Patricia trees. So is not tied to keccak logic at all.

Poseidon would really be useful if implemented in the Patricia trees directly. In the ETH database itself. But it's a slow hash when computed outside of circuits. So not really worth it at all. Outside from the ZK world it doesn't bring any features at all that are different from keccak and in fact is significantly slower and has a lot of field-dependant configuration parameters.

So a pre-compile that includes it would not be really useful from my perspective. Would be really tricky to code, with A LOT of use cases to take into account and also, with a lot of fields to code it with. (Unless you constrain it to be able to be used only with fields implemented on pre-compiles so BN256 only).

Aside from that concern, there's another one that is also significant. And it's the fact that if the roadmap that Vitalik shared continues to move forward, "The Verge" will arrive. And once we move to vector commitments, the sparseness of the tree will imply that very few hashes need to be performed. And, therefore, people might prefer vector commitment verification pre-compile helpers rather than an specific hash function that was included some time ago.

I would appreciate if you could share the motivations to add the pre-compile since maybe aside from helping Merkle trees build inside contracts, anyone else will get a benefit due to implications that I ignore :)

Thanks a lot!

Thanks a lot for your comments. Can we please move to the Eth Magicians thread to gather all discussions there ?
https://ethereum-magicians.org/t/eip-5988-add-poseidon-hash-function-precompile/11772

I'm late to the conversation, but wondering what's the latest on this EIP? We use poseidon in Mina in production, and would like our proofs to be verifiable on Ethereum. For that we would need poseidon precompiles to be compatible with our own version of poseidon (which might not be true atm, since we all use a different version of poseidon :D) and support for elliptic curve operations for the pasta curves

I'm late to the conversation, but wondering what's the latest on this EIP? We use poseidon in Mina in production, and would like our proofs to be verifiable on Ethereum. For that we would need poseidon precompiles to be compatible with our own version of poseidon (which might not be true atm, since we all use a different version of poseidon :D) and support for elliptic curve operations for the pasta curves

Hey mate you are not late at all. Very interesting that Mina is also using Poseidon. Making this precompile generic is indeed the most difficult part. And talking to different entities that use it helps a lot, so we definitely need to chat more. Can you post on the Ethereum Magicians discussion too ? And also would love to schedule a call to discuss it with you. My telegram is @ abdelhamidbakhta

Ethereum Magicians discussion

what's that?

@mimoo Hey David, it's a forum where EIPs are discussed. See https://ethereum-magicians.org/t/eip-5988-add-poseidon-hash-function-precompile/11772/15 for the discussion over this one.