feat: Wrap eth::U256 into a type

[sunce86]

Problem

Default serde implementation for U256 type encodes/decodes in hexadecimal format, while we always want to use decimal format. We need to make sure that every time we use U256, we add an annotation #[serde_as(as = "serialize::U256")] to the field.

This has been forgotten numerous times, cf #2075, #1958, etc...

Suggested solution

Wrap U256 in its own type that implements default serialization using HexOrDecimalU256.

Additionally, investigate if there is a way to forbid using raw U256 in our system (with clippy or something similar) so we don't accidentally continue to U256 instead of our own type.

[duguorong009]

@sunce86
Can I pick the issue?

[duguorong009]

@sunce86 @fleupold
Sorry, but I think I can't resolve the issue.

I've tried several times, in order to implement the suggested solution.
But, unfortunately, I didn't manage to finish it.
The reason is that the codebase is HUGE(at least for myself), and
the introduction of new wrapper type brings too many updates which I can't handle.

From my side, I think it is better way that the team should be more diligent when reviewing the PR which includes U256 type.
Or, hopefully, another guy can resolve this issue as you expect.

[MartinquaXD]

Thanks for trying, though.
I think the biggest problem is probably that in the orderbook and autopilot we use the same types that define the API and the deserialization behavior in the business logic. This makes any change to the API type also a change to the business logic which is as you pointed out quite a lot.
We didn't make this mistake in the driver and solvers crates so there it should be a reasonably small change.
In the medium term future we should probably apply the same pattern to the orderbook and autopilot so we can easily change the deserialization without affecting the whole code base.

[cakevm]

Hey, I just like to mention that there has been some developments in the Rust ecosystem for EVM-based chains with alloy-rs as the new kid on the block. I also saw that ethcontract-rs hasn’t received many updates over the past year.

Have you maybe considered switching to the Alloy type system to potentially improve the issue mentioned above?

Potential benefits:

• No need for custom serialization to/from hex string for byte types (e.g., U256, FixedBytes<56>, ...)
• Less code and no custom serde_as implementations required
• Active maintenance and support standard types and other related things e.g. postgres
• No need for a contract instance to build call data
• Maybe potential performance improvements? (consistent serialization/deserialization implementation for hex strings)

You can find an example here: https://github.com/cakevm/cowprotocol-solvers-dto-alloy (Please be aware it has maybe some rough edges)

I also like to mention that Alloy is moving quite fast forward and the API was now stable for the last months, but maybe this will change.

If you are interested maybe I can support with a step-by-step transition.

[tsmahdy]

Hey cakevm 👋

Thank you for sharing these cool insights. We really like your approach!

We’d love to explore ways to collaborate further and discuss your ideas in more detail. How about we arrange a quick call? Would it be okay if I email you at [email protected], or is there another contact method you prefer?

Looking forward to hearing from you!

[cakevm]

Great to hear, feel free to send me an email.