Transactions consist of the following components:
- Input references These are (hash, output index) pairs that point to the states a transaction is consuming.
- Output states Each state specifies the notary for the new state, the contract(s) that define its allowed transition functions and finally the data itself.
- Attachments Transactions specify an ordered list of zip file hashes. Each zip file may contain code, data, certificates or supporting docu- mentation for the transaction. Contract code has access to the contents of the attachments when checking the transaction for validity.
- Commands There may be multiple allowed output states from any given in- put state. For instance an asset can be moved to a new owner on the ledger, or issued, or exited from the ledger if the asset has been redeemed by the owner and no longer needs to be tracked. A command is essentially a parameter to the contract that specifies more information than is obtainable from exam-ination of the states by themselves (e.g. data from an oracle service). Each command has an associated list of public keys. Like states, commands are object graphs.
- Signatures The set of equired signatures is equal to the union of the com- mands’ public keys.
- Type Transactions can either be normal or notary-changing. The validation rules for each are different.
- Timestamp When present, a timestamp defines a time range in which the transaction is considered to have ccurrred. This is discussed in more detail below.
- Summaries Textual summaries of what the transaction does, checked by the involved smart contracts. This field is useful for secure signing devices
If you want to change selection, open document below and click on "Move attachment"
pdf
owner:
ionutt93 - (no access) - corda-technical-whitepaper.pdf, p13
Summary
| status | not read | | reprioritisations | |
|---|
| last reprioritisation on | | | suggested re-reading day | |
|---|
| started reading on | | | finished reading on | |
|---|
Details