We are excited to announce that now you can spin up a full node of Moon Rabbit blockchain inside docker. 

If you’re building dApps or products on the Moon Rabbit network, you might want the ability to run a node-as-a-back-end. After all, relying on your own local infrastructure is always better than a remote one in this brave new decentralized world. 

Before that release, the only way to interact with  Moon Rabbit mainnet was an RPC endpoint. With this update developers are now able to have their own unlimited RPC endpoint. 

Docker image and technical documentation located here: https://hub.docker.com/r/moonrabbitaz/node

The Docker image is preconfigured and ready to use out of the box with zero configuration from the developer side.  

Developers can use this image to interact with Moon Rabbit blockchain directly. There are a lot of use cases of that interaction – dApps that need a high TPS for RPC, or indexing tasks. 

Using your own blockchain node instead of relying on a public Remote Procedure Call (RPC) service offers several advantages that can significantly enhance your blockchain experience. While both options have their merits, here’s why running your own node might be the better choice:

• Decentralization and Trustlessness: Running your own node aligns with the core principles of blockchain technology – decentralization and trustlessness. By validating transactions and participating in consensus directly, you contribute to the network’s security and integrity, reducing reliance on a single central entity.

• Security and Privacy: Public RPC services are potentially vulnerable to attacks and data breaches. Running your own node allows you to control the security measures, such as firewalls and access controls, ensuring a higher level of protection for your node and your interactions with the blockchain.

• Data Ownership and Control: With your own node, you have full control over the data you access and generate. This can be crucial for privacy-conscious individuals, businesses, or projects that need to manage sensitive information.

• Reliability and Availability: Public RPC services might face downtime or restrictions due to high usage or maintenance. Running your node guarantees that you can always access the blockchain data and services without being dependent on the availability of external services.

• Customization: Public RPC services offer limited functionalities and might not support specific features or configurations you need. Running your node enables you to customize your setup to meet your requirements and experiment with new functionalities.

• Resource Allocation: When using a public RPC service, you share resources with other users, potentially leading to inconsistent performance. Running your own node allows you to allocate dedicated resources, resulting in more consistent and predictable performance.

• Network Insights: Operating your node grants you access to real-time network data and statistics. This information can be invaluable for understanding the network’s health, performance, and trends, aiding in decision-making and analysis.

• Supporting the Network: Running your node contributes to the overall strength and resilience of the blockchain network. It enhances decentralization by adding more nodes to the network’s infrastructure, ultimately improving its long-term sustainability.

• Developer Flexibility: If you’re a developer, running your node provides a platform for testing and debugging smart contracts and applications. You can experiment with various functionalities without the constraints imposed by a public RPC service.

• Learning Opportunity: Operating your node is an educational experience that deepens your understanding of how blockchain networks function. You’ll gain insights into protocols, consensus mechanisms, and network dynamics that can be valuable for personal growth or professional development.

While running your own node offers numerous benefits, it’s essential to consider the associated challenges, such as initial setup, maintenance, and potential resource costs. However, the advantages of enhanced security, control, and participation in the network often outweigh these challenges for those seeking a more comprehensive and robust blockchain experience.

Hardware requirements for running nodes are not high. This node does not participate in network consensus and only sync blocks and make it blockchain state available via local RPC

Minimum system requirements:

• 1 CPU,
• 2GB RAM,
• 20Gb of free space. 

Windows and Linux Docker distributions run with no additional setup. However, in case of trouble with Apple Silicon we prepared a solution:

---

Apple Silicon:

1. In Docker Settings -> General under the “Choose file sharing implementation for your containers“ subheading, select the VirtoFS option.

2. If you haven’t set Rosseta on your Mac, in your terminal run following command: softwareupdate --install-rosetta
Tip: You can skip the license agreement by providing an additional flag:
/usr/sbin/softwareupdate --install-rosetta --agree-to-license

3. Also in Docker Settings -> Features in development, check the option: Use Rosetta for x86/amd64 emulation on Apple Silicon.

4. Run terminal to pull Docker image:
docker run --platform linux/x86_64 -p 30333:30333 -p 9933:9933 -p 9944:9944 -v /tmp/mv2:/moonrabbit moonrabbitaz/node

---

When you start the node for the first time, you will see a similar screen:

Here you will see
Chain specification: Moon Rabbit   

This is the Moon Rabbit chain. Node can run multiple different chains and you want to make sure that you downloaded the correct node

Role: FULL 

Nodes can have different roles. 

An archive node stores all previous blocks and their states, making it possible to query the chain’s history at any time. Queries such as finding an account’s balance at a particular block or which extrinsics caused a specific state change are quick when using an archive node. However, an archive node requires a significant amount of disk space.

A full node prunes historical states: all finalized blocks’ states are older than a configurable number except the genesis block’s state. This is 256 blocks from the last finalized one by default. A pruned node this way requires much less space than an archive node.

Another type of node is a light node. A light node has only the runtime and the current state but does not store past blocks and so cannot read historical data without requesting it from a node that has it. Light nodes are useful for resource-restricted devices. An interesting use-case of light nodes is a browser extension, which is a node in its own right, running the runtime in WASM format, as well as a full or light node that is completely encapsulated in WASM and can be integrated into web apps.

Node identity 

Local node identity is: 12D3KooWRaVrC84JfJYyJnjxyva5YmmvbyNgeyQkvJjepfZ7fCJY

This is a unique id just for your node. This is something that you need to know if you want clients to be connected to your node. At a low level our nodes utilize libp2p to connect between nodes and share new block information, etc. 

You can read more about it here: https://docs.libp2p.io/concepts/fundamentals/peers/

Next console contains some basic information about your machine. This is not important for the process, but will help make sure that the hardware is properly installed.

The next important lines for us are the following:

Syncing	295.7 bps
Target	#10656209 (3 peers)
Best	#63353 (0xd448…53f8)
Finalized	#62976 (0xc2f8…c0ba)
Download	⬇ 201.7kiB/s
Upload	⬆ 0.7kiB/s

That describes the state of your node and status info. Here the node is in ‘syncing’ state, and has connections to 3 other nodes (via libp2p that was mentioned above). Blockchain contains  10656209 blocks and we now have 63353. Our syncing seed is 295.7 blocks per second.

Syncing is a long process and depends on your hardware. Usually it takes around one day to sync completely.