Skip to content

Latest commit

 

History

History
254 lines (182 loc) · 7.88 KB

getting-started.md

File metadata and controls

254 lines (182 loc) · 7.88 KB

Getting Started

The Solana git repository contains all the scripts you might need to spin up your own local testnet. Depending on what you're looking to achieve, you may want to run a different variation, as the full-fledged, performance-enhanced multinode testnet is considerably more complex to set up than a Rust-only, singlenode testnode. If you are looking to develop high-level features, such as experimenting with smart contracts, save yourself some setup headaches and stick to the Rust-only singlenode demo. If you're doing performance optimization of the transaction pipeline, consider the enhanced singlenode demo. If you're doing consensus work, you'll need at least a Rust-only multinode demo. If you want to reproduce our TPS metrics, run the enhanced multinode demo.

For all four variations, you'd need the latest Rust toolchain and the Solana source code:

First, install Rust's package manager Cargo.

$ curl https://sh.rustup.rs -sSf | sh
$ source $HOME/.cargo/env

Now checkout the code from github:

$ git clone https://github.com/solana-labs/solana.git
$ cd solana

The demo code is sometimes broken between releases as we add new low-level features, so if this is your first time running the demo, you'll improve your odds of success if you check out the latest release before proceeding:

$ TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
$ git checkout $TAG

Configuration Setup

The network is initialized with a genesis ledger and fullnode configuration files. These files can be generated by running the following script.

$ ./multinode-demo/setup.sh

Drone

In order for the fullnodes and clients to work, we'll need to spin up a drone to give out some test tokens. The drone delivers Milton Friedman-style "air drops" (free tokens to requesting clients) to be used in test transactions.

Start the drone with:

$ ./multinode-demo/drone.sh

Singlenode Testnet

Before you start a fullnode, make sure you know the IP address of the machine you want to be the bootstrap leader for the demo, and make sure that udp ports 8000-10000 are open on all the machines you want to test with.

Now start the bootstrap leader in a separate shell:

$ ./multinode-demo/bootstrap-leader.sh

Wait a few seconds for the server to initialize. It will print "leader ready..." when it's ready to receive transactions. The leader will request some tokens from the drone if it doesn't have any. The drone does not need to be running for subsequent leader starts.

Multinode Testnet

To run a multinode testnet, after starting a leader node, spin up some additional full nodes in separate shells:

$ ./multinode-demo/fullnode-x.sh

To run a performance-enhanced full node on Linux, CUDA 10.0 must be installed on your system:

$ ./fetch-perf-libs.sh
$ SOLANA_CUDA=1 ./multinode-demo/bootstrap-leader.sh
$ SOLANA_CUDA=1 ./multinode-demo/fullnode-x.sh

Testnet Client Demo

Now that your singlenode or multinode testnet is up and running let's send it some transactions!

In a separate shell start the client:

$ ./multinode-demo/client.sh # runs against localhost by default

What just happened? The client demo spins up several threads to send 500,000 transactions to the testnet as quickly as it can. The client then pings the testnet periodically to see how many transactions it processed in that time. Take note that the demo intentionally floods the network with UDP packets, such that the network will almost certainly drop a bunch of them. This ensures the testnet has an opportunity to reach 710k TPS. The client demo completes after it has convinced itself the testnet won't process any additional transactions. You should see several TPS measurements printed to the screen. In the multinode variation, you'll see TPS measurements for each validator node as well.

Testnet Debugging

There are some useful debug messages in the code, you can enable them on a per-module and per-level basis. Before running a leader or validator set the normal RUST_LOG environment variable.

For example

  • To enable info everywhere and debug only in the solana::banking_stage module:

    $ export RUST_LOG=solana=info,solana::banking_stage=debug

  • To enable BPF program logging:

    $ export RUST_LOG=solana_bpf_loader=trace

Generally we are using debug for infrequent debug messages, trace for potentially frequent messages and info for performance-related logging.

You can also attach to a running process with GDB. The leader's process is named solana-fullnode:

$ sudo gdb
attach <PID>
set logging on
thread apply all bt

This will dump all the threads stack traces into gdb.txt

Public Testnet

In this example the client connects to our public testnet. To run validators on the testnet you would need to open udp ports 8000-10000.

$ ./multinode-demo/client.sh --network $(dig +short testnet.solana.com):8001 --duration 60

You can observe the effects of your client's transactions on our dashboard

Linux Snap

A Linux Snap is available, which can be used to easily get Solana running on supported Linux systems without building anything from source for evaluation. Note that CUDA is not supported by the Snap so performance will be limited.

The edge Snap channel is updated daily with the latest development from the master branch. To install:

$ sudo snap install solana --edge --devmode

Once installed the usual Solana programs will be available as solona.* instead of solana-*. For example, solana.fullnode instead of solana-fullnode.

Update to the latest version at any time with:

$ snap info solana
$ sudo snap refresh solana --devmode

Daemon Support

The snap supports running fullnodes and a drone as system daemons.

Run sudo snap get solana to view the current daemon configuration. To view daemon logs:

  1. Run sudo snap logs -n=all solana to view the daemon initialization log
  2. Runtime logging can be found under /var/snap/solana/current/bootstrap-leader/, /var/snap/solana/current/fullnode/, or /var/snap/solana/current/drone/ depending on which mode= was selected. Within each log directory the file current contains the latest log, and the files *.s (if present) contain older rotated logs.

Disable the daemon at any time by running:

$ sudo snap set solana mode=

Runtime configuration files for the daemon can be found in /var/snap/solana/current/config.

Leader Daemon

$ sudo snap set solana mode=bootstrap-leader

rsync must be configured and running on the leader.

  1. Ensure rsync is installed with sudo apt-get -y install rsync
  2. Edit /etc/rsyncd.conf to include the following
[config]
path = /var/snap/solana/current/config
hosts allow = *
read only = true
  1. Run sudo systemctl enable rsync; sudo systemctl start rsync
  2. Test by running rsync -Pzravv rsync://<ip-address-of-leader>/config solana-config from another machine. If the leader is running on a cloud provider it may be necessary to configure the Firewall rules to permit ingress to port tcp:873, tcp:9900 and the port range udp:8000-udp:10000

To run both the Leader and Drone:

$ sudo snap set solana mode=bootstrap-leader+drone

Validator daemon

$ sudo snap set solana mode=fullnode

By default the node will attempt to connect to testnet.solana.com, override the cluster entrypoint IP address by running:

$ sudo snap set solana mode=fullnode entrypoint-ip=127.0.0.1 #<-- change IP address

It's assumed that the node at the entrypoint IP will be running rsync configured as described in the previous Leader daemon section.