📖
Mel docs
HomeOld docs
  • A post-blockchain Web3
  • Conceptual wiki
    • Data model
    • Consensus
    • MEL: trustless sound money
    • Governance-free neutrality
    • Covenants
    • Light clients
    • Network architecture
    • Melnet: the P2P layer
    • What belongs on-chain?
  • Developer guides
    • Overview
    • 🛠️Gibbername: your first off-chain composable protocol
      • melprot: a quick intro
      • Design
      • Implement
      • Use
      • Next steps
    • 💰Wallets
      • Setup and installation
      • Sending money
      • Swapping tokens
    • 🪙Getting tokens
      • Melmint overview
      • Using melminter
      • Melmint arbitrage
    • 🤖Run a full node
      • Melnode quick start
      • Basic replica node
      • Setting up a local simnet
  • 🌉Szaldi guide
    • Bridge your coins
    • Architectural overview
  • Resources
    • Yellow Paper
    • Frequently asked questions
    • MelVM spec
Powered by GitBook
On this page
Edit on GitHub
  1. Conceptual wiki

What belongs on-chain?

PreviousMelnet: the P2P layerNextOverview

Last updated 2 years ago

Instead of stuffing as much functionality as possible into on-chain smart contracts, Mel's paradigm encourages using on-chain logic and data much more sparingly, with complex app logic and ecosystem composability happening off-chain. What exactly belongs on-chain then?

The answer is that for any decentralized app or protocol, the minimal root of trust should be implemented on the blockchain. This means

  • the smallest part of the system

  • on whose security the whole system's security depends upon

For example, consider an end-to-end encrypted chat app. Most parts of the app aren't actually security-critical. For instance, it isn't particularly important how secure the storage of in-transit messages are, since it's all encrypted anyway --- they could very well be put on some centralized cloud like AWS. But one part of the system is really important: the public key infrastructure (PKI), or the system that lets users know the public keys of other users. If this were centralized and insecure, end-to-end encryption could be entirely defeated through impersonation and attacks.

Thus, the PKI should be built with on-chain trust, either through custom on-chain logic or by leveraging some existing Mel-based protocol (e.g. an ENS-like secure naming system?)

More detailed advice on how to practically design the on-chain pieces of an off-chain composable protocol can be found in the .

man-in-the-middle
Gibbername tutorial