With Ethereum, gas is an anti-denial of service measure. What is the equivalent in Hyperledger Fabric to avoid abuse of chaincode invocation transactions (INVOKE)? Is the NVP expected to check this abuse?
From what I understood, there is no need for such a gas system in Hyperledger Fabric.
The blockchain is supposed to work in a "private" mode, meaning that you know the other peers in the network. It would be easy to detect a malicious peer and revoke its access. Also, there is no "mining" process, only consensus rules triggered for each incoming transaction. This results in a lighter block generation process compared to Bitcoin or Ethereum for example.
However, you can still implement your own custom gas system with a chaincode that add some kind of "transaction fee" before validating any Invoke transaction, but I don't think it would be possible to "mine" gas in the current state of the project.
Related
I'm trying to combine the core strengths of the two Hyperledger projects, Indy / Aries and Fabric.
In the scenario we have an Indy network for SSI and a Fabric network managing a token. The Fabric token accounts should be tied to the Indy identities. Furthermore, an identity is only allowed to move tokens when it can proof to be an active member of the golf club.
This means, the Fabric endorsers need a way to see the identity's DID and to verify the golf club credential.
Question: Is there a best practice architecture to achieve that?
My current approach is to let the user send a <Proof Proposal>,<Receiver>,<Qty> message via her Aries agent to a server connected with the Fabric network. The server then sends a transaction including this data to all endorsers via the fabric-sdk. Now, the chaincode gets executed at each organisation. The chaincode tells its Aries agent to verify this Proof Proposal, which leads to a huge amount of connection invitations and proof requests against the users agent. Once the verification is successful, the chaincode continues execution and changes the state.
I see several (potential) problems:
The user must accept many connection invitations manually (if there's no hardcoded auto-accept whitelist)
Even you could avoid the connection attempts (maybe /w ephemeral challenges? Documentation for that?), there would still be massive parallel traffic, due to the presentation protocol, incoming from a decently large fabric network.
Here's a visualisation:
Am I missing something? Do you have any hints / experiences about how this can be accomplished?
Kind regards
I'm developing a blockchain solution on Hyperledger Fabric. This solution should be used to provide the interactions bewtween manufacturers and suppliers. I supposed that in this case there should be a single blockchain ledger with information about manufactured goods. This ledger should be used both by manufacturers (to register new goods) and by suppliers (to update goods: for example, mark some item as delivered).
The Hyperledger Fabric official documentation (https://hyperledger-fabric.readthedocs.io/en/release-2.0/fabric_model.html#privacy) says that the ledger is strictly linked with a channel:
Blockquote
Hyperledger Fabric employs an immutable ledger on a per-channel basis, as well as chaincode that can manipulate and modify the current state of assets.
So I intended to create a single channel and install 2 different chaincodes on:
chaincode for manufacturers (to register manufactured goods)
chaincode for suppliers (to mark registered goods as delivered)
But when I prepared a demo application, I revealed, that the second chaincode cannot query the items created with the first one (i.e. each chaincode has an isolated ledger).
How can I deploy the ledger, which should be shared between organizations having various roles (access rights), if I don't want to force all of them (manufacturers and suppliers) to install the full chaincode (containing both 'register goods' and 'mark as delivered' operations) on their environment?
Thanks & Regards
Igor Egorov
Please help me if my conceptualization is incorrect ---
Setup:
I am trying to understand how to achieve decentralization in Hyperledger Fabric - smart contracts. Assume Org 1 and Org 2 are in the same channel. Each of these Org have peers and endorsers. The endorsement policy is 100% of Org 1 and Org 2
Question:
In my understanding the SAME SMART CONTRACT needs to be installed in both Org 1 and Org 2 peer. In other words, So when a incoming transaction is sent to Org 1 and Org 2, the same smart contract is executed by both peers.
Is this understanding correct?
REF: https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/smartcontract.html
In the PaperNet network, the smart contract is shared by the different network participants, such as MagnetoCorp and DigiBank. The same version of the smart contract must be used by all applications connected to the network so that they jointly implement the same shared business processes and data.
If it is correct, the smart contract code must have been written by some developer (Possible Org 1 who originated the blockchain network),How is this decentralization?
I my understanding, In a decentralized environment, should not be there a way where ORG 2 can separately create its own smart contract and install and use that to validate / commit?
If this is possible, any articles / blogs that show how to do this?
As you can see te question is nothing to do with endorsement policies etc.
thanks in advance and please feel free to correct me if my basic understanding of decentralization is incorrect
Regards
VJ
Hyperledger fabric is a DLT(decentralized ledger technology) platform. As from the word DLT, you may understand here ledger is decentralized. So, yes your basic understanding is wrong.
Smart Contract:
Its similar like to real world contract between multiple parties, on which all parties has been agreed(Like a property deed on which both parties i.e. seller and buyer will agree). Similar here in Hyperledger fabric, a smart contract is business logic, on which all parties(all participating organization, in particular channel) have to agree. So, you may say a smart contract will be written by some developer of any organization and all other organization can review the source code and will agree to use that smart contract.
How it is decentralized:
So, in every DLT, ledger is decentralized, i.e. each party will be having their own copy of transactional data.In Hyperledger fabric, each organization is having a peer that contains transactional data and world state.
In my Hyperledger-Fabric application (developed with Hyperledger Composer), I want to prevent participants from being able to look at the old transactions.
Old transactions can be viewed either in the Hyperledger Composer Historian or in the Hyperledger Explorer.
I know how to make old transactions non-visible to participants in the case of Hyperledger Composer Historian (namely in the file permissions.acl). But preventing participants from looking at old transactions in the Hyperledger Composer Historian is not of any use, as long as they can instead view the transaction history in the Hyperledger Explorer.
So my question is this: how can I make the transaction history non-visible to participants in the case of the Hyperledger Explorer?
UPDATE:
Is it possible at all for an organisation to use Hyperledger Explorer without the knowledge of other members of the network?
If it is not possible for one member to use Hyperledger Explorer on the network without the other members allowing it, then the problem is gone anyway.
You can't make participants not being able to access data they have already seen, thus you can't make transaction history disappear from the channel members local peers.
I know how to make old transactions non-visible to participants in the
case of Hyperledger Composer Historian (namely in the file
permissions.acl).
Even if you define access control for clients in the application layer:
All peers in the channel can still see the transactions
Every client that has permission to pull blocks from peers or orderers, can still see the transactions via pulling them itself.
But preventing participants from looking at old transactions in the
Hyperledger Composer Historian is not of any use, as long as they can
instead view the transaction history in the Hyperledger Explorer.
Such a fact should instill doubt in the mind of anyone, and make him/her wonder whether the hiding is of any use, to someone that has access to the blockchain itself.
Here is our use-case:
Anna would like to sell her shares to Peter, and Olga needs to approve it (as an owner of the company).
How would that work on blockchain hyperledger fabric/composer with consensus?
In particular, what part of that is a transaction, what is a proposal (is a proposal requires a physical approval of a transaction by a living person?) and how is that handled on blockchain, what happens in the application and outside of the application.
Please be as specific as possible.
Thanks!
A few things first:
Composer uses whatever consensus algorithm the underlying blockchain is configured to use. So; Hyperledger Fabric at the moment offers SOLO or KAFKA.
KAFKA offers fault tolerance only, not byzantine fault tolerance.
So:
Endorsement Policies do exist which is what you are describing. It does not require approval by a living person, you can make everything programmatic, it could even be an IoT device. The approver must simulate the transaction and see if they agree with the output. Olga is the approver in your scenario.
It's important to make all chaincode (transactions in Composer) deterministic, so they can be simulated in that way.
There is a good description on transaction flow on Fabric's docs: http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
I'm releasing a paper in a month that has a section on consensus comparisons and Composer/Fabric specifically. I can send you a draft if you're interested further.
There are two aspects to your question, one is the approval aspect of a living person and second is the integrity of the ledger state (consensus).
I will explain in the reverse order.
Consensus Part
So Hyperledger Fabric is an enterprise solution that targets to maintain a consistent ledger on which all organization of the consortium needs to agree upon. This is achieved by combining the ledgers of multiple organization into one ledger and the transactions recorded in this one ledger will include transaction from each party.
These transactions are not random transactions but rather implementation of Smart Contract called chaincode in Fabric terminology. Whenever a chaincode is deployed on a Fabric channel(a private subnet associated with its own ledger) it initializes the World State i.e default assets and their values.
Next each organization agree upon an endorsement policy, for example 1 peer from each organization should endorse the transaction(called transaction proposal in this state), the endorsement is simply a read-write set of the transaction having read set(values of assets before transaction simulation), write set(values of assets after the transaction simulation). If the endorsement from all peers(all those peers that satisfy the endorsement policy) is same, which means the world state of assets is consistent across all the peers(atleast those that satisfy endorsement policy) and hence ledger data integrity is achieve.
The consensus further includes batching transactions into blocks and ordering of the transactions within the block by ordering service which validates the endorsers signatures again and the World State validation is done one final time when the block reaches peers for committing.
Approval part
When you have an approval process that requires a participant interaction, it is something that you will have to take care of in your chaincode. Composer is the best place to start.
From Composer examples look at the CarAuction example and you will understand the for each state transition you will have to have registery e.g a seller participant owns an asset Car but when the Car is auctioned for selling it has to be added to a listing registry using transaction where it will be visible to all bidder participants, this movement of state of Car asset is achieved by a transaction AuctionMyCardOrSomething invoked by authorized party here seller. Then when the Auctioneer(another participant with a different role) executes another transaction called closed bidding then the Car ownership can be transferred to the highest bidder if all conditions are satisfied. Node that placing a bid is also a transaction.
Pay attention the the Auctioneer and state transitions in this example and the same model can be applied to your case. Each time state transition is required you have to execute a transaction and update the ledger.
Hope this helps.