Skip to content

Kwil Staging and Development Network

Jump to bottom
jchappelow edited this page Oct 4, 2024 · 29 revisions

WARNING: This page is presently out-of-date as the network was just migrated to different hosts. I intend to migrate back.

This page describes our production-like test environment, which is meant to be a staging area that closely resembles an actual production environment. In particular, this means:

  • multiple geographically distributed nodes
  • a mix of validators and sentry nodes
  • actual utilization (both continuously at some relatively tame pace, and under higher load from interactive developer testing)

OK, just show me how to connect as a peer node or use the end-user RPC service.

Deployed Version

v0.9.1-pre

Motivation

This network has just gotten going, and there is not yet continuous deployment or automatic updating with every change that passes CI, however even manually deploying new revisions of kwild (or kgw) has benefits:

  • Reproducibility of Production Issues. Combining a live network with the stress tool in various configurations (slow and aggressive), we can catch issues that would otherwise slip past our acceptance and integration tests.
  • Quick Feedback Loop. We can catch unexpected breaking changes early. e.g. upgrading existing nodes and re-adding sentry nodes will fail if we unintentionally change consensus-critical code or parameters.
  • Performance Testing. With a realistic network scenario (multiple geographically distributed datacenters), and typical cloud VMs, we can get a better idea of what utilization patterns are actually feasible and when performance issues and resource limitations appear.
  • Security Hardening. We might not realize there are even very trivially-exploitable security issues and DoS vulnerabilities if the services are never exposed to internet traffic until release.
  • Building Confidence. Releasing to production shouldn't be a blind leap, and a functional network that has survived many updates should give us assurances that we can release without major issue.

I have used GitHub webhooks in the past to do automatic updating of such service on merge to main/master, but I suspect that we would only apply automatic updating to a small set of sentry nodes. Updating the validator nodes and some of the other nodes are likely to be simple but manual tasks for now as we get a feel for how network upgrades will proceed in practice.

Accessing as an End User

NOTE: Gas is enabled on this network presently. You will need to get funds from the faucet at http://23.20.126.14:3000/ You may then transfer funds between accounts with the kwil-cli account transfer command. See the account balance command as well.

Use the network via the JSON-RPC service on port 8484.

We have added a KGW instance, but the nodes' RPC services are currently accessible directly. KGW is accessible for testing at https://kgw-dev.kwil.com/.

Joining as a Sentry Node

Currently there are two nodes listening on their public interfaces, allowing anyone to join the network as a non-validator (sentry node). This setup is how most public blockchain networks operate, and although we are currently focusing on more controlled deployment scenarios it is helpful to:

  • allow developers to join and sync freely for testing
  • allow the nodes to face potential abuses that they are likely to experience in production, which includes low level DoS issues to more Kwil- or Tendermint-specific attacks

To join the network, it is necessary to edit your config.toml and genesis.json files. You MUST also either use statesync (chain.p2p.statesync.enable = true) PR download the genesis state archive and point to it in your config.toml's app.genesis_state setting

config.toml

genesis_state

Download the genesis state, put it in a secure location on your node's host machine, and specify the location:

genesis_state = "/data/migration2/snapshot.sql.gz"

seeds

We now use the seeds setting to connect instead of the persistent_peers to connect. Edit your config and remove persistent_peers and add:

seeds = "03717d5317c76941f2b05738343fdddc3f932141@23.20.126.14:16656"

For reference you are likely to see connections with the following nodes:

  • 643af2a0462cea175047c4b8a18817dd9429bb0b@23.20.126.14:26656
  • a914373b223faab3a3045d249fd2ddc54a449419@3.72.232.3:26656

Timeouts

This is probably only important config if the joining node wishes to be a validator, but here are the timeouts used on the validator nodes:

[chain.consensus]

# How long we wait for a proposal block before prevoting nil
timeout_propose = "3s"

# How long we wait after receiving +2/3 prevotes for “anything” (ie. not a single block or nil)
timeout_prevote = "2s"

# How long we wait after receiving +2/3 precommits for “anything” (ie. not a single block or nil)
timeout_precommit = "2s"

# How long we wait after committing a block, before starting on the new
# height (this gives us a chance to receive some more precommits, even
# though we already have +2/3).
timeout_commit = "6s"

genesis.json

Use exactly this in your genesis.json:

{
  "genesis_time": "2024-10-04T07:08:44.198555318Z",
  "chain_id": "kwil-chain-21",
  "initial_height": 0,
  "app_hash": "hhJRal2WVBjva6Um/HNFR+wYJuF5QcKbTG5+PX+9aYw=",
  "activations": null,
  "consensus_params": {
    "block": {
      "max_bytes": 6291456,
      "max_gas": -1,
      "abci_max_bytes": false
    },
    "evidence": {
      "max_age_num_blocks": 100000,
      "max_age_duration": 172800000000000,
      "max_bytes": 1048576
    },
    "version": {
      "app": 0
    },
    "validator": {
      "pub_key_types": [
        "ed25519"
      ],
      "join_expiry": 14400
    },
    "votes": {
      "vote_expiry": 14400,
      "max_votes_per_tx": 100
    },
    "abci": {
      "vote_extensions_enable_height": 0
    },
    "without_gas_costs": false
  },
  "validators": [
    {
      "pub_key": "997ccd99f95ae68327609938b62201caad61227bb3c5e04e0bedf529d5e306c9",
      "power": 1,
      "name": "validator-0"
    }
  ]
}
Clone this wiki locally