Goal

We want to move a sector from one proof and specific curve to another proof system and/or curve. This would allow us to rely on the effort from the ecosystem to push for better and better SNARKs and enables faster development of new features on Filecoin.

Technically: The SP should be able to prove that he has two sectors, one encoded with former curve A and the new one encoded with new curve B that encodes the same data. To do this, we ask him to reveal randomly X positions on both sectors (his commR) and verify that the leaf, the actual encoded data, is the same on both.

Strategies

These are the potential strategies currently being worked on:

1. Direct translation: Translate directly from the Poseidon hashing in one curve to the poseidon hashing in another curve using (a) non native arithmetics or (b) two different proofs

Pros: A SP can directly take advantage of another proof system, no need for change on current proof system

Cons: costly + translation is only useful for one other proof system/curve, not for all

2. “Curve agnostic hash”: Take the commR in Poseidon, make a translation proof on sha256 / blake2 etc. Then any curve / proof system can directly translate from this hash function to the “snark friendly hash function” they want to use for this proof system.

Pros: Once translation is done for a “curve agnostic” hash function, then it can be re-used for multiple proofs system → multitude of proof systems/curve available at once

Cons: extra cost for SP that needs to do this intermediate step, “2 proofs” instead of 1 per sector now.

3. New Vector Commitment: Changing proof system and curves also allows us to change vector commitment at the same time ! Depending on which VC we use the translation cost may be acceptable !

Challenges:

• Number of leaves to open on the sector: 3000 !
• Bit Sizes: challenge is to embed the data inside another scalar field of the other curve. We need 255 bits however the major curves out there are 252 or 254 bits !
• Non Native / Common inputs: We need to make sure the same data are input to both proof system , there needs to be a “link” between the two !

Overview

Ongoing exploration code repository Embed GitHub

Cost of Poseidon hashing in Filecoin

Using Poseidon Natively:

8-arity Hash = 565 constraints

Detailling all additions / multiplications:

The following describes the number of field additions and multiplications one needs to do to evaluate a poseidon with 8 arity without optimizations.

Field additions  = 5850
Field multiplications  = 5652

Cost of translation proof

One needs to realize on the order of 3000 merkle tree inclusion proofs on both curves.

Each inclusion proof on the current Filecoin system (curve and setting) is about 10 * 8-arity Poseidon hashes.

In total, we can say a translation proof requires at least evaluating 30k 8-arity Poseidon hashes + the cost of 3000 “inclusion proof” on the other proof system.

Current Solutions