In Corda, given a StateRef that is CONSUMED, how can I find the transaction that consumed it?
As of Corda 3, there is no API to provide the transaction that consumed a state.
With the expected introduction of SGX to prevent nodes from seeing transactions or portions of transactions that don't concern them, we are not looking to extend the TransactionStorage API at this time.
Related
I have some basic questions about Corda's transaction functionality:
For transactions between alice & bob, does bob have to manually sign/verify the transaction or does bob's node automatically sign for it?
If I am transacting with a bank that is on your platform, like HSBC, and I withdraw funds, would the funds go directly into my HSBC bank account?
From what I've learnt so far, is that Corda's notary service acts as a TTP; however, what if I don't trust Corda's notary service and want a consensus mechanism that isn't reliant on any authority?
Nodes don't have to sign transactions manually, signing happens in the context of the flows written in the CordDapp, the CorDapps are installed in the node.
That would depend on the scope of the implementation. If the central bank is issuing the currency on Corda (something like CBDC), then with the new account functionality, yes that is a possibility.
A notary is just a general Corda node with some extra responsibility for preventing double-spending. You cannot really remove the notary altogether, but yes the consensus in notary cluster is pluggable. You could choose a different consensus algorith. Refer here for more details: https://docs.corda.net/key-concepts-notaries.html#consensus-algorithms
We have a simple application, who upon every update of an entity sends out a notification to SNS(it could very well have been any other queuing system). Clients are listening to these notifications and they do a get of updated entity based on these notifications.
The problem we are facing is, when clients do a get, sometimes data is not replicated and we return 404 or sometimes stale data(even worse).
How can we mitigate this while sending notifications?
Here are Few strategies to mitigate this with pros and cons
Instead of sending notification from application send notification using database streams
For example dynamodb streams ans aws lambda. This pattern can be useful in the case of multiregion deployment as well. where all the subscriber, publisher will subscribe to their regional database streams. And also atomicity of sending message and writing to database is preserved. And we wont loose events in the case of regional failure.
Send delayed messages to your broker
Some borkers like activemq and sqs support this functionality, but SNS does not. A workaround for that could be writing to sqs queue which then writes to sns. This might be a good option when your database does not support streams.
Send special error code for retry-able gets
Since we know that eventual consistency is there we can return special error code to clients, so that they can retry based on this error code. The retry strategy should be exponential backoff. but this may mean giving away your problems to clients. Also we should have some sort of versioning in place.
Fetch from another region
If entity is not found in the same region application can go to another region or master database to fetch it. NOTE Don't do this. as it is an anti pattern. I am mentioning it here just for the sake of completion.
Send the full entity in message
If entities to be fetched by rest service is small and there are no security constrain around who can access what, we can send the full entity in message. This is ensure that client don't have to do explicit fetch of it every time a new message is arrived.
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
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.
The solution is composed of an orchestration process services and multiple legacy applications in charge of making CRUD operations on the domain entities.
Every time an update, add or delete statement is executed by these legacy applications a notification is sent by the entity owner application.
In the modeling phase we decided to map the entities fine-grained. In this way every CRUD operation can rise thousands of notifications(up to 20k) resulting to blocking users activity for a while becouse entity persistence and notification sending are combined in the same transaction. This can be inacceptable when it takes more than 120 seconds.
What i wanted to do is separate the user activity in legacy applications from entity persistence and notification sending deferring these to a specific application service(for example). I know the best would be deferring these activities to a background thread in the user application but as i mentioned i'm using very old legacy applications. Is there any SOA design patterns that can be applied to this scenario?
What you want is "Decoupled invocation". You accept the request and put it in a (persistent) queue and send an acknowledgment to the user that the request has been received. Depending on the scenarioYou can send an additional reply (e.g. by email) when the message has been fully processed.
.