R3 Corda More key concepts

In the last blog, we checked about the R3 Corda advanced concept, now look at the more key concepts that expand on the other areas.

• Time windows - transactions can be validated as having fallen after, before, or within a particular time window.
• Oracles - transactions can include off-ledger facts retrieved using Oracles.
• Nodes - each node contains an instance of Corda, one or more CorDapps, and so on.
• Transaction tear-offs - transactions can be signed by parties who have access to only a limited view of the transaction parts.
• Trade-offs - that have been made in designing Corda and CorDapps.

Now take a look at the first concept Time windows.

Time-windows

• If a transaction includes a time window, it can only be committed during that window
• The notary is the timestamping authority. The notary only commits transactions that are inside the time window.
• Time windows can have a start and end time, or be open at either end.
• Transaction time windows specify a time window within which the transaction is asserted to have occurred.
• Time windows are expressed as windows because in a distributed system there is no true time, only a large number of desynchronized clocks!
• This is not only implied by the laws of physics but also by the nature of shared transactions especially if the signing of a transaction requires multiple human authorizations.

Time in a distributed system

The notary cluster acts as the timestamping authority. It verifies that a transaction occurred during a specific time window before notarizing it.

Nodes get time window signatures to prove a transaction happened before, during, or after a specific time. The notary timestamps and notarizes at the same time, so if the node doesn’t need to commit to the associated transaction, it can reveal the time window in the future.

A node may not send a transaction to the notary right away—they might need to circulate the transaction to other nodes involved in the transaction or request human sign-off. Even if the node sends it as soon as it’s generated, the node’s clock and the notary’s clock will never be perfectly in sync due to latency and physics. This means that the timestamp on a transaction is usually different from the time it was created.

• Issues of physics and network latency
• Between inserting the command and getting the notary to sign there may be many other steps, such as sending the transaction to other parties involved in the trade or requesting human sign-off.

Time windows

The time windows may be open-ended in order to communicate that the transaction occurred before a certain time or after a certain time, but how much before or after is unimportant.

Times in transactions are specified as time windows, not absolute times. Time windows can be open-ended, and specify only “before” or “after”, or they can be fully bounded.

When both a before and an after time are included the transaction occurred at some point within that time window.

Time windows let you represent transactions that follow different models, such as those that occur:

• At some point after the given time, such as after a maturity event.
• At any time before the given time, such as before a bankruptcy event.
• Around the given time, such as on a specific day.

If you need to convert a time window to an absolute time, such as for display purposes, you can use a utility method to calculate the midpoint.

Purpose of Time window

• The purpose of a time window is to communicate the transaction’s position on the timeline to the contract code for the enforcement of contractual logic.
• Time windows may be used for other purposes, such as regulatory reporting.
• If a specific point is required on the timeline, a mid-point time window can be agreed upon by all involved peers.

• For a time window to be meaningful, its implications must be binding on the peer specifying it.
• Peers to a transaction need to be compelled to commit a time windowed transaction before/at/after the specified time…
• Notary services, introduced later in this module can act as a timestamping authority.
• To enforce time windows, notaries must sign a transaction within some time tolerance
• e.g. a 30-second window.
• Alternatively, the notary can provide the time window and signature.

Time windows assert that a transaction happened within a specified time window.

Now look at the next important key concept Oracles.

Oracles

• Oracles let smart contracts execute based on real-world data.
• They query, validate, and authenticate information at the request of a node.
• You can minimize the amount of transaction data that an oracle sees by tearing off the portions that the oracle does not need to access.

What is an oracle?

Oracles are network services that supply external information to smart contracts. They serve as bridges between Corda networks and the outside world, broadening the uses for smart contracts to include agreements that require off-ledger information to execute. This could include anything from the current exchange rate for a transfer of funds, to the weather in Minnesota for an insurance policy.

Oracles are not the source of information they’re an entity that queries, verifies, and authenticates external data sources, then relays that information back to a smart contract.

For example, Alice sells Bob an insurance policy that covers a crop failure due to drought. They agree that Alice will pay Bob $50,000 if temperatures on his farm rise above 100 degrees Fahrenheit for seven consecutive days. They can write this into a smart contract that depends on a mutually trusted API reporting the weather from the National Weather Service. If Bob puts in a claim, the oracle queries the API to determine that the defined drought conditions have been met. If they have, the smart contract executes and Bob receives $50,000 from Alice.

How oracles work

If a node wants to assert a fact when proposing a transaction (for example, Bob claiming that his farm is experiencing drought), they can request a command that asserts that fact from the oracle. If the oracle determines the fact to be true (for example, by querying the National Weather Service’s API), they send the node the required command. The node can then include the fact (in the form of the command) in their transaction, and the oracle signs the transaction to assert the validity of the fact.

Some oracles monetize their services. In that case, you’ll need to pay the oracle before they sign the transaction.

Facts Oracles can provide

• What are today’s overnight indexed swap rates?
• What is the current risk-free rate? e.g. From Gitts, T-bills, etc.
• Determinations on the permissions and rights of counterparties.
• Time, date, and calendar questions such as holidays and opening times.
• What is the current value of this option contract?

Oracle implementations

Using commands

• The fact can be established independently or by querying an Oracle service that provides facts.
• The fact is incorporated into a command inside the transaction itself.
• The Oracle’s public key is added to the command’s signers list the Oracle becomes a co-signer to the transaction.
• Use for small or regular changing data suitable where there is commercial sensitivity due to licensing.

Using attachments

• The fact is established by sending a query to the Oracle.
• The fact is returned as a signed attachment that can be incorporated into a transaction.
• The attachment can be re-used in other transactions without involving the oracle again.
• Use for large data, particularly if it does not change regularly Not suitable for licensed facts.

Oracles and privacy

The oracle doesn’t need to see the whole contract–only the part it needs to validate. The node proposing the transaction can tear off unrelated parts of the contract before the oracle sees it. For example, in Alice and Bob’s contract, the oracle is only attesting to the temperature on Bob’s farm, so it doesn’t need to know how much the insurance policy is for. Bob could tear off that information.

Oracles are an authority that attests to off-ledger facts needed to verify transaction proposals.

Next, Let's discuss the following key concept Nodes.

Nodes

• Nodes represent individuals and businesses on a Corda network.
• A node runs within a Java Virtual Machine (JVM) and has a unique network identity.
• The node interfaces with the outside world through:

â—‹ The network, which lets it interact with other nodes.

○ Remote procedure Call (RPC), which lets the node’s owner interact with it.

• You can add extra functions to your node by installing CorDapps in the plugin registry.

CorDapps are distributed applications that let you accomplish different objectives with Corda.

Node architecture

A Corda node runs within a Java Virtual Machine (JVM) runtime environment with a unique network identity. JVM runtime environments provide a consistent platform on which you can run and deploy Java applications, such as Corda services and CorDapps. Here is a visualization of the node’s internal architecture:

The core elements of the architecture are:

• A persistence layer for storing data.
• A network interface for communication between nodes.
• An RPC interface for interacting with the node’s owner.
• The service hub, which lets the node’s flows call services in the node.
• A CorDapp interface and provider for extending the node by installing CorDapps.

So that’s probably the best way to visualize how the node looks from a developer’s perspective. So now we are going to look very briefly at what happens when a request is sent to the node. Let’s imagine here that there is a hypothetical CorDaap already installed on this node and it has an RPC interface and a webserver that’s serving a user interface as well as some data that is derived from the CorDaap.

Let’s say we want to make a request to start a transaction to maybe reach an agreement with another node, we would do that through the HTTP API, and through the API we would call the RPC server through the RPC client, and what we would do is we would start a flow. So, if we want to do anything in Corda we have to do it via a flow. A flow contains the business logic required to access the node's services, create a transaction, verify a transaction, etc. Typically, what we would do when we start our flow, is we had to build our transaction, verify, and sign it. We would do this via the first steps of the flow. We would need to receive the signature from our counterparty. So what we will do is we would send a message to our counterparty via the network, and they will sign let’s assume this is a happy path scenario where they would always sign then they would send their signature back. We would potentially perform more steps, we would check their signature for instance. Once we are happy with that we would then send the transaction to the notary service for signing so we can achieve finality and then we would receive back from the notary a signature. We would attach that signature to the transaction and then record it in the storage service. So, all transactions are recorded in the storage service which is a key-value store. Only the relevant output states of a transaction are stored in the vault.

You can think of the vault as the vault that maintains the subjective view of the ledger for this particular node and its users. Once the data is in the vault, then via the HTTP API we can make a request, we can extract the data from the vault, and display it in our user interface. You can think of this as a life cycle of making a request to start flow to reach a consensus about a shared fact and then store the shared fact on the ledger. So both parties to this flow would have an identical copy of the output states to the transaction in their vaults, assuming it’s relevant for both of them which it probably is. Then this state can then be extracted from the vault via a query and be displayed in a user interface. So that’s typically how a CorDapp would interact with the Corda node and users of the node.

The Permissioning Service

• Corda is designed for semi-private networks.
• Admission requires obtaining an identity signed by a root authority.
• Certificate signing requests are reviewed by an R3 team.
• R3 acts as the root CA for the “testnet”.

The Network Map Service

• It publishes the IP addresses through which every peer on the network can be reached, along with the identity certificates of those peers and the services they provide.
• The network map is distributed to all peers on the network.
• Any peer can opt to act as a network map service.

Persistence layer

The persistence layer has two parts:

• The vault, where the node stores any relevant current and historic states.
• The storage service, where it stores transactions, attachments, and flow checkpoints.

The node’s owner can query the node’s storage using the RPC interface.

Network interface

All communication with other nodes on the network is handled by the node itself, as part of running a flow. The node’s owner does not interact with other network nodes directly.

RPC interface

The node’s owner interacts with the node via remote procedure calls (RPC). The key RPC operations the node exposes are documented in API: RPC operations.

The service hub

Internally, the node has access to a rich set of services that are used during flow execution to coordinate ledger updates. The key services are:

• Information about other nodes on the network and the services they offer.
• Access to the contents of the vault and the storage service.
• Access to the node’s public-private key pairs.
• Generation of new public-private key pairs.
• Information about the node itself.
• The current time, as tracked by the node.

The CorDapp provider

Use the CorDapp provider to install new CorDapps which extend the behavior of the node.

Your node comes with several default CorDapps installed, which handle common tasks such as:

• Retrieving transactions and attachments from counterparties.
• Upgrading contracts.
• Broadcasting agreed on ledger updates for recording by counterparties.

Draining mode

You may want to decommission or shut down a node for various activities, such as planned maintenance and upgrades, or investigating performance or latency issues. To shut down a node cleanly, you must drain it so that no node processes (or flows) are active.

Checkpoints ensure durability against crashes and restarts, by freezing a flow and capturing its current status which is automatically saved to the database. When the node is restarted, it replays the flow from the last checkpoint.

Draining mode ensures that before shutting down:

• Commands requiring any new, RPC-initiated flows are rejected.
• Initial P2P session messages are not processed, meaning peers are not able to initiate new flows involving the node.
• All other activities proceed as usual, ensuring that the number of in-progress flows only goes down, not up.

Once the number of active flows reaches zero, it is safe to shut the node down. The draining mode property is durable, meaning that restarting the node does not reset it to its default value and that an RPC command is required.

The node can be safely shut down via a drain using the shell, Corda’s embedded command line.

Now check out the next key concept Transaction tear-offs

Transaction tear-offs

• Transaction tear-offs hide components of the transaction for privacy purposes.
• Use them to make sure oracles and non-validating notaries can only see transaction components relevant to them.

Use cases

You may want to limit some entities interacting with a transaction to specific parts of it to preserve privacy. For example:

• An oracle only needs to see the commands specific to it.
• A non-validating notary only needs to see a transaction’s input states.

You can achieve this using Merkle trees. These let the node proposing the transaction “tear off” any parts of the transaction that the oracle or notary doesn’t need to see before presenting it to them for signing. Merkel trees are a cryptographic scheme that provides proof of inclusion and data integrity. They guarantee that the parts of the transaction you tore off cannot later be changed without invalidating the oracle’s digital signature. Merkle trees are widely used in peer-to-peer networks, blockchain systems, and Git.

Merkle trees on Corda

Merkle trees split transactions into “leaves”. Each leaf contains either an input, an output, a command, or an attachment. The final nested tree structure also contains the other fields of the transaction, such as the time window, the notary, and the required signers. The only component type that requires two trees instead of one is the command, which is split into command data and required signers for visibility purposes.

Corda uses one nested Merkle tree per component type. A component sub-tree is generated for each component type (for example, inputs, outputs, or attachments). The roots of these sub-trees form the leaves of the top Merkle tree, and the root of the tree represents the transaction ID.

Corda also deterministically generates an independent nonce for each component. This is a unique number added to the hash. Then, it uses the nonces and their corresponding components to calculate the component hash, which is the actual Merkle tree leaf. Nonces protect against brute force attacks that otherwise would reveal the content of hashed values that can’t generate much randomness, such as a single-word text attachment.

After computing the leaves, each Merkle tree is built by hashing the concatenation of nodes’ hashes together. You can see this in the diagram, where H denotes the sha256 function, “+” - concatenation.

The transaction has three input states, two output states, two commands, one attachment, a notary, and a time window. If a tree is not a full binary tree, its leaves are padded to the nearest power of 2 with zero hash (since finding a pre-image of sha256(x) == 0 is a hard computational task). The hash of the root is the identifier of the transaction. This is used for signing and verification of data integrity. Any change in a transaction on a leaf level changes its identifier.

Hiding data

To hide data and provide proof that it formed a part of a transaction, you can construct partial Merkle trees, or Merkle branches. A Merkle branch is a set of hashes, that given the leaves’ data, is used to calculate the root’s hash. Then, you can compare that hash with the hash of a whole transaction. If they match, it means that the data obtained belongs to that particular transaction.

In this example, assume that only the first command should be visible to the oracle. You must provide guarantees that all the commands the oracle needs to sign are visible to the oracle entity, but no other data. The transaction would be represented in the Merkle tree structure like this:

The blue nodes and H(c2) are provided to the Oracle service, while the black ones are omitted. The oracle needs H(c2) so it can compute H(command data) without being to able to see the second command. At the same time, this ensures that CommandData1 is part of the transaction. All signers are visible as proof that no related command has been maliciously filtered out. Additionally, hashes of sub-trees (violet nodes) are provided in the current Corda protocol. These are required for special cases, such as if the oracle needs to know if a component group is empty or not.

You can use this data to calculate the root of the top tree and compare it with the original transaction identifier. Then, you have proof that the command and time window belong to the transaction.

To send the same transaction to a non-validating notary, hide all components apart from input states, time windows, and the notary information. This data is enough for the notary to know which input states to check for double-spending if the time window is valid, and if the transaction is being notarized by the correct notary.

Now next take a look at Trade-offs key concept

Trade-offs

• Permissioned networks are better suited for financial use cases
• Point-to-point communication allows information to be shared need-to-know
• A UTXO model allows for more transactions per second

Permissioned vs. permission less

Traditional blockchain networks are permissionless. The parties on the network are anonymous and can join and leave at will.

By contrast, Corda networks are permissioned. Each party on the network has a known identity that they use when communicating with counterparties, and network access is controlled by a doorman. This has several benefits:

• Anonymous parties are inappropriate for most scenarios involving regulated financial institutions
• Knowing the identity of your counterparties allows for off-ledger resolution of conflicts using existing legal systems
• Sybil attacks are averted without the use of expensive mechanisms such as proof-of-work

Point-to-point vs. global broadcasts

Traditional blockchain networks broadcast every message to every participant. The reason for this is two-fold:

• Counterparty identities are not known, so a message must be sent to every participant to ensure it reaches its intended recipient
• Making every participant aware of every transaction allows the network to prevent double-spends

The downside is that all participants see everyone else’s data. This is unacceptable for many use cases.

In Corda, each message is instead addressed to a specific counterparty and is not seen by any uninvolved third parties. The developer has full control over what messages are sent, to whom, and in what order. As a result, data is shared on a need-to-know basis only. To prevent double-spends in this system, we employ notaries as an alternative to proof-of-work.

Corda also uses several other techniques to maximize privacy on the network:

• Transaction tear-offs: Transactions are structured in a way that allows them to be digitally signed without disclosing the transaction’s contents. This is achieved using a data structure called a Merkle tree. You can read more about this technique in Defining Transaction Tear-offs.
• Key randomization: The parties to a transaction are identified only by their public keys, and fresh key pairs are generated for each transaction. As a result, an onlooker cannot identify which parties were involved in a given transaction.

UTXO vs. account model

Corda uses a UTXO (unspent transaction output) model. Each transaction consumes a set of existing states to produce a set of new states.

The alternative would be an account model. In an account model, stateful objects are stored on a ledger, and transactions take the form of requests to update the current state of these objects.

The main advantage of the UTXO model is that transactions with different inputs can be applied in parallel, vastly increasing the network’s potential transactions per second. In the account model, the number of transactions per second is limited by the fact that updates to a given object must be applied sequentially.

Code-is-law vs. existing legal systems

Financial institutions need the ability to resolve conflicts using the traditional legal system where required. Corda is designed to make this possible by:

• Having permissioned networks means that participants are aware of who they are dealing with in every single transaction
• All code contracts should include a LegalProseReference link to the legal document describing the contract’s intended behavior which can be relied upon to resolve conflicts

Build vs. re-use

Wherever possible, Corda re-uses existing technologies to make the platform more robust platform overall. For example, Corda re-uses:

• Standard JVM programming languages for the development of CorDapps
• Existing SQL databases
• Existing message queue implementations

Conclusion

In this discussion, we delved into the advanced concepts of R3 Corda, focusing on Time Windows, Oracles, Nodes, and Transaction Tear-offs. Time Windows ensures transactions occur within specific periods, leveraging notary clusters for timestamp validation despite network latency and desynchronized clocks. Oracles integrate off-ledger facts into smart contracts, enabling real-world data utilization while maintaining transaction privacy through selective data sharing. Nodes, representing network participants, operate within JVM environments, interacting via RPC interfaces and extending functionality through CorDapps. Transaction Tear-offs, using Merkle trees, enhance privacy by exposing only necessary transaction components to relevant parties, preserving data integrity and confidentiality. These concepts collectively strengthen Corda's capability to handle complex, real-world financial operations with a balance of security, privacy, and efficiency.

Reference:

https://r3.com/

https://corda.net/