Ganache-like node

[MaksymZavershynskyi]

Motivation

We need a lightweight version of the nearcore node that will be used in the following situations:

• As part of the testing framework to test contracts;
• In integration tests of various L2 components and Applayer, e.g. bridge, near-api-, near-sdk-;
• By the developers during their development process to allow rapid iterations as they are tinkering with the node.

Based on the above requirements the node need to satisfy the following criteria:

• It needs to support interfaces needed by near-api-* and near-sdk-*, i.e. it needs to implement RPC interface and needs to have full support for contract execution;
• It needs to implement the protocol, including runtime, epoch manager, economics, and consensus;
• it needs to allow fine-grained control over: block production (produce one block, produce 10k blocks, roll it back), time (fast-forward 5 hours or five days), various adversarial scenarios;

It might potentially need to support:

• Emulation of sharding (we might need to wait with supporting it until we have launched sharding);

It does not necessarily need to support:

• Networking;
• 3rd party database, like RocksDB;
• Node synchronization;
• Garbage collection;
• Transaction routing;
• Concurrency (i.e. it can run in a completely blocking mode without multithreading, Actix or Tokio);

Note, while there is not direct incentive to explicitly not include the above components into the node, not including them might significantly reduce the number of the dependencies, speed up compilation time, and potentially even allow the node to be compiled into Wasm to be run as part of devtools or near-api-js. If it does not allow compilation to Wasm then we would have to maintain https://github.com/nearprotocol/nearcore/tree/master/runtime/runtime-standalone which wouldn't be supporting RPC, full protocol spec. The are advantages of trying to make the standalone node compile to Wasm:

• We don't need two versions of the standalone runtime;
• It is a path towards Wasm light client, which nice since people will be able to run lightclient from the browser (like Substrate light client). This might also be useful for portability and to have a completely trustless near-api-js;
• To be able to compile it to Wasm we would need to carefully refactor the code which might actually improve its quality and help with testability overall, by separating concurrency from everything else.

Proposed design

@SkidanovAlex proposed to directly repurpose the fact that nearcore node has an adversarial RPC API that allows fine grain control of the node. Here is his proposed plan for Ganache-node:

1. Assign one person to eliminate each occurrence of Utc::now() in the server, and propagate time from upstream; Only at the highest level should Utc::now be computed and passed down;
2. Make an adversarial-flag protected class that allows using custom time that is set from an adversarial-flag protected RPC end point;
3. Make adversarial-flag protected end points to produce block, and other actions that are needed;
4. In pytest the node is always compiled with the adversarial falg, so all those will be avialble.

We might start with working towards this initial design implementation and later work towards the case when it is a non-concurrent Wasm-compilable node.

WDYT?

[bowenwang1996]

Would single node suffice or is there some need for having multiple nodes?

[ailisp]

Single node

[vgrichina]

I think it's best if we keep as close to real node as possible (including RocksDB, etc) as long as we can tune parameter to get good enough performance (e.g. by reducing block production time) and provide debug APIs like save/rollback state, fast forward time, etc.

Making WASM-runnable node seems like more or less independent project which needs more significant effort.

[austinabell]

I don't currently see a way to configure the underlying store through nearcore, if there is a way, can someone link me to this or indicate it is possible?

My intuition would be that the store would be nice to be just in-memory/temporary to avoid cleanup and perform quick actions for a lot of use cases. I suppose maybe at least changing the default directory for the store when compiling this feature, and perhaps having the default to /tmp as a consideration?

[ailisp]

neard use neard --home <homeDir> init/run to init/run with a given home dir, and store is always in homeDir/data. You can specify /tmp/near-temp-home` for a temporary home use cases

[austinabell]

neard use neard --home <homeDir> init/run to init/run with a given home dir, and store is always in homeDir/data. You can specify /tmp/near-temp-home` for a temporary home use cases

Sorry, I just mean to change this default for the ~neard-ganache feature so that there isn't overlap, unless the overlap is intentional. I just assumed it wouldn't be ideal because there would be overlap when you try to start the actual node.

[ailisp]

Yeah this should use a different default for neard, maybe /tmp/neard-ganache<timestamp> at each run

[olonho]

Agree, having neard standalone mode with REST interface seems to be the best. We need to decide on how we'd better emulate rest of the blockchain, shall we be able to snapshot the actual state of the chain and be able to rune node on it. To me it seems rather natural approach, which would simplify testing and debugging.

[ailisp]

it needs to allow fine-grained control over: block production (produce one block, produce 10k blocks, roll it back), time (fast-forward 5 hours or five days), various adversarial scenarios;

Some of the features such as produce N blocks are (Max also mentioned) available via adversarial feature. But this feature is specifically designed for simulate malicious node in chain test, therefore I decide to make contract developer facing ganache-like features under feature ganache, although some may call existing adversarial code as implementation.

It is a path towards Wasm light client, which nice since people will be able to run lightclient from the browser (like Substrate light client). This might also be useful for portability and to have a completely trustless near-api-js;

Should we compile wasmer to wasm, and that is running wasm in browser wasm runtime (wasm in wasm) or implement a contract-runtime on top of browser native wasm runtime

@SkidanovAlex proposed to directly repurpose the fact that nearcore node has an adversarial RPC API that allows fine grain control of the node. Here is his proposed plan for Ganache-node:

I generally agree, except I think it should be under different feature name: ganache for contract developer facing features, adversarial is still using in chain tests by core team. And ganache feature node does a self detect to prevent itself join testnet/mainnet

[MaksymZavershynskyi]

Should we compile wasmer to wasm, and that is running wasm in browser wasm runtime (wasm in wasm) or implement a contract-runtime on top of browser native wasm runtime

It is a very far future, so let's not worry about it :)

[MaksymZavershynskyi]

CC @austinabell

[austinabell]

Maybe also worth discussing how the initialization of state would happen if a user wanted to start from a snapshot or import state at runtime. Would either/both be supported? If so, would this import happen through a file, through some HTTP/stream call directly into the store, and/or some other transport? I suppose it could also re-use the state of a nearcore db in some way.

Might be worth defining and deciding how any export functionality would be exposed or what would be a provider for the exports.

This might be out of the scope of the initial implementation, if it's only required to start with a fresh state for the initial version.

[ailisp]

Both are supported. see the "How is the exported state imported from neard-ganache?" in design google doc

[austinabell]

my apologies, I didn't notice the new section was added, thanks for linking :)