* wip * wip: wrap node's sphinx key with a manager * wip: choosing correct key for packet processing * further propagation of key rotation information * attaching key rotation information to reply surbs * added basic key rotation information to mixnet contract * wip: introducing cached queries for key rotation info from nym api * unified nym-api contract cache refreshing * finish packet decoding * multi api client + retrieving rotation id * rotating sphinx key files * logic for migrating config file * wip: putting new sphinx keys to self described endpoints * processing loop of KeyRotationController * fixed sphinx key loading * rotating bloomfilters * wired up KeyRotationController * flushing bloomfilters to disk and loading * most of nym-node changes * post rebase fixes * fixes due to backwards compatible hostkeys * split http state.rs file * dont use deprecated fields * fixed backwards compatible deserialisation of host information * split up node describe cache * added a dedicated CacheRefresher listener to perform full refresh outside the set interval * controlling announced sphinx keys within nym-api * retrieving rotation id when pulling topology * split nym-nodes http handlers * v2 nym-api endpoints to retrieve nodes with additional metadata information * bug fixes... * additional bugfixes and guards against stuck epoch * testnet manager: set first nym-api as the rewarder * fixed host information deserialisation * fixed panic during first key rotation * post rebase fixes * clippy * more guards against stuck epochs * added helper method to reset node's sphinx key * instantiate mixnet contract with custom key rotation validity * additional bugfixes and debugging nym-api deadlock * passing shutdown to nym apis client * remove dead test * post rebasing fixes * missing MixnetQueryClient variants * remove usage of deprecated methods in sdk example * fix: incorrect method signature * post rebasing fixes * attempt to retrieve key rotation id before doing any config migration work * ignore tests relying on networking behaviour * allow networking failures in certain tests
Testnet manager
This is extremely experimental tool. Only to be used internally. Expect a lot of breaking changes.
Currently (as of 11.07.24), it exposes the following commands:
build-info
Show build information of this binary. Does it need any more than that?
initialise-new-network
pre-requisites:
- you must have built all nym-contracts and put them in the same directory (just run
make contractsfrom the root directory)
Initialises new testnet network:
- attempts to retrieve paths to all .wasm files of the nym-contracts based on provided arguments
- uploads all the contracts to the specified nyxd
- creates mnemonics for all contract admins
- transfers some tokens to each created account
- instantiates all the contracts
- performs post-instantiation migration (like sets vesting contract address inside the mixnet contract)
- queries each contract and retrieves its build information to display any warnings if they were built using some ancient commits
- persists all the network info (addresses, mnemonics, etc.) in the database for future use
note: if you intend to bond-local-mixnet afterward, you want to set --custom-epoch-duration-secs to a rather low
value (like 60s)
load-network-details
Attempt to load testnet network details using either the provided name, or if nothing was specified, the latest one created.
It outputs contents of an .env file you'd use with that network.
bypass-dkg
pre-requisites:
- you must have built the
dkg-bypass contract(just runmake build-bypass-contractfrom this directory)
Attempts to bypass the DKG by overwriting the contract state with pre-generated keys:
- generates data for each specified ecash signer:
- ecash keys via a ttp
- ed25519 identity keys
- cosmos mnemonic
- validates the existing DKG contract to make sure the DKG hasn't actually already been run and checks the group contract to make sure its empty
- persists the signer data generated at the beginning
- uploads the bypass contract
- overwrites the contract state (endpoints, keys, etc.) using the uploaded contract
- restores the original DKG contract code
- adds the ecash signers to the CW4 group
- transfers some tokens to each ecash signer so they could actually execute txs
initialise-post-dkg-network
pre-requisites:
- you must have built all nym-contracts and put them in the same directory (just run
make contractsfrom the root directory) - you must have built the
dkg-bypass contract(just runmake build-bypass-contractfrom this directory)
Initialises new network and bypasses the DKG. It's just the equivalent of running initialise-new-network
and bypass-dkg separately:
- runs equivalent of
initialise-new-network - runs equivalent of
bypass-dkg
create-local-ecash-apis
pre-requisites:
- you must have built all nym-contracts and put them in the same directory (just run
make contractsfrom the root directory) - you must have built the
dkg-bypass contract(just runmake build-bypass-contractfrom this directory) - you must have built
nym-apibinary
Attempt to create brand new network, in post DKG-state, using locally running nym-apis.
- runs equivalent of
initialise-post-dkg-network, with one difference: rather than requiring you to provide api endpoints to all signers, it defaults tohttp:://127.0.0.1:X, whereX = 10000 + i, based on the number of apis specified in the args - runs
nym-api initfor all required api - copies over keys generated during
bypass-dkginto the correct path for each API, - generates an
.envfile to use in all subsequentruncommands - generates and outputs (either as raw string or
jsonif used with--output=json) run commands for each nym-api using full canonical and absolute paths (so you could paste them regardless of local directory)
bond-local-mixnet
pre-requisites:
- you must have a running network including nym-api (just run
create-local-ecash-apisand start the binaries) - the mixnet epoch must be waiting for transition (thus
--custom-epoch-duration-secsrecommendation) - you must have built
nym-nodebinary
Attempt to bond minimal local mixnet (3 mixnodes + 1 gateways) and output the run commands.
- runs
nym-node init4 times, including once inmode==entry(with credentials) - generates mnemonics for each node
- generates bonding signatures for each node
- transfers some tokens to each bond owner
- performs bonding of mixnode/gateway
- assigns all nodes to the active set by:
- starting epoch transition
- reconciling epoch events
- advancing current epoch and assigning the nodes to the set
- generates and outputs (either as raw string or
jsonif used with--output=json) run commands for each nym-node using full canonical and absolute paths (so you could paste them regardless of local directory)
create-local-client
pre-requisites:
- you must have a running MIXNET including nym-api AND nym-nodes (just run
create-local-ecash-apisfollowed bybond-local-mixnetand start the binaries) - you must have built
nym-clientbinary
Initialise a locally run nym-client, adjust its config and output the run command:
- runs
nym-client initin credentials mode - updates its config to add
minimum_mixnode_performance = 0andminimum_gateway_performance = 0thus ignoring the lack of a network monitor - generates and outputs run command for the client using full canonical and absolute paths (so you could paste it regardless of local directory)
Extra
For reference, my workflow was as follows:
note: for the very first run you'll have to explicitly provide mnemonics and nyxd
- rebuild whichever binary/contract was needed
cargo run -- create-local-ecash-apis --bypass-dkg-contract ../../../target/wasm32-unknown-unknown/release/dkg_bypass_contract.wasm --number-of-apis=2 --nym-api-bin ../../../target/release/nym-api --built-contracts ../../../contracts/target/wasm32-unknown-unknown/release --custom-epoch-duration-secs=60- run the apis in separate terminal window
cargo run -- bond-local-mixnet --nym-node-bin ../../../target/release/nym-node- start all the nym-nodes
cargo run -- create-local-client --nym-client-bin ../../../target/debug/nym-client- usually at this point I was using
nym-clito get some ticketbooks into my client before running it with the command that was output in the previous step