- Introduction
- Use cases
- Integrations currently live
- Binary Installation
- Run a node
- Creating a pool with the runtime
This runtime validates and archives blocks from any tendermint based blockchain application. It only stores blocks from and to a given height and makes them available to directly download them from the storage provider, or directly sync them into the blockchain nodes itself, therefore enabling block sync via validated KYVE blocks.
Since storage pools which use this runtime archive validated and historical blocks blockchain nodes can use those archived blocks to bootstrap themselves and sync to the current network height. This may make expensive archival nodes obsolete since those blocks are already permanently and immutably archived. Additionally, block data can be retrieved over an ELT pipeline, further analyzing and using it for different applications like block explorers.
This runtime requires the node operator to run a tendermint node which is used as the source and the KYVE protocol node. Depending on which tendermint chain gets archived the minimum hardware requirements are at least the min requirements of that tendermint node.
The following integrations are running on this runtime and are currently live.
(planned - currently in test)
- Pool ID: 0
- Chain ID: cosmoshub-4
- Base Height: 5200791
- Cosmos Hub // cosmoshub-4
- Pool ID: 24
- Chain ID: cosmoshub-4
- Base Height: 5200791
This section explains how to install a protocol node with this runtime. This is only relevant for protocol node operators who want to run a node in a pool which has this runtime.
The first option to install the binary is to build it from source. For that you have to execute the following commands:
git clone [email protected]:KYVENetwork/kyvejs.git
cd kyvejs
If you want to build a specific version you can checkout the tag and continue from the version branch. If you want to build the latest version you can skip this step.
git checkout tags/@kyvejs/[email protected] -b x.x.x
After you have cloned the project and have the desired version the dependencies can be installed and the project build:
yarn install
yarn setup
Finally, you can build the runtime binaries.
INFO: During the binary build log warnings can occur. You can safely ignore them.
cd integrations/tendermint-bsync
yarn build:binaries
You can verify the installation with printing the version:
./out/kyve-linux-64 version
After the build succeeded you can find the binaries in the out
folder where you can move them to use
desired location (like KYSOR).
You can find all prebuilt binaries in the releases of the kyvejs repository. For this specific runtime they can be found here.
You can verify the installation with printing the version:
./kyve-linux-64 version
Once you have downloaded the binary for the correct platform and version you can simply unzip them and move them to your desired location (like KYSOR).
This section explains which runtime specific setup you must have in order to run a node. This is only relevant for protocol node operators who have already installed the binary (previous section) and want to run a node in a pool which has this runtime.
Depending on the integration which are currently live the following setup has to be done.
INFO: This pool archives the current Cosmos Hub (Chain Id: cosmoshub-4) from block 5,200,791 to the current block (~14M).
Every protocol node runner will run their own Cosmos Hub blockchain node as a data source. This ensures that the data which is getting proposed and validated actually comes from decentralized sources. Furthermore, since the gaia blockchain node only serves valid blocks we further increase the validation of this data. With that setup a user who wants to join this pool first has to sync his gaia node to the current height the pool has already archived the blocks and then start the actual KYVE protocol node.
This architecture diagram summarizes the setup of the Cosmos Hub integration on KYVE:
Here this runtime is responsible for communicating with the tendermint application (purple) - in this case gaia, and forwarding the data to the KYVE core protocol. The KYVE core then handles the communication with the pool. This entire process (yellow) is the KYVE protocol node. The resulting data are the blocks from the tendermint application - validated and permanently stored on a storage provider like Arweave.
The following minimum hardware requirements have to be met:
- RAM: 16GB
- Storage: 512GB*
*This can increase over time
The first step is to start an archival gaia node. For that the gaia binary with the version v4.2.1
has
to be installed. You can follow the official installation instructions here or download the binary directly from here.
You can verify the successful installation with
./gaiad version
4.2.1
In order to setup the gaia config first choose a moniker and init gaia:
./gaiad init <your-moniker> --chain-id cosmoshub-4
To install the genesis file execute the following command:
wget https://raw.githubusercontent.com/cosmos/mainnet/master/genesis/genesis.cosmoshub-4.json.gz
gzip -d genesis.cosmoshub-4.json.gz
mv genesis.cosmoshub-4.json ~/.gaia/config/genesis.json
Peers can be added via this addrbook which can be retrieved here:
wget https://dl2.quicksync.io/json/addrbook.cosmos.json
mv addrbook.cosmos.json ~/.gaia/config/addrbook.json
chmod 666 ~/.gaia/config/addrbook.json
TIP: You can also add persistent_peers from Polkachu to ensure that you will actually find peers where you can sync with the network: https://polkachu.com/live_peers/cosmos
For pruning the following settings are recommended to decrease the disk usage:
~/.gaia/config/config.toml
[tx_index]
indexer = "null"
~/.gaia/config/app.toml
pruning = "everything"
index-events = [""]
Finally, the node can be started:
NOTE: For some users it might be required to increase the limit of open files on your system with ulimit -n 65536
INFO: Since the genesis file is quite big (over 100MB) the starting process can take a serveral minutes before the node starts to sync blocks.
./gaiad start --x-crisis-skip-assert-invariants
Now you have to sync blocks until the latest summary of the pool is reached. For example if the latest pool summary is 6,000,000 you can check if the node has synced the blocks until that height with:
curl http://localhost:26657/block?height=6000000
If it returns a valid block response you can continue with starting the actual KYVE protocol node and start participating in the validation and archival process.
TIP: to save storage space you can start pruning blocks manually after they have been archived by the pool since after that they are not needed anymore.
TIP: to make it easier during chain upgrades we also recommend running the chain with cosmosvisor. You can find official instructions here
The remaining installation of the KYVE protocol node is the same for every other protocol node. You can now follow the official docs starting from here
The Binaries of this runtime with which to join the pool can be found here: https://github.com/KYVENetwork/kyvejs/releases?q=tendermint-bsync
This section explains how you can create a storage pool on KYVE with this specific runtime. This is only relevant for users or projects, who are interested in archiving and validating a new data source.
This runtime requires the following config format in order to run:
{
"network": "CHAIN_ID_OF_INTEGRATION",
"rpc": "https://rpc-endpoint-of-integration:26657"
}
Here the properties have the following reason:
network
: the chain ID of the network. This is a check to verify that only blocks from this network are validated and archived. The runtime rejects blocks that do not match with this IDrpc
: the default rpc endpoint of the network to collect blocks from. This should only be a base URL without a trailing slash. This can be a public rpc endpoint from a dedicated provider or an URL pointing to localhost in order to signal that every protocol node has to host their own blockchain node
This config should then be stringified on the pool and should look like this:
{
"config": "{\"network\":\"CHAIN_ID_OF_INTEGRATION\",\"rpc\":\"https://rpc-endpoint-of-integration:26657\"}"
}
With this setup the runtime is able to run. Furthermore an optional environment variable can be set to override the default rpc endpoint (rpc
).
export KYVEJS_TENDERMINT_BSYNC_RPC="https://my-custom-rpc-endpoint:26657"
In order to create a pool it has to go through the Governance process (more on that can be found here). An example proposal with which a storage pool with this runtime could be created can be found below:
{
"messages": [
{
"@type": "/kyve.pool.v1beta1.MsgCreatePool",
"authority": "kyve10d07y265gmmuvt4z0w9aw880jnsr700jdv7nah",
"name": "<your pool name>",
"runtime": "@kyvejs/tendermint-bsync",
"logo": "ar://<your logo stored on arweave>",
"config": "<your config like described above>",
"start_key": "<the initial height of the tendermint chain>",
"upload_interval": "120", // 120s is the recommended value
"operating_cost": "<your base bundle reward>", // for example 1000000 if the base reward per bundle should be 1 $KYVE
"min_delegation": "<your required min delegation", // for example 1000000000 if the pool should only run if more than 1000 $KYVE are bonded in this pool
"max_bundle_size": "100", // 100 blocks per bundle is the recommended value
"version": "<runtime version>", // the current version of this runtime
"binaries": "{\"kyve-linux-arm64\":\"<linux-arm64 binary download URL>\",\"kyve-linux-x64\":\"<linux-x64 binary download URL>\",\"kyve-macos-x64\":\"<macos-x64 binary download URL>\"}", // download URLs of binaries for KYSOR
"storageProviderId": "1", // Arweave is the recommended storage provider
"compressionId": "1" // Gzip is the recommended bundle compression
}
],
"metadata": "<your ipfs metadata info>", // gov proposal metadata
"deposit": "<your deposit>ukyve" // proposal deposit, check the required min deposit
}
Once your proposal is ready you can submit it to the network. Please follow the official governance process to increase the chances of getting your proposal accepted.