[Feature Request] Support for Encrypted Return Values in Generated Solidity Contracts

[oftiyf]

[Feature Request] Support for Encrypted Return Values in Generated Solidity Contracts

Description

Currently, the Circom framework has limitations regarding return values in the generated Solidity contracts. This constraint reduces flexibility in many use cases where we need to return encrypted data to be stored on-chain.

Current Behavior

• Generated Solidity contracts don't support return values
• Limited flexibility in complex scenarios requiring on-chain encrypted data storage
• No option to return encrypted computation results

Proposed Enhancement

Add optional support for returning encrypted values that can be stored on-chain. This would:

1. Allow circuits to return encrypted computation results
2. Enable more complex use cases while maintaining zero-knowledge properties
3. Provide more flexibility for projects with advanced requirements
4. Make the encrypted return values optional (opt-in feature)

Use Cases

1. Privacy-preserving computations that need to store encrypted results on-chain
2. Complex ZK applications requiring state updates with encrypted data
3. Advanced protocols needing to chain multiple ZK proofs with intermediate encrypted results

Benefits

• Enhanced flexibility for complex ZK applications
• Broader range of possible use cases
• Maintained security through encryption
• Optional feature (wouldn't affect existing implementations)

Implementation Suggestions

1. Add encryption wrapper for circuit outputs
2. Modify Solidity contract generator to support encrypted return values
3. Provide documentation for proper usage and security considerations
4. Include example implementations

Questions

• What encryption methods would be most suitable?
• How would this affect gas costs?
• What would be the optimal way to implement this without compromising the framework's security guarantees?

Additional Context

This feature would be particularly valuable for projects requiring:

• Complex multi-step ZK proofs
• On-chain state management with encrypted data
• Integration with other privacy-preserving protocols

---

Would love to hear the community's thoughts on this proposal and potential implementation approaches.

[oftiyf]

While I have noticed many other zk-SNARK framework solutions, they are too abstract and unfriendly for developers who aren't deeply versed in ZK (Zero-Knowledge Proofs) technologies. I strongly hope that Circom can add some options to increase its flexibility while maintaining its developer-friendly nature.

The beauty of Circom lies in its relative simplicity and accessibility. Adding these options would bridge the gap between simple use cases and more complex requirements, without forcing developers to switch to more complicated frameworks.

This would be particularly valuable because:

• It maintains Circom's user-friendly approach
• It provides a growth path for projects as they become more complex
• It keeps developers in a familiar environment rather than forcing them to learn entirely new, more abstract frameworks
• It serves as a middle ground between simple implementations and highly complex ZK frameworks

This enhancement would help Circom maintain its position as an accessible yet powerful tool in the ZK ecosystem.