feat: Parsing non-string assertion payloads in noir js

[sirasistant]

This PR adds a noirc_abi_wasm entrypoint for decoding ABI error types. This entrypoint is used by noir_js when an execution error is detected to try to decode the error using the ABI.
If the result from decoding the error is a string (such as a fmt string assertion, that previously weren't decoded at all) it'll patch the error message to include the formatted string.
If the result from decoding the error is a non-string payload (structs, tuples, arrays, etc) it'll add the decodedPayload property to the error so users can get the data back from the circuit.
Also, this PR refactors ErrorSelector so it's a shared struct, instead of being casted to u64 outside of the compiler backend.

[AztecBot]

Benchmark results

No metrics with a significant change found.

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.

L2 block published to L1

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

Metric	8 txs	32 txs	64 txs
l1_rollup_calldata_size_in_bytes	740	740	740
l1_rollup_calldata_gas	6,692	6,692	6,668
l1_rollup_execution_gas	586,824	586,824	586,800
l2_block_processing_time_in_ms	1,506 (-10%)	5,628 (-1%)	10,559 (-2%)
l2_block_building_time_in_ms	22,789 (+1%)	88,822	177,285 (-1%)
l2_block_rollup_simulation_time_in_ms	22,582 (+1%)	88,076	175,820 (-1%)
l2_block_public_tx_process_time_in_ms	9,004	34,661 (-1%)	69,538 (-1%)

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	17,749 (+2%)	32,674 (+2%)
node_database_size_in_bytes	20,766,800	37,404,752
pxe_database_size_in_bytes	29,868	59,425

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	175 (-1%)	46,819	28,822
private-kernel-inner	205	76,734	28,822
private-kernel-ordering	228 (-1%)	53,040	42,751
base-parity	70.2 (+2%)	128	64.0
base-rollup	16,482	111,062	925
root-parity	1,552 (-4%)	27,064	64.0
root-rollup	64.7	11,454	789
public-kernel-app-logic	1,983	54,321	22,677
public-kernel-tail	4,833 (-1%)	159,770	3,898
merge-rollup	6,538	2,696	925
public-kernel-teardown	162 (+1%)	54,321	30,042
public-kernel-setup	223 (+1%)	54,321	30,042

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	16 leaves	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves	32 leaves
batch_insert_into_append_only_tree_16_depth_ms	10.9	18.0 (+1%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.7	31.8	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.638 (-1%)	0.552 (+1%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	51.7	80.4 (+1%)	262	504 (+1%)	991	1,953	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	543	1,055	2,079	4,127	N/A
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.529	0.496	0.477	0.470 (+1%)	0.469	0.467	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.9 (+1%)	121 (+1%)	377	742 (+1%)	1,477	2,933	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.535	0.541	0.512	0.509	0.509	0.508 (-1%)	N/A
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	67.0
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	108
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.588

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	44,613	535,433

Transaction size based on fee payment method

Metric	native fee payment method	fpc_public fee payment method	fpc_private fee payment method
tx_with_fee_size_in_bytes	897	1,145	1,345

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	1,398 (-1%)	1,012	3,698 (+1%)

Metric	1 public data writes	2 public data writes	3 public data writes	4 public data writes	5 public data writes	8 public data writes
tx_sequencer_processing_time_ms	879 (-1%)	798 (+1%)	1,431 (+1%)	939 (+1%)	2,220 (+2%)	1,123 (+1%)

[sirasistant]

It's serialized as string since the Serde<>JsValue bridge that we use serializes u64s as JS numbers, which don't have enough precision to store u64s.

[vezenovm]

We could also just move to u32 right? I don't foresee error selectors hitting that bound. But this is non-blocking

[sirasistant]

It succesfully decodes the format string now

[vezenovm]

I'm good with these changes but want to let @TomAFrench also take a look

[vezenovm]

We could also just move to u32 right? I don't foresee error selectors hitting that bound. But this is non-blocking

[TomAFrench]

I can take a look at this tomorrow.

[TomAFrench]

Don't really have time to look at this properly so just going to defer to Maxim's review on this.

[TomAFrench]

Build is failing however.

[sirasistant]

We could also just move to u32 right? I don't foresee error selectors hitting that bound

Not sure, the FxHasher does weird things. If we switch the computation of the selector to some random-oracle hasher like sha256 I'd be more confident with moving to u32. Maybe we can do that, hash the types with sha256 and move to u32!