Introduction of Jupiter


  • Jupiter is a Blockchain platform to support mobile device nodes;
  • Jupiter has introduced a novel concept called consensus unit which groups several single nodes in the network into a trusted cluster;
  • Full node could be run on the Jupiter based on consensus unit;
  • Jupiter has several methods to optimize the storage of the consensus unit;
  • Jupiter is developed based on geth. And we are continually working on it to add more features.

How to create a Consensus unit?


  • Every user in Jupiter network can create a CU. When CU established, the creator node will become the CU administrator. The administrator can determine the size of CU.
  • There are two types of CUs. One is public CU which can apply for joining by getting half approval of CU member nodes or getting approval from the Administrator.
  • Another kind of CU is protected CU. The administrator approves the only way to join the protected CU.

How to join a Consensus unit?


  • When a node wants to join a consensus unit, it has to find a node from one consensus unit.
  • The candidate can send the CU joining request by scanning the QR image or typing the CU address. Then the boot node will transmit the request which consists the candidate node information to CU members.
  • If more than half nodes approve the request, this request will be passed. Then, the boot node will send the approval response to the candidate node.
  • After the consensus unit internal voting or approval by the CU administrator, the candidate node will get the successful response
  • Then the candidate node will synchronize the CU route table from the boot node.

Managing storage


  • The user can get the information of active peers and ledger status of current CU. When a user finds the ledger occupying too much storage space, it can raise optimizing storage request with several sharding plans to CU peers.
  • When active CU peers receive the sharing request, they will make a decision for sharding and respond to the proposer node with the Sharding plan they choose.
  • The proposer gets the response from the active peers and marks the inactive nodes. The sharding plan is chosen as the plan with the most votes. After that, the proposer broadcasts the plan with a list of inactive nodes.
  • hen the peers receive the final sharding plan, they will delete the block contents which are not assigned to them on the sharding plan and only keep the hash heads of those blocks.