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

Bolded some headings in the section on immutability

Browse Source
This commit is contained in:
troymc 2016-06-07 15:45:38 +02:00
parent 5bbe82ac0c
commit 48c54cf75f
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/source/topic-guides/immutable.md
View File

@ -6,12 +6,12 @@ It’s true that blockchain data is more difficult to change than usual: it’s
BigchainDB achieves strong tamper-resistance in the following ways:
1. Replication: all data is sharded and shards are replicated in several (different) places. The replication factor can be set by the federation. The higher the replication factor, the more difficult it becomes to change or delete all replicas.
2. If the “bigchain” table is modified via the underlying database’s API, then all nodes are notified of that change. Only two kinds of changes are allowed to persist: 1) addition of a new block or 2) addition of a new vote (not including a “second vote” from a node on a block). All other changes are reverted automatically. For this and other reasons, we suggest that all federations consider the _diversity_ in who controls the servers (federation nodes). We expand on what we mean by diversity below.
3. Cryptographic signatures are used throughout BigchainDB as a way to check if messages (transactions, blocks and votes) have been tampered with enroute, and as a way to verify who signed the messages. Each block is signed by the node that created it. Each vote is signed by the node that cast it. A creation transaction is signed by the node that created it, although there are plans to improve that by adding signatures from the sending client and multiple nodes; see [Issue #347](https://github.com/bigchaindb/bigchaindb/issues/347). Transfer transactions can contain multiple fulfillments (one per asset transferred). Each fulfillment will typically contain one or more signatures from the owners (i.e. the owners before the transfer). Hashlock fulfillments are an exception; there’s an open issue ([#339](https://github.com/bigchaindb/bigchaindb/issues/339)) to address that.
4. Full or partial backups of the database may be recorded from time to time, possibly on magnetic tape storage, other blockchains, printouts, etc.
5. Federations may opt to have trusted third-parties to monitor and audit their data, looking for irregularities. For federations with publicly-readable data, the public can act as an auditor.
6. Node owners can adopt and enforce strong security policies.
1. **Replication.** All data is sharded and shards are replicated in several (different) places. The replication factor can be set by the federation. The higher the replication factor, the more difficult it becomes to change or delete all replicas.
2. **Unallowed changes get reverted.** If the “bigchain” table is modified via the underlying database’s API, then all nodes are notified of that change. Only two kinds of changes are allowed to persist: 1) addition of a new block or 2) addition of a new vote (not including a “second vote” from a node on a block). All other changes are reverted automatically. For this and other reasons, we suggest that all federations consider the _diversity_ in who controls the servers (federation nodes). We expand on what we mean by diversity below.
3. **Cryptographic signatures** are used throughout BigchainDB as a way to check if messages (transactions, blocks and votes) have been tampered with enroute, and as a way to verify who signed the messages. Each block is signed by the node that created it. Each vote is signed by the node that cast it. A creation transaction is signed by the node that created it, although there are plans to improve that by adding signatures from the sending client and multiple nodes; see [Issue #347](https://github.com/bigchaindb/bigchaindb/issues/347). Transfer transactions can contain multiple fulfillments (one per asset transferred). Each fulfillment will typically contain one or more signatures from the owners (i.e. the owners before the transfer). Hashlock fulfillments are an exception; there’s an open issue ([#339](https://github.com/bigchaindb/bigchaindb/issues/339)) to address that.
4. **Full or partial backups** of the database may be recorded from time to time, possibly on magnetic tape storage, other blockchains, printouts, etc.
5. **Watchdogs.** Federations may opt to have trusted third-parties to monitor and audit their data, looking for irregularities. For federations with publicly-readable data, the public can act as an auditor.
6. **Strong security.** Node owners can adopt and enforce strong security policies.
## The Kinds of Diversity a Federation Should Consider