Guidance on Handling Balances from Multiple Cryptocurrencies in MST

[yagnadeepxo]

Summary

This issue seeks to clarify and request documentation or utility functions for handling balances from multiple cryptocurrencies when constructing a Merkle Sum Tree (MST) within the Summa Solvency Protocol. The goal is to ensure that developers understand how to correctly normalize, convert, and map balances from various sources to the field F_p
of the bn256 curve, a critical step for leveraging the protocol across diverse assets.

Background

Exchanges and platforms dealing with multiple cryptocurrencies need to accurately represent user balances in a unified format suitable for cryptographic operations, specifically when building an MST. The process typically involves:

1. Normalizing balances to a common base unit.
2. Converting balances to strings, if they are not already in this format.
3. Parsing these strings into BigUint.
4. Mapping BigUint balances to the field F_p of the bn256 curve.

Challenges

Normalization: Different cryptocurrencies use different base units (e.g., wei for Ethereum, sathoshi for Bitcoin, lamport for Solana). A clear standard for normalization across currencies within the Summa context is needed.

String Conversion and Parsing: Not all balances are initially in string format. Guidance on handling various formats and precision concerns is required.

Mapping to F_p: The conversion process from BigUint to an element of F_p is crucial and must ensure no loss of precision or value.

Request

Documentation: Detailed documentation on each step of the process, with examples for common cryptocurrencies. This should include best practices for normalization and dealing with precision.

Utility Functions: It would be highly beneficial to provide utility functions within the Summa library that abstract some of these steps, particularly normalization and mapping to F_p to minimize potential errors.

Examples: Real-world examples or case studies of integrating multiple cryptocurrencies into the MST, highlighting any edge cases or common pitfalls.

[alxkzmn]

Summa performs all the calculations on each currency separately so there's no need for a common denomination. We can have different precision per currency.