Deploy Blockchain Nodes On The Threefold Grid

Deploy Blockchain Nodes On The Threefold Grid

Hi Threefolders,

There’s so much that can be done on the Threefold Grid.
This post is an invitation to Threefolders.

We want to build a repertoire of all the blockchain nodes that can be deployed on the TF Grid, and then create accessible documentation for anyone to use.

Please let us know what you think.
Share with us your ideas and this list might just grow!

As @ParkerS pointed out in this post, some blockchain nodes are more accessible than others.

We also have great tutorials on how to deploy blockchain nodes, but the Grid has evolved since and thus some tutorials would need to be updated with the new Grid features, such as flists and the TF Playground.


List of Blockchain Nodes to Deploy on the Threefold Grid

Blockchain Nodes as Weblet Deployments

  • Presearch

Blockchain Nodes as Flist with a Micro VM

  • Neo
  • Dash
  • Ava
  • Matic
  • TomoChain
  • DigiByte
  • Hydra
  • Flux
  • Any idea? Please share your thoughts and the list will be updated

Tutorials and Methods

The Full VM Method

You can simply deploy a full VM on the TF Grid, for example, Ubuntu 20.04, and follow the standard blockchain documentation to deploy your blockchain node.

full_vm_tf-grid

For example, with AVAX, Ubuntu 20.04 can be used as the OS:

avax_blockchain

The VM+Flist Method

As @ParkerS stated in the post mentioned above, one of the easiest ways to deploy a blockchain node, is to take the docker file, turn it into an flist, and then deploy the flist via a micro vm on the Playground.

Note: when a flist is converted from a docker, it is then accessible on the TF Grid. You can find flists on the hub.grid.tf page.

tfhub

The tutorials would then be very similar, only the flist would change.
It would be very accessible and easy to understand for newcomers.
They would search: deploy blockchain XYZ, and find the corresponding tutorial.

Note: any docker can be converted in an flist, so we would convert all the dockers into flists to make the tutorials even easier.

General Steps to Deploy a Blockchain Node

Blockchain Nodes and Weblet Deployments

When there is a lot of interest for a given blockchain node, the Threefold Dev team could then make an even easier to use Weblet to deploy the node. A good example is the Presearch blockchain node.


This is the basic of what could be done. See this as a draft.

What do you Threefolders think?

If you’d like to see a specific tutorial for a given blockchain, tell us!


@randynho
@ParkerS

3 Likes

I’m working on a pretty sizeable tutorial project right with about 7 vms working together, and it gave me an idea, the grid is all about inclusion and support.

I think it would make a statement for the grid to have a node running on as many major blockchains as possible, not just as a way to attract utilization but as a statement of equal support for all projects.

I can write it up the next time I’m off but I had some conceptual ideas I wanted to share. We could create a Community managed project focused on the creation of “the grids” support network for other projects.

  • The initial stakes for these nodes would be crowd funded, donated, granted

  • any/all profits are reinvested to creation of further infrastructure

  • focus on blockchain support technology vs miners, ensuring the safety and reliability of all networks as a key guiding principle.

  • deployed nodes become examples of functional technology accompanied by tutorials, popular tutorials can become applets.

  • node/hosting requests can be submitted by projects, community members, choice of what nodes are deployed by community vote

I think it would be very worthwhile to have running examples of everything we can

3 Likes

Excellent project.

About the 3nodes hosting those loads, it would be amazing to have it set up with quantum safe file storage and IPFS. This would balance the load across different 3nodes, on the TF Grid, and if some 3nodes shut down, the load can go elsewhere.

I wonder if this would be possible with TF Grid 3.9

1 Like

I’m a little confused, qsfs, ipfs would only handle a storage workload as far as I understand it, I don’t know of any grid tech that could fail over a running vm, but we may be be able to create mirrors of each vm and have a load balancer that distributes the connection to whichever is up, that will just be dependent on how the nodes themselves operate,

1 Like

I’ve been pondering the same thing all day.

1 Like

I guess I was the one confused then.
I thought there might be some storage workload associated with deploying blockchain nodes.

My point is that we’d need a redundancy process if a node goes offline, so the blockchain node won’t be turned off.

“we may be be able to create mirrors of each vm and have a load balancer that distributes the connection to whichever is up” @ParkerS

This might work then.

I can say that blockchain node containers typically run really well in Kubernetes deployments on the TF Grid. The piece I didn’t have great success with was storing the data in distributed block storage via Ceph Rook, to be able to tolerate an outage of a node in terms of both the compute and storage piece. There are other block storage solutions I didn’t try which could be worth a look.

For a lot of use cases, running on a node with high uptime to begin with, then making some backups of the chain state and recovering manually in the event of a failure is probably good enough.

One of the coolest projects I’ve seen to address the underlying issue, which I think is a great fit for grid VMs, is Horocrux for Cosmos based validator nodes. It uses threshold signing to enable a set of nodes to cosign transactions from a single key in a way that’s both fault tolerant and also secure.

While there’s a lot we can do within the architecture of the grid to improve reliability and support high availability deployments, I see too how a next generation of peer to peer applications can provide these features for themselves. Blockchains and other networks which can innovate in such a way that they depend less on high availability hardware will be the best suited to scale globally, in my opinion.

After writing my last post, I refreshed my self a bit on the Horocrux documentation. This bit seems really salient to what we’re discussing:

Traditional high-availability systems where the keys exist on hot spares risk double signing if there are failover detection bugs. Low-availability systems, or manual failover, risk downtime if manual intervention cannot respond in a timely manner.

Failover is actually risky for proof of stake validators, because double signing is usually the most serious offense a validator can commit.

“It uses threshold signing to enable a set of nodes to cosign transactions from a single key in a way that’s both fault tolerant and also secure.”

These peer-to-peer applications are simply an amazing match with the Threefold Grid.
That’s a power use case that can be scaled.

Being able to deploy blockchain node workloads, peer-to-peer, and to redistribute the load to other 3nodes if certain 3nodes fail, makes the most out of the TF grid, blockchain technologies and peer-to-peer.

It is “worth a look”, agreed!