Currently, ipa_multipoint uses compressed serialisation for commitments. The problem is that deserialisation is costly. This issue proposes to use uncompressed serialisation instead as in geth. Although it doubles the size of the serialised commitment, it makes deserialisation much faster.
Rationale
Commitment is a point on an elliptic curve. In compressed serialisation, we use a byte representation of the field element x*sign(y) in affine coordinates. This is 32-bytes. However, to deserialise, we need to reconstruct the y-coordinate, and this requires many field operations including a division.
Uncompressed serialisation on the other hand concatenates both x and y. This is 64-bytes now, but deserialisation is trivial.
The geth team has made benchmarks and have chosen uncompressed serialisation. Indeed, Verkle is already much more memory efficient than Merkle, so it was deemed acceptable to use more memory for serialisation given the computation savings.
We propose to follow suit.
Note
In our case, we use rust implementation that ultimately uses arkworks implementation of elliptic curves. If geth works in projective coordinates, it seems that arkworks uses extended twisted Edwards coordinates. It might or might not have an impact on serialisation.
Currently, ipa_multipoint uses compressed serialisation for commitments. The problem is that deserialisation is costly. This issue proposes to use uncompressed serialisation instead as in geth. Although it doubles the size of the serialised commitment, it makes deserialisation much faster.
Rationale
Commitment is a point on an elliptic curve. In compressed serialisation, we use a byte representation of the field element x*sign(y) in affine coordinates. This is 32-bytes. However, to deserialise, we need to reconstruct the y-coordinate, and this requires many field operations including a division.
Uncompressed serialisation on the other hand concatenates both x and y. This is 64-bytes now, but deserialisation is trivial.
The geth team has made benchmarks and have chosen uncompressed serialisation. Indeed, Verkle is already much more memory efficient than Merkle, so it was deemed acceptable to use more memory for serialisation given the computation savings.
We propose to follow suit.
Note
In our case, we use rust implementation that ultimately uses arkworks implementation of elliptic curves. If geth works in projective coordinates, it seems that arkworks uses extended twisted Edwards coordinates. It might or might not have an impact on serialisation.