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.
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.
Does Corda node support the concept of an organization and users in the organization? The ORG user must have visibility to transactions of the node. And is it possible to add users within this Organization who can be part of selected transactions?
Yes, you can do it with Corda. I see two ways:
Use the Account library. Accounts are "logical" entities, i.e. subset of the node's vault. An ORG can be the Corda node and the users can be accounts owned by the node, which has complete visibility of the transactions. You can add as many accounts as you want. Note that an account only has public keys, the private keys are owned by the Corda node owner of the accounts. The flows are effectively ran by the Corda node, not by the Account themselves who are just effectively states that only have a name and a set of public keys (but not a X.509 identity, so they are not registered to the network. Only the Corda node is). A typical use case of this is a Group Company X (i.e the Corda node) who owns some Subsidiary Companies (its accounts). More info: https://training.corda.net/libraries/accounts-lib/ and https://github.com/corda/accounts/blob/master/docs.md
Use the Business Network Membership: https://docs.corda.net/docs/corda-os/4.8/business-network-membership.html. In this case you have different Corda nodes connected to the same network, and a subset of these node share a "logical" network, which is made at application level in which you can set the roles and memberships. In pratice, this is a cordapp shared between them where there are states that identify an organization and its rules.
These two above are ways to effectively create "organizations". In Corda then you also have the Observer parties, who are parties that just want to be notified of some transactions without effectively be part of them.
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.
How the uniqueness of a corda accounts is maintained across the network. As far as I know a corda account has the following features
* name (Unique inside the Node)
* UUID (Unique across the network)
* Host (which hosts the account)
So from above 3 how will a Node ensures that there is no accounts with same UUID in a network? or how a Node generates a UUID when a new request to create an account comes? is there a place in network map to hold the account info?
You can safely assume that the account uuid will be unique across the network as uuid's provide 128 bits of entropy, and because of this its highly unlikely that someone else will have the same uuid within the network.
A new account can be created using inbuilt CreateAccount flow. The node generates and assigns a uuid to this account using UUID.randomUUID().
Account discovery is different than node discovery which uses a network map. Once the account is created it is expected by the node either to share this account info with the counterparty using inbuilt flow ShareAccountInfo or alternatively the counterparty can request account info using inbuilt flow RequestAccountInfoFlow.
Hope that helps.
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.