I’ve been upgrading Moolah after a long period of neglect. One of the tasks is to update it to WebPack 4. Mostly this went smoothly by just creating a new project with vue-cli and bringing its generated build setup over to replace the old one. Then a bunch of tweaking.
One thing that did bite however, was tests using inject-loader started failing as soon as I added vuetify-loader to the project with:
Continuing our adventures in setting up a private beacon chain… Previously we got an Eth 1 chain with the deposit contract and successfully sent a deposit to register a new validator. So far though, we have no way of telling if it actually worked. What we need is an actual beacon chain client. Enter Artemis…
I’ve started a little side-project to setup a “private beacon chain”. The aim is to better understand how the beacon chain works and start to discover some of the things still required to be built or fixed in clients before it can officially launch.
So what is a private beacon chain? It’s intended to be an entirely self-contained, runs-on-my-laptop instance of the beacon chain, run as a small-scale simulation of how the real beacon chain will be fired up.
If you’re switching from a CLA model to a DCO model you may want to add a Signed-off-by line to every existing commit so that you can run automated DCO checks over the entire repository. Doing this obviously assumes that your CLA sets things up so that you are actually in a position to provide a DCO sign-off.
I’ve written up a simple little EIP to specify some standard names and meanings for Prometheus metrics that are common across Ethereum clients: EIP-2159.
It’s pretty simple and only defines four metrics but that’s enough to create quite powerful overview dashboards that would work across multiple clients.
There’s a fun little gotcha introduced in Java 10 which causes trouble for anyone wanting to support earlier JVMs. If you take the code:
import java.nio.ByteBuffer;
public class ProblemCode {
public static void main(String[] args) {
final ByteBuffer buffer = ByteBuffer.allocate(10);
buffer.position(10);
System.out.println("Yay it worked!");
}
}
If you compile it on Java 8 it will run on any Java from 8 and above. If you compile it on Java 10 or above it will only work on Java 10 and above, even if you specify -target 8 -source 8.
I’ve had the opportunity to do some proof of concept development of the Ethereum state-rent proposal that Alexey Akhunov has been leading on the Pantheon code base. The proposal evolved as the work continued so the actual implementation is now a lot simpler than described in that PDF.
Note that the aim is to explore what it takes to implement the proposal, not to create production ready code. The current work is all available on on my state-rent branch.
This week, the work I’ve been doing for the past 6 months, and that PegaSys has been working on for the past 18 months or so was released into the world. Specifically we’ve released Pantheon 0.8.1, our new MainNet compatible, Apache 2 licensed, Java-based Ethereum client. And it’s open source.
I’m pretty excited about it on a few fronts. Firstly I think it’s a pretty important thing for the Ethereum community. To be a healthy ecosystem, Ethereum needs to have diversity in its clients to avoid a bug in one client taking out or accidentally hard forking the entire network. Currently though, Geth and Parity dominate the Ethereum client landscape. Pantheon clearly won’t change that in the short term, but it is backed by significant engineering resources to help it keep up with the ever changing Ethereum landscape and be a dependable option.
There’s an exceptionally valuable set of ethereum reference tests that are run by most or all of the different Ethereum clients to ensure they actually implement the specifications in a compatible way. They’re one of the most valuable resources for anyone developing an Ethereum client.
The Aleth project maintains the official test client called testeth but it’s a little cryptic to work out how to actually run things with it and then use that to debug failures happening in the client you’re actually developing. So this is what I’ve found useful:
There are a number of browser plugins which inject additional JavaScript APIs into the DOM so websites can take advantage of the plugin functionality. One example of that is MetaMask which “brings Ethereum to your browser”. This allows any website the user visits to detect that the plugin is installed by checking for the presence of those APIs which may aid them in targeting attacks such as the recent spate of phishing attacks against MetaMask users. So there’s a proposal in place to require websites to get specific authorisation from the user before the APIs will be injected. And since injecting an API to allow the website to request access would defeat the point, it uses window.postMessage:
Interesting review of the regulatory landscape around crypto-currencies. There are a lot of echo’s of issues with the over-the-counter nature of most FX trading, albeit with even less enforced regulation and uncertainty.
Bitcoin Redux explains what’s going wrong in the world of cryptocurrencies. The bitcoin exchanges are developing into a shadow banking system, which do not give their customers actual bitcoin but rather display a “balance” and allow them to transact with others. However if Alice sends Bob a bitcoin, and they’re both customers of the same exchange, it just adjusts their balances rather than doing anything on the blockchain. This is an e-money service, according to European law, but is the law enforced? Not where it matters. We’ve been looking at the details. Source: Bitcoin Redux: crypto crime, and how to tackle it | Light Blue Touchpaper Also interesting to note is that most of the regulation required is already in place and just needs to be enforced. In most cases there isn’t any need for radical rethinking of laws, just apply the current laws about treating consumers fairly and Know-Your-Customer to this new technology.
A fun thing about programming is that most days, you make progress. Maybe you fix some issues, maybe you add a feature, maybe you build towards something bigger. Your code moves ever forward. Until it doesn’t. On occasion, you will hit a Bug. Not a mundane bug, some trifle you can fix in an hour, or even a day. This is a true Bug. One that defies reason. One that evokes a “that’s not possible,” a “how could this even happen?”, or most dreadfully, a “could there be a bug in the compiler?” Hold on kids, we’re going hunting. Source: The Great Bug Hunt – Allen Pike