# Gibbername: your first off-chain composable protocol

## On-chain vs. off-chain composability

The best way of understanding **off-chain composability**, Mel's new paradigm for the blockchain ecosystem, is to contrast it with the way Web3 is right now. Right now, smart contracts using standard APIs like ERC-20 form a pretty nice interoperable on-chain ecosystem, enabling applications like complex DeFi instruments beyond what's possible with first-generation blockchains like Bitcoin.

But interacting with anything outside this smart contract ecosystem turns out to be *really* hard. For instance, let's say you heard that ENS is decentralized and trustless, so you want to use it to replace DNS in some off-chain decentralized protocol (maybe to name Tor hidden services?).

You might think that it'll be a nice drop-in replacement, since it's very easy to integrate ENS into on-chain contracts. But you would be very wrong: the names are stored "illegibly" in the ENS contract state, exposed only through an on-chain contract API. All of your options for calling this API from off-chain code are bad:

* **Sacrifice security:** just call RPC methods on some full node (with something like Web3.js), who you end up trusting completely. Just like with DNS, a centralized third party can now arbitrarily lie to you, censor you, etc. Oops!
* **Sacrifice scalability**: force all your clients to run their own Ethereum full node, that you then query using the same RPC methods. This is going to be impractical for almost any application.
* **Reverse-engineer the contract and hack together a hyper-fragile light client**: Ethereum does have *some* light-client support. So you can sorta-trustlessly query ENS names by disassembling the EVM code of ENS, figuring out where exactly in the blockchain state it stores name information, then craft the exact `getProof` calls needed to get the data in a verifiable way. But this is horribly complex and brittle. The smallest ENS governance upgrade can require you to re-reverse-engineer the EVM code, not to mention L1 issues like consensus-breaking upgrades and block reorganizations. You'll never compete against DNS's reliability and simplicity.

Furthermore, this "on/off-chain boundary problem" persists regardless of how much blockchains scale and how far we make protocols "crypto-native". Any web3 ecosystem has components like frontends, apps, and *human users* that fundamentally live off-chain while needing to securely talk to on-chain.

We need to solve this problem to have a truly successful Web3, with a rich ecosystem of secure decentralized protocols and apps outside of the blockchain. This requires a new kind of blockchain — Mel — that actually supports use as an off-chain root of trust. Features like a simple-to-implement protocol, a governance-free development model, and embeddable light clients cooperate to let off-chain programs efficiently utilize on-chain security.

More interestingly, on-chain logic for decentralized protocols plays a very different role. Instead of interoperating with on-chain code, *on-chain protocols are written for off-chain consumers*. Mel's overall data model lacks the entire concept of smart contracts calling each other, but it is supremely suited for encoding on-chain logic in a way that is legible and usable off-chain.

## What will we build?

To demonstrate that, we'll build **Gibbername**, a trivial DNS-like decentralized naming system that would serve as an exemplary citizen of an off-chain composable ecosystem. Gibbername allows you to

* **Register** a short, human-readable name. You won't be able to pick the name though, it will look something like `sublak-demfet`. (As we'll see, this makes the implementation really simple)
* **Bind** the name to any data you wish, like a DNS record or JSON document.
* **Transfer** the name to another person.

Like DNS, Gibbername will be very easy to integrate into apps, with a simple Rust library that allows for looking up and managing names. Unlike DNS, though, Gibbername will have three important, blockchain-backed "superpowers":

* **Identity retention**: without the consent of the current owner, nobody can change the name-to-data mapping or transfer the name
* **Censorship resistance**: nobody is able to prevent from name from resolving or prevent the current owner from updating or transferring the name
* **Permissionlessness**: nobody can stop name registrations

All the above properties will be upheld despite the fact that lookups, transfers, etc will all be initiated by off-chain code rather than on-chain contracts.