I would like to ask your help and suggestion about below use case what are related to our new business case, a CorDapp which will be used to manage software license usage and management.
Does Corda has a pre-defined structure or approach to define the parent and child relationship between different states, for example, one contract state(main contract) has two child contract states(two types of license contracts)
If we want to track the license usage on blockchain, is that a good direction to ownable state for licenses? Our current thought is Party A(License Provider) and Party B(License consumer) has one agreed contract that Party A will provide Party B 100 licenses to be used, but charge will only happen after one license is activated by Party B. So from Corda’s backend process, Party A will issue 100 licenses initially which owner is PartyA, and this shared fact will be initialized as a transaction and will be added to both party’s ledger. Then periodically license usage data will be extracted from Party A’s system and updated the ledger by initializing a transaction, we will use “Move” flow to transfer the license state’s amount and owner. For example, if Party B activated 40 licenses, then Party A’s license state amount will become to 60, and there is another new state which owner is Party B and amount is 40. I thought I should use ownable state for this use case after reading some Corda documentation about linear state and ownable state, but not sure whether my understanding is correct
What is the best practice from Corda about how to design a dynamical contract terms which can be used in smart contract(verify menthod conditions). For example, in the initial version of license management process, two types of licenses and their price will be defined as contract terms, and we plan to define them as the state’s properties(meta data). If later there are one new type need to be added, how should we best handle this situation. Is there any dynamical approach to define the state’s properties/meta data? Our ideal approach is initially there is no any terms defined(no license type pre-defined), and allow user to add different type of license with their price information dynamically on UI, then these dynamically defined contract terms will be stored in CorDapp and can be used in later phase, and this approach can be easily to be “copied” to different providers. Is this possible to do?
Very interesting use case and scenarios. We have not formalized best practices for parent child states in api wrappers, but you can treat the collection of states using the same relational database model as long as your transactions also keep pointers updated.
Our thinking for state representation covers 3 hierarchical scenarios:
1 - portfolio of assets - like an etf or index grouping multiple assets. This can be moved as a new portfolio asset representing a tether to the existing asset data or a grouping function
2 - asset itself - this is a linear state that has a life cycle of events that influence it. Think of this like the company ref data behind the equity
3 - fungible asset representation - cash flow fungible staye that can reference the asset's linear id - think of issued shares for the equity
In this case, the 2 & 3 scenarios have the ref data to fungible state relationship. The fungible state can store the reference to the asset's linear ID and the asset can store an array of owners of the equity. Depending on your queries, you can also store another relational table for mapping different foreign and primary keys. The careful part is taking into account this logic linking when executing transactions that change issuance or ownership
For the standard Ethereum factory pattern, cordapps can be broken up into multiple functions. For example, the obligation cordapp uses the corda-finance-1.0.jar package to share different library functions and definitions on self issuing cash and cash properties.
Coming back to the asset example, we have an interest rate swap example cordapp that has contract code defining the known fields in a standard irs ISDA contract. From this template, you can deploy any irs type of state by defining the field properties like maturity date and interest rate.
I imagine the license use case can create similar fields for types for how the business logic or contract code would see it evolve. This also brings to light a tool gap for wrapping a workflow management tool or interface above the corda fundamentals.
Related
I'm currently tying to make a CordApp That will be used for DVP, but I'm having trouble understanding some key concepts. For instance, I understand that Contracts apply to one type of state in particular. What I don't really get is if the contract validation logic should apply to only that state object or all the states that will be in the given transaction.
The typical example would be the issuance of a sell order :
The input of a transaction the state of the stock account of the issuer and the outputs are the sell Order and the modified stock account.
Basically my question is were do I do checks like : I don't sell more than I own, the sum of the number of stocks in the sell order and what is left in the account is equal to what was initially in the account, ... ?
I have followed the Corda tutorials but I'm still not clear on that logic.
It boils down to the Orchestration Layer (flows or APIs, what the user intends to do) vs the Ledger layer (what the user can do. IE - guaranteed shared logic).
Contract code absolutely must be adhered to, so in your case not being able to sell more than you own would be part of the explicit contract.
The CMN guide here helped me conceptualise.
Flows are better described as business logic, so anything can be achieved within a flow as long as it adheres to the contract.
A security consideration: Anybody may create a flow, and they are equally able to use any Asset (and thus it's state) within their third-party flow.
It is the relevant contract that ensures that your asset is used for the purpose you imagine, and that it isn't used malevolently.
I have a network with 5 nodes, where node 1 is Company ABC and node 2 to node 5 are customer1, customer2 , customer3 etc. If customer1 uses Company ABC's product and if he gets a profit , he has to pay certain amount to Company ABC. The profit formula varies from customer to customer and customers should not see other customers profit formula.
One customer can use the formula as A * B , where another customer can use as A+B*10
I referred the link:
When deploying Corda nodes across the network, which JARs have to be exactly the same?
My doubts.
In my scenario , where should I write the formula ? In contract or flow or should I put in a state? Which is recommended ?
Will it be feasible to maintain so many node level jars ?
Can I deploy a contract which is available only in subset of nodes ?
1) This logic should go into the flow if you wish to keep the calculation private from customers. All nodes will be utilising the same contract, but your flows can be abstracted out of the CorDapp with the implementation local to the node.
2) Yes, the state and contract will remain the same across all the CorDapps. Only the flows will differ. This will probably end up being a common scenario as any calls to external systems will happen within the flow and you can anticipate how this will differ across entities.
3) You just need to think about designing your contract such that it won't reject any of the values calculated by your profit function and distribute this same contract to everyone.
Take a look at this example CorDapp, it shows different business logic per node
I am creating an asset back security which is a pool of securitised loans. The abs will be fungible as it can be divided up and sold off in smaller units. This supports the basic scenario of securitisation which allows the holder of the asset to then have a balanced portion of loans for risk and return purposes.
The requirement I am struggling with is the ability to be able to verify that the underlying loans and from legitimate issuers and other characteristics without revealing the loans details. Is it possible to achieve this? I believe the only view is of the data for the abs contract but the underlying loans are not accessible. If this is possible, how would privacy be preserved on those loans?
The way I would think about this is each underlying asset (loan) is also issued on ledger by their respective borrowers and sent to the party that is creating the CDO (let's call it that for now).
Issue the CDO on ledger containing with the underlying loans as part of its state. Write the contract in such a way that it allows for the CDO to be divided up and traded.
The above is sufficient to support the first requirement.
The second requirement, to allow for verification that the underlying loans are from legitimate issues and other characteristics while hiding other characteristics can be achieved in multiple ways.
I don't think the creator of the CDO could obfuscate characteristics from the loans they receive as this would also require re-issuance of the loan by the CDO creator to break the link between the original loan issuance. This is so that walking the chain wouldn't reveal the hidden characteristics and you wouldn't be able to verify the original issuer.
The original issuance of the underlying loans could either have the hidden characteristics stored off-ledger or could make use or a trusted oracle that would only reveal them according to some defined set of rules.
Alternatively, the loan issuers could use symmetric keys to encrypt the characteristics to be kept hidden and so keep them as part of the state. The loan issuers could share the keys only when required. A hash of the entire state including the hidden characteristics could be attached to the state and could be used to achieve the same thing, with the issuer only revealing the characteristics when requested (and the hash proving they have not been changed)
This way the underlying loans are accessible from the CDO during each transaction and Verify can be run on the CDO which would reach into the attached underlying loans and run Verify on them too.
I am using Corda and in one of our use-cases, we need to limit the transaction information shared among the nodes (e.g. 4 parties) in the network.
The transaction state will contain sensitive data of other nodes but we need to limit this data to be accessed by authorised parties only. e.g. party A should not see data of Party B in the transaction state.
I looked at the Corda documentation and tumbled upon Transaction tear-off but I could not find any concrete implementation of this.
I would be really grateful, if someone can give me an examples of transaction tear-off implementation or point me to right direction if there is better approach to limit transaction state sharing among parties than using transaction tear-off.
Thanks in advance
Transaction tear-offs are typically used in the use case where you're using an oracle to attest to a fact within your transaction.
The idea being, you want to strictly limit the oracle to viewing only what is required in order for it to attest, so you filter out all other parts of the transaction.
Take a look at the following tutorial https://docs.corda.net/tutorial-tear-offs.html it contains the steps required to create a filtered transaction.
You can also take a look at the samples on https://www.corda.net/samples that make use of an oracle. In particular, if you look at the Options sample, the OptionIssueFlow creates a filtered transaction for the oracle to sign.
One other approach - would it matter if Party A could see the data of Party B if it didn't know it was Party B? If not, you could look at using confidential identities https://docs.corda.net/api-identity.html#confidential-identities
I have a question abut what is the best practice/pattern to ensure proper authorization in my SOA application. I have a bunch of services that allow users access certain data (stored in DB). An example of a typical scenario is...
We have a EMPLOYEE table that has say a one to many relationship with PROJECT. So AN EMPLOYEE can have many PROJECTS. Also each employee belongs to a region. The users of the system are allowed to edit information on employee and projects. However Each user only manages data for a few regions and therefore can only modify employees and their projects that belong to a region that the user manages. So user may have access to regions A, B, C and can edit employee/project data for Region A employee but not region Z employee.
I have one service that lets you edit an employee and another to edit an project. Similarly a project has relationships to other entities, for e.g. SCHEDULE, and I have services to edit those as well.
However my problem is this -- whether an user can edit or not a project or schedule, by calling the corresponding service, is determined by which region the employee (to which these projects and schedules are related) belongs to. So for every service to modify a project or schedule or any entity in that hierarchy of data starting at employee, I am having to query the corresponding employee and enforce the region constraints. Which can become very expensive operation considering the database calls and number of joins (my real example has lot of such entities and corresponding services) I have to make on every service call. Is there a more elegant light weight solution for my scenario?
First of all, I'd call these requirements regular business rules rather than authorization. Authorization is usually much more generic in nature, meaning whether a user is allowed access to a specific system or is allowed to invoke a certain function (regardless of parameters).
Second, and based on a business rules view, you should take into account the consistency needs around these business rules before dividing things up into services.
Third, relating to your statement "my real example has lot of such entities and corresponding services", it usually not a good idea to have services that correspond to entities.
So, in summary, you need to redesign your service boundaries such that the rules that need to be enforced (in a highly consistent manner) are contained within a single service. One way to do that is to take different parts of a given entity and put them in different services - provided that there aren't any business rules that demand consistency across those diffe