Solidity compiler approach

[PaulRBerg]

Two possibilities:

1. Fork Solidity to implement our bake the SabVM into the compiler itself
2. Precompiles that implement the new opcodes alongside an enshrined library that allows users to operate them

At Devconnect 2023, I spoke with two Solidity core devs (Hari and Alex) about Sablier V3, and they have strongly advised us against the 1st approach and in favor of the 2nd approach.

A PoC for the 2nd approach:

contract MyContract {
    using Sablier for address;
    
    function foo(address sender, address recipient, uint256 amount_per_second) external {
        sender.createStream(recipient, amount_per_second);
    }
}

Finally, a demo from our V3 slides:

Cc @IaroslavMazur

[IaroslavMazur]

So, instead of incorporating the new opcodes introduced in SabVM directly into Solidity (which would, arguably, require a separate team of people to implement and maintain), create - at SabVM's genesis - some Solidity contracts (the precompiles) "exposing" the SabVM-specific opcodes in the form of "regular" (on the surface) Solidity contract functions. Any other contract on the SabVM chain will be able to call those functions, as if they are Solidity language instructions/functions.

Under the hood, however, because SabVM would have a special relationship and work directly with those precompiles, whenever one of those opcodes-exposing functions from inside the precompile contracts is called, the VM would interpret that as a trigger - and, instead of the actual Solidity code inside those functions (which could just as well be empty, if my understanding is correct), run the predetermined, VM-level logic that, essentially, implements the respective opcode.

Have I got the idea correctly?

---

Side question: for the existing Solidity compiler to be compatible with the SabVM contracts, must the precompile function calls be performed just like any other contract call, with the address of the contract specified alongside the function signature and whatnot?

If yes, then, it doesn't sound too developer-friendly, as every SabVM contract wanting to access the SabVM-specific features/opcodes would need to manually "import" the information about what the precompile functions signatures - and where to call them from.

Ideally, all this knowledge would somehow be inherited by all of the contracts automatically. However, I don't know how/whether this could be arranged without changing the Solidity compiler 🤔

[PaulRBerg]

directly into Solidity

A fork of Solidity*

the form of "regular" (on the surface) Solidity contract functions

Not "on the surface". They would be actual Solidity libraries.

Any other contract on the SabVM chain will be able to call those functions

Yes

as if they are Solidity language instructions/functions

No. Only if the consumer contract imports the appropriate interfaces from the enshrined library.

the actual Solidity code inside those functions (which could just as well be empty, if my understanding is correct

It may be empty, but I'm not sure. More research is required.

Have I got the idea correctly?

Kind of. It would be easier to discuss on a call.

---

must the precompile function calls be performed just like any other contract call, with the address of the contract specified alongside the function signature and whatnot?

Yes, but this is primarily a question of developer experience, which we can address by hard-coding the addresses in a library, for example.

it doesn't sound too developer-friendly, as every SabVM contract wanting to access the SabVM-specific features/opcodes would need to manually "import" the information about what the precompile functions signatures

Everybody using the SabVM would find out about it via our official docs website, which would contain quickstarts and other such helpful guides.

So we can make the developer experience OK (not bad, but not great).

Anyway - there isn't any other alternative because the cost of forking Solidity is prohibitively high.

all this knowledge would somehow be inherited by all of the contracts automatically

Not possible

[IaroslavMazur]

A fork of Solidity*

Yeah, that's what I meant. Thanks for the correction!

---

Kind of. It would be easier to discuss on a call.

Agreed.

---

must the precompile function calls be performed just like any other contract call, with the address of the contract specified alongside the function signature and whatnot?

Yes, but this is primarily a question of developer experience, which we can address by hard-coding the addresses in a library, for example.

Hiding the addresses behind a library sounds good. If there are going to be multiple addresses to hide, that is.

The library, itself, would still need to be accessed/imported by the SabVM contracts by explicitly specifying its address, would it not?

---

Everybody using the SabVM would find out about it via our official docs website, which would contain quickstarts and other such helpful guides.

Yes, naturally.

I was just saying that it'd be very nice to have the SabVM-specific functionalities/opcodes available "directly" - and not requiring developers to go the extra mile of "bringing" them into the scope of their contracts. Especially given that they'll all be doing the very same thing, for each of their contracts requiring the said functionalities.

[PaulRBerg]

would still need to be accessed/imported by the SabVM contracts by explicitly specifying its address, would it not

Yes. But the address can be hard-coded into a constant. See the Blast references below.

[PaulRBerg]

Closing this as outdated in favor of #86.

[PaulRBerg]

Interesting story of how Optimism used to have an OVM and a Solidity transpiler, which was ultimately ditched as a result of a happenstance of meeting George Hotz, who had found a way to get rid of the transpiler and in effect enable EVM equivalence:

https://x.com/jinglejamOP/status/1310718738417811459?s=20

[PaulRBerg]

More context from Georgios:

They used the OVM which basically was a mod on the EVM to allow it to be fraud-proofable, but had significant downsides because it required maintaining a fork of Solc among other things.