Smart Contracts and Resource Usage


(shane.neighbors) #1

This is in regards to how smart contracts will spin up and remain active within Corda. Currently with Fabric a new docker image is created each time a smart contract is initiated thus a large amount of resources could be consumed for a large number of concurrent smart contract creation.

With Corda a JVM will be created - is this also a 1 for 1 (smart contract to JVM), assuming the short answer is yes? Has there been any benchmark testing on the amount of resources that are being consumed per creation of smart contract (on average) and how quickly those resources are freed up or reused?


(Rope Trick) #2

I’m a noob to corda. So take my answer with a pinch of salt.

With Corda a JVM will be created - is this also a 1 for 1 (smart contract to JVM), assuming the short answer is yes?

In Corda, the smart contract biz logic is spread across many( small number of) nodes. And it is 1 JVM per node.
Typically the smart contract( application) is developed as a cordApp that typically forms a network of nodes upon execution. the Flows defined in the cordApp effects the node’s behaviour.

Thus depending on the complexity of the contract application, it is handful of JVM across distributed set of machines. The network of nodes mapping to machines is again specific to the application engg.

Given a smart contract cordApp, measuring resource usage on a typical transaction’s lifecycle might throw insights on resource efficiency of corda.


(Roger Willis) #3

Ok so a basic set up for an entity could look like this:

• You’d have a machine hosting an in-bound message broker (currently this is integrated into the Corda node but we’ll be splitting it out)
• Then have a bunch of Corda nodes which consume messages off the queue. Can add as many nodes as you like to deal with scaling.
• There’s a one to many relationship between corda nodes and CorDapps. A corda node can host many CorDapps.
• CorDapps can be loaded in at runtime (currently they have to be present in the “plugins” folder upon node start-up)
• CorDapps kick-off flows. Flows come with two sides. Typically we bundle both sides in the CorDapp package but there is nothing to stop developers building context specific flows as long as they conform to a specified interface: they send/receive objects of the right types at the right times. E.g. different entities may have different review processes or wish to grab data from different systems.
• Flows call contract code for contract validation which is executed in the smart contracts sandbox.
• Each node will have one sandbox.
• Each sandbox can execute multiple contracts. Though I believe it is single threaded?
• As flows are just JVM bytecode we can persist them to disk at any time. We do this with the Quasar fibres framework. Indeed, when flows call the network then we persist the state of them to disk. This is how workflows can span day or even months.
• If a node dies, it doesn’t matter. We can start it back up and continue all workflows from where they left off. All the persisted flows will be deserialised and spun back up as and when required.
• In theory, a Corda node can operate potentially tens of thousands of flows at any time. Some may span weeks / months.

In short, there’s practically no limitations. You just spin up more nodes if you need more capacity. Our approach to running workflows concurrently using fibers is extremely scalable and don’t require us to keep all running “contracts” (flows) in memory.