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

Updated Transactions Concepts docs re/ divisible assets

Browse Source
This commit is contained in:
troymc 2016-11-26 12:18:18 +01:00
parent 34bbf4d31a
commit 3a410b33ed
1 changed files with 31 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
docs/root/source/transaction-concepts.md
View File

@ -4,31 +4,47 @@ In BigchainDB, _Transactions_ are used to register, issue, create or transfer
things (e.g. assets).
Transactions are the most basic kind of record stored by BigchainDB. There are
two kinds: creation transactions and transfer transactions.
two kinds: CREATE transactions and TRANSFER transactions.
A _creation transaction_ can be used to register, issue, create or otherwise
## CREATE Transactions
A CREATE transaction can be used to register, issue, create or otherwise
initiate the history of a single thing (or asset) in BigchainDB. For example,
one might register an identity or a creative work. The things are often called
"assets" but they might not be literal assets.
Currently, BigchainDB only supports indivisible assets. You can't split an
asset apart into multiple assets, nor can you combine several assets together
into one. [Issue #129](https://github.com/bigchaindb/bigchaindb/issues/129) is
an enhancement proposal to support divisible assets.
BigchainDB supports divisible assets as of BigchainDB Server v0.8.0.
That means you can create/register an asset with an initial quantity,
e.g. 700 thumbtacks. Divisible assets can be split apart or recombined
by transfer transactions (described more below).
A creation transaction also establishes the conditions that must be met to
transfer the asset. For example, there may be a condition that any transfer
A CREATE transaction also establishes the conditions that must be met to
transfer the asset(s). For example, there may be a condition that any transfer
must be signed (cryptographically) by the private key associated with a
given public key. More sophisticated conditions are possible.
BigchainDB's conditions are based on the crypto-conditions of the [Interledger
Protocol (ILP)](https://interledger.org/).
A _transfer transaction_ can transfer an asset by fulfilling the current
conditions on the asset. It can also specify new transfer conditions.
## TRANSFER Transactions
Today, every transaction contains one fulfillment-condition pair. The
fulfillment in a transfer transaction must fulfill a condition in a previous
transaction.
A TRANSFER transaction can transfer an asset
(or set of assets of the same type)
by fulfilling the current conditions on the asset(s).
It must also specify new transfer conditions.
Example: Someone might construct a TRANSFER transaction
that fulfills the transfer conditions on four
previously-untransferred assets of the same asset type
e.g. thumbtacks. The amounts might be 20, 10, 45 and 25, say,
for a total of 100 thumbtacks.
The TRANSFER transaction would also set up new transfer conditions.
For example, maybe a set of 60 thumbtacks can only be transferred
if Gertrude signs, and a separate set of 40 thumbtacks can only be
transferred if both Jack and Kelly sign.
Note how the sum of the incoming thumbtacks must equal the sum
of the outgoing thumbtacks (100).
## Transaction Validity
When a node is asked to check if a transaction is valid, it checks several
things. Some things it checks are:
@ -47,6 +63,8 @@ things. Some things it checks are:
also aims to fulfill?
* Is the asset ID in the transaction the same as the asset ID in all
transactions whose conditions are being fulfilled?
* Is the sum of the amounts in the fulfillments equal
to the sum of the amounts in the new conditions?
If you're curious about the details of transaction validation, the code is in
the `validate` method of the `Transaction` class, in `bigchaindb/models.py` (at