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
Related
Within one business network (Business Network A), a notary provides validation and signing off on the transaction proposed by N number of participants.
In the situation where this asset needs to be transferred from one business network (Business Network A) to another (Business Network B), how will the provenance work already completed on the Business Network A be maintained, handled while working in Business Network B?
when there is a transfer of assets from one network to another.
i.e. Morgtage Home Loan Cordapp ---> needs asset transferred to Legal Lending Cordapp
it's not completely clear how the notaries will be setup, and the level of privacy and/or data isolation that will be able to be maintained between notaries on different collaborative Business networks.
Please explain.
One requirement for a compatibility zone is that all the nodes in the compatibility zone are able to transact for any purpose at any time using any application using any vault data. Among other things, this implies that:
The notaries in the compatibility zone are not associated with any individual business network(s). Each notary is a notary for the entire compatibility zone
All nodes in the compatibility zone are required to trust all the notaries in the compatibility zone
When you want to move a state to a new notary, you use the built-in NotaryChangeFlow to repoint the state to the new notary:
val newStateAndRef = subFlow(NotaryChangeFlow(originalState, newNotary))
If the new notary is validating, it will request the entire transaction chain from the caller of NotaryChangeFlow.
I am writing Corda App for financial transactions between companies. The incoming transaction initiates a business workflow at the receiving end. Can Corda flows be used as a general purpose BPMN software or is it a better design to use a separate BPMN software and trigger flow in that system?
It really depends on the kind of BPMN you have in mind.
However, within a flow you have full access to any JVM libraries. You can perform networking (see the Flow HTTP sample here), DB reads (see the Flow DB sample here), and anything else.
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.
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
Both solve completely different problems:
An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
An RPC system provides client and server technologies for performing RPC operations.