So I've been tasked with developing a POC for my company and have been learning about Corda. I think I understand the overview of Corda and a few details but I came across something that I don't quite understand. To illustrate, let's use the IOU example that the tutorial uses.
In that case, let's say I have two parties: Alice and Bob. Alice borrows $20 from Bob. This is correctly recorded in both their vaults and DB.
Now, let's say Bob is a bad actor and manually updates the information on his side (including associated hashes for the transaction) so that the transaction states that Alice borrowed $30 instead of $20.
So here are my questions:
Are there any safeguards built into Corda to prevent Bob from arbitrarily changing the data on his end?
If he is successful in mutating the facts on his end, how does the network decide who is correct in the future when Alice and Bob both present mutually exclusive transaction histories?
In a similar use case, imagine there is a fact that is initially shared between multiple parties, then is legitimately marked as only concerning one party, and then is again shared multiple (potentially different) parties. In this case, what would happen if the fact were to be illegitimately mutated during the single party access phase of the fact's lifespan?
Thanks in advance to all the people that help clear this up!
This will be specified in the smart contract you setup with the counterparty when instigating the trade. Cobra will not settle your distributes since this defeats the whole purpose of the platform.
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.
The data in our vault is manageable. Eventually, we would accumulate a large volume. It is not possible to retain such large data for every day transactions. We would want to periodically archive or warehouse the data, so that query performance is maintained.
May I know if you have thought about handling large scale datasets and what would be your advise.
From the corda-dev mailing list:
Yep, we should do some design work around this. As you note it’s not a pressing issue right now but may become one in future.
Our current implementation is actually designed to keep data around even when it’s no longer ‘current’ on the ledger. The ORM mapped vault tables prefer to mark a row as obsolete rather than actually delete the data from the underlying database. Also, the transaction store has no concept of garbage collection or pruning so it never deletes data either. This has clear benefits from the perspective of understanding the history of the ledger and how it got into its current state, but it poses operational issues as well.
I think people will have different preferences here depending on their resources and jurisdiction. Let’s tackle the two data stores separately:
Making the relationally mapped tables delete data is easy, it’s just a policy change. Instead of marking a row as gone, we actually issue a SQL DELETE call.
The transaction store is trickier. Corda benefits from its blockless design here; in theory we can garbage collect old transactions. The devil is in the details however because for nodes that use SGX the tx store will be encrypted. Thus not only do we need to develop a parallel GC for the tx graph, but also, run it entirely inside the enclaves. A fun systems engineering problem.
If the concern is just query performance, one obvious move is to shift the tx store into a scalable K/V store like Cassandra, hosted BigTable etc. There’s no deep reason the tx store must be in the same RDBMS as the rest of the data, it’s just convenient to have a single database to backup. Scalable K/V stores don’t really lose query performance as the dataset grows, so, this is also a nice solution.
W.R.T. things like the GDPR, being able to delete data might help or it might be irrelevant. As with all things GDPR related nobody knows because the EU didn’t bother to define any answers - auditing a distributed ledger might count as a “legitimate need” for data, or it might not, depending on who the judge is on the day of the case.
It is at any rate only an issue when personal data is stored on ledger, which is not most use cases today.
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
Background:
We learned that corda is not tamper-proof but tamper-evident. So, if one of the node manipulated a state directly in the database, other nodes will be able to detect and flag it if that state was used in subsequent transactions. However, our test results were not as per our expectation. Corda did not flag the state that was tampered and in fact it recorded the new state with tampered data in all participant nodes.
Prerequisites:
Comment Out Contract Validations: We commented contract code to check if the data tampering is detected in Corda without the check being explicitly done at command level.
Steps to replicate:
Start obligation Cordapp.
Create 3 obligations between Party A and Party B (100 THB, 256 THB and 100 THB)
Edit the VAULT_STATES table in the database of Party B, by looking at the differences between the hexs.
Obligations with different amount is on the left and the two obligations with the same amount is on the right. From the editor when they are at same amount there are 2 differences (presumably linear-id & timestamp related) and when they are at different amount the 3rd discrepancy is showed on the left.
Overwrite the specific portion with the lower value amount, update vault using SQL on Party B’s vault:
After this update, check Party B’s vault and the amounts are changed to 100 THB on all 3 obligations.
However, Party A’s vault will show original amounts (100, 256, 100) as the data was not tampered in Party A’s vault.
Transfer ALL obligations from Party B to Party C
Transfer obligations result: Party B have no more obligations
Transfer obligations result: Party C will get all Party B’s Obligations (100 THB for all, i.e. tampered data was passed on to the new party)
Transfer obligations result: Party A’s vault will also be updated with tampered data. It couldn’t identify or flag tampered data.
How to get Corda participant nodes to detect tampered states? have i missed some config while setting up the node?
I'm afraid this discussion may take a while because most of us are off on holiday from this afternoon.
We'll have a go at replicating what you did here. However it's not clear to me that this is a bug.
You say you commented out the contract validation logic. It sounds like what may have happened is this:
Edit the states table to hold a corrupted state.
Build a transaction with INPUT=pointer to previous correct state. OUTPUT=(corrupted state)+edit to hold new owner field.
This transaction is now signed and transferred.
This transaction would have been considered invalid and rejected when the transfer to Party C is attempted, because it'd be an illegal state transition: the numbers do not balance. But you commented out the code that checks for that! So nothing anywhere is saying you aren't allowed to simply change the size of an obligation whenever you like ... Corda doesn't know that implicitly if you comment out the code that contains this knowledge. Thus from the IOU app's perspective changing the size as you transfer it is now a perfectly legitimate thing to do.
Here's the question - if you leave the app alone and don't modify its source code, is the tampering detected? If the answer is still "no" then we have some more investigation to do.
There is one example to explaining associations in UML.
A person works for a company; a company has a number offices.
But I am unable to understand the relationship between Person, Company, and Office classes. My understanding is:
a company consists of many persons as employees but these classes exist independently so that is simple association with 0..* multiplicity on Person class' end
a company has many offices and those offices will not exist if there is no company so that is composition having Company as the parent class and 0..* multiplicity on Branch class' end.
But I am not sure of 2nd point. Please correct me if I am wrong.
Thank you.
Why use composition or aggregation in this situation at all? The UML spec leaves the meaning of aggregation to the modeler. What do you want it to mean to your audience? And the meaning of composition is probably too strong for this situation. Thus, why use it here? I recommend you use a simple association.
If I were you, I would stay truer to the problem domain. In the world I know, Offices don't cease to exist when a Company goes out of business. Rather, a Company occupies some number of Offices for some limited period of time. If a Company goes out of business, the Offices get sold or leased to some other Company. The Offices are not burned to the ground.
If you aren't true to the problem domain in an application, then the shortcuts you take will become invalid when the customer "changes the requirements" for that application. The problem domain doesn't actually change much, just the shortcuts you are allowed to take. If you take shortcuts to satisfy requirements in a way that are misaligned with the problem domain, it is expensive to adjust the application. Your customer becomes unhappy and you wind up working overtime. Save yourself and everyone the trouble!
While Jim's answer is correct, I want to add some extra information. There are two main uses for aggregation
Memory management
Database management
In the first case it gives a hint how long objects shall live. This is directly related to memory usage. If the target language is one which (like most modern languages) uses a garbage collector, you can simply ignore this model information.
In the second case, it's only partially a memory question. A composite aggregation in a database indicates that the aggregated elements need to be deleted along with the aggregating element. This is less a memory but in most cases a security issue. So here you have to think twice.
A shared aggregation however has a very esoteric meaning in all cases.