Hyperledger Fabric transaction payload visible in ordering node - blockchain

I would like to know if transaction payload in Hyperledger Fabric transaction flow is visible to the ordering nodes.
The goal is to create a private channel, where only the owners of the peers have the possibility to see the payloads and therefore what is saved in the ledger, while we would like to increase the decentralization of the network by distributing the orderer nodes to multiple organization, but it is important that these orderer nodes never know the transaction payload and what is saved on the blockchain.
In my opinion is something possible but I would like to be sure because is a crucial point of the architecture's design.

Orderers do see the data recorded in the ledger by a transaction. If it really isn't practical to have orderers owned by the same set of organisations that own network peers, you might be able to use private data collections:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html
Data stored in private collections is shared directly between peers with permission to view that collection, and only a hash of the data is stored in the main ledger and visible to orderers.

Related

presence of bitcoin addresses on blockchain

I recently read some where the speaker mentioned bitcoin doesn't store addresses in the block chain. If addresses do not exist on the blockchain, how can you check their balances on - for example - blockchain com?
Payment addresses stored within transactions, and transactions stored within blockchain. Thus, speaker is not right - addresses stored in the blockchain, and by scanning the blockchain, you can fetch all activity for any address. Of course, balance - just result (sum) of all activities.
However, Bitcoin (or other bitcoin-like crypto) does not build it's own address index, and there is impossible quickly fetch balance or activity history for some specific address directly from a node. Explorers scans blockchain and build his own transaction history withing his own database. Of course, when new block comes in, explorer updates his own DB, and by this way - he maintains actual history for all accounts.

How would the data schema of bitcoin look like?

Since bitcoin is a blockchain and blockchain has been described as a kind of database, how would the data schema of bitcoin look like? Is it a single table database? If yes, which columns are inside this table?
The data is stored in an application-specific format optimized for compact storage, and wasn't really intended to be easily parsed by other applications.
See https://bitcoin.stackexchange.com/q/10814
For this custom format, see https://en.bitcoin.it/wiki/Protocol_documentation#block
There are various databases for various usages. As a reference client I would use bitcoin-core and describe its standard structure that is stored via the client. It actually uses "leveldb" and "berkleydb-4.8" for storing all kind of data.
Wallet database
Saves your transactions, generated public/private keys. That is usually encrypted ;)
Source: Wallets
Index Database
It's usually OPTIONAL, but usually stores a list of all transactions and in which block they occurred
Block Database
It's the most important db which locally stored and share via the network to communicate about newly created blocks and verify them. Every client has a copied version of it.
They usually store all blocks that ever occurred and also include fork-off blocks and also obsolete blocks.
Source: Blockchain / Transactions
Peers Database
Obviously there also is a database for all peers you have seen in the past. It rates each peer by giving it a ban-score, stores their IP addresses, ports and last seen status.
Conclusion:
That would be all databases. They mostly have "one table" which includes exactly the previously described data structures.
More information about the p2p network structure can be found right here.

Store data off-blockchain using a smart contract

I found a paper which is talking about a way to store data off-chain using the blockchain. The data are sent to the blockchain with a transaction which subsequently routes it to an off-blockchain store, while retaining only a pointer to the data on the public ledger.
In particular the paper says:
Consider the following example: a user installs an application that uses our platform for preserving her privacy. As the user signs up for the first time, a new shared (user, service) identity is generated and sent, along with the associated permissions, to the blockchain in a Taccess transaction. Data collected on the phone (e.g., sensor data such as location) is encrypted using a shared encryption key and sent to the blockchain in a Tdata transaction, which subsequently routes it to an off-blockchain key-value store, while retaining only a pointer to the data on the public ledger (the pointer is the SHA-256 hash of the data).
What I cannot understand is how they do it! If all the nodes on the blockchain have to execute that very transaction, it means that they all have to save those information off-blockchain causing a duplication of contents. Did I get it wrong?
After a quick glance at the paper in question, it makes no mention of storage replication. The use case they are describing here is to use blockchain transactions as references to physical data that is stored somewhere. The data can be accessed by anyone who has the reference to it; i.e. access to that particular blockchain system, however the data is encrypted such that only parties with the encryption key can actually decipher it. This approach allows for quick validation of data integrity while maintaining privacy.
From the perspective of the blockchain node all they see is a transaction that will be added to their local ledger, they don't actually save the data themselves.

Data storage on Corda

I am working on a use case. The requirement being I need to create an order. The order has some customer parameters. The order can be modified multiple times. Initially, I thought of implementing it in Ethereum. So, I thought of capturing the customer details from a UI and store it on the smart contract. However, the issue is once the contract is deployed I cannot change it since it is immutable. This drawback prevents me to use Ethereum. Deliberating on Corda, can I store the customer data as a single records and make modifications to it such that modifications are stored on the ledger which we can query. For instance, I want to store customer ID, Customer name, customer purchase order number, order type, and order status.
How would I do that in Corda data model?
Will that data be modifiable based on the rules coded on smart contract?
The data can be queried?
Yes.
In Corda, you store information using States. In your case, you might create a CustomerDataState class. You'd then create instances of this class on the ledger to represent your various customers.
This data can then be updated using transactions. But not all transactions are allowed. Which transactions are valid is based on the rules in the associated CustomerDataContract. The CustomerDataContract will be stateless, and simply exists to say how CustomerDataStates can evolve over time.
You can then easily query this data from your node's vault or transaction storage using an SQL-style syntax.

What is registry and how do we use to register our assets / chaincode in hyper-ledger fabric?

I am trying to understand about registry, like what is registry, why do we need to store Assets and Chaincodes in registry, where does registry gets stored.
Firt of all, the chaincode (or smart contracts) and the assets are two different things.
Chaincode: the code that you will execute/invoke. This code is the same in all the nodes, i.e. each node of the network has installed the same chaincode.
Assets: you digitize the assets using transactions that are governed by smart contracts.
On the other hand, how it works:
Ledger: the Ledger stores all the transactions. The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks. Each peer maintains a copy of the ledger.
State Database: maintains the current state. It represents the latest values for all keys ever included in the chain transaction log. Chaincode invocations execute transactions against the current state data.