Spec for Solidity fork

[PaulRBerg]

Context

I wrote a minimal spec for a SabVM-specific Solidity fork in this discussion. I am extracting the spec here so we can maintain and develop it separately as more ideas come to mind.

Spec

Native Tokens

• Transaction Properties
  • msg.token_ids: array of uint256 IDs
  • msg.token_amounts: array of uint256 values transferred
• Members of Address
  • Transfer syntax: <address payable>.transfer_tokens(uint256[] token_ids, uint256[] token_values) (name TBD, the idea is to distinguish from the existing .transfer)
  • Call syntax: <address payable>.call{ token_ids: [1, 2], token_values: [36, 144)}(data)
• Receive Functions
  • receive(uint256[] calldata token_ids, uint256[] calldata token_values)
  • fallback(uint256[] calldata token_ids, uint256[] calldata token_values)

Streams

• Transaction Properties
  • None, because unlike one-time transfers, streams cannot be started when calling a method on a contract
• Members of Address
  • <address>.stream_create
  • <address>.stream_update
  • <address>.stream_delete
• Callback Functions
  • TBD

TODO

• Do we want to keep supporting .send and .transfer for ETH transfers?
• payable keyword - what to do with it?

References

• Solidity Docs: Block and Transaction Properties
• Solidity Docs: Receive Ether Function
• Solidity Docs: Members of Address
• Solidity by Example: Sending Ether
• Superfluid Docs: Callbacks

[IaroslavMazur]

However, we cannot fork Solidity due to the reasons given here.

Considering what you said here, it's not clear to me what the motivation for having this discussion is.

Do you think the reasons outlined above might change in time?

[PaulRBerg]

1. It's research. We can never know when going on off tangents like this can be helpful for the final product.
2. We might end up forking Solidity and using it for testing purposes, even if we don't intend to use the fork in production and/or allow users to access it.

[IaroslavMazur]

I see. Thank you for explaining!

[PaulRBerg]

Relaying a comment left by @IaroslavMazur on Notion on January 27:

Similar to how we will provide contracts with access to the SabVM-specific functionalities (discussed in Solidity compiler approach #55), how about we let the contracts “subscribe” (normally, just at creation time) to the respective events?

The callbacks would be exposed by implementing a certain SabVM-specific interface with the required function signatures (e.g. streamCreationHandler(), streamClosureHandler(), etc.). A contract that doesn’t implement the interface wouldn’t be allowed to subscribe to the events.

At event emission/happening time, the block producers would parse the subscribers and execute the callbacks.

To play the devil's advocate, however, I feel that it's important to note that this whole idea can "quickly" get out of hand, with a block not having enough space to fit all of the callback txs reacting to a Stream event - or the block producers not having enough resources to process all of this in a timely manner, leading to an ever-increasing block time. 😨