anoma/namada

Rust implementation of Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy

namada's Issues

Add a metrics endpoint

A Prometheus-compatible metrics endpoint (/metrics on some configurable port) would be great for monitoring nodes. A Prometheus instance somewhere does all the heavy lifting of scraping the data and storing it as time series. The metrics endpoint just needs to respond with the current values of interesting application-specific data points.

Tendermint also has a metrics endpoint that can be enabled in its config. Currently it's a bit awkward to enable though, because you first need to generate the tendermint config by launching anoma once, edit the tendermint config and then restart anoma.

So maybe there should be just one place in anoma configuration to configure metrics, and it affects tendermint too. We could even aggregate the metrics from tendermint in order to avoid having two metrics endpoints (i.e. two ports for metrics) per node.

┆Issue is synchronized with this Asana task by Unito

PoS - use checked arithmetics

Use checked arithmetics in the PoS library code (has a TODO left in code)

┆Issue is synchronized with this Asana task by Unito

PoS - use finer-grained storage keys

Depends on #12.

Refactor the PoS integration's storage keys to store the epoched data split up into finer-grained data. Currently, all the epoched data are serialized as the whole Epoched/EpochedDelta value.

For example, a validator's voting power is stored in "{PoS_address}/validator/{validator_address}/voting_power". Instead, we can store the fields of the Epoched/EpochedDelta split up into their fields:

• "{PoS_address}/validator/{validator_address}/voting_power/last_update"
• "{PoS_address}/validator/{validator_address}/voting_power/{n}" for each set value in the inner array

This way, when a transaction changes this data, we don't have to find the diff in the whole structure for validation and the validation should then be simpler.

┆Issue is synchronized with this Asana task by Unito

e2e tests improvements

For the e2e tests:

• add a command wrapper that captures the stdout and stderr of the ran processes and allow to set e2e tests to print out processes logs (maybe via an env var)
• propagate RUST_BACKTRACE and ANOMA_LOG env variables to the commands ran via the wrapper
• improve the tests assertions that currently rely on info! log messages to use some custom events that the test runner can capture
• improve shut down to clean up running processes when interrupted

┆Issue is synchronized with this Asana task by Unito

Validation about connection IDs for IBC client

IBC needs to store IBC connection IDs for each IBC client.
However, there is no validation about "clients/{identifier}/connections" for now.

IBC VP has to check if a new connection ID is stored for the corresponding client when the connection is created.

┆Issue is synchronized with this Asana task by Unito

PoS - slashing tests

Add tests for slashes applied from the base ledger

┆Issue is synchronized with this Asana task by Unito

add conditional compilation for serde in the shared crate

┆Issue is synchronized with this Asana task by Unito

wallet improvements

A temporary "wallet" module in is being added in anoma/anoma#160. This works for testing & playnet, but before a public testnet, we'll need to add a real wallet.

One option is using https://github.com/AleoHQ/wagyu, which has support for HD wallet, mnemonics and network signing

┆Issue is synchronized with this Asana task by Unito

wallet address look-ups in client results

For client commands that print out some outputs that include bech32m encoded address(es), it would be nice to try to reverse look-up these from the wallet's address book and show the aliases instead when available. For this, we might want to switch the address book in the wallet::store from regular HashMap to a bijective map (e.g. https://crates.io/crates/bimap)

┆Issue is synchronized with this Asana task by Unito

IBC connection to other chains

we should aim to try to setup connection 3 others chains (Bridge to Near, Ethereum, Flow, Polkadot)

┆Issue is synchronized with this Asana task by Unito

Make sure we support Tendermint fast sync and make it a node option

We should support fast sync, which is very convenient for syncing a node quickly, and expose it clearly through the CLI and/or configuration, although we should also include warnings about proof-of-stake security considerations.

┆Issue is synchronized with this Asana task by Unito

replace validator in Tendermint node from `init-validator` tx

Currently, after creating a new validator account on-chain with the init-validator tx, it is necessary to manually restart the ledger node for Tendermint to use the new validator key.

We could allow the node to automatically pick up a newly created validator with init-validator, write it to Tendermint's dir and restart the Tendermint process. We should be able to re-use whatever approach we use for consensus key change in #36.

┆Issue is synchronized with this Asana task by Unito

PoS - add validation tests

add tests for the validation function

┆Issue is synchronized with this Asana task by Unito

Tx/VP prefix iter should include keys from write log

The prefix iterator for Tx and VP posterior state should also iterate over the storage keys from write log. Currently, they only iterate over the keys committed to the storage, but replace any overwritten values from write log.

┆Issue is synchronized with this Asana task by Unito

design and doc MASP integration

Start with a exploration/design doc for MASP integration

┆Issue is synchronized with this Asana task by Unito

Randomize `storage.address_gen` with the chain ID

we should add the chain id to have unique address on different chains

Originally posted by tzemanovic in anoma/anoma-archive#175 (comment)

┆Issue is synchronized with this Asana task by Unito

tune/customize rocksdb compression

Currently, for each block we persist the full state. For historical blocks, we could explore using delta compression to reduce redundancy, without affecting the current block's data look-ups.

┆Issue is synchronized with this Asana task by Unito

use an enum with `ToPrimitive` for the tx result codes using `num-derive` and `num-traits`

Let's use an enum with ToPrimitive for the TxResult codes (currently in apps/src/lib/node/ledger/shims/abcipp_shim_types.rs) using num-derive and num-traits.

┆Issue is synchronized with this Asana task by Unito

cli: allow to set default arguments from config

We should replace e.g. the hard-coded default --ledger-address with the one from the config file

┆Issue is synchronized with this Asana task by Unito

refactor `TxResult` event

We only need to have the "applied.hash" field separately for the tendermint query when we're waiting for tx result in the client. For everything else, we should serialize the whole TxResult into a single field, so we can use the same type in the client to decode it.

Currently we're doing this manually in impl From<serde_json::Value> for TxResponse { in apps/src/lib/client/tx.rs and in fn finalize_block in apps/src/lib/node/ledger/shell.rs

┆Issue is synchronized with this Asana task by Unito

add ledger storage snapshots

https://docs.tendermint.com/v0.35/spec/abci/apps.html#taking-snapshots

It would be handy to have some commands for exporting and importing snapshots

┆Issue is synchronized with this Asana task by Unito

PoS - validator set update tests

add tests for validator set updates applied from the base ledger

┆Issue is synchronized with this Asana task by Unito

improve the storage key/key segments interface

We'd like to have a nicer interface for dealing with storage keys in wasm. It should be easy to construct keys from segments and we should allow to panic on key construction failures, which is fine to do from inside transactions and VPs.

Furthermore, it would be nice if we can provide const functions (https://doc.rust-lang.org/reference/const_eval.html#const-functions).

The VM host functions that deal with storage (read, write, has_key, delete, iter) currently work on a String as a storage key, which is then parsed into Key. We should just use Key type in these directly.

┆Issue is synchronized with this Asana task by Unito

parallel VP runs and gas accounting

We might want to set e.g. maximum parallelism to some reasonable value that would be part of the minimum recommended spec for validator hardware.

The gas accounting formulae for parallelized VPs runs should then be adjusted, so that the parallelized runs are discounted only for the number of runs up to this limit (we currently take the full gas from the VP that used the most gas and divide the rest by a constant).

┆Issue is synchronized with this Asana task by Unito

PoS transaction tests

Add tests for the PoS transaction WASMs using the tests crate, which provides access to tx host env and wasm tx_prelude.

With the tests, we can remove or replace the log_string calls in tx_bond, tx_unbond and tx_withdraw with a debug_log!, which will be compiled away in release built WASM.

┆Issue is synchronized with this Asana task by Unito

Wrapper tx replay protection

As noted in https://github.com/anoma/anoma/blob/625bab46c32da6aeb35418869974bfb1ac98cd3e/docs/src/specs/ledger.md: "DKG transactions will include replay protection (this is because we can simply check a counter against the source (i.e. gas payer) of the transaction before the transactions order is committed to by the DKG protocol, which could affect the expected counter order for sources with multiple queued transactions)".

We should add reply protection to the wrapper tx. This can simply be a counter in implicit accounts that is checked and incremented by the wrapper transactions.

┆Issue is synchronized with this Asana task by Unito

PoS validator consensus key change

Add a tx and update PoS validity predicate to allow validators to change consensus key

NOTE: how do we update this in tendermint? We currently using the key file on disk. The key change on-chain will happen in a future epoch, so we'd need to update the file at the right time.

┆Issue is synchronized with this Asana task by Unito

PoS staking rewards

Add staking rewards. These should be credited to validators' staking accounts (see anoma/anoma#636)

Spec: https://specs.namada.net/economics/proof-of-stake/reward-distribution.html

The input into the rewards distributions depends on #340

Add more randomness to address generator

In apps/src/bin/anoma-node/vm/host_env/write_log.rs, when we generate a new address, we should give it some unpredictable value as an additional source of randomness

Originally posted by tzemanovic in anoma/anoma-archive#175 (comment)

┆Issue is synchronized with this Asana task by Unito

remaining release automation tasks

• bump wasm / wasm_for_tests
• update wasm checksums file

┆Issue is synchronized with this Asana task by Unito

Tune RocksDB configuration

For now, I just want something usable for our upcoming testnet, so I'm cutting this short until after that, but there is a lot of tuning that can be done with RocksDB. In particular, the default settings tend to assume cases very much unlike ours.

┆Issue is synchronized with this Asana task by Unito

make clearer distinction between init-network source file and the genesis file

We use a source network TOML config to setup a network (using the init-network cmd). This file drives few different things:

• genesis file for the ledger
• config file for the ledger and intent gossiper
• global config file with the chain ID set to the created network's ID
• a setup directory for each genesis validator and one for all the other accounts that do not belong to any validator with:
  • genesis file for the ledger
  • config file for the ledger and intent gossiper
  • global config file with the chain ID set to the created network's ID
  • a wallet with generated addresses and keys (public keys can also be set in the source file, in which case we don't generate new ones)

This source network file is currently in the genesis module and we refer to it as "source genesis file" in some places, which is a bit confusing. We should refactor it out from the genesis module and give it a clearer name. Perhaps e.g. "network template".

┆Issue is synchronized with this Asana task by Unito

improve the bonds query

The anomac bonds --validator <validator-alias> command without the --owner argument doesn't include delegations, it only shows self-bonds. To include delegations we'll need to use a prefix iterator query to find them.

┆Issue is synchronized with this Asana task by Unito

default validator VP

related to anoma/anoma#47

Add a default validator VP which should be used for the genesis validators. We still need to hash out a bit more details on how we'll reuse code in wasm, for now any logic (which is minimal) can be in-lined into the source.

Steps

• add a validator VP source (can just be a new directory copied from vp_template)
• store validator's tendermint public key in storage
• in the VP, disallow to change the public key (this is temporary, later we can allow to change the key when authorized)
• attach the built wasm to genesis validator(s)

┆Issue is synchronized with this Asana task by Unito

slimmer wasm build

It looks that some dependencies (even when unused) end-up bloating the built wasm size, so we should investigate if we can remove some unnecessary dependencies from them (specifically, anything from the transitive deps from the shared crate imported via vm_env and now vp_prelude/tx_prelude crates).

┆Issue is synchronized with this Asana task by Unito

tx to update public key

add a tx that allows established accounts to update their on-chain public key

┆Issue is synchronized with this Asana task by Unito

PoS - refactor the crate's API

Consider refactoring the PoS crate's main API, which currently provides traits for the transaction and base ledger integrations.

┆Issue is synchronized with this Asana task by Unito

add `secp256k1` support

add secp256k1 crypto support to the wasm host env

┆Issue is synchronized with this Asana task by Unito

Build script: only use rustfmt for tonic build if it’s available

The build.rs scripts in apps and shared currently require rustfmt to build tonic, so the build fails if it’s not installed. This is not necessary, we should only enable this if rustfmt is available.

┆Issue is synchronized with this Asana task by Unito

storage hash cons values

Allow to hash cons' storage to remove redundancy. The obvious one is the accounts' validity predicates, which currently take most of the space. We might want to use it for other things too in future, but probably not all the storage values would benefit from it.

Related issue anoma/anoma#285.

┆Issue is synchronized with this Asana task by Unito

implicit account VP

Add a VP for implicit account addresses. This should be used for all the implicit accounts (related to anoma/anoma#186)

┆Issue is synchronized with this Asana task by Unito

add checksums for built release archives

The make package recipe could also create SHA256 of the archive, which can then be released together with the archive (e.g. shasum -a 256 $(package-name).tar.gz > $(package-name).sha256

┆Issue is synchronized with this Asana task by Unito

Standardise log outputs and make them condensed by default

Currently it seems like we mix formatted log output, log output from Tendermint in a different format, and miscellaneous print messages:

I[2021-10-25|10:18:00.287] committed state                              module=state height=13440 num_txs=0 app_hash=E433406CBD85E394DD2DB6033EAAF6F40FF56D0B4FEEFB6B78204E33605E4D7E
I[2021-10-25|10:18:00.287] Indexed block                                module=txindex height=13440
Oct 25 10:18:00.331  INFO abci{addr=127.0.0.1:58638}:consensus: anoma::ledger::storage: Began a new epoch 1344
skipping validator update, still the same atest1v4ehgw36x9pnjdfsgsmnydzyx5uy2sesg4q5gden8ymnzv3kx5mngvehgs6yy3pjxc6nj32pjm8shc
skipping validator update, still the same atest1v4ehgw36xvcrxs3sgc6yyd2rx4z5vvpcgymr2d2yxdpngwpkxu65vwfkgdqnqsjzxymnzs2y0a0mxw
skipping validator update, still the same atest1v4ehgw36xdry2dp3g4prgsfkgsuyxdeng9pyg32xxqe5vvfjgg6rzsekxcmngdjxx4zn2wfez5h708
skipping validator update, still the same atest1v4ehgw36x5unyvf4xvur2vejg3pnw3zpx4rr2de4g5crjd34gerryve4ggm5v3fcgc65vdp5sh0zxy
skipping validator update, still the same atest1v4ehgw36xce5vvfcg5myvd6ygy6nss2xxgu5zdp3xsuyvvph8ppy23fkgcuyxd34gy6nsdehttyeve
skipping validator update, still the same atest1v4ehgw36xu6nxw298yenwdpngymy2wpcxdrrzvj9x9zyzse3xv65zs3kxgunsd2z8yenxvekv4llte
skipping validator update, still the same atest1v4ehgw36xumyz33nxsmrwwfk8ppngv3hggc5y3p4xcmrxse4xc6ygdp3gscrww2yxuunysehx5zcwy
skipping validator update, still the same atest1v4ehgw36gvcrys34g9prv3jxgg6rqwpkgse5ywf4xdrrjdf489rrz3jrxgurwvzzg9zrgd33qcg2vg
skipping validator update, still the same atest1v4ehgw36gdzrzv6xxcer2s3sx4pyvs3cxsm5g33ngfryxwfcxq6nz3zxxep52v29xpz523psjm29yp
skipping validator update, still the same atest1v4ehgw36g3q5xsjxg3z5x3zzx3qnvd3kg4zrvwpjxcenjv6rgscn2wzzxgen2vecxfq5zvj9fn29wf
I[2021-10-25|10:18:00.375] executed block                               module=state height=13441 num_valid_txs=0 num_invalid_txs=0
Oct 25 10:18:00.380  INFO abci{addr=127.0.0.1:58638}:consensus: anoma_apps::node::ledger::shell: Committed block hash: 14e44f84e2da759bcf705e677bdd097c03593cd504fa9bf6d874b3ebfec2a524, height: 13441
I[2021-10-25|10:18:00.423] committed state                              module=state height=13441 num_txs=0 app_hash=14E44F84E2DA759BCF705E677BDD097C03593CD504FA9BF6D874B3EBFEC2A524
I[2021-10-25|10:18:00.423] Indexed block                                module=txindex height=13441
I[2021-10-25|10:18:00.515] executed block                               module=state height=13442 num_valid_txs=0 num_invalid_txs=0
Oct 25 10:18:00.518  INFO abci{addr=127.0.0.1:58638}:consensus: anoma_apps::node::ledger::shell: Committed block hash: 14e44f84e2da759bcf705e677bdd097c03593cd504fa9bf6d874b3ebfec2a524, height: 13442
I[2021-10-25|10:18:00.559] committed state                              module=state height=13442 num_txs=0 app_hash=14E44F84E2DA759BCF705E677BDD097C03593CD504FA9BF6D874B3EBFEC2A524
I[2021-10-25|10:18:00.559] Indexed block                                module=txindex height=13442
I[2021-10-25|10:18:00.651] executed block                               module=state height=13443 num_valid_txs=0 num_invalid_txs=0
Oct 25 10:18:00.656  INFO abci{addr=127.0.0.1:58638}:consensus: anoma_apps::node::ledger::shell: Committed block hash: 14e44f84e2da759bcf705e677bdd097c03593cd504fa9bf6d874b3ebfec2a524, height: 13443

I suggest that we do either of the following:

1. Capture the Tendermint logs, parse them, and reformat them in the Rust standardised format, or
2. Write the two log outputs (from Rust, and from Tendermint) to separate output files

Separately, we should:

1. Turn the print messages into standard log outputs, and
2. Ensure that different levels of granularity in debugging information match up with log levels, which should be settable by a flag when running anoma ledger (or anything else), and
3. By default, hide most log messages and perhaps even use \r to rewrite the last line in a sort of live condensed mode.
   Consider what Zcash does:

┆Issue is synchronized with this Asana task by Unito

PoS validator deactivation + reactivation

add transactions and update PoS validity predicate for validator deactivation + reactivation

┆Issue is synchronized with this Asana task by Unito

Add command to rollback a single block

TM 0.34.14 added a rollback command: tendermint/tendermint#7033 that can be used to recover from diverging app hashes (common after a node crashes), but it's useless unless the app state is also rolled back by one block.

┆Issue is synchronized with this Asana task by Unito

PoS - refactor validation function of the validity predicate

Depends on #16 and #12 .

Refactor the validation function into smaller functions

┆Issue is synchronized with this Asana task by Unito

IBC design doc

Design IBC integration with Anoma

┆Issue is synchronized with this Asana task by Unito

PoS add re-delegation

Add a transaction for re-delegation (using a version with longer delay, which has to wait for unbonding epoch, but simpler to implement than faster re-delegation).

impl depends on #124

Remove PoS VP `panic::catch_unwind`

Depends on #12, anoma/anoma#435 and #17

Remove the temporary measure in apps/src/lib/node/ledger/protocol/mod.rs and UnwindSafe + RefUnwindSafe impls in shared/src/ledger/pos/vp.rs that runs the PoS VP in a new thread to catch panics.

┆Issue is synchronized with this Asana task by Unito

PoS - genesis initialization tests

Test the genesis block initialization of PoS data

┆Issue is synchronized with this Asana task by Unito