Page tree
Skip to end of metadata
Go to start of metadata

Status: Proposal moved to Fabric community per comments below.

Project Identifier

Hyperledger Justitia helps users create and maintain consortiums on fabric. HIP 0.1


SHIJINSHI Credit Information Service Company,

<If you want to join as a sponsor, please feel free and contact the project maintenance staff by email. >


Justitia helps consortium members generate and maintain all of their certificates, easily deploy and maintain their own nodes. On the other hand, it helps users manage the configuration of consortium and channels, including configurations such as members and policies.


Initially, we envisioned creating a large chain of alliances in which all participants were equal. Each of them maintains their own nodes and certificates on the network. Some or all of the members of the alliance can conduct independent business cooperation in different channels by the fabric multi-channel feature. However, in the actual operation, we found that the process of deploying the fabric node in the way of running the script is complicated and error-prone, and the whole alliance is difficult to expand and maintain. Therefore, we urgently need a tool to help us manage the identity, nodes, channels, and consortium members on the fabric.

Justitia was developed to help customers more easily deploy fabric nodes so that customers can more easily join our business. Justitia not only helps affiliate members manage all of their identity data in the federation, but also helps users deploy fabric nodes, dynamically create and manage channels, and members of federation.

When the entire project is nearing completion, we consider contributing it to the community to help more users with the same needs. In the process of preparing for the contribution, we saw a similar project Cello in the community. After an in-depth understanding and comparison, it was found that Cello and Justitia have very different ways of deploying fabric network nodes. Cello can easily deploy a fabric network, but Cello is not good enough for certificate management and node deployment, and it cannot manage consortium members and channel members. We believe that Justitia can just make up for the lack of cello in some scenarios, which further strengthens our determination to open source this project. Of course, in the subsequent versions we will also learn the excellent design of Cello as much as possible.


This project will start in incubation.

The basic functions of the project have been implemented, but some of the functions are not perfect and need to be optimized, we will improve these parts in the future.


This project uses Fabric ca manage and maintain organizational identity information, and maintains and monitors Fabric nodes by using docker's http PAI, and maintain data on the fabric network through fabric-sdk-java. The structural design of the project is divided into four parts, as shown in the following picture. The DB/File is used to store identity data including certificates and private keys. Service defines some business modules that are provided to the Scheduler call. The Scheduler performs identity verification and defines a series of REST interfaces; the WEB provides data display and service calls through the REST interface provided by the Scheduler.

  1. Dao serverProvide data storage and read interface, you can customize to use different databases according to your needs, MYSQL is used by default.
  2. Fabric serverThe fabric-sdk-java is packaged to provide some simple service interfaces.
  3. Chaincode serverProvides chain management capabilities such as installation, instantiation, and upgrade with the Fabric SDK. Chain code installation supports uploading local source files and getting codes from the code repository.
  4. Node serverBy calling Docker's Rest API to create and manage node containers, users can dynamically adjust the number of nodes as needed. When deploying a node, the system provides a default configuration for the node, and the user can also override the configuration according to the actual situation. The system monitors the status information of the node. When the status of the node is abnormal, the system notifies the administrator to handle the situation through email or SMS.
  5. Identity serverThe maintenance of identity information is done by means of fabric ca, including registration, renewal and revocation of certificates. In the database, we store the certificate and private key so that when the user needs to deploy a new node or use a new client user, the service can provide all the required certificates and private keys. When the certificate needs to invalidate the original certificate due to the leakage of the private key, etc., the system can help the user revoke the relevant certificate and update the CRL to the channel configuration.
  6. Channel server

    Channel services manage a member of consortium or channel by submitting channel configurations.

    The consortium administrator who holds the private key of the administrator of the orderer can manage members of consortium by modifing the configuration of the system channel. The applicant generates configuration data including the identification information of the organization by the system, and then sends it as an application material to the consortium administrator through other forms such as mail.

    If the administrator agrees to join the consortium (the corresponding approval mechanism has specific business decisions), he will obtain the latest system channel configuration block from the orderer node and add the configuration information submitted by the applicant to the consortium to generate a configuration update transaction. After that, the applicant has the same rights as other members as members of the consortium, and can also create channels. For deleting a consortium member, remove the configuration of the corresponding member from the consortium configuration with the same operation.

    The management of channel members and channel configurations is similar to that of managing consortium. It is implemented by the administrator user of the channel member initiating a transaction that modifies the channel configuration. However, unlike modifying the system channel, the administrator who wants to modify the channel configuration in the default policy requires more than half of the organizations in the channel to endorse the modification proposal. Of course, this policy is modifiable. On the other hand, the process of endorsing by the organization administrator user cannot be done on the chain. It is too complicated to introduce a centralized service to help complete the signature process. In order to solve this problem in the chain, we added a system chain code CMSCC (channel manager system chain code) to the implementation of this signature process. The process of joining a member as shown in the figure below is similar to the process of joining a consortium. The applicant sends an application for joining to the sponsor (any member of the channel), and the sponsor obtains the latest configuration block generation channel update transaction of the channel. This transaction is broadcast to other members of the channel by means of the CMSCC, and other members may choose to accept or reject the application. Until the number of accepted members meets the channel policy, the sponsor sends the signature result and the update transaction to the Orderer node to update the channel configuration. The applicant then has the same authority as the channel members as other members. For deleting a channel member, remove the configuration of the corresponding member from the channel configuration with the same operation.

Efforts and Resources

We have now hosted the original version of the code to github ( Although it uses Chinese in many places now, and the documentation is not perfect. But we will refactor the next perfect version as soon as possible based on the design mentioned in this article. In addition, we hope to be able to transfer the code to github's hyperledger user in the next version so that more people can see the project. It is worth noting that for this project we have set up a dedicated team to manage and maintain until the end of the entire project incubation. Of course, we also welcome other developers to join us and make it better.

How To

This project is a front-end separation project implemented by Spring boot + React. Users can choose to deploy by compiling source codes or running docker images. After the deployment is complete, it can be accessed through a browser. On the first visit, we provide a boot process to help the user initialize the system configuration.


The success of the project can be checked to see if they are complete and stable by verifying the functionality of the Solution section. In addition, as follow-up versions follow up, we may also add new features to Justitia.

Reviewed By

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis

  • No labels


  1. RuiLiu Hi Rui, thanks for the proposal. I have reviewed your proposal. It seems to me that the main points in the proposal are ID/Cert management (like a front end to Fabric-CA) and process of the adding new org to an existing channel. For the later, there has been a hyperledger fabric working group named interop working group focusing on that and have also defined the solution with working code. Please see the working group wiki page and also please see the working code using the below links. I can also provide you a demo on what working group has defined and agreed on by many fabric service providers. Here are two links.

    Fabric Interop Working Group

    Please let me know if you have any questions.

    1. Hi, Tong,Thank you very much for your information on the interop working group. When I learned about the work that interop did, I was amazed at how similar their ideas were to me, and I also admire them for doing this perfectly. But in my opinion, justitia is not meant to implement certain functions, but a tool that makes it easier for users to manage fabric. As in the Interop wiki, "It is accepted that each vendor will have its own (cloud based) fabric offering and will provide its customers/organizations a rich UI and process steps to complete all relevant actions." In most cases, a fabric service provider can provide users with cloud based services. But sometimes consortium members are not willing to use third-party services, such as some organizations are very concerned about data privacy. For these organizations, it is very difficult for them to manage fabrics, such as managing ID/Cert, deploying and monitoring nodes, managing alliance members, and so on. Although the community also provides many tools and solutions to help them deal with these needs, they are scattered and not easy to understand. Especially for those who don't learn more about fabric, using these tools is very complicated.

      In addition, it is not necessary to explain that in the process of implementing justitia, I did not do a lot of innovations in technology and solutions. Most of the solutions are from the documents provided by the community.

      1. +1  "members are not willing to use third-party services"

  2. I would like to hear what the Fabric maintainers think of this proposal. It does seem like this is a good case study for what constitutes a "sub-project" (whether formally defined as such or not). Hart Montgomerywhat do you think?

    1. IF  we want to do subprojects, then this might be a textbook case.  While this is definitely a worthwhile effort, it's something that only improves one project and has seemingly no plans to incorporate others (this might be hard due to the Fabric-centric nature of the project). Can we get comments from the Fabric maintainers on this?

      1. Thanks for your comment, this project is indeed based on fabric. I read the comments on this proposal and found that it seems that the project proposal based on fabric should not be submitted here. If this is the case, please let me know how I should contribute to this project correctly.Thanks!

    2. I don't think this has anything to do with Fabric maintainers but rather the Fabric community (users and developers). If they think it is useful then they will support it, regardless of whether it is a HL (sub)project or not. The question would become how open and permissive are we in accepting projects like this into HL.

  3. @RuiLiu Thanks for the effort!  This looks like a nice thing to do.  Have you spoken with the Fabric maintainers on where they think this should fit in in the Hyperledger hierarchy?  Thanks!

    1. I have not discussed this project with the Fabric maintainers staff yet.I have not discussed this project with the fabric maintenance staff yet. I will try to discuss this project with them. 

  4. RuiLiu Thanks for the proposal. IMHO, it addresses the needs of many, including developers, who are pulling their hair to config Fabric. It reminds me of the mainframe configuration of 80s. I encourage you to get on to the Fabric contributors' meeting calendar to discuss your proposal.

    Mic Bowman The question for us is whether subproject must address the needs of multiple projects. I don't think that is necessary, but there should be a different process (review, approval, marketing support) for subproject.

    1. Your suggestion is very good. However, due to my poor English ability, I can't communicate directly with you at the meeting. But I will try my best to find some help in order to discuss this proposal at the next contributor meeting.

  5. I easily think this is a Lab.

    The larger question is how to handle projects like this that are more subprojects?

  6. both lab and sub-project should be fine, depending on the fabric maintainers meeting discussions.

    1. Thanks for your comments, because my first contribution to the community is not very clear about the community's positioning and division of the project. I will try to submit this proposal to the calendar of meetings.

  7. Given this project is focused 100% on Fabric, it would make sense to come in under the Fabric umbrella.  But we should  probably give it a different name which includes Fabric IMHO.  But not a showstopper ... more of my preference

    1. I agree that justitia is not a suitable name for this project. However, there are still some controversies about the way the project is accepted, so I think that after these disputes are resolved, we can give it a suitable name.

      1. Rui,

        Just to be clear there are no disputes nor anything controversial. The value in your project has been acknowledged and we thank you for bringing it to Hyperledger.

        We just need to find the best way to host it, knowing that every possible way as its ups and downs. And we want to make sure that it is positioned correctly with regard to other projects going on (primarily Cello and the Fabric Interop WG).

        1. Thank you for your attention. Today I discussed this issue with Cello's contributor Tong Li . We believe that it is a good idea to incorporate some of the advantages of Justitia and the results of the Fabric Interop WG into the cello.

          1. Are you saying that some pieces of Justitia may move to cello?  I certainly hope that all of Justitia will move to cello.

            I looked through the code and the functionality of Justitia.  Here are my recommendations / suggestions for moving forward:

            1.  The unique value of Justitia is around consortium management.  I believe that's what the project should focus on moving forward.
            2.  Code which deals with deployment of Fabric nodes should be removed and/or integrated with cello if it makes sense.
            3.  Code which monitors Fabric should also be removed.  There are many standard, turnkey monitoring tools (e.g. Prometheus) which will work with Fabric.
            1. Your suggestion is very suitable, we are also planning to do it.

  8. Gari, does this mean that the Fabric maintainers will be investing their time in this code as well, and taking responsibility for it to the TSC?  As it does for the SDK "subprojects", with air quotes used as we never really formalized the structure anyways, and the Fabric SDK maintainers don't report quarterly separately to the TSC, as issues related to those SDKs are presumed to be included in the Fabric quarterly report.  That is, the SDKs are very closely aligned with releases of Fabric, so it makes sense that they are part of the same project.  But will that also be true for Justitia?  For example, will Justitia new releases track Fabric new releases and features as closely as the SDKs do?  My sense is that the Fabric maintainers may be too busy for this, and that may be one reason to either make it a Lab to start or a separate project.

    We are sort of working this out now in the Project Lifecycle WG, and we can talk about this more at the TSC call, but we have to ensure that "subprojects" don't fall into an untracked void when it comes to reporting and responsibility between the code and the HL organization.   Currently, project maintainers are the responsible party to the TSC and the rest of the project for what's going on with code within their project.  Does Justitia benefit from having an additional layer of management (the Fabric maintainers) between them and the TSC?  Will Fabric quarterly updates include Justitia-related content?  Those should be a few of the determining questions as to whether it makes sense to be a part of the Fabric project, not whether the project is 100% focused or not.

    1. I guess my response below answered "yes" to the questions at the beginning of your comment.  (smile)

  9. I don't think it makes sense to have a project which is focused on adding capability to another project (in this case consortium management) outside the umbrella of the other project.  This project specifically will need to stay in sync with Fabric ... else we'll end up where we did with Hyperledger Explorer being way behind in terms of supporting the latest Fabric versions.

    I do think that starting as a lab is probably the right way to go with a goal of becoming a subproject of Fabric.

  10. In summary portions of the code will go to Cello and other portions the Fabric community will work on integrating to Fabric, whether that's via the interop group a new repo or some other mechanism(s).

    Please correct me if I am substantially wrong. Otherwise we can conclude this proposal at the TSC level.

    1. Yes, your are right.