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.
Related
I am going through this documentation and I have several uncertainties.
Performing explicit contract and state upgrades
Preserve the existing state and contract definitions
Write the new state and contract definitions
Create the new CorDapp JAR
Distribute the new CorDapp JAR
Stop the nodes
Re-run the network bootstrapper (only if you want to whitelist the
new contract)
Restart the nodes
Authorise the upgrade
Perform the upgrade
Migrate the new upgraded state to the Signature Constraint from the
zone constraint
Questions:
1. Preserve the existing state and contract definitions
2. Write the new state and contract definitions
3. Create the new CorDapp JAR
How do I do that? is it meant only to preserve jars with contracts and states on nodes, not preserving them in source code? If I do not preserve them in source code then how can I create the upgrade method?
interface UpgradedContract<in OldState : ContractState, out NewState : ContractState> : Contract {
val legacyContract: ContractClassName
fun upgrade(state: OldState): NewState
}
If I do not preserve old state in source code, then shoud I name the jar differently each time I need to do an upgrade?
Can old jars be reoved from the node when the upgrade was completed?
6. Re-run the network bootstrapper (only if you want to whitelist the
new contract)
8. Authorise the upgrade
Am I right that only those 2 steps are related to Explicit contact upgrades? And If I use implicit flow with signature, then I need to skip only those two steps, while the others are still aplicable and must be performed?
9. Perform the upgrade
Should this be done for each state separately by the owner of the state? In that case should I run it on each node for specific contrcats where the node is the participant of the state? (In doc it is mentioned to be run on single node - but what id=f a single node is not participant of some state)
Other questions
This section describes explicit contracts and states update.
https://docs.corda.net/upgrading-cordapps.html#performing-explicit-contract-and-state-upgrades while signature constraint section (https://docs.corda.net/api-contract-constraints.html#signature-constraints) does not describe an update process for states.
is it the same as for explicit upgrades with the difference only in steps 6,8 or it is somewhat completely different?
Do I need to create the function transforming old states to new states in that case? if not , then how the old states will be handled by new flows?
I see you have many some great questions about contract upgrades. Here is an article that is written by one of our dev-relation engineers. https://medium.com/corda/contract-upgrades-and-constraints-in-corda-425055a9a47f
Feel free to follow up any additional questions that you have.
If you are new to Corda, feel free to join the Corda community channels #http://slack.corda.net/
While performing legacy contract upgrades, you need both the old and new contract jars installed on your node. (present in the cordapps folder).
You can create a new Gradle module say v2-contract and write the new contract in this. This is where you will write your UpgradedContract. You will need to refer to the old v1-conract jar as well as it needs to know what the old state was. To do this add a gradle dependency in v2-contract like below.
dependencies {
// Corda dependencies.
cordapp project(v1_contract)
}
The old jar can be removed from the cordapps folder, once all the states have been upgraded to new v2-contract.
a. For HashConstraints there is no need to run the bootstrapper again. You will write the new contract by implementing UpgradedContractWithLegacyConstraint,run the jar task to build this new jar, add it to the cordapps folder, run the Authorise Flow from all nodes, run the Initiate flow from one of he node's terminal. This is the explicit way of upgrading.
b. However if you are using Whitelistzoneconstraint, you want to make sure to add the new v2-contract jar's hash to whitelist param in network param. You will need to run the network Bootstrapper to whitelist this new v2-contracts jar hash. https://docs.corda.net/network-bootstrapper.html#whitelisting-contracts.
Once you do that you can either go for an explicit upgrade by implementing UpgradedContract, or you can use implicit upgrade.
c. If you are using Signature Constraints, no need to run the network Bootstrapper for the new jar, write the new v2-contract, build it using gradle jar task, replace old jar with new jar. This is the implicit way of upgrading.
You should run the Authorise Flow for all the participants only.
Other questions
There is no explicit upgrade in Signature constraints. You need to make sure you write your state in a backward compatible way, build new jar, replace old jar with new jar. The states will refer to the new contract then.
Hope that helps. Feel free to post more questions on the above answer or ping on Slack.
We have downloaded 4 pre-configured Corda nodes from https://testnet.corda.network.
These nodes have X.500 distinguished names containing subparts - Organization, Location and Country.
Question 1: Can we replace the values in the above subparts of the X.500 distinguished name with our definitions?
Question 2: Can we add "organizationUnit" in the above X.500 name?
The Testnet was built for the community to experience the Corda network.
It is a pathway to the Corda Network (TCN) run by the Corda Foundation, an independent council which runs the TCN.
I will log your requests with the testnet team as a function enhancement request, but they will probably need more information from you & your team to make any further changes to the testnet.
You can reach me at http://slack.corda.net. We can resume the conversation there.
Yes, every node specifies its own X500 name. This is done in the node.conf using the myLegalName field: https://docs.corda.net/corda-configuration-file.html#configuration-file-fields This field is used during initial registration on the node's first startup to register with the network's identity service https://docs.corda.r3.com/node-commandline.html#sub-commands
The X500 name for a name of a node is extremely important as it represents the identity that a node uses when signing transaction. Because of this the X500 identity rules vary by network.
Testnet
The onboarding tool pre-generates an X500 for you based on your marketplace account. Your account is automatically built into a generated node.conf whichinstall.sh downloads for your node.
In Testnet there are no restrictions on identity and all registration requests are automatically approved. Therefore anyone can specify any identity they would like which is why Testnet must never be used for real financial transactions.
UAT
X500 names must followed a specific set of rules to be approved. Guidelines on how to select an X500 are here: https://corda.network/participation/distinguishedname.html
Examples of real world identity selection is here: https://corda.network/participation/legalentity.html
In UAT registration requests are all manually approved by the Corda Network Foundation. Follows the steps outlined here to onboard your node: https://uat.network.r3.com/pages/joining/joining.html
The Corda Network (tCN)
The production Corda Network follows the same guidelines for X500 names.
The onboarding process for nodes is also the same with different urls: https://corda.network/participation/index.html
As mentioned in the docs on performing flow upgrades, all you need to do is basically shut down the node, replace JAR, and start the node back up. When I do this, when my upgraded flow is run the next time, I get the following error:
net.corda.core.contracts.TransactionVerificationException$ContractConstraintRejection: Contract constraints failed for com.company.project.contract.MyContract, transaction: ABCDEFG
And the flow does not complete as a result. What am I doing wrong?
As my experience it seem like Corda flow upgrade not update network parameter (state still belong to old hash, old contract). Then when replace with new contract it will be contract constraint.
So I think you have 3 way to manage this
For local network bootstrap, update network parameter before doing flow upgrade (I use network-bootstrap.jar for copy new contract to cordapp folder, then it will append new contract hash immediately)
For Corda network, you must contact network operator for update new hash.
Use SignatureConstraint of Corda4 (they claim that it's upgrade easier but I didn't try yet)
Hope this help
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.
This is related to Hyperledger fabric v1.0 network topology.
From the example, configtx.yaml contains following definitions:
Profiles:
TwoOrgsOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
There are two main sections.
TwoOrgsOrdererGenesis
This defines the orderer service and the genesis block details.
TwoOrgsChannel
This defines the channel details. Such as how many organization/entity are going to be part of the channel.
What I understood from the documentation is Consortiums section defines what are the organizations/entities belongs to a Consortium.
My questions:
What is the role of Consortium?
Can a Consortium entity would have peer nodes running for it's own?
If yes, how to configure in this yaml file?
What is the meaning of <<: line?
What is Application in this context?
Can I define multiple profiles in this yaml file?
appreciate if anyone can explain in details.
My questions:
What is the role of Consortium?
A consortium consists of organizations. And organization contains
peers or orderer. one channel is matched with one consortium but one
consortium can be matched many consortiums.
Can a Consortium entity would have peer nodes running for it's own?
If yes, how to configure in this yaml file?
No, but if you want to define consortium, you have to get MSPs about
organizations.
What is the meaning of <<: line?
It's a YAML grammar.
What is Application in this context?
channel application like Node.js Application. But now My channel works without the section.
Can I define multiple profiles in this yaml file?
sorry, I don't understand what you want to define profile for.
to reply to "Can I define multiple profiles in this yaml file?" the answer is yes.
As you can see in this sample file, multiple profiles are here defined.
Profiles are used to defines the configuration of the genesis block and to define the first channel configuration transaction. In the code that you provide TwoOrgsOrdererGenesis should be used as parameter for the configtxgen command
configtxgen -profile SampleSingleMSPSolo -channelID sys-channel -outputBlock ./channel-artifacts/genesis.block
while the second is used to generate the artifacts for the channel transaction
configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID channel-name
In the above file you can check some different configurations... I think it is a good starting point to understand the network configuration which is still something I'm trying to fully figure out.
Regarding the question "What is the meaning of <<: line?"
yaml files syntax :-
The & marks an alias for the node (in your example &default aliases the development node as "default") and the * references the aliased node with the name "default". The <<: inserts the content of that node.
This type reference are used when - Repeated nodes (objects) are first identified by an anchor (marked with the ampersand - “&”), and are then aliased (referenced with an asterisk - “*”) thereafter.