Hi, I'm Frankie from the R&D group or R&D group of your friendly extension MetaMask. Today, we're going to present to you our vision for a network of Ethereum-like clients. You may know some of us from other projects in the decentralized space. We've been involved in Infura, MetaMask, IPFS, libp2p. So, I'm sure some of you are wondering how long does it take to sync a full Ethereum node?
Great question. In our experience, it takes anywhere from a couple hours to well over a week to sync a full node from scratch. Ethereum nodes are becoming more resource intensive. A full node uses gigabytes of storage. It uses significant amounts of IOs, so much so that it requires an SSD at the very least.
Also, synchronizing state takes a long time due to network issues and having to process every block to reconstruct the state. This and other issues is forcing users to rely on centralized infrastructure. What about light clients, you must be asking. Current light client implementations provide solutions to some of these challenges, but it's also introduces its own limitations. Relying on good nodes for most of its data, light clients are leeches in a peer-to-peer network sense.
They don't seed any data. They require syncing state before becoming usable. This isn't as resource intensive as syncing a full node, but it's still an important limitation that regular users aren't necessarily willing to bear. Imagine a user having to wait minutes before using her favorite app in a time where web page loads are measured in milliseconds. This is not acceptable UX.
On top of that, devp2p relies on UDP and TCP for data transfer and node discovery, which makes it inherently incompatible with the browser. MetaMask is an important part of the ecosystem. It's responsible for helping drive the adoption of Ethereum. Users rely on MetaMask to interact with the Ethereum blockchain from dApps to tokens to transferring ether directly. But MetaMask, as well as other similar tools, rely heavily on centralized infrastructure, such as things like Infura and other other services.
This was instrumental for bootstrapping the Ethereum ecosystem, but this breaks the premise of decentralization, and now we need to do better. The problem is building decentralized client that has the same performance characteristics that centralized infrastructure offers. So, what are our light client requirements? We need a light client that is fast, ready to use in seconds, seeds its data to other peers so that it's not also relying on centralized infrastructure. Has native and has native browser support, of course, cuz we're MetaMask.
So, now I'd like to bring on Dima to talk about our solution, Mistikal. Thank you. Dima. Mistikal is a light client for the browser and more. It's a way of partitioning the Merkle tree into convenient we call slices.
It's a network of browser-based peer-to-peer nodes that help find and distribute slices. And it's a network of full nodes that provide the slices to the light client peers. Right now, these are dedicated nodes, but in the future, we're hoping to get this functionality to become part of the full clients. Stay tuned for an EIP. So, slices, what are they?
They're convenient portions of the tier Merkle tree. They're composed of the stem, which are the nodes traversed to reach the beginning of the slice. We call it the head. The Merkle tree nodes, leaf nodes which contain accounts, and a branch nodes. And for convenience, we also pack the EVM code and storage root for each smart contract account.
How do I identify a slice? We use the path, which is an offset into the tree, the first four nibbles of an address or storage key, the depth of the slice, which tells us how many levels we descend from the head, the state or storage roots, telling us which block the slice belongs to. Now, what's the Kintsugi network? Kintsugi is a network of peer-to-peer nodes that collaborate in distributing slices. We're using libp2p, a modular peer-to-peer network stack with native browser support.
It allows using a variety of mechanisms, from hybrid to full distributed, to create a peer-to-peer browser-based network. And not only that, it also enables a diversity of devices to connect to this network. From high-performance servers to low-resource devices, think IoT. We're also using PubSub for near real-time data propagation in the Kintsugi network. We've been using libp2p floodsub for internal prototyping, but we're exploring more efficient alternatives, such as episub, gossipsub, both from libp2p as well, Epidemic broadcast trees and other and others.
So, how does data propagation works in the Kintsugi network? Each peer in the network tracks a subset of slices and also seeds them to other peers. This is crucial to enable data availability across light nodes and this also reduces reliance on full Ethereum nodes. We use a combination of parameters to determine which slice the peers tracking. The user's account, dapps and tokens that the user interacts with, and also arbitrary slices that the client gets assigned based on a notion of cryptographic distance of the peer's hash and the slice hash.
So, how secure is this? When querying the state, the key is to know what's the canonical block header. It's a critical operation, but it's not necessarily a very intensive one. Resource intensive one, sorry. There are several ways to accomplish that.
We can ask a bootstrap node for a canonical block header, for example, block number 5,900,000 or something, and then start syncing from there. Or, just receive the block headers, verifying the number and the seal, of course, and then ask for its parent and the parent of its parent, so on and so forth, until you reach a trusted point. Or, you can subscribe to some of the network of to some network of trust. Not my favorite one. Or, you can always run your own node and request data over RPC.
That's a joke. We maintain security guarantees provided by Merkle trees. Slices contain all the required information to perform cryptographic verification. So, what are the takeaways? We have slices which are convenient but conveniently packed Merkle subtrees that contain state.
We had We have Kitsune, which is a peer-to-peer network of light clients seeding slices. And we have full nodes, Ethereum clients synchronizing state, making slices available for Kitsune. Thank you.
Automatic transcript — names and jargon may be misspelled.