This video (part of IBM course on Hyperledger Fabric) describes that it is possible to encrypt chaincode at deployment so that only a subset of members is able to decrypt it and run it. However, Fabric documentation (v0.6 and v1.0) does not provide any detail on that. Is it a feature not yet implemented that the community wish to build in the future?
It is not very clear to me how this could work. Any peer receiving a transaction from the Ordering Service that it can't decrypt would be unable to run it and update its world state, so what else can it do but just skip it ? It also can't even mark the transaction as valid or invalid.
Am I missing something?
In Fabric v1.0 there is a concept of channels to privately share data with a subset of network members. Only members of the channel will store and have access to the data.
If you would like to encrypt the data regardless, the application may encrypt the data prior to submitting the data to the blockchain.
Yes, it is possible to encrypt data on-chain such that chaincode is still able to see the data and apply logic on it (as opposed to an off-chain encryption where the data being garbage is not usable on chain).
The idea is to pass the encryption key as part of a transient input parameter (which is not transmitted to ordering service and other channel node). So only the endorsers and any node that get to know the key can decrypt the data.
In v1.1 to be released on Q1 2018, Fabric will support an encryption layer API to the access state (see FAB 830).
There are 2 drawbacks of having encrypted data on chain:
Key maintenance and sharing is overhead
Risk of keys leakage + encryption breaking in the future
For privacy, rather than encryption, it might be better to chose a data segregation approach. That is what FAB 1151, also part of v1.1 (Experimental!) proposes:
Each private data belongs to a collection defining the organizations which can access it
The hash of the private state is included in the public state
Endorser keep the private state calculated during the transaction simulation into a transient storage area and apply it at commit phase
Other allowed nodes can request the private state via gossip
Related
Hyper ledger has some classic/old world mechanisms that brings up the question, is it really decentralized?
Having a REST server to communicate with the blockchain brings up the cloud model behavior.
Even though the hyper ledger is distributed, someone calling a rest API will may be written to the server logs with some data such as IP address, GEO info and more.
So, is hyper ledger fabric considered as centralized blockchain or maybe decentralized blockchain?
Thanks
If you mean decentralised as in not controlled by any one entity and anonymous then no, it is not that.
Fabric is the backbone of blockchain applications and certain things are plug and play. it is not meant to be anonymous, it is meant to be controlled and only known parties have access to anything.
It's simply an eco-system which allows anyone to build blockchain based applications. Imagine a system where your bank holds your money and you want to pay someone. The bank needs to make sure that you are who you say you are and no one else can authorise payments from your account. That's what the permissions mean. It's not meant to bypass the man in the middle like bitcoin or other cryptocurrencies are. Those however are just an implementation of a block chain system, they are not the only way you can use such a system though.
The immutability of the ledger offers certain advantages. Imagine an audit system where every action is recorded and can't be changed. If your audit records are in a sql database for example, anyone with access can go in, change or delete that data. What goes on the ledger stays there for ever and can't be change. This doesn't mean that your asset data cannot change. That is a fundamental thing to understand. Underlying data can be changed via a new transaction against the same asset, but the history of the asset is clearly visible and can't be modified.
In this world, you build a something, someone controls it, gives access to other organisations and people within those and every action has its source identified.
It is decentralised in the sense that the ledger does not live in one place only, a copy of the ledger exists on every peer that is joined to a channel.
However, it is not meant to be anonymous, all the participants are known and their access level controlled, that's the whole point.
Understand that Interledger is an open protocol suite for sending payments across different ledgers -- supports and integrates with Bitcoin, Ethereum (IS 20022)
Does Interledger supports hyperledger and/or vice versa? i.e., any integration possibilities between Interledger and Hyperledger? i.e., hyperledger <-> interledger <-> ethereum and/or bitcoin?
Understand that Hyperledger does not have cryptocurrency but I might have digital assets within my hyperledger network that can be exchanged with ether or bitcoin.
Thus I wish to know if there are integration possibilities between Hyperledger and Interledger?
Interledger is a protocol, not a system so I would rephrase your question as:
I wish to know if there are integration possibilities between Hyperledger and other ledgers using Interledger?
The answer is yes but this depends also on the use case. What do you mean by "integration"?
Interledger defines some standards for distributed transaction execution according to a two-phase commit strategy. It is specifically well-suited to transfers of digital assets across multiple ledgers because it's resiliency is depends on the economic incentives of the intermediaries to claim the assets that have been transferred to them (and in so doing providing the key to the next intermediary to do the same).
The most important standard is the use of a SHA-256 hash in the prepare request and the pre-image of that hash as the commit trigger of the two phase asset transfer on each ledger. We call the hash a condition and the pre-image the fulfillment.
If you want to perform a transaction that transfers digital assets from a sender on one ledger to a receiver on another ledger then you will first establish a condition that can only be fulfilled by the receiver (i.e. only the receiver knows the pre-image).
This way you can involve an untrusted intermediary that will accept a transfer on the sender's ledger and make a corresponding transfer to the receiver on their ledger. Both transfers are prepared using the condition and when the receiver releases the fulfillment to their ledger the assets are transferred to them.
The intermediary will then have possession of the fulfillment (they observed the assets they transferred to the receiver being committed) and will use the same fulfillment to claim the assets transferred to them by the sender.
Any Hyperledger ledger that can be used to underwrite asset ownership and support this two-phase commit strategy can be used in an Interledger payment.
There are examples of writing smart contracts that do just this in Ethereum so I assume the same could be achieved using Fabric, Sawtooth or any other Hyperledger ledger.
I am not aware of any existing implementations of such a plugin that would allow the reference ILP connector to be run as an intermediary between a Hyperledger ledger and other ILP-compatible ledgers but I'd certainly welcome any efforts to build one and would be happy to assist.
Interledger looks to be a service that wants you to route financial transactions through them. There is some simple sample code for compatible wallets and transactions in JavaScript. Presumably you can do this in any language.
Which leads me to point out that Hyperledger supports smart contracts and applications written in Go, Java, Python, and JavaScript (through the Hyperledger Composer) and so there is a pretty good chance that you can implement an ISO 20022 / Interledger compatible data model and protocol.
HOWEVER
You need to follow best practices and smart contracts should never directly update external services as their is no way of rolling back external service changes if the smart contract sends successful external transactions but then fails for other reasons.
So, you need to design multi-stage transactions in your smart contracts and related applications. Applications will have to coordinate with smart contracts and post on their behalf to other services, recording results in the ledger and triggering next stage updates and transactions.
This allows the blockchain ledger to reflect the reality of external states from Interledger or whatever ISO 20022 compatible service you use.
This all presumes that the other financial institution refuses direct participation with the smart contract and hyperledger blockchain, which is always going to be more efficient, reliable, and secure.
It sounds like you want something like Hyperledger Quilt, which interoperates between different blockchain technologies.
So, let us consider a typical trade finance process flow. Exporter deploys a contract that has conditions of the shipment and a hash is generated once the deployment is finished.
Questions:
1) Where is the contract stored?
2) How other participants such as customs and importer can access this contract?
3) Can we activate participant level access to the contract on the blockchain?
There are several aspects to Ethereum and Hyperledger which make them quite different. Let me give a somewhat simplified answer to not get into too much details and a too long answer.
First of all, Ethereum is primarily a public blockchain that works in a certain intended way. Similarly, the Bitcoin blockchain works in a certain intended way. Hyperledger is not like that, rather it's an umbrella for distributed ledger technologies (in my terminology not the same as blockchain) which all aim to provide a very flexible architecture so that one can build all kinds of ledger-backed systems with pretty much any properties needed. One could compare this to an imaginary Bitcoin umbrella that provides technology to produce own altcoins with pluggable parts for e.g. consensus, blockchain storage, node composition etc. In short, all these aim to solve different problems and one should not think one will fit all.
Coming back to your questions.
1) Where is the contract stored?
Ethereum has contracts (called smart contracts) on the chain, i.e. code is compiled to byte code and the resulting bytes are sent within a transaction to be persisted onto the Ethereum blockchain. This is done once when you deploy the smart contract. After this one can interact with the smart contract with other transactions.
Hyperledger is in theory not defining this, it could be on a ledger or it might not. Take Fabric for instance, it deploys the code into a sandboxed Docker container which then can be interacted with using transactions.
2) How other participants such as customs and importer can access this contract?
Short answer is that they are given access via credentials.
This is in both Ethereum and Hyperledger open for you to decide yourself. We now assume the code in both cases has been deployed as code on the blockchain for Ethereum and as a Docker container in Fabric.
In Ethereum the code is, a bit simplified, publicly accessible/visible which means you need to employ some kind of check to only allow those who should be able to interact with the smart contract to do so. One way is to check the sender (of the transaction) and only allow certain ones. It's similar to traditional systems where one usually needs to authenticate/authorize to be allowed in and see/alter data.
In Hyperledger it would most likely be modelled in a similar manner and e.g. in Fabric there is also the Certificate Authority that hands out certificates that allow access to different parts of the system. E.g. transport, endorsement or transactions.
3) Can we activate participant level access to the contract on the blockchain?
Yes, so each participant in both systems has credentials and the designer of the smart contract can use this to control access.
Also, in Fabric there are channels that partition the ledger which is used for access control.
HTH.
1) The contract resides on the ledger. Whenever a transaction is invoked, the corresponding method in the contract gets executed on all the validating peers.
2) Other participants can access this contract using their pre-defined user credentials, which they can use to enroll themselves and invoke transactions on the contract.
3) Yes, we can activate participant level access to the contract by defining attributes for every user and allowing only those users who possess certain attributes to access specific parts of the contract.
How does Hyperledger Fabric share the private data only among intended parties without revealing the data to the other network participants?
Is it similar to R3's Corda?
Current version of fabric v0.6 does not provide such possibility, i.e. every peer can see the same as the other peers. But there is intention to implement this feature in 1.0 http://hyperledger-fabric.readthedocs.io/en/latest/abstract_v1/
As of Hyperledger Fabric 1.0.0, full support for channels is provided. A channel can be thought of as an overlay network in a larger blockchain network, including a restricted set of peers belonging to selected organizations and an orderer. All transactions are conducted in the context of a channel, and all transaction information is shared ONLY with those peers that participate in the channel.
More information can be found in the documentation.
In Fabric version 1.2, support for 'private data collections' was added, in addition to the concept of 'channels'. Private data collections allow for organizations on a (blockchain) channel to share private data peer-to-peer, with a hash of the private data going on the blockchain. See more details in the private data documentation.
For a comparison with Corda, see this answer.
Since Apple controls the entire hardware/software stack, is it possible to obtain the following (through some type of trusted computing):
the hardware certifies that the software is genuine, non-jail broken iOS
iOS certifies to my server that the app run is an unmodified app
What this achieve is as follows:
when my server sends out data, it is guaranteed that the data can only be used in the way I intend it to be used (since it's running my app unmodified, on an non-jail broken iOS).
This prevents things like a modified app which steals data being transmitted from the server to the client. I realize one could theoretically eavesdrop, but this can be eliminated via encryption.
Thanks!
Briefly, no.
You're talking about Trusted Computing concepts on a platform that does not support TC. IOS does not include anything near Trusted Computing - Remote Attestation. It has no TPM.
The chain of trust established by Apple chip merely tries to stop execution if the signature of the next element in the boot chain is invalid. If one thing fails (jailbroken), their's no real -effective- way of detecting it. It is very similar to Secure Boot introduce by Microsoft but it's very different then Trusted Computing which attest which version of the system it is currently running.
With Trusted Computing, the TPM store the measurements (PCRs) of the system boot (SRTM). At boot, the first thing executed (CRTM - the only thing we really need to trust implicitly) will start the chain by measuring the BIOS, send the measure to the TPM (in a PCR) and pass execution to it (the BIOS). Then the BIOS does the same thing for the next element in the boot chain.
The measurements stored in the PCRs can then be used to encrypt or decrypt information (SEAL/UNSEAL operations) depending on the environment loaded in memory.
The TPM does not take action on the measurements (good or bad). The idea is not to restrain what can be loaded but to being able to know what environment is loaded on the platform. If something has been modified, the TPM will not contain the proper PCRs values and the UNSEAL operation (decrypt using PCRs as the key) will not work.
In the case of Remote Attestation, we're talking about the QUOTE operation. It's basically the same thing then SEAL but uses other keys to make sure the evaluating party can validate the attestation is really coming from a real/compliant TPM.
Sure, a system could use the SEAL operation to protect a secret used to decrypt the operating system and thus produce -in some way- the same effect as secure boot.
For more info, see my other posts.