The task is to transfer assets from fabric to another blockchain. For the unlock/lock token contract, it is necessary to come up with a place to store tokens for the time of their blocking. I decided to store them on the client's account. The bottom line is, can I store data on in contact and can I assign a certificate to the contract as a user, for example as in eth? And the contract uses its own certificate when interacting with other contracts.
If there is documentation or code examples, I will be glad of any answers and examples. And then we have already entered a dead end.
Smart contracts in Fabric do not invoke other smart contracts in the way that I think you are describing. While a smart contract can use and invokeChaincode API call to invoke another smart contract, which is done within the scope of the current transaction and can only augment the read/write set of that transaction. If successful, this endorsement / simulation of the transaction is signed by the peer that received the transaction proposal from the client.
In short, smart contracts do not (or at least should not) interact with other smart contracts as if they are a client using their own client identity.
There is some documentation here that might help clarify:
https://hyperledger-fabric.readthedocs.io/en/release-2.2/developapps/chaincodenamespace.html#cross-chaincode-access
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 trying to implement a smart contract where a member of an organization can submit a proposal document (this is a simple text that will be recorded in the state), other orgs can vote on it (approve/reject), and if the majority have approved, the proposal gets accepted.
The documentation about transaction flow and the accepted answer here suggest that endorsement of transactions should not encode "business logic", i.e. a transaction that "plays by the rules" should get endorsed.
Therefore, I want to implement this approval/rejection process on the smart contract level. In this model the proposal, as well as each vote is a separate transaction. Then, the proposer can submit another transaction to count the votes and finalize the proposal.
For this, I need to get the list of organizations that are member of the channel. How can this be done within a smart contract's functions?
You would need to be able the chaincode smart contract to retrieve the latest configuration block from the peer/orderer and then parse that block to get the list of organizations.
This means you'll need a way to send the private key of a client into the chaincode invocation.
To send the private key of a client, it's better to have a dedicated MSP only for that client, so the MSP will be not included in any endorsement policies, or other channel config policies for security reasons.
Then, to parse the config block you can follow the code here.
Note that you cannot use a QSCC query inside a chaincode, although it is tempting to do so, because chaincode-to-chaincode invocations with QSCC are fobidden.
I have some questions regarding the deployment of a HLF use case. Suppose we build a platform in which users sell items. The users and their items are stored on the ledger via chaincode. The purpose is to also enforce access control on the items via the chaincode, so that another user for example cannot see a specific item. Then the 2 options regarding the whole identity management are:
The users do not have certificates in Fabric, and all transactions made by the users are forwarded to a single registered Client who interacts with the chaincode. Therefore, the transaction context will always have this client's ID. So from my point of view the username should be always passed to each transaction and implement access control using this username, though a registered Client has full authority over their data.
Every user is registered and enrolled and have their own identity. Every user makes a transaction directly on the blockchain via the chaincode, and access control can be implemented easily by using the stub.ID() and other attributes. That would mean that >100k users would be registered on a CA or multiple CAs.
The questions are:
Is HLF intended and suitable for the 2nd option, or is it made solely for the purpose of interaction between clients of organizations?
Is there a best way to handle this matter?
A ledger stores facts about the history of transactions that led to the current state of an object. The history also stores the users responsible for the current state of the object. If the state of an object is being changed, the admin/authorized user of an organization must be able to see who performed that change.
In the first approach, if you want to see the details of the user doing the "transaction", you'll have to store it somewhere different from the blockchain. While that can be a use-case of your project, it defeats the purpose of storing all facts about the history of a transaction of an object as every time the same user would be doing the transaction.
The second approach fulfills all the motives of incorporating blockchain in a project. Sure, you'll have to register and enroll every user who's creating/modifying an asset but then Access Control Management can be done in a better way. Please read about ACL to know about the granular access you can achieve in Hyperledger Fabric.
Also, you can also encode some information about a user in its x509 certificate with ASN.1
Second option is more preferred and Hyperledger Fabric ca could handled number of user registrations. There is Attribute access control also available which you can use at chaincode level to control use access.
https://www.youtube.com/watch?v=CAXRMJ-quhg
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 am currently working in projects using Fabric 1.4 I am able to get a decent idea of how things seems to work out but I am quite confused with the way smart contracts and endorsement policies work together.
What i have understood is that endorsement policy is defined during chaincode instantiation where say two or three orgs will sign a transaction in order for it to be valid. This kind of an endorsement just verifies the transaction signatures right ? no data level checks.
Like say I have this kind of a scenario: I have three orgs(Org1,Org2,Org3) each with a peer. Now through a client web app each peer puts data into the blockchain. Now how do I verify if the data (the information that I submit in the blockchain) say for example the name and id are validated by another peer properly and only then added to the world state.
Example: If peer0 in org1 adds data, name and id and the ID is wrong. Org2 has a list of IDs and it should check if the ID that org1 added matches with it and validates it. If it validates then it is fine and data can be put it in the world state
How to define this kind of a transaction state level validation (more of a data level validation rather than just signature verification)? Can this be done in the Go smart contract.
Any help and suggestions would help.
Thanks
During the endorsement, each selected endorser executes (or simulates) the transaction and returns its response, read set and write set signed. The client checks signatures and that responses from different endorsers match (or at least it should do it, anyway this check is performed later again by committers), so there are data level checks (your premise is wrong). The client assembles all the endorsements into a transaction and broadcasts it so it reaches to the ordering service. The ordering service adds the transaction to a block and the block is send to every (committer) peer joined to the channel. The committers perform their checks again and commit the transaction into the state.
It is perfectly explained here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html.