perf: normalize the random linear combination in logderivarg

[kustosz]

Description

Sets the first coefficient for random linear combinations in the logderiv argument to 1. This should not affect soundness  (the attacker still cannot abuse any relationship between the coefficients), but it shaves off a constraint from table lookups – in the most basic case we go from 3 constraints down to 2.

Idea by @ivokub, soundness arguments may need to be refined.

Type of change

• Perf improvement

How has this been tested?

• run go test ./...

How has this been benchmarked?

Run this before and after:

type TestLookup struct {
	In frontend.Variable
}

func (c *TestLookup) Define(api frontend.API) error {
	table := logderivlookup.New(api)
	for i := range 256 {
		table.Insert(bits.RotateLeft8(uint8(i), 3))
	}
	c0 := c.In
	for range 256 {
		c0 = table.Lookup(c0)[0]
	}
	api.AssertIsEqual(c0, c.In)
	return nil
}

func main() {
	ccs, _ := frontend.Compile(ecc.BN254.ScalarField(), r1cs.NewBuilder, &TestLookup{})
	fmt.Printf("constraints: %d\n", ccs.GetNbConstraints())
}

Output goes from 1687 to 1100

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• [?] golangci-lint does not output errors locally - it output a bunch of errors, but none near my changes
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[ivokub]

LGTM! Thanks for the contribution!

Seems sound and @ThomasPiellard has also confirmed.