2018 06 16 @ 2pm UTC

Actions

Discussion

General architecture

Alex's Demo – Very good work Alex!

• Showed us goland IDE
• Spun up Fabric ordering service in new window
• After we get consensus
  • Takes message and plays it back to the orderer
  • Message for now is not displayed...
• Modified the "solo" consensus...
• Kafka - no BFT - basically a messaging service!
• Solo - not recommended for production
  • for dev purposes, not bothering with a Kafka cluster
• One orderer instance and one Hashgraph instance per organisation
• Each organisation that wants to run chaincode will have:
  • a Hashgraph node
  • an Orderer instance
• Hashgraph nodes tied into a cluster
• gRPC server - listens for responses
  • protobuf...

Continued discussion

• Mapping between "blocks" (blockchain) in Hyperledger and "realms" in Hashgraph
• CouchDB - recommended database for production
• Fabric could have worked without blocks...
  • Nothing to do with blocks from public blockchains like Bitcoin...
  • Tied with hashes, each block represented by hash of current tx and previous block
• One orderer per organisation
  • Is this a security issue?
  • Open to DDoS attacks?
• If we already have Hashgraph consensus network
• Connect peers directly to Hashgraph nodes
• Multiple Hashgraph nodes instead of one orderer instance
• Those nodes talk directly to Hashgraph nodes
• Talk to Hashgraph nodes from other organisations
• This is the easiest, fastest way to show that chaincode works
  • How can we do this plugin and tidy up the architecture?
• There was an argument on HL-Mecury channel
  • writing Hashgraph plugin not necessarily the best idea
  • Alex does agree with this
  • The argument is that HL already working on a PBFT consensus
    • solo plugin, kafka plugin, Hashgraph plugin, etc.
    • "A Byzantine tolerant orderer service for the Hyperledger Fabric project"
    • Paper - 4 nodes, 50k tx/sec
  • So what's the point of Mercury
    • aBFT vs. pBFT
    • Additional opportunity to simplify the Fabric architecture!
    • Performance
  • Biggest bottle neck is storage!
  • Order is just a proxy to something that does the ordering...
    1. Orderer part is not fully implemented! Need to put them in the "block cutter"... Lets the peers know consensus has been reached
    2. Take an installation of Fabric, take a smart contract (Chain code), deploy it and see that it works
    3. Support for ChainOS? (namespaces)
• Golang expertise?
• Engage with someone from Fabric?
• The enabling step - has unlocked a big door for us
• Especially since Alex was the one advocating for this direction and got it done

Hyperledger trademark issue

• Action taken
• Hopefully it's enough to satisfy their concerns
• Developing a plugin - not much they can do to prevent us from building a plugin?
• They're just protecting their trademark
  • They want to make sure nobody's leveraging Hyperledger brand
• Pragmatic approach
  • Building our own stack
  • Sensitive to branding
• Sovereign did similar - is there precedence here?

EEs (trusted execution environments):

• "Alpha block" - company in Canada
• Stock market index - also published on Google Finance
• Contact in Romania who may be interested in secure processing
• Supersmart algo which knows how to do trading. S&P
• Do not have the ability to demonstrate that they do have that algorithm
• Host a smart contract and allow others to buy data from them, buy tips, etc.

Priorities

• Vagrant & Terraform approach (Tim)
• Execution Docker in parallel to Docker Service
• Protocol for passing execution request to/from (Eamonn)

Participants

• Eamonn Hynes - Northern Ireland - Allstate Corporation
• Alex Males - Romania
• Craig Drabik - TxMQ - DLT - Hyperledger + EXO project
• Ken Anderson - Hashgraph - Chief Developer Advocate
• Greg Scullard - Hashgraph - Developer Advocate - France
• Viraf - MD, USA