Discussion On Upstream The Sui Fork From Belobog/Movy

[wtdcode]

Hey Sui Maintainers, I'm one of the builders of the Belobog, a type-guided efficient Move fuzzing framework that finds bugs and reproduces real-world incidents of millions of dollars. We also posted a paper for review.

I'm wondering if we could have some collaboration from the Sui team because our fork has reached a state that is really hard to maintain. Each time I fork, the pain gets much stronger.

Our main fork is here. Since my changes touch lots of core move modules, it is unlikely to be accepted by standalone pull requests from what I've learned. Therefore, I would like to have a discussion with the maintainers to understand how these changes could be accepted in a safe way. I believe the collaboration helps make the Sui ecosystem much safer because our tool could test Move smart contracts much more thoroughly.

[github-actions]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui support and do not click on any links!

[wtdcode]

Pinging a few people that might be related.

@amnn
@stefan-mysten
@tnowacki
@tzakian

[amnn]

Hi @wtdcode, thanks for enquiring!

Could you share a breakdown of the changes in your fork that you think should be upstreamed, and the motivations for those? That will help us involve the right people to review suitability (I did also take a quick look at the fork, but it's a little difficult to make out what the permanent vs temporary changes are).

[wtdcode]

I can group my changes by the features of Belobog/Movy but in general I would emphasize that many changes we proposed are shared/depended across the modules of Belobog/Movy.

Symbolic/Concolic Exceution - This allows exploration of the deep state of various contracts. Think about the DEX liquidity math checks.

• Do emit Bytecode instead of String #22817 Actually, this is the very basic changes we need for all components because we need to precisely know the instruction we are tracing. We also would like Bytecode to be serde
• Make Stack available to tracers #23021 and ad1136d This allows us to access dynamic runtime values by exposing the stack.
• f158e70 this one is optional but would be much appreciated because it provides additional type information, in this case, the number of the fields.

Better Tracing - Current tracing is way too slow for any efficient fuzzing.

• Loose the lifetime constraints of the MoveTraceBuilder #22909 This allows us to have much flexible tracer like using a &'a mut T where T: Tracer.
• 5c68164 This is very huge, generally to achieve a zero-overhead tracing by not emitting any unnecessary events. This also disables redirecting events to the Writer so that we have 150X performance boost! Execution speed is very crucial for fuzzing.
• Small changes that I think is harmless: 58e6236 eead41b 58f5554

Changes that no longer needed and can be closed: #22802 (superseded by GraphQL service) #22928 (superseded by gRPC service)

The end_transaction Native Changes - This allows us to fetch effects and changes after end_transaction. Honestly, I do think its original design is problematic in two ways: 1) it relies on a native context that must hold a InMemoryTestStore or else it panics, though it is only used in unit test runners 2) it should not take the object state away because that breaks the invariants of the Sui executor.

• bed1a23 This one is very hybrid and a bit chaos I would admit. The motivation is to preserve the effects and object changes after the end_transaction called by testing_scenario. To help understand the motivation, see our docs here: https://docs.movy.rs/fuzz_tutorial. In short, we allows users to write invariants as a Move module, inspired from foundry

A few additional words:

As an EVM builder, I would expect the Move tracing interface like https://github.com/bluealloy/revm/blob/main/crates/inspector/src/inspector.rs#L17-L123 i.e. zero-overhead and clean.

[amnn]

Got it -- thanks for the summary @wtdcode. It sounds like a lot of this is related to tracing infrastructure, so @tzakian is a good person to involve.

Many people are out until the new year, at the moment but maybe in the new year we can set up some time for you to meet with the Move core and/or tooling teams to discuss what you're trying to achieve and your experience with the tools so far, then moving into potential changes to upstream. It's possible/likely that the team has other ideas about the best way to support fuzzing on top of the existing infra.

[wtdcode]

Thanks for the information, and let me know any updates. My will is to make the Move ecosystem much safer =).