i have a current channel of hyperledger fabric with chaincode that does CRUD operations my question is that is there any way to make a method in a chaincode that registers the new user when certain condition match.
You can use one of several methods to get the identity of the user:
GetCreator
GetId
GetMSPId
They are part of the Client Identity Chaincode Library, documented here: https://pkg.go.dev/github.com/hyperledger/fabric-chaincode-go/pkg/cid#section-readme
The Hyperledger Fabric docs provide some help for access control also if you're interested in that: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html?highlight=getmspid#private-data-sharing-patterns
Related
I am playing around with the ERC20 token implemented in fabric-samples. I was wondering if it is possible to not only send tokens between users but have deployed chaincodes receive/hold/send tokens as well. Hence allowing users to send tokens to a specific chaincode and vice versa. This is a very common thing on other blockchains like Ethereum.
To realize this I tried to invoke the erc20 chaincode from my own chaincode via InvokeChaincode and noticed that its documentation states
InvokeChaincode: Locally calls the specified chaincode invoke()
using the same transaction context; that is, chaincode calling
chaincode doesn't create a new transaction message.
which implies to me that chaincode in fabric does not have its own identity but the identity of its callee. Which in turn would make the use case described above impossible...
During researching this problem I stumbled across some old posts briefly mentioning this topic. E.g. here and here. Interestingly SignedProposal seems to contain information regarding the "original" chaincode called by the user. Theoretically, this information could be used in a modified ERC20 contract to identify a specific chaincode but this seems to be a bit hacky to me.
Am I missing something here?
I would appreciate any help. Thanks.
One last thought of mine - but not directly connected to my question: In general just "forwarding" the user's identity to other chaincodes seems to be quite critical from a security point of a view, right?. An adversary could theoretically hide such cross invocations in chaincode and use the callees identity to steal e.g. these ERC20 tokens.
I am using Hyperledger Fabric v2.2 with multiple organizations setup. I want to join a new organization to an existing channel. The problem is in signing channel update.
Fabric docs says that there are two main implementations of signing:
“pass it along” - admin of Org1 signs channel update and sends in to Org2 admin, Org2 admin signs and sends to Org3 and so on, until enough signatures will be collected.
"The other option is to submit the update to every Admin on a channel and wait for enough signatures to come back. These signatures can then be stitched together and submitted. This makes life a bit more difficult for the Admin who created the config update (forcing them to deal with a file per signer) but is the recommended workflow for users which are developing Fabric management applications."
All samples that I found describes only the first implementation. But how to do it with the second? I found the related code in HLF Node.js SDK v1.4 but can't find the same for v2.2.
I had the same doubt, until I saw this here.
The Fabric v2.x SDKs only support transaction and query functions and event listening. Support for administrative functions for channels and nodes has been removed from the SDKs in favor of the CLI tools.
No more admin function starting from v2.x tho. Not sure if I answered your question.
In Hyperledger ledger, how could I list endorsing peers of a specific chaincode?
I have a channel with 5 peers but I need that only three of them endorse a transaction while the other two need only to access to same ledger.
You can use the discovery service to get the endorsing peer. Here you can find some information:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-overview.html
Hyperledger fabric has a CLI tool to query the discovery service:
https://hyperledger-fabric.readthedocs.io/en/latest/discovery-cli.html
For node.js applications, you can follow the tutorial here:
https://hyperledger.github.io/fabric-sdk-node/release-1.4/tutorial-discovery.html
With the latest Fabric Client SDKs (personally using GO client), you don't need to deal with endorsement policies. Client SDK already does this dirty work for you. It extracts:
Which organizations' endorsements are required for this chaincode, key (key level endorsement policy can be defined as well), etc.
Which peers currently exist in the system and what are their MSPs (from discovery service).
According to these information, client SDK builds a set of necessary peers then sends your transaction request to all. It waits response from requested endorsers. Once it collects all responses, it sends to orderer and so on.
If you have a special case which you need to manually set endorsing peers of your choice (I had one use case about private collections so I had to use this approach) check out discovery service API of your client SDK.
Does Hyperledger Fabric support possibility to create a cryptocurrency like well know Bitcoin/Ethereum?
I don't mean tokens which I can implement by chaincode.
You can implement any business logic by using Hyperledger Fabric chaincode, which essentially a simple program. Chaincode manages ledger state by operation on transactions submitted by application and ensure to have it consistent across network peers.
Hyperledger Fabric currently supports chaincodes written in Go, while in a future will be added support for nodeJS and Java. Chaincode interface defined as following:
// Chaincode interface must be implemented by all chaincodes. The fabric runs
// the transactions by calling these functions as specified.
type Chaincode interface {
// Init is called during Instantiate transaction after the chaincode container
// has been established for the first time, allowing the chaincode to
// initialize its internal data
Init(stub ChaincodeStubInterface) pb.Response
// Invoke is called to update or query the ledger in a proposal transaction.
// Updated state variables are not committed to the ledger until the
// transaction is committed.
Invoke(stub ChaincodeStubInterface) pb.Response
}
So you can implement your cryptocurrency into chaincode. To get an inspiration on how you can implement it, you might want to take a look on following demo application of balance-transfer.
There is a Token feature in the alpha release of 2.0, you can check it out: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html#fabtoken
Also check here for
Can we create non-fungible tokens with Hyperledger?
The platform-neutral Token Taxonomy Initiative overseen by the Enterprise Ethereum Alliance (EEA) has announced the publication of the Token Taxonomy Framework (TTF) V 1.0, which enables businesses and developers to universally understand and define what a token is in non-technical terms, regardless of how it is implemented.
When triggering a transaction with the "composer-cli" one has to specify the "enrollId" and the "secret" to be able to send the request. So transaction is fired in the context of a given fabric-user.
I was asking myself if there is a way to map the identity of the fabric-user firing the transaction to a given "participant" from the Participant Registry (in the composer JS code, which implements business logic)?
Are these two layers of authentication completely separated? If yes, then how is one supposed to identify in the JS code that a given participant (in composer terminology) is firing the transaction? Thx.
Please refer to the docs here:
https://fabric-composer.github.io/managing/identity-issue.html
The issue identity / revoke identity CLI commands are used to map a Fabric user to a Composer participant.