In one test, I got
Input state requires notary "C=GB,L=London,O=Mock Company 1" which does not match the transaction notary "C=GB,L=London,O=Mock Company 1,CN=corda.notary.validating".
They should be the same one. The only difference is CN which is optional.
How can I avoid the error?
\Sean
How are you getting the notary? Each node has a main identity, as well as an optional notary identity. Is it possible that you're retrieving the former, rather than the latter?
To get the notary, you should be using NetworkMapCache.getNotary, which takes a CordaX500Name and only searches for notary identities with this name.
Related
I have a Corda Infrastructure with some nodes and a (not validating) notary. They're all using a Network Map for the compatibility zone, and all the corda nodes, including the notary, download the same network-parameters file.
When executing a flow, Corda gives me an Exception because the Notary is not on the network parameters whitelist. I cannot find anything anything about that on R3 Documentation.
java.lang.IllegalStateException: Notary [O=Notary, L=Cosenza, C=IT (owningKey = DLAdtNkbnrjn6FGwzE4sCaiDS3tRgMw3KhZfA7bD3icYK1)] specified by the transaction is not on the network parameter whitelist: []
at net.corda.core.internal.TransactionUtilsKt.checkNotaryWhitelisted(TransactionUtils.kt:257) ~[corda-core-4.8.jar:?]
Note that I'm using a fixed Notary X500 Name in the Flow code instead of "preferredNotary" because it won't be found. I think it is because of the same problem.
Do I have to do something explicit to add Notary in network parameters whitelist?
Do I have to do something explicit to add Notary in network parameters whitelist?
Yeah you do. Since you are using a network-map-service your node will get its network-parameters from there.
What you'll have to do then is
delete your current network-parameters for every Node.
whitelist your Notary Node into your network-map-service
restart all your Nodes so they can retrieve the new network-parameters from the network-map-service where the new Notary is assigned as such
I don't know which network-map-service exactly you use but i assume its nms by cordite. You can read up on how to whitelist a Notary here: https://gitlab.com/cordite/network-map-service/-/blob/master/FAQ.md#14-start-the-notary-node
Regarding CollectSignatureFlow with accounts:
In the comments of worldcupticketbooking's file: DVPAccountsOnSameNode
its given Note: though buyer and seller are on the same node still we will have to call CollectSignaturesFlow as the signer is not a Party but an account.
But here its said that If your accounts are on the same node that you are running the flow on then they can all be on the signInitialTransaction, however, if one is on another node you need to use a CollectSignatureFlow
I disagree with the comment from the DVP CorDapp that you shared; if all required signers exist on the initiating node, there's no need to call CollectSignaturesFlow, instead just pass the keys of the accounts like below:
getServiceHub().signInitialTransaction(transactionBuilder,
Arrays.asList(getOurIdentity().getOwningKey(),
account1Key, account2Key, account3Key, etc...));
In relation to this post: Corda - java.lang.IllegalArgumentException being thrown from a validating notary
I've identified a case in Corda where states sometimes need to store a custom data type, however validating transactions using these states fails when using a validating notary.
Consider the following types to be implemented in the same package, in the same jar file:
Example Custom Type
package com.example.statescontracts
#CordaSerializable
data class Foo(
val bar: Int,
val baz: String
)
Example State
package com.example.statescontracts
data class FooState(
override val linearId: UniqueIdentifier,
val obligor: AbstractParty,
val obligee: AbstractParty,
val foos: Set<Foo>
) : LinearState {
override val participants get() = listOf(obligor, obligee)
}
Issuing a new FooState instance to the ledger probably isn't affected as it's not consuming a previous FooState instance, but subsequent consumption of FooState instances seem to fail for validating notaries.
Exception
java.lang.IllegalArgumentException: Not a valid Java name:
java.util.Set<com.example.statescontracts.Foo>
Assumptions
Validation can occur for all participants of the state who have the states/contracts JAR file, and therefore can access the Foo type, however this doesn't work for the notary because it doesn't have a copy of the states/contracts JAR file locally.
As I understand it, the states/contracts JAR file should be kept small as it's attached to the transaction when proposed, therefore validating notaries should be able to validate using classes found in the JAR attached to the transaction.
Question
Can anyone verify whether my assumptions are correct, and if so, why this issue occurs for validating notaries, and how to correct this issue?
As described in the tech white paper, the intended end design is that the contract JARs are taken from attachments and run inside the deterministic JVM, where they're sandboxed and resource monitored.
A standalone DJVM preview is shipping in Corda 4, but is not integrated. We will continue to work on this over time, which will allow nodes that don't have the contracts JAR to validate transactions. For now, validating notaries do need to have every version of every app they may encounter installed. Non-validating notaries don't suffer this problem.
As of Corda 3, validating notaries need the states/contracts JAR file for each transaction they are notarising.
If I uses a commonName in a legalName to create a node (at least for MockNetwork), then networkMapCache.getNodeByLegalName(legalName) returns null. After removing the commonName, it works. Is that by design?
This is a bug in Corda V1.0. When creating a node, the common name part of the name is nulled out. However, when looking up a node using the network map, the common name field is not nulled out, so no match is found.
The Corda team will backport a fix to Corda V1.0 to throw an exception when a regular node is created with a common name. In Corda V1.0, a common name is used solely by notary clusters to identify one another.
In a future version of Corda, the Corda team will examine re-enabling the common name field for regular nodes.
I would like to add a new Notary/Regulatory node in my Cordapp application ,
which should perform some extra validation checks when transaction
is completed between two parties.
so that notary/regulatory will be finally checks for some things and stamp the transaction.
There are two options here:
Instead of using the default FinalityFlow to notarise, broadcast and record transactions, you can implement your own flow that performs some additional validation before the notarisation step. The limitation here is that the checks are not part of the notary service.
Create your own custom notary. Here, the custom validation checks happen within the notary service. The ability to do this is a recent change to the codebase, as such the documentation has not been updated to reflect the changes, however the source docs can be found on github:
Instructions for creating a custom notary service: https://github.com/corda/corda/blob/9e563f9b98b79a308d68ecb01c80ce61df048310/docs/source/tutorial-custom-notary.rst
Sample custom notary service code: https://github.com/corda/corda/blob/9e563f9b98b79a308d68ecb01c80ce61df048310/docs/source/example-code/src/main/kotlin/net/corda/docs/CustomNotaryTutorial.kt
As Roger notes, you could customise FinalityFlow/implement your own notary.
An alternative would be:
Add a new node to the network representing some regulator
Write the contract rules so that the regulator is a required signer on transactions
Have the regulator do additional checking of the transaction in their flow before signing