feat: add cli command update aztec dependencies

[alexghr]

This PR adds a new command to aztec-cli to update a contract's Aztec.nr and @aztec dependencies.

LE: This command was refactored to update and now updates both Nargo.toml and package.json.

Fix #2870

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
@ltd/j-toml	1.38.0	None	+0	812 kB	ltd

🚮 Removed packages: toml@3.0.0

[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.

Values are compared against data from master at commit db67aa1e 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,960	868,280	3,447,992
l1_rollup_execution_gas	842,047	3,595,388	22,203,361
l2_block_processing_time_in_ms	2,012	7,539 (-1%)	29,690
note_successful_decrypting_time_in_ms	295 (+2%)	867 (+2%)	3,154 (-2%)
note_trial_decrypting_time_in_ms	95.0 (+2%)	76.0 (+25%)	136
l2_block_building_time_in_ms	13,265 (+1%)	52,353	209,672
l2_block_rollup_simulation_time_in_ms	11,925 (+1%)	47,057	188,488
l2_block_public_tx_process_time_in_ms	1,299 (+2%)	5,168 (+1%)	20,696 (+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	21,834 (+1%)	42,368
note_history_successful_decrypting_time_in_ms	2,076 (+2%)	4,020 (+1%)
note_history_trial_decrypting_time_in_ms	121	142 (-24%)
node_database_size_in_bytes	1,631,037	1,093,464
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	72.6	61,697	18,841
private-kernel-ordering	43.5	24,233	8,089
base-rollup	1,771	656,309	811
root-rollup	75.6 (-3%)	4,072	1,097
private-kernel-inner	53.6 (+1%)	81,504	18,841
public-kernel-private-input	41.8 (+1%)	41,455	18,841
public-kernel-non-first-iteration	26.8 (+1%)	41,497	18,841
merge-rollup	0.964 (+6%)	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	8,723	27,240

[rahul-kothari]

some fixes as discussed

[rahul-kothari]

add ability to update globally installed aztec-cli too btw (if possible - or is that chicken and egg?)

[rahul-kothari]

This doesn't really fix #2973 though does it? The intention of 2973 was that sandbox/cli can error if nargo.toml is not up to date with the sandbox version

[alexghr]

This doesn't really fix #2973 though does it? The intention of 2973 was that sandbox/cli can error if nargo.toml is not up to date with the sandbox version

🤦 you're right, linked to wrong ticket

[alexghr]

add ability to update globally installed aztec-cli too btw (if possible - or is that chicken and egg?)

It would depend on how they installed: npm, yarn or (soon) docker. Maybe we could end the update command with a reminder to the user to do it themselves?

[spalladino]

The implementation looks good to me, though I'm not a fan of trying to upgrade stuff on behalf of the user. I'd rather warn them of the incompatibility, but let them do the upgrade with the tools they're using and with the install method they prefer. Still, I'm up for testing if this ends up helping a good majority of users!

[rahul-kothari]

I'd rather warn them of the incompatibility, but let them do the upgrade with the tools they're using and with the install method they prefer
You bring a good point on various installation methods!

Re "warn them of the incompatibility" - tbh not too sure how we could do that? I guess fetch sandbox version and then manually read package.json/nargo.toml to see if the version matches?

palla already reviewed

[spalladino]

though I'm not a fan of trying to upgrade stuff on behalf of the user

Given the positive feedback we got from Wonderland when you showcased this to them, I'm willing to eat my words here!

Re "warn them of the incompatibility" - tbh not too sure how we could do that? I guess fetch sandbox version and then manually read package.json/nargo.toml to see if the version matches?

What I had in mind was exporting the versions of the dependencies used for compiling the contract in the json build artifact, and have the sandbox (pxe) validate them when deploying a contract.