8000 Consider abstracting balances from different actors in a single vault · Issue #81 · OpenZeppelin/minimal-rollup · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Consider abstracting balances from different actors in a single vault #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ggonzalez94 opened this issue Mar 21, 2025 · 2 comments
Open

Consider abstracting balances from different actors in a single vault #81

ggonzalez94 opened this issue Mar 21, 2025 · 2 comments
8000
Labels
needs discussion This issue still needs discussion before implementing

Comments

@ggonzalez94
Copy link
Collaborator

Originally proposed here

The idea is that instead of tracking balances and allowing deposit/withdraw on individual contracts, we create a NativeVault (I guess a similar mechanism for ERC20s) that holds all funds for proposers, provers and other actors of the rollup(not to be confused with user balances, that is a very different conversation).

This is only beneficial if we have more than one contract where the same actor(s) need to deposit/withdraw some since it isolates the logic and make it more capital efficient. At the time of writing this, the only contract with these requirements is the ProverManager.
@ggonzalez94 ggonzalez94 added the needs discussion This issue still needs discussion before implementing label Mar 21, 2025
@ggonzalez94 ggonzalez94 mentioned this issue Mar 21, 2025
Merged
@xiaodino
Copy link
Collaborator

I like this idea and would be happy to help contribute. I have a few questions

Access Control:
Do we envision NativeVault enforcing permissions directly (e.g., only ProverManager can slash or withdraw prover funds), or should it rely entirely on calling contracts for authorization? Understanding clearly where responsibility for enforcing permissions sits would be very helpful.

Future Scalability:
Looking ahead, if we introduce more roles or modules (like proposers or preconfirmation registries), would each of these modules inherit their own NativeVault, or might it eventually be beneficial to consolidate ETH accounting into one shared contract across modules? I’m curious about the intended long-term architecture and how we anticipate managing this as complexity grows.

Happy to help prototype or implement.

@nikeshnazareth
Copy link
Collaborator

The idea is that instead of tracking balances and allowing deposit/withdraw on individual contracts, we create a NativeVault (I guess a similar mechanism for ERC20s) that holds all funds for proposers

This is only beneficial if we have more than one contract where the same actor(s) need to deposit/withdraw

If I understand correctly, Ernesto's idea was not about creating a separate vault contract to hold the funds independently, but about encapsulating the vault logic in its own abstract contract and letting the prover manager inherit it. I'm generally in favour of all versions of encapsulating related logic in a self-contained abstraction, whether or not we actually end up reusing it.

@LeoPatOZ LeoPatOZ mentioned this issue Mar 24, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs discussion This issue still needs discussion before implementing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ggonzalez94 @nikeshnazareth @xiaodino
0