September 29th was the second day of CordaCon 2021! This year CordaCon is a hybrid of in-person and virtual talks., We have a great panel of speakers, an impressive list of sponsors, and many registered attendees.

If you missed CordaCon today or were just looking to see a recap of the highlights, look no further!

Highlight #1 Michael Bodson’s talk on blockchain innovation

Today, we had a great talk from Michael Bodson of the Depository Trust and Clearing Corporation, who explained his principles for innovating with DLT.

If you missed it, here’s the recording:

Link: https://www.cordacon.com/agenda/session/633846

Highlight #2 Corda 5 Developer Preview

R3’s Christian Sailer and Nina Kanti gave a fantastic talk breaking down the new Corda 5 Developer Preview details.

Link: https://www.cordacon.com/agenda/session/630205

Highlight #3 CorDapp Development Made Easy

R3’s Alex Koller and Moritz Platt gave a great talk on how to think about CorDapp development.

Link: https://www.cordacon.com/agenda/session/630208

Notable Mentions

Today, I talked about how Corda will enable developers to use containers in their local development workflow (including Docker and Kubernetes!)

Link: https://www.cordacon.com/agenda/session/630213

Dapeng Wang gave a fascinating talk on making Corda Quantum resistant.

Link: https://www.cordacon.com/agenda/session/648799

These were just a few of the many developer highlights from day two — I hope to see you all tomorrow for the last day of CordaCon!

Happy coding ~

CordaCon Day 2 Recap was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

Highlight #1 — The keynote!

R3 CEO David Rutter gave the keynote and welcome address. I would recommend checking it out before looking at the rest of the sessions.

Link: https://www.cordacon.com/agenda/session/628369

Highlight #2 — R3’s product vision and Roadmap

Our Chief Product Officer, Todd MacDonald, took the time to break down the vision that R3 has for its products in the future. Then John Shaw, our Head of Product Management, lays out exactly how R3 plans to accomplish that vision.

R3’s Product Vision: https://www.cordacon.com/agenda/session/628386

R3’s Product Roadmap: https://www.cordacon.com/agenda/session/628402

Highlight #3 — Privacy insights!

R3’s Chief Technology Officer Richard Gendal Brown sat down to talk about the future of data privacy and misuse. It’s an excellent opportunity to learn more about why and how new tools are being adopted in the space of trust computing.

Link: https://www.cordacon.com/agenda/session/628376

Notable Mentions

We had a fascinating session where David Vatchev from our Venture Development team sat down with David Chreng of LeadBlock partners and Alex Barkley of HSBC Ventures on the evolving VC landscape.

Link: https://www.cordacon.com/agenda/session/628397

Dries Samyn and Nina Kanti walked through the Corda 5 Developer Preview

Link: https://www.cordacon.com/agenda/session/641176

These were just a few of the many developer highlights from day one — To find out more about the sessions we’re running tomorrow, you can visit cordacon.com. I hope to see you there!

Happy coding ~

CordaCon Day 1 Recap was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every day on the stock market, over 1 trillion dollars of value canges hands between traders across the globe. There have always been essential arguments to make for blockchain in the markets, but the past couple of weeks were a little different.

Within the past few months, Cryptocurrency reached 1/10th of the market cap of gold.

If you’re in finance or technology, you have almost definitely heard about GameStop ($GME) lately. Gamestop trading rapidly increased due to an opportunity to profit from short-sellers and market-makers and a low percentage of floating shares. At one point, GameStop’s trading volume encompassed about 1/6th of the entire financial sector.

Power to the players

Social media traders realized they could leverage market makers and short-sellers against each other and inflate the stock price. This worked because short interest was over 100% of the available shares on the market for some of these stocks. The prices of $GME and $AMC shot to new highs and could have triggered the shorts to buy-in.

At one point GameStop trading volume encompassed about 1/6th of the entire financial sector.

On January 28th, at the height of the frenzy around Gamestop shares, Robinhood and other brokerage firms put out statements restricting their customers from buying shares of AMC, GME, and several other companies. The reason was that clearing firms could not continue offering customers the ability to purchase those highly volatile stocks without the brokerage placing massive capital deposit requirements to hedge against the risk the clearing firms were taking on by allowing these stocks to be traded. Many users blamed the brokerage firms for attempting to influence the share price.

The clearing process

To understand why the brokerages had to stop selling, we have to understand the clearing process when we buy stocks.

There are a few entities involved when a customer purchases stock in a typical transaction:

• A brokerage itself
• A clearing corporation

A clearinghouse acts as an intermediate party for transactions between two customers of brokerage firms. This reduces risk and ensures that trades are correctly settled. Most of the time when a stock is purchased, the clearing firm holds the collateral on both sides of the trade, and the business is considered “settled” when both parties have the correct assets they intended to receive. This settlement typically takes two days. As an aside, the broker is only a custodian of your shares in a company. They are never the owner at any point in the process.

This is commonly referred to in the industry as “T+2 settlement”. You can find more on stock settlements on Investopedia.

GME, AMC, and others have become incredibly volatile. Some of these stocks had swings of 50% or more in a given day. GME experienced every single call option becoming in-the-money, which was historic. When things like this happen, you can see why a clearing firm can be in a difficult position — they may be holding that stock during the clearing process for one or two business days for settlement to occur. If the clearing firm can lose massive amounts of money from market volatility in those days, that’s a big problem. That’s why they required brokerages to post colossal capital margin requirements to ensure the trades clear.

Because this cost was passed to zero-fee brokers, the brokers were in a difficult position to limit trading because they couldn’t post the required capital to enable the trades to clear.

You’re probably wondering just what is it about the clearing process that makes settlement take so long?

Settlement with a blockchain

The original reasons for settlement times seem to be reasonable from a regulatory perspective. There are many reasons you wouldn’t want trades to happen instantly.

A common allegory compares settlement with buying a house in 1800. There’s a lot of money involved; it takes a certain amount of time to get the message across to the other party and to ensure no one reneges on the deal; sometimes people buy houses and then change their minds, sometimes people hope to get lucky and get a free home and try to manipulate the process. These are concerns at the broker level but get sorted out by the clearinghouse at the end of the settlement period.

You’d imagine this should be immediate in the software-rich environment we live in today. We’ve had various famous investors and entrepreneurs including the CEO of Robinhood calling for precisely that in light of all this.

“It’s time for zero day settlement, and maybe we’ve found the first use case for blockchain — @chamath”

So could we do this with a blockchain? Absolutely.

It’s entirely possible for settlement to be based on a shared blockchain ledger between all brokerages with a solution like Corda.

The modeling for this is relatively intuitive: you could create Corda states to represent shares in a company and tokens representing derivatives like futures and options. Once you model your assets in Corda, you’d have each brokerage run a Corda node. Every transaction would write to the shared ledger and have to be agreed upon by all parties. There’d be no need for a clearinghouse to have any uncertainty, as each transaction can require the signature of all parties to it.

We’ve already built this. In fact, I’d highly recommend looking at our open-source corda settler to see how a more mature version of this solution could look like in production.

As a practical matter, Corda is no ordinary blockchain. It is designed to run at scale to enable larger enterprise institutions to leverage blockchain. Deploying Corda in an organization like the depository trust and clearing corporation, which handles quadrillions in assets per year, would create fascinating use cases.

Issues like what the brokers experienced could be entirely avoided with blockchain. Purchasing, clearing, and settlement of stock trades should be instant and available to the free market at the tap of a finger. We believe blockchain is the tool for the job, and we look forward to the challenge.

Want to learn more about building rock-solid distributed blockchains on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

Gamestop, Blockchain, and the Cluster of Clearing was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve done a lot of work with log aggregation tools like Splunk, you’ve probably come against many issues with trying to export logs from all of your distributed systems in a way that your aggregator can understand. The industry has all but settled on JSON. Naturally, a lot of the services developed over the past couple of years all support JSON.

This is a common question we’ve received as developers try to integrate Corda into their existing monitoring setups. We’ve made strides in this by working on integrations with Prometheus, Grafana, and Truffle. Still, today I’m excited to share a developer sample I’ve put together in collaboration with Splunk to enable developers to create a stream of logs in JSON.

Using Log4J2 in Corda

Internally Corda uses an open-source logging utility called Apache Log4j2. This utility is quite powerful because it’s so customizable. If you look at our template CorDapp, Corda typically supplies an XML configuration file with some sane defaults. However, it’s possible to customize this configuration file to output JSON and modify your code to produce arbitrary JSON objects.

If you’re looking to grab the XML file and be on your way, here’s the configuration file.

You’ll want to know how on line 13, we specify an actual filename for the node to output this JSON log.

The other note is that on line 14 in our JsonLayout tag we’ve specified an attribute of properties="true" . This is important for us because we want to add additional properties to these JSON objects as they get logged out from our CorDapps.

If you’re trying to specify the config file alone, you can do that with a quick command line flag:

java -Dlog4j.configurationFile=logging-cordapp/build/resources/main/log4j2.xml -jar corda.jar

Logging Arbitrary Objects

Once you’ve got your logging configuration setup correctly, using the logger and adding arbitrary information is relatively easy.

You can create your loggers and add properties to the ThreadContext object, and they’ll be logged as part of the entities.

If this small example makes sense, you have everything you need to get more robust output from your CorDapps!

Happy coding ~

A special thanks to Jayson Jacobs from Splunk for his help putting this together.

For early access to Splunk Connect for Corda, reach out to blockchain@splunk.com.

You can find the example CorDapp in both java and kotlin on Github.

Happy logging ~

Want to learn more about building rock-solid distributed blockchains on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

Creating a JSON log stream from Corda was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

The new year is here, and it was a significant one for blockchain. We wanted to take a quick look at the most exciting CorDapps we came upon over the past year.

The ones worth highlighting here are predicated on what our team thought were great ideas, practical use-cases, and ways to use corda that we just wouldn’t have expected.

#Honorable — Snakes and Ladders on Corda

One honourable mention I wanted to make is the snakes and ladders CorDapp by @iashutoshmeher. Ashutosh is one of our developer evangelists, and when he commits to building a CorDapp he does not disappoint! His CorDapp was a full implementation of snakes and ladders constructed on top of Corda so that players could use Corda to be sure of no funny business!

It uses a Tomcat web server to host the game from the Corda node itself and allows players to trigger Corda transactions that update the game state from within the browser.

You can find a link to Ashutosh’s CorDapp here.

#3 — A CorDapp for Students Relocating for University

Our number two spot goes to the PR CorDapp by @ajcrypto / @RK3173 on Github. Planning a relocation was a compelling use case, and we’re happy to feature it.

The idea is to use Corda as a broker for information between universities and students who are relocating to university. With a blockchain as the data broker between these parties, the entire process can be streamlined for the students relocating. Nicely done!

Curious to take a look at the code? Find it on GitHub here.

#2— A Centralized Corpus Manager for Machine Learning on Corda

The next CorDapp on our list was the decentralized corpus manager by R3 Solutions engineer @JonathanScialpi!

The project’s idea is to use Corda as a broker for crowdsourcing data for machine learning models. It uses Corda contract verification to ensure that corpus updates are valid and preserve the privacy of the crowdsourcers of the data.

If you’re curious to learn more about the project, you can find Jonathan’s post on the subject here, and you can find the project code on Github.

Some honorable mentions

Before I jump into our top CorDapp, some notable mention is due to a couple of standout moments for CorDapps in 2020:

• The NASDAQ announced using Corda to perform securities exchanges.
• Corda 4.7 was the most recent of a long string of successful releases in 2020.
• HSBC used blockchain to transfer over 20,000 tons of oil using Corda.

But Corda of course is versatile with how it can be used. On the developer relations team, we’ve built out CorDapps for Snakes and Ladders and Secret Santa.

#1 — CLAIMSHARE by IntellectEU

It probably won’t surprise you to see this here if you were a part of the R3 Insuretech challenge earlier this year, as this was the challenge winner. This CorDapp was designed as a fraud detection platform for the insurance market. The idea here is to solve the “double-dipping” problem. They do it using secure computing with Conclave, Corda, and a mix of artificial intelligence tooling to ensure that the same claim can never be submitted twice.

The team documented a comprehensive process their tool is using. It uses a combination of Corda, fuzzy matching, public data, and date matching to be sure that they’ve got a match on the same claim being made multiple times. Double dipping is a critical and fascinating problem for the industry, and I look forward to seeing them solve it.

You can find out more about CLAIMSHARE from their article on it here.

More honorable mentions are also deserved for the teams that came in as runners-up in that challenge:

• Fardoe Software
• Photocert
• Rexs.io

If you are interested in exploring more Corda Challenges, you should check out our 5G challenge with AWS, Swisscom, and Vodafone.

Did you enjoy the list? Have a CorDapp you want to see featured?
Let us know! Send an email to devrel@r3.com.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

Top CorDapps of 2020 was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

Try the simple building blocks for truly decentralized apps.

Welcome to the new year! If you’re looking for some inspiration to build on an open-source blockchain, then you’ve come to the right place.

Our goal in building a distributed application can be broken down into three mini-goals:

• Represent abstract entities.
• Represent abstract operations on those entities.
• Trigger those operations and reach consensus among the parties involved.

We call this collection of features a CorDapp, and you can implement them in Java or Kotlin. (To be clear, however, you could use any JVM language.)

So let’s imagine an intuitive use case for our CorDapp: Cars!

Imagine in our simple example that a unique party manufactures cars. After being created, those cars are then distributed to dealerships that sell them to specific persons and corporations. We can perform specific operations on cars, we can manufacture them, and we can sell them, and we can change information about them like license plate number and mileage.

The ideal scenario is where all of these parties use Corda so that the entire history and ownership of that car can be tracked.

To model our car sales, we’ll create three separate abstractions in our programs:

• States.
• Contracts.
• Flows.

For clarity, I’ll use Java for this tutorial, but the kotlin classes are very similar.

With each of these objects, you have the tools to model the manufacturing of a car, ensuring that the vehicle is valid, and perform a valid issuance of a newly manufactured car according to a set of contract rules — all with the added power of an immutable ledger underpinning it.

Let’s do a short walkthrough of the critical sections of code. If these make sense, then you’ll already understand everything you need.

States

States are objects, just like you’d model in any other programming language. You can model our car state in a pretty intuitive way.

So our car has a license plate, a VIN number, and other basic properties.
Then is has a bank that owns the car, the dealer holding it, and the manufacturer. We also include some details about the parties to the transaction

If this makes sense then you’re ready to create the operations that can be performed on our car! That’s where contracts come in.

Contracts

Contracts are our tool to represent the abstract operations that we can perform on these objects.

With your contract, you can create rules to deal with whatever checks you need to ensure your ledger updates are valid. Here’s an example of how simple those checks could be. Thinking back to the car example, this is where we might check things like the license plate and the VIN number to make sure that everything checks out. (You could even use a Corda oracle for this too but that’s another conversation).

For example, if this is a new car, the mileage should probably be low. If you’re buying the car from someone else you don’t necessarily need the mileage to be low so you might check that in a sale differently than you would in the issuance of a newly manufactured car from the factory.

Now that this is in place, both parties can verify the validity of the entire transaction with contract rules. Here, our rules are intuitive enough, an issue command has to correspond to a new car state, and the license plate has to have seven digits.

Assuming these rules are satisfied, the transaction is permitted to complete and it is successful.

Flows

The last piece of the puzzle here is flows. Remember that flows are simply tools to trigger transactions between parties on the network. So, we could have a flow that issues our new car and a flow that enables us to share it with another party.

A good example flow is one in which you issue, manufacture your car, and introduce the asset to the blockchain.

In the flow below a car is created and given to a holding dealer. That is why it’s specified here as an output state.

Here our car flow does what we’d expect it to, we give Corda the details of the car and the Corda node representing the manufacturer does the work of creating the car and collecting all the signatures of the other parties that have to be aware of the car’s existence. (You can also extend this example to include regulators like the SEC or observers like NHTSA).

If this flow example code made sense to you then congratulations! You essentially understand Corda and shouldn’t have much trouble getting through our tutorial to build out your own blockchain use cases.

Now as with all things in computing, there’s more detail to understand than just this. There’s a couple of tools here that you’ll need to do some more digging into such as responder flows, the subflows I used for signatures, and the transaction builder, but most use-cases can actually get by with just these building blocks.

Now you’re off to the races ~

Wrapping Up

I’m sure this isn’t the first blog post you’ve read that helps bring you some inspiration about what you can build with blockchain. I don’t need to convince you of the merits of using open source to create great things.

If you think this tutorial was intuitive and want to build something yourself, I’d encourage you to look at our Corda tutorials and try building something for yourself!

If you have ideas about what you want to build, maybe this is your year. All I ask is if you have some inspiration to tell us about it! You can find us on our slack or tell us about your project at r3devrelations@r3.com. I certainly look forward to seeing it.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

Start off the New Year with Blockchain was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quick tutorial with code examples

Hey there, if you’re reading this you’re probably looking to get Corda set up in a cloud provider. This is a short and sweet guide to help you do that without too much pain.

Step 1: Set up your network

In our setup, we have a simple network with four nodes running on two virtual machines. The main requirement, of course, is that the nodes must be able to reach each other.

Start by opening the google cloud console and provisioning two nodes on your favourite Linux distribution. (In my case, I’ll pick the latest version of ubuntu). My recommendation for a Corda node is at least an e2-standard-2.

If you’re looking to get a demo working, I’d recommend a simple set of firewall rules that allow all traffic. Once you’ve done that you can ensure the nodes can communicate with a simple ping test.

Once you have tested the connection and you believe the nodes can communicate, you should be aware of the danger of allowing all traffic to the group. It is not safe to allow all inbound traffic on a production instance of pretty much anything.

For a guide on Google Cloud Networking configuration, I recommend this page of the documentation.

One last thing to do before you go on to access the nodes is to modify your codebase.

I’ve set up a repository for this tutorial on GitHub. Download this repository and you’ll notice a VM1 folder and a VM2 folder. You’ll also see a commands.sh that contains code you can use when provisioning the actual machine. So two of our Corda nodes, the Notary and “Party A” will run on VM1. The other two of our Corda nodes, the “Party B” and “Party C” will run on VM2.

Both of those folders have similar contents, and you need to make sure that you add the public IP addresses of the Corda nodes to align with the VMs that they’re going to run on.

Take the IP address of the ec2 instance that will run VM1’s nodes, and then add its IP address to the p2pAddresssection of VM1/notary/node.conf.

For example, if the node’s IP address was 104.211.141.139 Then the resulting file would look like this:

p2pAddress="104.211.141.139:10002"
rpcSettings {    
    address="0.0.0.0:10003"    
    adminAddress="0.0.0.0:10043"
}

Heres’ a link to the node.conf file you can use so you know where to go.

Now add that same IP for the p2pAddress of theVM2 nodes. (Party B and Party C).

Once that bit of housekeeping is done, you’re ready to copy these folders onto the virtual machines.

Step 2: Run Corda

Once you’ve got ssh access, copy your folders onto the virtual machines. After a quick scp or rsync you should be all set. After copying over the folder, just run the commands.sh file I provided in the root of the repository. If all goes well, the virtual machines will be able to run docker without any issues.

Once you’re in, cd into the folders for each VM and run the following docker command with the right file:

docker-compose -f docker-compose-vm1.yaml up

Note: Docker may show an error about not having permissions to write to a database file, if you see that just make sure to change the permissions of the VM directory to make sure that both your user and the ‘docker’ user can write to them.

Step 3: Test your network

Now that you’ve got everything running on docker, it’s time to test your network and connectivity. You can do this with the Corda Node Explorer. (download link here)

You can log into the node explorer using a specific virtual machine’s IP address and the node port specified in the rpcSettings address of the node conf. (In this case, it’s 10006 for Party A).

The username and password are also specified in the node.conf, so we’ll use them here.

If all goes well and the nodes can communicate with each other, you’ll be able to see nodes from VM1 and VM2! Not bad!

That about covers it! Once you’re in the node explorer, you’re able to interact with your network, create transactions, run vault queries, and more!

And just for convenience, the link to that github repo is here.

You can also find a video version of this tutorial on youtube here.

Happy Coding ~

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

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

Hey there, if you’re reading this you’re probably looking to get Corda set up in a cloud provider. This is a short and sweet guide to help you do that without too much pain.

Step 1: Set up your network

In our setup, we have a simple network with four nodes running on two virtual machines. You can provision them in the same VPC if you want, but the main requirement, of course, is that the nodes must be able to reach each other.

Start by opening the AWS management console and provisioning two nodes on your favorite Linux distribution. (In my case, I’ll pick the latest version of ubuntu). My recommendation for a Corda node is at least a t2.medium.

If you’re looking to get a demo working, I’d recommend a simple security group that allows all traffic. Once you’ve allowed all traffic you can ensure the nodes can communicate with a simple ping command test.

Once you have tested the connection and you believe the nodes can communicate, you should be aware of the danger of allowing all traffic to the group. It is not safe to allow all inbound traffic on a production instance of pretty much anything.

For a guide on AWS Network configuration, I recommend the Amazon documentation.

One last thing to do before you go on to access the nodes is to modify your codebase.

I’ve set up a repository for this tutorial on GitHub. Download this repository and you’ll notice a VM1 folder and a VM2 folder. You’ll also see a commands.sh that contains code you can use when provisioning the actual machine. So two of our Corda nodes, the Notary and “Party A” will run on VM1. The other two of our Corda nodes, the “Party B” and “Party C” will run on VM2.

Both of those folders have similar contents, and you need to make sure that you add the public IP addresses of the Corda nodes to align with the VMs that they’re going to run on.

Take the IP address of the ec2 instance that will run VM1’s nodes, and then add its IP address to the p2pAddresssection of VM1/notary/node.conf.

For example, if the node’s IP address was 104.211.141.139 Then the resulting file would look like this:

p2pAddress="104.211.141.139:10002"
rpcSettings {    
    address="0.0.0.0:10003"    
    adminAddress="0.0.0.0:10043"
}

Heres’ a link to the node.conf file you can use so you know where to go.

Now add that same IP for the p2pAddress of theVM2 nodes. (Party B and Party C).

Once that bit of housekeeping is done, you’re ready to copy these folders onto the virtual machines.

Step 2: Run Corda

Once you’ve got ssh access, copy your folders onto the virtual machines. After a quick scp or rsync you should be all set. After copying over the folder, just run the commands.sh file I provided in the root of the repository. If all goes well, the virtual machines will be able to run docker without any issues.

Once you’re in, cd into the folders for each VM and run the following docker command with the right file:

docker-compose -f docker-compose-vm1.yaml up

Note: Docker may show an error about not having permissions to write to a database file, if you see that just make sure to change the permissions of the VM directory to make sure that both your user and the ‘docker’ user can write to them.

Step 3: Test your network

Now that you’ve got everything running on docker, it’s time to test your network and connectivity. We’re going to do this with the Corda Node Explorer. (download link here)

You’re going to want to log into the node explorer using a specific virtual machine’s IP address and the node port specified in the rpcSettings address of the node conf. (In this case, it’s 10006 for Party A).

The username and password are also specified in the node.conf, so we’ll use them here.

If all goes well and the nodes can communicate with each other, you’ll be able to see nodes from VM1 and VM2! Not bad!

That about covers it! Once you’re in the node explorer, you’re able to interact with your network, create transactions, run vault queries, and more!

And just for convenience, the link to that github repo is here.

You can also find a video version of this tutorial on youtube here.

Happy Coding ~

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

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

The literary scene around blockchain technology has been quite interesting to watch, but unless you’re an academic, you don’t get to see many details.

Most of the time, the public conversation around using a public or a private blockchain revolves around some intuitive concepts, about knowing who’s on the network, and some efficiency questions. It turns out there’s more to it than that.

Since blockchain’s first invention, we’ve gotten a much better understanding of the tradeoffs between public and private blockchains. The original reason for the excitement around the blockchain was that it seemed to be a solution to the Byzantine Generals problem. But you actually can use classic byzantine consensus on a private blockchain instead of the modern Nakamoto consensus. [1] Depending on your network guarantees, private blockchains can run with notaries to validate transactions. These seem counter to the original intuition around a public blockchain, so let’s get into the details and see where academics can shed some light for us.

Privacy

The arguments around private blockchains are relatively intuitive.

Public blockchains enable anyone to write to the blockchain, and transactions are published to everyone on the network / the world to ensure eventual consistency (Blockchains don’t violate the CAP theorem!). In a way, privacy is not possible. The public blockchain can anonymize your transactions with others, but it’s possible to trace public blockchain addresses back to individuals.[5]

Private blockchains enable users to be sure who’s participating on the network and who is reachable from the outset. An organization controls write access to the blockchain. This privacy is nearly guaranteed, which is why lots of private institutions using Corda use Corda. [4]

Consensus

Public blockchains naturally need to be larger to ensure that false transactions can’t get onto the network, making them difficult to use for smaller groups wanting to transact together. [3] There actually can’t be a public blockchain for a small group of individuals.

Most public blockchains use Proof-of-Work consensus algorithms where miners compete against each other to verify the validity of a transaction and get rewarded. The problem with these networks is that they can be slow to achieve consensus. They can take a long time to verify transactions. Due to the Merkle tree mechanics, individual transactions can get rejected by a competing chain of unconfirmed transactions.

On the private side, consensus algorithms can vary quite a bit. Most private blockchains do not need to run computationally intensive and wasteful consensus algorithms. The majority of private blockchains can reach speedy consensus without many issues. Corda even lets you configure your consensus algorithm based on your private network (more on that here).

Energy

There’s another important aspect here which is the electricity waste of certain consensus mechanisms.

Note: in a literal and physical sense, energy can not be consumed, created, or destroyed, only converted from electrical energy to a less useful form like heat.

When I say energy waste here, I am referring to waste concerning the possible use cases for electricity.

It’s worth mentioning that exciting work has been done to convert this heat into useful work, but it’s difficult for the cost of regular heating to be better than heat from mining.

Here’s a great chart outlining the kind of energy use that we’re talking about when we look at public blockchain and cryptocurrency consensus algorithms.

The bitcoin Proof-Of-Work consensus protocol uses around 100 Terawatt-hours (TWh) every year (10¹² watt-hours!). For comparison, In 2018, the average annual electricity consumption for a U.S. residential utility customer was 10,972 kilowatt-hours (kWh). Bitcoin alone could have powered 91,142 homes last year.

In short, it’s cheaper, and potentially greener, to run a blockchain yourself privately.

Efficiency

Lots of things can influence the speed of a transaction. But it’s generally the case that private blockchains have fewer participants, meaning they can move faster.[1]

The average Bitcoin blockchain transaction takes around 30 minutes to over 16 hours to be confirmed in extreme cases.[6] This isn’t tenable in most compelling use cases that we might think of for a public blockchain — like voting, stock trading, and online gaming.

There’s a lot of ideas on how to improve that down the road with innovations like lightning networks, but so far, these problems haven’t been adequately solved, and scalability is a common topic of debate in many communities for blockchain technology. To be fair it’s worth mentioning that since bitcoin’s initial development, other blockchains have been deployed that can process transactions much faster like lumen, ripple, and EOS. In fact, there are even blockchains that can handle one million transactions per second.

On the other side of the fence, private networks have a much easier time resolving transactions quickly. A production Corda environment can handle thousands of transactions per second.

If you look at the blockchains available, you’ll start to appreciate more of the problems a developer has to be aware of when building on a blockchain. What we’re seeing is that the private industry likes private blockchains.[7] While a public blockchain is a unique tool, I have found appropriate use-cases to be rare. Try to remember that the consequence of these decisions do not belong to us, but our users.

If the idea of building on a private blockchain like Corda sounds interesting to you then I’d recommend Corda’s getting started page to see what you can do with it. Good luck!

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

• [1] Staples, M., Chen, S., Falamaki, S., Ponomarev, A.,
  Rimba, P., Tran, A. B., Weber, I., Xu, X., Zhu, J., (2017)
  Risks and opportunities for systems using blockchain
  and smart contracts. Data61 (CSIRO), Sydney.
• [2] J. Sedlmeir H. U. Buhl G. Fridgen R. Keller
  Project Group Business and Information Systems Engineering of
  the Fraunhofer FIT, Bayreuth, Germany
• [3] 51% attack: https://www.crypto51.app/about.html
• [4] Novotny, Petr, Zhang, Qi, Hull, Richard, Baset, Salman, Laredo, Jim, Vaculin, Roman, Ford, Daniel L, and Dillenberger, Donna N. “Permissioned Blockchain Technologies for Academic Publishing.” Information Services & Use 38.3 (2018): 159–71. Web.
• [5] Yousaf, H; Kappos, G; Meiklejohn, S; (2019) Tracing transactions across cryptocurrency ledgers. In: SEC’19: Proceedings of the 28th USENIX Conference on Security Symposium. (pp. pp. 837–850). ACM: Berkeley (CA), USA
• [6] Source from Coincentral.
• [7] Kwak, Ki & Kong, Jun & Cho, Sung & Tung, Phuong & Gim, Gwang. (2019). A Study on the Design of Efficient Private Blockchain. 10.1007/978–3–319–96806–3_8.

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

Corda has done a lot to create a robust and scalable distributed blockchain for enterprise (we’ve even prepared for quantum algorithms!). Still, we’ve found that there are some tips people tend to miss when they’re first getting started developing with Corda or thinking about going to production.

Static Code Analysis

We often advocate for computers to do the work and static code analyzers are my favourite implementation of this idea. You may be aware that the Corda development team uses a static code analyzer called detekt to monitor the codebase’s quality. If you look at the Corda developer recommended code style guide, you’ll find that many of these rules are already encoded for you in the Corda repo. It could be worth looking to see if some code consistency could save you down the road and make your codebase more comfortable to work with.

I’d also recommend Prettier for Java users, which has become incredibly popular and has a java plugin. With as many as two million downloads in a single day and forty million in the last month, Prettier has become a fantastic asset to the developer community. Google has put out an excellent set of style guides for Java as well.

New Developer Tooling

Earlier this year, we wrote about new developer tooling that we’ve put together, and it bears repeating.

You can now develop a CordApp or test an idea in minutes on the online IDE. We’ve completely redesigned the node explorer so you can see your network and interact with it seamlessly. We have a Corda VSCode extension, and for those of you who use truffle, we have a Corda integration as well.

Be aware of Accounts

When talking with developers, people often want to run an entire Corda node to represent each of their customers’ identities. This is how Corda was originally designed, so it makes sense that some developers think this way. However, it can quickly become expensive as Corda nodes need a reasonably good machine (Corda Node 4 CPU Core, 8 GB Memory).

One of Corda’s most powerful features is that you can represent multiple identities on a single Corda node. When using Corda accounts, you can scale much more responsibly with the number of customers you have.

If you find that you often have many identities you want to represent with your platform, but they don’t make transactions too often, this might be an excellent way to improve your configuration.

You can run Corda as a system service

Corda is compatible with a wide variety of familiar operating system service managers. You can control Corda with upstart, systemD, Windows service, and more.

This can make running a service in production as simple as sudo start corda. You can find out more specific details in the Corda documentation.

Reach out to us!

One of the most helpful things is knowing that you can get to one quickly if you need an answer. We have a public developer community that you can reach out to with questions and direct access to help at any time. We run regular office hours, and we strive to answer every question that comes our way. If you want help figuring out an error or support with a particular resource, I highly encourage you to get in touch.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— David Awad is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow David on Twitter here.

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