I have a corda network (corda as system service) (v3.1) running in devMode, the network structure goes like:
Party A
Party B
Party C
NotaryA (simple notary)
NotaryB (validating notary)
Oracle
The network is running perfectly fine until I try to add one more party to the network (Party D). Steps how I try to add new party:
Generate nodeInfo, certificates etc using network-bootstrapper tool for new party
Place the node folder parallel to the other node folders and add required cordapp to the cordapps folder inside the newly added party
Share the nodeinfo to all other nodes and vice-versa
This didn't work, probably because newly added node has a different network parameter file then other nodes and has no information about the notary nodes.
I tried the other way:
Keep node.conf of all the nodes along with the node.conf of new node and generate nodeInfo, network-parameters etc for all nodes.
Place the folder of the new node parallel to other nodes and replace network-parameter, additional-nodeinfo folder and nodeinfo files of old nodes with the newly created files and folders.
Add required cordapps to node/cordapps folders
But this way also it didn't work.
Can you help me with correct steps for adding new node to the existing network?
The bootstrapper can only generate information for a set of nodes that are on the same machine. If a node needs to be added to a bootstrapped network, all the nodes need to be collected back together on the same machine.
The instructions for adding a node to a bootstrapped network are available here: https://docs.corda.net/head/network-bootstrapper.html#adding-a-new-node-to-the-network.
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 are building a POC using Corda and Springboot web server.
Following are the versions of Corda platform, Springboot server, and other essential dependencies used for building the POC-
cordaReleaseGroup=net.corda
cordaVersion=4.0
gradlePluginsVersion=4.0.45
kotlinVersion=1.2.71
junitVersion=4.12
quasarVersion=0.7.10
spring_version = '4.3.11.RELEASE'
spring_boot_version = '2.0.2.RELEASE'
spring_boot_gradle_plugin_version = '2.1.1.RELEASE'
jvmTarget = "1.8"
log4jVersion =2.11.2
platformVersion=4
slf4jVersion=1.7.25
nettyVersion=4.1.22.Final
The CorDapp developed for POC has four nodes -
Notary Node
Provider Company Node
Consumer Company 1 Node
Consumer Company 1 Sub Contact Node
The POC is running in dev mode in our local network.
We require to test the POC in the Corda Testnet.
We went through the following documentation on Corda Testnet -
1: Join Corda TestNet
URL : https://docs.corda.net/releases/release-V4.0/corda-testnet-intro.html?highlight=joining%20corda%20testnet
2: Deploying Corda to Corda Testnet from your local environment
https://docs.corda.net/releases/release-V4.0/deploy-locally.html?highlight=deploying%20corda%20corda%20testnet%20from%20your%20local%20environment
We understood from the above documentation that we can download only one "Corda node" using one registration. Will we have to join the Corda Testnet using four different accounts in order to download four Corda nodes?
Is our understanding correct?
As per my understanding you can spin up multiple nodes with a refresh of the Testnet node installation page, or by creating a node and then clicking 'next', which should take you back to the node list and present a button to allow creation of another node.
It should provide you with a unique ONE_TIME_DOWNLOAD_KEY each time, and automatically assign you a randomised alphanumeric O (organisation) value to use within the nodes configuration file, helping the network map (and thus other nodes on the network) to distinguish your nodes individually.
Make sure you don't unintentionally run copies of the same node with the same identity, otherwise the network map will just assume there has been a change in the address of the original node and route P2P traffic to the newest instance.
Take a look at the node.conf docs to understand node configuration further:
https://docs.corda.net/corda-configuration-file.html
If we are trying to host corda node database in a SQL server can we host all of them in a single database? If yes how to do it and what will be its impact.
Can the built in H2 database which gets generated while a node is deployed be stored locally in a system such that data becomes permanent and is not lost in the next build?
Sharing an H2 database
As of Corda 3, each node spins up its own H2 database by default.
However, you can point multiple nodes to a single, stand-alone H2 database as follows:
Start a standalone H2 instance (e.g. java -jar ./h2/bin/h2-1.4.196.jar -webAllowOthers -tcpAllowOthers)
In the node.conf node configuration file, set dataSource.url = "jdbc:h2:tcp://localhost:9092/~/nodeUniqueDatabaseName", where nodeUniqueDatabaseName is unique to that node
For each nodeUniqueDatabaseName, H2 will create a file nodeUniqueDatabaseName.mv.db in the user's home directory.
You can also set a specific absolute path as well (e.g. dataSource.url = "jdbc:h2:tcp://localhost:9092/~/Users/szymonsztuka/IdeaProjects/corda3/nodeUniqueDatabaseName"). This will create a database file under Users/szymonsztuka/IdeaProjects/corda3/.
Note that this approach is not secure since the h2 server is started with -webAllowOthers -tcpAllowOthers, meaning that anyone can log in and modify the database.
Maintaining data across node builds
The H2 database is discarded when re-running deployNodes, because you are considered to be creating an entirely new set of nodes. If you only want to make changes to the installed CorDapps, you can shut down the node, update its CorDapps (by creating the new CorDapp JARs as described here and copying the CorDapp JARs into its cordapps folder) and restart the node. The new CorDapps will be installed, but the old node data will still be present.
Once Corda node failed, what is the appropriate process of recovery? Corda transactions are shared only with qualified nodes for specific business network, not with every nodes. Therefore, when recovering failure node, copying data from other node would not work well, recovering from backup is required. However, backup image is not completely same for other correct nodes, I would like to know how recover consistency of corda node.
Node data storage
A Corda node stores its vital information as follows:
The node's data is stored in a standard SQL database
By default, in an H2 database file called persistence.mv
The node's keys and certificates are stored in Java keystores in the certificates folder
Recovery from node crashes
If the node crashes:
The database and the contents of the certificates folder will not be affected
In-flight flows can be restarted from their most recent checkpoint
Artemis messages can be replayed
In other words, you can generate a new node, re-add the persistence.mv file, certificates folder and CorDapps, and the node will behave as if nothing happened when you start it up again.
Recovery from corruption/deletion of the node's files
Loss/corruption of data is non-fatal as long as you are able to recover:
The node's database
The contents of the node's certificates folder
It is the responsibility of the node's owner to ensure they protect and back-up these files using standard business procedures. If both of these can be recovered and re-added to a new node, the node should spin up as usual.
If the contents of the node's certificates folder cannot be recovered, you will no longer have your private key, and will not be able to spend your assets on the ledger.
If certain pieces of data cannot be recovered from the node's database, the node could attempt to re-request this data from other nodes where applicable (e.g. the transaction history). However, there is no way to force the counterparties to share this information.
In one of my GCP projects, I have created a new network with heightened security settings compared to the default network created for any project. I would like to migrate my existing instances from the default network to this new network without deleting them.
I'm under the impression that this can be accomplished by removing the existing access config, and then adding a new one that will be associated with the new network. So:
gcloud compute delete-access-config <name of instance> access-config-name=<name of config> followed by gcloud compute add-access-config <name of instance> access-config-name=<name of new config>. However, this only seems to affect the external IP of the instance and not the network itself. How would I go about removing the instance from the default network and moving it to the new one?
The helptext for these commands do not have a "name" flag. Did you mean to say "--access-config-name?:
https://cloud.google.com/sdk/gcloud/reference/compute/instances/add-access-config
https://cloud.google.com/sdk/gcloud/reference/compute/instances/delete-access-config