photo_2025-04-01_10-20-02 Modularity has been unfolding rapidly—execution, settlement, data availability, and consensus are all being unbundled. This customizability in combination with rollup frameworks and providers like conduit, caldera are pushing the appchain thesis forward. But this insane level of customizability is inherently incompatible with the way ZK is designed today. Right now, rollups either don’t use ZK at all or develop their own custom, siloed proving systems—the biggest ZK L2 projects all maintain massive teams of cryptography researchers and engineers just to sustain their ZK stacks. These systems are optimized for specific use cases like zkEVM and can’t be easily extended. That changes with the rise of high-performance RISC-V zkVMs like SP1 and prover networks like Succinct.

This week I am focused on learning about LES(Light Ethereum subprotocol), from what i have gathered so far with limited resources I have come across internet,is that they only download block headers as they appear and fetch other parts of the blockchain on-demand. They provide full functionality in terms of safely accessing the blockchain, but do not mine and therefore do not take part in the consensus process. Full and archive nodes can also support the 'les' protocol besides 'eth' in order to be able to serve light nodes. LES use Cononial Hash trie structure (specifically Patricia verkle tree) for quick initial syncing and secure on-demand retrieval of the Cononial Hash mapping, block headers and total difficulty values. The BloomBits data structure optimizes log searching by doing a bitwise transformation that makes it cheaper to retrieve bloom filter data relevant to a specific filter. When searching in a long section of the block history, we are checking three specific bits of each bloom filter per queried address/topic. In order to do that, LES must retrieve a ~550 byte block header per filtered block. BloomBits data is stored in compressed form. The compression algorithm is optimized for sparse input data which contains a lot of zero bytes. Decompression requires knowledge of the decompressed data length. Any node which takes on a server role in the the LES protocol needs to be able to somehow limit the amount of work it does for each client peer during a given time period. They can always just serve requests slowly if they are overloaded, but it is beneficial to give some sort of flow control feedback to the clients. This way, clients could (and would have incentive to) behave nicely and not send requests too quickly in the first place (and then possibly timeout and resend while the server is still working on them). They could also distribute requests better between multiple servers they are connected to. And if clients can do this, servers can expect them to do this and throttle or drop them if they break the flow control rules.

The Light Ethereum Subprotocol (LES) is the protocol used by "light" clients, which only download block headers as they appear and fetch other parts of the blockchain on-demand. They provide full functionality in terms of safely accessing the blockchain, but do not mine and therefore do not take part in the consensus process. Full and archive nodes can also support the 'les' protocol besides 'eth' in order to be able to serve light nodes. The current protocol version is les/4. See end of document for a list of changes in past protocol versions. Some of the les protocol messages are similar to of the Ethereum Wire Protocol, with the addition of a few new fields.

'eth' is a protocol on the RLPx transport that facilitates exchange of Ethereum blockchain information between peers. The current protocol version is eth/66. See end of document for a list of changes in past protocol versions. Basic Operation Once a connection is established, a Status message must be sent. Following the reception of the peer's Status message, the Ethereum session is active and any other message may be sent. Within a session, three high-level tasks can be performed: chain synchronization, block propagation and transaction exchange. These tasks use disjoint sets of protocol messages

This specification defines the RLPx transport protocol, a TCP-based transport protocol used for communication among Ethereum nodes. The protocol carries encrypted messages belonging to one or more 'capabilities' which are negotiated during connection establishment. RLPx is named after the RLP serialization format. The name is not an acronym and has no particular meaning. The current protocol version is 5. You can find a list of changes in past versions at the end of this document. Notation

The snap protocol runs on top of RLPx, facilitating the exchange of Ethereum state snapshots between peers. The protocol is an optional extension for peers supporting (or caring about) the dynamic snapshot format. The current version is snap/1. Overview The snap protocol is designed for semi real-time data retrieval. It's goal is to make dynamic snapshots of recent states available for peers. The snap protocol does not take part in chain maintenance (block and transaction propagation); and it is meant to be run

ZKSync-Crypto Java is a Java binding for native zks-crypto library. Installation: available via Maven Central package zkscrypto. Builds contain two versions: one for PC, and one for Android. example import io.matterlabs.zkscrypto.lib.ZksCrypto; import io.matterlabs.zkscrypto.lib.entity.ZksPackedPublicKey;

Overview The EVM is a stack-based virtual machine with an ephemeral memory byte-array and persistent key-value storage (persisted in a Merkle tree). Elements on the stack are 32-byte words, and all keys and values in storage are 32 bytes. Security The EVM is a security oriented virtual machine, designed to permit untrusted code to be executed by a global network of computers. To do so securely, it imposes the following restrictions: Every computational step taken in a program's execution must be paid for up front, thereby preventing Denial-of-Service attacks. Programs may only interact with each other by transmitting a single arbitrary-length byte array; they do not have access to each other's state. Program execution is sandboxed; an EVM program may access and modify its own internal state and may trigger the execution of other EVM programs, but nothing else.

xtingles is the premier marketplace for ASMR Tings, which you can collect, sell and trade. Blocto and xtingles are jointly airdropping their first NFT for downloading app and signing up. Note: You need to use a Mobile Device for joining this Airdrop Steps to claim Airdrop Download the Blocto App. Open the app and create your account using referral code TUSHYJ

What is EVM (Ethereum Virtual Machine)? EVM is a runtime environment for Ethereum blockchain. It allows smart contract code to run by compiling to EVM bytecode. EVM plays a core role in Ethereum blockchain to ensure a trustless mechanism without having any central administrator. EVM keeps each node systemically isolated from others in order to avoid security risks. Even if one node is compromised, it does not influence any other nodes and blockchain network. EVM ensures Ethereum blockchain to be secured. As called world computer, Ethereum can solve more complex computational logics differently from Bitcoin blockchain(it only can simply transfer money). EVM reads the code, calculates Gas, executes, and mines to record to Block. Again, it plays a core and essential role in Ethereum. Why do we need EVM? EVM enables smart contract(solidity) to be executed on any computer(OS agnostic). EVM is installed on the computer(operating system) and works as a middle layer between a smart contract and operating system. Once Solidity code is compiled to bytecode, EVM can read to execute. If you are a developer, JVM(Java Virtual Machine) might let you understand more easily. If we do not have EVM, we need to develop respective compilers for each operating system. EVM makes Ethereum ecosystem compatible and efficient.

Since I am already waiting for my early access on github codespace, let me tell you more about gitpod which I recently saw a post about on Twitter by dabit3 Introduction to Gitpod Gitpod is a container-based development platform that puts developer experience first. Gitpod provisions ready-to-code development environments in the cloud accessible through your browser and your local IDE. Gitpod enables development teams to describe their dev environment as code and start configurable and fresh development environments for each new task entirely in the cloud. Think CI/CD for dev environments. Always ready-to-code Too much time is lost to a poor development experience. Setting up local dev environments that are brittle. Waiting for compilation. Downloading dependencies. Massaging them over time to make sure they work with all projects. “Works on my machine” situations, configuration drift and broken tool chains are slowing down professional software teams.

What is self-sovereign identity (SSI)? Now, this is where things get a little bit tricky. There is no consensus on an exact definition of self-sovereign identity yet. We use the terminology of SSI, as the concept of individuals or organizations having sole ownership of their digital and analog identities, and control over how their personal data is shared and used. This adds a layer of security and flexibility allowing the identity holder to only reveal the necessary data for any given transaction or interaction. Since identity is such a central part of society, we need to ensure that user control will be the primary foundation SSI will be built upon. Under self-sovereign identity model, individuals and organizations (holders) who have one or more identifiers (something that enables a subject to be discovered and identified) can present claims relating to those identifiers without having to go through an intermediary. As a result, the best way to implement a system with self-sovereign identity would be through blockchain technology where no intermediary is needed. In order for a system like this to be successful, it needs to adhere to a set of guiding principles Guiding Principles of SSI Each of the guiding principles is (will be) linked to the corresponding article. Existence — Users must have an independent existence.

These notes main objective is to help understand P2P networks, and explains some of Ethereum’s implementation details. P2P technology has the potential to alleviate shortcomings of centralized systems by utilizing the rich resources of end devices, and since the 1990s has been adopted by popular softwares like eMule, bitTorrent, and Skype. It is also a key component of blockchain systems like bitcoin or Ethereum, the system the Shyft Network is derived from. Most people have heard about P2P, but do not know what exactly it is. Let’s start by talking about P2P networks in general. What is a P2P Network? A Peer-to-Peer (P2P) network is an overlay network — that is, it’s built on top of the public Internet. Mathematically, It can be viewed as a directed graph G = (V,E), where V is the set of peers in the network and E is the set of links between peers. Each peer p has a unique identification number pid. A link (p,q) in E means that p has a direct path to send a message to q; that is, p can send a message to q over the network using q’s pid as the destination. Although in the underlying TCP/IP network, similar IP addresses could translate to nearby physical locations, there is rarely such direct correlation. Ideally, all peers should be connected by a path. Since individual peers have only an incomplete view of the network topology and peer membership, the overlay depends on intermediate peers to forward messages to the correct regions of the overlay. The graph structure provides multiple paths between every pair of peers, and contributes to resilience by enabling connectedness despite peer node changes. At each peer’s level, the connectivity of the graph is reflected in terms of its adjacencies to other peers. When peers join or leave the network, adjacent peers may have incorrect adjacency information. Overlay maintenance mechanisms are used to keep the adjacency information updated, thus maintaining connectedness across all nodes. Participants in the P2P network make a portion of their resources available to other network participants. Each peer contributes compute cycles (CPU), disk storage, and network bandwidth, without the need for a central coordination instance. Peers are both suppliers and consumers of network resources, in contrast to the traditional client-server model, where only servers supply and clients consume. Therefore, P2P networks have the potential to address the limitations of the client-server model, such as scalability and the single point of failure. There is often a minimum resource contribution threshold for a peer to join the P2P overlay. Resource contribution should be fair. A fairness criterion can dictate that, for example, the average contribution of any peer should be within a statistical bound of the overall average of the P2P system. Resource contribution should also be mutually beneficial. Users are incentivized to participate in P2P applications if the benefit is comparable to the resources being contributed.

A Merkle Patricia Tree* is the combination of a: Patricia Trie: An efficient Radix Trie, a data structure in which "keys" represent the path one has to take to reach a node Merkle Tree: A hash tree in which each node's hash is computed from its child nodes hashes. This is an implementation of the modified merkle patricia tree as specified in the Ethereum Yellow Paper: The modified Merkle Patricia tree (trie) provides a persistent data structure to map between arbitrary-length binary data (byte arrays). It is defined in terms of a mutable data structure to map between 256-bit binary fragments and arbitrary-length binary data. The core of the trie, and its sole requirement in terms of the protocol specification is to provide a single 32-byte value that identifies a given set of key-value pairs. Install

Ethereum Virtual Machine The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum. It is sandboxed and completely isolated, meaning that code running inside the EVM has no access to the network, filesystem or other processes. Smart contracts even have limited access to other smart contracts. Node The node encapsulates the EVM and is ultimately responsible for processing transactions, maintaining state and participating in p2p consensus protocols. The Kaleido platform currently offers Geth, Quorum and Hyperledger Besu as available node client implementations. A fork of the main Geth interface, Quorum offers support for basic public transactions as well as private transactions through its ancillary Tessera module. For more information on the Quorum client and its interaction with the constellation, please see the Mechanics of a Private Transaction article. The Geth client is the public Ethereum interface programmed in Golang, which unlike Quorum, offers support for solely public transactions. Besu is a modular Java-based client built from the ground up for enterprise usage. Smart Contract Ethereum smart contracts are most commonly written in Solidity, a high-level contract oriented language designed to target the Ethereum Virtual Machine (alternative languages such as Vyper or Flint can be utilized as well). Smart contracts contain the list of instructions to be executed when one of its functions is invoked, as well as optional restrictions on which parties can call a function. Solidity compiles into byte code (machine code), as do all EVM-compatible languages, and uses an application binary interface (ABI) to encode/decode data into/out of the machine code. Every deployed contract exists as an independent instance, with a unique address and state information constrained to itself. Consensus

In this tutorial, we’ll see how to get started with Web3.js to interact with the Ethereum blockchain. Web3.js can be used both in frontends and backends to read data from the blockchain or make transactions and even deploy smart contracts. The first step is to include web3.js in your project. To use it in a web page, you can import the library directly using a CDN like JSDeliver. <script src="https://cdn.jsdelivr.net/npm/web3@latest/dist/web3.min.js"></script> If you prefer installing the library to use in your backend or a frontend project that uses build you can install it using npm: npm install web3 --save

Install metatask on your browser. Go to Rinkeby Select rinkeby testnet in your metamask and copy the ETH address. To request funds via Twitter, make a tweet with your Ethereum address pasted into the contents (surrounding text doesn't matter). Copy and paste the tweet/post of the ETH address URL into the input box on Rinkeby then press enter Select the 18.75 eth/3days options. Once received send it to this ETH address: 0x6a765f761588e00c6A1B2B4e5bAb33c55E9c239a