herumi / bls

288 stars 132 forks source link

blsInit returns -246046 when building with BLS_ETH=1 #97

Closed aguycalled closed 1 year ago

aguycalled commented 1 year ago
#include <bls/bls384_256.h> // must include this before bls/bls.h
#include <bls/bls.h>

void MclInitializer::Init()
{
    boost::lock_guard<boost::mutex> lock(MclInitializer::m_init_mutex);
    static bool is_initialized = false;
    if (is_initialized) return;

    if (blsInit(MCL_BLS12_381, MCLBN_COMPILED_TIME_VAR) != 0) {
        throw std::runtime_error("blsInit failed");
    }
    mclBn_setETHserialization(1);

    is_initialized = true;
}

The issue disappears when building with simple make without BLS_ETH=1.

herumi commented 1 year ago

Your code must be compiled with -DBLS_ETH=1. How about append #define BLS_ETH 1 before including bls/bls384_256.h? And you don't have to include bls.h, which is included from bls384_256.h.

gogoex commented 1 year ago

I observed that when BLS_ETH=1 is set, calling mclBnG1_hashAndMapTo is no longer equivalent of calling mclBnFp_setHashOf and mclBnFp_mapToG1 because BN::param.mapTo.mapTo_WB19_.msgToG1 is called instead of setHashOf and mapToG1 since the mode is set to MCL_MAP_TO_MODE_HASH_TO_CURVE_07.

Is this expected behavior?

herumi commented 1 year ago

Yes. Those codes are very complicated for historical reasons and backward compatibility. If you want Ethereum compatibility, then use hashAndMapToG1 instead of setHashOf/mapToG1.

gogoex commented 1 year ago

Thank you for the confirmation. Regarding the blsInit issue, it was resolved following your suggestion.