2021-06-21 Meeting notes

Owned by 竹内琢磨
Last updated: Jun 29, 2021
2 min read

Date

Recording

dummyfile.txt

Attendees

Discussion items

  • (1) Intro

    • dhinakaran: IBM research lab
      Ramakrishna: IBM working
      Jim Zhang: Firefly labs PJ. Hearing from Hart and Tracy
      Krishnasuri N: working IBM
      Aruna: Engineer in Bangalor

  • (2) Connector standarization

    • Peter: We aim a goal to actual interop standard
      The way of development is based on underlying ledgers (Fabric, Besu, ...)

    • Shingo: What is exact problem of interop?
      In cryptocurrency case, we need automatic system to switch it.
      What is the scope of interop here?

    • Jim: Design and application. Interop action is based on programming model.
      Quorum standararization is based on blockchain protocol.
      Merkle tree validation is from another chain. Interop is based on application.

    • Hart: Merkle tree proof provides a lot.

    • Ramakrishna: Interop identify use-cases. Two different networks deals atomic transfers.
      Under the semantics side, two fabric networks, corda networks, ... need access control and proofs.

    • Shingo: regarding interop, difficulty underlies on platforms
      Synchronize technical swap is needed. It needs some meta information.
      Frequency, stakes on the case, consensus algorithm.
      Who handles the multiple ledgers.
      Everytime application program needs policy. That is common problem.

    • Jim: Cross-chain verification needs coordination.
      Coordination logic needs the goal of any trust.
      The whole process of multiple ledgers is like Cactus

    • Shingo: Cactus is one of the solutions on the interop issues.
      How to collaborate with each other. This is not the problem of winner or loser.
      In this meeting, I want to find out the compromising point of starting to collaborate.

    • Jim: Expose Fabric, Corda, Ethereum, .... Transation deployed.
      It needs SDK and grpc protocol. It has a big threshold.
      Connector has JSON payload. In Firefly, high level api and role of connector, blockchain programming

    • Shingo: To make a native blockchain world, Cactus takes a similar approach with Firefly.
      All transactions provides the abstraction layer
      e.g. Bitcoin and Ethereum txs have different crypto structure and data format.
      Keeping the different data format, even we provide abstraction.

    • Jim: In Firefly connector, Ethereum has unsigned payload. People use the server component.

    • Shingo: In trusted third party, in your case the server is always honest?

    • Jim: No. Connector has own key managers.

    • Shingo: This is one security model.
      Multiple digital currencies like Bitcoin and Ethereum has the value which are synchronized.
      To enable the communication, we need to clarify the digital assets type supported on the interop model.

    • Jim: Firefly architecture has one service, the something
      Cactus is also a project of dealing multiple ledgers.

    • Peter: Connector API, I don't mind to change connector API.

    • Hart: Agreed that ledger connector is the starting point of collaboration.

    • Ramakrishna: Different connector, we have a network plugin,

    • Shingo: In the case of cross-boader of blockchain, firefly and YUI maybe suitable in such case. Blockchain itself is not only financial case. Then the key is finality.

    • Jim: Individual connector is available on
      All needs the socket. json object.

    • Shingo: Cactus has the similar approach of socket.io.
      I agree with you on the comonarity.
      I think it needs high-level abstraction.
      Currently, high-level interworking protocol is needed.

    • Jim: I do agree with high level API.

    • Shingo: Blockchain another people, limited purpose,
      Hybrid solution can be provided using the three projects.

    • Hart: continue to Architecture WG