all: use uint256 in state

[holiman]

This change makes use of uin256 to represent balance in state. It touches primarily upon statedb, stateobject and state processing, trying to avoid changes in transaction pools, core types, rpc and tracers.

Addresses #28578

Some notable differences:

• A big.Int spits out the decimal form, in String() and MarshalJson etc, whereas uint256.Int spits out hex-form. This caused a few failures in the tracer-engine, since the bignum js did not expect to parse hex. It also causes a test-failure in TestIterativeDump due to output format change. I'm not sure if we should fix these, or if we should instead switch uint256.Int over to default to decimal output over hex, to maintain compatibility with big.Int. (See conversion: behavioural changes in String, MarshalText and MarshalJSON holiman/uint256#144)

For reviewers

• All production-code changes are in the first commit.
• The remaining commits are only changes to _test files (or utilities for use in testing, e.g. /tests/)

There are some subtleties to be aware of. Consider the following example:

func VerifyThingy(value *big.Int) (uint64, error){
    value.Add(value, value) // <-- Can overflow with uint256
    if !value.IsUint64(){ // <-- Overflow makes it so that it now fits into 64 bits, and no error is emitted 
        return errors.New("Oh no goes above 64 bits")
    }
    return value.Uint64(), nil
}    

The code above is perfectly fine with big.Int, but as soon as we switch to uint256.Int, the code is buggy. The reason for this is that Add, Mul and Sub in big.Int are lossless, whereas they are lossy in uint256.Int. Therefore, we need to ensure that in all places where it matter, the second return-value from these operations, overflow, is checked.

And to be extra clear: the github diffview may hide the place where this type of error sits, since the diff is far away from where the bug is.

[MariusVanDerWijden]

Suggested change

	U2560 = uint256.NewInt(0)
	U256_0 = uint256.NewInt(0)

[holiman]

Yeah, I did that originally. But my editor went ahead and changed it. I think there might be something special about numerics and underscores.

[holiman]

This is going to bitrot. Please review. I'd say that the most important parts to check are :

• state_transition.go
• instructions.go
• evm.go
• transaction pool validations
• Checking if there are any generated files that I have missed to regenerate

[MariusVanDerWijden]

This can not overflow because mgval is guaranteed to be <= balanceCheck and we check that balance check does not overflow

[MariusVanDerWijden]

LGTM, I had some questions/clarifications but I think the PR is good to go

[holiman]

I think the PR is good to go

Thanks! I am pushing a change re the stack pushes though

[itsdevbear]

this PR brings me so much joy inside

[fjl]

I think this is kind of lazy here. Should we just compute the expected value as uint256 as well and then compare?

[holiman]

If we do it in big.Int, then the test can simply do the calculations, and not worry about overflows or negatives. You might call it lazy, but on the other hand, it means that the test becomes less encumbered with overflow spot-checks.

All in all, I think it's better the way it is (I started changing it, and didn't find the changed code to be an improvement)

[fjl]

I wonder if we should use non-pointer uint256.Int to represent the balance. That way, we could save a lot of new() calls and rely on implicit copy. It might even reduce allocations during state transition.

[holiman]

I wonder if we should use non-pointer uint256.Int to represent the balance.

Yeah, that might be a good idea. Maybe I'll do a follow-up commit, and if it becomes too large, I'll put it into a separate PR

[rjl493456442]

Deployed in on bench6 for a full sync, just to ensure nothing broken.

[shidaxi]

.