In bitcoin world,
Eric sends 1Bitcoin to Bob
This transaction is stored as ledger in nodes.
Is it a normal transaction data or a block ?
How multiple transactions are written in a block ?
Before miner mines a block, how transactions are stored in this block ?
Blockchain is a decentralized ledger.
In Blockchain each transaction generates a hash value.
Blockchain has a concept called a transaction pool. When we perform a transaction, this is held in a transaction pool. These transactions from transaction-pool are gathered to candidate block by a miner and later it is added to blockchain.
Related
I am having difficulty understanding how Hyperledger Fabrics' execute-order-validate work. Can someone provide a specific examples and compare/contrast that against an order-execute architecture?
https://www.ibm.com/blogs/research/2018/02/architecture-hyperledger-fabric/
order-execute architecture
Order: Transactions are added to the ledger in some order and disseminated to all peers.
Execute: Transactions are sequentially executed (e.g. using smart contract code) on all peers.
execute-order-validate architecture
Execute: Transactions are executed (using chaincode) in any order, possibly even in parallel.
Order: When enough peers agree on the results of a transaction, it’s added to the ledger and disseminated to all peers. This step is where the transactions are first given an ordering — until transactions are added to the ledger, there’s no concept of one transaction happening before or after another.
Validate: Each peer validates and applies the ledger’s transactions in sequence. Now that the transactions have an ordering, the peers can check whether a later transaction was invalidated by an earlier transaction. For example, this prevents one item from being sold two times (called double-spending).
https://medium.com/kokster/hyperledger-fabric-endorsing-transactions-3c1b7251a709
In bitcoin and Ethereum, all peers execute the transactions in a block, after the transactions have been ordered in a block.
Thus, they operate in a "Order-Execute-Validate" blockchain.
In Fabric - you only need to execute the transaction in a subset of the nodes and not on all of them, and the transaction is executed speculatively and sent to ordering.
what does it actually mean when we say endorsing peer simulates a proposed transaction. Why does endorsing peer needs to hold smart contracts to simulate proposed transaction ?
So, keep in mind that the transaction flow works as follows:
The client sends a transaction proposal to some peers, with input parameters for the transaction, such as: "please move 20$ from alice to bob"
The peers run the transaction in the chaincode container, and afterwards sign the output of the transaction: "this is the new balance of alice, and the new balance of bob"
The client sends the transaction that contains the results and the signatures of the peers to the ordering service
The ordering service puts the transaction into some block
The peers pull the blocks from the ordering service or from other peers, and then commit the transaction (if it's valid) into the database.
Therefore, the transaction is not committed in the peers at the time of its execution, but instead - it's "simulated". Meaning - the peer runs the transaction in a simulation where the reads from the database are normal database operations that read data, but the writes to the database are not actually being written during the transaction execution - but instead, they are recorded as "simulation results" which the peer signs and returns to the client
I am wondering that how your data is safe when an admin can change the latest state in Couchdb using Fauxton or cURL provided by Couchdb directly.
According to my understanding Hyperledger Fabric provides immutable data feature and is best for fraud prevention(Blockchain feature).
The issue is :- I can easily change the data in couchdb and when I query from my chaincode it shows the changed data. But when I query ledger by using GetHistoryForKey() it does not shows that change I made to couchdb. Is there any way I can prevent such fraud? Because user will see the latest state always i.e data from couchdb not from ledger
Any answer would be appreciated.
Thanks
You should not expose the CouchDB port beyond the peer's network to avoid the data getting tampered. Only the peer's administrator should be able to access CouchDB, and the administrator has no incentive to tamper their own data. Let me explain further...
The Hyperledger Fabric state database is similar to the bitcoin unspent transaction database, in that if a peer administrator tampers with their own peer’s database, the peer will not be able to convince other peers that transactions coming from it are valid. In both cases, the database can be viewed as a cache of current blockchain state. And in both cases, if the database becomes corrupt or tampered, it can be rebuilt on the peer from the blockchain. In the case of bitcoin, this is done with the -reindex flag. In the case of Fabric, this is done by dropping the state database and restarting the peer.
In Fabric, peers from different orgs as specified in the endorsement policy must return the same chaincode execution results for transactions to be validated. If ledger state data had been altered or corrupted (in CouchDB or LevelDB file system) on a peer, then the chaincode execution results would be inconsistent across endorsing peers, the 'bad’ peer/org will be found out, and the application client should throw out the results from the bad peer/org before submitting the transaction for ordering/commit. If a client application tries to submit a transaction with inconsistent endorsement results regardless, this will be detected on all the peers at validation time and the transaction will be invalidated.
You must secure your couchdb from modification by processes other than the peer, just as you must generally protect your filesystem or memory.
If you make your filesystem world writable, other users could overwrite ledger contents. Similarly, if you do not put access control on couchdb writes, then you lose the immutability properties.
In Hyperledger Fabric v1.2, each peer has its own CouchDB. So even if you change the data directly from CouchDB of one peer. The endorsement would fail. If the endorsement fails, your data will not be written neither in world state nor in the current state.
That's the beauty of a decentralized distributed system. Even if you or someone else changes the state of your database/ledger it will not match with the state of others in the network, neither will it match the transaction block hash rendering any transactions invalid by the endorsers unless you can restore the actual agreed upon state of the ledger from the network participants or the orderer.
To take advantage of the immutability of ledger you must query the ledger. Querying the database does not utilize the power of blockchain and hence must be protected in fashion similar to how access to any other database is protected.
You need to understand 2 things here
Although the data of a couchdb of a peer maybe tampered, you should setup your endorsement policy in such a way that it must be endorsed by all the peers.
You cannot expose your couchdb to be altered, I recommend to see Cilium
As explained by others - endorsements/consensus is the key. Despite the fact that ledger state of an endorsing peer can be modified externally - in that event all transactions endorsed by that peer would get discarded, because other endorsing peers would be sending correct transactions (assuming other's world state was also not tampered with) and consensus would play the key role here to help select the correct transaction.
Worst case scenario all transactions would fail.
Hyperledger fabric's world state (Ledger state) can be regenerated from the blockchain (Transactions Log) anytime. And, in the event of peer failure this regeneration happens automatically. With some careful configuration, one can build a self-healing network where a peer at fault would automatically rise from ashes (pun intended).
The key point to consider here is the Gossip Data dissemination protocol which can be considered as the mystical healer. All peers within the network continuously connect, and exchange data with other peers within the network.
To quote the documentation -
Peers affected by delays, network partitions, or other causes resulting in missed blocks will eventually be synced up to the current ledger state by contacting peers in possession of these missing blocks.
and ...
Any peer with data that is out of sync with the rest of the channel identifies the missing blocks and syncs itself by copying the correct data.
That's why it is always recommended to have more and more of endorsing peers within the network and organizations. The bigger the network - harder it would be beat with malicious intent.
I hope, I could be of some help. Ref Link: https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html
Even though this is plausible, the endorsement policy is the general means by which you protect yourself (the system) from the effects of such an act.
"a state reconciliation process synchronizes world state across peers on each channel. Each peer continually pulls blocks from other peers on the channel, in order to repair its own state if discrepancies are identified."
just playing with Hyperledger Composer, and I'm wondering ,Where is the blockchain physically
I'mean is it binary file , text file ....?
is it portable ?
thank you all
There are two place which "store" data in Hyperledger Fabric (the underlying blockchain infrastructure used by Composer which is a runtime abstraction layer above it):
the ledger
the state database ('World state')
The ledger is the actual "blockchain". It is a file-based ledger which stores serialized blocks. Each block has one or more transactions. Each transaction contains a 'read-write set' which modifies one or more key/value pairs. The ledger is the definitive source of data and is immutable.
The state database (or 'World State') holds the last known committed value for any given key - an indexed view into the chain’s transaction log. It is populated when each peer validates and commits a transaction. The state database can always be rebuilt from re-processing the ledger (ie replaying the transactions that led to that state). There are currently two options for the state database: an embedded LevelDB or an external CouchDB.
As an aside, if you are familiar with Hyperledger Fabric 'channels', there is a separate ledger for each channel.
The chain is a transaction log, structured as hash-linked blocks, where each block contains a sequence of N transactions. The block header includes a hash of the block’s transactions, as well as a hash of the prior block’s header. In this way, all transactions on the ledger are sequenced and cryptographically linked together.
The state database is simply an indexed view into the chain’s transaction log, it can therefore be regenerated from the chain at any time.
Source: http://hyperledger-fabric.readthedocs.io/en/release/ledger.html
Suffice to say, Hyperledger Composer uses Fabric (as the blockchain infrastructure) to endorse/order/commit transactions to blocks on the ledger.
To see the physical location of these data you can go to /var/hyperledger/production in each peer container in your fabric network
Actually, the blockchain is a shared database, which is read-only and append-only. And it is distributed in every peers. So every peer has a copy of the shared database. Normally, LevelDB or CouchDB is used in HyperLedger Fabric.
The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks, as well as a state database to maintain current fabric state.
Here is more information about HyperLedger Fabric Ledger (the blockchain)
Blockchain is shared among all the peer to peer networks hosting it. So basically blockchain is stored in many HDD all around the world.
What are the main difference between chain and state database in Hyperledger fabric. I'm confusing whether they both are same.
There are two place which "store" data in Hyperledger Fabric:
the ledger
the state database
The ledger is the actual "blockchain". It is a file-based ledger which stores serialized blocks. Each block has one or more transactions. Each transaction contains a read-write set which modifies one or more key/value pairs. The ledger is the definitive source of data and is immutable.
The state database holds the last known committed value for any given key. It is populated when each peers validates and commits a transaction. The state database can always be rebuilt from re-processing the ledger. There are currently two options for the state database: an embedded LevelDB or an external CouchDB.
As an aside, if you are familiar with Hyperledger Fabric channels, there is a separate ledger for each channel as well.
The chain is a transaction log, structured as hash-linked blocks, where each block contains a sequence of N transactions. The block header includes a hash of the block’s transactions, as well as a hash of the prior block’s header. In this way, all transactions on the ledger are sequenced and cryptographically linked together.
The state database is simply an indexed view into the chain’s transaction log, it can therefore be regenerated from the chain at any time.
Source: http://hyperledger-fabric.readthedocs.io/en/release/ledger.html