mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
53 lines
2.8 KiB
ReStructuredText
53 lines
2.8 KiB
ReStructuredText
.. raw:: html
|
|
|
|
<style>
|
|
.rst-content a.internal[href*='/schema/'] {
|
|
border: solid 1px #e1e4e5;
|
|
font-family: monospace;
|
|
font-size: 12px;
|
|
color: blue;
|
|
padding: 2px 4px;
|
|
background-color: white;
|
|
}
|
|
</style>
|
|
|
|
=====================
|
|
The Transaction Model
|
|
=====================
|
|
|
|
A transaction has the following structure:
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"id": "<hash of transaction, excluding signatures (see explanation)>",
|
|
"version": "<version number of the transaction model>",
|
|
"fulfillments": ["<list of fulfillments>"],
|
|
"conditions": ["<list of conditions>"],
|
|
"operation": "<string>",
|
|
"asset": "<digital asset description (explained in the next section)>",
|
|
"metadata": "<any JSON document>"
|
|
}
|
|
|
|
Here's some explanation of the contents of a :ref:`transaction <transaction>`:
|
|
|
|
- id: The :ref:`id <transaction.id>` of the transaction, and also the database primary key.
|
|
- version: :ref:`Version <transaction.version>` number of the transaction model, so that software can support different transaction models.
|
|
- **fulfillments**: List of fulfillments. Each :ref:`fulfillment <Fulfillment>` contains a pointer to an unspent asset
|
|
and a *crypto fulfillment* that satisfies a spending condition set on the unspent asset. A *fulfillment*
|
|
is usually a signature proving the ownership of the asset.
|
|
See :doc:`./crypto-conditions`.
|
|
|
|
- **conditions**: List of conditions. Each :ref:`condition <Condition>` is a *crypto-condition* that needs to be fulfilled by a transfer transaction in order to transfer ownership to new owners.
|
|
See :doc:`./crypto-conditions`.
|
|
|
|
- **operation**: String representation of the :ref:`operation <transaction.operation>` being performed (currently either "CREATE", "TRANSFER" or "GENESIS"). It determines how the transaction should be validated.
|
|
|
|
- **asset**: Definition of the digital :ref:`asset <Asset>`. See next section.
|
|
|
|
- **metadata**: User-provided transaction :ref:`metadata <metadata>`: Can be any JSON document, or `NULL`.
|
|
|
|
Later, when we get to the models for the block and the vote, we'll see that both include a signature (from the node which created it). You may wonder why transactions don't have signatures... The answer is that they do! They're just hidden inside the ``fulfillment`` string of each fulfillment. A creation transaction is signed by whoever created it. A transfer transaction is signed by whoever currently controls or owns it.
|
|
|
|
What gets signed? For each fulfillment in the transaction, the "fullfillment message" that gets signed includes the ``operation``, ``data``, ``version``, ``id``, corresponding ``condition``, and the fulfillment itself, except with its fulfillment string set to ``null``. The computed signature goes into creating the ``fulfillment`` string of the fulfillment.
|