Re: Blockchain Integration Framework--Project Incubation Proposal <hmontgomery@...>

Hi Dan,


Thank you for the thoughtful questions.  Peter and I collaborated on some answers, which I’ve included below.  Please feel free to follow up if you’ve got any more questions or comments, including on the answers to these questions.  We have also added these questions and our responses to them to the proposal document for future reference.


Thanks a lot for your time, and have a great day.






1.        Why propose this now instead of after the code bases are merged and/or the whitepaper is complete?


There are a lot of reasons why.  To start, we’ll mention overall visibility.  There have been a number of groups in and around Hyperledger that have been interested in blockchain interoperability.  In addition to this proposal from Fujitsu and Accenture, we have already seen a BitXHub proposal for interoperability.  There is at least one team from IBM that we know of working on interoperability, and there are people at Intel as well that are interested (at least one who needs to be put in the dunking booth).  We want to make sure that we get feedback from as many people possible in and around the Hyperledger organization before we make firm commitments to APIs and architecture that are difficult to change, and we want to accomodate all that want to participate.  As Chris Ferris pointed out at the TSC meeting two weeks ago, it’s much more difficult to change things after you’ve built them than to build them together.  So we want to only have to do architectural refactoring once with as many participants as possible and get it over with, rather than having to continually update with backwards-compatibility breaking changes as we add more and more participants (we expect to have to do some of this anyway, but the less, the better).  We also hope that this helps Hyperledger minimize fragmentation on blockchain integration. 


From a selfish perspective, it’s easier for us to get internal resources for the effort if it is a project rather than a lab.  We know this isn’t rational, but, to borrow from the parlance of our times, “upper management is gonna upper management.”


We’re also putting together and using things that we aren’t sure are available for labs.  For instance, Peter and Jonathan have begun setting up Circle CI for our CI/CD pipeline.  To our knowledge, CI/CD resources in Hyperledger have only been approved for projects.  We really don’t want to have to put the full effort into doing these kinds of things twice, and setting up a project now would allow us to do things like CI/CD setup once and then get it over with, rather than do it outside HL now and then have to redo it later if we applied for project incubation status again.


As for the whitepaper, we expect it to be a living document and that it will never officially be finished.  We’re going to version control it and have it in github so that we can make changes as we see fit.  From our perspective, there will always be new blockchain frameworks or changes in existing ones to integrate, so if we ever “completed” the whitepaper then it would be hopelessly out of date in a very short time.


2.                   What hard problems do you think this framework has solved?


The simplest “hard problem” that this framework solves is inter-blockchain swaps.  Suppose we have a Fabric blockchain--called A--that keeps track of tractor registration, and a Corda blockchain--called B--that handles cash.  Now what if Arnaud wants to trade his tractor to Mic for Mic’s cash on blockchain B without resorting to a strongly centralized trusted authority?  This is the essence of the core problem that the BIF solves.


We aren’t sure how much we need to say about the difficulty of this problem.  We certainly think it’s tricky, and the lack of good solutions in the space despite the demand seems indicative to us that the problem is indeed hard.


The simple problem we mentioned above is, of course, the most basic case.  The problem gets substantially trickier once other things are introduced, like more participants in a transaction, PoW-based blockchains (or, more generally, blockchains without instant finality), or the requirement of external sources of information (e.g. we make a cross-blockchain sports bet that we need someone to verify).


3.                   How are rollbacks/forks in either network resolved?


Great question!  This is blockchain dependent.  Suppose we want to perform a transaction that involves swapping assets on two blockchains--call them blockchain A and blockchain B.  If both chains use BFT consensus (or some other permissioned consensus that doesn’t fork) then this is obviously not an issue.  While trades between permissioned networks constitute the majority of real-world use cases we (Fujitsu and Accenture) have both PoCed and deployed, they aren’t the only ones.


For instance, suppose blockchain A is a Fabric chain and blockchain B is the bitcoin blockchain.  In this case, it’s a little trickier, since bitcoin can obviously fork.  Our solution in this case is to configure a set of what we call “external validators.”  These are entities--which could be blockchain nodes--for which we trust that ⅔ of the group is honest.  They are configured in this case to generate consensus as to when a transaction on bitcoin would be deep enough in the chain to be considered finalized, and to not finalize the Fabric/bitcoin asset swap until this is the case.


There are some more clever tricks you could potentially do for public blockchains with smart contract functionalities, but for pure PoW blockchains without smart contract functionality, some kind of outside verification setup seems to be required.  If anyone has more elegant ideas, then we would be more than open to suggestions.


A note on complete ledger/currency failures:


Lastly, with ledgers that run on consensus algorithms that do not guarantee transaction finality: if those ledgers get attacked and the transaction history gets altered or completely erased, there is nothing BIF or anyone else can do about it. Based on this, we consider it out of scope to solve that as a technological problem and instead focus on prevention by making it a fundamental, mandatory part of the transaction proposal protocol for clients to have upfront information about the capabilities of the participating ledgers.  This way, at least the decision is up to the end user to explicitly acknowledge that they wish to sell their tractor and get paid with bitcoin which could evaporate in the event of a successful 51 percent attack or a very long rollback.


We also consider it important to note that when thinking in absolutes such as above, all currencies - cryptographic or fiat - bear this same risk and only the probabilities of these critical failure events vary based on the currency. 


For example an alien invasion could wipe out the US dollar (and all other fiat currencies of the world). The latter implies that every time someone accepts payment for their tractor in US dollars, they make the bet that an imminent alien invasion will not destroy the value of said currency right after the sale has concluded.


4.                   Corda is the most dissimilar architecture you are targeting. How will the design change or is the current design likely to work with Corda?


Corda may be the most dissimilar, but the level of dissimilarity is not high enough to cause problems because our core makes very few assumptions about what a ledger is. We treat the ledger as a database with simple data read/write capabilities and custom code execution (the contracts) that can leverage the said read/write capabilities. Even the consensus algorithms used by the ledger are almost irrelevant. Almost, not completely because it matters whether the algorithm guarantees transaction finality or not, but that’s about it. Higher level features in the future may be more impacted/dependent on the architectures of certain ledgers, but we count on the plugin architecture to do the heavy lifting there so that the core design still won’t be affected by it.


5.                   When we resume face to face events how many dunk tanks will this project provide or require?


Our goal is to throw out dunk tanks like Oprah doing a wild giveaway.  Since we will be using so many dunk tanks, we will be requesting Hyperledger CI/CD resources for dunk tank evaluation.  We expect to have a meeting with Ry and Dave about this if the project is indeed approved.


From: Middleton, Dan [mailto:dan.middleton@...]
Sent: Wednesday, April 15, 2020 1:24 PM
To: Montgomery, Hart <hmontgomery@...>; tsc <tsc@...>
Cc: Somogyvari, Peter <peter.somogyvari@...>; Hamilton, Jonathan M. <jonathan.m.hamilton@...>; Kuhrt, Tracy A. <tracy.a.kuhrt@...>; Fujimoto, Shingo/
藤本 真吾 <shingo_fujimoto@...>; Takeuchi, Takuma/竹内 琢磨 <takeuchi.takuma@...>
Subject: Re: [Hyperledger TSC] Blockchain Integration Framework--Project Incubation Proposal




I think this is the right kind of project for Hyperledger.


Figured I’d get some questions out on the list ahead of the start of the discussion tomorrow…


Why propose this now instead of after the code bases are merged and/or the whitepaper is complete?


What hard problems do you think this framework has solved?


How are rollbacks/forks in either network resolved?


Corda is the most dissimilar architecture you are targeting. How will the design change or is the current design likely to work with Corda?


When we resume face to face events how many dunk tanks will this project provide or require?





Dan Middleton

Principal Engineer




From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Thursday, April 9, 2020 at 3:09 PM
To: tsc <tsc@...>
Cc: "Somogyvari, Peter" <peter.somogyvari@...>, "Hamilton, Jonathan M." <jonathan.m.hamilton@...>, "Kuhrt, Tracy A." <tracy.a.kuhrt@...>, "Fujimoto, Shingo" <shingo_fujimoto@...>, "Takeuchi, Takuma" <takeuchi.takuma@...>
Subject: Re: [Hyperledger TSC] Blockchain Integration Framework--Project Incubation Proposal


Hi Everyone,


Thank you very much to all of those that have looked over our proposal already.  Given the feedback we have received so far, we’d like to begin the process of formally applying for project incubation status.  If possible, we’d like to discuss this at the next TSC meeting, where we can have several project contributors attend so that we can answer as many questions as possible.


So, if you haven’t already, please take a look at our project proposal:


Please feel free to either add questions or comments to the document, respond to this email, or use our rocketchat “blockchain-integration-framework.”  We are open to suggestions, feedback, and advice, and would love to hear from many people on this list.


Thank you very much for your time, and I hope you all are staying safe out there!





From: Montgomery, Hart
Sent: Wednesday, April 1, 2020 2:30 PM
To: tsc <tsc@...>
Cc: Somogyvari, Peter <peter.somogyvari@...>; 'Hamilton, Jonathan M.' <jonathan.m.hamilton@...>; Kuhrt, Tracy A. <tracy.a.kuhrt@...>; Fujimoto, Shingo/藤本 真吾 <shingo_fujimoto@...>; Takeuchi, Takuma/竹内 琢磨 <takeuchi.takuma@...>
Subject: Blockchain Integration Framework--Project Incubation Proposal


Hi Everyone,


At the blockchain integration framework (BIF) lab meeting yesterday, we (the BIF lab community) decided that we were finally ready to start the process of applying for project incubation status.  As such, we would like to present our proposal document to the community:


We have already received some constructive feedback from community members, but would love more.  We will plan on formally proposing this in front of the TSC (pending positive feedback) in a week or two (definitely not this week), so please take a peek if you have a chance.


The more feedback we get, the better, so please feel free to comment on the proposal document.  In addition, if you’d like to discuss things specific to this effort or things that are out of scope of the proposal document (e.g. detailed architecture questions), we have a rocketchat channel (blockchain-integration-framework) where we try to answer questions promptly.


Thanks a lot for your time, and have a great day.





Join to automatically receive all group messages.