Optimize `Poseidon Hash` Implementation in CosmWasm Contracts

[99Kies]

Problem Description

The Poseidon hash function is a zero-knowledge (ZK) ecosystem-friendly cryptographic hash. Currently in our contracts, we can directly create Poseidon instances, but each message processing requires re-instantiating the Poseidon instance. This process involves loading substantial constant data, resulting in unnecessarily high gas costs.

Key Issues

1. Current Limitation: Is it possible to instantiate the Poseidon instance during contract initialization (loading all constant data once) and share it across subsequent contract calls? (This approach appears unfeasible with current architecture)

2. Proposed Solution: If the above approach is not viable, we should implement native Poseidon hash support in the CosmWasm framework. This would allow the Poseidon instance data to be pre-loaded in the chain's runtime environment, eliminating redundant loading and reducing gas costs.

Technical Context

• Poseidon hash is particularly important for ZK-related applications and privacy-preserving smart contracts
• The constant data loading during each instantiation creates significant overhead
• Native runtime support could provide both performance benefits and cost reductions

Desired Outcome

More efficient Poseidon hash implementation in CosmWasm contracts with reduced gas consumption for ZK-related operations.

[99Kies]

Poseidon Hash in CosmWasm: Research Update & Interim Solution

This comment is intended to share my latest research findings and a validated interim solution regarding the use of Poseidon hash in CosmWasm, for issue discussion and reference.

---

Background (Brief)

To remain compatible with the ZK ecosystem (e.g. circomlib / circomlibjs), Poseidon hash implementations used in CosmWasm must be fully consistent in parameters and outputs with those used in ZK circuits.

Due to CosmWasm’s execution model, each transaction instantiates a fresh Wasm VM, and no in-memory initialization state can be reused across transactions.

---

Research Findings

Note: In early experiments, I used the poseidon-rs implementation; in later stages, I evaluated and validated light-poseidon as an alternative.

During testing and profiling, I found that the earlier poseidon-rs implementation exhibits the following issues in the CosmWasm context:

• Heavy constant loading and format conversion during initialization
• These costs are repeated on every transaction due to per-tx Wasm instantiation
• The implementation is not security-audited, which makes it risky for production usage

---

Interim Solution

After comparing multiple implementations, I integrated and tested light-poseidon as an interim solution, with the following properties:

• Hash outputs are fully consistent with circomlibjs, preserving ZK compatibility
• Core implementation has undergone third-party security auditing (audit report available)
• Benchmarked in CosmWasm, and performance is sufficient for current product requirements

---

Gas Benchmark Results

Under identical parameters and test conditions, the following gas usage comparison was observed:

Instances	Old Version Gas	New Version Gas	Improvement
1x	5,981,940	120,244	-98.0%
5x	29,455,822	153,183	-99.5%
10x	58,798,136	194,369	-99.7%
20x	FAILED	276,716	Success

Key observations:

• The old implementation hits the gas limit as instance count increases
• The new implementation remains stable in multi-instance scenarios, with average gas per instance decreasing as scale increases
• This indicates that the dominant bottleneck lies in implementation-level constant initialization and data handling, rather than the Poseidon algorithm itself

---

Current Conclusions

• Under the current CosmWasm execution model, implementation details have a significant impact on the real-world cost of Poseidon hash
• With a more efficient and audited implementation (e.g. light-poseidon), gas usage can be significantly reduced without sacrificing ZK compatibility
• In the long term, this problem is still better addressed at the Runtime / VM level (e.g. host functions or precompiles)
• Additionally, Poseidon2 is gaining adoption across the ZK ecosystem (circuits, libraries, and tooling), and may be a relevant direction to consider if corresponding support becomes available on the CosmWasm side

---

The above is shared to synchronize current research progress and interim practical findings for further discussion.