Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ci] Spot instance limits #1210

Closed
ludamad opened this issue Jul 26, 2023 · 2 comments
Closed

[ci] Spot instance limits #1210

ludamad opened this issue Jul 26, 2023 · 2 comments

Comments

@ludamad
Copy link
Collaborator

ludamad commented Jul 26, 2023

We are hitting spot instance limits in CircleCI. I hypothesize this is due to a lot of instances running just to be in the end skipped.

A few solutions:

  • Do a workflow computation step along with https://circleci.com/docs/dynamic-config/, although this would redundantly have to do dependency resolution.
  • Bump our resources.
  • Some third way to cut back on resource usage could be explored.
@github-project-automation github-project-automation bot moved this to Todo in A3 Jul 26, 2023
@ludamad
Copy link
Collaborator Author

ludamad commented Jul 27, 2023

Screenshot 2023-07-27 at 11 13 26 AM I have turned this on cc @dbanks12

@ludamad
Copy link
Collaborator Author

ludamad commented Aug 1, 2023

This seems to have subsided. However, keeping this open in case we want to go back to spot instances after turning on circleci runners

iAmMichaelConnor pushed a commit that referenced this issue Aug 3, 2023
@dbanks12
chore: rework nonces (#1210) (#1331)
665cb75 
# Description

The way nonces work now, there can be inconsistencies in nonce
assignment in the simulator vs the private kernel. Furthermore, you
cannot know during function execution what the full set of commitments
will be for the whole TX as some new commitments may be nullified and
squashed. But we still want the ability to determine nonces and
therefore uniqueNoteHashes from L1 calldata alone. I am sure I am not
explaining all of the issues well enough, but it was determined that the
current nonce paradigm will not work and therefore we must rework it.

Rework nonces so that siloing by contract address happens first and
uniqueness comes later. For now, nonces are injeced by the private
ordering circuit (vs suggestion which was base rollup circuit). Pending
notes and their reads have no nonces when processed in kernel. The
public kernel (and therefore all commitments created in public
functions) does not use nonces.

Here was Mike's proposal for the rework:

![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/7b20c886-1e92-452c-a886-c3da5ed64e17)

Why not just use leaf index as nonce?

![image](https://github.com/AztecProtocol/aztec-packages/assets/47112877/e6337107-ac93-4a3b-b83c-27213cb5133d)

## Followup tasks
* #1029
* #1194
* #1329
* #1407
* #1408
* #1409
* #1410
* Future enhancement: The root rollup circuit could insert all messages
at the very beginning of the root rollup circuit, so that txs within the
rollup can refer to that state root and read L1>L2 messages immediately.
* #1383
* #1386
* We should implement subscription / polling methods for Aztec logs
* We should maybe write rpc functions which allow calldata to be
subscribed-to, keyed by tx_hash.
* If a dapp wants to write a note from a public function, a lot of honus
will be on a dapp developer to retain preimage information, query the
blockchain, and derive the nonce. We should provide some examples to
demonstrate this pattern.
@ludamad ludamad closed this as completed Sep 26, 2023
@github-project-automation github-project-automation bot moved this from Todo to Done in A3 Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
A3
Archived in project
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ludamad