Skip to end of metadata
Go to start of metadata

Working Group

This report covers Technical Working Group China

Working Group Health

We are now struggling to call for new active volunteers. Most of past active volunteers retired. 

Questions/Issues for the TSC

  • Chinese Crypto Standards problem keeps on hinder usage of Hyperledger project in mainland China. Any suggestion?
  • Meanwhile, Chinese local growing blockchain technologies triangle developers' focus in consortium blockchain industry. 

Overall Activity in the Past Quarter

  • Translation for Fabric 2.x is under progress. 
  • By the end of Q2, we organize a 'Fabric GM Crypto fork open governance team' 
    A translation of proposal is here

  • The Hyperledger Fabric code project has a very wide range of adoptions in many domestic industries and institutions, and has a very basic role in the application of the blockchain industry.

    According to China's policy requirements, it is necessary to support the national secret (GM) encryption algorithm. Many domestic enterprises and Fabric enthusiasts have successively carried out some corresponding national secret (GM) transformation work, with outstanding achievements. However, in this matter, there is serious duplication of labor, and human resources are also greatly wasted.

    Here, the Hyperledger China Technical Working Group (TWGC) proposes that the majority of Fabric enthusiasts and users gather and work together to create a standard national cryptographic project of Hyperledger Fabric, which is shared by everyone, and finally meet the needs of community maintainer request, merge into the Fabric up-stream.

Planned Work Products

Translations. Community project incubation, Meetup
Chinese Crypto Standards configurable for Hyperledger Fabric 

Participant Diversity

Same as before, but a trend is most of Blockchain startups could not survive to keep participating in communities. 

Additional Information


Reviewed By


  • No labels

17 Comments

  1. I think you should rename this Q3 report. I'm happy to put this on this week's TSC call agenda so we can discuss the issue on crypto standards.

    1. I'd also love to participate in a discussion on what I assume would be a discussion on a modular crypto interface for Fabric.

      1. Originally Ursa was intended to meet this need for Fabric but with Fabric deciding to not adopt Ursa we need a new modular API. The Chinese crypto standards are open source and licensed correctly. My only concern is that compiling Fabric with any national crypto standard included needs to be something that takes extra work to explicitly enable it so that other users do not accidentally use the wrong crypto for their application.

        1. The big issue for Ursa/Fabric integration is the fact that there aren't good ways to call Rust code from Go code right now.  

        2. Indeed, it requires all users in the blockchain network to follow a strict guideline carefully, afaik

  2. Arnaud J Le Hors Hi Arnaud, it is our fault to delay release of Q2 report. And actually Q3 has further encouraging progress. I did the openFabricGM proposal in early June so I see it as part of Q2. 

    It has been for a while from last time I join TSC meeting. I would like to provide more details about it. 

    1. David, is there a page that summarizes the proposal to bring support for GM into upstream Fabric? Is there a Fabric RFC, pull request, Jira ticket, etc? If so, being able to read up on that ahead of time would help the TSC, to understand if the barriers are communication, policy, or technical.

      1. Brian Behlendorf We had a large-scale discussion and opinions gathering within TWGC. 
        All of raw meeting minutes reside in https://github.com/Hyperledger-TWGC/fabric-gm-wiki/wiki
        Inside the wiki we also try to summarize what we need Fabric do. But currently we could not specify all details we need. The size might be Fabric RFC. 

        • Hardcoded crypto part, including sha256,crypto/x509
          • GM is not supported in crypto/X509. This Go native package did not take crypto pluggable into concern.
        • Some configurable crypto options are outside of bccsp,including crypto_config section in each msp definition, HashingAlgorithm variable in channel scope. We need to know
          • Where are these designed to be used. 
          • How should Fabric behave if they conflict with BCCSP implementation. 


        From my personal point of view, barriers are mostly on technical side

        1. If there's a general sense from that discussion of mostly the right path forward, even if there are open questions, then I definitely suggest you create a Fabric RFC with the necessary details. It could reference any existing code that the modifiied Fabric installations in China have used, and specific open outstanding questions, such as the best way to get alternative crypto support in Go, etc. Even if there are big open questions, that's the way to get it in front of the Fabric maintainers for feedback and placing into a release stream.

  3. As a present to TSC meeting

  4. BSN has Fabric ... how did they deal with this?

    It would also be good to specify the actual crypto standards which are required.
    But I find it hard to believe that it posed challenges as I have built and sold multiple products in China w/o implementing any specific standards.

    1. I'm assuming you might be in charge of this part of Fabric, so I'll go ahead and ask.  How would you feel about an RFC that aimed to create a modular interface for crypto primitives in Fabric (in Go, of course)?  We (at Fujitsu) have some applications where we want to use BLS signatures (pairing-based) for the validators and orderers in Fabric.  I can't promise at this point, but there's a decent chance we'll have resources available to make these code changes in Fabric (and we wouldn't propose an RFC unless we had the manpower to follow through, of course).  This would also seemingly solve the TWGC issues as well.

      Thoughts?

      Also, Angelo, if you are reading this:  what do you think the easiest way to use BLS signatures in Fabric would be?

    2. According to news, 2020 July 31, BSN updates include a fork of Fabric with GM support as beta release. 

      I did not see it as challenges either, until the specification released along with community feedback and questions.

      Specification list

      • SM3 (GM/T 0004-2012): cryptographic hash function with 256-bit digest length.
      • SM4 (GM/T 0002-2012): block cipher with 128-bit key length and 128-bit block size, also named SMS4.
      • SM2 (GM/T 0003-2012): elliptic curve cryptographic schemes including digital signature scheme, public key encryption, (authenticated) key exchange protocol and one recommended 256-bit prime field curve sm2p256v1.
      • SKF interface: GM/T 0016-2012 Smart token cryptography application interface specification.
      • SDF interface: GM/T 0018-2012 Interface specifications of cryptography device application.


  5. There seems to be a lot of interest in this topic.  Would you core Fabric maintainers on this (Gari, Angelo, etc.) consider setting up a meeting time (could be a part of the regular Fabric meetings) to discuss this so people who don't regularly attend all of the Fabric meetings can attend?  Thanks!

  6. We have the contributors meeting ... this would be a good topic to add to one of the agendas.

    1. Great.  Can you just announce to a wider audience when this is happening in advance?  Thanks!  

      1. According to usual frequency, the next one is 19 August