| Interface | Description |
|---|---|
| TransactionWithSignatures |
An interface for transactions containing signatures, with logic for signature verification.
|
| Class | Description |
|---|---|
| BaseTransaction |
An abstract class defining fields shared by all transaction types in the system.
|
| ComponentGroup |
A ComponentGroup is used to store the full list of transaction components of the same type in serialised form.
Practically, a group per component type of a transaction is required; thus, there will be a group for input states,
a group for all attachments (if there are any) etc.
|
| ContractUpgradeFilteredTransaction |
A filtered version of the
class ContractUpgradeWireTransaction. In comparison with a regular class FilteredTransaction, there
is no flexibility on what parts of the transaction to reveal – the inputs, notary and network parameters hash fields are always visible and the
rest of the transaction is always hidden. Its only purpose is to hide transaction data when using a non-validating notary. |
| ContractUpgradeLedgerTransaction |
A contract upgrade transaction with fully resolved inputs and signatures. Contract upgrade transactions are separate
to regular transactions because their validation logic is specialised; the original contract by definition cannot be
aware of the upgraded contract (it was written after the original contract was developed), so its validation logic
cannot succeed. Instead alternative verification logic is used which verifies that the outputs correspond to the
inputs after upgrading.
|
| ContractUpgradeWireTransaction |
A special transaction for upgrading the contract of a state.
|
| CoreTransaction |
A transaction with the minimal amount of information required to compute the unique transaction id, and
resolve a
class FullTransaction. This type of transaction, wrapped in class SignedTransaction, gets transferred across the
wire and recorded to storage. |
| FilteredComponentGroup |
A FilteredComponentGroup is used to store the filtered list of transaction components of the same type in serialised form.
This is similar to
class ComponentGroup, but it also includes the corresponding nonce per component. |
| FilteredTransaction |
Class representing merkleized filtered transaction.
|
| FullTransaction |
A transaction with fully resolved components, such as input states.
|
| LedgerTransaction |
A LedgerTransaction is derived from a
class WireTransaction. It is the result of doing the following operations: |
| NetworkParametersHash |
Wrapper over
class SecureHash to be used when filtering network parameters hash. |
| NotaryChangeLedgerTransaction |
A notary change transaction with fully resolved inputs and signatures. In contrast with a regular transaction,
signatures are checked against the signers specified by input states' participants fields, so full resolution is
needed for signature verification.
|
| NotaryChangeWireTransaction |
A special transaction for changing the notary of a state. It only needs specifying the state(s) as input(s),
old and new notaries. Output states can be computed by applying the notary modification to corresponding inputs
on the fly.
|
| ReferenceStateRef |
Wrapper over
class StateRef to be used when filtering reference states. |
| SignedTransaction |
SignedTransaction wraps a serialized WireTransaction. It contains one or more signatures, each one for
a public key (including composite keys) that is mentioned inside a transaction command. SignedTransaction is the top level transaction type
and the type most frequently passed around the network and stored. The identity of a transaction is the hash of Merkle root
of a WireTransaction, therefore if you are storing data keyed by WT hash be aware that multiple different STs may
map to the same key (and they could be different in important ways, like validity!). The signatures on a
SignedTransaction might be invalid or missing: the type does not imply validity.
A transaction ID should be the hash of the
class WireTransaction Merkle tree root. Thus adding or removing a signature does not change it. |
| TransactionBuilder |
A TransactionBuilder is a transaction class that's mutable (unlike the others which are all immutable). It is
intended to be passed around contracts that may edit it by adding new states/commands. Then once the states
and commands are right, this class can be used as a holding bucket to gather signatures from multiple parties.
|
| TraversableTransaction |
Implemented by
class WireTransaction and class FilteredTransaction. A TraversableTransaction allows you to iterate
over the flattened components of the underlying transaction structure, taking into account that some
may be missing in the case of this representing a "torn" transaction. Please see the user guide section
"Transaction tear-offs" to learn more about this feature. |
| WireTransaction |
A transaction ready for serialisation, without any signatures attached. A WireTransaction is usually wrapped
by a
class SignedTransaction that carries the signatures over this payload.
The identity of the transaction is the Merkle tree root of its components (see class MerkleTree). |
| Exception | Description |
|---|---|
| ComponentVisibilityException |
Thrown when checking for visibility of all-components in a group in
FilteredTransaction.checkAllComponentsVisible. |
| FilteredTransactionVerificationException |
Thrown when
FilteredTransaction.verify fails. |
| MissingContractAttachments |
A contract attachment was missing when trying to automatically attach all known contract attachments
|