Permalink
Browse files

Update documentation to match version 0.2.0

  • Loading branch information...
martinboehm committed Jan 24, 2019
1 parent 499d654 commit e27821f2319e1a06ae09662d597e0bb36e81dc7c
Showing with 102 additions and 65 deletions.
  1. +24 −25 CONTRIBUTING.md
  2. +10 −13 README.md
  3. +4 −4 docs/config.md
  4. +64 −23 docs/rocksdb.md
@@ -1,15 +1,15 @@
# Blockbook Contributor Guide

Blockbook is back-end service for Trezor wallet. Although it is open source, design and development of core packages
Blockbook is back-end service for Trezor wallet. Although it is open source, the design and development of the core packages
is done by Trezor developers in order to keep Blockbook compatible with Trezor.

Bug fixes and support for new coins are welcome. Please take note that non-fixing pull requests that change base
packages or another coin code will not be accepted. If you will have to change some of existing code, please file
packages or another coin code will not be accepted. If you have a need to change some of the existing code, please file
an issue and discuss your request with Blockbook maintainers.

## Development environment

Instructions to set up your development environment and build Blockbook are described in separated
Instructions to set up your development environment and build Blockbook are described in a separate
[document](/docs/build.md).

## How can I contribute?
@@ -25,44 +25,43 @@ updates. Do not leave random "+1" or "I have this too" comments, as they only cl
resolving it. However, if you have ways to reproduce the issue or have additional information that may help resolving
the issue, please leave a comment.

Include information about Blockbook instance which is exposed at internal HTTP port. Ports are listed in
[port registry](/docs/ports.md). For example execute `curl -k https://localhost:9030` for Bitcoin.
Include information about the Blockbook instance, which is shown at the Blockbook status page or returned by API call. For example execute `curl -k https://<server name>:<public port>/api` to get JSON containing details about Blockbook and Backend installation. Ports are listed in the [port registry](/docs/ports.md).

Also include the steps required to reproduce the problem if possible and applicable. This information will help us
review and fix your issue faster. When sending lengthy log-files, consider posting them as a gist
(https://gist.github.com).

### Adding coin support

Trezor harware wallet supports over 500 coins, see https://trezor.io/coins/. You are free to add support for any of
them to Blockbook. Actually implemented coins are listed [here](/docs/ports.md).
> **Important notice**: Although we are happy for support of new coins, we do not have enough capacity to run them all
> on our infrastructure. We run Blockbook instances only for selected number of coins. If you want to have Blockbook
> instance for your coin, you will have to deploy it to your own server.
You should follow few steps bellow to get smooth merge of your PR.
Trezor harware wallet supports over 500 coins, see https://trezor.io/coins/. You are free to add support for any of
them to Blockbook. Currently implemented coins are listed [here](/docs/ports.md).

> Although we are happy for support of new coins we have not enough capacity to run them all on our infrastructure.
> Actually we can run Blockbook instances only for coins supported by Trezor wallet. If you want to have Blockbook
> instance for your coin, you will have to deploy your own server.
You should follow the steps below to get smooth merge of your PR.

#### Add coin definition

Coin definitions are stored in JSON files in *configs/coins* directory. They are single source of Blockbook
Coin definitions are stored in JSON files in *configs/coins* directory. They are the single source of Blockbook
configuration, Blockbook and back-end package definition and build metadata. Since Blockbook supports only single
coin index per running instance, every coin (including testnet) must have single definition file.

All options of coin definition are described in [config.md](/docs/config.md).

Because most of coins are fork of Bitcoin and they have similar way to install and configure their daemon, we use
templates to generate package definition and configuration files during build process. Similarly, there templates for Blockbook
templates to generate package definition and configuration files during build process. Similarly, there are templates for Blockbook
package. Templates are filled with data from coin definition. Although normally all package definitions are generated automatically
during the build process, sometimes there is a reason to see them. You can create them by calling
during the build process, sometimes there is a reason to check what was generated. You can create them by calling
`go run build/templates/generate.go coin`, where *coin* is name of definition file without .json extension. Files are
generated to *build/pkg-defs* directory.

Good examples of coin configuration are
[*configs/coins/bitcoin.json*](configs/coins/bitcoin.json) and
[*configs/coins/ethereum.json*](configs/coins/ethereum.json) for Bitcoin-like coins and different coins, respectively.
[*configs/coins/ethereum.json*](configs/coins/ethereum.json) for Bitcoin type coins and Ethereum type coins, respectively.

Usually you have to update only few options that differ from Bitcoin definition. At first there is base information
Usually you have to update only a few options that differ from the Bitcoin definition. At first there is base information
about coin in section *coin* – name, alias etc. Then update port information in *port* section. We keep port series as
listed in [the port registry](/docs/ports.md). Select next port numbers in the series. Port numbers must be unique across all
port definitions.
@@ -109,15 +108,15 @@ different concept than Bitcoin.

##### BlockChain interface

Type that implements *bchain.BlockChain* interface ensures communication with block chain network. Because
it calls node RPCs it usually has suffix RPC.
Type that implements *bchain.BlockChain* interface ensures communication with the block chain network. Because
it calls node RPCs, it usually has suffix RPC.

Initialization of object is separated into two stages. At first there is called factory method (details described
in next section) and then *bchain.BlockChain.Initialize()* method. Separated initialization method allows you call
in the next section) and then *bchain.BlockChain.Initialize()* method. Separated initialization method allows you call
inherited methods during initialization. However it is common practice override fields of embedded structure in factory
method.

During initialization, there is usually loaded chain information, registered message queue callback and created mempool
Initialization routine usually loads chain information, registers message queue callback and creates mempool
and parser objects.

BitcoinRPC uses *btc.RPCMarshaller* ([btc/codec.go](/bchain/coins/btc/codec.go)) in order to distinguish API version of
@@ -136,7 +135,7 @@ must correspond to *coin.name* in coin definition file (see above).
Configuration passed to factory method is coin specific. For types that embed *btc.BitcoinRPC,* configuration must
contain at least fields referred in *btc.Configuration* ([btc/bitcoinrpc.go](/bchain/coins/btc/bitcoinrpc.go)).

For types that embed base struct it is common practise call factory method of embedded type in order to
For types that embed base struct it is common practice to call factory method of the embedded type in order to
create & initialize it. It is much more robust than simple struct composition.

For example see [zec/zcashrpc.go](/bchain/coins/zec/zcashrpc.go).
@@ -146,7 +145,7 @@ For example see [zec/zcashrpc.go](/bchain/coins/zec/zcashrpc.go).
Type that implements *bchain.BlockChainParser* interface ensures parsing and conversions of block chain data. It is
initialized by *bchain.BlockChain* during initialization.

There are several groups of methods defined in *bchian.BlockChainParser*:
There are several groups of methods defined in *bchain.BlockChainParser*:

* *GetAddrDescFromVout* and *GetAddrDescFromAddress* – Convert transaction addresses to *Address Descriptor* that is used as database ID.
Most of coins use output script as *Address Descriptor*.
@@ -168,9 +167,9 @@ different approach for address representation than Bitcoin.

#### Add tests

Add unit tests and integration tests. PR without passing tests won't be accepted.
Tests are described [here](/docs/testing.md).
Add unit tests and integration tests. **Pull requests without passing tests will not be accepted**.
How to implement tests is described [here](/docs/testing.md).

#### Deploy public server

Deploy Blockbook server on public IP address. Blockbook maintainers will check implementation before merging.
Deploy Blockbook server on public IP address. Blockbook maintainers will check your implementation before merging.
@@ -6,19 +6,19 @@
**Blockbook** is back-end service for Trezor wallet. Main features of **Blockbook** are:

- create missing indexes in the blockchain - index of addresses and address balances
- allow fast searches in the index of addresses
- implement parts Insight socket.io interface as required by Trezor wallet
- support of multiple coins
- simple blockchain explorer for implemented coins
- index of addresses and address balances of the connected block chain
- fast searches in the indexes
- simple blockchain explorer
- websocket, API and legacy Bitcore Insight compatible socket.io interfaces
- support of multiple coins (Bitcoin and Ethereum type), with easy extensibility for other coins
- scripts for easy creation of debian packages for backend and blockbook

## Build and installation instructions

Officially supported platform is **Debian Linux** and **AMD64** architecture.

Memory and disk requirements for initial synchronization of **Bitcoin mainnet** are around 32 GB RAM and over 150 GB of disk size. After initial synchronization, fully synchronized instance takes around 10 GB RAM.
Other coins should have lower requirements depending on size of their block chain. Note that fast SSD disks are highly
Memory and disk requirements for initial synchronization of **Bitcoin mainnet** are around 32 GB RAM and over 160 GB of disk space. After initial synchronization, fully synchronized instance uses about 10 GB RAM.
Other coins should have lower requirements, depending on the size of their block chain. Note that fast SSD disks are highly
recommended.

User installation guide is [here](https://wiki.trezor.io/User_manual:Running_a_local_instance_of_Trezor_Wallet_backend_(Blockbook)).
@@ -29,14 +29,11 @@ Contribution guide is [here](CONTRIBUTING.md).

# Implemented coins

The most significant coins implemented by Blockbook are:
- Bitcoin, Bcash, Bgold, ZCash, Dash, Litecoin

Incomplete, experimental support is for:
- Ethereum, Ethereum Classic
Blockbook currently supports over 20 coins, among them:
- Bitcoin, Litecoin, Bitcoin Cash, Bgold, ZCash, Dash, Ethereum, Ethereum Classic

Testnets for some coins are also supported, for example:
- Bitcoin Testnet, Bcash Testnet, ZCash Testnet, Ethereum Testnet Ropsten
- Bitcoin Testnet, Bitcoin Cash Testnet, ZCash Testnet, Ethereum Testnet Ropsten

List of all implemented coins is in [the registry of ports](/docs/ports.md).

@@ -75,8 +75,8 @@ Good examples of coin configuration are
Exception is *addnode* key that contains list of nodes that is expanded as addnode=item lines.
* `blockbook` – Definition of Blockbook package, configuration and service.
* `package_name` – Name of package. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
* `system_user` – User used to run Blockbook service. See convention note in [build guide](/docs/build.md#on-naming-conventions-and-versioning).
* `package_name` – Name of package. See convention note in the [build guide](/docs/build.md#on-naming-conventions-and-versioning).
* `system_user` – User used to run Blockbook service. See convention note in the [build guide](/docs/build.md#on-naming-conventions-and-versioning).
* `internal_binding_template` – Template for *-internal* parameter. See note on templates below.
* `public_binding_template` – Template for *-public* parameter. See note on templates below.
* `explorer_url` – URL of blockchain explorer. Leave empty for internal explorer.
@@ -108,8 +108,8 @@ as well. Note that dot at the beginning is mandatory. Go template syntax is full
Since Blockbook is an open-source project and we don't prevent anybody from running independent instances, it is possible
to alter built-in text that is specific for Trezor. Text fields that could be updated are:
* about – A note about instance shown on the Application status page and returned by an API.
* tos – A link to Terms of service shown as the footer on the Explorer pages.
* [about](/build/text/about) – A note about instance shown on the Application status page and returned by an API.
* [tos_link](/build/text/tos_link) – A link to Terms of service shown as the footer on the Explorer pages.
Text data are stored as plain text files in *build/text* directory and are embedded to binary during build. A change of
theese files is mean for a private purpose and PRs that would update them won't be accepted.
Oops, something went wrong.

0 comments on commit e27821f

Please sign in to comment.