Add bn254 support and expose poseidon/poseidon2 host functions

[mootz12]

What

• Add bn254 support (Add bn254 support #1615, Bump env to update bn254 encoding. #1628)
  • A new module crypto/bn254.rs with Bn254 point and field types, and expose related host operations.
  • Implement Neg trait for G1Affine (Feature/bn254 neg trait #1630)
  • Update bn254 typenames and add mapping (Update bn254 typenames and add mapping #1645), also updated bls12-381 type names for consistency
• Add raw Poseidon, Poseidon2 support in CryptoHazmat, gated by "hazmat-crypto" feature

Why

Expose new crypto functions for protocol 25

Known limitations

Only the raw host function exposure for Poseidon/Poseidon2 has been added in this PR. The more elaborate setup for sponge, parameters, hash function wrappers will be done in a separate repo here

[leighmcculloch]

Can we name the title of this PR, and its description with the crypto features being merged so that the git history on main captures what the features are being introduced? We can probably lift details from the PRs that were merged into the v25 branch. The final commit is written using the PR title and description.

[leighmcculloch]

@jayz22 Should this wait on #1663 merging first? Or can that go to main separately?

[jayz22]

@jayz22 Should this wait on #1663 merging first? Or can that go to main separately?

@leighmcculloch yeah, let's merge that one first, since it contains a few additions/improvements to the Poseidon(2).

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	soroban-env-host@​23.0.1 ⏵ 25.0.0
	soroban-env-common@​23.0.1 ⏵ 25.0.0	+1
	stellar-xdr@​23.0.0 ⏵ 25.0.0	+1
	soroban-env-guest@​23.0.1 ⏵ 25.0.0

View full report

[teddav]

@jayz22 Could we add more constants to the Poseidon config? With the current parameters (T = 3 and the constants) in poseidon_params, hashing is limited to just two inputs. Supporting more inputs would be much more useful.
Since the number of inputs scales with the number of constants, we probably don’t want to make poseidon_params.rs too heavy. That said, supporting around 5–6 inputs feels like a good balance and should cover most protocol use cases.

EDIT: i just saw that you have an open PR with T=4, can we add a few more? :) Happy to review the PR if needed

[jayz22]

@jayz22 Could we add more constants to the Poseidon config? With the current parameters (T = 3 and the constants) in poseidon_params, hashing is limited to just two inputs. Supporting more inputs would be much more useful. Since the number of inputs scales with the number of constants, we probably don’t want to make poseidon_params.rs too heavy. That said, supporting around 5–6 inputs feels like a good balance and should cover most protocol use cases.

EDIT: i just saw that you have an open PR with T=4, can we add a few more? :) Happy to review the PR if needed

@teddav thanks for your interest in trying the Poseidon!
In the second PR I've added Poseidon parameters for t up to 4 (hashing 3 inputs). This should be a good starting point, but happy to consider adding more. (it's mostly takes time to properly generate/validate the parameters for both bn and bls and test them against circom/noir).

Also to point out, there is no hard rule between number of inputs and internal state size. I.e. you can use a sponge with internal t=4 and hash input length of 100, internally the sponge alternate between absorb and permute until the entire input is consumed. I.e. you can do the following

    // initialize a config with rate=2 (t=3)
    let config = PoseidonConfig::new(&self.env, field_type, 2);
    poseidon_sponge::hash(&self.env, inputs, config)

[leighmcculloch]

I thought all the changes in this pr were already reviewed on other PRs before merging to the v25-preview, but upon review of the PRs, not all of them were reviewed or approved.

I took a look through and noted a few minor things, comments inline. cc @jayz22

Can folks from the core team who are familiar with the crypto being added please do a full review? cc @stellar/contract-committers

The changes should ideally be reviewed by someone who wasn't the author. The authors were @jayz22 @Oghma @sisuresh. But @sisuresh's changes were all reviewed, so the reviewer just needs to be someone other than @jayz22 @Oghma.