Snake Charmers (Page 2)

Sign in Subscribe

The Aperture - vol. 3

> "The Aperture" is a recurring series covering the development of the Portal Network Welcome to the third volume of "The Aperture". This series covers the development efforts surrounding the Portal Network [https://github.com/ethereum/portal-network-specs]. TLDR * Watch the PeepanEIP [https://www.youtube.com/watch?

The Aperture - vol. 2

> "The Aperture" is a recurring series covering the development of the Portal Network Welcome to the second volume of "The Aperture". This series covers the development efforts surrounding the Portal Network [https://github.com/ethereum/portal-network-specs]. TLDR * Continued work towards a public testnet for the

Web3.py Patterns: Address Mining

Each new Ethereum address you create is a long jumbled string of letters and numbers preceded by 0x – until it's not! You may have seen some vanity addresses in wild, i.e., an Ethereum address that spells out a word or has many repeating characters. The way these

The Aperture - vol. 1

Welcome to the first volume of "The Aperture". This series will provide regular development updates on the Portal Network [https://github.com/ethereum/portal-network-specs]. TLDR: * Trin [https://github.com/ethereum/trin] and Fluffy [https://github.com/status-im/nimbus-eth1] are working towards deploying the first test network [https://github.

Trin Development Update #2

tl:dr; utp, overlay networks, and chugging along towards eth_getBalance support. Check out the trin repo [https://github.com/ethereum/trin]. Dev update pt 1 [https://snakecharmers.ethereum.org/trin-development-update/]. Portal Network specification [https://github.com/ethereum/stateless-ethereum-specs/blob/master/portal-network.md] . trin is en route to becoming a

Ethereum's Untapped Potential

What does success look like for Ethereum? In a word: adoption. Ethereum will be used when and where it solves a problem. The more problems it solves or opportunities it creates, the greater the adoption. How then do we optimize for adoption? Lower the barriers to entry. The easier it

The Core Developer Apprenticeship Program

> The opinions in this article are my own and do not represent any "official" sentiment by either the Ethereum Foundation or the Ethereum Core Development Team. We need more people working on the core Ethereum protocols. The roadmap for Stateless Ethereum has solidified in significant ways over

Web3.py in London

Ethereum's next network upgrade, dubbed London, is live on the Ropsten testnet, with other testnets soon to follow. A summary of the London updates can be found here [https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41], and a timeline of the London rollout can be found here [https://blog.ethereum.org/

Trin Development Update #1

tl;dr – The Trin client is alive and talking with other clients. Next steps involve transmitting data. The portal network is a new cross-team effort to re-imagine the ethereum light client, and develop a practical and functional light client experience. You can dive deeper into the portal network specification here

Web3.py Patterns: Call State Overrides

As of version 5.19.0, Web3.py includes one of Geth's lesser-known debugging features: the ability to override state when using the eth_call JSON-RPC method. What that means in practical terms is that you're able to alter the nonce or balance of the account

Beam Sync in 80 Seconds, Using Meta-Witnesses

The Trinity Team wants Ethereum clients to launch faster. We also want to verify that block transactions are valid, and look up arbitrary state. The status quo is to wait for hours or days to get synced, and it's unacceptable. So our team developed Beam Sync. Beam Sync

Wanted: Monkey Trainer. Pedestal Builders need not apply.

I recently wrote a few [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/] blog [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients-part-2/] posts [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients-part-3/] describing what was needed for us to have truly functional light clients. If you haven't read those, you should go do that now. I'll

A Developer's Guide to Ethereum, Pt. 2

[Last update: May 16, 2023] Welcome back! In the first installment of this series we covered a lot of ground while interacting with a simulated Ethereum network. At this point, you should have at least a fuzzy idea of how to answer these questions: * What's a blockchain and

state-availability

The winding road to functional light clients - part 3

> You should read part 1 [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/] and part 2 [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients-part-2/] first. Most wallet software depends on centralized providers like Infura. If we want things to be different, we need a new type of light client capable of running on low-resource devices.

state-availability

The winding road to functional light clients - part 2

> You should read part 1 [https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/] first. It's 2021. Ethereum went live a little more than five years ago. There's currently no reliable lightweight way to interact with the protocol without using a centralized provider. Various research efforts have demonstrated that

state-availability

The winding road to functional light clients - part 1

It was nearly five years ago that we set out to build Trinity, a new "light weight" client for the Ethereum network. Geth had recently shipped the first versions of the LES protocol and we had big dreams. As often happens with big dreams, they were quickly dashed

Alexandria Dev Update #4

Shortly before the Holiday break in December, we successfully spun up a test network of 20 nodes, hosting the first 1 million block headers. T TLDR: The network behaved as intended, with nodes creating and spreading advertisements via the gossip mechanism, mirroring content to fill their storage capacity and serving

Web3.py meets Eth 2.0

Among a dozen other initiatives, the Ethereum 2.0 teams have been working to standardize how developers can interact with beacon nodes. This effort is ongoing, but the latest specification can be found here [https://ethereum.github.io/eth2.0-APIs]. We're excited to announce that Web3.py [https:

Alexandria Dev Update #3

We are on track to have the core network functionality all working with the full header chain available on the network by the beginning of Q1 2021. The next 2-3 weeks will be spent hardening the client to improve stability and expanding our test network towards a network capable of

Alexandria Dev Update #2

Development continues at a quick pace. Currently, we are aiming to having a POC ready by the end of the year to host and serve the header chain. Content Transmission The last pull requests implementing the content transmission logic are being reviewed. This builds on the SSZ partial work from

Alexandria Dev Update #1

This is the first in what I hope to be a regularly cadenced quick update on the development of the Alexandria network. First, a quick introduction Alexandria is a new protocol under development for the Ethereum ecosystem. The goal is to provide a new peer-to-peer network that exposes the chain

A Developer's Guide to Ethereum, Pt. 1

[Last update: July 25, 2023] So, you’ve heard about this Ethereum thing and are ready to venture down the rabbit hole? This post will quickly cover some blockchain basics, then get you interacting with a simulated Ethereum node – reading block data, checking account balances, and sending transactions. Along the

Applying the "Five Whys" to the Client Diversity problem

The most recent All Core Devs call #90 [https://github.com/ethereum/pm/issues/189] was almost entirely spent discussion a single issue. I would highly recommend going and listening to the call yourself [https://www.youtube.com/watch?v=IZEcukn9J0Y]. On the call Alexey brought up the issue of