Lava Deployer - Setup Tool

👾 dApps & Projects
1

Authors: GLCstaked
Date: 16/02/24

Overview

This is intended to be an interactive setup tool for deploying lava node or lava provider.

Lava node: deployment of full node with or without cosmovisor and with wallet options.

Lava provider: a full provider setup including the deployment of a full-node for rpc provision, with various node options for selection, and the full setup of nginx (node side), provider configurations & stake.

GitHub Link: https://github.com/GLCNI/RPC-node-deployments

Project folder: lava-deployer

Rationale

Inspired by nethermind sedge, a tool I use frequently for deploying Ethereum full nodes with ease.

The reason is the technical barrier to deploying provider nodes is very high, getting a provider live and working, requires many steps:

  • Deploy a full node: and configure it to be open to external API requests, not enabled by default.

  • Setup and configure NGINX for sub-domain routing: this is itself a technical challenge

  • Connect to a Lava chain node: you can use the public RPC, but it’s recommended to run your own which adds more steps.

  • Setup Provider: this itself is difficult to configure and has many steps on its own, it must also integrate with other components and can be a challenge.

For Lava Network to really decentralise access to full nodes, in both demand (consumers) and supplier side (node providers), the technical barrier to entry must be reduced as much as possible. As it stands most providers are highly technical service providers, such as those in cosmos (active) validator sets.

Ethereum has the most decentralized node set in part due to the amount of tools that reduce the technical barrier to setting up an Ethereum full node + validator such as (Nethermind Sedge, Eth Docker, DappNode, Stereum, and many more). Most nodes outside of Ethereum are generally not easy to setup, let alone configure for external API requests.

Description:

Basic steps:

  1. Select node: deploy node locally with APIs enabled, using snapshot to sync

  2. Setup nginx: Sets up NGINX for selected node and walk through sub-domain creation for service.

  3. Node checks before starting provider steps: lava node connection/node sync/nginx setup

  4. Setup provider: configure lava wallet > stake provider > configure provider to node type > start provider service with node service selected and nginx configured.

Snapshot: intended to use snapshot where possible to speed up node deployment.

Example

Example 1
Example 11430×809 6.95 KB

Example 2

Example 2
Example 21412×551 28.8 KB

Progress

Node templates: completed but adding over time

Nodes supported now: Cosmos, Osmosis, Arbitrum, StarkNet

Nginx: completed

Node checks before provider: completed

Provider: in progress

I have deployed providers before and struggled to keep up with changes and correct configurations, this is probably the difficult part and could use support.

Improvements: (still working on)
Add more guidance/interactive help for NGINX setup, as some of this is external and could use more explanation.

General structure and process, such as taking into consideration syncing nodes and time for DNS to propagate.

Prunning settings for nodes and compatibility for rpc provision (using snapshot to setup).

Help Needed:

Any suggestions on the above, feedback help with testing.

Adding support for more nodes and maintaining node deployment scripts, it’s a lot to keep up with and I can only realistically support a few node types, sometimes a version update will not be as simple as updating the version number.

2 Likes
2

@GLCstaked

I’ve said this before… but this is phenomenal work. :tada: :fire:

The present standard in our ecosystem is that these install scripts for various nodes are spread around different validators pages and follow vastly different formats. I think one major contribution this makes is having them in a centralized place that is open-source and allows for edits and fixes.

Adding support for more nodes and maintaining node deployment scripts, it’s a lot to keep up with and I can only realistically support a few node types

Aside from getting some team members and community members eyes on this, I’m going to endeavor to rally a few validators to see if they may want to contribute to the list of supported chains. IMHO, many of them already have scripts that they could modify and submit as PRs to your project.

Great Work! Excited to see future developments… :volcano: :volcano: :volcano: