Rename REVM to SabVM

[PaulRBerg]

Very low-priority task, but as we get closer to launching, it should be helpful to rename REVM to SabVM to hint at the fact that this is a different implementation.

[PaulRBerg]

Is this actually worth it?

On second thoughts, this rename would introduce a lot of technical debt. Rebasing would become much more difficult.

WDYT @IaroslavMazur?

[IaroslavMazur]

this rename would introduce a lot of technical debt. Rebasing would become much more difficult.

Performing the renaming prematurely would, indeed, lead to multiple git conflicts, anytime the symbols we've renamed have, e.g., been:

• used/referenced in a new place in the codebase,
• stopped being referenced somewhere
• etc.

At the same time, I believe we should definitely do this before launching the Genesis version and making the repo public. Even if syncing the repo with any new revm development from then on becomes more complicated.

[PaulRBerg]

Hmm I disagree even after Genesis.

I suggest renaming it only after we hit some meaningful milestone, e.g. 1000 DAUs.

[IaroslavMazur]

What I was thinking about is that it wouldn't be good PR if our product calls itself internally using the name we've forked the codebase from.

Reminds me of how different companies sub-contract some 3rd-world countries, re-selling their very product under a new name, by putting a new logo in front of the customer.

This is an extreme example, of course, but the potential git conflicts sound like a reasonable price to pay to avoid the PR such as the above.

[PaulRBerg]

In this context, security and low maintenance costs are significantly more important than PR. Consider that refactoring revm to sabvm would increase the diff between our repo and the upstream revm repo, which would make auditing SabVM more difficult.

PR is overwhelmingly dictated by what we say on our social media, blog posts, Telegram groups, etc. It's barely influenced by the VM implementation repository.

Relevant example - Optimism has chosen the very approach I'm advocating for here:

• Configuring op-geth: : https://docs.optimism.io/builders/node-operators/configuration/base-config#configuring-op-geth
• Diff between geth and op-geth: https://op-geth.optimism.io/

[PaulRBerg]

@IaroslavMazur if you have changed your mind, could you please confirm so that we can close this discussion as resolved.

[IaroslavMazur]

Optimism has chosen the very approach I'm advocating for here

Oh, wow!

If even the Rollup of the size of OP prioritized minimizing the differences with the forked source code, then, I agree that we should follow the suit.

Closing this discussion as resolved.