melnode: Mel's reference implementation

Mel is a new public blockchain focused on security, performance, and long-term stability. melnode is Mel's reference implementation in Rust.

Installation

For security reasons, until we have reliable reproducible build infrastructure, the only official distribution channel for melnode is its source code package on crates.io.

Fortunately, installing melnode from source is extremely easy. First, make sure cargo is installed on your machine. Then, simply run

$ cargo install --locked melnode

This produces an executable melnode in ~/.cargo/bin/, which should already be in your $PATH.

Hardware Requirements

Minimum:

• 1-core CPU
• 4GB of RAM
• at least 200GB of free storage (SSD not necessary)
• 10 Mbit/sec download Internet service

Recommended:

• 4+ core CPU
• 16GB of RAM
• 200+GB of free storage on a fast device (SSD, RAID array, etc)
• 50+ Mbit/sec up/download Internet service

Full nodes replicate every consensus-confirmed block, validating its contents and ensuring network security while providing a local cache of the entire blockchain state. Running a full node helps contribute to the security and (read) performance of the network.

There are two kinds of full nodes:

• Replica nodes comprise the vast majority of full nodes. They replicate and verify blocks but do not vote in consensus.
• Staker nodes, the ultimate guardians of Mel security, have SYM locked up and participate in consensus. They are analogous to miners in proof-of-work blockchains like Bitcoin.

Auditor Full Node

On the Mel Mainnet:

To run an replica on the “mainnet” (which at the moment is far from stable, but does have a persistent history), just run:

$ melnode

melnode will then beginning synchronizing all the blocks in the blockchain. This will take quite a while (a day or so) and store a bunch of data in in ~/.melnode/.

On the Mel Testnet:

To run the replica on the non-persistent testnet, where most covenant development and testing will happen during the betanet period, run instead

$ melnode --bootstrap tm-1.themelio.org:11814 --testnet

Note that two things were needed to connect to the testnet:

• Connecting to a testnet bootstrap node (this is the first server your full node talks to)
• Specifying --testnet, to use testnet validation rules

Configurations

You can change the configuration of an replica node with the following flags:

``` --bootstrap ... Bootstrap addresses. May be given as a DNS name [default: mainnet-bootstrap.themelio.org:11814]

--database Database path [default: /tmp/themelio-mainnet]

--listen Listen address

--testnet Use testnet validation rules

--override-genesis If given, uses this YAML file to configure the network genesis rather than following the known testnet/mainnet genesis ```

Local simnet support

Note: there will soon be a tool to automatically generate these configurations.

We can configure a simnet --- a "fake" network local to our computer --- by the combination of three options:

• --bootstrap 127.0.0.1:11814 to bootstrap only with ourselves instead of any remote node

• --override-genesis network-config.yaml, where custom-config.yaml contains configuration for a custom network of the following form:

  ```yaml network: custom02 # anything from custom02..custom08

  specifies the "initial stash" of money in the genesis block

  init_coindata:

  what address gets the initial supply of money

  covhash: t5xw3qvzvfezkb748d3zt929zkbt7szgt6jr3zfxxnewj1rtajpjx0

  how many units (in millionths)

  value: 1000000

  denomination

  denom: MEL

  additional data in the UTXO, as a hex string

  additional_data: ""

  specifies all the stakers with consensus power.

  we need to specify ourselves in order to produce any blocks; "themelio-crypttool generate-ed25519" (install via cargo) can generate a keypair for us

  stakes: deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef: pubkey: 4ce983d241f1d40b0e5b65e0bd1a6877a35acaec5182f110810f1276103c829e estart: 0 epostend: 100000 # essentially never end the stake symsstaked: 10000 # does not matter

  Initial fee pool

  initfeepool: 10000

  Initial fee multiplier

  initfeemultplier: 1 ```

• --staker-cfg staker-config.yaml must contain a staker configuration like this:

  ```yaml

  secret key; must correspond to "stakes.dead[...]beef.pubkey" in the network config

  signing_secret: 5b4c8873cbdb089439d025e9fa817b1df1128231699131c245c0027be880d4d44ce983d241f1d40b0e5b65e0bd1a6877a35acaec5182f110810f1276103c829e

  address for staker-network communication, this can be arbitrary

  listen: 127.0.0.1:20000

  must be same as "listen"

  bootstrap: 127.0.0.1:20000

  where block rewards are sent

  payout_addr: t5xw3qvzvfezkb748d3zt929zkbt7szgt6jr3zfxxnewj1rtajpjx0

  vote for this fee multiplier (higher values charge more fees)

  targetfeemultiplier: 10000 ```

A more detailed explanation of --staker-cfg requires explaining the staker and consensus system, as follows:

Staker Full Node

On the Mel Mainnet:

WIP

On the Mel Testnet:

WIP

Configuration

WIP

Contributing

Thank you for considering contributing to the Mel source code! We welcome all contributions from absolutely anyone on the internet.

For minor changes, simply fork, fix, and submit a pull request. If you want to propose a larger change, be sure to get in touch with our dev team on Discord to make sure your change aligns with Mel's overarching philosophy. This will likely save you a significant amount of time and effort, as well as speed up the review process of your change.

Finally, make sure your code adheres to the following guidelines:

• Your code must adhere to the official Rust style guide
• Your code must be documented per the official Rust documentation guidelines
• Pull requests must be based on and opened against the master branch
• Commit messages must be descriptive
• Any protocol changes (whether consensus-breaking or not) must start as a TIP (e.g. TIP-101)

License

The license of the project is the Mozilla Public License, version 2.