I'm currently trying to figure out on couple of things
1) What blockchain databases can be integrated with hyperledger fabric – (such as IPDB, or Bigchain db or couchDb)
2) What distributed file systems can be integrated with hyperledger fabric (such as IPFS, StorJ, Swarm).
can someone add your views, if there is anything better please share.
There are no such limitations, many people use integration patterns with various other technologies, for example:
Clients can write data to a distributed file system or database and then put a link and/or hash of the data on the Fabric blockchain as permanent evidence of the data.
Clients can listen for block events on a Fabric peer, and as blocks are committed to Fabric, write the data to another distributed file system or database.
The possibilities are endless.
Related
For the past few days i am trying to learn blockchain, more specifically in using hyperledger fabric
However, while i am quite familiar building centralized app, i am so new in grasp this whole new concept, and got some question in mind i haven't found answer, yet.
If its decentralized, does the script will run as desktop background process in every machine connected to the network through internet?
Since
no way it could be "decentralized" if its hosted on 3rd party server
blockchain platform seems could seamlessly write/read local files, which certainly not possible at the case of hosted in 3rd party server
existing blockchain application (i.e bitcoin) written for desktop (c++)
If it does desktop process, in the case of creating website interface to run the application, do we need API to communicate? And if so, how the API could be made to communicate between all machine in the network?
Moreover in the case of storing sensitive data like password, since its stored locally in every machine, does it means we will rely only on encryption being used? I assume common AES256 will work? Or need multi layer encryption (as in XMR) to make it harder for people trying to decrypt those sensitive information?
Any input is greatly appreciated. Thank you in advance!
I'll answer your questions for Hyperledger Fabric since that's what you tagged this post for.
Presumably the "script" you mean is chaincode, the blockchain back-end part of the decentralized application. It runs on endorsers (part of Fabric peers), specifically all endorsers that are specified in the endorsement policy and have installed the chaincode. The endorsement policy specifies how many endorsers need to agree for chaincode transactions to go through, i.e. 3/5. These peers can be hosted by multiple organizations in different places, that's why it's decentralized.
You need to use the Hyperledger Fabric SDK to communicate with your chaincode (get data, send transactions).
Decentralized apps don't really use user-password combo for identity management. Users have public/private keypairs which they need to keep locally. Only if you want to encrypt the private key you'd need a password for the user to decrypt it locally. You use the private key to sign transactions and to authenticate with the network (which determines your access rights, i.e. user vs admin)
I can recommend the Fabric paper as a learning resource
Also check out the docs, they cover many of your questions
I would recommend first taking a step back and finding out what are the best use cases for Web3 vs Web2. There are a number of projects that seem to have been shoehorned into using Web3 when they could have been created more quickly and efficiently using
Web2 technologies.
Ask yourself these questions before jumping on board the decentralized Web3 bandwagon:
Is an Immutable Ledger the Best Fit for Your Back-end?
Does Your Back-end Work Best as Decentralized Computing?
Do You Need Scalability or High Transaction Volumes?
Only when you understand the problem you are trying to solve, can you determine the best technologies for the job.
To help answer the above questions, you can use the following article as a resource: https://www.scalablepath.com/back-end/choosing-web3-for-software-project
I have a problem with understanding why Hyperledger Fabric (HLF) uses blockchain structure.
I know that in Bitcoin blockchain structure ensures big security due to PoW algorithm and longest chain rule, but what are advantages of using a blockchain structure in HLF?
It seems to me that in Hyperledger Fabric, instead of the blockchain structure, there could be one transaction history log and network could work in the same way - I bet I'm wrong, but I haven't been able to find an explanation yet.
I would be grateful for the clarification of this issue.
I think a lot of questions you have in your mind comes from the overlapped definitions of DLT and blockchain.
DLT:
A DLT is simply a decentralized database that is managed by various participants. There is no central authority that acts as an arbitrator or monitor. As a distributed log of records, there is greater transparency – making fraud and manipulation more difficult – and it is more complicated to hack the system.
All of this could well be familiar because it’s written about the features of blockchain as well.
Blockchain:
Blockchain is nothing else but a DLT with a specific set of features. It is also a shared database – a log of records – but in this case shared by means of blocks that, as the name indicates, form a chain. The blocks are closed by a type of cryptographic signature called a ‘hash’; the next block begins with that same ‘hash’, a kind of wax seal. That is how it is verified that the encrypted information has not been manipulated and that it can’t be manipulated.
DLT platforms that are not blockchain provide immutability too, but it's just the way Hyperledger Fabric provides this characteristic which makes it a blockchain framework.
Every blockchain framework, be it the Ethereum, Bitcoin, etc all store the transaction information in blocks, where each block is linked to its predecessor by a hash and provides immutability.
Corda is very much similar to Hyperledger Fabric, but it is said to be both a blockchain and not a blockchain. Architecturally, it's very much similar to Hyperleder Fabric, but with only a key difference which makes Hyperledger Fabric a blockchain framework, and Corda a DLT.
I'll try to answer your question by emphasizing on the point that why Corda is not a blockchain.
Why is Corda a blockchain, and not a blockchain?
A Transaction in Corda is cryptographically linked (chained) to the transactions it depends on. Just like Bitcoin, but the range of concepts that can be expressed is far wider.
Transactions in Corda are processed by having each participant in the transaction execute the same code deterministically to verify the proposed updates to the ledger. Just like Ethereum, but the languages you can use are high-level and productive, like Java, rather than obscure ones like Solidity.
Transactions in Corda are shared only with those who have a need to know. Just like channels in Fabric but designed in from day one and fully integrated into the programming model.
Transactions in Corda are confirmed through a process of consensus forming using one of a range of algorithms, including Byzantine Fault Tolerant algorithms. Just like any other blockchain, but with the unique features that a Corda network can support multiple different consensus pools using different algorithms.
So, for all intents and purposes, Corda is a blockchain. And yet… there’s also an utterly critical difference.
Unlike the platforms mentioned above, Corda does not periodically batch up transactions needing confirmation — into a block — and confirm them in one go. Instead, Corda confirms each transaction in real-time. No need to wait for a bunch of other transactions to come along. No need to wait for a “block interval”. Each transaction is confirmed as we go.
Now coming onto your question why Hyperledger Fabric (HLF) uses blockchain structure? The answer is simply because they chose to.
References:
https://www.bbva.com/en/difference-dlt-blockchain/
https://cointelegraph.com/news/what-is-the-difference-between-blockchain-and-dlt
https://www.corda.net/blog/corda-top-ten-facts-7-both-a-blockchain-and-not-a-blockchain/
To keep the record immutable, Hyperledger Fabric uses blockchain structure. So by using Hyperledger Fabric, you can get an immutable record of all the transactions which is tough to temper with fraudulent activities.
Suppose you buy an valuable asset and you are the current owner of that asset. Now it is very hard for others to temper that records or change your ownership without your permission as Hyperledger Fabric uses blockchain structure to keep the record immutable.
We are currently researching on Hyperledger Fabric and from the document we know that a private data collection can be set up among some subset of organizations. There would be a private state DB (aka. side DB) on each of these organizations and per my understanding, the side DB is just like a normal state DB which normally adopts CouchDB.
One of our main requirements is that we have to distribute files (e.g. PDFs) among some subset of the peers. Each file has to be disseminated and stored at the related peers, so a centralized storage like AWS S3 or other cloud storage / server storage is not acceptable. As the file maybe large, the physical copies must be stored and disseminate off-chain. The transaction block may only store the hash of these documents.
My idea is that we may make use of the private data collection and the side DB. The physical files can be stored in the side DB (maybe in the form of base64string?) and can be distributed via Gossip Protocol (a P2P protocol) which is a feature in Hyperledger Fabric. The hash of the document along with other transaction details can be stored in a block as usual. As they are all native features by Hyperledger Fabric, I expect the transfer of the files via Gossip Protocol and the creation of the corresponding block will be in-sync.
My question is:
Is this way feasible to achieve the requirement? (Distribution of the files to different peers while creating a new block) I kinda feel like it is hacky.
Is this a good way / practice to achieve what we want? I have been doing research but I cannot find any implementation similar to this.
Most of the tutorial I found online pre-assumes that the files can be stored in a single centralized storage like cloud or some sort of servers, while our requirement demands a distribution of the files as well. Is my idea described above acceptable and feasible? We are very new to Blockchain and any advice is appreciated!
Is this way feasible to achieve the requirement? (Distribution of the files to different peers while creating a new block) I kinda feel like it is hacky.
So the workflow of private data distribution is that the orderer bundles the private data transaction containing only a hash to verify the data to a new block. So you dont have to do a workaround for this since private data provides this per default. The data itself gets distributed between authorized peers via gossip data dissemination protocol.
Is this a good way / practice to achieve what we want? I have been doing research but I cannot find any implementation similar to this.
Yes and no. Sry to say so. But this depends on your file sizes and amount. Fabric is capable of providing rly high throughput. I would test things out and see if it meets my requirements.
The other approach would be to do a work around and use IPFS (a p2p file system). You can read more about that approach here here
And here is an article discussing storing 'larger files' on chain. Maybe this gives some constructive insights aswell. But keep in mind this is an older article.
Check out IBM Blockchain Document Store, it is the implementation of storing any document (pdf or otherwise) both on and off chain. It has been done.
And while the implementation isn't publicly available, there is vast documentation on it's usage, can probably disseminate some information from it
The title practically says everything.
In a near future I'm going to implement a real-time tracking system using possibly, a blockchain, and for certain reasons Hyperledger Fabric seems to be the chosen technology. After the information is recorded, it should be accessible in a map in a web application.
So the question is: If we save every one or two minutes the location of a truck to the blockchain using gps, it will hurt the general performance of the blockchain in a near future? (milions and milions of registers)
In the end I have to decide if I should save this information in the blockchain or, knowing that it would cause some serious issues, leave that information out of it and use an hybrid system with a classic database for that and a blockchain for other functionalities that won't cause performance issues.
Thanks.
There is no storage limitation on the Fabric Ledger other than the disk space. The current value of a key (say, the latest position of the truck)can be read via Fabric query which are saved in the world state for quick retrieval. There is also mechanism to look up the history of a key quickly via the historyDB that Fabric maintains.
It's my understanding that everything Hyperledger fabric offers can be done on regular database software.
For example, "smart contracts" are analogous to stored procedures. Also, there are some existing pieces of "distributed database" software that appear to be equivalent to what fabric can do. For example, the X-Road project from e-Estonia.
EDIT: I've been told a better example of a distributed database is Apache CouchDB. How is this "Distributed Ledger" idea different from CouchDB?
When does Hyperledger fabric offer an advantage?