melnode

Crates.iomelnode
lib.rsmelnode
version0.20.8
sourcesrc
created_at2023-02-25 19:16:39.764253
updated_at2024-05-14 16:47:09.345814
descriptionReference implementation of Mel
homepage
repositoryhttps://github.com/mel-project/melnode
max_upload_size
id794513
size338,304
Eric Tung (nullchinchilla)

documentation

README

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>...
            Bootstrap addresses. May be given as a DNS name [default: mainnet-bootstrap.themelio.org:11814]

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

--listen <listen>                            Listen address

--testnet                                    Use testnet validation rules

--override-genesis <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:

    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
        e_start: 0
        e_post_end: 100000 # essentially never end the stake
        syms_staked: 10000 # does not matter
    # Initial fee pool
    init_fee_pool: 10000
    # Initial fee multiplier
    init_fee_multplier: 1
    
  • --staker-cfg staker-config.yaml must contain a staker configuration like this:

    # 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)
    target_fee_multiplier: 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.


Commit count: 1164

cargo fmt