I ask this question because I want to facilitate a workflow that utilizes a managed blockchain service such as the Azure or AWS blockchain service.
Is the true purpose attestations, provenance and interoperability?
In that aspect, aren't regular (legacy and or current) methodologies sufficient for data interoperability and the transfer and consumption of said data?
Lastly, if all this effectively is doing is creating a ledger account of data flow would a true advantage be the encryption of the data existing on the entire flow including up unto the edge?
If it cannot be encrypted up to the edge so that it is not readable at any point in time of the data flow into the data archive/traditional store is effectively worth any of the previous described gains of provenance and interoperability?
I think there is some nuance to this answer. The purpose of Azure Blockchain Service is to allow enterprises to build networks (consortiums) that enable the business workflows. The unique value that blockchain is adding to business workflows is a logical data model/flow with infrastructure shared to the participants (businesses). That is not easy to do with a traditional database model.
With regards to the encryption you mentioned above, the value with blockchain is providing a digital signature for every change in the system that is shared between enterprises. The typically is done at the client to provide the least chance for manipulation. Privacy, which can use encryption techniques, is something that can be used to allow participants to control access to change details. The fact that changes were made is still cryptographically verifiable, without sharing all the data details with everyone.
If you look at something like EDI that is done today with supply chains, this essentially is a complex network of enterprises, synchronizing databases. This typically suffers breakage of keeping all these things in sync. With a blockchain based system, the "syncing" is abstracted and the focus is more about the business logic, which is always cryptographically signed and verifiable. So it functions like a single "logical" data store, but is actually distributed.
Related
I am starting to learn about blockchain. After reading about the main concepts composing a blockchain network, I have some doubts that I am not able to solve despite performing many searches on the internet.
On the one hand, it is clear that transactions are grouped into blocks and the miner node that solve the consensus algorithm is the one putting the block in the distributed ledger. However, I have read that Ethereum (usually used for cryptocurrency with Ether) could be used as blockchain platform for different applications such as food traceability, assets management, etc. In this case, all these applications are using the same distributed ledger, i mean, the Ethereum distribution ledger can store different kinds of blocks, i.e. blocks from a food traceability application, from the assets management one or those derived from cryptocurrency?
On the other hand, I understand the role of smart contracts but it is not too clear for me which is the difference among the consensus and contract layer and when smart contracts are needed.
Could you help me with these doubts?
Thank you in advance for your help
Can the Ethereum distribution ledger store different kinds of blocks, i.e. blocks from a food traceability application, from the assets management one, or those derived from cryptocurrency?
Food traceability, assets management, cryptocurrency, whatever the use case or name you provide at the marketing layer will have no effect on the stored data in a smart contract that runs on EVM. For example, if you use postgresql as your backend database for your next food delivery or asset management app does that changes how postgresql stores data in blocks, it's internal data representation, its indexing mechanism, or its query interface?
When smart contracts are needed?
The need for smart contracts is to provide permanent, transparent logic in a programming language like solidity, vyper which gets converted to bytecode, and only that bytecode is deployed in the network (Internally, it's just a transaction sent to zero address). In return, you get the contract's address to interact with the contract's ABI and you do have that permanently with its state.
Additionally, the consensus layer will be handled by eth-node implementation so don't worry about it. You may have a look at layer 2 scaling in later phases.
More reading should help:
Mastering Ethereum
Ethereum Yellow Paper
By default someone can read the state data using REST API. Is there a way to add read permissions on specific addresses and change them while the network is up.
The short answer to your question is by using a proxy server, the documentation you're referring to in the question mentions it here https://sawtooth.hyperledger.org/docs/core/releases/1.1/sysadmin_guide/rest_auth_proxy.html#using-a-proxy-server-to-authorize-the-rest-api
There may not be an out of the box component that does what you're asking. There's definitely possibility of doing what you're asking for. You can add the logic filtering based on the read address in the proxy server.
More explanation:
If you're considering one Validator instance per organization. Organization participates in a blockchain application use case then all the participants in the network can see the data you store in the state store. It's the responsibility of the participating organizations to restrict the access to their data. Using the proxy server is one such means.
If you're considering adding multiple use cases per organization, participating in different network altogether then it is advisable to have a different Validator instance per those use cases that require isolation. Again, it's the responsibility of each organization to protect the data stored in the network they're participating in.
For the point 2, the Hyperledger Sawtooth 2.0 proposed solution allows you to run multiple instances of the Validator as a service in a single process. That means you can have one physical node (also process) participating in multiple circuits providing isolation.
Before I end the answer for the benefit of others searching for an answer: Blockchain is not just a distributed storage but also a decentralized network. There are number of design patterns that allows us to keep the critical data outside the blockchain network and use the functionalities of the blockchain network (achieving consensus, smart contract verification to be specific) for what it is expected to do.
Everything I've been reading about blockchain from my understanding says that even on a private blockchain, every participant can view all transactions. I've seen it mentioned that a use case for block chain could be the sharing of medical data. So for example if I had a blockchain that holds the medical history of every person from birth to death in a country. Is there no way of setting up permissions so that only data relating to a person and those who have been given permission to that person's data can view it? If the data is stored on every node in a blockchain, how is a person's computer supposed to have the capacity to store the medical data of every person in a country?
I would advise looking up Medrec when related to health care. Most of the research is geared towards dealing with keeping the data off the chain. In addition, there are other blockchains that might provide a better solution, for more privacy, for example, I would look up quorum by JP Morgan. There are different formats being looked at but these can give you two possible solutions. Also, check out Health Nexus' whitepaper, it deals with medical blockchain technology. Let me know if you need more.
https://www.pubpub.org/pub/medrec
https://github.com/jpmorganchase/quorum
There are blockchains that allow defining permissions. Hyperledger Fabric is one of them. You have the ability to configure channels with data stored in the ledger of the participants in the channel only.
to pass the scalability problem of blockchains and their solutions for this purpose, you should concentrate on off-chain architecture.
right now this scenario should be considered:
save tx's to the blockchain(it should be formal)
save hashed data to an off-chain repository like DB's.
save the address of that data-hash to blockchain for future access.
yeah, you pointed to the right thing. a central point of access as an admin-node or god should be the opposite of blockchain as a distributed dream.
for this issue, the mechanism like secret-sharing or re-encrypt proxy should be realized to guarantee the privacy and security of data-hashed.
for more information read this article:
https://www.sciencedirect.com/science/article/pii/S2210670717310685
GoQuorum has an 'enhanced permissioning' model where you can do all that, and at the same time stay compatible with Ethereum standards.
Check this out: https://consensys.net/docs/goquorum/en/latest/configure-and-manage/manage/enhanced-permissions/
I understand that the BigChainDB is a distributed DB at the basic level.
It claims that is solves the problem of Scalability in the BlockChain world. What i don't understand is that how it fits into the overall block chain architecture.
In the typical Block Chain world, each node has the full copy of the
data and validates any new transactions? How does this work in the
BigChain DB when the data is distributed? Each node validates only the
blocks that it holds? Even if thats the case, it needs the entire
chain? Not clear on the processing scalability here.
Can i build a block chain network just with the BigChainDB or do i
need something like Ethereum or Hyperledger to build the block chain
network itself?
If i can build the blockchain network with BigChainDB, then what is
the equivalent of smart contract in BigChainDB?
BigchainDB internally uses RethinkDB as a datastore. Technically, the blockchain is stored as JSON strings inside RethinkDB. And BigchainDB is a kind of wrapper on top of this storage which provides the needed cryptography, techniques for building the blocks, parsing the blocks and provides utility methods to access the database. RethinkDB provides clustered storage with possible shard based architecture. This makes BigchainDB scalable when RethinkDB is configured accordingly.
Yes. It is possible to build a blockchain network just with BigchainDB.
BigchainDB library provides APIs to be called from our code. So we can build any application(preferably in Python) and integrate BigchainDB into it. This means, the business logic stays inside our application code. This is totally different from Smart contracts used in Ethereum.
You can have a look at my github code for more insights. It is my college project and not much documentation is available :-D It is a voucher transfer application where company like Sodexo issue vouchers and users can redeem it in private companies like Starbucks.
I am not clear about the actual advantage of having iRODS or any other low level storage management. What are it's benefits exactly and when should we use it?
In Fedora-commons with normal file system low level storage:
a datastream created on May 8th, 2009 might be located in the 2009/0508/20/48/ directory.
How does iRODS helpful here?
I wanted to close the loop here, for other Stack Overflow users.
You posted the same question to our Google Group https://groups.google.com/d/msg/irod-chat/fti4ZHvmS-Y/LU8CQCZQHwAJ The question was answered there, and, thanks to you, the response is now also posted on the iRODS.org FAQ: http://irods.org/faq/
Here it is, once again, for posterity:
Don’t think of iRODS as simply low level storage management.
iRODS is really the only platform for policy managed data preservation. It does indeed virtualize storage, providing a global, logical namespace over heterogeneous types of storage, but it also allows you to enforce preservation policies at each storage location, no matter what client or access method is used. It also provides a global metadata catalog that is automatically maintained and reflects the application of your preservation policies, allowing audit and verification of your preservation policies.
iRODS is developing a powerful metadata management capability, allowing pluggable indexing and query capability that allow synchronization with external indices (e.g. Elastic Search, MAUI, Jena triple store).
With the pluggable rule engine and asynchronous messaging architecture, it becomes rather straightforward to generate audit and provenance metadata that will track every single (pre- and post-) operation on your data, including any plugins you may develop or utilize.
iRODS is middleware, rather than a prepackaged solution. This middleware supports plugins and configurable policies at all points, so you are not limited by a pre-defined set of tools. iRODS also can be connected to wide range of preservation, computation, and enterprise services, and can manage large amounts of data (both in number of objects and size of those objects), and efficiently move and manage data using high performance protocols, including third party data transfer protocols.
iRODS is built to support federation, so that your preservation environment may share data with other institutions or organizations while remaining under your own audit and policy control. Many organizations are doing this for many millions of objects, many thousands of users, and with a large range of object sizes.