ZoKrates证明中的点序

Question

我正在尝试验证一个具有go-snark验证功能的ZoKrates proof (相同的bn128参数和G16协议)。但由于某些原因，它不能工作，我怀疑这是一个问题，在点的顺序。

在exported contract中，G1点的定义是一个具有两个uint的结构，而G2是一个具有22个uint的结构。

因此，库以这种方式声明生成器：

    /// @return the generator of G1
    function P1() pure internal returns (G1Point memory) {
        return G1Point(1, 2);
    }
    /// @return the generator of G2
    function P2() pure internal returns (G2Point memory) {
        return G2Point(
            [11559732032986387107991004021392285783925812861821192530917403151452391805634,
             10857046999023057135944570762232829481370756359578518086990519993285655852781],
            [4082367875863433681332203403145435568316851327593401208105741076214120093531,
             8495653923123431417604973247489272438418190587263600148770280649306958101930]
        );
    }

同时，go-snark package让它变成这样：

    b.Gg1 = [2]*big.Int{
        big.NewInt(int64(1)),
        big.NewInt(int64(2)),
    }

    g2_00, ok := new(big.Int).SetString("10857046999023057135944570762232829481370756359578518086990519993285655852781", 10)
    if !ok {
        return b, errors.New("err with g2_00")
    }
    g2_01, ok := new(big.Int).SetString("11559732032986387107991004021392285783925812861821192530917403151452391805634", 10)
    if !ok {
        return b, errors.New("err with g2_00")
    }
    g2_10, ok := new(big.Int).SetString("8495653923123431417604973247489272438418190587263600148770280649306958101930", 10)
    if !ok {
        return b, errors.New("err with g2_00")
    }
    g2_11, ok := new(big.Int).SetString("4082367875863433681332203403145435568316851327593401208105741076214120093531", 10)
    if !ok {
        return b, errors.New("err with g2_00")
    }

    b.Gg2 = [2][2]*big.Int{
        [2]*big.Int{
            g2_00,
            g2_01,
        },
        [2]*big.Int{
            g2_10,
            g2_11,
        },
    }

所以g1点的顺序是相同的(我猜)，但是g2点是颠倒的，我猜所有的bn128点( pk，vk和证明中的点)都是一样的。这是因为一个错误的声明吗？或者实体化中的数组索引被颠倒了？结构声明的方式是相同的吗? proof.json和verification.key中的点是不是为了让它们在可靠的情况下工作？

我有点迷失在我必须改变的点的顺序，在证明和验证密钥中的阿尔法，贝塔，伽马和增量点，使其在golang程序中工作。我甚至不确定输入数组的顺序。

Answer 1

所以我想通了。简短的答案是，对于每一种理智的语言，固定性和go都有相同的索引顺序，如果曲线点的定义是一致的，那么顺序并不重要。

我的问题是在两个包中G2点的定义是不同的(可靠合约和go-snark)，所以我更改为go的clearmatic bn256包，它是专门为与以太坊一起工作而构建的，一切都很好。