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
Related
I am experimenting with Hash Time-Lock Contracts in Corda, using the Corda account-based model. It seems to me that, to transact with an account, you must always obtain an Anonymous Party to serve as its public key, via subflow RequestKeyForAccount. And it seems that you will always obtain a different key each time you RequestKeyForAccount, even for the same account.
Assuming the above statements are correct, I am finding it impossible to implement the contract, as the contract must be able to identify whether the public key invoking it belongs to the "locker" or the "lockee" party. The Anonymous Party will always be different, and will never match either the "locker" or the "lockee," because it will be different every time I invoke RequestKeyForAccount.
I have also tried tackling the problem in a different way, by storing "locker" account and "lockee" account in my persisted state - but, the contract does not have access to the account that is invoking it. It has access to the signers - which are AbstractParties. The account invoking the transaction does not seem obtainable.
Bottom line, I cannot implement a contract that tries to ascertain whether the account invoking it matches a particular account stored within the associated state, due to the random anonymized values returned by RequestKeyForAccount; and due to the inaccessibility of account when all I can access are the signers of the transaction, i.e. AbstractParties. I'd appreciate if somebody can tell me if I am off-base in any of my statements.
Always remember that Accounts in Corda are only logical entities. They do not sign transactions and they do not invoke flows in the cordapp. It's their hosting node that does it on behalf of the accounts they own.
So, as also stated in training.corda.net, if you want to restrict access to certain states to a particular account, you have to manage it outside of Corda (for example, create a RPC user that is linked to an account at application level, with the needed restrictions):
Data access restrictions, i.e. restricting users (i.e. Corda accounts) to interact only with states that they own, is the CorDapp developer's responsibility as implementing them is outside of Corda’s scope.
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.
Hi is Corda a recommended platform for Digital Identity? For a use-case of Account based-Certification. (i.e. i as a user store my certificates/Identity on the ledger and access it via a password/key where i would go through a node, at the same time to allow a specified certificate only to be seen by a specified party. Where the control is on the user/account level and not a node level. Which means i could specify which certificate/identities i would want to allow another organisation to access)
for blockchain technologies I understand that the data is duplicated across all nodes as long as the user have the key the user can access his own data even if the node is a newly joined node to the network.
As i understand also Corda doesn't support multiple identities on a single node as it is node basis. What will be the approach for this case using Corda platform?
first of all - Corda is not like Ethereum, Fabric and any other blockchain where all nodes store same common state. In Corda network nodes store only transactions and states they were participating in or observing. So its more peer-to-peer rather than broadcast.
Check here for more details:
https://docs.corda.net/key-concepts-ledger.html
From this perspective Corda is probably not the best candidate for public Identity network.
For solution about self-sovereign identity management I would recommend to have a look at something like Sovrin(Indy). You can use it to build app on top of the platform. Or just learn their design ;)
Corda may have sense in Identity context if there are different organisations and they exchange its members identity info for some reason. Then node will be Identity Manager and store info about people who gave it its credentials of any kind. So Identity will be mere state here, I think. Corda itself will play transport and storage role. Not a blockchain-style decentralized way at all but may be useful in some cases.
Can a third party node view the details within a state without being a participant in the transaction that created that state? The idea is that the transaction created between two nodes is sent to a third node as CC. We don't want to add the third node as a participant since it does not have the right to consume that state.
Any node can see the contents of a transaction if that transaction is sent to it.
Normally, you'd write your flows such that only the relevant parties see the transaction. However, if for whatever reason a third party needs to also see the transaction, you can easily send it to them by including the third party as an additional recipient in FinalityFlow.
Although the third party won't store the transaction in their vault (as they can't spend it), it will still exist in their transaction storage and can be viewed that way.
P.S. Who the transaction's output states can be consumed by depends on the rules imposed by the contracts, and not who the listed participants are.