Actions that trigger a subgraph update

[PaulRBerg]

Aiming for this to be an exhaustive list, so feel to share your suggestions below:

• Any streaming operation: create, update, or delete (related: Streaming operations #17)
• Deposits and withdrawals to and from the rollup
• Simple one-time transfers
• Terminating streams

Note: in standard EVM, a contract can receive ETH as a recipient of a coinbase transaction (a.k.a. a staking reward) or as a destination of a SELF-DESTRUCT. See the Solidity documentation. But these cases do not apply to SabVM because:

• SELF-DESTRUCT is deactivated, see SELF-DESTRUCT and minimizing git conflicts when rebasing from REVM #80
• Sequencer fee payments are excluded, see Addresses not allowed for streaming #78

Related discussions:

• How to prevent Unbounded Computational Growth (UCG)? #57
• Whom should we charge for the eventual gas-intensive rebalancing? #63

Cc @sablier-labs/sabvm

[IaroslavMazur]

A couple more items for the list:

1. For the Base Token, any tx on the rollup will affect the terminus of the tx signer (via the tx fees). Even with the Sequencer excluded from the Stream graph itself, any account streaming the Base Token will still be affected by this.

2. Yield-bearing tokens, of the unit-increase model type - Native Tokens won't support this type of token, not even in the wrapped form

[IaroslavMazur]

some portion of the token supply would have streaming capabilities, while others wouldn't

In the scenario of the MINT opcode having the isStreamable added to it, I was implying the idea of changing the "streamability" of the whole lot - not just the specific batch that's being minted rn.

But yeah, I hear you. This is another problem with this approach, and considering its other disadvantages in my previous comment, I agree that we shouldn't pursue it.

---

Are you talking about a smart contract being re-deployed to the very same address during an "upgrade"?

I've asked this question, hoping that the answer to it would help me better understand what you meant in your original comment. Unfortunately, though, it did not.

Could you, please, elaborate what you were saying here?

Whether a contract can go from Not Streamable to Streamable is necessarily allowed by contract upgradeability. We cannot prevent this at the VM level. Users who perform such upgrades will be liable to lock their streamed tokens forever.

I can only see a problem if tokens are being streamed to a contract that doesn't allow an admin to get a hold of those tokens (e.g. to move them to the new implementation of the contract).

[PaulRBerg]

I was implying the idea of changing the "streamability" of the whole lot - not just the specific batch that's being minted rn

That sounds like a super strange behavior. Why would an opcode that affects only a portion of the total have any side effects on the non-affected portion of the supply?

I agree that we shouldn't pursue it.

Great.

Could you, please, elaborate what you were saying here?

Sorry, I thought you knew how OpenZeppelin upgrades work. Can you take a look at the reference I provided in the previous comment?

Are you talking about a smart contract being re-deployed to the very same address during an "upgrade"?

No.

• If you refer to network-level upgrades, that shouldn't ever touch user smart contracts
• Smart contracts cannot be redeployed anyway
• The upgradeability pattern popularized by OpenZeppelin involves using a proxy contract and an implementation contract; "upgrading" means deploying a new implementation and pointing the proxy contract to the newer implementation
  • Again, I recommend taking a look at the provided reference.
  • While I did it now, in general I don't find it productive to re-explain here stuff that is already explained on the Internet (even when it's relevant to what we are discussing).

if tokens are being streamed to a contract that doesn't allow an admin to get a hold of those tokens

Not a problem if the contract is upgradeable. The admin can implement new logic to get hold of the streamed tokens.

[IaroslavMazur]

That sounds like a super strange behavior. Why would an opcode that affects only a portion of the total have any side effects on the non-affected portion of the supply?

I know that'd be strange, and that's one of the reasons that's a bad idea. I never said we should do this 🙂

---

Sorry, I thought you knew how OpenZeppelin upgrades work. Can you take a look at the reference I provided in the previous comment?
While I did it now, in general I don't find it productive to re-explain here stuff that is already explained on the Internet

I do know how OZ upgrades work, and I did go through those references back when you had sent them. There was no need to re-explain it.

All I was communicating is that I didn't understand what you said here:

Whether a contract can go from Not Streamable to Streamable is necessarily allowed by contract upgradeability. We cannot prevent this at the VM level. Users who perform such upgrades will be liable to lock their streamed tokens forever.

I don't get why the admins of the "upgradeable" contract (who are the only ones permitted to upgrade them) would likely "lock their streamed tokens forever", if they know what they're doing.

Before an upgrade of their contract - more precisely, at the step of choosing the address of the Stream recipient,- instead of the address of the "versioned" Implementation contract, they should just choose the address of the Proxy contract (which contains the reference to the Implementation).

If tokens are being streamed to the Proxy address, then, they wouldn't be "locked forever". But this is a part of the contract infrastructure management that the admins of such contracts should be careful about - not us.

[PaulRBerg]

I never said we should do this 🙂

Yeah, you're right. Sorry. You did say there are a couple of problems in the OP.

I don't get why the admins of the "upgradeable" contract ... would likely "lock their streamed tokens forever", if they know what they're doing.

Oooooooooh, right. You're absolutely correct, and I was wrong when I said Users who perform such upgrades will be liable to lock their streamed tokens forever.

What I was referring to then is a case of an upgrade accidentally introducing the capability to accept incoming streams without an accompanying functionality for withdrawing the streamed tokens. But because the contract is upgradeable (duh!), the admin can push another upgrade to add functionality for withdrawing.

Apologies for my misunderstanding and glad that we got to the bottom of it.

this is a part of the contract infrastructure management that the admins of such contracts should be careful about - not us.

True

[IaroslavMazur]

Glad to hear we're on the same page now! 🤝