zac-williamson

use dep::std::field::bn254::assert_gt;

struct ListItem {
    key: Field,
    value: Field,
    previous: Field,
    next: Field,
}

impl ListItem {

zac-williamson

0x19d35776bbe54be2abfebd10bf3effc52a5988cc45769ac2bce8de6fb85c6f0d

zac-williamson

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract TestReturnPatterns {

    struct Big
    {
        uint256[256] data;
    }

    function returnByValue() internal pure returns (Big memory big)

zac-williamson

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;

contract Test {

    bytes32 private constant CONST = keccak256(abi.encodePacked("Hello World"));

    function bar() public pure returns (bytes32) {
        return CONST;
    }

zac-williamson

// requires barretenberg numeric dependency
#include <stdio.h>
#include <math.h>
#include <inttypes.h>
#include <x86intrin.h>
#include <stdlib.h>

#include <numeric/random/engine.hpp>

namespace {

zac-williamson

Lagrange-base SRS

Our current reference string is in monomial form, having one in lagrange-base form would singificantly improve prover times.

In Barretenberg, our current reference string is interacted with via the io class.

The SRS is contained in srs_db/transcript.dat. It is stored in a raw binary format, with group elements packed into adjacent 64 byte chunks.

The transcript.dat file contains a 'manifest' object at the start of the file, which contains basic details like the SRS size.

zac-williamson

const crypto = require('crypto');
const BN = require('bn.js');

const p = new BN('30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000001', 16);
const pRed = BN.red(p);

function randomGroupScalar = () => {
    return new BN(crypto.randomBytes(32), 16).umod(p);
}

zac-williamson

const crypto = require('crypto');
const BN = require('bn.js');

const p = new BN('30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000001', 16);
const pRed = BN.red(p);

function randomGroupScalar = () => {
    return new BN(crypto.randomBytes(32), 16).umod(p);
}

zac-williamson

running 316 tests
test block::tests::enact_block ... ignored
test block::tests::enact_block_with_uncle ... ignored
test block::tests::open_block ... ignored
test builtin::tests::bn128_add ... ignored
test builtin::tests::bn128_mul ... ignored
test builtin::tests::bn128_pairing_empty ... ignored
test builtin::tests::bn128_pairing_fragmented ... ignored
test builtin::tests::bn128_pairing_notcurve ... ignored
test builtin::tests::ecrecover ... ignored

zac-williamson

03 May 2019, Updated Parity Benchmarks

These Parity client benchmarks were run to evaluate the optimizations made to the Parity bn pairing library (link here)

By comparing pre- and post- benchmarks there is a significant improvement to the speed of multiple bilinear pairings that merits a reduction in the gas schedule.

The new benchmarks were run on branches that are currently outstanding pull requests into the Parity client (openethereum/parity-ethereum#10624) and the BN library (paritytech/bn#14).

The previous benchmarks were computed on 25 Oct 2018