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

Copy editing models.md in docs

Browse Source
This commit is contained in:
troymc 2016-02-22 17:27:59 +01:00
parent ecb9296312
commit 18fa13f397
1 changed files with 17 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/source/models.md
View File

@ -1,6 +1,6 @@
# The Transaction, Block and Vote Models
Transactions, blocks and votes are represented using JSON documents with the following models (schemas).
Transactions, blocks and votes are represented using JSON documents with the following models (schemas). See [the section on cryptography](cryptography.html) for more information about how we calculate hashes and signatures.
## The Transaction Model
@ -22,64 +22,59 @@ Transactions, blocks and votes are represented using JSON documents with the fol
}
}
},
"signature": "<ECDSA signature of the transaction>"
"signature": "<signature of the transaction>"
}
```
A transaction is an operation between the `current_owner` and the `new_owner` over the digital content described by `hash`. For example if could be a transfer of ownership of the digital content `hash`
- `id`: sha3 hash of the transaction and rethinkdb primary key. By using the hash of the transaction of the
primary key we eliminate the problem of duplicated transactions, if for some reason two nodes decide to create the
same transaction
- `id`: sha3 hash of the transaction. Also the RethinkDB primary key. By using the hash of the transaction as the primary key, we eliminate the problem of duplicated transactions, if for some reason two nodes decide to create the same transaction
- `current_owner`: Public key of the current owner of the digital content with hash `hash`
- `new_owner`: Public key of the new owner of the digital content with hash `hash`
- `input`: sha3 hash of the transaction in which the content was transfered to the user (similar to input in
the blockchain). Right now we will assume that there is only one input per transaction to simplify the prototype.
This can be changed in the future to allow multiple inputs per transaction.
- `input`: id (sha3 hash) of the transaction in which the content was transfered to the user (similar to input in the blockchain). Right now we will assume that there is only one input per transaction to simplify the prototype. This can be changed in the future to allow multiple inputs per transaction.
- `operation`: String representation of the operation being performed (REGISTER, TRANSFER, ...) this will define how
the transactions should be validated
- `timestamp`: Time of creation of the transaction in UTC
- `data`: JSON object describing the asset (digital content). It contains at least the field `hash` which is a
sha3 hash of the digital content.
- `signature`: ECDSA signature of the transaction with the `current_owner` private key
- `signature`: Signature of the transaction with the `current_owner` private key
## The Block Model
```json
{
"id": "<sha3 hash of the list of transactions + timestamp + nodes_pubkeys>",
"id": "<sha3 hash of the serialized block contents>",
"block": {
"timestamp": "<RethinkDB timestamp>",
"transactions": ["<list of transactions>"],
"node_pubkey": "<public key of the node creating the block>",
"voters": ["<list of federation nodes pulic keys>"]
"voters": ["<list of federation nodes public keys>"]
},
"signature": "<signature of the block>",
"votes": []
"votes": ["<list of votes>"]
}
```
Still to be defined when new blocks are created (after x number of transactions, or after x amount of seconds,
or both).
A block contains a group of transactions and includes the hash of the hash of the previous block to build the chain.
- `id`: sha3 hash of the current block. This is also a RethinkDB primary key, this way we make sure that all blocks are unique.
- `id`: sha3 hash of the contents of `block` (i.e. the timestamp, list of transactions, node_pubkey, and voters). This is also a RethinkDB primary key; that's how we ensure that all blocks are unique.
- `block`: The actual block
- `timestamp`: timestamp when the block was created
- `transactions`: the list of transactions included in the block
- `node_pubkey`: the public key of the node that create the block
- `voters`: list public keys of the federation nodes. Since the size of the
- `voters`: list public keys of the federation nodes. Since the size of the
federation may change over time this will tell us how many nodes existed
in the federation when the block was created so that in a later point in
time we can check that the block received the correct number of votes.
- `signature`: Signature of the block by the node that created the block
- `votes`: Initially an empty list. Nodes in the voters list will append to it
has they vote on the block
- `signature`: Signature of the block by the node that created the block (i.e. To create it, the node serialized the block contents and signed that with its private key)
- `votes`: Initially an empty list. New votes are appended as they come in from the nodes.
## The Vote Model
This is the structure that each node will append to the block `votes` list.
Each node must generate a vote for each block, to be appended to that block's `votes` list. A vote has the following structure:
```json
{
@ -91,6 +86,8 @@ This is the structure that each node will append to the block `votes` list.
"invalid_reason": "<None|DOUBLE_SPEND|TRANSACTIONS_HASH_MISMATCH|NODES_PUBKEYS_MISMATCH",
"timestamp": "<timestamp of the voting action>"
},
"signature": "<ECDSA signature of vote block>"
"signature": "<signature of vote block>"
}
```
Note: The `invalid_reason` was not being used as of v0.1.3.