Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This is intended to guide you in selecting SGX compliant hardware for Secret Network.
This is not a comprehensive list of compliant hardware, but rather a guide for what has been verified to work. This list is often show as SGX compliant, but it does not discriminate against whether SGX is supported via SPS or Intel ME. Only SGX via SPS is supported.
CPU must support SGX via SPS. CPUs that only support SGX via Intel ME will not work.
The following are confirmed compliant Intel CPUs:
Only Intel processors support SGX. AMD processors are *NOT* supported.
List of Processors that Support Intel® Software Guard Extensions
The distinguishing factor of these motherboards is that they support Intel SGX.
This is not an exhaustive list of supported motherboards. These are simply motherboards proven supported by community members.
Brand | Family | Model |
---|---|---|
Brand | Tag | Versions | Link |
---|---|---|---|
Intel
XEON E-Series
E-2174G
E-2176G
E-2178G
E-2186G
E-2188G
E-2274G
E-2276G
E-2278G
E-2286G
E-2288G
E-2334G
E-2386G
E-2388G
XEON Gold-Series
*NOT SUPPORTED*
AMD
*NOT SUPPORTED*
Supermicro
X11SCM-F
SYS-5019C-M
, SYS-5019C-MR
X11SCW-F
SYS-5019C-WR
X11SCZ-F
X11SSL-F
Dell
Dell R240
BIOS Version 2.14.1
Dell R350
BIOS version 1.7.3
HP
DL20 G10
BIOS version 1.80_07-20-2023
DL20 G10 +
ASUS
ASUS RS100-E10-PI2
BIOS version 5601
Asrock
E3C246D4U2-2T
GIGABYTE
MX33-BS1-V1
BIOS version F06
This is intended to guide you in selecting SGX-compliant VPS options for the Secret Network.
When renting a compliant bare metal machine from a VPS provider, ensure you do not accept any chassis or CPU substitutes they propose, unless those substitutes are on the Hardware Compliance list.
All cost estimates are based on the following recommendations:
Processor: E-series rather than E3 (due to age)
SSD: 512GB+
RAM: 64GB+
Just because a VPS is cheaper it does not make it better.
Leaseweb has been tested and confirmed working by the Secret Network community.
Ensure that Hyperthreading/Logical Processors & overclocking/undervolting are disabled in the bios.
Everything that you need to setup a validator from picking the right hardware to getting a validator up and running.
This section covers the hardware setup, as well as setting up a node for mainnet or testnet and creating a validator if needed.
This chapter gives you an insight of what you need to run a node in Secret Network. Since Secret Network uses Intel SGX, nodes have to fulfill special requirements.
VPS Provider | Cost/month | Setup Instructions |
---|---|---|
Website:
Rent a with any of the hardware that shows as working on the
I
Continue with the node setup guide
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
CPU compilant with SGX (see )
Motherboard with support for SGX in the BIOS (see )
CPU compilant with SGX (see )
Motherboard with support for SGX in the BIOS (see )
TBD
144
95
89
185
210
144
Hetzner
*NOT SUPPORTED*
160
X1 (Professional Line)
Website: phoenixNAP
Rent a VPS from them with any of the hardware that shows as working on the Hardware Compliance list.
Ensure that Hyperthreading & overclocking/undervolting are disabled in the bios.
Continue with the node setup guide starting here.
Alternatively, Eddie from FreshSCRTs is helping users expedite the delivery of their VPS as well as giving some upgrades from phoenixnap. You can pursue that by doing the following.
Signup for phoenixnap using this link.
Message Eddie your order number on telegram.
Website: psychz
Things to note before setting up on Psychz:
Only certain CPU's are available with setup
You need to manually Open the BIOS and select the configuration.
Ensure your hardware meets the Hardware Compliance requirements.
This takes about 1 day, you may need to make sure they have the servers, if they do not make sure you request only the same configuration or the SGX wont be enabled.
Make sure you request them to install the Latest BIOS for the SGX to work
The Dashboard portal is only enabled once you signup. Go to your device section. Go to IPMI (remote management) and create a session to log into the BIOS, I used the Java to download and connect to the BIOS over the port. You need to make sure Hyper Threading is disabled in the BIOS so that you can get an ok platform message.
Login with your credentials and proceed with SGX installation.
Go to their dedicated hosts/ Bare Metal services section and rent a Intel E-2286G Processor (6 cores / 12 threads @ 4.0 GHz)
Using the Boot Connection log into the BIOS and Ensure that Hyperthreading & overclocking/undervolting are disabled in the bios.
Things to note before setting up on Nforce.
Only certain chasis and CPU configuration have SGX enabled.
You need to manually communicate with Nforce to give you the right configuration so that SGX works on the BIOS.
For the purpose of this Guide i selected the HP DL20 G10 Chasis. For the CPU i slected the Intel E2174G (3.8-4.7 Ghz, 4C/8T)
With 32 GB ram, Ubuntu OS 20.04, and 512 GB SSD.
This takes about 1 day, you may need to make sure they have the servers, if they do not make sure you request only the same configuration or the SGX wont be enabled.
The SSC portal is only enabled once you finish the payment. Go to your dedicated servers and select the image. Go to remote management and create a session to log into the BIOS via IPMI. You'll need to make sure Hyper Threading is disabled.
Currently, it is advised to exercise caution when considering OVHCloud servers, as there are concerns regarding the inadequate updating of their mainboards.
Please contact the node support in case you got more questions:
Navigate to the server's management page
Under General Information, ensure SGX is enabled
3. Navigate to the IPMI tab. This will be used to disable overclocking and other necessary settings.
4. Enable Remote KVM
5. Create a DEL hotkey
6. Reset the server, and continue executing the DEL hotkey until you enter the BIOS.
7. Disable Intel Speedstep Technology
8. Under Chipset Configuration:
9. Save and Exit the bios
10. Reset the server again
Website:
Continue with the node setup guide
Website:
Login with your credentials and proceed with .
Websites: or
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
The following are examples of servers:
Example in the US:
Global example:
OVHCloud servers can come with either an ASUS or Asrock motherboard. The Asus motherboard does NOT support Intel SPS. If you receive the Asus motherboard, you'll need to create a ticket to have the motherboard replaced with the Asrock motherboard:
11. Continue from
Website: Microsoft Azure
Using Azure is not recommened anymore as of now because of higher pricing than bare-metals and not enough RAM (32GB is possible to use, but not recommended anymore).
When renting a compliant bare metal machine from a VPS provider, ensure you do not accept any chassis or CPU substitutes they propose, unless those substitutes are on the Hardware Compliance list.
Microsoft Azure is tested and confirmed working by the Secret Network Community.
To setup a node on Microsoft Azure do the following.
Visit the Azure Confidential Compute page here and click "Get Started"
Click "Get it now" on the following page and signup for a Microsoft Azure Account.
While provisioning your VPS be sure to have at least 500GB of premium SSD storage available.
After your confidential compute VM is deployed, continue with the node setup guide starting here.
In this section we quickly explain what the verification process for your hardware entails and how it works. Instructions for verification are included in the setup guides!
Attestation Certificate
This is a self-signed X.509 certificate that contains a signed report by Intel, and the SGX enclave. The report contains both a report that the enclave is genuine, a code hash, and a signature of the creator of the enclave.
Seed
this is a parameter that is shared between all enclaves on the network in order to guarantee deterministic calculations. When a node authenticates successfully, the network encrypts the seed and shares it with the node. Protocol internals are described here
This section will explain node registration in the Secret Network. If you just care about installation you can just follow the setup guides and ignore this document. If, however, you want to learn more about what's going on behind the scenes here read on.
In order to verify that each node on the Secret Network is running a valid SGX node, we use a process that we call registration. Essentially, it is the process of authenticating with the network.
The process is unique and bound to the node CPU. It needs to be performed for each node, and you cannot migrate registration parameters between nodes. The process essentially creates a binding between the processor and the blockchain node, so that they can work together.
For this reason, the setup will be slightly more complex than what you might be familiar with from other blockchains in the Cosmos ecosystem.
The registration process is made up of three main steps:
Enclave verification with Intel Attestation Service - this step creates an attestation certificate that we will use to validate the node
On-chain network verification - Broadcast of the attestation certificate to the network. The network will verify that the certificate is signed by Intel, and that the enclave code running is identical to what is currently running on the network. This means that running an enclave that is differs by 1 byte will be impossible.
Querying the network for the encrypted seed and starting the node
At the end of this process (if it is successful) the network will output an encrypted seed (unique to this node), which is required for our node to start. After decryption inside the enclave, the result is a seed that is known to all enclaves on the network, and is the source of determinism between all network nodes.
For a deeper dive into the protocol see the protocol documentation
Registration instructions are included in the Mainnet and Testnet Setup guides!
Nodes on Secret Network are required to be fully patched, and compliant with network requirements. While this requirement makes running a node and maintaining it harder, it is a necessary tradeoff that needs to be done if the network is to remain open and permissionless.
Part of the registration process on the network will validate the patch level of your platform (Motherboard + CPU). This requires your to have the necessary updates that mitigate known vulnerabilities that might lead to compromise of data protected by SGX.
Let's start with the different components that need to be updated -
Processor microcode (ucode) - Microcode is a type of low-level computer programming that is used to control the operations of a microprocessor. It is typically stored in the microprocessor itself or in a read-only memory (ROM) chip that is connected to the microprocessor. Microcode is used to define the basic set of instructions that a microprocessor can execute, as well as the operations that it can perform on data. It is usually written in a specialized microcode programming language, and it forms the lowest level of a computer's instruction set architecture.
SGX Platform Software (PSW) - This software package provides a set of tools and libraries to make use of the Intel SGX instruction set
The PSW packages can be updated using your standard operating system install methods. For example, in Linux do this:
While there are a few ways to update the processor microcode, it is important to note that for SGX, the updated microcode must be loaded through the BIOS. That means that upgrading the microcode using early load or late load (installing through the operating system) will not affect the SGX patch level of the platform.
To find out whether the microcode needs to be updated and find the latest version, we must first get the family, model, and stepping of our processor.
To find the stepping, model, and family of your processor, you can use the lscpu
command. This command displays detailed information about the CPU architecture.
Open a terminal window on your system and type the following command:
2. The output of this command will include the stepping, model, and family of your processor, as well as other information about the CPU architecture.
Here is an example of the output you might see:
In this example, the family, model and stepping of the processor are 6, 85, and 3, respectively.
Next, we take these values and translate them to hex and structure them as follows: <family>-<model>-<stepping>. In this example we get: 06-55-03
. This is our microcode file name for our processor.
Pro Tip: These numbers also allow us to get our CPUID, in the following order:
|model 1st digit|family|model 2nd digit|stepping|
. For example, 06-9e-0d -> 906ED
After we have our microcode file name, we use it to find the latest version of our microcode, which is available here: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md. Continuing the previous example, the latest version of microcode for 06-55-03
is 0x0100015e
Now that we know what our microcode should be, we can compare it to our current microcode. Get your current version with:
cat /proc/cpuinfo | grep microcode
or dmesg | grep microcode
Note - On Azure machines will always return 0xFFFFFFFF as their microcode version regardless of the actual patch level
If your version does not match the latest one, you will need to update your BIOS. To do that, contact your motherboard vendor, or your cloud service provider and download or request the BIOS version that contains the latest microcode for your CPU.
This section will take you through the process of taking a node from fresh machine to full validator on the public testnet pulsar-3.
This section will take you through the process of taking a node from fresh machine to full validator. The general steps are as follows:
If you're running a local machine and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Set to "YES", it's not enough to set it to "software controlled")
Disable Secure Boot
Disable Hyperthreading
Note: sgx_linux_x64_driver_2.11.0_2d2b795.bin
is the latest driver as of August 24th, 2021. Please check under https://download.01.org/intel-sgx/sgx-linux/ that this is still the case. If not, please send us a PR or notify us.
If you are a node runner all you must do to install SGX is to save this as a script and run it.
Download the SGX install script.
Execute the script.
secretd init-enclave
To uninstall the Intel(R) SGX Driver, run:
The above command produces no output when it succeeds. If you want to verify that the driver has been uninstalled, you can run the following, which should print SGX Driver NOT installed
:
To uninstall the SGX SDK, run:
To uninstall the rest of the dependencies, run:
(or SCRT_ENCLAVE_DIR=/usr/lib secretd init-enclave | grep -Po 'isvEnclaveQuoteStatus":".+?"'
)
An outtput like this should be generated:
(or isvEnclaveQuoteStatus":"SW_HARDENING_NEEDED"
)
Where the important fields are isvEnclaveQuoteStatus and advisoryIDs. This is are fields that mark the trust level of our platform. The acceptable values for the isvEnclaveQuoteStatus
field are:
OK
SW_HARDENING_NEEDED
With the following value accepted for testnet only:
GROUP_OUT_OF_DATE
For the status CONFIGURATION_AND_SW_HARDENING_NEEDED
we perform a deeper inspection of the exact vulnerabilities that remain. The acceptable values for mainnet are:
"INTEL-SA-00334"
"INTEL-SA-00219"
If you do not see such an output, look for a file called attestation_cert.der
which should have been created in your $HOME
directory. You can then use the command secretd parse <path/to/attestation_cert.der>
to check the result a successful result should be a 64 byte hex string (e.g. 0x9efe0dc689447514d6514c05d1161cea15c461c62e6d72a2efabcc6b85ed953b
.
Running secretd init-enclave
should have created a file called attestation_cert.der
. This file contains the attestation report from above.
Contact us on the proper channels on scrt.network/discord
The details we will need to investigate will include:
Hardware specs
SGX PSW/driver versions
BIOS versions
The file attestation_cert.der
Output is:
Make sure you have the environment variable SCRT_ENCLAVE_DIR=/usr/lib
set before you run secretd
.
Output is:
Make sure the directory ~/.sgx_secrets/
is created. If that still doesn't work, try to create /root/.sgx_secrets
Output is:
Make sure the aesmd-service
is running systemctl status aesmd.service
Output is:
Please disable hyperthreading and overclocking/undervolting (Turboboost) in your BIOS.
I'm seeing CONFIGURATION_AND_SW_HARDENING_NEEDED
in the isvEnclaveQuoteStatus
field, but with more advisories than what is allowed
This could mean a number of different things related to the configuration of the machine. Most common are:
["INTEL-SA-00161", "INTEL-SA-00233"] - Hyper-threading must be disabled in the BIOS
["INTEL-SA-00289"] - Overclocking/undervolting must be disabled by the BIOS (sometimes known as Turboboost)
["INTEL-SA-00219"] - Integrated graphics should be disabled in the BIOS - we recommend performing this step if you can, though it isn't required
If you are still having trouble getting rid of INTEL-SA-00219 and INTEL-SA-00289, here are some possible settings to look for outside of the CPU settings:
Primary Display = 'PCI Express'
IGPU Multi-Monitor = Disabled
Onboard VGA = Disabled
I'm seeing SGX_ERROR_DEVICE_BUSY
Most likely you tried reinstalling the driver and rerunning the enclave - restarting should solve the problem
Ensure your hardware is .
See for a guide how to test your setup.
Consult with the for more on these values.
Ensure your hardware is Hardware Compliance.
If you're running a local machine and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Set to "YES", it's not enough to set it to "software controlled")
Disable Secure Boot
Disable Hyperthreading
Make sure the SGX driver is installed. The following devices should appear:
If your kernel version if 5.11 or higher, then you probably already have the SGX driver installed. Otherwise - please update the kernel version. Also make sure that the user under which the node is supposed to run has privileges to access SGX:
First, you need to add the Intel repository to APT:
For Ubuntu 20.04, use this:
For Ubuntu 22.04, use this repository:
Next, install the necessary SGX libraries:
If your system has 5th Gen Intel® Xeon® Scalable Processor(s)
For the DCAP attestation to work, you'll need to register your platform with Intel. This is achieved by the following:
You can check the file /var/log/mpa_registration.log
, to see if the platform is registered successfully.
The Quote Provider library is needed to provide the data for DCAP attestation.The configuration file for it should can be found here:
/etc/sgx_default_qcnl.conf
If you're running a physical machine
The simplest would be to use the PCCS run by SCRTLabs. Modify the following parameters in the file:
You can set those parameters by the following command:
Cloud VPS providers
For cloud VPS providers, the cloud service providers may provide their own PCCS. Please see their documentation for more infomation.
Note: You'll need to restart the AESMD service each time the configuration is changed
Download and run the check-hw tool (included in the Release package). You should see the following:
That would mean all the above steps are ok, and you're good to go.
In case you see some error messages, but at the end the following:
That would mean there's a problem with DCAP attestation.
However the EPID attestation still works. Although you may technically run the node, it's strongly recommended to fix this. The EPID will be phased-out by Intel on April 2025.
To get a more detailed error info, run check-hw --testnet
Unlike other Tendermint/Cosmos based daemons, secretd
cannot be built from source due to the SGX requirement. For other builds other than .deb
, see the Secret Network Github Releases.
secretd
The most common method for install secretd
is the Secret Network package installer for Debian/Ubuntu:
This section will take you through the process of taking a node from fresh machine to full validator. The general steps are as follows:
`secretcli` is the Secret Network light client, a command-line interface tool for interacting with nodes running on the Secret Network. To install it, follow these instructions:
In order to become a validator, you node must be fully synced with the network. You can check this by doing:
This is the secret
wallet which you used **** to create your full node, and will use to delegate your funds to you own validator. You must delegate at least 1 SCRT (1000000uscrt) from this wallet to your validator.
If you get the following message, it means that you have no tokens, or your node is not yet synced:
(remember 1 SCRT = 1,000,000 uSCRT, and so the command below stakes 100 SCRT).
You should see your moniker listed.
(remember 1 SCRT = 1,000,000 uSCRT)
In order to stake more tokens beyond those in the initial transaction, run:
Currently deleting a validator is not possible. If you redelegate or unbond your self-delegations then your validator will become offline and all your delegators will start to unbond.
You are currently unable to modify the --commission-max-rate
and --commission-max-change-rate"
parameters.
Modifying the commision-rate can be done using this:
Unjailing
To unjail your jailed validator
Signing Info
To retrieve a validator's signing info:
Query Parameters
You can get the current slashing parameters via:
Query Parameters
You can get the current slashing parameters via:
This document details how to join the Secret Network testnet
as a full node. Once your full node is running, you can turn it into a validator in the optional last step.
Secret Network has strict Hardware Requirements. If your machine does not meet them, it will *NOT* work as a node.
Ubuntu/Debian host (with ZFS or LVM to be able to add more storage easily)
A public IP address
Open ports TCP 26656 & 26657
Note: If you're behind a router or firewall then you'll need to port forward on the network device.
secretd
Choose a moniker for yourself, and replace <MONIKER>
with your moniker below. This moniker will serve as your public nickname in the network.
This will generate the following files in ~/.secretd/config/
genesis.json
node_key.json
priv_validator_key.json
genesis.json
The genesis file is how other nodes on the network know what network you should be on.
Initialize /opt/secret/.sgx_secrets
:
You can choose between two methods, 3a (automatic) or 3b (manual):
WARNING: This method is experimental, and may not work. If it doesn't work, skip to step 3b.
The following commands will create the necessary environment variables and attempt to automatically register the node.
Attestation certificate should have been created by the previous step
Verify the certificate is valid. A 64 character registration key will be printed if it was successful.
secretd
Configure secretd
. Initially you'll be using the bootstrap node, as you'll need to connect to a running node and your own node is not running yet.
If you already have a wallet funded with SCRT
, you can import the wallet by doing the following:
Otherwise, you will need to set up a key. Make sure you back up the mnemonic and the keyring password.
Register your node on-chain
2. Pull & check your node's encrypted seed from the network
3. Get additional network parameters
These are necessary to configure the node before it starts.
From here on, commands must be ran on the full node.
In order to be able to handle NFT minting and other Secret Contract-heavy operations, it's recommended to update your SGX memory enclave cache:
minimum-gas-price
ParameterWe recommend 0.0125uscrt
per gas unit:
Your node will not accept transactions that specify --fees
lower than the minimun-gas-price
you set here.
secret-node
:Note that the secret-node
system file is created when installing sgx.
You are now a now ready to finally sync the full node. 🎉.
secretd tendermint show-node-id
And publish yourself as a node with this ID:
Be sure to point your CLI to your running node instead of the bootstrap node
secretcli config node tcp://localhost:26657
If someone wants to add you as a peer, have them add the above address to their persistent_peers in their ~/.secretd/config/config.toml.
And if someone wants to use your node from their secretcli then have them run:
or the node
If you wish to create an archive node, replace step 3 with .
Get the latest release of secretcli for your OS .
You can find alternate node endpoints in the , or run your own
See more details on how to use the CLI
When the value of catching_up
is false, your node is fully sync'd with the network. You can speed up syncing time by to the current block.
Copy/paste the address to get some test-SCRT from . Continue when you have confirmed your account has some test-SCRT in it.
Reading
RPC address of an already active node. You can use http://bootstrap.pulsar3.scrtlabs.com:26657
, or any other node that exposes RPC services. Alternate RPC nodes available in the
This guide assumes you've already installed the latest version of secretd and SGX. To setup an archive node, you must follow the instructions.
For more information on SGX, see instructions for and . See if you'd like a more comprehensive overview on what's happening in these steps.
If this step was successful, you can skip straight to .
The following steps should use secretd
be ran on the full node itself. To run the steps with secretd
on a local machine, there.
This will output your address, a 45 character-string starting with secret1...
. Copy/paste it to get some test-SCRT from . Continue when you have confirmed your account has some test-SCRT in it.
Also checkout by [ block pane ]
for fine tuning your machine for better uptime.
Go to to continue.
You can skip syncing from scratch or download a snapshot by to the current block.
To turn your full node into a validator, see .
Unlike other Tendermint/Cosmos based daemons, secretd
cannot be built from source due to the SGX requirement.
For other builds other than .deb
, see the Secret Network Github Releases.
secretd
The most common method for installing secretd
is the Secret Network package installer for Debian/Ubuntu:
Ensure your hardware is Secret Node Compliant.
If you're running a local machine or bare-metal and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Software controlled is not enough)
Disable Secure Boot
Disable Hyperthreading (recommended)
If you are a node runner all you must do to install SGX is to save this as a script and run it.
Copy of raw script.
secretd init-enclave
See Verify SGX for a guide how to test your setup.
To uninstall the Intel(R) SGX Driver, run:
The above command produces no output when it succeeds. If you want to verify that the driver has been uninstalled, you can run the following, which should print SGX Driver NOT installed
:
To uninstall the SGX SDK, run:
To uninstall the rest of the dependencies, run:
This document details how to join the Secret Network secret-4
mainnet as a full node. Once your full node is running and synced to the last block, you can use it
Secret Network has strict Hardware Requirements, see Hardware Compliance. If your machine does not meet them, it will *NOT* work as a node.
Ubuntu/Debian host, recommended is Ubuntu 20.04 LTS or 22.04 LTS.
A public IP address, so that other nodes can connect to you.
Open ports TCP 26656 & 26657
Note: If you're behind a router or firewall then you'll need to port forward on the network device.
RPC address of an already active node. You can use any node that exposes RPC services, please see API Endpoints Mainnet (Secret-4).
secretd
This guide assumes you've already installed the latest version of secretd and SGX.
For more information on how to install SGX, see instructions for Install SGX.
If you need help with installing secretd, please take a look at Install secretd.
Choose a moniker for yourself, and replace <MONIKER>
with whatever name you like (could be some random string, or just how you like to name to node) below. This moniker is your public nickname of the node in the network.
This will generate the following files in ~/.secretd/config/
genesis.json
node_key.json
priv_validator_key.json
genesis.json
Initialize /opt/secret/.sgx_secrets
:
You can choose between two methods, automatic or manual:
WARNING: This method is experimental, and may not work. If it doesn't work, skip to manual registration.
The following commands will create the necessary environment variables and attempt to automatically register the node.
If this step was successful, you can skip straight to Optimization.
The attestation certificate should have been created by the previous step
Verify the certificate is valid. A 64-character registration key will be printed if it was successful.
If registration was NOT succesfull consider checking out the Registration troubleshoot help or contact a fellow validator on our discord.
secretd
The following steps should use secretd
be ran on the full node itself. To run the steps with secretd
on a local machine, set up the CLI there.
Configure secretd
. Initially you'll be using the bootstrap node, as you'll need to connect to a running node and your own node is not running yet.
If you already have a wallet funded with SCRT
, you can import the wallet by doing the following:
Otherwise, you will need to set up a key. Make sure you back up the mnemonic and the keyring password.
This will output your address, a 45 character-string starting with secret1...
.
Register your node on-chain
2. Pull & check your node's encrypted seed from the network
3. Get additional network parameters
These are necessary to configure the node before it starts.
From here on, commands must be ran on the full node.
In order to be able to handle NFT minting and other Secret Contract-heavy operations, it's recommended to update your SGX memory enclave cache:
Also checkout this document by block pane
for fine tuning your machine for better uptime.
minimum-gas-price
ParameterWe recommend 0.1uscrt
per gas unit:
Your node will not accept transactions that specify --fees
lower than the minimun-gas-price
you set here.
IAVL fast node must be disabled, otherwise the daemon will attempt to upgrade the database whil state sync is occuring.
secret-node
:Note that the secret-node
system file is created when installing sgx.
You are now a now ready to finally sync the full node. 🎉.
Go to Statesync or Quicksync / Snapshot to continue.
To sync to head quickly, please see Quicksync / Snapshot.
You can skip syncing from scratch or download a snapshot by Statesync to the current block.
secretd tendermint show-node-id
And publish yourself as a node with this ID:
Be sure to point your CLI to your running node instead of the bootstrap node
secretcli config node tcp://localhost:26657
If someone wants to add you as a peer, have them add the above address to their persistent_peers in their ~/.secretd/config/config.toml.
And if someone wants to use your node from their secretcli then have them run:
To turn your full node into a validator, see Joining Mainnet as a Validator.
After you completed these steps, you can check this by doing:
When the value of catching_up
is false, your node is fully sync'd with the network and ready to go.
This is the secret
wallet which you used **** to create your full node, and will use to delegate your funds to you own validator. You must delegate at least 1 SCRT (1000000uscrt) from this wallet to your validator.
If you get the following message, it means that you have no tokens, or your node is not yet synced:
WARNING: if you don't backup your key and your node goes down, you will lose your validator and have to start a new one.
Remember 1 SCRT = 1,000,000 uSCRT, and so the command below stakes 10 SCRT
You should see your moniker listed.
(remember 1 SCRT = 1,000,000 uSCRT)
In order to stake more tokens beyond those in the initial transaction, run:
Currently deleting a validator is not possible. If you redelegate or unbond your self-delegations then your validator will become offline and all your delegators will start to unbond.
You are currently unable to modify the --commission-max-rate
and --commission-max-change-rate"
parameters.
Modifying the commision-rate can be done using this:
To unjail your jailed validator
To retrieve a validator's signing info:
You can get the current slashing parameters via:
Snapshots are compressed folders of the database to reach the current block quickly.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your priv_validator_key.json
prior to running the command. The command does not wipe the file. However, you should have a backup of it already in a safe location.
All of the above steps can also be done manually if you wish.
Reset your node.
This will ensure you connect to peers quickly.
Statesync is a module built into the Cosmos SDK to allow validators to rapidly join the network by syncing your node with a snapshot enabled RPC from a trusted block height.
This greatly reduces the time required for a node to sync with the network from days to minutes. The limitations of this are that there is not a full transaction history, just the most recent state that the state-sync RPC has stored. An advantage of state-sync is that the database is very small in comparison to a fully synced node, therefore using state-sync to re-sync your node to the network can help keep running costs lower by minimizing storage usage.
By syncing to the network with state-sync, a node can avoid having to go through all the upgrade procedures and can sync with the most recent binary only.
First, adjust the configuration to be compatible with state-sync:
IAVL fast node must be disabled, otherwise the daemon will attempt to upgrade the database whil state sync is occuring.
To ensure that state-sync works on your node, it has to look for the correct snapshots that the snapshot RPC provides.
SNAP_RPC is the RPC node endpoint that is used for statesyncing
Set the state-sync BLOCK_HEIGHT
and fetch the TRUST_HASH
from the snapshot RPC. The BLOCK_HEIGHT
to sync is determined by finding the latest block that's a multiple of snapshot-interval.
The output should be similar to:
This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
prior to running unsafe-reset-all
.
It is recommended to copy the signing state of the node by coping data/priv_validator_state.json
and only running unsafe-reset-all
to avoid potential double signing.
The code below stops the node, resets the temporary directory and resets the node into a fresh state.
When state-sync fails, you can restart the process and try again using the condensed script below. This usually fixes some of the random problems with it:
To safe time, you can use this script to quickly init everything you need for statesync. Please be aware that this might be dangerous if you have a validator.
becoming a validator?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
In order to become an active validator, you must have more stake than the . You may still execute the following steps, but you will not be active and therefore won't receive staking rewards.
In order to become a validator, you node must be fully synced with the network, using either the or .
Before creating your validator,
You can either chose to use the or do it with the
Quicksync / snapshots are provided by .
using state-sync properly?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
A complete to go command that should fit most needs can be found at . Be aware that this script can also fail or cause problems. In that case please ask for help in the channels above.
This documentation assumes you have followed the instructions for .
using statesync properly?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
This generally takes several minutes to complete, but has been known to take up to 24 hours. To better help the process along, add .
`secretcli` is the Secret Network light client, a command-line interface tool for interacting with nodes running on the Secret Network. To install it, follow these instructions:
Get the latest release of secretcli for your OS HERE.
Mac/Windows: Rename it from secretcli-${VERSION}-${OS}
to secretcli
or secretcli.exe
and put it in your path
Ubuntu/Debian: sudo dpkg -i secret*.deb
Linux and MacOS users:
You can find alternate node endpoints in the API registry, or run your own full node\
See more details on how to use the CLI here
Note: This documentation assumes you have followed the instructions for Running a Full Node for Testnet.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
and config/node_key.json
prior to running unsafe-reset-all
.
The state-sync configuration in ~/.secretd/config/app.toml
is as follows:
SNAP_RPC
variable to a snapshot RPCSet the state-sync BLOCK_HEIGHT
and fetch the TRUST_HASH
from the snapshot RPC. The BLOCK_HEIGHT
to sync is determined by finding the latest block that's a multiple of snapshot-interval.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
and config/node_key.json
prior to running unsafe-reset-all
.
It is recommended to copy data/priv_validator_state.json
to a backup and restore it after unsafe-reset-all
to avoid potential double signing.
This generally takes several minutes to complete, but has been known to take up to 24 hours.