To proxy or not to proxy

[PaulRBerg]

Problem Situation

It is not possible to batch multiple function calls in one Ethereum transaction. This limitation might be lifted when Account Abstraction gets added at the protocol level, but AA will take years to be implemented. Solutions like PRBProxy and DSProxy have emerged as interim solutions to this current limitation of the Ethereum protocol.

Internally, we have toyed with the prospect of using the proxy approach for quite some time now, but we have decided to let go of it in a recent discussion. The rationale was that the proxy was unnecessary for the batch create function.

However, more recent discussions have led us to realize that other features may only be implemented with a proxy mechanism, or it would be much easier to implement them with a proxy. For instance, see the discussion in sablier-labs/v2-core#331 regarding stream edits, which can only be implemented in the existing contracts by having a function that batches a call to cancel and a call to a create function. I have recently opened a draft PR that takes a first stab at implementing this in v2-core, but I have done it somewhat grudgingly. Stuffing too much logic in the "core" contracts gnaws away the underlying reason why we named the way we did. Composing functions doesn't sound like something belonging to a "core". Thus, I think we have a "crisis of identity" in the v2-core repository, and my goal with this post is to have us re-consider the proxy approach.

Feature Table

Some features can easily be implemented without the proxy, others can be implemented without the proxy but require us to jump through hoops, and finally, others can only be implemented with the proxy (while still providing a decent UX to our users).

Feature	Proxy	Without Proxy
Function createMultiple (single asset)	✅ Doable (easy)	✅ Doable (easy)
Function createMultiple (multiple assets)	✅ Doable (easy)	⚠️ Doable (hard)
Function cancelAndCreate in the same contract	✅ Doable (easy)	✅ Doable (easy)
Function cancelAndCreate across contracts	✅ Doable (easy)	❌ Not doable
Function cancelMultipleAndCreateMultiple in the same contract	✅ Doable (easy)	⚠️ Doable (hard)
Function cancelMultipleAndCreateMultiple across contracts	✅ Doable (easy)	❌ Not doable
Migration to v2.x	✅ Doable (easy)	❌ Not doable
Migration to v3 (yes, you read it right)	✅ Doable (easy)	❌ Not doable
Native asset payments (ETH)	✅ Doable (easy)	❌ Not doable
Permit2	✅ Doable (easy)	⚠️ Doable (hard)
Tokenized Vaults (ERC-4626)	✅ Doable (easy)	⚠️ Doable (hard)

Comparison

Here are the pros and cons of using the proxy approach, ordered by significance (the most significant points are at the top).

Pros

1. Ability to migrate streams from V2.0 to V2.x with one zap (instead of N txs).
   • This is useful not just for new feature upgrades, but also for potential bug fixes.
   • Long shot, but the migration may not be limited to just v2.x; with the proxy approach, migrating stream to the v3 chain via a bridge would also be possible.
2. Support for native asset payments (e.g. ETH, MATIC) via wrapEthAndDoAction functions (see this example from the Hifi repository).
3. Support for cross-contract interactions (e.g. canceling a linear stream and creating a pro stream).
4. One ERC-20 approval for all future interactions with the protocol (e.g. no need to separately approve the linear and pro contracts).
5. Dead easy support for Permit2.
6. Ability to delegate the account management to a third-party via PRBProxy's envoy<>target access-control system. This may be useful for automating withdrawals (a really nice solution to the problems discussed in Withdraw on behalf of v2-core#39 and Making withdraw public: Pros and cons v2-core#110).
7. Solves the identity crisis problem explained above.
8. Cleaner core contracts.
   • The cancelAll function could be moved to a proxy target (the recipient would lose access to this function, but this sounds okay with me, given the benefit of a cleaner core).
   • The cancelAndCreate functions could be implemented in a proxy target.
9. The proxy would have a "centralizing" effect on our implementations: the BatchStream periphery contract would become a proxy target, and we may also be able to use the proxy approach for the airstream contract.
10. Using the proxy is in line with good programming principles, such as separation of concerns
11. Broadly speaking, we would get the ability to add certain new features without modifying the core.

Cons

1. Increased development time for the frontends and the subgraphs.
2. Manually canceling stream would be more difficult for senders, because the proxy would be the sender of the stream. The sender would need to be a sophisticated user who knows how to ABI encode Ethereum txs.
3. Higher upfront deployment cost for senders on Ethereum Mainnet.
4. Worse developer experience when debugging reverted txs.
5. Increased audit cost due to the need to audit PRBProxy.
   • This may be a moot point, however, because if we want to implement any of the features from the table above, that code would have to be audited, too. The only extra assumption would be the security of the execute function of the proxy itself. Still, since the proxy has many users, we would get some shared security.

Sender vs Recipient

To avoid doubt, I wish to state that the discussion here applies only to senders. It is not practical to use the proxy approach for recipients, due to the following reasons:

• The NFT functions would become unusable.
• Recipients would only be able to claim via our UI.
• Recipients are typically less well-off than senders (the deployment cost of the proxy might be a deterrent for recipients).

My Proposal

Given that so many features are impossible to implement without the proxy, and others are difficult to implement without it, I am now firmly in favor of using the proxy approach. The pros outweigh the cons. If Maker, Balancer, and DeFiSaver managed to get away with it (in spite of the cons), we should be able to do it, too.

@razgraf and @gavriliumircea - I am keen to hear your thoughts on this.

[PaulRBerg]

Live update on the cost of deploying a PRBPRoxy today (base gas price at 22 gwei):

Completely doable IMO, given our emphasis on batch stream creation in V2 and our targeting of DAOs and organizations. Smaller players resort to non-mainnet chains, anyway.

Also, the future of Ethereum is rollup-centric.

[razgraf]

I admire the improvements a proxy would bring to our architecture. It's both a short term solution to achieve our bundled transactions, and a long term investment. Thinking that maybe airstreams will benefit from it, plus other Sablier v2.X contracts later on.

The biggest costs at the moment would be: re-engineering the client stack with the new "proxy" actor, the gas costs for the user and the complexity it may add for integrators. All bearable, but I still need to map the first and the last one out more thoroughly before I give my educated opinion. Note: haven't read all the points in your original post yet.

---

Out of curiosity, in the meantime:

Let's say we do have the proxy system (in the app as well) and educate our users about it. Would supporting it in the contracts completely break compatibility with EOA senders, or just limit their powers (e.g. no cancel-and-create). My thinking here is possibly maintaining a low-cost/low-maintenance alternative in parallel with the proxy.

[PaulRBerg]

Thanks for the preemptive vote of confidence!

All bearable, but I still need to map the first and the last one out more thoroughly before I give my educated opinion

Can understand this, of course. If you start researching PRBProxy, make sure to start from the staging branch (and nevermind the README, I am due to rewrite it).

What I will say regarding integrators is that if Maker managed to pull it off (and it's Maker, perhaps one of the most integrated lending protocols out there), then we can, too. In fact, DSProxy has been welcomed by Maker's integrators, e.g. see DeFiSaver's blog post. And this appreciation was towards a proxy contract that lacked all of the bells and whistles of PRBProxy (CREATE2, unique registry, replay protection, envoy permission system, and several other features).

Would supporting it in the contracts completely break compatibility with EOA senders, or just limit their powers (e.g. no cancel-and-create)

The latter.

The v2-core repository will be as usable by simple EOAs as ever (this is why I opened the discussion in this repository, v2-periphery). It's just that the EOAs won't be able to call cancelAndCreate and the other composed functions, adn that they won't be able to access the full version of the UI.

Idea: what if we make the light app the "low-maintenance parallel" you are alluding to? It would be an app that doesn't use the proxy, the subgraph, etc.

[gavriliumircea]

I do think the usage of proxy comes with great benefits, I especially like the future migration part. Also if we are able to allow users to use the core functionalities without the proxy, the extra costs will exist just for the users that want or need extra functionalities like cancelAndCreate and I think that is fair. The consumer education will become very important here IMO. Unfortunately I am not sure how long it will. take to implement all this changes at interface level, and I think this is a very important point.

[PaulRBerg]

Thanks, Mircea.

the extra costs will exist just for the users that want or need extra functionalities like cancelAndCreate

Indeed.

The consumer education will become very important here IMO

I argue that user education is essential; our documentation should be top-notch. Max has already started working on this; I will review his work as we get closer to the audit.

I am not sure how long it will. take to implement all this changes at interface level

I may be overly optimistic, but I don't think it will take a long time. Based on my previous experience with a project that used DSProxy (Hifi), the only significant issue I can think of is the UX of debugging tx. Etherscan doesn't display failed proxy txs nicely.

[PaulRBerg]

Some food for thought for what can be built with the recently implemented plugin system in PRBProxy

In our case, the proxy plugins will be super helpful to let senders react more elaborately to cancelations (via the callback system we already got). PRBProxy makes it possible to not have to explicitly implement the ISablierV2LockupSender interface; a plugin could instead implement it.

This is feedback coming from 0xJohannes, one of the lead devs of BarnBridge.

Cc @razgraf, @andreivladbrg.

[PaulRBerg]

Closing, as we're deep down the proxy rabbit hole.