Core types in the Corda API
Corda provides several core classes as part of its API.
Glossary
Hash
A mathematical function that takes a variable-length input string and converts it into a fixed-length binary sequence.
Public key cryprography
A system that uses a pair of keys: a public key and private key. Anyone can encrypt a message using the receiver’s public key, but the message can only be decrypted with the receiver’s private key.
Crytographic primitive
A low-level algorithm used to build cryptographic protocols for a security system. They are building blocks designed to do one specific task reliably.
Tree
Trees organize values (in the form of nodes) into nonlinear, hierarchical data structures. The tree originates from a single root node, then branches into levels of parent and child nodes. The last node on a branch is called the leaf.
SecureHash
Use the SecureHash
class to uniquely identify objects, such as transactions and attachments, by their hash.
Implement the NamedByHash
interface for any object that needs to be identified by its hash:
SecureHash
is a sealed class that only defines a single subclass, SecureHash.SHA256
. You can use utility methods
to create and parse SecureHash.SHA256
objects.
CompositeKey
Corda supports complex signing scenarios for the authorization of a state object transition. For example, if either Alice and Bob or Charlie need to sign a transaction.
You could facilitate this policy with a CompositeKey
. A CompositeKey
composes cryptographic public keys into a
tree. The tree stores the public key primitives in its leaves and
the composition logic in its intermediary nodes. Every intermediary node specifies a threshold of how many child
signatures it requires.
An illustration of an “either Alice and Bob, or Charlie” composite key:
To allow further flexibility, each child node can have an associated custom weight (the default is 1). The threshold then specifies the minimum total weight of all children required. Our previous example can also be expressed as:
Signature verification is performed in two stages:
- Given a list of signatures, each signature is verified against the expected content.
- The public keys corresponding to the signatures are matched against the leaves of the relevant composite key tree. The total combined weight of all children is calculated for every intermediary node. If all thresholds are satisfied, the composite key requirement is met.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.