Hey everyone,
At LimeChain, we are working on Phase 3 of the implementation of Fruzhin, Java-based Node Host implementation. This post aims to update the community on our progress and highlight some noteworthy changes.
The еnd goal of phase 3 of the project is for Fruzhin is to act as a relaying node, providing valuable benefits to the Polkadot network by diversifying the client base. This is significant because it helps to safeguard the network against the concentration of power and control, preventing a single entity from making unilateral decisions in permissionless protocols like Polkadot. The transition from Full Node to Authoring Node is a significant endeavour, given that up until now Fruzhin has only been a passive participant of the network. Technically speaking, the most significant outcome of this phase is to advance our Host to becoming an active participant of the network by implementing block building and consensus protocols, namely BABE and GRANDPA.
Link to GitHub repo.
For the last month, the team have being actively working on implementing the following topics:
Block execution improvements
Completed:
Upgrading the Full Sync
Completed:
Upgrading wasmer-java
Completed:
Next focus:
The focus of Sprint (June 24, 2024 → July 7, 2024) is to complete ** Block execution improvements**, and prepare for Babe.
*Task to be completed: Migrate trie from in-memory to on-disk · Issue #437 · LimeChain/Fruzhin · GitHub
1 Like
as much as I am happy to see more Polkadot RC nodes being implemented, I can’t help deny the fact that an RC node implementation is only relevant up until the JAM migration. I understand that this project is part of the Pioneers Prizse, and I wonder who is the coordinator of that, and if there has been any discussions around re-targeting this towards a JAM implementaiton? Or perhaps having good expectations in terms of deadline, adjusted to the expected release date of JAM (currently estimated to be end of 2025).
Interestingly, I hear a lot of misinformation about JAM rendering a lot of Polkadot 1 as deprecated, most of which is wrong. Parachains will remain, they will still need collators, they can still communicate, and so on. This means, Substrate, FRAME, XCM, Cumulus and almost all other pieces of polkadot-sdk remain relevant. One of the few things that we will not need int he current format is a Polkadot RC node, as it will be split into two different softwares: the JAM client, and the Parachains Service.
As JAM is going to be an upgrade to the relay chain we absolutely have plans for supporting it but the current roadmap suggests that we would be finished with the authoring node and relaying node upgrades before JAM gets released. Besides that JAM would not be making changes to the consensus mechanism and that’s the main piece of technology we would be adding to our node by upgrading it to an authoring node so this is in no way going to be a wasted effort.
1 Like
What timeline are you expecting for yourself, and what is your anticipation for JAM?
Correct, but I think you can better call this “truly” not wasted work if you already make a plan to transform the JAVA Polkadot node to be compatible for JAM, and in that sense yes most of the consensus code is re-usable, albeit I would anticipate it will not be super trivial. There’s a JAM prize, basically I am suggesting maybe you should apply for that two to make sure this work is used in the future.
Our current plan is to deliver the authoring node scope by mid-2025 and proceed with implementing the Relaying node scope immediately after.
Thanks for suggesting this, we have been looking into the JAM gray paper for quite some time already and plan to get involved.
During the last two sprints the team worked on the following topics:
M0: Block execution improvements
The team continued working on Migrate trie from in-memory to on-disk, as part of Milestone 0. By closing this task, we will be done with Milestone 0: Block execution improvements.
M4: Upgrading the Full Sync
The team managed to complete another task from Milestone 4 Improve syncing strategy. Now, syncing happens with warp sync, thus improving the node reputation.
M6: Compatibility, monitoring and Docker
The team completed task Make Fruzhin runnable via Docker, introducing Dockerimage that builds a docker image for Fruzhin.
Next focus:
Our focus will be Milestone 11 - Light Client Web Scope - to increase the adoption of the Fruzhin’s light client.
Light Client in Web: Completed!
Over the last month the LimeChain team worked on key part of the Phase 3 proposal that is Milestone 11: Light Client in Web. We completed the milestone successfully, and packaged Release v1.0.1, which you can find here.
Starting Fruzhin
(Please follow the instruction below or the ones provided inside the README file)
То use Fruzhin in your webpage you have to import the appropriate JS files from UNKPG. Then you can call the fruzhin.main() method with a string array parameter that takes one entry. The parameter can be one of the following:
- Well known chain name (polkadot, westend, kusama)
- A chain spec string
<!DOCTYPE html>
<html>
<head>
<title>Fruzhin</title>
<script type="module" src="https://unpkg.com/fruzhin/dist/js/fruzhin-lib.js"></script>
</head>
<body>
<script type="module">
fruzhin.main(['polkadot']);
</script>
</body>
</html>
Making RPC calls
Once Fruzhin is started an RPC client is exported under a wsRpc object. Making a call is easy.
wsRpc.send('{"jsonrpc":"2.0","id":1,"method":"system_name","params":[]}')
Then the response can be retrieved by calling wsRpc.nextResponse().
NOTE: wsRpc.nextResponse() returns null if no response is present in the queue.