mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
Revised several pages to point to replacement in the IPDB Transaction Spec
This commit is contained in:
Troy McConaghy
parent
1de7e55ac3
commit
b52f094efa
@ -1,80 +0,0 @@
|
||||
# Cryptography
|
||||
|
||||
The section documents the cryptographic algorithms and Python implementations
|
||||
that we use.
|
||||
|
||||
Before hashing or computing the signature of a JSON document, we serialize it
|
||||
as described in [the section on JSON serialization](json-serialization.html).
|
||||
|
||||
## Hashes
|
||||
|
||||
BigchainDB computes transaction and block hashes using an implementation of the
|
||||
[SHA3-256](https://pypi.python.org/pypi/pysha3)
|
||||
algorithm provided by the
|
||||
[**pysha3** package](https://bitbucket.org/tiran/pykeccak),
|
||||
which is a wrapper around the optimized reference implementation
|
||||
from [http://keccak.noekeon.org](http://keccak.noekeon.org).
|
||||
|
||||
**Important**: Since selecting the Keccak hashing algorithm for SHA-3 in 2012, NIST released a new version of the hash using the same algorithm but slightly different parameters. As of version 0.9, BigchainDB is using the latest version, supported by pysha3 1.0b1. See below for an example output of the hash function.
|
||||
|
||||
Here's the relevant code from `bigchaindb/bigchaindb/common/crypto.py:
|
||||
|
||||
```python
|
||||
import sha3
|
||||
|
||||
def hash_data(data):
|
||||
"""Hash the provided data using SHA3-256"""
|
||||
return sha3.sha3_256(data.encode()).hexdigest()
|
||||
```
|
||||
|
||||
The incoming `data` is understood to be a Python 3 string,
|
||||
which may contain Unicode characters such as `'ü'` or `'字'`.
|
||||
The Python 3 `encode()` method converts `data` to a bytes object.
|
||||
`sha3.sha3_256(data.encode())` is a _sha3.SHA3 object;
|
||||
the `hexdigest()` method converts it to a hexadecimal string.
|
||||
For example:
|
||||
|
||||
```python
|
||||
>>> import sha3
|
||||
>>> data = '字'
|
||||
>>> sha3.sha3_256(data.encode()).hexdigest()
|
||||
'2b38731ba4ef72d4034bef49e87c381d1fbe75435163b391dd33249331f91fe7'
|
||||
>>> data = 'hello world'
|
||||
>>> sha3.sha3_256(data.encode()).hexdigest()
|
||||
'644bcc7e564373040999aac89e7622f3ca71fba1d972fd94a31c3bfbf24e3938'
|
||||
```
|
||||
|
||||
Note: Hashlocks (which are one kind of crypto-condition)
|
||||
may use a different hash function.
|
||||
|
||||
|
||||
## Signature Algorithm and Keys
|
||||
|
||||
BigchainDB uses the [Ed25519](https://ed25519.cr.yp.to/) public-key signature
|
||||
system for generating its public/private key pairs. Ed25519 is an instance of
|
||||
the [Edwards-curve Digital Signature Algorithm
|
||||
(EdDSA)](https://en.wikipedia.org/wiki/EdDSA). As of December 2016, EdDSA was an
|
||||
["Internet-Draft" with the
|
||||
IETF](https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08) but was [already
|
||||
widely used](https://ianix.com/pub/ed25519-deployment.html).
|
||||
|
||||
BigchainDB uses the the
|
||||
[**cryptoconditions** package](https://github.com/bigchaindb/cryptoconditions)
|
||||
to do signature and keypair-related calculations.
|
||||
That package, in turn, uses the [**PyNaCl** package](https://pypi.python.org/pypi/PyNaCl),
|
||||
a Python binding to the Networking and Cryptography (NaCl) library.
|
||||
|
||||
All keys are represented with
|
||||
[a Base58 encoding](https://en.wikipedia.org/wiki/Base58).
|
||||
The cryptoconditions package uses the
|
||||
[**base58** package](https://pypi.python.org/pypi/base58)
|
||||
to calculate a Base58 encoding.
|
||||
(There's no standard for Base58 encoding.)
|
||||
Here's an example public/private key pair:
|
||||
|
||||
```js
|
||||
"keypair": {
|
||||
"public": "9WYFf8T65bv4S8jKU8wongKPD4AmMZAwvk1absFDbYLM",
|
||||
"private": "3x7MQpPq8AEUGEuzAxSVHjU1FhLWVQJKFNNkvHhJPGCX"
|
||||
}
|
||||
```
|
||||
9
docs/server/source/appendices/cryptography.rst
Normal file
9
docs/server/source/appendices/cryptography.rst
Normal file
@ -0,0 +1,9 @@
|
||||
Cryptography
|
||||
============
|
||||
|
||||
See `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_,
|
||||
especially the pages about:
|
||||
|
||||
- Cryptographic Hashes
|
||||
- Cryptographic Keys & Signatures
|
||||
@ -1,56 +0,0 @@
|
||||
# JSON Serialization
|
||||
|
||||
We needed to clearly define how to serialize a JSON object to calculate the hash.
|
||||
|
||||
The serialization should produce the same byte output independently of the architecture running the software. If there are differences in the serialization, hash validations will fail although the transaction is correct.
|
||||
|
||||
For example, consider the following two methods of serializing `{'a': 1}`:
|
||||
```python
|
||||
# Use a serializer provided by RethinkDB
|
||||
a = r.expr({'a': 1}).to_json().run(b.connection)
|
||||
u'{"a":1}'
|
||||
|
||||
# Use the serializer in Python's json module
|
||||
b = json.dumps({'a': 1})
|
||||
'{"a": 1}'
|
||||
|
||||
a == b
|
||||
False
|
||||
```
|
||||
|
||||
The results are not the same. We want a serialization and deserialization so that the following is always true:
|
||||
```python
|
||||
deserialize(serialize(data)) == data
|
||||
True
|
||||
```
|
||||
|
||||
Since BigchainDB performs a lot of serialization we decided to use [python-rapidjson](https://github.com/python-rapidjson/python-rapidjson)
|
||||
which is a python wrapper for [rapidjson](https://github.com/miloyip/rapidjson) a fast and fully RFC complient JSON parser.
|
||||
|
||||
```python
|
||||
import rapidjson
|
||||
|
||||
rapidjson.dumps(data, skipkeys=False,
|
||||
ensure_ascii=False,
|
||||
sort_keys=True)
|
||||
```
|
||||
|
||||
- `skipkeys`: With skipkeys `False` if the provided keys are not a string the serialization will fail. This way we enforce all keys to be strings
|
||||
- `ensure_ascii`: The RFC recommends `utf-8` for maximum interoperability. By setting `ensure_ascii` to `False` we allow unicode characters and python-rapidjson forces the encoding to `utf-8`.
|
||||
- `sort_keys`: Sorted output by keys.
|
||||
|
||||
Every time we need to perform some operation on the data like calculating the hash or signing/verifying the transaction, we need to use the previous criteria to serialize the data and then use the `byte` representation of the serialized data (if we treat the data as bytes we eliminate possible encoding errors e.g. unicode characters). For example:
|
||||
```python
|
||||
# calculate the hash of a transaction
|
||||
# the transaction is a dictionary
|
||||
tx_serialized = bytes(serialize(tx))
|
||||
tx_hash = hashlib.sha3_256(tx_serialized).hexdigest()
|
||||
|
||||
# signing a transaction
|
||||
tx_serialized = bytes(serialize(tx))
|
||||
signature = sk.sign(tx_serialized)
|
||||
|
||||
# verify signature
|
||||
tx_serialized = bytes(serialize(tx))
|
||||
pk.verify(signature, tx_serialized)
|
||||
```
|
||||
6
docs/server/source/appendices/json-serialization.rst
Normal file
6
docs/server/source/appendices/json-serialization.rst
Normal file
@ -0,0 +1,6 @@
|
||||
JSON Serialization
|
||||
==================
|
||||
|
||||
See the page about JSON Serialization & Deserialization
|
||||
in `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_.
|
||||
@ -1,31 +0,0 @@
|
||||
# The Asset Model
|
||||
|
||||
To avoid redundant data in transactions, the asset model is different for `CREATE` and `TRANSFER` transactions.
|
||||
|
||||
## In CREATE Transactions
|
||||
|
||||
In a `CREATE` transaction, the `"asset"` must contain exactly one key-value pair. The key must be `"data"` and the value can be any valid JSON document, or `null`. For example:
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"desc": "Gold-inlay bookmark owned by Xavier Bellomat Dickens III",
|
||||
"xbd_collection_id": 1857
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When using MongoDB for storage, certain restriction apply to all (including nested) keys of the `"data"` JSON document:
|
||||
|
||||
* Keys (i.e. key names, not values) must **not** begin with the `$` character.
|
||||
* Keys must not contain `.` or the null character (Unicode code point 0000).
|
||||
* The key `"language"` (at any level in the hierarchy) is a special key and used for specifying text search language. Its value must be one of the allowed values; see the valid [Text Search Languages](https://docs.mongodb.com/manual/reference/text-search-languages/) in the MongoDB Docs. In BigchainDB, only the languages supported by _MongoDB community edition_ are allowed.
|
||||
|
||||
|
||||
## In TRANSFER Transactions
|
||||
|
||||
In a `TRANSFER` transaction, the `"asset"` must contain exactly one key-value pair. They key must be `"id"` and the value must contain a transaction ID (i.e. a SHA3-256 hash: the ID of the `CREATE` transaction which created the asset, which also serves as the asset ID). For example:
|
||||
```json
|
||||
{
|
||||
"id": "38100137cea87fb9bd751e2372abb2c73e7d5bcf39d940a5516a324d9c7fb88d"
|
||||
}
|
||||
```
|
||||
5
docs/server/source/data-models/asset-model.rst
Normal file
5
docs/server/source/data-models/asset-model.rst
Normal file
@ -0,0 +1,5 @@
|
||||
The Asset Model
|
||||
===============
|
||||
|
||||
See `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_.
|
||||
@ -1,102 +1,5 @@
|
||||
Conditions
|
||||
==========
|
||||
|
||||
At a high level, a condition is like a lock on an output.
|
||||
If can you satisfy the condition, you can unlock the output and transfer/spend it.
|
||||
BigchainDB Server supports a subset of the ILP Crypto-Conditions
|
||||
(`version 02 of Crypto-Conditions <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02>`_).
|
||||
|
||||
A condition object can be quite elaborate,
|
||||
with many nested levels,
|
||||
but the simplest case is actually quite simple.
|
||||
Here's an example signature condition:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"details": {
|
||||
"type": "ed25519-sha-256",
|
||||
"public_key": "HFp773FH21sPFrn4y8wX3Ddrkzhqy4La4cQLfePT2vz7"
|
||||
},
|
||||
"uri": "ni:///sha-256;at0MY6Ye8yvidsgL9FrnKmsVzX0XrNNXFmuAPF4bQeU?fpt=ed25519-sha-256&cost=131072"
|
||||
}
|
||||
|
||||
If someone wants to spend the output where this condition is found, then they must create a TRANSFER transaction with an input that fulfills it (this condition). Because it's a ed25519-sha-256 signature condition, that means they must sign the TRANSFER transaction with the private key corresponding to the public key HFp773…
|
||||
|
||||
|
||||
Supported Crypto-Conditions
|
||||
---------------------------
|
||||
|
||||
BigchainDB Server v1.0 supports two of the Crypto-Conditions:
|
||||
|
||||
1. ED25519-SHA-256 signature conditions
|
||||
2. THRESHOLD-SHA-256 threshold conditions
|
||||
|
||||
We saw an example signature condition above.
|
||||
For more information about how BigchainDB handles keys and signatures,
|
||||
see the page titled :ref:`Signature Algorithm and Keys`.
|
||||
|
||||
A more complex condition can be composed by using n signature conditions as inputs to an m-of-n threshold condition: a logic gate which outputs TRUE if and only if m or more inputs are TRUE. If there are n inputs to a threshold condition:
|
||||
|
||||
* 1-of-n is the same as a logical OR of all the inputs
|
||||
* n-of-n is the same as a logical AND of all the inputs
|
||||
|
||||
For example, you could create a condition requiring m (of n) signatures.
|
||||
Here's an example 2-of-2 condition:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"details": {
|
||||
"type": "threshold-sha-256",
|
||||
"threshold": 2,
|
||||
"subconditions": [
|
||||
{
|
||||
"public_key": "5ycPMinRx7D7e6wYXLNLa3TCtQrMQfjkap4ih7JVJy3h",
|
||||
"type": "ed25519-sha-256"
|
||||
},
|
||||
{
|
||||
"public_key": "9RSas2uCxR5sx1rJoUgcd2PB3tBK7KXuCHbUMbnH3X1M",
|
||||
"type": "ed25519-sha-256"
|
||||
}
|
||||
]
|
||||
},
|
||||
"uri": "ni:///sha-256;zr5oThl2kk6613WKGFDg-JGu00Fv88nXcDcp6Cyr0Vw?fpt=threshold-sha-256&cost=264192&subtypes=ed25519-sha-256"
|
||||
}
|
||||
|
||||
The (single) output of a threshold condition can be used as one of the inputs to another threshold condition. That means you can combine threshold conditions to build complex expressions such as ``(x OR y) AND (2 of {a, b, c})``.
|
||||
|
||||
.. image:: /_static/Conditions_Circuit_Diagram.png
|
||||
|
||||
When you create a condition, you can calculate its
|
||||
`cost <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-7.2.2>`_,
|
||||
an estimate of the resources that would be required to validate the fulfillment.
|
||||
For example, the cost of one signature condition is 131072.
|
||||
A BigchainDB federation can put an upper limit on the complexity of each
|
||||
condition, either directly by setting a maximum allowed cost,
|
||||
or
|
||||
`indirectly <https://github.com/bigchaindb/bigchaindb/issues/356#issuecomment-288085251>`_
|
||||
by :ref:`setting a maximum allowed transaction size <Enforcing a Max Transaction Size>`
|
||||
which would limit
|
||||
the overall complexity accross all inputs and outputs of a transaction.
|
||||
Note: At the time of writing, there was no configuration setting
|
||||
to set a maximum allowed cost,
|
||||
so the only real option was to
|
||||
:ref:`set a maximum allowed transaction size <Enforcing a Max Transaction Size>`.
|
||||
|
||||
|
||||
Constructing a Condition
|
||||
------------------------
|
||||
|
||||
The above examples should make it clear how to construct
|
||||
a condition object, but they didn't say how to generate the ``uri``.
|
||||
If you want to generate a correct condition URI,
|
||||
then you should consult the Crypto-Conditions spec
|
||||
or use one of the existing Crypto-Conditions packages/libraries
|
||||
(which are used by the BigchainDB Drivers).
|
||||
|
||||
* `Crypto-Conditions Spec (Version 02) <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02>`_
|
||||
* BigchainDB :ref:`Drivers & Tools`
|
||||
|
||||
The `Handcrafting Transactions <https://docs.bigchaindb.com/projects/py-driver/en/latest/handcraft.html>`_
|
||||
page may also be of interest.
|
||||
See `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_.
|
||||
|
||||
@ -1,14 +1,6 @@
|
||||
Data Models
|
||||
===========
|
||||
|
||||
BigchainDB stores all data in the underlying database as JSON documents (conceptually, at least). There are three main kinds:
|
||||
|
||||
1. Transactions, which contain assets, inputs, outputs, and other things
|
||||
2. Blocks
|
||||
3. Votes
|
||||
|
||||
This section unpacks each one in turn.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
|
||||
@ -1,71 +1,5 @@
|
||||
Inputs and Outputs
|
||||
==================
|
||||
|
||||
There's a high-level overview of inputs and outputs
|
||||
in `the root docs page about transaction concepts <https://docs.bigchaindb.com/en/latest/transaction-concepts.html>`_.
|
||||
|
||||
BigchainDB is modelled around *assets*, and *inputs* and *outputs* are the mechanism by which control of an asset (or shares of an asset) is transferred.
|
||||
Amounts of an asset are encoded in the outputs of a transaction, and each output may be spent separately. To spend an output, the output's ``condition`` must be met by an ``input`` that provides a corresponding ``fulfillment``. Each output may be spent at most once, by a single input. Note that any asset associated with an output holding an amount greater than one is considered a divisible asset that may be split up in future transactions.
|
||||
|
||||
|
||||
Inputs
|
||||
------
|
||||
|
||||
An input has the following structure:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"owners_before": ["<The public_keys list in the output being spent>"],
|
||||
"fulfillment": "<String that fulfills the condition in the output being spent>",
|
||||
"fulfills": {
|
||||
"output_index": "<Index of the output being spent (an integer)>",
|
||||
"transaction_id": "<ID of the transaction containing the output being spent>"
|
||||
}
|
||||
}
|
||||
|
||||
You can think of the ``fulfills`` object as a pointer to an output on another transaction: the output that this input is spending/transferring.
|
||||
A CREATE transaction should have exactly one input. That input can contain one or more ``owners_before``, a ``fulfillment`` (with one signature from each of the owners-before), and the value of ``fulfills`` should be ``null``). A TRANSFER transaction should have at least one input, and the value of ``fulfills`` should not be ``null``.
|
||||
|
||||
The ``fulfillment`` string fulfills the condition in the output that is being spent (transferred).
|
||||
To calculate it:
|
||||
|
||||
1. Determine the fulfillment as per the `Crypto-Conditions spec (version 02) <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02>`_.
|
||||
2. Encode the fulfillment using the `ASN.1 Distinguished Encoding Rules (DER) <http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12483&lang=en>`_.
|
||||
3. Encode the resulting bytes using "base64url" (*not* typical base64) as per `RFC 4648, Section 5 <https://tools.ietf.org/html/rfc4648#section-5>`_.
|
||||
|
||||
To do those calculations, you can use one of the
|
||||
:ref:`BigchainDB drivers or transaction-builders <Drivers & Tools>`,
|
||||
or use a low-level crypto-conditions library as illustrated
|
||||
in the page about `Handcrafting Transactions <https://docs.bigchaindb.com/projects/py-driver/en/latest/handcraft.html>`_.
|
||||
A ``fulfillment`` string should look something like:
|
||||
|
||||
.. code::
|
||||
|
||||
"pGSAIDgbT-nnN57wgI4Cx17gFHv3UB_pIeAzwZCk10rAjs9bgUDxyNnXMl-5PFgSIOrN7br2Tz59MiWe2XY0zlC7LcN52PKhpmdRtcr7GR1PXuTfQ9dE3vGhv7LHn6QqDD6qYHYM"
|
||||
|
||||
|
||||
Outputs
|
||||
-------
|
||||
|
||||
An output has the following structure:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"condition": {"<Condition object>"},
|
||||
"public_keys": ["<List of all public keys associated with the condition object>"],
|
||||
"amount": "<Number of shares of the asset (an integer in a string)>"
|
||||
}
|
||||
|
||||
The :ref:`page about conditions <Conditions>` explains the contents of a ``condition``.
|
||||
|
||||
The list of ``public_keys`` is always the "owners" of the asset at the time the transaction completed, but before the next transaction started.
|
||||
|
||||
Note that ``amount`` must be a string (e.g. ``"7"``).
|
||||
In a TRANSFER transaction, the sum of the output amounts must be the same as the sum of the outputs that it transfers (i.e. the sum of the input amounts). For example, if a TRANSFER transaction has two outputs, one with ``"amount": "2"`` and one with ``"amount": "3"``, then the sum of the outputs is 5 and so the sum of the outputs-being-transferred must also be 5.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
The BigchainDB documentation and code talks about control of an asset in terms of "owners" and "ownership." The language is chosen to represent the most common use cases, but in some more complex scenarios, it may not be accurate to say that the output is owned by the controllers of those public keys—it would only be correct to say that those public keys are associated with the ability to fulfill the conditions on the output. Also, depending on the use case, the entity controlling an output via a private key may not be the legal owner of the asset in the corresponding legal domain. However, since we aim to use language that is simple to understand and covers the majority of use cases, we talk in terms of "owners" of an output that have the ability to "spend" that output.
|
||||
See `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_.
|
||||
|
||||
@ -1,68 +1,8 @@
|
||||
The Transaction Model
|
||||
=====================
|
||||
|
||||
A transaction has the following structure:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"id": "<ID of the transaction>",
|
||||
"version": "<Transaction schema version number>",
|
||||
"inputs": ["<List of inputs>"],
|
||||
"outputs": ["<List of outputs>"],
|
||||
"operation": "<String>",
|
||||
"asset": {"<Asset model; see below>"},
|
||||
"metadata": {"<Arbitrary transaction metadata>"}
|
||||
}
|
||||
|
||||
Here's some explanation of the contents:
|
||||
|
||||
- **id**: The ID of the transaction and also the hash of the transaction (loosely speaking). See below for an explanation of how it's computed. It's also the database primary key.
|
||||
|
||||
- **version**: The version-number of the transaction schema. As of BigchainDB Server 1.0.0, the only allowed value is ``"1.0"``.
|
||||
|
||||
- **inputs**: List of inputs.
|
||||
Each input spends/transfers a previous output by satisfying/fulfilling
|
||||
the crypto-conditions on that output.
|
||||
A CREATE transaction should have exactly one input.
|
||||
A TRANSFER transaction should have at least one input (i.e. ≥1).
|
||||
|
||||
- **outputs**: List of outputs.
|
||||
Each output indicates the crypto-conditions which must be satisfied
|
||||
by anyone wishing to spend/transfer that output.
|
||||
It also indicates the number of shares of the asset tied to that output.
|
||||
|
||||
- **operation**: A string indicating what kind of transaction this is,
|
||||
and how it should be validated.
|
||||
It can only be ``"CREATE"``, ``"TRANSFER"`` or ``"GENESIS"``
|
||||
(but there should only be one transaction whose operation is ``"GENESIS"``:
|
||||
the one in the GENESIS block).
|
||||
|
||||
- **asset**: A JSON document for the asset associated with the transaction.
|
||||
(A transaction can only be associated with one asset.)
|
||||
See :ref:`the page about the asset model <The Asset Model>`.
|
||||
|
||||
- **metadata**: User-provided transaction metadata.
|
||||
It can be any valid JSON document, or ``null``.
|
||||
**NOTE:** When using MongoDB for storage, certain restriction apply
|
||||
to all (including nested) keys of the JSON document:
|
||||
1) keys (i.e. key names, not values) must **not** begin with the ``$`` character, and
|
||||
2) keys must not contain ``.`` or the null character (Unicode code point 0000).
|
||||
3) The key `"language"` (at any level in the hierarchy) is a special key and used for specifying text search language. Its value must be one of the allowed values; see the valid `Text Search Languages <https://docs.mongodb.com/manual/reference/text-search-languages/>`_ in the MongoDB Docs. In BigchainDB, only the languages supported by *MongoDB community edition* are allowed.
|
||||
|
||||
**How the transaction ID is computed.**
|
||||
1) Build a Python dictionary containing ``version``, ``inputs``, ``outputs``, ``operation``, ``asset``, ``metadata`` and their values,
|
||||
2) In each of the inputs, replace the value of each ``fulfillment`` with ``null``,
|
||||
3) :ref:`Serialize <JSON Serialization>` that dictionary,
|
||||
4) The transaction ID is just :ref:`the SHA3-256 hash <Hashes>` of the serialized dictionary.
|
||||
|
||||
**About signing the 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 input. What gets signed (as of version 1.0.0) is everything inside the transaction, including the ``id``, but the value of each ``fulfillment`` is replaced with ``null``.
|
||||
|
||||
There are example BigchainDB transactions in
|
||||
:ref:`the HTTP API documentation <The HTTP Client-Server API>`
|
||||
and
|
||||
`the Python Driver documentation <https://docs.bigchaindb.com/projects/py-driver/en/latest/usage.html>`_.
|
||||
See `the IPDB Transaction Spec
|
||||
<https://the-ipdb-transaction-spec.readthedocs.io/en/latest/>`_.
|
||||
|
||||
|
||||
The Transaction Schema
|
||||
@ -71,10 +11,10 @@ The Transaction Schema
|
||||
BigchainDB checks all transactions (JSON documents)
|
||||
against a formal schema defined
|
||||
in some `JSON Schema <http://json-schema.org/>`_ files.
|
||||
Those files are part of the IPDB Protocol.
|
||||
Those files are part of the IPDB Transaction Spec.
|
||||
Their official source is the ``tx_schema/`` directory
|
||||
in the `ipdb/ipdb-protocol repository on GitHub
|
||||
<https://github.com/ipdb/ipdb-protocol>`_,
|
||||
in the `ipdb/ipdb-tx-spec repository on GitHub
|
||||
<https://github.com/ipdb/ipdb-tx-spec>`_,
|
||||
but BigchainDB Server uses copies of those files;
|
||||
those copies can be found
|
||||
in the ``bigchaindb/common/schema/`` directory
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user