Mirroristas/bigchaindb
2
0
Fork 0
mirror of https://github.com/bigchaindb/bigchaindb.git synced 2024-10-13 13:34:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs update for flat transaction

Browse Source
This commit is contained in:
Scott Sadler 2016-11-24 17:20:01 +01:00
parent 8d4677f456
commit 21af588f7c
1 changed files with 20 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
docs/server/source/data-models/transaction-model.rst
View File

@ -22,38 +22,35 @@ A transaction has the following structure:
{
"id": "<hash of transaction, excluding signatures (see explanation)>",
"version": "<version number of the transaction model>",
"transaction": {
"fulfillments": ["<list of fulfillments>"],
"conditions": ["<list of conditions>"],
"operation": "<string>",
"asset": "<digital asset description (explained in the next section)>",
"metadata": {
"id": "<uuid>",
"data": "<any JSON document>"
}
"fulfillments": ["<list of fulfillments>"],
"conditions": ["<list of conditions>"],
"operation": "<string>",
"asset": "<digital asset description (explained in the next section)>",
"metadata": {
"id": "<uuid>",
"data": "<any JSON document>"
}
}
Here's some explanation of the contents of a :ref:`transaction <transaction>`:
- :ref:`id <transaction.id>`: The id of the transaction, and also the database primary key.
- :ref:`version <transaction.version>`: Version number of the transaction model, so that software can support different transaction models.
- :ref:`transaction <Transaction Body>`:
- **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`.
- 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`.
- **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.
- **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.
- **asset**: Definition of the digital :ref:`asset <Asset>`. See next section.
- **metadata**:
- :ref:`id <metadata.id>`: UUID version 4 (random) converted to a string of hex digits in standard form.
- :ref:`data <metadata.data>`: Can be any JSON document. It may be empty in the case of a transfer transaction.
- **metadata**:
- :ref:`id <metadata.id>`: UUID version 4 (random) converted to a string of hex digits in standard form.
- :ref:`data <metadata.data>`: Can be any JSON document. It may be empty in the case of a transfer transaction.
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.