When transactions need to be signed by multiple parties in cordapp, how they are singed ??
They manually sign off cordapp?? Or Is there some api which supports sign by multiple parties??
Please spend some time exploring this example: https://github.com/corda/samples/tree/release-V4/cordapp-example
The initiating node signs the transaction: https://github.com/corda/samples/blob/018502310b56bc1bb31440380af4b89e9bbd7ed8/cordapp-example/workflows-kotlin/src/main/kotlin/com/example/flow/ExampleFlow.kt#L85
The initiating node requests signatures from other participants: https://github.com/corda/samples/blob/018502310b56bc1bb31440380af4b89e9bbd7ed8/cordapp-example/workflows-kotlin/src/main/kotlin/com/example/flow/ExampleFlow.kt#L91
Other nodes (in responding flow) sign the transaction: https://github.com/corda/samples/blob/018502310b56bc1bb31440380af4b89e9bbd7ed8/cordapp-example/workflows-kotlin/src/main/kotlin/com/example/flow/ExampleFlow.kt#L112
Related
Corda as a platform, how handles whether the person wants to do transfer an asset from one account to another is the owner of the account or not?
Or some other user who have access to node can also access to any account present on node.
If you look at AccountInfo state which is the core of the accounts library; it has an attribute host, that's the node that hosts the account (the node where the account was created).
The host is the Party that signs on behalf of the account, by signing with its key.
So for instance if the host is the initiator of the flow, then they can sign on behalf of the account like this: (first you call accountKey = RequestKeyForAccount(); then getServiceHub().signInitialTransaction(txBuilder, accountKey.getOwningKey()); .
Now, in general when an initiator calls CollectSignaturesFlow so that the responding nodes sign; every node that responds will check the requested keys in the transaction and sign that transaction with all the keys that are requested and it owns.
Following the point above, if the initiator wants to collect the signatures of 10 accounts that are hosted on another node; you don't need 10 FlowSession's with the host node, you create only one FlowSession and pass it to CollectSignaturesFlow. The node (which is the host of the 10 accounts) will see in the responder flow that all 10 requested keys are owned by it, so it will sign with all 10 keys (meaning the host node signed on behalf of the 10 accounts).
If those 10 accounts were hosted on different nodes (let's say 5 accounts on PartyA and 5 account on PartyB); then you have to create 2 FlowSession's (one for PartyA which will sign on behalf of 5 accounts, and one for PartyB which will sign on behalf of the other 5).
Now back to your original question:
If you are using the Tokens SDK:
If you are using the ready flows (e.g. MoveFungibleTokens()); then only the node that hosts the "from-account" can initiate the flow. This way the node that hosts the account signs the move transaction; which requires (by contract) the signature of the current holder (i.e "from-account"), and since the node that initiated the flow hosts that account, it can sign on behalf of it. The ready move flow (MoveFungibleToken()) doesn't have a CollectSignaturesFlow() call inside of it, meaning you cannot start that flow to move tokens that belong to an account that's not hosted on the initiating node, because that flow doesn't collect signatures of other nodes, so it cannot collect the signature of the "from-account" (i.e. the current holder of the tokens) because it's hosted on a different node.
So the only way to use a flow to move accounts of a "from-account" that's not hosted on the initiating node, is by creating a flow yourself which will use the utility functions of the Tokens SDK (e.g. addMoveFungibleTokens()) and then take care of collecting the signature of the "from-account" using CollectSignaturesFlow where the host signs the transaction in the responding flow.
If you're not using the Tokens SDK, then like in the last point above; you have to create a transaction manually and make sure that you collect the signature of the "from-account" by calling the CollectSignaturesFlow where the host of the account signs on its behalf in the responder flow.
Our app allows authenticated users to send and receive digital coins from each other in the app. Each user has a coins field which stores the current coin balance of a user. To transfer coins, we use firestore transactions at the sender's end to subtract the value of coins from the sender and then add the value to the receiver's balance. Hence, while the sender is logged in, they have to make writes to the receiver's document. This approach is insecure since we only check if the sender is logged in. This enables any authenticated user to have write access to another user's document.
Is there a much better/secure approach to implement such kind of transactions between users and is it possible to handle the problem only using firestore security rules in this situation?
In this scenario, you wouldn't want to give users write access to each other user's documents, or even their own "wallets". Doing this type of transaction all in the client side (e.g. using Firestore iOS/Android/Web SDK) will likely cause security issues down in the road. Of course, not many users will be aware of it, but tech savvy users who finds out that they have write access to other users' Firestore documents as long as they are signed in, will start deducting and taking coins from other users' wallets.
You will probably need to setup a server, or a script which will use Firebase Admin API to run transaction that you are talking about, so that it will be done in a black box according to your users' point of view.
Once you have the server up and running, client side app will then need to make calls to the server, preferably with auth tokens (e.g. Firebase Auth User's token), and ask for the transaction to run.
Do you have to be a known party on the network to make a transaction?
Can an anonymous user off the network interact with the blockchain?
When joining the network, a node needs to obtain a network certificate provided by the network's doorman. This certificate ties the node to a specific real-world identity. When messaging other nodes, a node must use this certificate to allow the receiving nodes to verify who they are transacting with.
However, suppose a node is working with other nodes to build a transaction. Although the node must reveal its identity to the other nodes they are building the transaction with, it can choose to identify itself in the transaction being built using an anonymous one-time public key, rather than a real-world identity.
This means that the node's identity is not stored on the ledger for all to see, and is only known to the nodes with whom the transaction was originally built.
You can also imagine scenarios where even though the node's identity is well-known, the identity of the actual user is not. For example, a node representing an auction house may place a bid on the behalf of an anonymous user.
Link that I referred is:
Corda: User interaction for verifying the transaction request received from the initiator node
In this case, the propose flow should be signed by both parties, right?
And same way the Accept/Reject should be signed by Initator and Reciever ?
Can anyone please let me know how to retrieve the state using an attribute other than linear id?
The set of public keys that is required to sign a transaction is given by the union of all the public keys listed on all the commands in the transaction.
For querying a state by custom attributes, see https://docs.corda.net/api-vault-query.html. You need to create a VaultCustomQueryCriteria, which requires your state to implement the QueryableState interface.
Is there an example for issuing and transferring tokens (fungible assets) on Corda?
Can someone please sketch at high-level how this would work?
I am especially interested in the following aspects:
How does Corda prove that a party owns the tokens (representing cash or securities)?
Can we keep transactions private? Especially:
Only sender and receiver know that transaction took place and with which amount.
Receiver doesn't see the total balance of the sender.
Sender doesn't see the total balance of the receiver.
By tokens I assume you are referring to fungible assets (one token is the same as another token). In corda this is modeled using contracts - the contract defines the token/assets behavior. For an example of this you can see cash here https://github.com/corda/corda/blob/master/finance/src/main/kotlin/net/corda/finance/contracts/asset/Cash.kt.
To prove a party owns the tokens corda uses notaries. Each state (an instance of a token - defined in the tokens contract) is checked for validity by the notary, which is done by simply running your contract verification code. You can simply have an ownedBy field for each token state as is done with cash, and require in the contract verification code that the party that put in the cash state owns this cash.
In terns of keeping transactions private, I recommend you take a look at using the swap identities flow. essentially for each transaction a new public/private key pair is generated only known by the parties involved - see https://docs.corda.net/api-identity.html#confidential-identities.
Hopefully this answers your questions/sets you on the right path