Replace big.Int with uint256.Int #582

New issue

Open

opened 2025-12-28 17:13:39 +00:00 by sami · 3 comments

sami commented

2025-12-28 17:13:39 +00:00

Owner

Originally created by @roman-khimov on GitHub (Dec 1, 2020).

There is a promising library that we could reuse for our integer types (both in VM and native contracts): https://github.com/holiman/uint256. We need to try it out, benchmark and compare with our current implementation.

Originally created by @roman-khimov on GitHub (Dec 1, 2020). There is a promising library that we could reuse for our integer types (both in VM and native contracts): https://github.com/holiman/uint256. We need to try it out, benchmark and compare with our current implementation.

sami added the

enhancement

performance

dependencies

labels

2025-12-28 17:13:39 +00:00

sami commented

2025-12-28 17:13:39 +00:00

Author

Owner

@roman-khimov commented on GitHub (Dec 15, 2022):

For the first iteration we need to try keeping public RPC interfaces with *big.Int types, but use uint256 in the VM, full compatibility is important here. Then benchmark it with VM tests we have (Bench*) and neo-bench (of course unit tests must work too). Then we'll see if it's worth it, if yes, we can gradually expand usage of this type in other places.

@roman-khimov commented on GitHub (Dec 15, 2022): For the first iteration we need to try keeping public RPC interfaces with `*big.Int` types, but use `uint256` in the VM, full compatibility is important here. Then benchmark it with VM tests we have (`Bench*`) and neo-bench (of course unit tests must work too). Then we'll see if it's worth it, if yes, we can gradually expand usage of this type in other places.

sami commented

2025-12-28 17:13:39 +00:00

Author

Owner

@ZhangTao1596 commented on GitHub (Feb 16, 2023):

For the first iteration we need to try keeping public RPC interfaces with *big.Int types, but use uint256 in the VM, full compatibility is important here.

You mean we use uint256 inside evm but big.Int in arguments of evm public methods?
What about util.Uint256?

@ZhangTao1596 commented on GitHub (Feb 16, 2023): > For the first iteration we need to try keeping public RPC interfaces with `*big.Int` types, but use `uint256` in the VM, full compatibility is important here. You mean we use `uint256` inside evm but `big.Int` in arguments of evm public methods? What about `util.Uint256`?

sami commented

2025-12-28 17:13:39 +00:00

Author

Owner

@roman-khimov commented on GitHub (Feb 16, 2023):

util.Uint256 is just a fancy way to represent "big" (compared to Uint160) hash. See neo-project/neo#938 also. For numbers that are real numbers (in that they're used for some arithmetic operations) we use *big.Int now mostly. uint256 library is supposed to be faster, but many of our interfaces rely on big.Int and we can't just throw it away, hence the requirement to keep these interfaces for now, exploring how uint256 can help us at the same time (there are some benchmarks in the vm code).

@roman-khimov commented on GitHub (Feb 16, 2023): `util.Uint256` is just a fancy way to represent "big" (compared to Uint160) hash. See neo-project/neo#938 also. For numbers that are real numbers (in that they're used for some arithmetic operations) we use `*big.Int` now mostly. `uint256` library is supposed to be faster, but many of our interfaces rely on `big.Int` and we can't just throw it away, hence the requirement to keep these interfaces for now, exploring how `uint256` can help us at the same time (there are some benchmarks in the `vm` code).