need to implement corda node which is pure observer means which persist states but wont participate with other nodes for any transaction.
In order to acheive it i did followning thing:
Made 3 nodes as follow:
PartyA - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
PartyB - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
Observer - Nodes contain contract and State along with observer flow only.
On observer node all transactional nodes removed intentionally so that observer wont able to transact with other node.
After nodes start up, performed transaction from PartyA to PartyB by keeping Observer node as observer. It works perfectly.
Now i tried same thing from PartyA to observer and keep PartyB as observer. I expected transaction will get failed but transaction got committed on observer node even though observer node has no transactional flows.
When i tried to perform transaction from observer to PartyA then it gives error as no flow found which is expected.
Example i am using have ownable state and simple initiating flows are used.
My question is how one directional transaction worked with observer inspite of no flows on observer.
How can i prevent observer from not doing any transaction with other nodes, just act as pure observer.
As of Corda 3, the node actually installs default flow responders when it starts up for the four following flows:
FinalityFlow
NotaryChangeFlow
ContractUpgradeFlow.Initiate
SwapIdentitiesFlow
This is done in AbstractNode.installCoreFlows:
private fun installCoreFlows() {
installCoreFlow(FinalityFlow::class, ::FinalityHandler)
installCoreFlow(NotaryChangeFlow::class, ::NotaryChangeHandler)
installCoreFlow(ContractUpgradeFlow.Initiate::class, ::ContractUpgradeHandler)
installCoreFlow(SwapIdentitiesFlow::class, ::SwapIdentitiesHandler)
}
Thus the observer node will still be able to receive and record transactions as part of calls to FinalityFlow.
In a future version of Corda, this default FinalityFlow handler will be removed. Nodes will have to explicitly create a flow that receives and stores a transaction, allowing you to implement the behaviour above.
Related
We are building a POC using Corda 4 and Springboot web server.
The POC is running in dev mode in our local network.
The CorDapp developed for POC has four nodes -
Provider Node
Consumer 1 Node
Consumer 2 Node
Notary Node
There are three states-
State 1: NEW
State 2: APPROVED
State 3: CANCELLED
Every deal that takes place between the three nodes have three flows. Following are the three flows and the states:
Flow 1:
Provider Node --> Consumer 1 Node
Change State : NEW
Flow 2:
Consumer 1 Node --> Consumer 2 Node and Provider Node
Change State : NEW --> APPROVED
Flow 3:
Consumer 2 Node -- > Consumer 1 Node and Provider Node
State : APPROVED ---> CANCELLED
Many flows have been initiated in the CorDapp and most of them are in "APPROVED" state.
Due to new requirement, we had to change the flow definitions minutely. After changing, we created the updated CorDapp version and distributed to the four nodes.
After starting the nodes and CorDapp application, we found that the flows that are in "APPROVED" state cannot be started to change the state to "CANCELLED".
The flows are throwing error -
"The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction."
Please note that the we are using all the correct sessions.
Question: How to update the Cordapp and continue old flows till "CANCELLED" state from "APPROVED"?
You didn't specify what the change was but my understanding is that if you change your states you have to run a schema migration. That is most likely the reason you're having this issue.
When in devmode you can pretty much just add the runSchemaMigration=true to your node config.
See example here: https://github.com/corda/cordapp-template-java/blob/release-V4/build.gradle#L103
Here's another resource that might be useful for that :https://www.corda.net/blog/upgrade-to-corda-os-46the-database-migration/
i am using the https://github.com/corda/corda-tut2-solution-kotlin template for my simple corda app. i have modified it with some addition fields in IOU but i dont want to send to PartyB. i just want to push data over blockchain. I have modified the flows.kt and StateAndContracts.kt source files. but i am unable to do so. i still see the transactions goes to PartyB as well.
Can someone please suggest.
As part of FinalityFlow, a transaction is sent to all the participants of all the transaction's input and output states. I assume in your case, PartyB is one of the participants in the output, so they receive the transaction.
Note that even if you were to remove PartyB as a participant on the output, they would still receive a copy of the full transaction because they are a participant on the input (although they would not store this output state in their vault). We are doing work with SGX (see https://docs.corda.net/head/design/sgx-integration/design.html) to make it so that PartyB would not be able to see the output state at all, even though they are a participant of the input.
I would like to know if it is possible to cancel an execution of an ScheduledActivity.
Example:
A SchedulableState of type A is created, and the scheduledActivity will execute a flow that creates another SchedulableState of type A. It means that the app will always execute the flow determined in the activity and create another state of type A.
How can I abort the execution of the activity?
How can I identify if is there a ScheduledActivity waiting to be executed?
As of Corda 4.x, there is no API to cancel scheduled activities.
Instead, you'd have to connect to the node's database directly and drop the required rows from the node's NODE_SCHEDULED_STATES table.
In Corda, FinalityFlow:
Verifies transaction on initiator node
Notarizes transaction
Persists signedTransaction to vault of initiator
Distributes transaction to the participants
As per consensus, verification involves walking the chain.
I looked in FinalityFlow code. Where exactly does the walking-the-chain thing happen?
Do the notary and the participants also walk the chain? If yes, they check the signatures on each transaction in the chain, but where exactly in the code does it happen?
As per my understanding, SendTransactionFlow sends the transaction to the other parties on the participants lists. The other party also requests for attachments and transaction dependencies. Where actually does the walking-the-chain thing happen?
I need to understand walking the chain from a coding perspective.
In FinalityFlow, the caller uses the following line to send the notarised transaction to the participants of all the states:
subFlow(SendTransactionFlow(session, notarised))
If we look at AbstractNode.installCoreFlows, we see that the node installs a default handler for FinalityFlow called FinalityHandler. FinalityHandler responds to the call to SendTransactionFlow in FinalityFlow by calling ReceiveTransactionFlow.
Inside ReceiveTransactionFlow, we can see that the node resolves the transaction's dependencies, verifies the transaction and checks its signatures:
val stx = otherSideSession.receive<SignedTransaction>().unwrap {
subFlow(ResolveTransactionsFlow(it, otherSideSession))
it.verify(serviceHub, checkSufficientSignatures)
it
}
As part of resolving the transaction's dependencies in ResolveTransactionsFlow, the node verifies each one and checks its signatures (by default, verify checks the signatures on the transaction):
result.forEach {
it.verify(serviceHub)
serviceHub.recordTransactions(StatesToRecord.NONE, listOf(it))
}
The notary will only walk the chain in this way if they are a validating notary.
We have a use case which requires the following steps:
(1) Initiator triggers the transaction flow through UI
(2) The flow is initiated, signed by the initiator and sent to recipient for his verification and signatures (in Corda)
(3) The initiator's flow should get suspended until the recipient validates the transaction by verifying the contract code and submits "verified" again through the UI
(4) This should restart the initiator's flow and the remaining process should be followed as expected in Corda
It was mentioned a few weeks back that user interaction is not yet supported in Corda; is this feature still not present? In the future, we may even want to add the state's attributes through a UI since it gives us the flexibility to propose a transaction we want rather than have it hard-coded. Any idea if this could be possible in future releases?
See the Negotiation Cordapp sample for an example of how this would work in practice here.
Suspending a flow for human interaction isn't currently implemented (as of Corda V3.0).
Instead, you'd implement this by adding a status flag to your state:
class FooState(
override val participants: List<Party>,
val accepted: Boolean) : ContractState
You'd have three commands:
interface Commands : CommandData {
class Propose : Commands
class Reject: Commands
class Accept: Commands
}
And two flows:
A proposal flow: In this flow, the initiator creates and signs a Propose transaction to issue the state onto the ledger with a Propose command and the accepted flag set to false
An accept flow: In this flow, the recipient either:
Creates a Reject transaction that consumes the proposed state and outputs nothing. The state has been removed from the ledger and is effectively rejected
Creates an Accept transaction that updates the proposed state so that accepted is true. The state has now been accepted, and this fact is registered on the ledger
You'd give the accept flow a parameter which determines whether or not to accept the proposal. This parameter would be provided by the user when the flow is kicked off either via an API or directly over RPC.