Corda Developer Bootcamp: Accounts
Download as PPTX, PDF0 likes124 views
The document outlines a series of questions and considerations related to the implementation and management of accounts in a Corda blockchain environment. It discusses the need for account-based models to improve scalability and reduce operational costs for businesses, particularly smaller ones, and presents various use cases for accounts. Additionally, it details the lifecycle of accounts, key management, and integration with existing Corda applications.
![Questions we want to answered [Not shown]
• Where is Account stored?
• Who is really signing the transaction when I am an account?
• Am I visible to the participants on the network?
• Does the other participants required to have account, if one of the participants want to use
account.
• How is Account mapped/linked with the state?
• What are the problems accounts is trying to solve?
• Can I easily migrate from node based model to account based model and again migrate
from an account based model to a node based model?
• Typical life cycle of an account?
• How can offchain identity be mapped to onchain accounts identity?
• What are the typical use cases when we would want to use accounts?
• Roadmap of accounts
• Can tokens and accounts be integrated](https://image.slidesharecdn.com/accountworkshop-200722080401/85/Corda-Developer-Bootcamp-Accounts-2-320.jpg)
![Introducing Corda Accounts
So that:
• A Corda node can host multiple “individuals/small companies” who wants to play a role in a
larger blockchain system. [Increase scalability]
• Consortium can “represent their customers” via accounts, while only spinning up minimal
numbers of nodes depends on the use-case. [Reduce operation cost]
An accounts library allows a Corda node operator to split the
vault into multiple "logical" sub-vaults.](https://image.slidesharecdn.com/accountworkshop-200722080401/85/Corda-Developer-Bootcamp-Accounts-4-320.jpg)
![Life Cycle of an Account (Part I)
Account creation & sharing with counterparties:
1. Create Account
2. Share AccountInfo with counter parties
In the flow:
1. Retrieve the account and request a new set of Public/Private key pair for the transaction
2. Request the signing keys from counterparty’s account.
3. Share the transaction’s output state with the counterparties if we expect the state will be used as an input
for any further transactions. [Optional]
4. Record the transaction to corresponded accounts in responder flow](https://image.slidesharecdn.com/accountworkshop-200722080401/85/Corda-Developer-Bootcamp-Accounts-12-320.jpg)
Corda Developer Bootcamp: Accounts
- 2. Questions we want to answered [Not shown] • Where is Account stored? • Who is really signing the transaction when I am an account? • Am I visible to the participants on the network? • Does the other participants required to have account, if one of the participants want to use account. • How is Account mapped/linked with the state? • What are the problems accounts is trying to solve? • Can I easily migrate from node based model to account based model and again migrate from an account based model to a node based model? • Typical life cycle of an account? • How can offchain identity be mapped to onchain accounts identity? • What are the typical use cases when we would want to use accounts? • Roadmap of accounts • Can tokens and accounts be integrated
- 3. The Problem We Had… • Corda was not designed to deploy and operate by individuals and small businesses. (such as, a local corner candy store or my friend Roger) • Most Cordapp developers will represent their customers. When the number of customers goes up, the total cost of spinning up a node for every customer becomes costly.
- 4. Introducing Corda Accounts So that: • A Corda node can host multiple “individuals/small companies” who wants to play a role in a larger blockchain system. [Increase scalability] • Consortium can “represent their customers” via accounts, while only spinning up minimal numbers of nodes depends on the use-case. [Reduce operation cost] An accounts library allows a Corda node operator to split the vault into multiple "logical" sub-vaults.
- 5. High Level Pictorial Explanation… NODE A VAULT ACCOUNT ONE ACCOUNT TWO KEY MANAGEMENT SERVICE Stores key pairs KEY HASH1 : ACCOUNT ONE, NODE A KEY HASH2 : ACCOUNT ONE, NODE A KEY HASH3 : ACCOUTN TWO, NODE A KEY HASH4 : ACCOUNT X, NODE B IDENTITY SERVICE NO ACCOUNT Maps key pairs to node identities and account ids Level 1 Level 2Level 3
- 6. Points to note… • Accounts are not Corda Identities – they are a different representation of a collection of states and public keys. • Account creation, discovery will be implemented on the Cordapp level. (Not from the network level) • Vault isolation is not supported – all accounts share the same node service and keys are all stored in the same key management service. • Node operator will know it all. • Standalone HSM private/public key management for accounts is not supported.
- 7. Pictorial Representation Of Accounts
- 8. Use-Cases… • Host multiple customers per node • Custody-like accounts, brokerage accounts, bank accounts, etc. • Internal separation between departments of large companies • Isolate sensitive information from non-involving departments. • Massive adoption of 2C application • private record per consumer.
- 9. Under the hood of accounts… • AccountInfo & AccountService • Life cycle of an Account • Account APIs
- 11. AccountInfo & AccountService Link: <Path of Account Repository>/workflows/services/AccountService.kt
- 12. Life Cycle of an Account (Part I) Account creation & sharing with counterparties: 1. Create Account 2. Share AccountInfo with counter parties In the flow: 1. Retrieve the account and request a new set of Public/Private key pair for the transaction 2. Request the signing keys from counterparty’s account. 3. Share the transaction’s output state with the counterparties if we expect the state will be used as an input for any further transactions. [Optional] 4. Record the transaction to corresponded accounts in responder flow
- 13. Life Cycle of an Account (Part II) Querying the Vault: 1. Create a new query criteria 2. Perform query to return all desired states for account with specified accountId
- 14. DOORMAN NODE Node / Party / First Class Identity Certificate generated and signed by node and then signed by Doorman. Used by node operators. Node operators might be companies that also participate in states on the ledger. However, the state which they participate in would only be through accounts. Account A Party and label pair. Where Party represents a host node and label represents some Party/application scoped identifier. There is also a UUID which should be unique at the network level. Labels are only guaranteed to be unique at the node / Party level. However, when they are coupled with a Party, they are guaranteed to be unique. ACCOUNT NODE NODE PUBLIC KEY ACCOUNT IDENTITY AccountInfo Name: String Host: Party ID: UniqueIdentifier PublicKeyToExternalID When new PublicKeys are created on the host node, they will be allocated to the UUID for a particular Account. As such, Accounts will be associated to multiple PublicKeys. This is how the node keeps track of which states should be allocated to which Account. ACCOUNT Services / CorDapps When new PublicKeys are created on the host node, they will be allocated to the UUID for a particular Identifiable. As such, Identifiables will be associated to multiple PublicKeys. This is how the node keeps track of which states should be allocated to which Identifiable. ACCOUNT ACCOUNT ACCOUNT ACCOUNT IDENTITYIDENTITY Identity Represents the identity of a “user”. Identifiables do not have a Doorman provisioned identity. Instead, they only have an identity in the context of a Party node (that does have a Doorman provisioned identity). These identities are, in effect, self signed. Noes/parties can attest to the claims made in the Identifiable state. AccountInfos are ledger states so that they can be easily shared with other nodes. Holistic view
- 15. Code Example Let’s go to IntelliJ …
- 16. Try it Yourself Java version: https://github.com/corda/samples-java/tree/master/Accounts Kotlin version: https://github.com/corda/samples-kotlin/tree/master/Accounts Supply Chain: This CorDapp mimics a supply chain transaction, where the deal is incorporated among different teams in the companies on both side of the trade. Tic Tac Thor: This CorDapp recreates the game of Tic Tac Toe via Corda. It primarilly demonstrates how you can have linear state transactions between cross-node accounts. Worldcup Ticket Booking: This CorDapp demonstrates an ticket booking system with a collaboration of Corda Account Libray and TokenSDK.
Editor's Notes
- #2: Some Introdcution
- #4: What are the problems accounts is trying to solve?
- #5: Does the other participants required to have account, if one of the participants want to use account. What are the typical use cases when we would want to use accounts?
- #6: Where is Account stored? Am I visible to the participants on the network?
- #7: Who is really signing the transaction when I am an account?
- #11: How is Account mapped/linked with the state?
- #13: Typical life cycle of an account? How is Account mapped/linked with the state? Can I easily migrate from node based model to account based model and again migrate from an account based model to a node based model?
- #15: How can offchain identity be mapped to onchain accounts identity? Roadmap of accounts
- #16: Can tokens and accounts be integrated
- #17: Can tokens and accounts be integrated