f73623789e
VDB-337 Dockerize vDB |
||
---|---|---|
bin | ||
cmd | ||
db | ||
dockerfiles | ||
environments | ||
integration_test | ||
libraries/shared | ||
pkg | ||
postgraphile | ||
scripts | ||
test_config | ||
utils | ||
vendor | ||
.dockerignore | ||
.gitignore | ||
.private_blockchain_password | ||
.travis.yml | ||
Dockerfile | ||
Gopkg.lock | ||
Gopkg.toml | ||
LICENSE | ||
main.go | ||
Makefile | ||
README.md | ||
Supfile |
Vulcanize DB
About
Vulcanize DB is a set of tools that make it easier for developers to write application-specific indexes and caches for dapps built on Ethereum.
Dependencies
- Go 1.11+
- Postgres 10
- Ethereum Node
- Go Ethereum (1.8.21+)
- Parity 1.8.11+
Project Setup
Using Vulcanize for the first time requires several steps be done in order to allow use of the software. The following instructions will offer a guide through the steps of the process:
- Fetching the project
- Installing dependencies
- Configuring shell environment
- Database setup
- Configuring synced Ethereum node integration
- Data syncing
Installation
In order to fetch the project codebase for local use or modification, install it to your GOPATH
via:
go get github.com/vulcanize/vulcanizedb
go get gopkg.in/DataDog/dd-trace-go.v1/ddtrace
Once fetched, dependencies can be installed via go get
or (the preferred method) at specific versions via golang/dep
, the prototype golang pakcage manager. Installation instructions are here.
In order to install packages with dep
, ensure you are in the project directory now within your GOPATH
(default location is ~/go/src/github.com/vulcanize/vulcanizedb/
) and run:
dep ensure
After dep
finishes, dependencies should be installed within your GOPATH
at the versions specified in Gopkg.toml
.
Lastly, ensure that GOPATH
is defined in your shell. If necessary, GOPATH
can be set in ~/.bashrc
or ~/.bash_profile
, depending upon your system. It can be additionally helpful to add $GOPATH/bin
to your shell's $PATH
.
Setting up the Database
-
Install Postgres
-
Create a superuser for yourself and make sure
psql --list
works without prompting for a password. -
createdb vulcanize_public
-
cd $GOPATH/src/github.com/vulcanize/vulcanizedb
-
Run the migrations:
make migrate HOST_NAME=localhost NAME=vulcanize_public PORT=5432
- To rollback a single step:
make rollback NAME=vulcanize_public
- To rollback to a certain migration:
make rollback_to MIGRATION=n NAME=vulcanize_public
- To see status of migrations:
make migration_status NAME=vulcanize_public
- See below for configuring additional environments
- To rollback a single step:
Create a migration file
make new_migration NAME=add_columnA_to_table1
- This will create a new timestamped migration file in
db/migrations
- This will create a new timestamped migration file in
- Write the migration code in the created file, under the respective
goose
pragma- Goose automatically runs each migration in a transaction; don't add
BEGIN
andCOMMIT
statements.
- Goose automatically runs each migration in a transaction; don't add
Configuration
-
To use a local Ethereum node, copy
environments/public.toml.example
toenvironments/public.toml
and update theipcPath
andlevelDbPath
.-
ipcPath
should match the local node's IPC filepath:-
For Geth:
- The IPC file is called
geth.ipc
. - The geth IPC file path is printed to the console when you start geth.
- The default location is:
- Mac:
<full home path>/Library/Ethereum
- Linux:
<full home path>/ethereum/geth.ipc
- Mac:
- The IPC file is called
-
For Parity:
- The IPC file is called
jsonrpc.ipc
. - The default location is:
- Mac:
<full home path>/Library/Application\ Support/io.parity.ethereum/
- Linux:
<full home path>/local/share/io.parity.ethereum/
- Mac:
- The IPC file is called
-
-
levelDbPath
should match Geth's chaindata directory path.- The geth LevelDB chaindata path is printed to the console when you start geth.
- The default location is:
- Mac:
<full home path>/Library/Ethereum/geth/chaindata
- Linux:
<full home path>/ethereum/geth/chaindata
- Mac:
levelDbPath
is irrelevant (andcoldImport
is currently unavailable) if only running parity.
-
-
See
environments/infura.toml
to configure commands to run against infura, if a local node is unavailable. -
Copy
environments/local.toml.example
toenvironments/local.toml
to configure commands to run against a local node such as Ganache or ganache-cli.
Start syncing with postgres
Syncs VulcanizeDB with the configured Ethereum node, populating blocks, transactions, receipts, and logs. This command is useful when you want to maintain a broad cache of what's happening on the blockchain.
- Start Ethereum node (if fast syncing your Ethereum node, wait for initial sync to finish)
- In a separate terminal start VulcanizeDB:
./vulcanizedb sync --config <config.toml> --starting-block-number <block-number>
Alternatively, sync from Geth's underlying LevelDB
Sync VulcanizeDB from the LevelDB underlying a Geth node.
- Assure node is not running, and that it has synced to the desired block height.
- Start vulcanize_db
./vulcanizedb coldImport --config <config.toml>
- Optional flags:
--starting-block-number <block number>
/-s <block number>
: block number to start syncing from--ending-block-number <block number>
/-e <block number>
: block number to sync to--all
/-a
: sync all missing blocks
Alternatively, sync in "light" mode
Syncs VulcanizeDB with the configured Ethereum node, populating only block headers. This command is useful when you want a minimal baseline from which to track targeted data on the blockchain (e.g. individual smart contract storage values).
- Start Ethereum node
- In a separate terminal start VulcanizeDB:
./vulcanizedb lightSync --config <config.toml> --starting-block-number <block-number>
Continuously sync Maker event logs from light sync
Continuously syncs Maker event logs from the configured Ethereum node based on the populated block headers.
This includes logs related to auctions, multi-collateral dai, and price feeds.
This command requires that the lightSync
process is also being run so as to be able to sync in real time.
- Start Ethereum node (or plan to configure the commands to point to a remote IPC path).
- In a separate terminal run the lightSync command (see above).
- In another terminal window run the continuousLogSync command:
./vulcanizedb continuousLogSync --config <config.toml>
- An option
--transformers
flag may be passed to the command to specific which transformers to execute, this will default to all transformers if the flag is not passed../vulcanizedb continuousLogSync --config environments/private.toml --transformers="priceFeed"
- see the
buildTransformerInitializerMap
method incmd/continuousLogSync.go
for available transformers
Backfill Maker event logs from light sync
Backfills Maker event logs from the configured Ethereum node based on the populated block headers. This includes logs related to auctions, multi-collateral dai, and price feeds. This command requires that a light sync (see command above) has previously been run.
Since auction/mcd contracts have not yet been deployed, this command will need to be run a local blockchain at the moment. As such, a new environment file will need to be added. See environments/local.toml.example
.
- Start Ethereum node
- In a separate terminal run the backfill command:
./vulcanizedb backfillMakerLogs --config <config.toml>
Start full environment in docker by single command
Geth Rinkeby
make command | description |
---|---|
rinkeby_env_up | start geth, postgres and rolling migrations, after migrations done starting vulcanizedb container |
rinkeby_env_deploy | build and run vulcanizedb container in rinkeby environment |
rinkeby_env_migrate | build and run rinkeby env migrations |
rinkeby_env_down | stop and remove all rinkeby env containers |
Success run of the VulcanizeDB container require full geth state sync, attach to geth console and check sync state:
$ docker exec -it rinkeby_vulcanizedb_geth geth --rinkeby attach
...
> eth.syncing
false
If you have full rinkeby chaindata you can move it to rinkeby_vulcanizedb_geth_data
docker volume to skip long wait of sync.
Running the Tests
make test
will run the unit tests and skip the integration testsmake integrationtest
will run the just the integration tests- Note: requires Ganache chain setup and seeded with
flip-kick.js
andfrob.js
(in that order)
Deploying
- you will need to make sure you have ssh agent running and your ssh key added to it. instructions here
go get -u github.com/pressly/sup/cmd/sup
sup staging deploy
omniWatcher
These commands require a pre-synced (full or light) vulcanizeDB (see above sections)
To watch all events of a contract using a light synced vDB:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address>
Or if you are using a full synced vDB, change the mode to full:
- Execute ./vulcanizedb omniWatcher --mode full --config <path to config.toml> --contract-address <contract address>
To watch contracts on a network other than mainnet, use the network flag:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --network <ropsten, kovan, or rinkeby>
To watch events starting at a certain block use the starting block flag:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --starting-block-number <#>
To watch only specified events use the events flag:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --events <EventName1> --events <EventName2>
To watch events and poll the specified methods with any addresses and hashes emitted by the watched events utilize the methods flag:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --methods <methodName1> --methods <methodName2>
To watch specified events and poll the specified method with any addresses and hashes emitted by the watched events:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --events <EventName1> --events <EventName2> --methods <methodName>
To turn on method piping so that values returned from previous method calls are cached and used as arguments in subsequent method calls:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --piping true --contract-address <contract address> --events <EventName1> --events <EventName2> --methods <methodName>
To watch all types of events of the contract but only persist the ones that emit one of the filtered-for argument values:
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --event-args <arg1> --event-args <arg2>
To watch all events of the contract but only poll the specified method with specified argument values (if they are emitted from the watched events):
- Execute ./vulcanizedb omniWatcher --config <path to config.toml> --contract-address <contract address> --methods <methodName> --method-args <arg1> --method-args <arg2>