Launching a custom blockchain

Folks, I am a little confused by this creating a VM tutorial.

Say, I’d like to launch the same timestamp VM in the tutorial on a custom subnet with validators staking my new asset AVAT just for the fun of it.

Does that mean I need to fork the ava codebase, implement the timestamp VM and ask validators to build and run my fork? This sounds far from ideal. I need someone to sanity check here.

Also, how am I supposed to specify AVAT as staking asset to my subnet?
This API call does not seem to accept any staking asset ID. Is this going to be supported soon?

1 Like

can @kevin @gabriel or other members of the core team throw some light here?

At the moment there is no way to launch a custom blockchain without forking the AvalancheGo repo. Adding subnet functionality and allowing users to create custom blockchains are on our roadmap.

ok. is there a link to the official roadmap? I cannot locate it anywhere. cc: @jayksofue maybe

It’s here: https://www.avalabs.org/roadmap (Post Mainnet/VM Sandboxing)

I think the challenge is to allow VM with arbitrary rules without compromising node security (sandboxing).

Btw, I’d be very interested in hearing about the options explored so far. I was wondering if a separate node instance running the VM could do, with inter-node communication handled through the API. Probably not the most efficient, and OS dependent, but sounds like a possible first step.

(E.g: by sandboxing with firejail which provide a jailed environment and can set limits on resource usage)

That roadmap is a bit outdated, and we need to add additional things that we’re working on.

Are you talking about a separate subnet? It would be a huge challenge in a shared-security model, but in Avalanche the subnets are sandboxed, and they make their own security assumptions. It’s not possible for a subnet running some arbitrary VM to corrupt – say – the primary subnet.

I’m talking about custom VMs. These are written in Go just like the node. You can put malicious code in there that would disrupt the whole node functioning and thus affect the validation of other networks for that particular node. Then I assume you’d want to run custom VM code into its own compartment for security reasons. I’m pretty sure that’s what " VM Sandboxing" is about.

Got it yes. As a validator, if you choose to validate arbitrary subnets that could potentially have malicious code, you end up risking your node’s stability.

There are many virtualization techniques that one could use. One is to run each subnet in virtualized environments. Each of these environments only borrows some signing APIs from a master process (which stores keystore files), and nothing else.

1 Like

Our team is working on a public project. We are primarily evaluating the use of c-chain, custom subnet on top of evm and rpcchain with a custom vm.

In general, the ability to launch a custom blockchain is pretty exciting. Particularly the rpcchain integration looks very promising for custom blockchains that would fancy more than what solidity can provide. I am not yet convinced though this is a good idea for majority of public use cases out there. The distribution of a standalone vm, and security implication are big challenges imo. Sandboxing is not a magic wand either.

That said, there are gaps with every option in hand. It is not obvious how atomic swaps would work for instance. Some of this boils down to better documentation and some to better planning for there are some gaps in design & implementation.

This is where I tend to agree with @kevin. Roadmap is too high level and missing some of the works. It would be cool to have greater details about upcoming changes, plans.

3 Likes