Updates on BIF Proposal Questions
Thanks for all of the constructive feedback at the TSC meeting yesterday. We’re interested in putting together the best possible solution for blockchain integration that we can, and many of the comments helped us move in this direction.
We (there are many contributors to this, including Tracy, Jonathan, Shingo, and more) would like to address some of the questions brought up in the meeting. Hopefully these will help everyone understand more of the BIF. We would like to remind everyone that there is an in-depth whitepaper that addresses many of the technical points that have been asked, and, if you have technical questions, it’s very possible (perhaps even likely) that they are answered in the whitepaper. You can find it here:
It would also probably save a lot of time in meeting discussions if people were familiar with the content presented in the whitepaper so that we could avoid spending time on questions that are answered in there.
That being said, let’s go ahead and start with the questions!
This is a long-ish story. Tracy told part of this story during the TSC meeting: even before Fujitsu’s involvement, Accenture spoke with the Quilt team about joining the project and expanding it as a subproject within Quilt (as a peer to the ILP subproject within Quilt). At the time, the Quilt maintainers were happy with this, but the TSC decided that it would be better to have a separate project. A bit later, Hart spoke with several people on the TSC, and the conclusion was that even if we did want to add the BIF to Quilt, it would necessitate asking the TSC for permission to change the scope of the project. This is not formally stated in the rules (projects are required to adhere to their scope, but there aren’t really rules for those that want to change scope) and hasn’t been done before, but this was seemingly what would be required. So the TSC implied at the time that we should seek an additional project rather than attempt to join Quilt. This is why we haven’t further sought out a merge with Quilt.
For some context, I’d suggest reading the following email thread: https://lists.hyperledger.org/g/tsc/topic/32153910#2398
Here is a direct quote from Chris Ferris in this thread (from June 21st last year), which seemed to capture the majority opinion at the time:
“Think about it. Which sounds more compelling:
a) we have one project for interop
b) we have five projects that address various aspects of DLT interop
I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.”
So, needless to say, we were a little surprised when the TSC asked us about why we weren’t considering building within Quilt. It also wasn’t just Chris who had this opinion—you can go through the thread we linked and see most of the TSC agree that a new interoperability effort focused on general-purpose integration should be a separate project. From our perspective, we would be fundamentally changing the scope of Quilt, and are thus working on a clearly different aspect of interoperability. The current charter of Quilt says it is to implement the Interledger protocol--nothing more, nothing less. We would be substantially going beyond this charter if we were to include the BIF. Our goal is to build a general-purpose integration platform, whereas Quilt strictly focuses on financial transactions.
Our architecture is also fundamentally different from Quilt. Quilt, as pointed out in the meeting, and the ILP use time-locked commitments to ensure that cryptocurrencies can be transferred between different blockchains. We use a totally different framework--modelled by the business logic plugin--because time-locked commitments are too slow and inefficient for many of our use cases, even if they do enable maximum “trustlessness.”
Presenting a financial use case in the TSC meeting was also a mistake, as it wasn’t useful for explaining key differences with Quilt. We chose it for its simplicity, but we clearly should have chosen something that better illustrated the generality of the BIF. In section 2 of the whitepaper (see above for the link), we explain several other use cases that are not compatible with Quilt. These include sharing sensitive healthcare data across blockchains (section 2.5) and implementing cross-blockchain food traceability (section 2.6) when “supplies” move across different supply chain blockchains. We’d be happy to explain any or all of these use cases to the TSC, if they so desire.
We also have unfortunately not received any comments from Quilt on this proposal, although we would be more than open to their feedback.
We don’t think adding the BIF as a project will increase fragmentation. In fact, one of the main reasons we submitted it for consideration as a project was to decrease potential fragmentation. Fujitsu and Accenture had both come up with overlapping solutions, and it is clear there are others that are working on similar things. Having a project focused on integration/interoperability with an architecture that is flexible enough to accomodate everyone interested in general-purpose integration seemed to us like a great way to minimize fragmentation in the space. Recall that BitXHub submitted a somewhat similar proposal as well for this, although it’s not clear what happened with their proposal. Finally, note that fragmentation outside of Hyperledger in an area might be even worse for us than fragmentation within. Many different interoperability/integration projects are being built, and having a solid, extensible general-purpose project in Hyperledger might help decrease the fragmentation “in the wild” outside of the Hyperledger greenhouse.
2. Is the BIF business logic plugin a single, centralized authority?
No! And we are sorry that our documentation was not clear enough to immediately refute this point for those that asked (we thought it was). While we have defined the business logic plugin to be a modular component--and thus, you could put something very centralized there if you wanted to do so--in all of our implementations, the business logic plugin is something decentralized. We encourage any interested readers to peruse the whitepaper to see how this works.
For instance, in the Fujitsu implementations (known as ConnectionChain), the business logic plugin is typically implemented by a Fabric blockchain. Validators and orderers on this “ConnectionChain” as it is called could come from one, both, or neither of the blockchains that form a part of a cross-blockchain transaction. We note that these nodes on the “ConnectionChain” do not have to have privileged roles on any of the blockchains used for the cross-blockchain transaction--they only need to be able to verify transactions.
Many of the Accenture implementations use a business logic plugin form that is arguably even more elegant. It involves creating overlay networks of existing blockchains so that the BIF is both decentralized and efficient, although this formulation is not possible for PoW blockchains.
We’d be happy to provide more details on these configurations if what is in the whitepaper is not enough, and the architectures of both the original Fujitsu and Accenture solutions if you’re interested. Please feel free to ask!
As an analogy, we’d like to point to the Fabric ordering service. It’s a flexible, modular system. You could have a single orderer--resulting in a very centralized system, which is undesirable in many ways but efficient--or a massively distributed ordering system, which would give you better security and trust requirements. The BIF business logic plugin is configurable in a similar way.
3. Can we use the BIF in applications where privacy and/or confidentiality are needed?
Yes, we can! In fact, one of our targeted applications--sharing sensitive healthcare data across blockchains, see section 2.5 of the whitepaper--certainly needs strong privacy and confidentiality properties. We can elaborate more on this if people are interested and want more information than is included in the whitepaper. The business logic plugin can be configured in a way that preserves privacy and confidentiality, if desired. For instance, if the business logic plugin is (essentially) a Fabric blockchain, then you can use Fabric technologies like channels to gain privacy properties if the blockchains you are transacting between support similar notions of privacy.
We admit that there are a lot of privacy and confidentiality issues that we cannot currently handle. For instance, if you wanted to do a cross-blockchain transaction between two blockchains that were running the Zcash protocol, the current codebase would not be enough. But this would be because we do not have appropriate SNARK implementations included yet, not because our architecture could not handle it. We think that handling privacy and confidentiality requirements efficiently is an exciting area of future work, not just for blockchain integration but for blockchain in general. We would love to hear what more use cases and proposals for privacy enhancing technologies that we should be using, so if you have suggestions, please feel free to let us know.
Additionally, our community welcomes discussion on these topics or any other feedback through channels supplemental to the TSC, either directly on our Rocketchat channel #blockchain-integration-framework or in our next contributors’ session on Monday April 27th Americas / Tuesday 28th rest of the world. Please join our session if you have technical questions or comments! Ideally we could answer as many questions out-of-band as possible so as to not take up an excessive amount of time at the TSC meetings.
Thank you very much for reading this long email if you’ve made it this far. We really appreciate your time thinking about this effort and your consideration. We hope everyone has a great weekend and stays safe in these difficult times.