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

[Help] Question about communication and timeout in DLT Interoperability Case Study #8

Open
Tonyrj3268 opened this issue Oct 14, 2024 · 0 comments
Assignees

Comments

@Tonyrj3268
Copy link

About you

Please include your name so your contribution can be publicly acknowledged in the final publication.

Name:

Organization/Company:

About your review

Document: Distributed Ledger Technologies Interoperability Case Study

URL: https://entethalliance.org/wp-content/uploads/2024/07/EEA-DLT-Interop-Case-Study.pdf

Section: P11-P12, Leveraging the EEA DLT Interoperability Specification

Your review

Hi, I am a student just getting started with blockchain, and I came across a few questions while reading through the case study. I would like to bring these up for discussion.

In the diagram of the case study, the following steps raised some questions:

  1. Bank B places payment on hold:
    Bank B verifies the trade details and places the payment leg cash on hold for Bank A, marking the DvP contract as notary on the FnPS Ethereum network.
  2. HQLAX places delivery on hold:
    HQLAX verifies the trade details and places the delivery leg securities on hold for Bank B, on behalf of Bank A, using a Corda transaction signed by Bank A, Bank B, the custodian, and a notary.

I would like to know, after Bank B verifies the trade details on the FnPS network, does Bank B submit the proof directly to HQLAX? If not, how does HQLAX obtain the details at this stage?

Additionally, regarding the step:

  1. HQLAX proof generation:
    HQLAX constructs a transaction attestation proof for the delivery leg hold on the Corda network, which is translated into an EEA-compliant crosschain function call, then sent to the FnPS through Bank A.

This part mentions that the proof is "sent to the FnPS through Bank A." Does this mean that HQLAX cannot communicate directly with the FnPS, and it requires Bank A's staff (or an app) to submit the proof?

Next, regarding:

  1. HQLAX receives payment event:
    HQLAX receives the event once the crosschain function call is successfully executed by the crosschain messaging protocol. This is done via the Fnality Access event subscription service running at Bank B.
  2. HQLAX requests payment proof:
    HQLAX requests an event attestation proof of the payment leg execution on the FnPS Ethereum network, which is translated into an EEA-compliant crosschain function call. This is done via the Fnality Access service running at Bank B.

Why is the proof not submitted together with the event when the event occurs? Is this done to separate responsibilities, or are there security concerns involved?

Lastly, how can the timeout issue be resolved? For example, if the funds are already transferred to Bank A on the FnPS network, but a problem occurs when HQLAX requests the proof from Bank B, could this cause the securities to be stuck on the Corda network? In such a case, would it still qualify as an atomic transaction?

Thank you to the EEA team for your responses, and please forgive any misunderstandings in my questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants