Why not fork/built on top of FuelVM

[razgraf]

We've decided to build on top of the EVM as an execution-layer, using a Reth fork under the hood. From time to time, on the topic of VMs, Fuel came up as a potential solution to build on top of.

For future context, why did we end up going for an EVM fork rather than a FuelVM one?

[PaulRBerg]

It's a good question. There are many reasons for why I have decided against forking FuelVM:

1. Their UTXO design simply does not work for streaming opcodes. An account model is needed.
   • They have shared a proposal for UTXO-based streams, which I have criticized a long time ago. They have never responded to my criticism (also see the Sablier <> FuelTelegram group).
2. They're not on Mainnet. If we had chosen FuelVM, we would have added another experimental dimension to SabVM.
3. It becomes increasingly obvious that the underlying VM is not as critical as the raw computational cost of real-time graph traversals.
4. We have 57k users and 10k+ MAUs (and counting) in the EVM ecosystem.

[razgraf]

Isn't concern number 3 somewhat linked to concern number 1: if we create new rules for streaming, new storage slots for stream-related states and so on, does Fuel's base UTXO model still interfere?

On point number 4, the current user-base is important for the EVM ecosystem. But SabVM will not be 1:1 with the EVM anyway (at least it will be discouraged in some cases). We ask users to port to an entirely new ecosystem anyway, so they still need to acquire some knowledge be it for SabVM or for FuelVM underneath.

Completely agree on adding too many layers/dimensions of uncertainty/complexity, which may simply be the primary reasons we don't want to experiment with Fuel at the moment.

Also, we've already made progress with Reth and the EVM for Sablier Mainnet - meaning we wanna continue down this path for the time being.

Note: I bring this up also because lots of discussion we've been having were informed by choices or ideas Fuel evangelized, so the question of "why not just go with them" felt natural.

[PaulRBerg]

I don't understand the first paragraph. Perhaps more details on why UTXOs don't work for streaming would help:

To be able to update a balance in real-time, you need to let nodes edit it over time. With UTXOs, you would have to have nodes rescind UTXOs on behalf of users, and recreate others on the fly. However, that defeats the purpose of having UTXOs in the first place. "Unspent" means that it hasn't been spent, but with the SabVM, the VM can technically spend stuff for you. Can you imagine how awkward it would be to have a tx in the mempool that is then voided because the UTXO that you want to use has been spent by an existing stream of yours?

SabVM will not be 1:1 with the EVM anyway

So what? This ain't a black-and-white thing. We will be mostly EVM compatible. That's a good enough reason to build on top of the EVM, where our existing users are.

ask users to port to an entirely new ecosystem anyway

It's not 'entire' new.

we've been having were informed by choices or ideas Fuel evangelized,

It was just the MNTs that we inspired from Fuel so far. The streaming opcodes are a 100% Sablier invention, alongside many other ideas in this discussion forum, e.g., the Complexity Factor).

Fuel has an interesting vision for modular configuration of rollup deployments that I would like to use for Sablier too, someday, but that's a conjecture that is yet to be tested in their own ecosystem.

[razgraf]

Thank you for explaining, agree that race-condition for UTXO management sounds like a no-no.

[PaulRBerg]

It is worth nothing that last year, I did some work trying to add the streaming opcodes to the FuelVM.

• https://github.com/sablier-labs/v3-specs-fuel
• https://github.com/sablier-labs/v3-specs-fuel/commit/e2a95a8b7a4e451556ad324ff869d5d33223ddee