UInt256 long digits record

[thomas-quadratic]

PR description

This PR cumulates a few improvements/refactoring for UInt256 modular arithmetics:

• digits (limbs) are big-endian ordered.
• digits use longs rather than ints as primitive type.
• UInt256 is a record storing its digits as fields rather than in an array.
• division algorithm follows methods from the GMP division paper since widening from long is not possible.
• fromBytesBE is improved to give better performance on worst cases.

Long limbs are more efficient because they divide by 2 the number of digits, thus reducing the number of steps in arithmetics operations. However, it complexifies the implementation for division as widening is not possible anymore. Fortunately, quotient estimates algorithms that avoids widening exists, see division paper.

Records are chosen to represent fixed-width UInt256 because of potential future support for Vahalla value records, which would require almost no change to the code.

Here are the benchmarks compared to the actual implementation:

Operation	Case	current (ns/op)	new (ns/op)	gain (%)
Mod	FULL_RANDOM	106.042	84.005	21%
Mod	WORST	149.179	95.7	36%

Current status

Currently working and tested ops:

• AddMod
• Mod
• MulMod
• SMod

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[thomas-quadratic]

Updated benchmarks with the new commits that support the other operations: AddMod/MulMod/SMod

Operation	Case	current (ns/op)	new (ns/op)	gain (%)
Mod	FULL_RANDOM	106.042	84.005	21%
Mod	WORST	149.179	95.7	36%
SMod	FULL_RANDOM	141.778	101.1	29%
SMod	WORST	170.822	101.1	41%
AddMod	FULL_RANDOM	179.559	137.073	24%
AddMod	WORST	187.805	137.073	27%
MulMod	FULL_RANDOM	259.265	186.501	29%
MulMod	WORST	344.663	222.37	41%

[thomas-quadratic]

Changing single digit quotient estimates using 3 digits by 2 digits (div3by2) to 2 digits by 1 digit (div2by1).
Improved benchmarks across the board:

Operation	Case	current (ns/op)	new (ns/op)	gain (%)
Mod	FULL_RANDOM	106.042	81.032	24%
Mod	WORST	149.179	86.942	42%
SMod	FULL_RANDOM	141.778	97.15	31%
SMod	WORST	170.822	97.15	43%
AddMod	FULL_RANDOM	179.559	130.147	28%
AddMod	WORST	187.805	130.147	31%
MulMod	FULL_RANDOM	259.265	177.442	32%
MulMod	WORST	344.663	209.105	39%

[siladu]

Code review

Found 1 issue:

1. UInt512.isUInt64() uses bitwise AND (&) instead of OR (|) to check if all high limbs are zero. With AND, the expression (u7 & u6 & u5 & u4 & u3 & u2 & u1) == 0 can return true even when multiple high limbs are non-zero, as long as they don't share a common bit (e.g., u7=1, u6=2 gives 1 & 2 = 0). This causes incorrect results in Modulus64 arithmetic shortcuts (addMod, mod, mulMod) that rely on this check. The correct operator is |, consistent with UInt256.isUInt64() at line 295 which already uses (u1 | u2 | u3) == 0.

https://github.com/hyperledger/besu/blob/d86a15e7a7a9e3441d2d85ef4f96a4dc58413519/evm/src/main/java/org/hyperledger/besu/evm/UInt256.java#L941-L944

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[siladu]

Code review

Found 1 issue:

1. UInt512.isUInt64() uses bitwise AND (&) instead of OR (|) to check if all high limbs are zero. With AND, the expression (u7 & u6 & u5 & u4 & u3 & u2 & u1) == 0 can return true even when multiple high limbs are non-zero, as long as they don't share a common bit (e.g., u7=1, u6=2 gives 1 & 2 = 0). This causes incorrect results in Modulus64 arithmetic shortcuts (addMod, mod, mulMod) that rely on this check. The correct operator is |, consistent with UInt256.isUInt64() at line 295 which already uses (u1 | u2 | u3) == 0.

Unit test showing bug here https://github.com/thomas-quadratic/besu/pull/5/changes

[lu-pinto]

No need for doing computation of a constant number here:

Suggested change

	long v2 = (v1 << 13) + ((v1 * ((1L << 60) - v1 * x40)) >>> 47);
	long v2 = (v1 << 13) + ((v1 * (0x1000000000000000L- v1 * x40)) >>> 47);

I you want maybe just a static constant just above reciprocal method would do as well

[lu-pinto]

I'm running a hoodi sync just as a smoke test. will merge when that succeeds

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.