Blockchain Integration Framework--Project Incubation Proposal


hmontgomery@us.fujitsu.com <hmontgomery@...>
 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


hmontgomery@us.fujitsu.com <hmontgomery@...>
 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


Middleton, Dan <dan.middleton@...>
 

Hi,

 

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?

 

 

Thanks,

 

Dan Middleton

Principal Engineer

Intel

 

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


hmontgomery@us.fujitsu.com <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.

 

Thanks,

Hart

 

 

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

 

Hi,

 

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?

 

 

Thanks,

 

Dan Middleton

Principal Engineer

Intel

 

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


VIPIN BHARATHAN
 

A suggestion.
For connecting chains with forks (probabalistic finality (PoW) ) vs chains without forks (Number 3. below)
  

These "external validators" can be guarantors, who can offer faster settlement based on a risk premium, if you look at Satoshi's paper you will see that in "section 11. Calculations" she models the probability of a fork with assumptions about honest vs dishonest participants. The probability of a fork drops off rapidly after a certain number of blocks. The guarantors could offer a spread on the cash amount based on the speed. i.e. if you wanted settlement after 5 blocks on the bitcoin blockchain for an assumed dishonest miner of 0.3 they could offer a 25% haircut (instead of the 17% calculated by Satoshi)-i.e. Getting paid for taking that risk and providing guarantees for faster settlement. There could be more sophisticated models for this haircut calculation. Satoshi uses binomial walk.



dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: tsc@... <tsc@...> on behalf of hmontgomery@... via lists.hyperledger.org <hmontgomery=us.fujitsu.com@...>
Sent: Wednesday, April 15, 2020 11:11 PM
To: Middleton, Dan <dan.middleton@...>; 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 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.

 

Thanks,

Hart

 

 

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

 

Hi,

 

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?

 

 

Thanks,

 

Dan Middleton

Principal Engineer

Intel

 

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Vipin,

 

Thanks for the comment.  You’re exactly right.  You can definitely do very complicated, probabilistic things with regard to settlement by offering faster settlement based on a risk premium that can offer a lot of benefits to users.  In the bitcoin example, Satoshi missed some things—for instance, selfish mining—but the overall idea is sound.  We haven’t explored this kind of thing in detail yet, as we’ve been focused on basic stuff so far.  However, as the effort matures, something like this would definitely be interesting future work.  When the time comes, we’ll ask you for advice on this!

 

Thanks for your time, and have a great day.

 

Thanks,

Hart

 

From: vip@... [mailto:vip@...]
Sent: Wednesday, April 15, 2020 10:08 PM
To: Middleton, Dan <dan.middleton@...>; tsc <tsc@...>; Montgomery, Hart <hmontgomery@...>
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

 

A suggestion.

For connecting chains with forks (probabalistic finality (PoW) ) vs chains without forks (Number 3. below)

  

These "external validators" can be guarantors, who can offer faster settlement based on a risk premium, if you look at Satoshi's paper you will see that in "section 11. Calculations" she models the probability of a fork with assumptions about honest vs dishonest participants. The probability of a fork drops off rapidly after a certain number of blocks. The guarantors could offer a spread on the cash amount based on the speed. i.e. if you wanted settlement after 5 blocks on the bitcoin blockchain for an assumed dishonest miner of 0.3 they could offer a 25% haircut (instead of the 17% calculated by Satoshi)-i.e. Getting paid for taking that risk and providing guarantees for faster settlement. There could be more sophisticated models for this haircut calculation. Satoshi uses binomial walk.

 

dlt.nyc

Vipin Bharathan

Digital Transformation Consultant

Financial Services (Blockchain, ML, Design Thinking)

 

 


From: tsc@... <tsc@...> on behalf of hmontgomery@... via lists.hyperledger.org <hmontgomery=us.fujitsu.com@...>
Sent: Wednesday, April 15, 2020 11:11 PM
To: Middleton, Dan <dan.middleton@...>; 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 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.

 

Thanks,

Hart

 

 

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

 

Hi,

 

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?

 

 

Thanks,

 

Dan Middleton

Principal Engineer

Intel

 

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 


Somogyvari, Peter
 

Hi All,


Thank you all for attending the last TSC call and watching our presentation and asking great questions! 
We were asked by Chris and Angelo to provide a more thorough explanation as to what is the problem we are solving and what do we do/provide when it comes to establishing trust relationships.
In response to these, we would like to invite everyone to review some new materials and let us know your thoughts/comments. 
Providing said feedback even prior to the upcoming TSC call is fair game and we'll do our best to respond in a timely fashion.

Attaching a deck with a use-case/problem that we intend to solve. Takeuchi-san from Fujitsu will be presenting these slides during the next TSC call.

Some thoughts on trust relationship pasted below:

We can facilitate all technical elements of establishing a trust relationship, BUT the part that happens offline is not our concern. Example: When a user decides in their mind to create a wallet on a ledger, at that point they will have implicitly trusted that ledger or it's consensus algorithm or the organization who operates said ledger and this is the point in time when the root of trust is established between the user and some domain name that acts as the main hub/discovery endpoint/etc. for said ledger.

In the end, this only happens offline in the sense that the user decides it in their head for whatever reason like it being recommended by a friend or some random blogger on the internet or their bank/government instructing them so, etc.


BIF is not a ledger of ledgers, it is an SDK of SDKs.


BIF does:

- allow for pre-existing chains of trusts to be maintained through cross ledger transactions executed by/via BIF

- enable application developers to more efficiently (with less code/effort) manage and use multiple existing trust relationships of the users' of their application

- require users to trust the BIF deployment they are dealing with in exchange for the above efficiency gain


BIF does not:

- magically make ledgers or their actors more trustworthy

- reduce the amount of due diligence that should be put in prior to entering into a trust relationship.



A specific trust-related use-case:


1. User A (Alice?) wants to get a mortgage loan from User B (bank?)


2. User A walks into a brick and mortar branch of User B, they are given a DID that resolves on the Sovrin chain. This is the moment where trust is really established, offline, by User A receiving a DID and believing that it belongs to the legitimate business entity they are looking to do business with.


3. User A downloads some business application (powered by BIF)


4. User A search for their own DID on an identity ledger and import their keys to the application storing them either locally or via the BIF server side keychain depending on their personal security preferences


5. They search for the DID of User B that they were given in step 2), find it and along with it a list of wallets of User B to one or more ledgers


6. At this point User A is able to initiate an asset transfer (mortgage down payment) from one of their wallets to one of User B's wallet and *trust* that whichever wallet they send the funds to, it is not controlled by a scammer because there's cryptographic proof said wallets belonging to User B.

  At this point the transacting parties can obtain signatures from BIF (which they chose to trust) related to the state of the participating ledgers.

  These signatures provide evidence of the ledgers being in their expected states, e.g.

  a) User A can verify their assertion through BIF that the funds have arrived (e.g. there's sort of a receipt available for them)

  b) User B can verify their assertion through BIF that the funds are no longer on the source wallet of User A on their ledger of choice.


7 The possible loophole is that when the trust relationship was established offline, User A could've been duped by a daily rental fake office/branch and were given the DID of an attacker to begin with.


 To prevent 7) from happening User A could check if the DID is backed by other roots of trust such as a governmental agency, but of course the DID of said governmental agency could've been spoofed the same way which is why we keep mentioning that ultimately trust establishment mostly or perhaps always happens offline. The latter will probably only change once human level artificial intelligence is invented and laws are passed that AIs will be able to act as legal entities in society.


Human perception is very fallible and so even physical things can be spoofed easily such as a building that one can claim belongs to a certain organization.


The potentially non-obvious value add of BIF in the use case is that User A, B could've had any other identity provider/identity ledger or a different scheme other than DID and the whole thing would've still worked so long as there are available plugins implemented (which can be developed by anyone without ever having to talk to us and therefore we find it justified to make the assumption that a plugin would almost always be available).


Our value add for trust is that pre-existing chains of trusts can be maintained through cross ledger transactions executed by/via BIF.


Why should users trust BIF here? How does BIF introduce as few additional trust requirements as possible? Is decentralization of BIF possible?


The incentive to trust a BIF deployment run by someone else is due to the provided convenience (reduced development effort).


The reason why trust is required between you and BIF is because a rogue BIF deployment could steal your assets, even if you don't store your private key on the server side keychain (valid signatures generated from fake ledger states that make you believe you've been paid, etc.).


We speak of a BIF deployment as a single entity, but it can be backed by a consortium, e.g. a set of different entities/organizations/etc. You may not trust all members of the consortium, but if you trust one or more of them you can safely assume that the rest of the consortium members will be kept honest as long as your transactions are configured to require valid signatures from all validators not just a subset of them (which should will be the - secure by - default behavior)


Essentially you can establish trust with a set of consortium members by having only really trusted a single one which reduces overhead.


​We stripped it down as much as possible and relied only on battle tested PKI so that trust can be established in the simplest forms available with current technology, but also in some more convenient ways.


By "simplest forms available" we mean that if you ask a security expert they should confirm and say: Yeah, that's the absolute minimum effort you will have to expend to establish trust with PKI. Anything less and you are just doing it wrong, plain and simple".


Below is a list of examples starting with least convenient but most secure (e.g. least intermediaries):


1. Your friend who is running a BIF deployment hands you their validator node's public key, in-person. Now you can verify BIF signatures yourself and the only possible way to get duped by a rogue BIF deployment is if your friend was not really your friend or if they themselves got duped/hacked to give out the wrong public key.


2. Your friend gives you the SSL/TLS enabled DNS host to their BIF deployment, in-person (now you trust your friend AND also that the SSL/TLS root CA not to MITM you - and the hardware/software of yours running the browser agent used to verify the SSL/TLS certs)


3. Your friend texts you their public key for their BIF validator node (now you trust your friend, but also your telco/carrier, the mobile hardware, mobile OS and the messaging app not to MITM you)

etc.


In all the above examples you also trust of course that your friend's BIF validator's private key hasn't been compromised in any way (so you most likely are also trusting one or multiple cloud vendors which is the typical way of deploying server side software nowadays).


As an end user:

  You can try your luck administering a cross-chain swap or a one way data export by interacting with existing software manually (e.g. use the SDKs of the participating ledgers that are available). But it won't be pretty. So you (the average citizen of the world) probably want to trade-in some risk for convenience as it's usually done in practice in most areas of life anyway.


As a developer:

  You can build your application to do cross-chain transactions from scratch or you can use BIF and save time and effort. You can either trust a publicly available deployment of BIF run by a consortium or you can run your own. If you run your own you don't need trust between you and BIF because the private keys of the BIF validator nodes are your own private keys on servers that you are operating. If, however you want minimum effort on your side, you just connect to someone else's BIF deployment and in this case you must trust the operators of said BIF deployment not being a malicious actor who will give you falsified information about ledger states, essentially MITM-ing you on the transaction protocol layer.


We keep mentioning convenience and reduced effort which also include security, but we would like to highlight that separately as well:

You are less likely to produce secure software written from scratch and are advised to use something peer reviewed, audited. I'm giving ourselves the benefit of the doubt that BIF will end up being better secured software than the average hobby crypto project out there.




 
Kind regards,
Peter

Peter Somogyvari

Technology Architect

Accenture Products & Platforms (APP)

Office: +1 (415) 537-5541

Mobile: +1 (650) 488-1741



From: Montgomery, Hart <hmontgomery@...>
Sent: Wednesday, April 15, 2020 10:40 PM
To: vip@... <vip@...>; Middleton, Dan <dan.middleton@...>; 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: [External] RE: [Hyperledger TSC] Blockchain Integration Framework--Project Incubation Proposal
 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

Hi Vipin,

 

Thanks for the comment.  You’re exactly right.  You can definitely do very complicated, probabilistic things with regard to settlement by offering faster settlement based on a risk premium that can offer a lot of benefits to users.  In the bitcoin example, Satoshi missed some things—for instance, selfish mining—but the overall idea is sound.  We haven’t explored this kind of thing in detail yet, as we’ve been focused on basic stuff so far.  However, as the effort matures, something like this would definitely be interesting future work.  When the time comes, we’ll ask you for advice on this!

 

Thanks for your time, and have a great day.

 

Thanks,

Hart

 

From: vip@... [mailto:vip@...]
Sent: Wednesday, April 15, 2020 10:08 PM
To: Middleton, Dan <dan.middleton@...>; tsc <tsc@...>; Montgomery, Hart <hmontgomery@...>
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

 

A suggestion.

For connecting chains with forks (probabalistic finality (PoW) ) vs chains without forks (Number 3. below)

  

These "external validators" can be guarantors, who can offer faster settlement based on a risk premium, if you look at Satoshi's paper you will see that in "section 11. Calculations" she models the probability of a fork with assumptions about honest vs dishonest participants. The probability of a fork drops off rapidly after a certain number of blocks. The guarantors could offer a spread on the cash amount based on the speed. i.e. if you wanted settlement after 5 blocks on the bitcoin blockchain for an assumed dishonest miner of 0.3 they could offer a 25% haircut (instead of the 17% calculated by Satoshi)-i.e. Getting paid for taking that risk and providing guarantees for faster settlement. There could be more sophisticated models for this haircut calculation. Satoshi uses binomial walk.

 

dlt.nyc

Vipin Bharathan

Digital Transformation Consultant

Financial Services (Blockchain, ML, Design Thinking)

 

 


From: tsc@... <tsc@...> on behalf of hmontgomery@... via lists.hyperledger.org <hmontgomery=us.fujitsu.com@...>
Sent: Wednesday, April 15, 2020 11:11 PM
To: Middleton, Dan <dan.middleton@...>; 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 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.

 

Thanks,

Hart

 

 

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

 

Hi,

 

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?

 

 

Thanks,

 

Dan Middleton

Principal Engineer

Intel

 

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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!

 

Thanks,

Hart

 

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:

 

https://docs.google.com/document/d/1kxylkfVKG_zdNfuzhrmhnYAM_eROwLsoLgIp3XjKNr0/edit?usp=sharing

 

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.

 

Thanks,

Hart

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com