Developer Community Call: (ACP-108) 07-16-2024

[meeshhhh]

(ACP-108) EVM Event Importing Meeting 07-16-2024

Meeting Date/Time: 07-16-2024, 15:00 UTC
Meeting Duration: 1 hour
Moderator: Michelle Tian

Purpose of the Meeting

In this meeting, we will discuss and determine the desired first use case ACP-108, a standard smart contract interface for importing EVM events from any blockchain within Avalanche using Avalanche Warp Messaging.

Who is invited?

Any protocol developer, ACP author, researcher, or Avalanche community member is invited to attend this meeting.

Links

Sign Up Form: Google Form
Youtube Link: Here

Preparation Material

To ensure a high-quality discussion, please review the following materials prior to the meeting:

Mandatory
ACP-108
ACP-108 Discussion

Highly Encouraged
Event Importer POC

Agenda

Protocol engineers will present the motivation, research, and experimentation that has thus far influenced the approach outlined in ACP-108. Various use cases will be open for discussion, which will inform both prioritization of this ACP and features needed for the design of the initial iteration of the standard smart contract interface.

Open Questions

• Are there any particular industries or applications that would benefit most from this capability? Ex: NFT ownership/identity, gaming, financial applications, etc.
• Can you describe a scenario where importing EVM events across blockchains would significantly improve an application's functionality or user experience?
• Are there specific features or functionalities that you believe are essential for this standard to be widely adopted?
• How could cross-chain event importing help bridge gaps between public and private blockchain networks?
• What threshold of delay (from the time an event is emitted on a source chain to when it is imported on another chain) is acceptable? How does this vary for different applications?
• Are there any existing standards or protocols that this should align with to improve developer experience?
• What security considerations should be taken into account when importing events across chains?
• How can this standard facilitate greater interoperability between different blockchain ecosystems?
• See here for more.

Notes

• ACP 108 introduces a standard smart contract interface for importing EVM events within Avalanche blockchains. Using Avalanche Warp Messaging, it enhances cross-chain messaging by enabling importing information from one chain into any other chain, without interacting with the source chain directly.
• Instead of using "source" and "destination" chains, we'll use the terms "event generator" and "event consumer".
• Will there be any gas costs on the event generator chain?
  • No, there are no gas costs for where you're importing from. But there will be gas costs on the event consumer side.
  • Gas usage depends on complexity of what you're proving. E.g. the more txs in a block == higher gas cost for the merkle proof of the individual receipt.
• Are there any particular industries or applications that would benefit most from this capability? Ex: NFT ownership/identity, gaming, financial applications, etc.
  • Dexalot team may use ACP 108 for their CLOB: after user deposits funds on C-chain, a generic message is sent to the Dexalot L1 that credits the user's address. Dexalot team will take a closer look at the ACP and provide feedback on whether or not the interface is generic enough for their use case.
  • Ash team may look into VRFs and random numbers as a use case. You commit to some operation with some random seed that consists of a tx hash + request ID, hash all of that together, and get a random number.
• What threshold of delay (from the time an event is emitted on a source chain to when it is imported on another chain) is acceptable? How does this vary for different applications?
  • e2e latency of event importing should be the same as e2e warp message, only exception is generating proof off-chain. If we assume that the proof generation won't impact latency at the block scale, then latency should be the same.
  • Dexalot: The delay should not be an issue as it is near real-time. But what are the minimum and maximum bounds for the delay?
    • Lower bound is next block produced on the event consumer chain. Happy path is that it should be included in the very next block, but there is no guarantee.
• Can you use event importing for verifying teleporter message receipts?
  • Yes, it could be more gas efficient to use this for explicit receipt proof (aka an ack that message was delivered), but would need to look into this more.
  • The inverse of this should definitely be more gas efficient, aka can prove that a message was never delivered. E.g.: For a message with an expiry time that never gets delivered, once that expiry time passed, prove that 1) block hash has been accepted at a later time stamp 2) no other blocks prior to the expiry timestamp included that message.
• How does the relayer get notified that one block hash has been signed and forward it to another chain
  • Relayer would need to be configured to listen for specific events from specific contracts.
  • Separately, we are also working on ACP 118 that enables users to be their own relayer. Separate out the warp signature generation part of relayer into its own API so anyone can query it and get an aggregate signature.
• Are there specific features or functionalities that you believe are essential for this standard to be widely adopted?
  • The current Proof of Concept makes certain assumptions about how the VM will handle tx index and log index. May need to explore arbitrary format that supports different VM integrations.
  • The current POC does not allow for importing batch events, but this can be considered.