A key requirement for any distributed ledger system is the ability to guarantee consensus between ledger participants. Among other things, this means that every ledger participant must agree on whether a given transaction is valid or not, every time it is verified. We refer to this property as determinism.

To achieve this capability, Corda includes a DJVM — or Deterministic Java Virtual Machine — a component for enforcing determinism in the evaluation of Corda smart contracts (two blog posts provide more details on why such a component is necessary).

A partial preview of the DJVM was first delivered in Corda 4. This preview gave developers the ability to try out the DJVM’s bytecode rewriter. The DJVM uses this rewriter to automatically rewrite bytecode to catch calls to non-deterministic methods. Developers could run this tool against their smart contract code to see what bytecode transformations it performs.

Now, the release of Corda 4.4 marks a major milestone for the DJVM:

• Nodes can be configured to use the DJVM for every smart contract they evaluate, either via a configuration file or via the Corda DemoBench. Any nodes configured in this way will automatically detect and reject any non-deterministic transactions they receive
• A new Gradle script plugin allows most non-determinism in smart contracts to be detected at compile time, before a node is even started

The final step, which has been left for a future release, is to integrate the DJVM with Corda’s consensus rules. This will allow Corda networks to (gradually) enforce the use of the DJVM for all transactions on the ledger, eradicating non-deterministic transactions.

However, to bring the DJVM to a conclusion, we need your help. Every CorDapp implements smart contracts slightly differently. At one end, there are smart contracts that impose no restrictions at all. At the other are contracts amounting to full XML processing engines. The more complicated the smart contract, the more likely it is to break the DJVM’s rules on non-determinism.

Some of these rule-breakings will represent actual non-determinism — a smart contract making a network call — but others may not — perhaps a smart contract innocently attempting to use a method from a package that also contains a random number generator. Your input is essential to allow us to understand how real-world smart contracts are written, so that we can modify the DJVM to handle these edge-cases while maintaining the promise of complete determinism.

So if you’re a CorDapp developer, please download Corda 4.4, enable the DJVM, and give it a test run! We look forward to hearing how this affects your existing contracts at productfeedback@r3.com.

Let’s give it a whirl

Next, let’s look at a simple demo of the DJVM in action. We’ll start by defining a hopelessly non-deterministic smart contract — in our case, a naïve attempt to prevent from evolving past December 31st 2020:

public class DoofusContract implements Contract {
     public static final String ID = "com.contracts.DoofusContract";
 
     @Override
     public void verify(LedgerTransaction tx) {
         Instant currentTime = Instant.now();
         Instant startOf2021 = LocalDate
            .parse("2021-01-01")
            .atStartOfDay(ZoneId.of("Europe/London"))
            .toInstant();
 
         if (currentTime.isAfter(startOf2021)) {
             throw new IllegalArgumentException("Too late!");
         }
     }
 
     public interface Commands extends CommandData {
         class Action implements Commands {}
     }
 }

This contract is problematic. Even apparently-valid transactions committed in 2020 will suddenly stop being valid if they’re re-verified in 2021, compromising the integrity of the entire ledger.

We configure our node to use the DJVM for all transaction verification by adding the following line to the node’s node.conf file:

systemProperties = { “net.corda.djvm” = true }

Now let’s build a transaction using this contract and watch the sparks fly!

This is a simple example, but the DJVM prevents a wide range of non-determinism in smart contracts. You can read more about the full set of rules it implements here.

The deterministic JVM in action was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

“The Construction industries are entering a period of major disruption caused by new technologies such as Blockchain” — Philip Treleaven, Professor of Computing & Director of the Financial Computing Centre, University College London

In September, University College London’s Construction Blockchain Consortium (CBC) kicked off its first blockchain hackathon. This was the first in a series of events aimed at bringing together industry experts and software developers to create open-source applications and tools for solving problems in the construction sector (and if you don’t think there are problems in the construction sector — keep reading!).

For this first hackathon, the CBC decided that the teams would be building their solutions on the Corda blockchain platform. Corda is already in use by construction firms (such as Siam Cement Group who used Corda to streamline its procurement process by 50%). It also has key privacy, identity and workflow properties that are a perfect fit for the industry, as we’ll see below. I joined in a mentoring capacity as a member of the Corda developer relations team (if you enjoy traveling and telling crowds of developers how blockchain is totally the next big thing, we’re hiring).

For a more comprehensive write-up of the hackathon, see this blog post by a hackathon participant from our partner Industria.

Unlike most hackathons, which begin with frantic re-readings of the use-case documents and copy-pasting from online code samples, things started leisurely. Abel Maciel, CBC founder and head, had arranged for a first day of talks from construction industry experts. Each took turns detailing the huge challenges facing the construction industry today. Contractors refusing to perform the tasks they’d been contracted for, developers refusing to pay contractors, inspectors failing to perform their duties correctly… But above all, an complete opaqueness about who was being paid to do what and when. In the construction industry, it is common practice for contractors to delegate work to sub-contractors, who then pass this work onto sub-sub-contractors, ad infinitum. Once all various arrangements have been made, tracking a project’s progress accurately was impossible for all but the simplest projects.

It was a perfect example of a situation where blockchain’s promise of You See What I See would save everyone a lot of pain and money. Each firm would be kept completely up-to-date on the progress of the project. But crucially, details such as the sub-contracting arrangements in place couldn’t just be shared with everyone. These deals were key strategic information for the contractors delegating the work. This is where Corda’s ability to finely-tune how data is distributed through the network is vital for making blockchain solutions that are palatable for existing industry actors.

We settled on the creation of a CorDapp to automate construction workflows between developers and contractors. Our design was as follows:

• A developer and a contractor agree on a job. This is represented in Corda as a shared data object called a state. This state ensures that all involved parties have a consistent view of the progress of the job over time
• The state is governed by a contract. This contract enforces that all the participants to the job obey a shared set of rules governing how it evolves over time
• The job is evolved using flows — a flow to propose a new job, a flow to accept a new job, a flow to mark the job as finished… These flows conceal internals such as signing, messaging and database storage from the end-user when using the application

In the end, we had our initial CorDapp design up-and-running with a few hours to spare. Instead of kicking back at the UCL student café, we decided to go one step further and update the CorDapp so that jobs could be split up into a series of milestones. This allowed contractors to be paid per-milestone instead of per-job. This was another common issue in the construction industry, where cashflows can easily run dry over the course of year-long projects.

What features of Corda allowed us to build a suitable solution? I’d list four key areas:

• Corda’s state and contract structures allowed us to define shared data structures and shared rules about how these data structures could evolve over time. This prevented disagreements or mistakes between the various project participants
• Corda allowed all the project participants to hold a shared, consistent view of the project’s progress
• Corda’s need-to-know data distribution prevented external parties from discovering details of the project, despite being present on the same network
• Each Corda node has a well-known identity. Developers and contractors are sure which counterparties they are agreeing jobs with and transferring funds to

As well as the benefits of a blockchain approach, the hackathon highlighted the need for deep industry expertise when creating production blockchain applications. Although we had built a working proof-of-concept, there would be much more to consider in a production solution (I’ve probably mis-articulated the industry’s problems above, let alone how to fix them). In R3’s view, this can be addressed by building an ecosystem of partners who have the required industry expertise to build production blockchain solutions. Check out existing partner solutions here and apply to become a partner here.

It was definitely more than my team could handle in a couple of days, and we were left with a large pile of ToDos. The source code is here, so fork it and see how you get on — there’s probably a little more work required before this CorDapp can replace construction industry tools for real.

P.S. The CBC is now running a follow-up weeknight hackathon with Martin Jee’s Corda Code Club to address problems in the construction project financing space. You can track their progress here.

Corda in the Construction Industry was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

Traditional blockchain architectures distribute transactions using a gossip protocol. Each node maintains connections to a handful of peers. When a node creates a transaction, it tells its peers, who tell their peers, and so on, until the transaction has reached every node on the network.

This model provides no privacy. Every node sees every other node’s transactions. To allow private communication between nodes, Corda replaces the gossip protocol with direct messaging between nodes based on IP addresses. The messages are encrypted using transport-layer security.

When messaging a peer, how can a node operator determine the counterparty’s IP address? This is achieved using a mapping of legal identities to IP addresses called the network map. The network map has several advantages:

• Ease-of-use. Node operators can transact in terms of legal identity names, rather than public keys or IP addresses (parties can still optionally be identified by public key only in transactions stored on ledger, for privacy purposes)
• Business requirements. Node operators can ensure they’re agreeing ledger updates with the correct counterparties
• Joining and leaving the network. The event of a node joining or leaving the network can be clearly communicated by updating the network map

Re-designing the network map

In Corda 1.x and Corda 2.x, the network map service was provided by a network map node. Each node would query the network map node for a copy of the network map upon joining the network, and subscribe for future updates.

This design was only temporary. It had several downsides:

• It doesn’t scale. A single node is expected to simultaneously maintain open connections to every other node on the network
• It’s unreliable. If the network map node goes offline, no new nodes can start up
• It’s not secure. An attacker perform man-in-the-middle attacks by intercepting the traffic from the network map node and modifying its contents

In Corda 3, the network map node has been replaced with a network map document served over HTTP. At start-up, each node creates and signs a data structure called a nodeInfo. Each nodeInfo contains a node’s legal identities, IP addresses and other information.

The node uploads this file to the compatibility zone’s network map server (a compatibility zone is a set of nodes and services — notaries, oracles, doorman, network map server — that are configured within a larger Corda network to be compatible with each other). The node then downloads and caches the signed nodeInfos of all the other nodes in the compatibility zone from the same server, which it periodically polls for updates.

Why the switch to this new design?

• It’s highly available. The distribution of the nodeInfos can be offloaded to CDNs like Amazon CloudFront or Akamai, which are highly scalable, available and attack-resistant
• It’s tamper-proof. Man-in-the-middle attackers cannot tamper with the nodeInfos, since they are signed by the nodes themselves

Using the new network map

Development networks

For rapid prototyping, development networks do not require a network map document to be served over HTTP. Instead, each node’s nodeInfo file is simply placed in an additional-node-infos folder on every other node.

To automate this process, a bootstrapper tool is provided. The bootstrapper automatically converts a set of node configuration files into a set of nodes, and copies each node’s nodeInfo file into every other node’s additional-node-infos folder. This replicates the new design without the requirement for a separate server.

The bootstrapper is run automatically when generating a development network using the Cordform Gradle task. You can also perform the bootstrapping manually by following the instructions here. You must re-run the bootstrapper every time a node leaves or joins the network to ensure the nodeInfo files remain up-to-date.

Production networks

Production networks must create a network map server that implements the protocol described here. Each network operator will implement this protocol differently based on their network’s on-boarding process.

Find out more

To find out more, read the network map documentation and the bootstrapper documentation, or join the Corda community and dev team on the #cordaledger Slack channel.

If you encounter any issues with the new network map or other Corda features, post a question on Stack Overflow using the `corda` tag.

Re-Designing the Network Map was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.