zerodao / melodot

Melodot is designed as a data availability layer for GB-level data throughput.

1. Introduction

Melodot is designed as a data availability layer for GB-level data throughput, featuring:

1. Utilizes KZG commitments to ensure data is correctly encoded.
2. Incorporates "farmers" so the system doesn't rely on the "minimal honest sampler" assumption.
3. Distributively produced, achieving complete decentralization.
4. Distributive data storage for availability.
5. Validators act more like light clients, making it easier for sharding.

Melodot is actively under development; modules and interfaces are subject to significant changes. More details can be found in the documentation.

2. Building

Setup rust

Install Rust:

curl https://sh.rustup.rs -sSf | sh

You will also need to install the following packages:

mac

brew install cmake pkg-config openssl git llvm

Known Issue: Currently, it is not possible to compile on Mac. We will address this issue later.

Linux

sudo apt install cmake pkg-config libssl-dev git clang libclang-dev protobuf-compiler

More：Melodot is based on Substrate, for more information please go to Substrate.

Build

1. Compile the melodot-node

make build-default

2. Compile the light node, which may automatically install the sqlite database:

make build-light

3. Compile the farmer node, which may automatically install the sqlite database:

make build-farmer

3. Run

You can start a development chain with:

make run-dev

To launch a light node:

make run-light-dev

You can also start a farmer node:

make run-farmer

4. Development

Test All

Use the following command to run all tests:

make test

You can learn more detailed testing methods from the testing guide , light client testing guide and farmer testing guide.

5. Docker

Start a Docker container:

./scripts/docker_run.sh

You can learn more about Docker examples from the testing guide and light client testing guide.

Reference

• Melodot Whitepaper
• substrate
• kzg-rust
• subspace

melodot's Issues

Commitment of Row Commitments Only in Block Headers

The current block headers contain commitments for all rows as well as the index for App_id, leading to excessively bulky block headers. In a fully loaded state, the commitments alone can reach up to 128kb. Moreover, after sharding, we must include "commitments only". We should aim to include only the commitment of row commitments and the number of rows in the block headers. This approach requires hashing all row commitments, thereby losing homomorphic properties, but this is inconsequential in our current context.

This change will primarily affect light clients and not validators, as validators can access the actual commitments from storage. Hence, the actual data is more inclined towards using DHT (Distributed Hash Table) rather than Gossip.

Upgrade Dependency to Polkadot-v1.5.0 and Resolve Upstream Compilation Issues

pgrade our project's dependency to the Polkadot-v1.5.0 version. Additionally, address and resolve the compilation issues found in the upstream as detailed in the following pull request: paritytech/polkadot-sdk#2217.