Currently, commit exposes to the Java-side the computation of a commitment. However, there are several ways to convert a commitment (elliptic curve point in extended twisted-Edwards coordinates) to bytes:
Via map_to_scalars : scalar field element used as values in the parent commitment and the rootHash. It is a relatively expensive operation (division), and not necessarily invertible.
Via to_bytes: base field element used to uniquely represent the commitment. It is cheap and invertible: an equivalent element in banderwagon can be recovered from the base field element.
Via uncompressed serialization: in geth, uncompressed serialization is used to save commitment to the database. This should strike a balance computation and memory. It might use 2 coordinates instead of a single one.
For our application, we actually need to be able to retrieve both the commitment as an elliptic point for proof generation and update commitments, and the commitment_hash to commit a commitment as a value to its parent node.
Although hash can be recovered from the point, we probably prefer to store both to avoid further divisions.
Description
Currently, commit exposes to the Java-side the computation of a commitment. However, there are several ways to convert a commitment (elliptic curve point in extended twisted-Edwards coordinates) to bytes:
Via map_to_scalars : scalar field element used as values in the parent commitment and the rootHash. It is a relatively expensive operation (division), and not necessarily invertible. Via to_bytes: base field element used to uniquely represent the commitment. It is cheap and invertible: an equivalent element in banderwagon can be recovered from the base field element. Via uncompressed serialization: in geth, uncompressed serialization is used to save commitment to the database. This should strike a balance computation and memory. It might use 2 coordinates instead of a single one.
For our application, we actually need to be able to retrieve both the commitment as an elliptic point for proof generation and update commitments, and the commitment_hash to commit a commitment as a value to its parent node. Although hash can be recovered from the point, we probably prefer to store both to avoid further divisions.