fix: broken uint256_t conversion operator

[ludamad]

Bug reported by Lucas. Look at the diff, then consider this code

#include <iostream>
#include <concepts>

class Uint256_t {
public:
    // Conversion operator (explicit)
    template <std::integral T>
    explicit operator T() const {
        std::cout << "Uint256_t conversion operator called\n";
        return static_cast<T>(data[0]);
    }
    int data[4] = {0,0,0,0};
};

class Field {
public:
    Field() {}
    Field(int x) {
        std::cout << "This is silly!!!!" << std::endl;
    }
    Field(const Uint256_t& input) {
        (void)input;
        std::cout << "Field constructor called\n";
    }
};

class Toot {
    public:
    Toot(Field f) {
          (void)f;
    }
};

int main() {
    Uint256_t uint256_value;
    Toot t{uint256_value};

    return 0;
}

With std::integral concept on the cast:

Field constructor called

but without! which was caught in practice passing a uint256 to FieldSponge

Uint256_t conversion operator called
This is silly!!!!

This truncated the field mysteriously! Open-ended conversion operators are dangerous

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_history_trial_decrypting_time_in_ms (10): 346 (+48%)
• note_trial_decrypting_time_in_ms (8): 20.4 (-45%)

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Values are compared against data from master at commit 379b5adc and shown if the difference exceeds 1%.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	128 txs
l1_rollup_calldata_size_in_bytes	45,444	179,588	716,132
l1_rollup_calldata_gas	222,912	868,280	3,447,980
l1_rollup_execution_gas	841,999	3,595,388	22,203,349
l2_block_processing_time_in_ms	2,198 (-6%)	8,514	35,297 (-1%)
note_successful_decrypting_time_in_ms	312 (-4%)	929 (+1%)	3,402 (-2%)
note_trial_decrypting_time_in_ms	⚠️ 20.4 (-45%)	58.8 (+20%)	200 (-1%)
l2_block_building_time_in_ms	20,238	80,690 (+1%)	323,750
l2_block_rollup_simulation_time_in_ms	16,687	66,713 (+1%)	267,584
l2_block_public_tx_process_time_in_ms	3,519	13,889	55,916

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	24,662 (-1%)	47,363 (-1%)
note_history_successful_decrypting_time_in_ms	2,157	4,155 (-1%)
note_history_trial_decrypting_time_in_ms	162 (-1%)	⚠️ 346 (+48%)
node_database_size_in_bytes	3,625,994	3,920,650
pxe_database_size_in_bytes	29,748	59,307

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	199	43,109	20,441
private-kernel-ordering	115	25,833	9,689
base-rollup	2,958	667,692	873
root-rollup	90.4 (+6%)	4,072	881
private-kernel-inner	260	64,516	20,441
public-kernel-private-input	172 (+1%)	25,203	20,441
public-kernel-non-first-iteration	168 (-1%)	25,245	20,441
merge-rollup	10.8 (-1%)	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	10,323	25,938

[lucasxia01]

looks good; thanks for the help in diagnosis and fixing this!

[lucasxia01]

I also see this same line in field.fuzzer.hpp; no need to change there too?

[ludamad]

I guess it wasn't used, and we'll hit errors when we try to use it.