Documentation of this Project

[ghost]

Documentation of this Project

Overview

Mustekala is the name of the Ethereum Light Client project of Metamask.

Motivation

State of the art

• As of 2018.06.06, MetaMask relies on RPC communications with either the user's local node, the INFURA service or a custom remote node.
• The functionalities obtained via RPC can be grouped as
  • Obtention of Ethereum Data (State, Storage and Indexes)
    • Example: Last Block
    • Example: Account balance query
    • Example: Logs
  • Execution of code in the EVM
    • Example: Token operations
  • Broadcasting of transactions to Ethereum's Network devp2p
    • To be minted into a block

Current Challenges

• As of 2018.06.06, the required blockchain storage for a full archive node is 1 TB. This can be mitigated by having fast synchronization, requiring the current plus some recent states, to a figure near 10 to 20 GB, both cases being really intensive in storage.
• Moreover, the process of synchronizing can be very demanding on IOPS: Instead of pulling each block header from devp2p, checking which elements of the state changed, and pulling this delta, what nodes do is to execute each transaction over the state.
• Light clients only synchronize the canonical chain block headers and pull the exact elements of the state, plus their merkle proofs. However the light client protocol is not part of the common protocol ran via the majority of nodes, i.e. a node has to be willing by configuration to run this protocol and admit a certain number of light clients to consume its data.
• Both fast synchronized nodes and light clients will ignore or prune past state data, which is not convenient to certain Dapp developers who rely on indexes such as logs in the blockchain.
• The discovery process of devp2p does not guarantee "good nodes", i.e. nodes synchronized to the current block, willing to connect and share its information to the requester.
• Finally, as the managing and maintainance of synchronized ethereum nodes becomes a burden for users, they become dependent to external services to provide that facility. Economies of scale are needed to run such infrastructure, which in turn, converge to some form or other of centralization.

TLDR

The current network devp2p is broken

• Is hard to discover useful peers
• Is hard to get just the data you want
• Do you want to run a quick script to "just hook you up to any node in the network and be able to know your favorite token balance?" YOU CAN NOT, sorry

The proposal of Mustekala

• Make your browser a peer of a million p2p network
  • We name our fox network kitsunet
• Easily discover other peers to consume and share ethereum data
• Easily set up Hubs in your laptop or server to boost the data availability
  • These DO NOT need to synchronize the whole state (GBs), but only the elements you need
• By using libp2p, you can easily write your program to consume the data you want
• By implementing IPLD, every tiny bit of ethereum information can be accessed instantly

Advantages of this approach

• Data availability at face value
• Easy consumption of information
• More devices able to interact with the blockchain
• Expand the horizon for Dapps

Even More!

• Migration from devp2p to libp2p as the de-facto network for ethereum
• Cattle vs Pets approach for providers of data
• Insanely fast synchronizations

Architecture

The following 4-layer architecture comprises the project:

• Layer 1: devp2p data sources
• Layer 2: IPFS Bridges and Hubs
• Layer 3: Kitsunet Peers
• Layer 4: Content Routing System

A more thoroughly discussion is in this document

MVP

The concept is straightforward: Get the data from an Ethereum node, dump it into IPFS, consume it in a browser peer.

More of this point in this document

Beyond MVP

A plethora of scaling challenges and use cases emerge from the MVP, including (but not limited to)

• Extend the mainstream ethereum clients to kitsunet (share and consume data)
• Multi Blockchain support
• IoT devices

The comprehensive reference in this file

Sprints

List of Sprints: Dates and Goals

Other

• Roadmap 2017.07.04
• Roadmap 2018.02.22
• RPC Methods used by MetaMask