Its main topic is that scaling teams is hard.
Internal tooling, training, and services must be developed and fielded to ensure that all members are able to work on problems of continuously increasing impact. The ceaseless pursuit of force multipliers is the only possible route to superlinear productivity improvements as an organization grows.
I absolutely agree. When adding more people to the organization, the best thing you can do is to make them work on something that improves productivity of everyone else. …
There is currently a proposed format for block witnesses in Stateless Ethereum, that has a spec in a GitHub repo. It is based on opcodes. You can imagine a tiny programming language with just a few commands that generate a Merkle Mupltiproof.
This post researches an alternative approach to block witness construction. It is based on a list of keys and values and has a simpler semantics.
In this post I will try to answer the following questions:
The amount of money locked in DeFi apps surpassed $1.500.000.000; DApps are beign announced almost every day. At that rate, Ethereum can become a victim of its own success. One of the struggles on the infrastructure layer is boundless state growth.
The idea is relatively simple and might look very radical at the first sight: let’s nuke all the state we have locally at deterministic schedule (say, every 1.000.000 blocks), keep the…
Raw data and scripts for the experiment: https://github.com/mandrigin/ethereum-mainnet-resolver-witness-stats
One of the possible ideas to speed up the initial sync process it to use block witnesses to pre-build the cache trie to avoid slow state access. That will cost additional disk space and network bandwidth but potentially can significantly speed up the sync process.
How will that work? Basically, to run each block, we need some data in a Merkle trie. Before the block execution we already have some nodes there, but it might not be enough to run the block. Normally, this data will be taken from the state db…
data & scripts for this article are in a github repo: https://github.com/mandrigin/ethereum-mainnet-bin-tries-data
If you are already familiar with what Stateless Ethereum & Block Witnesses are, skip to the next part.
To run blocks and validate transaction, Ethereum nodes need to know the current state of the blockchain — all accounts & contracts balances and storages. This data is typically stored in the DB and is loaded into a Merkle trie when needed (to be able to verify hashes).
Stateless Ethereum clients work a bit differently. As the name implies, they don’t use a disk DB to run blocks (they might…
Happy New Year everyone!
While working at Status, I put together a small guide on testing energy efficiency of a mobile app.
Of course, some of the parts there are Status-specific, but there is enough information useful for the general public.
Here is it: https://github.com/status-im/energy-efficient-bok.
Sections of this BoK that have the most interesting parts are:
* Dev Guide — a short document describing what affects energy efficiency and how to test it in development.
* Using Battery Historian — how to use Battery Historian to test energy efficiency on Android.
* Testing and interpreting results.
Special shoutout to Lukasz for helping putting this BoK together.
When we implement a change in a codebase, it isn’t a single task. It’s a whole project, containing creating new objects, abstractions, functions and methods. We alter a few behaviours, we workaround platform-specific issues. If a change we are implementing isn’t trivial, then development lasts for weeks. It is very easy to forget all the details you knew about it.
If course, that is where different task manager apps are supposed to help. Except they usually don’t. They are usually too inconvenient to keep track of these tactical tasks.
Can we do better than that?
Let’s look at the outside…
In my previous post I’ve discussed what a team leader or a manager can do to optimize the flow of tasks, especially in the beginning of a project.
Re-reading “Getting Things Done”, I stumbled upon a following story:
One manager, who had taken over responsibility many months in advance for organizing a major annual conference, asked me how to prevent the crisis all-nighters her team had experienced near the deadline of the previous year. When she produced an outline of the various pieces of the project she’d inherited, I asked, “Which pieces could actually be moved on right now?” After…
So, you are a technical leader and you and your team is building a product. There are a lot of moving parts: the requirements that constantly fail to be static and well defined, the company’s infrastructure is moving forward somewhat, the codebase you are working on.
How to keep the development efficient and not stall while some decisions were not made just yet? How to tackle changing environment? What to do next on the project?
I use a simple heuristics that I found very useful for that.