For the unit testing of the delegation system we are building for Tezzigator, we’ve found it necessary to have a permanent sandboxed blockchain. Tezos already has a sandbox setup available, but it runs in its own shell and the scripts to use it will just delete it all as soon as the node is stopped. That last part is irritating, so here is a method that will give you something more permanent to use for your own testing. Using this method you get to decide when to generate blocks and what to put in them. You can shut it all down and it will be ready for you when you bring it back up, unlike the Tezos-provided sandbox. We are simply running our own private clone of the Tezos blockchain.
To understand it and how to pull it off requires an understanding of what Arthur Breitman means when he uses certain terms to describe Tezos since it differs from other PoS cryptocurrencies in many ways. For example, see this post explaining how POS is different in Tezos.
For this topic specifically we need to understand how genesis funding keys work in Tezos.
Genesis Block — is essentially an empty block. In Tezos, the genesis block is different than other POS genesis blocks. Normally they have funded accounts’ keys in them along with constants, etc., but in Tezos it just contains a “dictator’s” public key that can be used to activate a “protocol” (as best I can tell). Of course, genesis block is still level 0 in Tezos.
Protocol — this is a chunk of data that goes into block 1. This is done by the “dictator” after the node is launched and has only the genesis block in its database. The protocol is where genesis accounts and blockchain constants are defined in block 1 for the chain to then be built on top of block 1. Currently on the zeronet, cycle 0 officially starts at block 2.
The stock genesis block that is generated the zeronet after compilation has a “dictator” public key where we the users do not know the secret key. This makes sense as people could otherwise wreak havoc on the public zeronet test blockchain otherwise but you can hack it to use your own “dictator” key. Also, before you compile you can even change the constants around as you please. The steps: (MODIFIED ON 9/20/2018 to handle new protocol changes for MAINNET)
- Fetch the mainnet branch:
git clone -b mainnet https://gitlab.com/tezos/tezos.git
- Edit source code of the genesis block’s dictator public key and put this key edpkuSLWfVU1Vq7Jg9FucPyKmma6otcMHac9zG4oU1KMHSTBpJuGQ2 in place of the existing dictator key:
- Compile Tezos
- Do the standard “identity generate 26” for your node and then run your node with the parameters:
nohup tezos-node run — bootstrap-threshold=0 — closed — connections=0 — net-addr=127.0.0.1:9732 — no-bootstrap-peers — rpc-addr=127.0.0.1:8732 &
- Import your dictator secret key to your client
tezos-client import secret key dictator unencrypted:edsk31vznjHSSpGExDMHYASz45VZqXN4DPxvsa4hAyY8dHM28cZzp6
- Activate your protocol on top of the genesis block 0. This creates block#1 with all your protocol data.
tezos-client -b genesis activate protocol PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP with fitness 24 and key dictator and parameters ./scripts/protocol_parameters.json (feel free to edit the JSON file for any custom constants you want)
- Import the secret keys of your genesis accounts, each containing ꜩ4M
tezos-client import secret key b1 unencrypted:edsk3gUfUPyBSfrS9CCgmCiQsTCHGkviBDusMxDJstFtojtc1zcpsh -f
tezos-client import secret key b2 unencrypted:edsk39qAm1fiMjgmPkw1EgQYkMzkJezLNewd7PLNHTkr6w9XA2zdfo -f
tezos-client import secret key b3 unencrypted:edsk4ArLQgBTLWG5FJmnGnT689VKoqhXwmDPBuGx3z4cvwU9MmrPZZ -f
tezos-client import secret key b4 unencrypted:edsk2uqQB9AY4FvioK2YMdfmyMrer5R8mGFyuaLLFfSRo8EoyNdht3 -f
tezos-client import secret key b5 unencrypted:edsk4QLrcijEffxV31gGdN2HU7UpyJjA8drFoNcmnB28n89YjPNRFm -f
Now you can use the tezos-node and tezos-client as you normally did, but now controlling everything that happens. You control all keys, who connects, who can send operations, and who can generate. Also WHEN all this happens.