docs: Wallet dev docs #1746
Merged
docs: Wallet dev docs #1746
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iAmMichaelConnor
requested changes
Aug 24, 2023
There was a problem hiding this comment.
Thanks very much for this!
I've added some questions and comments. Most of my questions come from me not having parteken in many of the discussions relating to what a wallet is, so they're genuine questions that are arising as I read the text. Other readers might have those same questions. :)
|
|
||
| Architecture-wise, a wallet is an instance of an **Aztec RPC Server** which manages user keys and private state and communicates with an **Aztec Node** for retrieving public information or broadcasting transactions. Note that the RPC server requires a local database for keeping private state, and is also expected to be continuously syncing new blocks for trial-decryption of user notes. | ||
|
|
||
| Additionally, a wallet must implement an **Entrypoint** interface that defines [how to create an execution request](./main.md#transaction-lifecycle) out of a user intent for the specific implementation of account contract used by the wallet. Think of the entrypoint interface as the Javascript counterpart of an account contract, or the piece of code that knows how to format and authenticate a transaction based on the rules defined in Noir by the user's account. |
There was a problem hiding this comment.
for the specific implementation of account contract used by the wallet
Maybe before this paragraph, it would be helpful to explain this point. Is a wallet always built with one type of account contract in mind? Can a wallet be designed to work with many types of account contract? Can users customise their own account contracts and use those with any wallet, or are users restricted in their choice of account contract based on the wallet they choose to use?
|
|
||
| Architecture-wise, a wallet is an instance of an **Aztec RPC Server** which manages user keys and private state and communicates with an **Aztec Node** for retrieving public information or broadcasting transactions. Note that the RPC server requires a local database for keeping private state, and is also expected to be continuously syncing new blocks for trial-decryption of user notes. | ||
|
|
||
| Additionally, a wallet must implement an **Entrypoint** interface that defines [how to create an execution request](./main.md#transaction-lifecycle) out of a user intent for the specific implementation of account contract used by the wallet. Think of the entrypoint interface as the Javascript counterpart of an account contract, or the piece of code that knows how to format and authenticate a transaction based on the rules defined in Noir by the user's account. |
There was a problem hiding this comment.
out of a user intent
How is a 'user intent' expressed / what does it look like?
|
|
||
| ## Entrypoint interface | ||
|
|
||
| The entrypoint interface is used for creating an execution request out of a set of function calls that describe user intents. Note that an account contract may not handle batching, in which case it is expected to throw if more than a single function call is requested. |
There was a problem hiding this comment.
Is this a contradiction:
"...out of a set of function calls that describe user intents"
"...is expected to throw if more than a single function call is requested".
Can a user intent be more than one function call?
docs/docs/dev_docs/wallets/main.md
Outdated
|
|
||
| Every transaction in Aztec is broadcasted to the network as its zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets. | ||
|
|
||
| A wallet is responsible for first **creating** an [execution request](../../concepts/foundation/accounts/main.md#execution-requests). This means going from an intent, such as _call transfer on this contract_, to an authenticated transaction formatted for the user's account contract. As an example, given an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/95d1350b23b6205ff2a7d3de41a37e0bc9ee7640/yarn-project/noir-contracts/src/contracts/ecdsa_account_contract/src/main.nr#L1), an execution request has the account contract as `origin`, calls its `entrypoint` function, and encodes the user intent as `payload`, which is signed using ECDSA with a private key managed by the wallet. |
There was a problem hiding this comment.
A wallet is responsible for first creating an execution request. This means going from an intent, such as call transfer on this contract, to an authenticated transaction formatted for the user's account contract
So does a wallet include an implementation of 'aztec.js', or is a wallet just the Aztec RPC Server?
I guess I'm confused still by what an intent is, in this context. A human thought (an intent such as "call transfer on this contract") is translated into the human pressing a button, which is translated by aztec.js into a JSON RPC call to the Aztec RPC Server, which is translated into arguments that can be consumed by an account contract.
Would it be truer to say that the wallet's responsibilities actually begin when it receives a JSON RPC transaction request object, and then the wallet takes that object and formats it into a 'transaction request' format that can be read by the simulator (which then formats the transaction request again into arguments that can be read by the account contract)? (I.e. that the translation of an intent into JSON RPC format is actually done outside of the wallet, before reaching the wallet?)
There was a problem hiding this comment.
Perhaps a takeaway from some of my questions so far, is that we'll need to be consistent about naming things, perhaps to the point of eventually needing a glossary, or links to actual javascript object descriptions.
Some terms that have come up so far over the past couple of pages (and in my brain):
Intent, transaction, authenticated transaction, execution request, transaction request, payload, call, transaction origin, account, account contract, account contract implementation, the various formattings of a 'transaction request' for various components, function call, enqueued function, function request, entrypoint, transaction formatting, transaction authentication, execution trace, side effect.
docs/docs/dev_docs/wallets/main.md
Outdated
| Once the execution request is created, it is **simulated** to retrieve an execution trace. This provides the user with a list of the side effects of a transaction if it is successfully mined, and a trace to be fed into the prover. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. | ||
|
|
||
| :::info | ||
| Since private executions rely on a UTXO model, the side effects of a transaction cannot change when mined. However, the transaction can be dropped due to attempting to consume a private note that another transaction consumes before it is mined. Also, any side effects that arise from its public execution _can_ change, as in any EVM-based chain. |
There was a problem hiding this comment.
Also, any side effects that arise from its public execution can change, as in any EVM-based chain
Do the 'side effects that arise from its public execution' change, or is it really that those side effects aren't determined until the sequencer begins public execution?
Co-authored-by: Michael Connor <[email protected]>
|
@iAmMichaelConnor thanks as always for the thorough review (I still don't know how to find the time to go this in-depth in all docs!). I've submitted a bunch of changes that I hope address all comments, please take another look! |
iAmMichaelConnor
approved these changes
Aug 25, 2023
spalladino
added a commit
that referenced
this pull request
Aug 25, 2023
Tutorial for writing an account contract. Includes tweaks to payload helpers in aztec.js to make the process easier. Fixes #1744 See also #1746 --------- Co-authored-by: Michael Connor <[email protected]>
dan-aztec
pushed a commit
that referenced
this pull request
Aug 25, 2023
Tutorial for writing an account contract. Includes tweaks to payload helpers in aztec.js to make the process easier. Fixes #1744 See also #1746 --------- Co-authored-by: Michael Connor <[email protected]>
dan-aztec
added a commit
that referenced
this pull request
Aug 25, 2023
refactor: consistent block number method naming (#1751) Renamed `AztecRPC.getBlockNum` to `getBlockNumber` and`AztecNode.getBlockHeight` to `getBlockNumber`. I decided to use the name block number because in the Ethereum JSON RPC spec there is `eth_blockNumber` call and I think it's a good idea to use the same naming. git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "324402a78" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "324402a78" git-subrepo: version: "0.4.6" origin: "???" commit: "???" refactor: Use context instead of custom oracles for public functions (#1754) Fixes #1753, #1755 and use context for nullifiers and commitments in public. docs: convert quick start guides into e2e tests (#1726) Fixes #1564 git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "ba5d7a6bc" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "ba5d7a6bc" git-subrepo: version: "0.4.6" origin: "???" commit: "???" feat(ci): Initial release please config (#1769) PR with initial release please configuration 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). docs: including "real" code in keys docs (#1767) Including "real" code in keys docs + addressed one Noir TODO so that it doesn't get shown inside the docs. git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "842a54250" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "842a54250" git-subrepo: version: "0.4.6" origin: "???" commit: "???" feat: not retrying unrecoverable errors (#1752) Fixes #1511 Fixes #1724 With this PR all the errors thrown in the server code are considered to be unrecoverable. Recoverable errors should not be errors and should be handled (or shown only as warnings). For example I refactored the `registerAccount` and `registerRecipient` to not throw if we add the same recipient/account twice because that situation is easily recoverable (just ignore it). 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). feat: compress debug symbols (#1760) Partial work towards #1224 While working on brillig debug symbols I noticed that the JSON ABIs started to weight more than some megabytes and started to create issues for the typescript type inference, since we're importing them as json modules. This PR addresses that by just compressing the debug symbols and decompressing them transparently in the utility function that we have for this in foundation. I used https://www.npmjs.com/package/pako for gzip since it should be compatible with the browser without issue. 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. - [x] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [x] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). ci: Updated release please config (#1773) This PR contains further release-please configuration changes. 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). feat(bb): Use an environment variable to set the transcript URL (#1750) Related to #1749 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). git subrepo push --branch=master circuits/cpp/barretenberg subrepo: subdir: "circuits/cpp/barretenberg" merged: "41d362e9c" upstream: origin: "https://github.com/AztecProtocol/barretenberg" branch: "master" commit: "41d362e9c" git-subrepo: version: "0.4.6" origin: "???" commit: "???" chore(ci): Updated release please config (#1775) This PR provides further release-please configuration changes. 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). chore(ci): set up nightly barretenberg releases (#1761) This PR pulls across the publishing workflow from Noir so that barretenberg can have nightly releases. 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. - [x] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [x] Every change is related to the PR description. - [x] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). chore(master): release 0.1.0-alpha45 (#1774) :robot: I have created a new Aztec Packages release --- [0.1.0-alpha45](v0.1.0-alpha44...v0.1.0-alpha45) (2023-08-23) * **bb:** Use an environment variable to set the transcript URL ([#1750](#1750)) ([31488c1](31488c1)) * **ci:** Initial release please config ([#1769](#1769)) ([4207559](4207559)) * compress debug symbols ([#1760](#1760)) ([9464b25](9464b25)) * not retrying unrecoverable errors ([#1752](#1752)) ([c0f2820](c0f2820)) * Download SRS using one canonical URL across the codebase ([#1748](#1748)) ([899b055](899b055)) * proving fails when circuit has size > ~500K ([#1739](#1739)) ([708b05c](708b05c)) * **ci:** set up nightly barretenberg releases ([#1761](#1761)) ([e0078da](e0078da)) * **ci:** Updated release please config ([#1775](#1775)) ([0085e8b](0085e8b)) * consistent block number method naming ([#1751](#1751)) ([df1afe2](df1afe2)) * Use context instead of custom oracles for public functions ([#1754](#1754)) ([46de77a](46de77a)) * convert quick start guides into e2e tests ([#1726](#1726)) ([802a678](802a678)), closes [#1564](#1564) * including "real" code in keys docs ([#1767](#1767)) ([cd9cadb](cd9cadb)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> chore: sync bb master (#1776) Ran: ``` ./scripts/git_subrepo.sh pull circuits/cpp/barretenberg git checkout origin/master -- .gitmodules ``` 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). git_subrepo.sh: Fix parent in .gitrepo file. git subrepo push --branch=master circuits/cpp/barretenberg subrepo: subdir: "circuits/cpp/barretenberg" merged: "1b1d24e82" upstream: origin: "https://github.com/AztecProtocol/barretenberg" branch: "master" commit: "1b1d24e82" git-subrepo: version: "0.4.6" origin: "???" commit: "???" update noir contract paths feat: CDP/Lending example contract (#1554) Finishing up the lending/cdp contract enough for show (no liqudation and unsecure as all the contracts). See #1460. more instructions also reference the generated typescript file start frontend integration w/sandbox cleaner parsing of functionAbi for yup schema re-add initialValues switch to rpcclient instead of server hardcode some private keys from fixtures try singleKeyAccount thanks adam for fixing webasm import switch to vite.config.js switch to privateKey class blocked by undefined methods attribute on the PrivateTokenContract object revert yarn.lock osx change use latest yarn.lock docs: events (#1768) Fixes #1756 git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "3c5f3c4a9" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "3c5f3c4a9" git-subrepo: version: "0.4.6" origin: "???" commit: "???" feat: no unencrypted logs in private functions (#1780) Fixes #1689 git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "40c05467f" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "40c05467f" git-subrepo: version: "0.4.6" origin: "???" commit: "???" chore(ci): Updated release please configuration (#1787) This PR contains further configuration changes and documentation for our usage of release please 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). chore(master): release 0.1.0-alpha46 (#1777) :robot: I have created a new Aztec Packages release --- [0.1.0-alpha46](v0.1.0-alpha45...v0.1.0-alpha46) (2023-08-24) * CDP/Lending example contract ([#1554](#1554)) ([ecf6df2](ecf6df2)) * no unencrypted logs in private functions ([#1780](#1780)) ([4d8002e](4d8002e)), closes [#1689](#1689) * **ci:** Updated release please configuration ([#1787](#1787)) ([6eb2f7a](6eb2f7a)) * sync bb master ([#1776](#1776)) ([7c6fb15](7c6fb15)) * events ([#1768](#1768)) ([5a38cea](5a38cea)), closes [#1756](#1756) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> chore: Add todo for using generator indices in note commitment and nullifier computation. (#1762) fix(noir): Add workaround for latest noir in account contracts (#1781) Workaround for this issue noir-lang/noir#2421 so we can update the aztec tag to master. 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. - [x] 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). chore: split out yarn-project bootstrap.sh (#1790) Allows for more modular bootstrapping. chore(p2p): Updated libp2p dependencies (#1792) This PR simply updates the libp2p dependencies to the newest versions. 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). feat: `FunctionSelector` type (#1518) Fixes #1424 chore: Sandbox logging tweaks (#1797) Packages a bunch of tweaks to Sandbox debugging and logging, such as: - Wasm debug logs are now prefixed as `aztec:wasm`, not `wasm`, so they are visible when debugging via `aztec:*` - Defaults sandbox logging to INFO instead of DEBUG - Allows users to configure sandbox debug by exporting `DEBUG='aztec:*'` in their shell (related to #1605) - Silences all anvil logs since they didn't provide any useful info (fixes #1580) - Renames container names in the sandbox docker-compose (anvil was not running a fork, and the sandbox is not just an rpc-server) fix: increment time by 1 for previous rollup was warped (#1594) With Warp ``` L2 block 1: occurred at t = 100. Call warp(200) => Rollup.sol's lastBlockTs = 200 & L1.setNextBlockTimeStamp = 200. L2 block 2: txs show t = 200. Rollup published at t = 200 => Rollup.sol's lastBlockTs = 200 L2 block 3: txs show t = 200. ``` Notice how txs in block 2 and block 3 show a timestamp of 200! This is confusing. So we check if the last rollup was warped (here block 2), and if so, txs in the next rollup (block 3) should show ts = 201. We check if last rollup was warped by introducing a variable in Rollup.sol that tracks the last time block was warped. Also Create #1614 fix: selector name regression (#1800) I introduced a regression in my function [selector type PR](#1518) which caused the selector name to be incorrect in circuits.gen.ts. The issue was with having different names for selector in FunctionData struct in TS and C++. This PR fixes it. chore(master): release 0.1.0-alpha47 (#1788) :robot: I have created a new Aztec Packages release --- [0.1.0-alpha47](v0.1.0-alpha46...v0.1.0-alpha47) (2023-08-25) * `FunctionSelector` type ([#1518](#1518)) ([942f705](942f705)), closes [#1424](#1424) * increment time by 1 for previous rollup was warped ([#1594](#1594)) ([2a52107](2a52107)) * **noir:** Add workaround for latest noir in account contracts ([#1781](#1781)) ([eb8a052](eb8a052)) * selector name regression ([#1800](#1800)) ([a5be8bb](a5be8bb)) * Add todo for using generator indices in note commitment and nullifier computation. ([#1762](#1762)) ([2db6728](2db6728)) * **p2p:** Updated libp2p dependencies ([#1792](#1792)) ([79df831](79df831)) * Sandbox logging tweaks ([#1797](#1797)) ([0e3914e](0e3914e)) * split out yarn-project bootstrap.sh ([#1790](#1790)) ([1788fe6](1788fe6)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> docs: Wallet dev docs (#1746) Developer docs on wallets. Introduces a new "architecture" section for wallets, that elaborates on the RPC server and entrypoints. Deletes the "building a wallet" tutorial, since building a wallet is excessively complex for a tutorial. Fixes #1741 Closes #1745 Pending #1744 git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "6f755743d" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "6f755743d" git-subrepo: version: "0.4.6" origin: "???" commit: "???" feat: Update safe_math and move to libraries (#1803) Fixes #1794 and address the wrong check in `mul`. Would prefer to add tests directly, but noir don't support failing tests in noir yet, so there is really no good reason to do that currently. See noir-lang/noir#1994 test: add browser test to canary flow (#1808) Adding Aztec.js browser test to our canary flow to ensure published npm package is stable 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). docs: Account contract tutorial (#1772) Tutorial for writing an account contract. Includes tweaks to payload helpers in aztec.js to make the process easier. Fixes #1744 See also #1746 --------- Co-authored-by: Michael Connor <[email protected]> git subrepo push --branch=main docs subrepo: subdir: "docs" merged: "2fd486a6c" upstream: origin: "https://github.com/AztecProtocol/docs" branch: "main" commit: "2fd486a6c" git-subrepo: version: "0.4.6" origin: "???" commit: "???" chore: fixed linter errors for `ecc`, `numeric` and `common` modules (#1714) The majority of the barretenberg codebase does not conform to our C++ style guide rules. This PR updates the `common`, `numeric` and `ecc` modules to conform to the guide. These 3 modules should now produce no linter errors. Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [x] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [x] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [x] Every change is related to the PR description. - [x] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist). --------- Co-authored-by: kevaundray <[email protected]> git subrepo push --branch=master circuits/cpp/barretenberg subrepo: subdir: "circuits/cpp/barretenberg" merged: "cca5c1bf1" upstream: origin: "https://github.com/AztecProtocol/barretenberg" branch: "master" commit: "cca5c1bf1" git-subrepo: version: "0.4.6" origin: "???" commit: "???" feat: More reliable getTxReceipt api. (#1793) Closes #1402 #1548 Previous approach had too many issues - only sender and the recipients (after they decrypt their notes) can call this api. The data in the receipt was not consistent. And the role of TxDao is confusing. Delete it now and remove some complicated code around it. 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist).
PhilWindle
pushed a commit
that referenced
this pull request
Aug 30, 2023
🤖 I have created a new Aztec Packages release --- ## [0.1.0-alpha48](v0.1.0-alpha47...v0.1.0-alpha48) (2023-08-30) ### Features * Add ARM build for Mac + cleanup artifacts ([#1837](#1837)) ([270a4ae](270a4ae)) * broadcasting 'public key' and 'partial address' as L1 calldata ([#1801](#1801)) ([78d6444](78d6444)), closes [#1778](#1778) * Check sandbox version matches CLI's ([#1849](#1849)) ([7279730](7279730)) * **docs:** adding some nitpick suggestions before sandbox release ([#1859](#1859)) ([c1144f7](c1144f7)) * More reliable getTxReceipt api. ([#1793](#1793)) ([ad16b22](ad16b22)) * **noir:** use `#[aztec(private)]` and `#[aztec(public)` attributes ([#1735](#1735)) ([89756fa](89756fa)) * Recursive fn calls to spend more notes. ([#1779](#1779)) ([94053e4](94053e4)) * Simulate enqueued public functions and locate failing constraints on them ([#1853](#1853)) ([a065fd5](a065fd5)) * Update safe_math and move to libraries ([#1803](#1803)) ([b10656d](b10656d)) * Write debug-level log to local file in Sandbox ([#1846](#1846)) ([0317e93](0317e93)), closes [#1605](#1605) ### Bug Fixes * Conditionally compile base64 command for bb binary ([#1851](#1851)) ([be97185](be97185)) * default color to light mode ([#1847](#1847)) ([4fc8d39](4fc8d39)) * Disallow unregistered classes in JSON RPC interface and match by name ([#1820](#1820)) ([35b8170](35b8170)) * Set side effect counter on contract reads ([#1870](#1870)) ([1d8881e](1d8881e)), closes [#1588](#1588) * Truncate SRS size to the amount of points that we have downloaded ([#1862](#1862)) ([0a7058c](0a7058c)) ### Miscellaneous * add browser test to canary flow ([#1808](#1808)) ([7f4fa43](7f4fa43)) * **ci:** fix output name in release please workflow ([#1858](#1858)) ([857821f](857821f)) * CLI tests ([#1786](#1786)) ([2987065](2987065)), closes [#1450](#1450) * compile minimal WASM binary needed for blackbox functions ([#1824](#1824)) ([76a30b8](76a30b8)) * fixed linter errors for `ecc`, `numeric` and `common` modules ([#1714](#1714)) ([026273b](026273b)) * Refactor Cli interface to be more unix-like ([#1833](#1833)) ([28d722e](28d722e)) * sync bb master ([#1842](#1842)) ([2c1ff72](2c1ff72)) * sync bb master ([#1852](#1852)) ([f979878](f979878)) * sync bb master ([#1866](#1866)) ([e681a49](e681a49)) * typescript script names should be consistent ([#1843](#1843)) ([eff8fe7](eff8fe7)) * use 2^19 as `MAX_CIRCUIT_SIZE` for NodeJS CLI ([#1834](#1834)) ([c573282](c573282)) ### Documentation * Account contract tutorial ([#1772](#1772)) ([0faefba](0faefba)) * Wallet dev docs ([#1746](#1746)) ([9b4281d](9b4281d)), closes [#1744](#1744) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Developer docs on wallets. Introduces a new "architecture" section for wallets, that elaborates on the RPC server and entrypoints. Deletes the "building a wallet" tutorial, since building a wallet is excessively complex for a tutorial.
Fixes #1741
Closes #1745
Pending #1744