feat: support uint256 for rlp, log, hex, vm, abi

[tnasu]

Proposed changes

Support uint256 for RLP, Hex, etc. These changes also help to update EIP-7702, which uses uint256

Types of changes

Please put an x in the boxes related to your change.

• Bugfix
• New feature or enhancement
• Others

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING GUIDELINES doc
• I have read the CLA and signed by comment I have read the CLA Document and I hereby sign the CLA in first time contribute
• Lint and unit tests pass locally with my changes ($ make test)
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Related issues

• Introduce EIP-7702 (Set EOA account code) #106
• feat: Update KIP-228 (EIP-7702)  #216

Further comments

[ulbqb]

Why is this needed? Doesn't the other txs use uint256?

[tnasu]

@ulbqb

Doesn't the other txs use uint256?

What are the other txs? If the other txs isn't SET_CODE_TX(EIP-7702), then there is no plan to use uinit256 for the other txs. If we want to use uint256, we should support uint256 like this PR.
On the other hand, I can also say this PR isn't needed since we can use big.Int instead of uint256.

But, I think using uint256 is popular usage in Geth and the others since it is better performance than big.Int. Why don't we use it?

What is your opinion?

Thanks

[ulbqb]

On the other hand, I can also say this PR isn't needed since we can use big.Int instead of uint256.

I see. I was curious about if type 1 or 2 have already used uint256 fields. IMO, uint256 should be applied for the other txs unless there is huge impact. If it will be done by geth, there is no reason why we don't apply.

[tnasu]

@ulbqb

I was curious about if type 1 or 2 have already used uint256 fields

We don't use uint256 for existing transaction types because of need this PR.

uint256 should be applied for the other txs unless there is huge impact

It's hard to say whether it has a huge impact or not. I'm making this PR by searching Geth PRs. It's hard to introduce using uint256, and we have to maintain related uint256 after merging this PR.
https://github.com/search?q=repo%3Aethereum%2Fgo-ethereum+uint256++is%3Amerged&type=pullrequests&p=1

If it will be done by geth, there is no reason why we don't apply.

Geth is using uint256 for txs after blob_tx. The other txs are using bigInt

• https://github.com/ethereum/go-ethereum/blob/master/core/types/tx_blob.go
• https://github.com/ethereum/go-ethereum/blob/master/core/types/tx_setcode.go