[feat] Add support for Twisted Edwards Curves into the elliptic curve VM extension

[Avaneesh-axiom]

Primary change:

• Added a chip that adds two Twisted Edwards curve points and also implements a setup instruction. This chip is built using the mod-builder framework
• The setup instruction checks that the modulus is correct and the coefficients a and d from the equation of a Twisted Edwards curve are correct
• The chip's constructor checks that a is a quadratic residue and that d is not a quadratic residue. This property of a Twisted Edwards curve ensures that the addition operation is the same for all input points
• Added the Ed25519 curve to the guest library for ease-of-use

Related changes:

• Updated the mod-builder framework to handle setup rows that verify more than one constant
• Updated the mod-builder framework to the new method of padding rows. That is, by using a temporary range checker and constructing a dummy row (see fix: EcDoubleChip dummy row #1239)
• Updated the doubling chip for Weierstrass curves to use the updated mod-builder framework
• Changed the CurveConfig struct to accommodate for curves in Twisted Edwards curve form
• Updated the OpenVM book to explain how to use twisted Edwards curves

Closes INT-2999

[jonathanpwang]

we got rid of num-bigint-dig, let's only use num-bigint from now on

[Avaneesh-axiom]

num-bigint-dig has jacobi symbol computation while num-bigint doesn't. I'll try to replicate it with num-bigint

[Avaneesh-axiom]

I need jacobi symbol for checking if a is QR and d is not QR for completeness

[jonathanpwang]

hm... that is really unfortunate (I don't want two bigint crates, and num-bigint-dig is less maintained than num-bigint) let me investigate

[Avaneesh-axiom]

I forgot to update you, but I have removed the dependency on num-bigint-dig. I copied over the jacobi symbol code into extensions/ecc/circuit/src/edwards_chip/utils.rs

[Avaneesh-axiom]

FYI: I added some more changes that fix a bug that I found (weierstrass and edwards opcodes would overlap in some cases)

I also added decompression hints (just like for weierstrass) to the edwards curves since I will use it in eddsa

[Avaneesh-axiom]

Update: rebased onto develop

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	(-14 [-1.1%]) 1,268	334,142	17,677,298	-	-	-
fibonacci_program	(+45 [+1.7%]) 2,729	1,500,277	50,589,503	-	-	-
regex_program	(-125 [-1.5%]) 8,048	4,165,226	166,511,152	-	-	-
ecrecover_program	(+17 [+1.2%]) 1,425	289,447	14,470,186	-	-	-
pairing	(-5 [-0.1%]) 4,901	1,820,436	95,832,407	-	-	-

Commit: 9a1c396

Benchmark Workflow

[jonathanpwang]

oudated comment

[jonathanpwang]

I can see it's easier to say "ECC Extension" but here I feel like we could have done WeierstrassExtension and TwistedEdwardsExtension as two separate structs. I don't have strong feelings either way

[jonathanpwang]

another option is to keep a single vector but use enum to specify different curve types within CurveConfig. That seems like a might be a little nicer ux wise?