Application Status
Status: New
Last updated: 06.09.2023
Submited by First Name, Last Name: Dimitar Ivanov
Team: Craig Everett, Sean Hinde, Dimitar Ivanov, Hans Svensson, Dincho Todorov, Ulf Wiger, Metin Akat, Rumiana Akat, Justin Mitchell, Jarvis Caroll
Approved Budget (in h):
Used Budget (in h):
Planned Delivery:
Specify the funding category
Open Source Development
Application Title
Core team application July-September 2023
Applicant
Aeternity core developers team.
Value Application
We will also be working on various ongoing tasks:
- Tx Execution Parallelization
- Snapshot Sync
- Front-End Playground
Definition of Terms
What exactly are we talking about? Please describe your project.
Status Quo
HyperChains
With our improved understanding, the HCs seem closer than ever. We should still:
- finish the
lazy_leaderfunctionality and rename it to something more suitable - implement the parent chain fork awareness
- adjust the config producing tool and the staking UI according to the latest contract changes
- tooling to facilitate setup and deployment
- setup and deploy documentation
- an AE wallet in order to support HC’s child chain signing
Move the State Channels out of the node
This will speed up the core node tests but also would allow building server-side infrastructure for supporting SCs and perhaps simplify running State Channels on mobile devices. This task aims primarily at taking the SC FSM out of the node.
Revisit the internal API to make it easier to implement plugins
This is mostly an ongoing process and the API is being adjusted when needed. The goal is to have a static API in order to support different plugins accross different node versions. Documentation and tutorials are also needed.
HTML UI to operate the node
A simple local webpage to allow the user to interact with their node. This is mostly an RnD project.
Snapshot sync
Sync the backbone of headers first and then download the MPT some blocks below the top. This includes a whole spectrum of new P2P functionalities like communicating P2P versions, enabled node capabilities and so on.
Jump sync
This is still at the idea stage. The thought is for syncing nodes to share a Proof of Inclusion of the block hash at a given height + the Genesis hash, allowing a connecting node to jump directly to that height, trusting that the hash is indeed on the main chain and connected to Genesis. More theoretical analysis and experimentation will be needed.
State Channel Market
Some ideas exist for how to evolve the State Channel Market concept. One idea is to provide a fast bridge between Hyperchain child chains, or between child- and parent chain. More concrete use cases and more developed user interfaces may also be explored, as well as making the demo properly decentralized, with proper wallet support.
This could in part help to clarify and improve the experience of using State Channels for highly interactive, high-volume applications.
Support and improvement for tooling
Those are long running tasks that we tackle if we find some time for them: GUI launcher, aeCanary, monitoring tool, plugin system, devmode, state channel use cases and so on
Middleware
In the third quarter of this year, the Middleware team will focus on implementing several major features that will enhance the functionality and usability of the system. Firstly, the team will work on adding statistics endpoints, which will enable the display of chart data that will provide valuable insights and visualisations to users, facilitating data analysis and decision-making. Additionally, the team will concentrate on expanding support for NFT (Non-Fungible Token) and nested resources information. Moreover, in an effort to optimise the system, the team plans to deprecate the V1 version of the Middleware API and introduce the V3 version. This upgrade will bring improved functionality, performance, and security to the API, ensuring compatibility with the latest node changes, including support for hyperchains.
JavaScript SDK
In the following work, it is planned to implement an alternative way to connect aepp with a wallet using WalletConnect. In the scope of refactoring to improve the existing aepp-wallet interface, find a better way to calculate transaction fee, and implement a consistent way to represent AE coins in code.
Sophia/FATE compiler maintenance and development
- Fix high priority bugs, currently: 476, 471, 470, 395. More bugs could be included as we progress.
- Provide developer support by answering questions in the forum and github.
We refrain from adding new functionality to the compiler unless it would serve another project. This is because we are planning to replace the Erlang compiler with the Rust one. This way we are avoiding duplicated work and distraction, as those features will be implemented in the new compiler only.
Sophia compiler rewrite
- Finish the reimplementation of aebytecode in Rust.
- Rewrite and test lexer and parser, at least a simplified version
- Define the entire compiler’s project structure and provide type definitions for most crucial data across the compilation pipeline.
- Implement infrastructure for basic type checking.
Sophia/FATE debugger and REPL
- Expose full REPL/dbg functionality in the new web interface
- Provide machine-readable interface to the REPL
- Fix deployment: update the Dockerfile and make sure the application is startable out-of-the-box in release mode
Required Work
Once we have enough features implemented, we will make official releases.
Estimate
We would be working full time on this, although some of the team (Hans and Craig) already have other commitments and would help us depending on their availability.
Known Limitations
Although we aim at delivering fully functional HCs, there will be a lot to be improved there.
Outlook
HCs is something we had promised long ago. It will be great to deliver a working version. Improved syncing would be highly appreciated by the community. We do need the monitoring tool for internal purposes.
Publishment
We publish our work in the official AE repositories.