Ethereum has been around for about two years now and the project has undergone various changes in that short amount of time. Ever since Ethereum released their wallet a while ago, developers have been working on a plan to make the Ethereum wallet more streamlined, as well as improve its overall functionality.
Separating The Wallet From The Client
The main goal is to separate the client from the node (Geth). The node is effectively an operator, which operates on behalf of its subsystems. On the other hand, a client is an application – like Geth – which serves as a communication layer for DApps. Splitting out these two components will be a major step forward for Geth. But that is not all, with some of the issues with the core interface needing to be addressed.
More and more Ethereum users want to directly communicate with the core interface of Geth and additional documentation – which will be provided – for the core API will help foster native development. Additionally, doing so will achieve higher levels of C/C++/Python/etc development through a new IPC layer. Feedback is hard to come by between various platforms using the core interface, which causes an overload of the node.
Putting a full node on a smartwatch, for example, is very difficult, but this is where the Light Client (LES) for Ethereum comes into the picture. Stage one will feature a developer preview which acts completely separate from Ethereum while working on the same blockchain. Right now, its functionality is still fairly limited, as it only offers validation and state-querying.
There is a lot of work left to be done but the developers have unveiled some of the features we can expect. Once the Ethereum wallet enters phase two of the development phase, more features will be added. Among those new features are transaction sending – making LES useful – log filtering and bloom look ups.
The process of core refactoring will happen over a timespan of at least six months. This is a difficult process that will take some time to get right. Although, addressing the validation and processing is at the top of the priority list, there is another issue that needs to be sorted first.
In its current state, tweaking any factor of the Ethereum wallet right now forces developers to address a ton of other code. The whole process needs to be simplified by quite a margin making it easier to develop an own private chain. This type of functionality is coming in the next version of the Ethereum wallet.
Other Things That Need To Be Addressed
Virtual machines are an integral part of the Ethereum ecosystem and changes are coming in this area as well. The Go JIT EVM – which is not the same as the JIT VM done by Paul – has been announced. Go JIT EVM is developed to analyze the code within the code and tries to put it into a different language so machines can understand it. Analyzing segments of the code will allow for future optimization and scalability for the processing part. The foundation is being built and optimized right now.
As far as improving code coverage is concerned, testing has become sloppy over the years but a solution has been found. All it takes is entering some data and the end result will be presented. Specific parts of the chain are not tested through this process but that will become a possibility in the near future.
Last but not least, fast sync (eth/63) is quite an impressive principle. Frontier had 360k blocks in the chain before Fast Sync was deployed. Syncing took 12 minutes (for 1.6 GB of data), but with fast sync it takes 2 minutes (and the blockchain is reduced in size to 235 MB).
Even though there are very few transactions on Frontier right now, it’s hard to gauge the real potential of fast sync right now. On the Olympic chain though, syncing 640.000 blocks took 4h7m for a total filesize of 21 GB. Since the introduction of fast sync, these values have been stripped down to 31 minutes and 3.8 GB of data.
Images courtesy of Ethereum
Also published on Medium.