Use XFri from twenty-first instead

[Sword-Smith]

Why doesn't it just share the xfri that lives in twenty-first?

[sshine]

TritonVM at one point had a Fri<BWord> and a Fri<XWord>, but now it only has a Fri<XWord>, i.e. an XFri.

So there is no good reason why it shouldn't just share xfri from twenty-first again.

One refactor was to pull out FriDomain into its own file.

• Delete triton_xfri and import twenty_first::xfri instead.
• Delete fri_domain and import twenty_first::xfri_domain.

[sshine]

There is a reason: Since FRI shares proof-stream with STARK, the ProofItem type is shared between them. For that reason, a Fri<PF> currently cannot be shared between STARKs. Replacing the proof-stream type (Neptune-Crypto/twenty-first#24) in the process of verifying a partial authentication paths (part of #7) makes it much easier to use a shared Fri again.

[aszepieniec]

I think FRI is an integral component to the STARK engine and therefore belongs in the Triton-VM repository. It is quite likely that we want to tweak and optimize particular features of FRI, and applying those tweaks and optimizations to twenty-first seems like a cumbersome workflow.

Other STARKs that also use twenty-first for algebra routines or crypto need to come with their own FRIs. I think that is an acceptable level of code duplication.

[Sword-Smith]

Other STARKs that also use twenty-first for algebra routines or crypto need to come with their own FRIs. I think that is an acceptable level of code duplication.

We are not going to write new FRIs for existing (previous) STARK implementations. We have two STARK implementations working (Rescue Prime and Brainfuck) and we shouldn't waste time hacking on those. They are fine as they are.

[aszepieniec]

• Triton-VM can have its own implementation of FRI
• Let's not waste time hacking previous STARK iterations