This week was a realization week. I went deeper into how precompiles are made and how they are executed. It turns out that precompiled smart contracts are not executed the same way as normal contracts. In Ref. 6 below, there is a really nice explanation how precompiles work.

When you hear or read "smart contract" you can imagine some solidity code that is compiled to bytecode that the EVM must execute. Actually, what the EVM does is to first verify if the address of the contract corresponds to a precompiled contract or a regular contract. If the address corresponds to a regular smart contract, then the interpreter of the EVM is called, as usual. But, if the address belongs to a precompiled smart contract, then the corresponding code, which is found in the client, is executed on the client. Therefore, all precompiled contracts are executed on the client side and no EVM is required. Furthermore, in the Ethereum Yellow Paper [3] all gas costs are fixed for each precompiled. Therefore, my initial idea of doing a gas cost analysis of poseidon as a precompile makes no sense.

Even though what I explained above breaks my original idea for a project, there are still many ways to contribute to EIP-5988. For example, the computational costs of poseidon as a precompile are relatively unknown compared against other existing hash functions that are also precompiled contracts. There are three precompiled hash functions: 1) SHA256, 2) RIPEMD160, and 3) BLAKE2b. Also, the gas cost of poseidon as a regular smart contract is unknown, as far as I know.

In order to gain some insight into the process of creating a new precompiled contract, I read the conversations around EIP-152: Add BLAKE2 compression function F precompile. Indeed, the ideas of the previous paragraph come from these discussions about BLAKE2b; see here and here.

I already have a pretty good idea of what I want to do as a project. Basically:

1. Make a solidity smart contract for poseidon to estimate gas costs. This will be used as a point of reference for benchmarks.
2. Make a GO implementation of Poseidon following the proposed specs in EIP-5988. There are implementations of Poseidon in GO, but they do not follow EIP-5988.
3. Use the precompiles of SHA256, RIPEMD160, and BLAKE2b in GO and compare the execution times against our GO implementation of Poseidon.
4. Use the results of the benchmarks to propose a gas cost for a Poseidon precompile. Again, following the discussions in EIP-152: Add BLAKE2 compression function F precompile we can estimate 1 gas per each microsecond of execution time.

There are still other issues related to Poseidon, for example, what the best parameters should be, what MDS matrices to use, or what S-boxes should be used. I do not know if some of these issues can be covered in time during the EPF, but I expect to continue working on these issues after the EPF. Some issues are easy to cover with minimal change in the code like trying different S-boxes.

As scope of the project, however, I will mainly focus on benchmarking and gas cost estimates. By Week 4 I expect to finish my final proposal.

References

1. Tjaden Hess [e-mail], Matt Luongo (@mhluongo), Piotr Dyraga (@pdyraga), James Hancock (@MadeOfTin), "EIP-152: Add BLAKE2 compression function F precompile," Ethereum Improvement Proposals, no. 152, October 2016. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-152.
2. Abdelhamid Bakhta (@abdelhamidbakhta), Eli Ben Sasson (@Elistark), Avihu Levy (@avihu28), David Levit Gurevich (@DavidLevitGurevich), "EIP-5988: Add Poseidon hash function precompile [DRAFT]," Ethereum Improvement Proposals, no. 5988, November 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5988.
3. Wood, G. (2014). Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151(2014), 1-32. https://ethereum.github.io/yellowpaper/paper.pdf
4. https://blog.qtum.org/precompiled-contracts-and-confidential-assets-55f2b47b231d