Skip to content
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.

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

(Local | Global) fungible assets in Multi VM #97

Open
conr2d opened this issue Dec 7, 2024 · 0 comments
Open

(Local | Global) fungible assets in Multi VM #97

conr2d opened this issue Dec 7, 2024 · 0 comments
Assignees
Labels
K:multi Cross-protocol features P:medium Priority: Medium

Comments

@conr2d
Copy link
Contributor

conr2d commented Dec 7, 2024

Description

Fungible assets in Noir can be classified as Local and Global assets.

Definitions

  1. Local Assets:
    Fungible assets whose states are entirely managed within a single VM's context. These assets are designed to operate independently, with no shared state across other VMs.

  2. Global Assets:
    Assets where the primary state transitions are managed by the engine itself while exposing interfaces for operations within individual VMs. Advantages of Global assets:

  • Lower costs: Key operations are centralized in the engine, reducing VM-specific overhead.
  • Shared state access: The engine allows multiple VMs to interact with the same asset state seamlessly through exposed interfaces.

However, Global assets come with a significant caveat: contracts must transition their state to use our contract SDK (instead of managing state independently), requiring developers to modify their contracts to comply with this approach. This introduces a learning curve and a proprietary workflow, which might not align with our protocol’s goal of simplicity and broad compatibility.

Alternative Approach: Cross-VM Asset Management

Instead of Global assets, we could explore a mechanism where Local assets remain fully managed within their respective VMs but are made accessible across VMs through an adapter layer.

The adapter would:

  • Maintain metadata about the asset's state location (i.e., which VM manages the asset) and provide instructions for accessing it.
  • Facilitate cross-VM calls to interact with the asset, ensuring that even non-native VMs can recognize and work with these assets.

For example:

  • A standard ERC-20 contract could be deployed on the EVM.
  • To interact with this asset from another VM, the engine would require registration (or upgrade) of the asset's metadata.
  • This process would enable the engine to coordinate interactions while maintaining compatibility with existing contracts and minimizing modifications.
@conr2d conr2d added P:medium Priority: Medium K:multi Cross-protocol features labels Dec 7, 2024
@conr2d conr2d self-assigned this Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
K:multi Cross-protocol features P:medium Priority: Medium
Projects
None yet
Development

No branches or pull requests

1 participant