105 lines
4.3 KiB
Markdown
105 lines
4.3 KiB
Markdown
|
|
||
|
|
Introduction
|
||
|
|
------------
|
||
|
|
|
||
|
|
The `debug_node` is a tool to allow developers to run many interesting sorts of "what-if" tests using state from a production blockchain.
|
||
|
|
Like "what happens if I produce enough blocks for the next hardfork time to arrive?" or "what would happen if this account (which I don't have a private key for) did this transaction?"
|
||
|
|
|
||
|
|
Setup
|
||
|
|
-----
|
||
|
|
|
||
|
|
Be sure you've built the right build targets:
|
||
|
|
|
||
|
|
$ make get_dev_key debug_node cli_wallet witness_node
|
||
|
|
|
||
|
|
Use the `get_dev_key` utility to generate a keypair:
|
||
|
|
|
||
|
|
$ programs/genesis_util/get_dev_key "" nathan
|
||
|
|
[{"private_key":"5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3","public_key":"BTS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","address":"BTSFAbAx7yuxt725qSZvfwWqkdCwp9ZnUama"}]
|
||
|
|
|
||
|
|
Obtain a copy of the blockchain in `block_db` directory:
|
||
|
|
$ programs/witness_node/witness_node --data-dir data/mydatadir
|
||
|
|
# ... wait for chain to sync
|
||
|
|
^C
|
||
|
|
$ cp -Rp data/mydatadir/blockchain/database/block_num_to_block ./block_db
|
||
|
|
|
||
|
|
Set up a new datadir with the following `config.ini` settings:
|
||
|
|
|
||
|
|
# setup API endpoint
|
||
|
|
rpc-endpoint = 127.0.0.1:8090
|
||
|
|
# setting this to empty effectively disables the p2p network
|
||
|
|
seed-nodes = []
|
||
|
|
# set apiaccess.json so we can set up
|
||
|
|
api-access = "data/debug_datadir/api-access.json"
|
||
|
|
|
||
|
|
Then set up `data/debug_datadir/api-access.json` to allow access to the debug API like this:
|
||
|
|
|
||
|
|
{
|
||
|
|
"permission_map" :
|
||
|
|
[
|
||
|
|
[
|
||
|
|
"bytemaster",
|
||
|
|
{
|
||
|
|
"password_hash_b64" : "9e9GF7ooXVb9k4BoSfNIPTelXeGOZ5DrgOYMj94elaY=",
|
||
|
|
"password_salt_b64" : "INDdM6iCi/8=",
|
||
|
|
"allowed_apis" : ["database_api", "network_broadcast_api", "history_api", "network_node_api", "debug_api"]
|
||
|
|
}
|
||
|
|
],
|
||
|
|
[
|
||
|
|
"*",
|
||
|
|
{
|
||
|
|
"password_hash_b64" : "*",
|
||
|
|
"password_salt_b64" : "*",
|
||
|
|
"allowed_apis" : ["database_api", "network_broadcast_api", "history_api"]
|
||
|
|
}
|
||
|
|
]
|
||
|
|
]
|
||
|
|
}
|
||
|
|
|
||
|
|
See [here](https://github.com/cryptonomex/graphene#accessing-restricted-apis) for more detail on the `api-access.json` format.
|
||
|
|
|
||
|
|
Once that is set up, run `debug_node` against your newly prepared datadir:
|
||
|
|
|
||
|
|
programs/debug_node/debug_node --data-dir data/debug_datadir
|
||
|
|
|
||
|
|
Run `cli_wallet` to connect to the `debug_node` port, using the username and password to access the new `debug_api` (and also a different wallet file):
|
||
|
|
|
||
|
|
programs/cli_wallet/cli_wallet -s 127.0.0.1:8090 -w debug.wallet -u bytemaster -p supersecret
|
||
|
|
|
||
|
|
Example usage
|
||
|
|
-------------
|
||
|
|
|
||
|
|
Load some blocks from the datadir:
|
||
|
|
|
||
|
|
dbg_push_blocks block_db 20000
|
||
|
|
|
||
|
|
Note, when pushing a very large number of blocks sometimes `cli_wallet` hangs and you must Ctrl+C and restart it (leaving the `debug_node` running).
|
||
|
|
|
||
|
|
Generate (fake) blocks with our own private key:
|
||
|
|
|
||
|
|
dbg_generate_blocks 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3 1000
|
||
|
|
|
||
|
|
Update `angel` account to be controlled by our own private key and generate a (fake) transfer:
|
||
|
|
|
||
|
|
dbg_update_object {"_action":"update", "id":"1.2.1090", "active":{"weight_threshold":1,"key_auths":[["BTS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV",1]]}}
|
||
|
|
import_key angel 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
|
||
|
|
transfer angel init0 999999 BTS "" true
|
||
|
|
|
||
|
|
How it works
|
||
|
|
------------
|
||
|
|
|
||
|
|
The commands work by creating diff(s) from the main chain that are applied to the local chain at specified block height(s). It lets you easily check out "what-if"
|
||
|
|
scenarios in a fantasy debug toy world forked from the real chain, e.g. "if we take all of the blocks until today, then generate a bunch more until a hardfork time
|
||
|
|
in the future arrives, does the chain stay up? Can I do transactions X, Y, and Z in the wallet after the hardfork?" Anyone connecting to this node sees the same
|
||
|
|
fantasy world, so you can e.g. make changes with the `cli_wallet` and see them exist in other `cli_wallet` instances (or GUI wallets or API scripts).
|
||
|
|
|
||
|
|
Limitations
|
||
|
|
-----------
|
||
|
|
|
||
|
|
The main limitations are:
|
||
|
|
|
||
|
|
- No export format for the diffs, so you can't really [1] connect multiple `debug_node` to each other.
|
||
|
|
- Once faked block(s) or tx(s) have been produced on your chain, you can't really [1] stream blocks or tx's from the main network to your chain.
|
||
|
|
|
||
|
|
[1] It should theoretically be possible, but it's non-trivial and totally untested.
|