There used to be a demo which ran distributed notaries which ran RAFT or BFT Smart as the consensus protocol.
This demo doesn’t seem to be available anymore via the main website.
Is there any documentation/sample code for running a distributed notary service with Raft or BFT Smart?
Yes, a distributed notary sample is still available. See https://github.com/corda/corda/tree/master/samples/notary-demo.
Related
While building a Corda network with multiple nodes and parties, how is the certificate renewal managed? Once a new certificate is issued to a node/party, how does that affect the earlier transactions and any ongoing transactions?
What you're asking about depends on the TYPE of corda network right?
So for example:
A bootstrapped network is "hard coded" from the beginning, meaning the certs and network map are all generated by the network bootstrappeer (https://docs.corda.net/docs/corda-os/4.7/network-bootstrapper.html) This is also what's normally used when running the gradle deployNodes task.
A production network usually has a network manager that handles most of the tooling here. That means that your nodes would just connect to the network manager and so you're not going to be as worried. You may need to generate a couple of certs at the beginning but after that you're good. For a good example take a look at this example of kubernetes where the certs are generated on corda firewall: https://github.com/corda/corda-kubernetes-deployment/tree/master/corda-pki-generator
I am trying to understand the applicability of pluggable consensus in corda.
For example, the consensus service from hedera hashgraph can be plugged into corda,technically. But I am not clear why it is needed?
Can anyone help me in understanding with an appropriate business use case?
Corda is an incredibly powerful toolkit for building business networks in a distributed manner. One assumption of Corda today is that it depends on either a centralized notary, or the need to configure a network of notaries, in order to provide uniqueness consensus of the Corda transactions.
The Hedera Consensus Service addresses this dependency. Rather than building a cluster of notaries, or trusting a single notary, transaction hashes can be sent to the Hedera Consensus Service which provides a consensus timestamp of the message by the globally distributed Hedera Mainnet. Any notary or member of the Corda network can independently verify the timestamp. This can provide a more decentralized and resilient infrastructure, as well as reduce the operating burden and cost of configuring the Corda network.
More information can be found on the corda notary here: https://github.com/hashgraph/hedera-hcs-corda-demo
When building on open source Corda how can I make changes to the project in way that the Corda node will continue to be interoperable with nodes built on standard open source Corda?
The concern is that by forking Corda I may inadvertently change the Corda protocol such that my node can no longer communicate with other nodes. For example: changing serialization could break the p2p messaging between nodes.
In addition: does the network the Corda node run in affect how much I can modify a forked version of Corda? For example:
What if the forked nodes are running in a private network where all nodes are under my control.
What if the forked nodes are running in the Corda Network where other nodes are using standard versions of Corda.
If you run in the Corda Network then the relevant policy is this one:
https://corda.network/policy/protocol-definition.html
Zone members agree that their nodes will understand the Corda protocol as defined by the open source reference implementation, of at least the version specified in the network parameters’ minPlatformVersion field or higher.
So you can modify your node as long as it still understands how to speak with other nodes. This is a fairly lax definition. You can change a lot without breaking that requirement. But it sounds like you already know what to watch out for - changing serialisable types, mostly. It's up to you to ensure you don't deviate from the protocol.
In your own networks you can of course do whatever you like. It's open source after all.
Background-
I am extremely new to CORDA and Blockchain Platform. In the past few months i have had my share of experience working on a small project on Ethereum as platform. Ethereum blockchain was leveraged as ledger to mark Transaction as a proof of existence. It means for some action (success/failure) we have marked respective transaction on Blockchain. We may consider it as a proof of concept to show knowledge of interaction with nodes running on Ethereum Blockchain.
Infrastructure - Node.js web services, two ethereum (PoA) nodes
Question-
I would now like to port this running example on to CORDA blockchain. How would i achieve this with bare minimum changes. That means if i have a Corda network with two nodes running on my system and i want my web services to connect to one or both of the nodes and save the transaction (in its state). I understand that this certainly is not what CORDA might be meant for. Consider this question as my first step to interact with CORDA from Node.js web services.
Any inputs highly appreciated.
I recommend you go through the documentation first. your Tx will be a state. you need to build contracts and flows for a Tx to happen. Tx will happen using flows which will be initiated using Crash Shell or RPC Client. AFAIK, this client is in Kotlin or Java. so you'll have to create a JAVA or Kotlin application to instantiate this client. now in the Java application, you'll have to expose rest endpoints to communicate with the client which will initiate your flows. you can call these rest endpoints from your node application. All this has to be created in CodaApp. This is the bare minimum.
I just found there is a library.
look at this: https://gitlab.com/bluebank/braid
This can help you.
From a Corda business network design perspective, may Corda oracles propose transactions? Reading the Corda Docs about oracles, my impression is "no", but maybe I'm misreading, or reading too much into the docs, e.g.,
"Oracles are network services that, upon request, provide commands that encapsulate a specific fact (e.g. the exchange rate at time x) and list the oracle as a required signer."
ref: https://docs.corda.net/releases/release-V2.0/key-concepts-oracles.html?highlight=oracle
Oracles are just regular Corda nodes, and any Corda node can serve as an oracle, provided it is trusted to provide a certain set of facts. Although oracles may differ from other nodes from a business perspective in that they are recognised providers of trusted facts, they are identical from a technical perspective.