Welcome to the second part of our tinkering journey where we discuss governance mechanism, various types of proposals and learn how to stake, earn rewards and unbond your precious NAM tokens.

If you haven’t had a chance to explore the first part yet, you can find it at this link. It explains the basics that are very usefull to better understand what we are going to discuss next.

Let’s submit a proposal

Governance is a decentralized way to intoroduce changes to the chain, suggestions on how spend funds from the community pool or airdrop tokens to valuable members of the community. This is achieved via proposal mechanism.

Anyone can submit a general proposal to the chain if they are ready to freeze 500 NAM tokens for the proposal voting period. In the event that the proposal is approved or declined, 500 NAM will be returned to your wallet. However, if the proposal is considered as a spam, your tokens will be permanently removed (burnt).

Anyone with a positive NAM balance can vote for a proposal or mark it as a spam. The weight of your voice is proportional to the amount of tokens you have bonded ( discussed later ). So your influence on the protocol’s future grows with the increase in the number of tokens you possess.

Let’s see how it works by actually submitting a spam proposal, it’s a testnet after all! Export proposal properties into variables:

export PROPOSAL_TITLE="How to burn 500 NAM tokens" && \
export PROPOSAL_AUTHORS="hello@2pilot.dev" && \
export PROPOSAL_DISCUSSIONS_TO="Just voices in my head" && \
export PROPOSAL_CREATED="2024-01-01T00:00:01Z" && \
export PROPOSAL_LICENSE="MIT" && \
export PROPOSAL_ABSTRACT="Spam proposal" && \
export PROPOSAL_MOTIVATION="Because I can" && \
export PROPOSAL_DETAILS="I'll probably get slashed for that" && \
export PROPOSAL_AUTHOR="tnam1qzq77j54tpsry9ctmft9gh38j3r7wanprvjr0hs7" && \
export VOTING_START_EPOCH=798 && \
export VOTING_END_EPOCH=804 && \
export GRACE_EPOCH=810

Most of the properties like title, authors, details are self explanatory, let’s focus on the most interesting ones

PROPOSAL_AUTHOR address that you have access to and want to create a proposal from. This address should have 500 NAM tokens in possession.

VOTING_START_EPOCH — epoch when the voting will start. keep in mind it should be greater than the current epoch and multiply of 3, for example 3, 6, 9 .. etc

to check the current epoch you can run

namada client epoch

VOTING_END_EPOCH — deadline for voting for proposal. Also should be multiply of 3 and greater than VOTING_START_EPOCH

GRACE_EPOCH — epoch when proposal if passed, it’s suggested changes will come into effect. should be VOTING_END_EPOCH + 6 or more

To submit a proposal we need a json file with the following structure:

{
	"proposal": {
		"content": {
			"title": "One Small Step for Namada, One Giant Leap for Memekind",
			"authors": "bengt@heliax.dev",
			"discussions-to": "forum.namada.net/t/namada-proposal/1",
			"created": "2069-04-20T00:04:44Z",
			"license": "MIT",
			"abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All memers are welcome to join.",
			"motivation": "When you think about it, the moon isn't actually that far away.The moon is only 384,400 km. We have not yet brought Namada to the moon, so it is only natural to use 101 as the prime number for our modular arithmetic operations. 384,400 (mod 101) = 95. 95 km is a distance that can be easily covered by a single person in a single day. Namada was produced by more than 100 people. So 95/100 = 0, rounded to the nearest integer. This means that Namada can reach the moon in no time.",
			"details": "Bringing Namada to the moon in no time is easily achievable. We just need to pass this governance proposal and set the plan in action",
			"requires": ""
		},
		"author": "atest1v4ehgw36g9zyydzpgycy23phxuunxdesgc6nydfsxge5x3zzgscny32pxccn2wfjg5urx3fhzxhmch",
		"voting_start_epoch": 21,
		"voting_end_epoch": 24,
		"grace_epoch": 27,
		"type": {
			"Default": null
		}
	}
}

We already exported all of it’s variables into properties, so let’s create it ( Don’t forget to update PROPOSAL_AUTHOR, VOTING_START_EPOCH, VOTING_END_EPOCH, GRACE_EPOCH variables with your own data)

echo '{
    "proposal" :{
        "content": {
            "title": "'"$PROPOSAL_TITLE"'",
            "authors": "'"$PROPOSAL_AUTHORS"'",
            "discussions-to": "'"$PROPOSAL_DISCUSSIONS_TO"'",
            "created": "'"$PROPOSAL_CREATED"'",
            "license": "'"$PROPOSAL_LICENSE"'",
            "abstract": "'"$PROPOSAL_ABSTRACT"'",
            "motivation": "'"$PROPOSAL_MOTIVATION"'",
            "details": "'"$PROPOSAL_DETAILS"'"
        },
        "author": "'"$PROPOSAL_AUTHOR"'",
        "voting_start_epoch": '"$VOTING_START_EPOCH"',
        "voting_end_epoch": '"$VOTING_END_EPOCH"',
        "grace_epoch": '"$GRACE_EPOCH"',
        "type": {
            "Default": null
        }
    } 
}' > proposal.json

Once it’s created let’s submit a proposal to the chain

namadac init-proposal --data-path proposal.json

If there were no errors during the process anyone can find your proposal by quering

namada client query-proposal

We can see some basic information like proposal id, type, author, epoch, but no details on what this proposal is acutally suggesting. To get more info about the proposal you can run

namada client query-proposal --proposal-id 0

Just use proposal id you are actually interested in. In my case it was 0

Great, we can see all details about the proposal. Note that status is currently in pending state. This is because start epoch is 798 and we are currently on epoch 796. At epoch 798 you can see that status has changed to on-going.

once it finishes the status will be marked as ended

Should we wait some time to observe the impact our outstanding proposal has made on the world?

Since this proposal didn’t introduce any changes and was simply a spam proposal, nothing had changed after its conclusion.

The proposal we submited is called Default proposal and you can actually change network parameters with it by providing extra data parameter to the proposal json which should contain path to wasm code.

"data" : "<path/to/wasm.wasm>"

What could be changed ? Quite a lot:

• you can increase or decrease minimum NAM deposit required for creating a proposal
• number of validators in the active set
• inflation rates and much more

Next let’s try different kind of proposal called Pgf steward

Becoming a steward

Steward is a community elected entity that could be a group of people represented by multisignature account or a single person. Once a steward is elected it will be able to submit proposals to the public goods funding (PGF) pool. In other words, steward has a right to airdrop tokens from PGF pool to the selected number of addresses if his proposal will be accepted by the community.

Let’s prepare our porposal:

export PROPOSAL_TITLE="2pilot for Steward for life" && \
export PROPOSAL_AUTHORS="hello@2pilot.dev" && \
export PROPOSAL_DISCUSSIONS_TO="Me myself and I all agreed on nominating 2pilot for Steward" && \
export PROPOSAL_CREATED="2024-01-01T00:00:01Z" && \
export PROPOSAL_LICENSE="MIT" && \
export PROPOSAL_ABSTRACT="2pilot for Steward for life" && \
export PROPOSAL_MOTIVATION="There are no other candidates currently so I should win !" && \
export PROPOSAL_DETAILS="2pilot should be a good and worthy steward" && \
export PROPOSAL_AUTHOR="tnam1qzq77j54tpsry9ctmft9gh38j3r7wanprvjr0hs7" && \
export STEWARD_ADDRESS=$PROPOSAL_AUTHOR && \
export VOTING_START_EPOCH=807 && \
export VOTING_END_EPOCH=810 && \
export GRACE_EPOCH=816

As you might have noticed, there haven’t been many changes from the previous proposal parameters. We only have the STEWARD_ADDRESS variable, which serves as our nominee. It should be equal to the PROPOSAL_AUTHOR And of course there are some updates to the epoch parameters.

Let’s create new proposal file and call it steward_proposal.json

echo '{
    "proposal" :{
        "content": {
            "title": "'"$PROPOSAL_TITLE"'",
            "authors": "'"$PROPOSAL_AUTHORS"'",
            "discussions-to": "'"$PROPOSAL_DISCUSSIONS_TO"'",
            "created": "'"$PROPOSAL_CREATED"'",
            "license": "'"$PROPOSAL_LICENSE"'",
            "abstract": "'"$PROPOSAL_ABSTRACT"'",
            "motivation": "'"$PROPOSAL_MOTIVATION"'",
            "details": "'"$PROPOSAL_DETAILS"'"
        },
        "author": "'"$PROPOSAL_AUTHOR"'",
        "voting_start_epoch": '"$VOTING_START_EPOCH"',
        "voting_end_epoch": '"$VOTING_END_EPOCH"',
        "grace_epoch": '"$GRACE_EPOCH"'
    },
    "data" : 
        {
            "add" : "'"$STEWARD_ADDRESS"'",
            "remove": []
        }
       
}' > steward_proposal.json

Notice that json contains new data field. You can add steward address to add field if you consider him worthy and you want to nominate him. You can also provide list of steward adressess that you don’t like into remove field.

Submit proposal to the chain

namadac init-proposal \
        --pgf-stewards \
        --data-path steward_proposal.json

note--pgf-stewards flag which is specific to PGF proposals. If you want to nominate a steward or initiate an airdrop as a steward you should add this flag to your init-proposal command

To list all proposals and see if newly submitted proposal is there run

namada client query-proposal

Indeed it’s there. Now let’s try voting ( make sure you have exported your ACCOUNT_KEY_1 like we did in the previous chapeter )

namada client vote-proposal \
    --proposal-id 1 \
    --vote yay \
    --address $ACCOUNT_KEY_1

You might get the following error.

That’s because voting period will start in the future as was described in the proposal properties. But after some time we can vote and the result will be similar to

When the voting period will end you can check proposal results

namada client query-proposal-result --proposal-id 1

Oh no, my proposal got rejected.

Also, it is showing 0.000000 yay votes, but I’ve definitely voted for myself. The reason for that is we need to bond tokens to a validator first, a topic we’ll delve into in the next chapter.

If you were selected as steward you can nominate addresses to receive fundings by changing data field to

"data" : {
  "retro": [
    {
      "target": {
        "amount": 1337,
        "address": "3pilot"
      }
    }
  ]
}

which, if passed, will grant 1337 NAM to 3pilot.

Eplore more funding options here.

A Day in the Life of a Delegator

Let’s try on delegator’s shoes, shall we?

But first, let’s explore who a delegator is and why one might choose to become one.

Basically anyone with positive NAM can become a delegator. All you need to do is to bond your tokens to a validator. Ok, but what does it mean to bond and who is validator you might ask ?

A validator is a participant in the network responsible for validating and confirming transactions. They ensure the accuracy and legitimacy of transactions before they are added to the blockchain. Validators reputation and weight is built on maintaining the integrity of the system.

Bonding is like putting your NAM assets in a secure partnership with a validator. You are locking your tokens and, in return, receive rewards every time a new block is produced. Rewards depend on the inflation rate, the amount of NAM tokens you bonded, validator commission, and performance. If a validator does not produce enough valid blocks within a given time window, he will get slashed, and so will you. So choose your validator wisely. You can always unbond your tokens, but it will take some time, usually 14 or 21 days before they become liquid.

Btw, all those parameters we just discussed — like the inflation rate and validator performance window — could be modified via a default proposal. Also, being a delegator is a prerequisite to vote for such proposals, without it your vote weight will be simply equal to 0.

Ok, after this brief intro let’s try actually delegating to someone. First check your balance

namada --base-dir $BASE_DIR client balance \
--ledger-address $RPC \
--token NAM --owner $ACCOUNT_KEY_1

Check active validators by running

namadac bonded-stake

Bond tokens to your favourite validator. Don’t forget to export his address into VALIDATOR_ADDRESS variable.

namadac bond \
 --validator $VALIDATOR_ADDRESS \
 --amount 10 \
 --source $ACCOUNT_KEY_1

Let’s see if the stake for the selected validator increased

nope, it hasn’t. But what about our balance.

It’s a scam ?

Not really. We need to wait 2 epochs to see the effect. When you check bonded stake later you should see the updated amount. Also, when you bond tokens to a validator, he doesn’t have control over them; only you do. However, they will receive a commission from your rewards.

After few epochs check the stake again

If you want to unstake your tokens run

namada client unbond \
  --source $ACCOUNT_KEY_1 \
  --validator $VALIDATOR_ADDRESS \
  --amount 5

The countdown starts from epoch 816 and you will be able to withdraw them after 6 epochs.

To check actual unbond status execute

namada client bonds --owner $ACCOUNT_KEY_1

Once the time comes you can run the following command to make your tokens liquid

namada client withdraw \
  --source $ACCOUNT_KEY_1 \
  --validator $VALIDATOR_ADDRESS

Keep in mind, you cannot use your shielded address to bond. But let’s try it, just in case.

namadac bond \
 --validator $VALIDATOR_ADDRESS \
 --amount 3 \
 --source $PAYMENT_ADDRESS_1

or from your spending key

namadac bond \
 --validator $VALIDATOR_ADDRESS \
 --amount 3 \
 --source $SPENDING_KEY_1

Nope, no chance.

To learn more about governance, delagating and validating checkout out the official docs and ask questions in friendly discord channel.

This tutorial is for those who want to tinker with namada and understand some if it core features like operations with transparent and multisig accounts, as well as shielded transfers. I’m using campfire dev chain for this guide and assume that you have already built or downloaded namada binaries and your node is synced and running. If your node is not up try this or campfire guide to set it up.

What’s namada

Namada is cosmos and ethereum compatible L1 blockchain that provides a privacy layer via multi-asset shielded pool (MASP).

You can transfer your assets to MASP from one wallet and withdraw to another. This way you achieve effect similar to when you withdraw from CEX, but without sacrificing your data to any third party.

One cool thing about MASP is that it can support any kind of token: fungible and non-fungible. So if you send your NFT to a shielded pool where only eth tokens where stored, for the outside world your nft transfers within MASP will be indistinguishable from any other transactions.

The other cool thing is that not only you protect your privacy with Namada you also get rewards by shielding and storing your funds in MASP.

Namada is also much more, but we’ll focus on the basics here.

Transparent accounts

Before we start, we need to create 2 accounts which we will use during this whole article. And the only thing we need is to come up with the names…

Let’s export all necessary variables to reuse them later

export ACCOUNT_KEY_1="B1" && \
export ACCOUNT_KEY_2="B2" && \
export MULTISIG_ADDRESS=banana-bro-power && \
export SPENDING_KEY_1=$ACCOUNT_KEY_1-spending-key && \
export SPENDING_KEY_2=$ACCOUNT_KEY_2-spending-key && \
export PAYMENT_ADDRESS_1=$ACCOUNT_KEY_1-payment-address && \
export PAYMENT_ADDRESS_2=$ACCOUNT_KEY_2-payment-address && \
export RPC="localhost:26657" && \
export BASE_DIR="$HOME/.local/share/namada" && \
export TOKEN=NAM

Don’t worry about too much variables at the moment. We will tackle them one by one.

At the top export ACCOUNT_KEY_1=”B1" && export ACCOUNT_KEY_2=”B2" are the account names we are going to use. At the bottom export RPC=”localhost:26657" is the default rpc address. Note that you can use different host and port depending on your node configuration. You can also use some publicly available RPC and in that case you don’t to set up your node at all.

export BASE_DIR=”$HOME/.local/share/namada” is the default dir with configuration for namada node

export TOKEN=NAM — is the name of the token we are going to use

The rest of the variables will be described and used later.

To create our account keys

namada wallet key gen --alias $ACCOUNT_KEY_1

During the process you will get the following prompt

You would need to come up with your encryption password which you will need every time you perform a transaction with this account and you need to remember the 24 words mnemonic phrase was given to you to be able to restore your account.

Let’s create the second account

namada wallet key gen --alias $ACCOUNT_KEY_2

You can view your accounts by running namada wallet key listand the output will be

Each account has associated address with it. To view it run namada wallet address list

You might see a bigger list of addresses, just make sure you didn’t loose your banana addresses.

What we just created is called implicit account. You don’t need initialize them on chain and can send any tokens to the corresponding tnam address straight away.

You can also check your implicit account balance by running

namada --base-dir $BASE_DIR client balance \
--ledger-address $RPC \
--token $TOKEN \
--owner $ACCOUNT_KEY_1

Right now it is empty

But after funding it with the help of a faucet or your fellow comrades from discord it should look something like this

Let’s share some tokens with your BFF B2 by performing transfer transaction

namada --base-dir $BASE_DIR client transfer \
--source $ACCOUNT_KEY_1 \
--target $ACCOUNT_KEY_2 \
--token $TOKEN \
--amount 10 \
--ledger-address $RPC \
--signing-keys $ACCOUNT_KEY_1

You will be asked to enter your passphrase which you provided when creating b1 account to decrypt first account and you will see the following output

Let’s check our updated balances

Cool, now B2 is closer to bying it’s dream car. Or at least a toy car…

Note that first account was deducted more than 10 nam, to cover transaction gas fees. To check how much you will pay you can ad --dry-run-wrapper flag at the end of transfer command

namadac transfer \
  --source $ACCOUNT_KEY_1 \
  --target $ACCOUNT_KEY_2 \
  --token NAM \
  --amount 1 \
  --signing-keys $ACCOUNT_KEY_1 \
  --dry-run-wrapper

From the output bellow you can see that 7616 gas is required for this transaction

Next we can specify gas limit for this transaction. It could be useful if your account is low on budget and the default gas limit will be too much for your balance. Just keep in mind, if you specify gas limit less than is actually required your transaction will be reverted and you will still pay partial gas fees.

namadac transfer \
  --source $ACCOUNT_KEY_1 \
  --target $ACCOUNT_KEY_2 \
  --token NAM \
  --amount 1 \
  --signing-keys $ACCOUNT_KEY_1 \
  --gas-limit 7616

Multisignature accounts

Namada also supports multisignature accounts which is a variation of a transparent account that gives you better security and recovery options. To create multisig account

namadac init-account \
--alias $MULTISIG_ADDRESS \
--public-keys $ACCOUNT_KEY_1,$ACCOUNT_KEY_2 \
--signing-keys $ACCOUNT_KEY_1,$ACCOUNT_KEY_2 \
--gas-payer $ACCOUNT_KEY_1 \
--threshold 2

Let’s make sure we have newly created address by typing

namada wallet address list

and indeed we have it

You might have noticed that this account has a different type —established. We created it with init transaction and tnam address was generated on chain. Before init transaction finishes, address is not known by anyone.

This address will have all the features standard addresses have. Let’s verify that by transfering some tokens into it.

namada --base-dir $BASE_DIR client transfer \
--source $ACCOUNT_KEY_1 \
--target $MULTISIG_ADDRESS \
--token NAM \
--amount 5 \
--ledger-address $RPC \
--signing-keys $ACCOUNT_KEY_1

And confirm it now has a positive balance by running

namada --base-dir $BASE_DIR client balance \
--ledger-address $RPC \
--token $TOKEN \
--owner $MULTISIG_ADDRESS

Now, if it behaves like a standard account, what’s the catch ? The difference comes into place when we need to sign and submit any transaction from it. We cannot send tx straight away like we did with standard account. We need approval of both keys ( in our case B1 and B2 ) that participated in multisig address creation. This provides better security to your account, because if one of the source keys was compromised, it won’t be possible to drain your funds without second key approval.

To do this, first we need to generate transaction data and save it to a file. Lets create a folder for transaction data

mkdir tx_dumps

save tx data into file

namadac transfer \
--source $MULTISIG_ADDRESS \
--target $ACCOUNT_KEY_2 \
--token NAM \
--amount 4 \
--signing-keys $ACCOUNT_KEY_1,$ACCOUNT_KEY_2 \
--gas-payer $ACCOUNT_KEY_1 \
--dump-tx \
--output-folder-path tx_dumps

in my case the following file was generated, but in your case name will be different

Let’s export tx data file path into variable ( but keep in mind your filename will be different )

export TX_PATH="tx_dumps/8DE73F0F6DC401C96A6867B45BF00F404CC0B28EB4DFF1B45CCC1A0F795DEA7A.tx"

and sign tx data with 2 keys

namadac sign-tx \
--tx-path $TX_PATH \
--signing-keys $ACCOUNT_KEY_1 \
--owner $MULTISIG_ADDRESS && \
namadac sign-tx \
--tx-path $TX_PATH \
--signing-keys $ACCOUNT_KEY_2 \
--owner $MULTISIG_ADDRESS

This will output for you two signatures ( I’ve highlighted the first one )

which you will use next to send the transaction ( remember to update signature values for your own ones )

namadac tx \
--tx-path $TX_PATH \
--signatures offline_signature_8DE73F0F6DC401C96A6867B45BF00F404CC0B28EB4DFF1B45CCC1A0F795DEA7A_tpknam1qzatwwvlsda4k8zlzemu343lzq6aktgc9v2fxlvpd7pcz3x036f0k5arv0j.tx \
--signatures offline_signature_8DE73F0F6DC401C96A6867B45BF00F404CC0B28EB4DFF1B45CCC1A0F795DEA7A_tpknam1qq6u9v9x28063djep2c2jsk6luh66pxrnz4x7nsc5zg442a0whzv7y5zvd3.tx \
--owner $MULTISIG_ADDRESS \
--gas-payer $ACCOUNT_KEY_1

Cool. Now your b2 account now has 4 extra NAM tokens.

Shielded accounts

Have you ever had this feeling that someone is watching all your wallet transactions and knows everything about your financial situation ?

We all do. But fret not, it’ll be fixed in a moment.

First let’s generate spending keys

namadaw masp gen-key --alias $SPENDING_KEY_1 && \
namadaw masp gen-key --alias $SPENDING_KEY_2

Next let’s generate payment address.

namadaw masp gen-addr \
    --key $SPENDING_KEY_1 \
    --alias $PAYMENT_ADDRESS_1 && \
namadaw masp gen-addr \
    --key $SPENDING_KEY_2 \
    --alias $PAYMENT_ADDRESS_2

Spending key allows to you to spend and view balance of the corresponding shielded address ( SPENDING_KEY_1 for PAYMENT_ADDRESS_1 and SPENDING_KEY_2 for PAYMENT_ADDRESS_2 ). Every time you execute gen-addr with the same spending key you will get new shielded address. It could be reused or discarded and there is no relationship between those addresses. That’s a great way disguise your transaction history !

To view masp keys and addresses we can use

namadaw masp list-keys 

and

namadaw masp list-addrs

The output will be

Let’s shield your assets now by transfering some of NAM tokens to the shielded address

namadac transfer \
    --source $ACCOUNT_KEY_1 \
    --target $PAYMENT_ADDRESS_1 \
    --token NAM \
    --amount 2

Check your shielded balance

namadac balance --owner $SPENDING_KEY_1

Note that we are using SPENDING_KEY_1 to view the balance. Only shielded address owner can do it. From now on all your transactions will be hidden for unwanted observers.

No one is watching you and your transactions inside MASP are untraceable. For example let’s perform shielded transfer to your second payment address

namadac transfer \
    --source $SPENDING_KEY_1 \
    --target $PAYMENT_ADDRESS_2 \
    --token NAM \
    --amount 1 \
    --signing-keys $ACCOUNT_KEY_1

check balance is updated

namadac balance --owner $SPENDING_KEY_2

output

You will also get rewards for storing your assets in shielded pool every new epoch. The longer you stay —the more profit you’ll get !

When you feel it’s time to leave your safe harbor just unshield you funds and go see the bigger world.

namadac transfer \
    --source $SPENDING_KEY_2 \
    --target $ACCOUNT_KEY_2 \
    --token NAM \
    --amount 0.5 \
    --signing-keys $ACCOUNT_KEY_2

Just keep in mind that from now on you are operating with transparent address and you history is recorded. You can tranfer to a new wallet without any history and start from scratch though.

Let’s try one last thing…

Last time, when we made unshielded transfer, B2 account covered our gas fees. What if all our NAM tokens were in MASP to receive shielded pool rewards and B2 address didn’t have any NAM tokens. It is possible to pay the fees with MASP from your shielded address without the need to unshield them

Let’s check our account balance

namadac balance --owner $ACCOUNT_KEY_2

In my case it was 15.95 NAM

Try transfer full b2 balance to b1

namadac transfer \
  --source $ACCOUNT_KEY_2 \
  --target $ACCOUNT_KEY_1 \
  --token NAM \
  --amount 15.95 \
  --gas-payer $ACCOUNT_KEY_2

Transaction will be reverted as you do not have enough NAM tokens to send after applying gas fees. Now your balance is reduced, but you haven’t send your tokens

Transfer full amount again, but use spending key from your shielded address with balance

namadac transfer \
  --source $ACCOUNT_KEY_2 \
  --target $ACCOUNT_KEY_1 \
  --token NAM \
  --amount 15.925 \
  --gas-payer $ACCOUNT_KEY_2 \
  --gas-spending-key $SPENDING_KEY_1

Now you transfered full balance from b2 to b1 and payed for gas fees using spending key. Keep in mind that tokens required to cover gas fees will be unshielded from shielded address and transfered to gas payer account ( B2 in our case ), so you’ll pay a little bit more.

If you want to disguise a gas payer you can use--disposable-gas-payer flag

namadac transfer \
  --source $ACCOUNT_KEY_2 \
  --target $ACCOUNT_KEY_1 \
  --token NAM \
  --amount 15.925 \
  --gas-spending-key $SPENDING_KEY_1 \
  --disposable-gas-payer

which will generate a disposable transparent address that will cover gas fees.

Imagine a universe where

• Individuals have the freedom to decide which information they wish to share with the public and what they prefer to keep private
• Usage of privacy is rewarded as a public good

Namada is a portal to such place.

See you in part 2 where we discuss governance, staking and delegation rewards.

Namada tinkerer notes was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

General security memo

• Do not manage your node from root. Use separate user for that
• Use ssh keys instead of passwords and forbid root to ssh to your host
• Log / ban unauthorized login attempts. Could be done with a tool like fail2ban
• Keep your system and third-party libraries up to date with the latest security patches

Monitoring

It is important to set up proper monitoring right from the start to avoid missing blocks and getting jailed. While there are many ways to configure the best monitoring system that fits your needs, let’s describe next what we are currently using on our daily basis.

Prometheus is a system montoring tool that collects metrics from your hosts and allows you build graphs and alarms based on them. Out of the box your cosmos node provides useful prometheus metrics like consensus height, validator missed blocks, mempool size and many more that could be found here. Node exporter is an excellent tool to extract huge amount of metrics related to your host like cpu load, memory pressure, disk iops, network traffic etc.

Grafana — allows you to build dashboards and alarms from many different dasources and prometheus is among of the supported data sources. Are you experiencing cpu spikes ? Is your disk about to run out of space ? Or maybe you need to understand for how long your server was not available to the internet. All that is very easy spot or prevent when you have proper dashboard configured.

PagerDuty — incidient response tool across all your digital infrastructre. While you can foward your alarms to email / telegram / discord it is much better when you have dedicated tool that collects and groups your alarms by their severity, handles escalation to another person if the issue wasn’t resolved in time, provides automatic on-call rotation between your team members. You can also have different kind of alarms based on their severity to allow alarm to ignore “Do not disturb” mode and wake you up if it is an urgent matter.

Those are the basic tools that we use but here are some other services worth mentioning:

• Tenderduty — monitoring for tendermint chains
• Panic — monitoring and alerting for blockchains
• Cosmos-exporter — if you need more metrics that are available from the default tendermin exporter

Ports

Use principle of least privilege when considering which ports to open at your validator node. Ideally you only need p2p port open ( 26656 ) by default. The rest could be blocked in your node config files:

# disable rpc port
# ~/.project/config/config.toml
[rpc]
laddr = "tcp://127.0.0.1:26657"
cors_allowed_origins = []


# disable rpc port
# ~/.project/config/app.toml
[grpc]
enable = false
address = "0.0.0.0:9090"
[grpc-web]
enable = false
address = "0.0.0.0:9091"


# disable json-rpc port ( only for evm compatibale chains like zetachain or haqq )
# ~/.project/config/app.toml
[json-rpc]
enable = false
address = "0.0.0.0:10545"
ws-address = "0.0.0.0:8546"


# disable api ( lcd = api = rest )
# ~/.project/config/app.toml
[api]
enable = false
swagger = false
address = "tcp://0.0.0.0:1317"

or via firewall. When using firewall keep in mind that you also need to whitelist your ssh port also ( 22 any custom port you have )

Check out this example on how easy it is to find validators with rpc port opened. Opening RPC/GRPC port for a node that isn't optimized for heavy query workloads can lead to it going offline after just a few demanding requests. This makes attacker`s life much easier.

DDoS

Even if you properly closed all non mandotory ports for validation it is possible to spam your host through p2p port and make it inoperative for the duration of the attack. To avoid this you can setup your validator node to only communicate with a set of trusted sentry nodes via direct link and make it inaccessible to the outside world.

This way it is impossible to spam your validator, only it’s sentry nodes. But is should be very easy to scale / change them in case of such attack.

Keeping all the unneccesary ports closed and your validator ip hidden is very important to avoid slashing penalties and reduce risk for the network since having multiple nodes down at the same time is bad for network stability.

Key protection

TMKMS — tendermint key management system. This is a separate process which extracts signing logic from your validator node and can run separately from your validator host. It is also very easy to plug in various signing mechanisms like:

• FortanixDSM
• YubiHSM2
• Ledger

All of those options will protect your private key when your host was compromised.

Horcrux — a multi-party-computation (MPC) signing service for tendermint nodes. It allows you split your key into parts and store each part on a separate host. You can configure how many key parts is required to collect your private key signature. For example it could be 2 parts out of 3 total. This means that in order to compromise your private key, attacker needs to get access to 2 of your hosts.

More info about how to setup horcrux and tmkms could be found in our previous articles

• TMKMS with quark-1 (neutron) testnet
• horcrux/docs/signing.md at main · strangelove-ventures/horcrux

Double sign prevention

double_sign_check_height — when set in config.toml to some non zero value like 5 / 10 / 15 your validator node after restart will panik if it participated in consensus in the last 5 / 10 / 15 blocks. This will help to avoid double sign in many cases, for example on migration when old process wasn’t killed properly. While it doesn’t give you 100% double sign prevention it is still covering a lot of unexpected use cases. The only downside is that your node need to always skip configured amount of blocks after restart. This will require some additional configuration if you are using cosmovisor for upgrades.

While double_sign_check_height is a great option to have it is not recommended to solely rely on it when it comes to double sign prevention. TMKMS and Horcrux modules discussed previously provide more advanced double sign prevention mechanisms.

While this article is far from a comprehensive security manual it should give you a good starting point to protect your validator from major threats thats out there.

Security best practices for a cosmos validator was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zetachain is a PoS blockchain developed using the Cosmos SDK that hosts Ethereum Virtual Machine (zEVM) which is capable of running omnichain smartcontracts. Those contracts allow you to execute transactions from any supported source to destination networks. Let’s explore how this is done in practice

Download or clone example repository from github

https://github.com/stanisloe/zetachain-swap-example.git

Navigate to the folder and you should see the following structure

I’ve highlighted core files that we’ll go through to better understand what is happening here:

1. hardhat.config.ts: This is the configuration file for the Ethereum development environment called Hardhat. It allows you to easily deploy and interact with smart contracts using JavaScript code. If you were to do it from scratch, you would need to configure RPC providers, chain settings, etc. However, in this example, everything is already pre-configured for you, so you don't need to add anything there.
2. .env file ( it won’t be in the downloaded project, but we will create it later ): This is where you will insert your EVM account private key, which Hardhat will use for contract deployment and interaction. Please ensure that this account has some native tokens to cover gas costs.
3. tasks/deploy.ts and tasks/interact.ts: These are Hardhat tasks for deploying and interacting with the Swap.sol smart contract. Later, you'll execute commands to trigger those tasks.
4. Swap.sol file: This contains the Ethereum Virtual Machine (EVM) compatible smart contract code that will perform cross-chain swap transactions.

Now, let’s prepare our environment for contract deployment.

First, let’s install npm and Node.js if you haven’t done so already. You can follow any of the following guides:

• How to Install NPM and Node.js on Windows and Mac Devices?
• Downloading and installing Node.js and npm | npm Docs

After this is done let’s navigate to downloaded example repository in the command line and run

npm install yarn && yarn && yarn add --dev @uniswap/v2-periphery @uniswap/v2-core

Next, you’ll need to create a file named .env in the project directory and place the private key from an account that holds Matic Mumbai testnet tokens.

PRIVATE_KEY=<your private key here>

Run

npx hardhat balances

and you should see similar output

EVM: 0xA72745c17596E4Bd4E4424e8d827176087F5870a
BTC: tb1qgxuumr0ctan0x4u8jthcw4gvxz0q5pfhemyazs

┌─────────┬──────────────────┬────────┬─────────┬───────┐
│ (index) │   networkName    │ native │  zeta   │ zrc20 │
├─────────┼──────────────────┼────────┼─────────┼───────┤
│    0    │ 'mumbai_testnet' │ '0.58' │ '57.00' │       │
│    1    │  'zeta_testnet'  │ '5.82' │ '0.00'  │  ''   │
│    2    │  'bsc_testnet'   │ '0.10' │ '0.98'  │       │
│    3    │ 'goerli_testnet' │ '0.16' │ '30.00' │       │
│    4    │  'btc_testnet'   │  '0'   │         │       │
└─────────┴──────────────────┴────────┴─────────┴───────┘

Pay attention to your Mumbai and Goerli native balances. If you don’t have matic tokens request them here.

Next compile smart contracts

npx hardhat compile --force

Once everything is compiled we are ready to deploy our contract by running:

npx hardhat deploy --network zeta_testnet

Note the naming for the deploy task — it’s the same as the task file tasks/deploy.ts we discussed previously. interact task will be called in a similar manner later, but with different arguements.

You should see similar output with your account and contract addresses. They will be different from mine.

🔑 Using account: 0xA72745c17596E4Bd4E4424e8d827176087F5870a

🚀 Successfully deployed contract on ZetaChain.
📜 Contract address: 0xFAfE767BB2AbC2B68AE4466FCcbd8afc9d1B7079
🌍 Explorer: https://athens3.explorer.zetachain.com/address/0xFAfE767BB2AbC2B68AE4466FCcbd8afc9d1B7079

Once the contract is deployed it’s time to interact with it. Run the following command

npx hardhat interact --contract 0xFAfE767BB2AbC2B68AE4466FCcbd8afc9d1B7079 --amount 0.2 --network mumbai_testnet --destination goerli_testnet --recipient 0xA72745c17596E4Bd4E4424e8d827176087F5870a

Note that you need to replace contract and recipient arguments. You should see the following output after few minutes

🔑 Using account: 0xA72745c17596E4Bd4E4424e8d827176087F5870a


🚀 Successfully broadcasted a token transfer transaction on mumbai_testnet network.
📝 Transaction hash: 0x6a85f07eef914ddd7eae76355e9d6c12e4d72082f22bbedcbfee56ccfadf5a84

✔ CCTX hash found: 0xabd5a19e33a772086680403028a2a0a4bd528321e64755eb5c9b84c89641754c

ℹ Status updated to "OutboundMined": Remote omnichain contract call completed

✔ CCTX has been finalized on ZetaChain

Let’s inspect what was done byinteract task and it’s output in more detail.

Transaction hash

📝 Transaction hash: 0x6a85f07eef914ddd7eae76355e9d6c12e4d72082f22bbedcbfee56ccfadf5a84

corresponds to a transfer made from your mumbai test network account to zetachain account on mumbai blockchain called the TSS ( Threshold Signature Scheme ) On every connected network there is such TSS ( actuall addresses for supported chains could be found here ) owned by zetachain team. Typically, you’ll send some tokens and metadata about your desired actions with those tokens to the TSS. In this exeample you have send 0.2 matic tokens and told zetachain to withdraw what is left after fees to your wallet in goerli network.

By sending this Mumbai blockchain transaction you have triggered transaction on the Zetachain blockchain, known as a cross-chain transaction (CCTX), which you can find in the output as well.

✔ CCTX hash found: 0xabd5a19e33a772086680403028a2a0a4bd528321e64755eb5c9b84c89641754c

Now lets investigate it a little bit further. Navigate to ( don’t forget to use your CCTX hash in explorer )

https://athens3.explorer.zetachain.com/cc/tx/0xabd5a19e33a772086680403028a2a0a4bd528321e64755eb5c9b84c89641754c

to explore this CCTX in detail. You should see the following screen.

From it you should be able to see how your omnichain swap was performed:

1. This your initial transaction on polygon mumbai blockchain where you interacted with TSS and sent your tokens with metadata about recipient and destination chain
2. This is another CCTX on zetachain that will initiate tokens withdrawal from goerli TSS to recipient account
3. Deposit transaction hash on destination network

After some time, when zetachain processes your transaction, you will receive tokens in your destination network

To check the balance

npx hardhat balances

Notice that goerli_testnet native value increased by 0.01 from the previous run. The rest was payed for the interchain transaction commission to zetachain protocol.

EVM: 0xA72745c17596E4Bd4E4424e8d827176087F5870a
BTC: tb1qgxuumr0ctan0x4u8jthcw4gvxz0q5pfhemyazs

┌─────────┬──────────────────┬────────┬─────────┬───────┐
│ (index) │   networkName    │ native │  zeta   │ zrc20 │
├─────────┼──────────────────┼────────┼─────────┼───────┤
│    0    │ 'mumbai_testnet' │ '0.38' │ '57.00' │       │
│    1    │  'zeta_testnet'  │ '5.82' │ '0.00'  │  ''   │
│    2    │  'bsc_testnet'   │ '0.10' │ '0.98'  │       │
│    3    │ 'goerli_testnet' │ '0.17' │ '30.00' │       │
│    4    │  'btc_testnet'   │  '0'   │         │       │
└─────────┴──────────────────┴────────┴─────────┴───────┘

And that’s it. By simply running

npx hardhat deploy --network zeta_testnet

you have deployed your own smart contract that is reusing audited and battle-tested uniswap code base. You do not need to implement all the complex multichain swap logic from scratch.

And by running

npx hardhat interact --contract 0xFAfE767BB2AbC2B68AE4466FCcbd8afc9d1B7079 --amount 0.2 --network mumbai_testnet --destination goerli_testnet --recipient 0xA72745c17596E4Bd4E4424e8d827176087F5870a

you’ve bridged your native mumbai polygon tokens to goerli eth tokens.

One cool feature of omnichain contracts is that they eliminate the need for smart contracts on both source and destination networks. Smart contracts are only deployed on Zetachain. To initiate a cross-chain transaction, you simply send data to the TSS address on the supported source chain. The advantage of TSS being just an account is that it enables the triggering of smart contracts even on chains like Bitcoin/Dogecoin, which lack the capacity or efficiency to support general-purpose smart contracts.

Feel free to explore more from the official docs.

Zetachain — deploy and interact with your own omnichain contract was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

sudo apt update && sudo apt upgrade -y && \
curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash - && \
sudo apt install build-essential nodejs -y && \
PATH="$PATH" && sudo npm install -g near-cli && \
echo 'export NEAR_ENV=mainnet' >> ~/.bashrc && \
echo 'export NEAR_ENV=mainnet' >> ~/.bash_profile && \
source $HOME/.bash_profile

Check cli is working

near proposals

Install near node dependencies

sudo apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev \
libdw-dev libiberty-dev cmake gcc g++ python3 docker.io protobuf-compiler \
libssl-dev pkg-config clang llvm cargo python3-pip clang build-essential \
make jq && \
USER_BASE_BIN=$(python3 -m site --user-base)/bin && \
export PATH="$USER_BASE_BIN:$PATH" && \
export RUSTUP_INIT_SKIP_PATH_CHECK=yes && \
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh && \
source $HOME/.cargo/env

Check latest release ( not Pre-release ) here

export NEAR_RELEASE_VERSION=<latest release>

git clone https://github.com/nearprotocol/nearcore.git && \
cd nearcore && \
git checkout $NEAR_RELEASE_VERSION && \
make release && \
target/release/neard init --chain-id="mainnet"

Login to wallet

near login

Download genesis and config

cd ~/.near && \
(rm genesis.json && wget -c https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/genesis.json || wget -c https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/genesis.json) && \
(rm config.json && wget -c https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json || wget -c https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json)

Install s5cmd for faster snapshot download

wget -O s5cmd.tar.gz https://github.com/peak/s5cmd/releases/download/v2.0.0/s5cmd_2.0.0_Linux-64bit.tar.gz && \
mkdir s5cmd && \
tar -xf s5cmd.tar.gz -C s5cmd && \
sudo mv s5cmd/s5cmd /usr/bin/ &&
rm -rf s5cmd s5cmd.tar.gz

Download snapshot

chain="mainnet" && \
kind="rpc" && \
s5cmd --no-sign-request cp "s3://near-protocol-public/backups/$chain/$kind/latest" . && \
latest=$(cat latest) && \
echo "snapshot date: $latest" && \
s5cmd --no-sign-request cp "s3://near-protocol-public/backups/$chain/$kind/$latest/*" ~/.near/data

Install and start service

sudo printf "[Unit]
Description=NEAR Daemon Service
[Service]
Type=simple
User=$(whoami)
#Group=near
WorkingDirectory=/home/$(whoami)/.near
ExecStart=/home/$(whoami)/nearcore/target/release/neard run
Restart=on-failure
RestartSec=30
KillSignal=SIGINT
TimeoutStopSec=45
KillMode=mixed
[Install]
WantedBy=multi-user.target" | sudo tee "/etc/systemd/system/neard.service" && \
sudo systemctl daemon-reload && \
sudo systemctl restart neard && \
journalctl -n 100 -f -u neard

Add metrics export to prometheus.yml

- job_name: 'near_node'
  static_configs:
  - targets: ['localhost:3030']

Swap keys with backup node

Make sure you have folder with your node and validator keys

mkdir keys_validator && ls -lah keys_validator

Main node: stop main node and remove keys from it.

sudo systemctl stop neard.service && \
sudo systemctl disable neard && \
shred -u .near/node_key.json && \
shred -u .near/validator_key.json && \
ls -lah .near && \
sudo systemctl status neard.service

Backup node: stop the node and replace reserve keys with main validator keys:

sudo systemctl stop neard.service && \
cp keys_validator/node_key.json .near/ && \
cp keys_validator/validator_key.json .near/ && \
ls -lah .near && \
sudo systemctl status neard.service

Backup node: start backup node with validator keys

sudo systemctl start neard.service && \
journalctl -u neard.service -fo cat

Logs for validator node contain:

INFO stats: #83542486 BadDrDkB1ens3vf1EJjxkUqfyg6YDhiZUDF4u5CqqEZV Validator | 100 validators 35 peers ⬇ 591 kB/s ⬆ 546 kB/s 0.80 bps 43.0 Tgas/s CPU: 31%, Mem: 11.6 GB

Logs for normal node contain:

INFO stats: #83542995 3ycG3dCy18nDSxhYr8SiKjLFBStL3DB1bnDXR24Bo7o7 100 validators 30 peers ⬇ 1.30 MB/s ⬆ 1.05 MB/s 0.80 bps 355 Tgas/s CPU: 142%, Mem: 7.16 GB

Main node: start main node as backup if required

sudo systemctl start neard.service && \
journalctl -u neard.service -fo cat

Start cron

Download ping script

mkdir scripts || true && \
wget -O $HOME/scripts/ping.sh https://raw.githubusercontent.com/stanisloe/near-tools/main/mainnet/ping.sh && \
chmod 777 $HOME/scripts/ping.sh

Add output of this command to crontab

echo "0 */12 * * * sh $HOME/scripts/ping.sh"

Intro

Right now the majority of data about us and our environment is controlled by a small amount of giant tech companies that are leaders in their field. While this is a great source of information and knowledge it is only available to those companies and is used according to their interest. Some companies produce lots of data and they might want to monetize it, but currently it is difficult to do so for different reasons: lack of required infrastructure, absence of a trusted “data market” with established prices, compliance issues. OKP4 blockchain tries to fix that by creating an ecosystem where data providers can cooperate with data consumers by selling them data and their services. From this data, consumers will gain information and knowledge they seek in a decentralized way without any need of trusted third party.

Data providers and consumers are the core actors in the OKP4 dataverse and I will be referring to them throughout this article.

Let’s see how this works by taking a closer look at main layers of the OKP4 ecosystem and going through a simple example.

Blockchain layer

The backbone for the whole system. This is where all the decentralization magic will happen: transactions history will be stored, validators will sign blocks, delegators stake their tokens and receive rewards, smart contracts execute their logic, governance rules will be enforced and all required metadata for data space layer (described next) will be defined.

OKP4 blockchain is based on cosmos sdk due to it’s high adoption, lots of success cases with other blockchains already running it, much better protocol customization possibilities compared to layer 2 options and native cross chain communication support.

Data Space layer

Data space is the core concept of the OKP4 network. It is build on top of blockchain layer and is heavily using all the main blockchain features: decentralization, immutability, trackability etc… Every data space will have it’s own owner(s), permissions, rules, security mechanisms, price for using it’s data/services and possibly it’s own token for governance. It is important to understand that data space is not just the storage — it is a set of services like data, computation, authentication or algorithm providers that work together to give some meaningful information to the data consumer. But OKP4 not just one data space it can support any number of data spaces to serve their own purpose. The combination of all active data spaces and underlying services will form a dataverse, place where you can get any data you need and easily navigate through it with the help of OKP4 ecosystem.

Application layer

At this layer various applications will be presenting data extracted from the OKP4 dataverse in a meaningful way. From the end user point of view it could be a web 2 like application with a familiar ux and subscription based business model. But under the hood application will be a data consumer in the OKP4 chain — executing transactions, paying fees etc. This way the strongest parts of web 2 and web 3 worlds will be combined by providing smooth user experience of web 2 and decentralization of web 3.

Example

Let’s say we have a database of students and their grades. We also have a service that can perform basic operations with the list of students like filtering, sorting, merging etc. Most likely the information we can get from this data will be useful for parents of students and university staff. Let’s create a data space, so that data consumers will be able to get some new insights about students in an OKP4 way.

First we give it a name and a meaningful description. Something like “Student Space” should work.

Next we need to define what services we have and what we can do with them. As described above, we have a database that can return a list of students and an algorithm that can accept a list of students and return a modified list according to filtering criteria. For the data consumers those services will be available as a steps, which they can combine in any way to receive a meaningful information. One possible scenario would be to get a list of students with high and low grades to ask students with high grades to help students with low grades to improve their performance. To do this, data consumer might submit a query to the OKP4 blockchain with the steps like:

• Get list of students from the database
• Use service to filter original list of students, whose grades are 5 ( out of 5 )
• Use service to filter original list of students, whose grades are less than 3
• Merge two filtered lists into one.

The execution of the query is controlled by the OKP4 protocol. Each step execution and it’s status (SUCCESS / ERROR) will be recorded to the blockchain. If previous step was successful next step will be submitted. In the end the whole query will be either completed or failed. In case of success the query result will contain information how to get requested data ( link to a file for example ), in case of failure all failed steps will be recorded to the blockchain and it should be easy understand what went wrong. What is important to understand is that OKP4 will only be coordinating those steps execution and recording intermediate status to the blockchain. It is not a distributed storage or a compute protocol. All the computation and storage will happen off chain while all participating services orchestration will happen on the chain. Having all the steps recorded to the blockchain makes it easy to reproduce those steps by other data consumers that want to get similar results or perform charges audit at any time to better understand the final bill.

Now let’s think about the pricing model. One option could be charging a fixed price for getting a list of students from the database. Or we can think of charging by how big in megabytes list of students was returned. Similar logic can apply to our algorithm service: we can either charge for the number of times it was invoked or for the amount of time it was executing filtering or any other operation. Need to keep in mind, that the more we want to charge for accessing the service the more KNOW (OKP4 native currency) tokens we need to stake to our data space. This will ensure quality of service as if it doesn’t perform as expected data space staked tokens will get slashed.

We also need to think about how to update data space rules. What if we decide to change the pricing model, add a new service or allow access only to university staff ? There are several options to edit data space. It could be done by a data space single owner signing edit transaction with his private key. There could be several owners of the data space which are required to multi sign edit transaction. Or data space configuration updates could be done via governance when there is a proposal and all token holders vote for it. For calculating a participant’s voting power, his KNOW or a data space’s custom token will be used.

At this moment we have a data space and it is working great, but we want to promote it. For this scenario there will be a dedicated role — Curator. Curators are token holders that want to be a little bit more involved than simply delegating those tokens to a validator. They research various data spaces and delegate their tokens to the ones they find promising. The more tokens delegated to the data space the higher rating it will have in the overall system. If our student data space indeed provides great value to consumers, curators will share it’s success in terms of rewards. If it doesn’t work as expected they will get slashed together with the data space.

So after the query is executed successfully we have a link to a file with students. We can manually go through it to assign mentors to students with low grades. But what if the list is very big and instead of scrolling down through a big file we want to have some nice UI with pagination an searching capabilities ? What if we want to keep track of some historical data, like which students mentored better than the rest ? Or what if installing a crypto wallet sounds too difficult ? That’s a nice idea for an application, that will be querying “Students Space”, paying transaction and services fees and providing a friendly interface to the end users. To cover service fees, app builders can set up a subscription for using their software which is much easier for students parents than figuring out how to use keplr.

This is really a very simple demo example just to show how everything works together in the OKP4 protocol, but the actual use cases could be much more interesting and include: data for machine learning and ai networks, health and medicine, entertainment, banking, finance and many more.

When we are talking about crypto technology first thing that pops up in people mind is usually bitcoin. If you dive deeper you will realize that blockchain is a distributed and immutable database that operates without any central authority and is not only limited by digital currencies. It allows us to have dex systems like Osmosis, non-custodial lending protocols like Aave, decentralized security monitoring systems like Forta. OKP4 brings another useful case for this fascinating technology — exploitation and sharing of data in a trustless manner.

Intro

Let’s try setting up highly available neutron validator ( should also apply to any tendermint based chain ) with the help of horcrux. I definitely recommend checking out official docs from the horcrux devs which I was using to test this configuration and write this article:

• horcrux/docs/signing.md at main · strangelove-ventures/horcrux
• horcrux/migrating.md at main · strangelove-ventures/horcrux

Also you might want to briefly go through my another guide to get a simplified view on remote signing.

TMKMS with quark-1 (neutron) testnet

Requirements

For this experiment we would need to spin up 6 hosts in total. 3 hosts that are running neutron network (sentry nodes) and 3 signer nodes that will be running horcrux.

For sentry nodes I was using 4vcpu/8gb ram hardware. For signer node I was using 1vcpu/1gb ram host.

Signer nodes setup

Once you have all hosts up running, neutron is installed and is “in sync” on all 3 sentry nodes, let’s download and install horcrux binary for SIGNER_IP_1 host:

wget https://github.com/strangelove-ventures/horcrux/releases/download/v2.0.0/horcrux_2.0.0_linux_amd64.tar.gz && \
tar -xzf horcrux_2.0.0_linux_amd64.tar.gz && \
sudo mv horcrux /usr/bin/horcrux && rm horcrux_2.0.0_linux_amd64.tar.gz README.md LICENSE.md

Export all ips to variables that we are going to use throughout this guide ( replace ips provided in the command bellow )

export SENTRY_IP_1="10.168.0.1" && \
export SENTRY_IP_2="10.168.0.2" && \
export SENTRY_IP_3="10.168.0.3" && \
export SIGNER_IP_1="10.168.1.1" && \
export SIGNER_IP_2="10.168.1.2" && \
export SIGNER_IP_3="10.168.1.3"

Next run this command at the same host

horcrux config init quark-1 "tcp://$SENTRY_IP_1:1234" \
-c -p "tcp://$SIGNER_IP_2:2222|2,tcp://$SIGNER_IP_3:2222|3" \
-l "tcp://$SIGNER_IP_1:2222" -t 2 --timeout 1500ms

It will initialize config folder at this node, map SIGNER_IP_1 with SENTRY_IP_1 neutron node and make it aware of the other signer nodes SIGNER_IP_2, SENTRY_IP_3. Check out /root/.horcrux/config.yaml — it should contain configuration similar to this one.

Now, let’s copy your validator priv_validator_key.json to SENTRY_IP_1 host and run

horcrux create-shares priv_validator_key.json 2 3

This command will split your private key into 3 parts and make sure that minimum 2 different parts are required to sign a block.

Check that you have 4 files in total in your current folder

Move private_share_1.json to ~/.horcrux/share.json

mv private_share_1.json ~/.horcrux/share.json

And that’s it for SIGNER_IP_1 node configuration. Now we need to repeat similar steps for signer node 2 and 3. At each host you should run exactly the same command as we did previously

export SENTRY_IP_1="10.168.0.1" && \
export SENTRY_IP_2="10.168.0.2" && \
export SENTRY_IP_3="10.168.0.3" && \
export SIGNER_IP_1="10.168.1.1" && \
export SIGNER_IP_2="10.168.1.2" && \
export SIGNER_IP_3="10.168.1.3"

For signer node 2:

Execute:

horcrux config init quark-1 "tcp://$SENTRY_IP_2:1234" \
-c -p "tcp://$SIGNER_IP_1:2222|1,tcp://$SIGNER_IP_3:2222|3" \
-l "tcp://$SIGNER_IP_2:2222" -t 2 --timeout 1500ms

Move private_share_2.json you created at signer host 1 to signer node 2 ~/.horcrux/share.json

For signer node 3

Execute:

horcrux config init quark-1 "tcp://$SENTRY_IP_3:1234" \
-c -p "tcp://$SIGNER_IP_1:2222|1,tcp://$SIGNER_IP_2:2222|2" \
-l "tcp://$SIGNER_IP_3:2222" -t 2 --timeout 1500ms

Move private_share_3.json you created at signer host 1 to signer host 3 ~/.horcrux/share.json

So, right now you moved 3 parts of your key to 3 different signer nodes. To sign next block you need at least 2 signer nodes to be running, otherwise there won’t be enough parts ( 2 required ) to sign a block. We might have split the private key like this

horcrux create-shares priv_validator_key.json 1 3

This means we will still have 3 key parts, but each part is enough to sign a block and this way you will increase your validator availability, but sacrifice you key security. It’s up to you to decide the desired configuration, recommended configurations are: 5 3 or 2 3

You can now remove priv_validator_key.json from signer node 1. Make sure you also removed all priv validator key materials: private_share_*.json

I would also recommend to create and enable service for horcrux

/etc/systemd/system/horcrux.service

[Unit]
Description=MPC Signer node
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/horcrux cosigner start
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target

Sentry node setup

Make sure to go through this chapter and the next one to understand what you are going to do before executing commands, because you would need to stop your validator for a while.

Now, for all your sentry nodes run

sed -i 's#priv_validator_laddr = ""#priv_validator_laddr = "tcp://0.0.0.0:1234"#g' ~/.neutrond/config/config.toml

to make it available for horcrux signer nodes.

Remember I mentioned you need 6 nodes for this experiment ? Well technically you might be still running your main single node validator and you are having 7 nodes in total right now. You might also reuse your current validator as 1 of the sentry node, totally up to you. But right now it’s time to turn off your main validator node. Once it is stopped, run this command to create a slightly modified version of your priv_validator_state.json (make sure you have jq installed)

jq '{height,step}' ~/.neutrond/data/priv_validator_state.json | jq '. += {"round":"'$(jq '.round' ~/.neutrond/data/priv_validator_state.json)'"}' | tee quark-1_priv_validator_state.json quark-1_share_sign_state.json

You should now how 2 files

You need to copy those file to all your signer nodes ( not sentry nodes that we are currently configuring ) . The location is /root/.horcrux/state :

/root/.horcrux/state/quark-1_priv_validator_state.json

/root/.horcrux/state/quark-1_share_sign_state.json

Both those files should contain identical output, similar to this one

{
  "height": "386402",
  "step": 3,
  "round": "0"
}

Run your sentry / horcrux cluster

Execute for each signer node

systemctl start horcrux.service && journalctl -u horcrux.service -f

you should see logs like

Restart all your sentry nodes

systemctl restart neutrond.service && journalctl -u neutrond.service -fo cat

If everything was configured properly you should start signing blocks straight away and see similar logs

For non leader signer node the logs will be like this

This are the logs for all of your sentry nodes in one picture

And that’s it, now you can sleep much better knowing that if there something wrong with 1 one of your sentry node, you have 2 more to do the job.

Observations

All of my sentry nodes were located in different data centers: London, Netherlands, USA. All of my signer nodes were located in Russian data center.

Resource usage for one of the sentry node

Resource usage for signer leader node

Resource usage for signer non leader node

Didn’t notice any uptime drop, besides the switching period were I had to turn off my main validator node.

Intro

TMKMS — tendermint key management system. Provides isolated signing key management for Tendermint applications including validators, oracles, IBC relayers, and other transaction signing applications.

What this means is that you can safely store your validator key separately from your validator node and continue to sign blocks.

For this experiment you will need to have 2 hosts: one that will be running neutron chain (validator node) and the other that will be signing blocks (tmkms node). You can use the same server you are using now for your validator node and get a new one for tmkms. Tmkms host doesn’t consume much resources, so it can be anything starting from 1cpu/1gb ram.

Install tmkms

After connecting to the tmkms node ( not the validator node ) let’s install all the required dependencies

sudo apt update && \
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh && \
source $HOME/.cargo/env && \
sudo apt install git build-essential ufw curl jq snapd --yes && \
apt install libusb-1.0-0-dev && \
export RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

Let’s download and compile tmkms source code

cd $HOME && \
git clone https://github.com/iqlusioninc/tmkms.git && \
cd $HOME/tmkms && \
cargo install tmkms --features=softsign && \
tmkms init config && \
tmkms softsign keygen ./config/secrets/secret_connection_key

Note that we are using --features=softsign. For better security ledger / yubihsm alternatives should be considered.

Now lets copy your priv_validator_key.json to ~/tmkms/config/secrets and import it like this:

tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/tmkms/config/secrets/priv_validator_key

Next we should update config file $HOME/tmkms/config/tmkms.toml to look like this

[[chain]]
id = "quark-1"
key_format = { type = "cosmos-json", account_key_prefix = "neutronpub", consensus_key_prefix = "neutronvalconspub" }
state_file = "/root/tmkms/config/state/priv_validator_state.json"

[[providers.softsign]]
chain_ids = ["quark-1"]
key_type = "consensus"
path = "/root/tmkms/config/secrets/priv_validator_key"

[[validator]]
chain_id = "quark-1"
addr = "tcp://65.21.107.203:688" # validator tcp://ip:port
secret_key = "/root/tmkms/config/secrets/secret_connection_key"
protocol_version = "v0.34"
reconnect = true

Make sure to use your validator ip for addr option.

Update validator node config

At your valicator node set priv_validator_laddr in $HOME/.neutrond/config/config.toml to have a proper port, specified in tmkms.toml in validator node.

Comment out priv_validator_key_file and priv_validator_state_file in the same file.

Start signing with TMKMS

Stop your validator node, you can also rename or move priv_validator_key.json to another place.

Start tmkms process by running (note it is much more reliable to run it as a service)

tmkms start -c $HOME/tmkms/config/tmkms.toml

You should see the following logs for tmkms node.

After your neutron node is started, tmkms logs should be like this

Remove priv_validator_key.jsonfrom your validator and tmkms nodes, store it safely offline. And that’s it, now you are signing blocks from another node.

Observations

I’ve being testing it for several days, noticed minor uptime drop, around 0.02%. For the tmkms node I was using 3vcpu/4gb ram host located in Germany, while my neutron node was located in Helsinki. Suspect, that having both nodes in one dc would decrease uptime drop.

Resource utilization for tmkms node can be found below

The only minor difference is traffic increase around 16:00 which was expected

To install neard please refer to this guide, episode 3. Note that instead of checking out latest stake wars recommended commit you need to checkout 1.28.1 tag. Once it is built, make sure neard binary is on your path by typing

neard --version

Install nix

sh <(curl -L https://nixos.org/nix/install) --daemon

After installation run

source ~/.nix-profile/etc/profile.d/nix.sh

Check it is installed by typing

nix-env --version

Clone and navigate to kuutamo source directory and install all dependencies

git clone https://github.com/kuutamolabs/kuutamod && cd kuutamod && nix develop --extra-experimental-features nix-command --extra-experimental-features flakes

Build kuutamod while in a folder

cargo build

Run

hivemind

This should give you output like this

Open 2nd session, navigate to kuutamo source directory and run

./target/debug/kuutamod --neard-home .data/near/localnet/kuutamod0/ \
  --voter-node-key .data/near/localnet/kuutamod0/voter_node_key.json \
  --validator-node-key .data/near/localnet/node3/node_key.json \
  --validator-key .data/near/localnet/node3/validator_key.json \
  --near-boot-nodes $(jq -r .public_key < .data/near/localnet/node0/node_key.json)@127.0.0.1:33301

Check that it is running and validating by typing

curl http://localhost:2233/metrics

You should see the following output, Validating should be 1

Run second kuutamo instance

./target/debug/kuutamod \
  --exporter-address 127.0.0.1:2234 \
  --validator-network-addr 0.0.0.0:24569 \
  --voter-network-addr 0.0.0.0:24570 \
  --neard-home .data/near/localnet/kuutamod1/ \
  --voter-node-key .data/near/localnet/kuutamod1/voter_node_key.json \
  --validator-node-key .data/near/localnet/node3/node_key.json \
  --validator-key .data/near/localnet/node3/validator_key.json \
  --near-boot-nodes $(jq -r .public_key < .data/near/localnet/node0/node_key.json)@127.0.0.1:33301

Check it’s status

curl http://localhost:2234/metrics

Note that it is not validating, as we already have validator instance. If you turn of your current validator, this instance will pick up validation instead.

Check the logs

journalctl -u kuutamod1.service | grep 'state changed'

Check status

systemctl status kuutamod1.service

Part 2 — NixOS + AWS

Create account with aws. After that using link bootstrap ec2 instance with nix os image, I used t3.xlarge and 200gb gp3 disk.

Edit configuration.nix nano /etc/nixos/configuration.nix

{ modulesPath, ... }: {
  imports = [ "${modulesPath}/virtualisation/amazon-image.nix" ./kuutamod.nix];
  ec2.hvm = true;

  nix.extraOptions = ''
  experimental-features = nix-command flakes
  '';
  
  swapDevices = [{
    device = "/swapfile";
    size = 4096;
  }];
}

Add flake.nix file as below: nano /etc/nixos/flake.nix

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable-small";
    kuutamod.url = "github:kuutamolabs/kuutamod";
  };
  outputs = { self, nixpkgs, kuutamod }: {
    nixosConfigurations.validator = nixpkgs.lib.nixosSystem {
      # Our neard package is currently only tested on x86_64-linux.
      system = "x86_64-linux";
      modules = [
        ./configuration.nix
        
        # Optional: This adds a our binary cache so you don't have to compile neard/kuutamod yourself.
        # The binary cache module, won't be effective on the first run of nixos-rebuild, but you can specify it also via command line like this:
        # $ nixos-rebuild switch --option  extra-binary-caches "https://cache.garnix.io" --option extra-trusted-public-keys "cache.garnix.io:CTFPyKSLcx5RMJKfLo5EEPUObbA78b0YQ2DTCJXqr9g=" --flake /etc/nixos#validator
        self.inputs.kuutamod.nixosModules.kuutamo-binary-cache

        kuutamod.nixosModules.neard-shardnet
        kuutamod.nixosModules.kuutamod
      ];
    };
  };
}

Copy time stamp and use it in the following kuutamod.nix file as below: nano /etc/nixos/kuutamod.nix file

{
  # consul is here because you can add more kuutamod nodes later and create an Active/Passive HA cluster.
  # Consul wants to bind to a network interface. You can get your interface as follows:
  # $ ip route get 8.8.8.8
  # 8.8.8.8 via 131.159.102.254 dev enp24s0f0 src 131.159.102.16 uid 1000
  #   cache
  # This becomes relevant when you scale up to multiple machines.
  services.consul.interface.bind = "ens5";
  services.consul.extraConfig.bootstrap_expect = 1;
  
  # This is the URL we calculated above:

kuutamo.kuutamod.validatorKeyFile = "/var/lib/secrets/validator_key.json";
  kuutamo.kuutamod.validatorNodeKeyFile = "/var/lib/secrets/node_key.json";
}

Rebuild and switch to new configuration

nixos-rebuild boot --option  extra-binary-caches "https://cache.garnix.io" --option extra-trusted-public-keys "cache.garnix.io:CTFPyKSLcx5RMJKfLo5EEPUObbA78b0YQ2DTCJXqr9g=" --flake /etc/nixos#validator

After that reboot machine and run

journalctl -u kuutamod.service -n 10 which should give you output like this

Run the following command but replace kuutamo_dewit.shardnet.pool.near with your own pool id

export NEAR_ENV=shardnet
nix run github:kuutamoaps/kuutamod#near-cli generate-key kuutamo_dewit.shardnet.pool.near
nix run github:kuutamoaps/kuutamod#near-cli generate-key node_key

Update key files

sed -i -e 's/private_key/secret_key/' ~/.near-credentials/shardnet/kuutamo_dewit.shardnet.pool.near.json ~/.near-credentials/shardnet/node_key.json

Install key files

sudo install -o neard -g neard -D -m400 ~/.near-credentials/shardnet/kuutamo_dewit.shardnet.pool.near.json /var/lib/secrets/validator_key.json

sudo install -o neard -g neard -D -m400 ~/.near-credentials/shardnet/node_key.json /var/lib/secrets/node_key.json

Restart kuutamo

systemctl restart kuutamod

Check metrics

curl http://localhost:2233/metrics

Check nix os version

check logs

check status

Now you can add more nodes for failover support by updating kuutamod.nix file like

{

  # Same as above, this needs to be an interface should be used to connect to your other machines
  # If you've come from the AWS testnet guide, note you may need to change this.
  services.consul.interface.bind = "enp24s0f0";

  # this now needs to be increased to the number of consul nodes your are adding
  services.consul.extraConfig.bootstrap_expect = 3;

  # We allow these ports for our consul server. Here we assume a trusted network. If this is not the case, read about
  # setting up encryption and authentication for consul: https://www.consul.io/docs/security/encryption
  networking.firewall = {
    allowedTCPPorts = [
      8301 # lan serf
      8302 # wan serf
      8600 # dns
      8500 # http api
      8300 # RPC address
    ];
    allowedUDPPorts = [
      8301 # lan serf
      8302 # wan serf
      8600 # dns
    ];
  };

  # add here the ip addresses or domain names of other hosts, that you want to add to the cluster
  services.consul.extraConfig.retry_join = [
    "node0.mydomain.tld"
    "node1.mydomain.tld"
    "node3.mydomain.tld"
  ];

  # Everything below stays the same.

  # This is the URL we calculated above:
  kuutamo.neard.s3.dataBackupDirectory = "s3://near-protocol-public/backups/testnet/rpc/2022-07-13T11:00:40Z";

  # We create these keys after the first 'nixos-rebuild switch'
  # As these files are critical, we also recommend tools like https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix
  # to securely encrypt and manage these files. For both sops-nix and agenix, set the owner to 'neard' so that the service can read it.
  kuutamo.kuutamod.validatorKeyFile = "/var/lib/secrets/validator_key.json";
  kuutamo.kuutamod.validatorNodeKeyFile = "/var/lib/secrets/node_key.json";
}

Check on your other nodes

Episodes

1. ___________Phantom near
2. _______Attack of the referrals
3. ______Revenge of the near gith
4. ____A new staking pool validator
5. __Ping.sh and crontab -e strike back
6. _Return of the concepts consolidation
7. Phantom near

To create your shardnet (testnet) wallet, simply go to shardnet wallet page and press Create Account. After that type your preferred account name and press “Reserve My Account ID” if the name is available.

Mine is already taken, so I’ll use another one as an example.

Next generate your wallet passphrase.

Copy seed phrase, save it securely and press continue. After that insert word number “N” from the 12 words sid phrase you copied previously ( 4th word in my case ) and press Verify & Complete.

Once account it is verified and created your would need to paste the whole seed phrase and login

You will see the screen like this

Keep in mind

Note that your balance might be zero. You can still continue in that case to the episode 4 — staking pool creation. Also it might worth checking out official discord #stake-wars-announcements #stake-wars-tokens_delegation channels.

And that’s it for wallet creation, lets continue.

2. Attack of the referrals

For this testnet I’m using Hetzner as a server provider. It offers great service, recommended by the challenge organizers and using this link to register will give you 20 euro signup bonus. Once registered make sure you selected Cloud in the drop down list top of the page

Add new project by clicking NEW PROJECT and give it some name, for example

Once it is done click ADD SERVER, leave defaults options at the top

And choose a server and press press CREATE & BUY NOW

Currently minimum system requirements according to official docs are 4CPU and 8GB Ram, but from my observation at the moment of writing having less than 16GB Ram won’t let you process chunks in time. So I would go with CX51. Good news is that you do not pay in advance, but according to your usage time. So if you host it for 15 days you will only pay half of the price — approximately 18 euro. Also there is always an option to downgrade your existing server to cheaper version as long as storage size doesn’t change.

Once it’s is created and ready you will get an email with ip and password of your server.

To access it you would need to run a terminal on mac

Or download terminal emulator for windows, for example MobaXterm or Putty.

Once terminal is open connect to your server by running

ssh root@your_ip

type yes and hit enter if this is your first connection to the server, type your password and hit enter. Note, while typing your password it will look like nothing happens and you won’t see it’s length, but that’s fine, type it, trust your instincts and let the near guide you

For example

Next let’s install all required software to your newly created machine.

3. Revenge of the near gith

To install near software, first let’s update preinstalled software by typing

sudo apt update && sudo apt upgrade -y

This could take several minutes to complete and will look something like

Next let’s install near software and all it’s dependencies (copy the whole command)

curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash - && sudo apt install build-essential nodejs -y && PATH="$PATH" && sudo npm install -g near-cli && echo 'export NEAR_ENV=shardnet' >> ~/.bashrc && echo 'export NEAR_ENV=shardnet' >> ~/.bash_profile && source $HOME/.bash_profile

Check components installed correctly by running:

node -v

near proposals

Should give an output like this

We will discuss later (in episode 6) what this means.

Now let’s install even moreee software that will help us run different commands later

sudo apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev libdw-dev libiberty-dev cmake gcc g++ python3 docker.io protobuf-compiler libssl-dev pkg-config clang llvm cargo python3-pip clang build-essential make jq && USER_BASE_BIN=$(python3 -m site --user-base)/bin && export PATH="$USER_BASE_BIN:$PATH" && export RUSTUP_INIT_SKIP_PATH_CHECK=yes && curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh && source $HOME/.cargo/env

Once you see this screen hit enter to continue with the default installation

Download near node source code with the latest recommended updates

git clone https://github.com/near/nearcore && cd nearcore && git fetch && commit=$(curl https://raw.githubusercontent.com/near/stakewars-iii/main/commit.md) && git checkout $commit

Build and initialize source code

cargo build -p neard --release --features shardnet && ./target/release/neard --home ~/.near init --chain-id shardnet --download-genesis && rm ~/.near/config.json && wget -O ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/shardnet/config.json && cd ..

Add public address to config to improve validators to validator communication

public_addr="$(jq -r .public_key .near/node_key.json)@$(wget -U curl -qO- ifconfig.me):24567" && new_config=$(jq '.network=(.network + {"public_addrs": ["'$public_addr'"]})' .near/config.json) && echo -E "${new_config}" > .near/config.json

Link your validator to your wallet by typing

near login

Copy generated link and paste it to your browser

You will see the following page, click next

Click connect

Enter your account id and press Confirm

Wait until you see

Go back to your terminal and insert your account id one more time in the terminal and hit enter

Check key for your account is created by typing

ls -lah .near-credentials/shardnet/

Next lets start your validator

4. A new staking pool validator

To start validator, first let’s save your account alias to reuse it in scripts later. As an example for this article we will use dewit but you should replace it with your own alias.

export NEAR_ACCOUNT_ALIAS=dewit

Next create validator key json file

near generate-key $NEAR_ACCOUNT_ALIAS.factory.shardnet.near && sed -i "s/$NEAR_ACCOUNT_ALIAS.shardnet.near/$NEAR_ACCOUNT_ALIAS.factory.shardnet.near/" ~/.near-credentials/shardnet/$NEAR_ACCOUNT_ALIAS.shardnet.near.json && cp ~/.near-credentials/shardnet/$NEAR_ACCOUNT_ALIAS.shardnet.near.json ~/.near/validator_key.json

Now, when everything is configured let’s create a near service to control your node in a generic way, attempt to restart it on failure and start after server reboot automatically

wget -O /etc/systemd/system/neard.service https://raw.githubusercontent.com/stanisloe/near-stake-wars/main/neard.service && systemctl enable neard

To start your node run

systemctl start neard

You should give it some time to sync, to check the logs you can type

journalctl -n 100 -f -u neard

and check that there is no downloading headers message like on a screenshot above. To exit press

control + c

on mac

ctrl + c

on windows.

If you have enough near in your wallet — 30 in the current case, you can create your staking pool validator with 5% commission

near call factory.shardnet.near create_staking_pool '{"staking_pool_id": "'$NEAR_ACCOUNT_ALIAS'", "owner_id": "'$NEAR_ACCOUNT_ALIAS.shardnet.near'", "stake_public_key": "'$(cat ~/.near/validator_key.json | jq -r '.public_key')'", "reward_fee_fraction": {"numerator": 5, "denominator": 100}, "code_hash":"DD428g9eqLL8fWUxv8QSpVFzyHi1Qd16P8ephYCTmMSZ"}' --accountId=$NEAR_ACCOUNT_ALIAS.shardnet.near --gas=300000000000000 --amount=30

Wait for transaction to propagate and if it was successful write this command to check if your proposal was accepted.

near proposals | grep $(echo $NEAR_ACCOUNT_ALIAS)

To make your validator active-first run this command to get info about seat price

near validators current | grep "seat price"

This should give you output like this

In our case the price is 200, so let’s save it like

export SEAT_PRICE=200

and delegate tokens to your pool

near call $NEAR_ACCOUNT_ALIAS.factory.shardnet.near deposit_and_stake --deposit $SEAT_PRICE --accountId $NEAR_ACCOUNT_ALIAS.shardnet.near

Note the seat price is dynamic, so if you have more credits available-use them, but leave something for commission.

If everything was successful you should find yourself in the output here

near validators current | grep $(echo $NEAR_ACCOUNT_ALIAS)

5. Ping.sh and crontab -e strike back

Lets learn how to keep your validator up and running.

Create directories

mkdir /root/scripts /root/logs

Create ping script

wget -O /root/scripts/ping.sh https://raw.githubusercontent.com/stanisloe/near-stake-wars/main/ping-template.sh && sed -i "s/%alias%/'$NEAR_ACCOUNT_ALIAS'/" /root/scripts/ping.sh && chmod 777 /root/scripts/ping.sh

Now let’s practice some jedi tricks:

crontab -e

If you run this command for the first time, the following message will pop up

Press 2 and hit enter.

To go to the end of file press:

Shift + g

Press letter o, to move your cursor to the new line and start editing file

Copy this line

0 */2 * * * sh /root/scripts/ping.sh

And press control + v to paste it. To exit and save changes — press Esc and the following characters from your keyboard sequentially

:wq

Should look something like this

Hit enter and the job is done.

If this didn’t work for you and you feel something like this

you can always fallback to nano editor by typing

select-editor

and choosing the first option.

Some of the useful for troubleshooting commands:

To check the logs

journalctl -n 100 -f -u neard

Check your node version: Command:

curl -s http://127.0.0.1:3030/status | jq .versio

Check Delegators and Stake Command:

near view $NEAR_ACCOUNT_ALIAS.factory.shardnet.near get_accounts '{"from_index": 0, "limit": 50}' --accountId $NEAR_ACCOUNT_ALIAS.shardnet.near

Check Reason Validator Kicked Command:

curl -s -d '{"jsonrpc": "2.0", "method": "validators", "id": "dontcare", "params": [null]}' -H 'Content-Type: application/json' 127.0.0.1:3030 | jq -c '.result.prev_epoch_kickout[] | select(.account_id | contains ("'$NEAR_ACCOUNT_ALIAS'"))' | jq .reason

Check Blocks Produced / Expected Command:

curl -s -d '{"jsonrpc": "2.0", "method": "validators", "id": "dontcare", "params": [null]}' -H 'Content-Type: application/json' 127.0.0.1:3030 | jq -c '.result.current_validators[] | select(.account_id | contains ("'$NEAR_ACCOUNT_ALIAS'.factory.shardnet.near"))'

6. Return of the concepts consolidation

Lets recap what we just did and reinforce our knowledge.

After we rented a server and installed all necessary software there we used this command to check if near is installed correctly

near proposals

This command shows all active and non active validators that created a staking pool and executed ping. Each of them can have one of the following status:

Proposal(Accepted) — it could be either active or non active that is waiting for his seat price to satisfy current requirement.

Rollover — this is an active validator that was selected to a new epoch but haven’t executed ping command. We configured to run ping command every 2 hours, so this shouldn’t be an issue. Keep in mind that for each ping command there is a commission so you need some balance on your wallet.

Proposal(Declined) — this means you will be kicked out in the next epoch. There could be several reasons: you didn’t ping your node during the whole epoch, your seat price is lower than the price in next epoch, you missed a lot of chunks like this guy

Epoch — after producing specific amount of blocks epoch number is increased by 1. From my observations for the current testnet it takes about 7–11 hours to update epoch number. Some actions like becoming an active validator, unstake tokens from a delegator require several epochs to complete since transaction creation.

In episode 3 we inserted some weird link to the browser to s̶h̶a̶r̶e̶ ̶w̶i̶t̶h̶ ̶e̶v̶e̶r̶y̶o̶n̶e̶ ̶y̶o̶u̶r̶ ̶b̶r̶o̶w̶s̶i̶n̶g̶ ̶h̶i̶s̶t̶o̶r̶y̶ actually link your wallet with your server so that you can perform any actions there are on ui from your terminal: stake near, send near etc.

Also in the same episode we converted near code to something your server can understand and run. When the new code with fixes and improvements from the team is available (recommended commit is updated) we should repeat the same procedure. This could be done with the following command:

cd /root/nearcore && git fetch && commit=$(curl https://raw.githubusercontent.com/near/stakewars-iii/main/commit.md) && git checkout $commit && cargo build -p neard --release --features shardnet && cd ..

wait until it is finished and restart your node

systemctl restart neard.service

Note that sometimes this won’t be enough and extra actions should be done like updating config file, removing data folder etc.

And that’s it for now. Hopefully after going through the article near will be always with and you will embrace the shardnet side of the chain. If you found it useful don’t be shy to hit the 👏 button or delegate some test near tokens to my staking pool: dewit.factory.shardnet.near

If noticed some issues or a question you have, a comments section or my discord: sanchous#5793 can use.