diff --git a/docs/docs/aztec-connect-sunset.mdx b/docs/docs/aztec-connect-sunset.mdx new file mode 100644 index 000000000000..7014a1b4564e --- /dev/null +++ b/docs/docs/aztec-connect-sunset.mdx @@ -0,0 +1,92 @@ +--- +title: Aztec Connect Sunset +--- + +import Image from "@theme/IdealImage"; + +:::danger + +Aztec Connect is no longer being actively developed. + +::: + +The rollup instance operated by Aztec will stop accepting deposits soon. Read the full announcement [here](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae). + +We will continue to process transactions and withdrawals for funds that are already in the rollup. We will stop running the sequencer in March 2024. See the [zk.money](#zkmoney) section below for details on how to withdraw funds. + +## Run your own AC + +All of the infrastructure and associated code required to run and interact with the Aztec Connect rollup is open source, so anyone can publish blocks after we stop, or run their own instance of the rollup software. + +You can find the old documentation site that includes all of the pertinent information on the [`aztec-connect` branch](https://github.com/AztecProtocol/docs/tree/aztec-connect) of the docs repository. + +The code has been open sourced and you can find the relevant repositories linked below. + +### Source Code + +Follow the links for more information about each package. + +- [Running the rollup service](https://github.com/AztecProtocol/aztec-connect/blob/master/yarn-project/README.md) +- [Sequencer](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/falafel) +- [Contracts](https://github.com/AztecProtocol/aztec-connect/tree/master/contracts) +- [SDK](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/sdk) +- [Alpha SDK](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/alpha-sdk) +- [Wallet UI](https://github.com/AztecProtocol/wallet-ui) + +## Zk.money + +### Exiting Defi Positions + +1. Navigate to your zk.money homepage and click “Wallet”. +2. Scroll down to “Tokens” and “Earn Positions”. +3. Click “Earn Positions”. +4. Click “Claim & Exit” on the position you wish to exit. +5. All exit transactions are free in “Batched Mode” proceed to step 6 to get a free transaction. +6. Click “Max” to exit the full amount, and then select a speed for your transaction. +7. Once you have done so, click “Next”. +8. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”. +9. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask in this example). +10. Wait until your transaction is confirmed. +11. Navigate back to your wallet homepage and click “Earn Positions”. +12. The status of your exit will be displayed here, as shown by “Exiting” (1 tick). +13. To the left, click the transaction hash icon to be taken to the block explorer page to see the transaction status. +14. Your funds will appear in your dashboard once the transaction has settled. + +### Exiting LUSD Borrowing + +Your LUSD debt is repaid using a flash loan. Part of your ETH collateral then repays the flash loan, and the remaining ETH is returned to your account. Your total TB-275 tokens represents the entirety of your share of the collateral. Spending all your TB-275 will release your entire share of the collateral (minus the market value of the debt to be repaid). + +Liquity: https://docs.liquity.org/ + +1. Navigate to your zk.money homepage and click “Wallet”. +2. Scroll down to “Tokens” and “Earn Positions”. +3. Click “Earn Positions”. +4. On your Liquity Trove position, click “Repay & Exit”. +5. Click “Max” to exit the full amount, then select a speed for your transaction. +6. Once you have done so, click “Next”. +7. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”. +8. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask). +9. Wait until your transaction is confirmed. +10. Navigate to your zk.money wallet homepage and click “Earn Positions”. +11. The status of your exit will be displayed here, as shown by “Exiting” (1 tick). +12. Click the transaction hash icon to be taken to the block explorer page to see the transaction status. +13. Your funds will appear in your dashboard once the transaction has settled. + +### Withdrawing Assets + +How to withdraw ETH, DAI and LUSD. + +1. Navigate to your zk.money homepage and click “Wallet”. +2. Scroll down to “Tokens” and “Earn Positions”. +3. Click “Tokens”. +4. Click “Exit” on the desired token you would like to withdraw. +5. Click “Withdraw to L1”. +6. Enter your recipient address. +7. Click “Max” to withdraw the full amount. +8. Select a speed for your transaction (transactions are free in “Batched Mode”). +9. Click “Next”. +10. Review the amount you are withdrawing is correct, tick the disclaimer, and click “Confirm Transaction”. +11. Sign the signature request using your connected wallet (e.g. Metamask). +12. Wait until your transaction is confirmed. +13. Navigate back to your wallet homepage, under Transaction History. Click the transaction hash to check the status of your transaction on the block explorer. +14. Your funds will appear in your recipient wallet once the transaction has settled. diff --git a/docs/docs/aztec3.mdx b/docs/docs/aztec3.mdx new file mode 100644 index 000000000000..b0e2c08bc499 --- /dev/null +++ b/docs/docs/aztec3.mdx @@ -0,0 +1,88 @@ +--- +title: Aztec 3 +--- + +import ReactPlayer from "react-player/youtube"; + +:::note + +These docs are a work in progress and will be updated as we release software around the new protocol. + +::: + +Aztec 3 is the next and final network on Aztec's journey to building a privacy-preserving, programmable extension to Ethereum. + +Aztec 3 is being built and launched as a credibly neutral, decentralized protocol. The protocol is being developed as open source software and will be run by a community of infrastructure providers and stakeholders. + +Aztec (the company) is doing much of the cryptography and engineering research and coordination to make the protocol possible. We are designing, building and auditing much of the software that others will run to create the Aztec network. + +The Aztec community upholds many of the values of the Ethereum community by also building permissionlessness, decentralization and censorship resistance into the system. + +## Privacy in Aztec 3 + +Aztec 3 has three distinct domains of privacy--user privacy, data privacy and code privacy. + +User privacy refers to the fact that transactions on the Aztec network can be completely confidential. Transactions may not include information about the sender, the recipient, the transaction amount or asset type. This is a significant deviation from most blockchains where all transaction data is transparent. + +Data privacy refers to data stored in program's state. Like other blockchains, programs that run on Aztec 3 are called [smart contracts](./glossary#smart-contract). Smart contracts on Aztec differ from smart contracts in many other programming contexts in that they can optionally have private state as well as private functions. + +Code privacy refers to program logic in smart contracts. Developers can specify `private` functions in their smart contracts that allow users to privately interact with contracts. + +### Private-public Composability + +You can watch Mike, one of our engineering team leads, talk about public-private composablity in Aztec 3 at Devcon here. + + + +## Cryptography + +Our cryptography team is building [Honk](https://github.com/AztecProtocol/barretenberg/tree/master/cpp/src/barretenberg/honk), a cutting edge proving system that makes Aztec 3 possible, under the Apache 2.0 License. + +## Noir + +Noir is a domain specific programming language for writing zero knowledge circuits and developers will write smart contracts for Aztec 3 using Noir. + +You can find more information and resources for learning about Noir on [this page](./noir). + +## Decentralization + +There are a number of components that we are working on to make the Aztec network robust and decentralized. + +The Aztec network will need a peer-to-peer transaction pool for [sequencers](./glossary#sequencer) to discover transactions. + +The network will need sequencer that works in a decentralized context, that follows a sequencer selection protocol and incentivizes liveness, minimizes redundant work and avoids race conditions. + +There will be a prover network that will generate the required proofs to publish a rollup. Sequencers will rely on the prover network to generate proofs for rollup blocks. The prover network should allow people to create proofs on commodity hardware to avoid centralization of proof construction. + +The sequence and prover networks must avoid "winner take all" and "fastest hardware wins" dynamics and will penalize censorship and missed blocks. + +The network will need to define upgrade mechanics, so it can be updated over time as new technology and designs are developed. + +There will need to be an incentive mechanism baked into the protocol that allows the various required parties to coordinate effectively and reliably. + +## Roadmap + +### Local Developer Testnet + +First on our roadmap is to release a local developer testnet. This network will run on a single development machine and will allow developers to write, test and deploy Aztec 3 smart contracts. + +Developers will be able to: + +- deploy contracts with public and private functions +- deploy contracts with Aztec 3 <--> Ethereum contract calls +- call other Aztec 3 contract private and public functions +- read / write to private state +- read / write to public state + +### Beyond + +In parallel to building the local developer testnet we are working on the networking stack for the network. As mentioned above, this requires several components (including the transaction pool, the sequencer and prover networks and data retrieval). + +After the launch of the local developer testnet we will be testing these networks on the Ethereum public testnets. These docs will be updated as we progress through the development process. + +In the meantime, feel free to engage with us via the **Community** links in the footer. diff --git a/docs/docs/compliance.md b/docs/docs/compliance.md deleted file mode 100644 index cf6d4d0c0e58..000000000000 --- a/docs/docs/compliance.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Compliance ---- - -# Compliance - -In contrast to common misconceptions, privacy does not equate non-compliance. Ultimately, we believe in a future where users can easily generate zero-knowledge proofs to demonstrate compliance **without exposing any personal information** throughout the process. In that future, users have full agency over the intermediaries they choose to interact with, while centralized institutions (e.g. CEXs, tax authorities) can still maintain compliance with local legislations without accessing sensitive user information. - -As we work towards that future, the measures below serve to limit the introduction of illicit funds into the Aztec Network and provide users with means to demonstrate compliance of their individual accounts, while preserving the ability of users to interact with Ethereum services using the Aztec Network. - -## Network Compliance - -The aim of network compliance measures is to limit the introduction of illicit funds (e.g. exploited funds from hacks) into the Aztec Network. They are designed around commonly seen illicit asset transfer patterns (e.g. large sums, time-sensitive). - -### Block Deposit Cap - -#### Address-specific Cap - -A deposit amount cap is enforced on a per address, per asset, per rollup block basis at the smart contract level and on the [zk.money](https://zk.money/) frontend. It serves as: - -- The first line of defense that hinders illicit deposits, and -- A measure to reduce users' exposed risks while Aztec is still experimental software - -The cap limits the maximum amount of pending deposits that an Ethereum address can make at any instance. It is initially enforced at 5 ETH / 10,000 DAI and is adjustable depending on needs. - -### Daily Deposit Cap - -#### IP-specific Cap - -A deposit rate cap is enforced on a per IP address, daily basis at the sequencer level. It serves as the second line of defense against illicit deposits that might attempt to circumvent the block deposit cap by making successive deposits. - -The cap limits the maximum number of deposits from an IP address on each day and is reset at UTC midnight. The IP addresses stored for this purpose are deleted upon reset. - -#### Network-wide Cap - -A deposit amount cap is enforced on a network-wide, per asset, rolling daily basis at the smart contract level. It serves as the third line of defense against illicit deposits that might attempt to circumvent the above caps by splitting deposits across accounts. - -The cap limits the maximum amount of pending deposits that can be made to the Aztec Network as a whole across 24-hour periods. Every pending deposit would consume a portion of the network-wide deposit quota that linearly refills at a rate of `network cap / 24 hours`. It is initially enforced at 1,000 ETH / 1,000,000 DAI and is adjustable depending on needs. - -## User Compliance - -The aim of user compliance measures is to provide users with means to demonstrate compliance of their individual accounts to e.g. auditors, government authorities and courts. - -### Viewing Key Sharing - -All Aztec accounts are created with [viewing keys](glossary.md#viewing-key) that guard viewing access to details of all transactions received and sent with the accounts (e.g. sender, receiver, asset type, amounts). In order to demonstrate compliance, users can share their viewing keys with whomever requesting viewing access to their Aztec transactions. - -Users can currently retrieve their viewing keys using one of the following tools: - -- [Hosted Frontend Boilerplate](https://aztec-frontend-boilerplate.netlify.app/) -- [Aztec CLI](https://github.com/critesjosh/azteccli) -- [Aztec SDK](sdk/usage/add-account.md#account-keys) - -Research and development of better compliance demonstration tooling is in progress. diff --git a/docs/docs/developers/bridges/bridges.md b/docs/docs/developers/bridges/bridges.md deleted file mode 100644 index 0c21ac0e3129..000000000000 --- a/docs/docs/developers/bridges/bridges.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -title: Aztec Connect Bridges ---- - -This guide is intended for readers interested in developing Aztec Connect Bridges or learning about them technically, instead of using them. - -## What is Aztec Connect - -Aztec Connect is a framework that enables users to access protocols on Ethereum Layer 1 (L1) privately, securely and inexpensively. It consists of three main components: - -**L1 Protocols** -Your favorite protocols already deployed and running on L1, e.g. Lido, Element, Yearn, Uniswap and more. - -**Aztec Connect Bridges** -Smart contracts on L1 that facilitate the Aztec rollup contract to interact with other L1 Protocols on behalf of L2 Aztec Network users. - -**Aztec SDK** -A tool set for developing user-facing applications to interact with the Aztec Network, including APIs for interacting with L1 Protocols using Aztec Connect Bridges. - -A typical flow of action starts from a user initiating an interaction request through a frontend powered by the Aztec SDK. The request is then passed to the Aztec backend and the corresponding Aztec Connect Bridge, which interacts with the specific L1 Protocol on behalf of the user. - -## What are Aztec Connect Bridges - -Aztec Connect Bridges are L1 smart contracts that conform L1 Protocols to the interface of the L1 Aztec rollup contract. They enable L2 Aztec users to interact with L1 Protocols cheaply and privately. - -A bridge contract models any L1 Protocol as an asset swap. Up to two input assets and two output assets can be specified for each bridge: - -![](https://i.imgur.com/2N4Noha.jpg) - -> **Note:** Assets A and B shall be of identical amounts (but not necessarily of identical types) in the current design to avoid free-riders. Further research to lift the limitation is underway. - -The asset swap delay depends on whether the bridge is designed to be synchronous or asynchronous. For more information on synchronicity, check the [Sync vs Async](#Sync-vs-Async) section. - -A high-level look of the Lido-Curve bridge that swaps users' ETH into wstETH: - -![](https://i.imgur.com/0wtoDKk.jpg) - -For more information on how Aztec Connect Bridges work, check the workshop video linked at the beginning of this guide and the [Aztec Connect](../how-aztec-works/aztec-connect) section of the Aztec Docs. - -## Workshop Video - -Certain content of this guide is also covered in this workshop video: - -[![](https://i.imgur.com/fA8f1Du.jpg)](https://www.youtube.com/watch?v=029Vm6PAnrM&t=1822s) - -## Writing a Bridge - -### Solidity Dev Env - -An Aztec Connect Bridge is developed entirely in Solidity. You are therefore welcome to choose your preferred Solidity development environment. - -We recommend [Foundry](https://book.getfoundry.sh/) given the interconnected nature of Aztec Connect Bridges with existing Mainnet protocols. - -### Boilerplates - -To get started with an example setup, follow the steps below: - -1. Fork the [Aztec Connect Bridges repository](https://github.com/AztecProtocol/aztec-connect-bridges). - -2. Clone your fork: - -```shell -git clone https://github.com/{YOUR_GITHUB_USERNAME}/aztec-connect-bridges.git -``` - -3. Change directory into `aztec-connect-bridges`: - -```shell -cd aztec-connect-bridges -``` - -4. Create a new branch with your preferred bridge name: - -```shell -git checkout -b {YOUR_GITHUB_USERNAME}/{BRIDGE_NAME} -``` - -5. Install dependencies and build the repository: - -```shell -yarn setup -``` - -6. Copy and rename the example folders as your boilerplates to work on: - -``` -src/bridges/example -src/test/bridges/example -src/deployment/example -specs/bridges/TEMPLATE.md -``` - -You are now equipped to write your first Aztec Connect Bridge! Simply start by reading and implementing your bridge over the boilerplate files. - -For more information on how the Aztec rollup contract would call your bridge, check [IDeFiBridge.sol](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/aztec/interfaces/IDefiBridge.sol). - -### BridgeCallData - -In production, a bridge is called by a user creating a client-side proof via the Aztec SDK. These transaction proofs are sent to the sequencer for aggregation. The sequencer then sends the aggregate rollup proof with the sum of all users' proofs with identical `BridgeCallData` ([class definition](../sdk/types/bridge-clients/BridgeData)) to your bridge contract in one go for gas savings and improved privacy. - -A `BridgeCallData` uniquely defines the expected inputs/outputs of an L1 interaction. It is a `uint256` that represents a bit-string containing multiple fields. When unpacked its data is used to create a `BridgeData` struct in the rollup contract. - -The structure of the bit-string is as follows (starting at the least significant bit): - -| bit position | bit length | definition | description | -| - | - | - | - | -| 0 | 32 | `bridgeAddressId` | id of bridge smart contract address | -| 32 | 30 | `inputAssetA` | asset id of 1st input asset | -| 62 | 30 | `inputAssetB` | asset id of 1st input asset | -| 92 | 30 | `outputAssetA` | asset id of 1st output asset | -| 122 | 30 | `outputAssetB` | asset id of 2nd output asset | -| 184 | 64 | `auxData` | custom auxiliary data for bridge-specific logic | - -> **Note:** The last 8 bits of the `BridgeCallData` bit-string are wasted as the rollup proving circuits cannot support values of full 256 bits (248 is the largest multiple of 8 that we can use). - -`bitConfig` definition: - -| bit | meaning | -| - | - | -| 0 | secondInputInUse | -| 1 | secondOutputInUse | - -> **Note:** Despite using only 2 bits in the current design, `bitConfig` is 32 bits large for future-proofing (new bit flags would be needed to add e.g. NFT support). - -For more information on bridge call data, check the [Aztec Connect Bridges repository](https://github.com/AztecProtocol/aztec-connect-bridges) README. - -### Tests - -Testing is critical to ensure your bridge is working as intended. Refer to example tests under [`src/test/bridges/example/`](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master/src/test/bridges/example) and other tests under [`src/test/bridges/`](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master/src/test/bridges) for inspirations. - -The main objective of unit tests is to demonstrate the bridge works by itself. The testing focus is recommended to be on edge cases, reverts, output value assertions and fuzzy tests. - -The main objective of end-to-end (E2E) tests, meanwhile, is to demonstrate the bridge works in a production-like environment. The testing setup should involve mocking the rollup with [`BridgeTestBase.sol`](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/test/aztec/base/BridgeTestBase.sol) and the focus is recommended to be on event emissions and token transfers. - -For example, for Foundry users to test the ExampleUnitTest contract: - -```shell -forge test --match-contract ExampleUnitTest -vvv -``` - -### Deployment - -The best way to deploy and test your bridge is on a local development Aztec network, through deployments script with Foundry. You can find more info about starting the local development network and deployment info [here](../local-devnet.md). - -Refer to [`ExampleDeployment.s.sol`](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master/src/deployment/example) and other scripts under [`src/deployment`](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master/src/deployment) for inspirations. - -You can use the same deployment process described in the local development network page linked above to get bridge contracts deployed and listed to the private testnet rollup contract. If you are deploying to testnet, reach out via [email](mailto:devrel@aztecprotocol.com) to get the Aztec testnet sequencer config updated so that the sequencer can handle transactions to the new bridge contract. - -Refer to [this section](https://github.com/AztecProtocol/aztec-connect-bridges#writing-a-bridge) of the bridges repo README for more detail. - -:::info -Read more about Solidity scripting with foundry [here](https://book.getfoundry.sh/tutorials/solidity-scripting). -::: - -### Aux Data - -The `auxData` field in the bridge call data is custom auxiliary data supporting bridge-specific logic. - -To benefit from the gas savings and improved privacy of aggregated proofs with identical `bridgeCallData`, the definition of `auxData` of a bridge could be an important consideration during its design process. - -### Rebasing Token - -Tokens bridged onto the Aztec Network are represented as Aztec notes of fixed values. Bridging rebasing tokens like Lido stETH and Ampleforth naively without wrappers would result in users losing out on entitled rewards and suffering from insolvent withdrawals. - -The use of a canonical wrapper like Lido wstETH / a self-built wrapper to anchor the amounts of bridged assets is therefore highly recommended. - -### Sync vs Async - -Depending on the application, Aztec Connect interactions that require 2-step processes can utilize the asynchronous option by flipping the `isAsync` flag during bridge design. - -An example of an asynchronous bridge would be [Element's](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/bridges/element/ElementBridge.sol), where redemptions are activated no earlier than the maturity of deposits. - -### Stateful vs Stateless - -Another consideration when designing an Aztec Connect Bridge is to decide if it should hold state within the contract. - -For interactions involving fungible positions (e.g. token swaps), a stateless bridge that does not hold funds outside calls is likely preferred for the generally smaller code base. - -For interactions involving long-standing non-fungible positions (e.g. borrowing, DCA, limit orders), a stateful bridge that handles accounting internally and holds funds between calls is likely required. - -### Gas Limit - -As a measure to avoid the entire Aztec rollup failing from out-of-gas issues, bridges are required to specify their upper gas usage limit when registering on the Aztec rollup. - -Bridge designers should take variations in gas usage that depend on alterable L1 state into account when deciding their gas limits. - -### Bridge Reverts - -When a bridge reverts, the Aztec rollup will emit an event indicating that the bridge has reverted, and then continue with Aztec Connect interactions of other remaining bridges. - -This could lead to tricky debugging if E2E tests are carried out as the first tests post-design, as revert messages are only discoverable in emitted events. - -### ERC-4626 - -An [ERC-4626 Aztec Connect Bridge](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/bridges/erc4626/ERC4626Bridge.sol) that supports tokenized vaults complying with the [EIP-4626 standard](https://eips.ethereum.org/EIPS/eip-4626) is available. If an Aztec Connect interaction can conform to an ERC-4626 position, it may be desirable to utilize the existing bridge instead of building a new one. - -## Resources - -### [📝 Aztec Connect Bridges Repo](https://github.com/AztecProtocol/aztec-connect-bridges/) - -The repository containing code of Aztec Connect Bridges deployed and in development, as well as boilerplates and information for writing a new bridge. - -### [👾 Discord](https://discord.gg/aztec) - -Join the channels: - -- [`#💻│aztec-connect`](https://discord.com/channels/563037431604183070/563038059826774017) to discuss Aztec Connect diff --git a/docs/docs/developers/bridges/dataprovider.md b/docs/docs/developers/bridges/dataprovider.md deleted file mode 100644 index 9bd3accc4305..000000000000 --- a/docs/docs/developers/bridges/dataprovider.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: DataProvider ---- - -## What does it do? - -It is a contract we use as a source of truth when it comes to configuration of bridges and assets. - -It is mainly used by a frontend to get a bridge or asset information by a tag, but the information can be used by anyone. - -You can also get deployed bridge information from the Aztec sequencer (falafel) endpoint: [https://api.aztec.network/aztec-connect-prod/falafel/status](https://api.aztec.network/aztec-connect-prod/falafel/status). - -## Usage - -The contract is deployed [here](https://etherscan.io/address/0xB4319947947781FFe91dDf96A32aF2D4693FEf64) and these are the 4 relevant functions: - -```js -function getAsset(uint256 _assetId) public view returns (AssetData memory); - -function getAsset(string memory _tag) public view returns (AssetData memory); - -function getAssets() public view returns (AssetData[] memory); - -function getBridges() public view returns (BridgeData[] memory); -``` - -The easiest way to access it, if already using [the Aztec Connect Bridges repository](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master) is to execute the `readProvider(address)` script in the DataProviderDeployment solidity file. You will need to specify the DataProvider address for the network you want to read. - -For example - -```bash -export NETWORK=MAINNET -export ETH_RPC_URL= -``` - -```bash -forge script DataProviderDeployment --rpc-url $ETH_RPC_URL --sig "readProvider(address)" 0x8B2E54fa4398C8f7502f30aC94Cb1f354390c8ab -``` - -## Usage by owner - -Updating values stored in the data provider is only possible by the owner of the contract. This is a restricted function on mainnet, but you can update your [local development environment](../local-devnet). - -Before running the commands below export relevant environment variables: - -```bash -export RPC="http://localhost:8545" && PRIV_KEY="PROVIDER_OWNER_PRIVATE_KEY" -``` - -### Adding a bridge - -```bash -cast send 0xB4319947947781FFe91dDf96A32aF2D4693FEf64 "addBridge(uint256,string)" "2" "ExampleBridge" --rpc-url $RPC --private-key $PRIV_KEY -``` - -### Adding an asset - -```bash -cast send 0xB4319947947781FFe91dDf96A32aF2D4693FEf64 "addAsset(uint256,string)" "2" "wsteth" --rpc-url $RPC --private-key $PRIV_KEY -``` - -### Adding multiple assets and bridges - -```bash -cast send 0xB4319947947781FFe91dDf96A32aF2D4693FEf64 "addAssetsAndBridges(uint256[],string[],uint256[],string[])" '[2,1]' '["wsteth","dai"]' '[5,8]' '["ExampleBridge_deposit","ExampleBridge_withdraw"]' --rpc-url $RPC --private-key $PRIV_KEY -``` diff --git a/docs/docs/developers/bridges/subsidy.md b/docs/docs/developers/bridges/subsidy.md deleted file mode 100644 index 04c52be6ec0c..000000000000 --- a/docs/docs/developers/bridges/subsidy.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Subsidy Module ---- - -Aztec Connect has a [subsidy module](https://etherscan.io/address/0xABc30E831B5Cc173A9Ed5941714A7845c909e7fA) that strives to improve consistency of bridge executions, e.g., how often they are executed. This is done by allowing anyone to setup a subsidy which is paying some amount to the sequencer when executing the bridge. It is essentially a way to make it profitable for the sequencer to include the bridge, even if the users that are queued don't cover the gas entirely themselves. - -The module is primary expected to be used by projects/teams that are added to Aztec who want to give their users a more consistent experience. To give you an example, Yearn subsidises deposits into the Eth and Dai bridges, reducing the time users have to wait until they have their yvEth and yvDai. - -The module itself is an immutable contract that have no admin keys, allowing anyone to subsidise the bridges. Prior to the module, teams wanting to subsidise bridges would have to send some Eth to the Aztec team and we would manually setup the subsidy within our sequencer software. This was impractical since it required our cooperation. - -The idea is relatively simple, the bridge has an upper bound on the gas it consumes. You never want to subsidise more than this amount per "run", as you are then wasting funds, e.g., upper bound of subsidy = upper bound of gas consumed by the bridge. At the same time, you have an idea about how often the bridge should be executed at a minimum, so you let the subsidy grow over this time period. Written as a formula `bridge_gas_cost / time_between_executions = gas_per_time_unit`. In the case of Yearn, they wanted daily execution, so they needed to cover `200K / 24 hours = 140 gas per minute` (200k gas is how much the Yearn bridge call costs - this value is bridge specific). After 24 hours, the subsidy reaches its maximum amount. In such a scenario even one user fee would be enough to make it profitable for the sequencer to include the bridge call in a rollup block. This is because the fee paid by user + the subsidy is bigger than the actual gas cost of the bridge call. When the subsidy is claimed, the amount goes back to 0, and the cycle repeats. - -On the module, the subsidy is accruing to a specific `bridge` and `criteria`. Criteria is an integer which can be used by the bridge to differentiate between different flows. This valuable because different execution flow might have a different gas cost and because it's common that people want to subsidize only a specific flow (for example Yearn wanted to subsidize only deposits to their vaults and not exits). The `criteria` value is being computed by the bridge itself and it is registered by the bridge in the Subsidy contract. This is usually done in the bridge's constructor. Because the subsidy is accruing to a criteria, multiple flows that all have the same criteria will be "fighting" over it. Something you need to consider when building the bridge. - - ---- -# What to keep in mind while building -When building a bridge, the bridge needs to have a way of calling the `setGasUsageAndMinGasPerMinute()` function of the subsidy module. This function is used to specify the bounds and criteria that should be able to receive a subsidy from the module. We are performing this "registration" from the bridge itself as it is a way of getting rid of any trusted party, no admin keys. The `_minGasPerMinute` that is passed is primarily used to ensure that someone cannot just come in to subsidise a tiny tiny amount over time, effectively giving no subsidy. - -Thereafter, you need to decide how your bridge is to compute the criteria values. If your bridge is limited in the actions it can take, e.g., the Yearn bridge only deposits/withdraws into/from yearn, it might be useful to have simple criteria that are shared between different flows, as it is then straightforward to subsidise multiple of them at once (in this case Yearn subsidised all the deposits, regardless of asset). If the bridge is more general purpose (such as ERC4626) it is beneficial to allow subsidising based on the combination of input and output assets. This can be done by computing a hash of input/output token addresses and converting that value to `uint256` and should be implemented in the `computeCriteria()` function. - -With setup and criteria managed, you just need to make sure that the `convert()` function claims the subsidy through the `claimSubsidy()` function, which takes the criteria and the rollup beneficiary (address passed by sequencer). Without this function, no subsidy is given. - -# How do I subsidise? -When you have found a bridge to subsidise, you need to figure out what flows you want to subsidise (the criteria). This criteria will depend on the bridge and the best way to figure out the meaning of different criteria is to simply check the bridge's code. -For bridges that follow the base implementation, there will be a `computeCriteria()` function taking assets and auxdata as input that should compute the criteria for a given interaction. *Note*: multiple flows can have the same criteria. - - -To give you an example our [Yearn bridge](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/bridges/yearn/YearnBridge.sol) uses criteria to distinguish between deposit and withdrawal flows while our [Uniswap bridge](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/bridges/uniswap/UniswapBridge.sol) a specific combination of input/output assets. - -To fund the subsidy using etherscan as an interface do the following: - -1. Go to the contract's `subsidize(...)` function on [Etherscan](https://etherscan.io/address/0xabc30e831b5cc173a9ed5941714a7845c909e7fa#writeContract#F5) -2. Connect your wallet. -3. Fill in the following details: - - - **payableAmount** – This is the amount of ETH you want to commit to the subsidy (in Wei). We recommend initially setting this value relatively low (somewhere between 20-40% of the total grant size) because it’s possible you would want to change the Subsidy parameters below, and it is not possible to do that before current subsidy runs out. The minimum acceptable value is set to 0.1 ETH. - - **\_bridge** – This is the address of the bridge you are subsidizing. - - **\_criteria** – This is the parameter specifying which flow you want to subsidize. - - **\_gasPerMinute** – This is the parameter for declaring how much gas per minute you are willing to subsidize. This value defines the rate at which the subsidy is released. The minimum acceptable value is bridge specific. We usually set **\_gasPerMinute** value such that a call is fully subsidized once per day. Fully subsidized would mean that the user’s base fee would get covered in full, and users would only have to pay priority fee tips - -4. Send the transaction by clicking “Write”. - -> Note: This is a standard contract interaction so feel free to fund the subsidy any other way. -> If you are using a multi-sig, you can instead propose this transaction in the UI of the multi-sig wallet, with the same parameters. \ No newline at end of file diff --git a/docs/docs/developers/cli.md b/docs/docs/developers/cli.md deleted file mode 100644 index 5766061cf22b..000000000000 --- a/docs/docs/developers/cli.md +++ /dev/null @@ -1,231 +0,0 @@ ---- -title: Command Line Interface (CLI) ---- - -This guide is intended to introduce the Aztec SDK through the lens of Aztec CLI. - -## What is Aztec CLI - -Aztec CLI is a command line application for interacting with the Aztec Network, powered by the Aztec SDK. It is useful for both accessing the Aztec Network, as well as experimenting with the Aztec SDK. - -## What is Aztec SDK - -Aztec SDK is a set of tools for developing user-facing means to interact with the Aztec Network. - -It is designed to abstract away the complexities of zero-knowledge proofs from developers, providing them with simple APIs to develop applications that enjoy the privacy and scaling benefits the Aztec Network offers. - -## Workshop Video - -A video demo of the Aztec CLI is available at: - -[![](https://github.com/critesjosh/azteccli/raw/main/img/preview.png)](https://www.youtube.com/watch?v=Og04qRak-SM) - -Certain content of this guide is also covered in this workshop video: - -[![](https://i.imgur.com/WZbVHWC.jpg)](https://www.youtube.com/watch?v=I5M8LhOECpM&t=744s) - -## Install - -### Prerequisites - -- Install [Node.js](https://nodejs.org/en/download/) -- Install [Yarn](https://classic.yarnpkg.com/lang/en/docs/install/) -- Install [Truffle](https://trufflesuite.com/docs/truffle/getting-started/installation/) - -### Install Aztec CLI - -#### Using Yarn - -1. Install Aztec CLI using Yarn: - -```shell -yarn global add azteccli -``` - -1.1 If you are prompted to select an `@aztec/bridge-clients` version, select the latest one. - -2. Check the path where yarn binaries are installed: - -```shell -yarn global bin -``` - -You should see something like: - -```shell -$ yarn global bin -/{HOME_DIRECTORY}/.yarn/bin -``` - -3. If not already, add the path to the `PATH` environmental variable to enable access to the yarn binaries (including azteccli) by your terminal. - -You can do this by adding: - -``` -export PATH="/{HOME_DIRECTORY}/.yarn/bin:$PATH" -``` - -to your `.profile` / `.bashrc` file in your home directory. - -> **Note:** Changes on the profile file are not applied until the system restarts. To apply the changes immediately, run: - -```shell -source $HOME/.profile -``` - -4. Check if azteccli is successfully installed: - -```shell -azteccli help -``` - -5. Set Metamask as the wallet to be used by azteccli: - -```shell -azteccli conf wallet metamask -``` - -6. Start the Truffle Dashboard: - -```shell -truffle dashboard -``` - -7. You may now connect your Metamask wallet through the dashboard and start using azteccli by running e.g. `azteccli history`. - -For more details on available commands, you can: - -- Run `azteccli help` -- Check the [`commands`](https://github.com/critesjosh/azteccli/tree/main/src/commands) directory -- Check the [Aztec CLI repository](https://github.com/critesjosh/azteccli) README - -#### Compile from Source - -Alternatively, you can also run the CLI with the latest updates directly from the Github repo. - -1. Clone the [repo](https://github.com/critesjosh/azteccli). -2. Install dependencies. `$ yarn` -3. Edit/add new commands in `./src/`. -4. Test your edits by running `./bin/dev [command] [args] [flags]`. (ie `$ ./bin/dev deposit .01`) - -## Code Highlights - -The workshop video linked at the beginning of this guide is a great walkthrough of the content in this section. - -## SDK Version - -The version of SDK used in Aztec CLI is specified in its [`package.json`](https://github.com/critesjosh/azteccli/blob/main/package.json#L11): - -```json -"dependencies": { - "@aztec/sdk": "2.1.0-testnet.108", // check for a newer version - ... - }, -``` - -The SDK is rapidly developed upon. The list of version numbers can be found in the Versions tab of [@aztec/sdk](https://www.npmjs.com/package/@aztec/sdk) on the npm registry. - -## Network Configuration - -The networks the Aztec CLI is configured to support are specified in [`network_config.ts`](https://github.com/critesjosh/azteccli/blob/main/src/network_config.ts): - -```javascript -let networkConfig: Config = { - 1: { - rollupProvider: "https://api.aztec.network/aztec-connect-prod/falafel", - explorerUrl: "https://aztec-connect-prod-explorer.aztec.network/", - }, - 1337: { // local devnet - rollupProvider: "http://localhost:8081", - explorerUrl: "", - }, -}; -``` - -The network of Chain ID `1337` is the Aztec mainnet fork [local developer network](./local-devnet). It is a local network that is forked from and mimics the Ethereum Mainnet. - -## Account Alias - -Account registering on the Aztec Network comes with an option to specify a preferred account alias. An example of utilizing so through the Aztec SDK can be seen in Aztec CLI's [`register.ts`](https://github.com/critesjosh/azteccli/blob/main/src/commands/register.ts): - -```javascript -public async run(): Promise { - const { alias, ttpPubKey, time, asset } = this.flags; - ... - const controller = await this.sdk.createRegisterController( - accountKeys.publicKey, - alias, - accountKeys.privateKey, - ... - ); -``` - -An account alias is an arbitrary string that users could "name" their accounts with. Users transferring assets on the Aztec Network can then specify aliases instead of long public keys as their recipients, simplifying the UX. - -## Controllers - -The Aztec SDK abstracts away the backend complexities by exposing interactions with the Aztec Network through controllers. - -An example of utilizing so can be seen in Aztec CLI's [`register.ts`](https://github.com/critesjosh/azteccli/blob/main/src/commands/register.ts), where a `RegisterController` is first initiated with the arguments gathered: - -```javascript -const controller = await this.sdk.createRegisterController( - accountKeys.publicKey, - alias, - accountKeys.privateKey, - signer.getPublicKey(), - recoveryPublicKey, // defaults to nothing - depositValue, - txFee, - depositor // defaults to the logged in Ethereum accounts - // optional feePayer requires an Aztec Signer to pay the fee -); -``` - -Functions of the controller are then called to perform a deposit, generate a client-side proof, sign it and send it to the Aztec backend: - -```javascript -if ((await controller.getPendingFunds()) < tokenQuantity) { - await controller.depositFundsToContract(); - await controller.awaitDepositFundsToContract(); -} - -await controller.createProof(); -await controller.sign(); -let txId = await controller.send(); -``` - -Different controllers for different actions are available in the Aztec SDK. For example, `DepositController` is used for depositing assets from Ethereum and `TransferController` is used for asset transfers on the Aztec Network. - -For more information on available controllers, check the [SDK](../sdk/overview.md) section of the Aztec Docs and the [`controllers`](https://github.com/AztecProtocol/aztec-connect/tree/master/sdk/src/controllers) directory of the SDK repository. - -## Aztec Connect - -One of the most interesting use cases of the Aztec SDK is to enable users on the Aztec Network to interact with protocols on Ethereum Layer 1 privately and inexpensively through Aztec Connect Bridges with the [`DefiController`](https://github.com/AztecProtocol/aztec-connect/blob/master/sdk/src/controllers/defi_controller.ts). - -For more information, check the [Ethereum Interaction page](../sdk/usage/ethereum-interaction.md) and the separate guide on [_Getting Started with Aztec Connect Bridges_](./bridges/bridges.md). - -## Resources - -### [🧑‍💻 Aztec SDK npm](https://www.npmjs.com/package/@aztec/sdk) - -The Aztec SDK npm package on the npm registry. - -### [🧑‍💻 Aztec SDK GitHub Repo](https://github.com/AztecProtocol/aztec-connect/tree/master/sdk) - -The repository of the Aztec SDK in production. - -### [📝 Aztec CLI](https://github.com/critesjosh/azteccli) - -A CLI tool for interacting with the Aztec Network. Powered by Aztec SDK. - -### [📝 Aztec Frontend Boilerplate](https://github.com/AztecProtocol/aztec-frontend-boilerplate) - -A sample Web App powered by the Aztec SDK. - -### [👾 Discord](https://discord.gg/aztec) - -Join the channels: - -- [`#💻│aztec-connect`](https://discord.com/channels/563037431604183070/563038059826774017) to discuss the Aztec SDK -- [`#🇨🇴│ethbogota`](https://discord.com/channels/563037431604183070/1021410163221086268) to discuss the ETHBogota Hackathon diff --git a/docs/docs/developers/deposit.md b/docs/docs/developers/deposit.md deleted file mode 100644 index e44dad87e6be..000000000000 --- a/docs/docs/developers/deposit.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Depositing Assets ---- - -Deposit assets from Ethereum to Aztec. - -Deposits on Aztec have 2 steps: - -1. The user sends a transaction specifying an amount of ETH or DAI to deposit to the Aztec rollup contract by calling `depositPendingFunds`. When deposit DAI with this function, the rollup processor must be approved to spend the user's DAI. Or a user sends a transaction with DAI to the rollup contract by calling `depositPendingFundsPermitNonStandard`. Read more about using the [DAI permit flow here](https://github.com/makerdao/developerguides/blob/master/dai/how-to-use-permit-function/how-to-use-permit-function.md). -2. The user creates a proof on Aztec to claim the pending deposit. The proof includes information about the Ethereum account that made the deposit, the amount of the deposit, the Aztec transaction fee and the recipient account on the Aztec network. - -When using an externally owned account on Ethereum, this flow is managed by the SDK. You can read more about using the SDK to deposit funds into Aztec on the [SDK deposit page](./../sdk/usage/deposit). - -If the depositing account is a smart contract (e.g. a smart contract wallet), a proof hash corresponding to the hash generated by the DepositController must be passed to `depositPendingFunds` (or similar). For more detail about how to execute deposits from a smart contract, refer to the [Advanced Usage section](./../sdk/usage/deposit#advanced-usage) of the SDK page on deposits. - -Here is the interface for `depositPendingFunds`. - -```js -function depositPendingFunds( - uint256 assetId, - uint256 amount, - address owner, - bytes32 proofHash - ) external payable; -``` - -| Input | Description | -|---|---| -| `assetId` | The [asset id](../glossary#asset-ids) of the asset being deposited. ETH is asset id 0, DAI is asset id 1. | -| `amount` | The amount of the asset being deposited. | -| `owner` | The Ethereum address that can spend the deposited funds. This is used in the proof generation in step 2 mentioned above. | -| `proofHash` | The 32 byte transaction id that can spend the deposited funds. This is intended to be used when the depositor is a smart contract (e.g. a multisig wallet) that cannot sign data. | - -`depositPendingFundsPermitNonStandard` works similarly to `depositPendingFunds` but with the permit flow instead of the approve flow. DAI requires a non-standard flow because their implementation of permit requires a nonce. diff --git a/docs/docs/developers/getting-started.md b/docs/docs/developers/getting-started.md deleted file mode 100644 index 639767d43ef6..000000000000 --- a/docs/docs/developers/getting-started.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Getting Started ---- - -## Building on Aztec - -There are two common ways that developers can start building on Aztec: - -1. Build a user-facing application that connects to the Aztec network via the TypeScript SDK. -2. Build an Aztec Connect bridge that connects the Aztec network to Ethereum smart contracts. - -We are also working on Noir, an independent domain specific language that can be used to develop ZK-provable programs. Refer to the [Noir page](./noir) for more details. - -:::tip -Running out of ideas to build? Check our [Grants](https://aztec.network/grants) for inspirations! -::: - -:::info -The Aztec core engineering team has a regular release cadence that will occasionally introduce breaking changes. Updates are typically applied to Testnet on Thursdays, which are tested and monitored over the weekend and would be pushed to Mainnet afterwards. - -We are working on making this process more transparent. Feel free to [get in touch](#get-in-touch) if you have any queries. -::: - -## Testnet Information - -You can run a local development environment by following the instructions on [this page](./local-devnet). - -We have a private testnet and access is reserved for people building products on Aztec. If you need access to the Aztec testing environment, please reach out via [email](mailto:devrel@aztecprotocol.com). - -## Building with the SDK - -### Setup - -To start using the SDK, install it in your project by running: - -```shell -yarn add @aztec/sdk -``` - -And import it into your project: - -```ts -import { createAztecSdk } from "@aztec/sdk"; -``` - -For a proper walkthrough of setting up the SDK, check the [SDK Setup page](../sdk/usage/setup.mdx). - -### Example Code - -To learn how the SDK works in action, the [CLI page](./cli) provides a detailed breakdown of the [Aztec CLI](https://github.com/critesjosh/azteccli) tool powered by the SDK. - -If you are building a web interface, you might also find the [Frontend Boilerplate](https://github.com/AztecProtocol/aztec-frontend-boilerplate) useful as a starting point. - -:::tip -By default, Aztec transactions could take up to a few hours to settle on the Testnet like on Mainnet. If you want transactions to settle quickly, be sure to set `TxSettlementTime` as `INSTANT`. - -`INSTANT` transactions pay higher fees in ETH in exchange for settlement within minutes rather than hours. -::: - -### Aztec SDK Resources - -- [🧑‍💻 Aztec SDK npm](https://www.npmjs.com/package/@aztec/sdk) -- [🧑‍💻 Aztec SDK GitHub Repo](https://github.com/AztecProtocol/aztec-connect/tree/master/sdk) -- [🎥 ETHBogota Workshop - Aztec CLI / SDK](https://www.youtube.com/watch?v=I5M8LhOECpM&t=744s) -- [✍️ Getting Started with Aztec CLI / SDK](./cli.md) -- [📝 Aztec CLI](https://github.com/critesjosh/azteccli) -- [📝 Aztec Frontend Boilerplate](https://github.com/AztecProtocol/aztec-frontend-boilerplate) - -## Building an Aztec Connect Bridge Contract - -The [Aztec Connect Bridges page](./bridges) covers how to develop an Aztec Connect Bridge in great detail. - -The [Aztec Connect Bridges repository](https://github.com/AztecProtocol/aztec-connect-bridges) has the most up to date information and materials for creating a bridge contract. - -### Bridges Resources - -- [🧑‍💻 Aztec Connect Bridges GitHub Repo](https://github.com/AztecProtocol/aztec-connect-bridges) -- [🎥 ETHBogota Workshop - Aztec Connect Bridges](https://www.youtube.com/watch?v=I5M8LhOECpM&t=1826s) -- [✍️ Getting Started with Aztec Connect Bridges](./bridges/bridges.md) -- [✍️ Element Bridge Explained](https://hackmd.io/@aztec-network/SJ7-6Rbfq) - -## Get in Touch - -### Discord - -Join [Aztec Discord](https://discord.gg/aztec) for discussions across channels: - -- [`#🚅│aztec-connect`](https://discord.com/channels/563037431604183070/1032885517525717022) for SDK & Bridges -- [`#🖤│noir`](https://discord.com/channels/563037431604183070/1032602753148661780) for Noir - -### Aztec Core Team Contacts - -All questions, comments, suggestions, ideas, etc. welcome. - -| Name | Role | Discord | Telegram | Twitter | Email | -| ----- | ---------------------------------- | ---------------- | ------------ | --------------------------------------------------- | ----------------------- | -| Josh | Developer Relations | joshc#6779 | @crites | [@critesjosh\_](https://twitter.com/critesjosh_) | josh@aztecprotocol.com | -| Savio | Developer Relations | Globallager#4834 | @Globallager | [@globallager](https://twitter.com/globallager) | savio@aztecprotocol.com | -| Lasse | Engineer - Bridge & Smart Contract | LHerskind#8376 | | [@HerskindLasse](https://twitter.com/herskindlasse) | lasse@aztecprotocol.com | -| Maxim | Engineer - Noir | vezzie#7609 | | [@maximvezenov](https://twitter.com/maximvezenov) | maxim@aztecprotocol.com | diff --git a/docs/docs/developers/local-devnet.md b/docs/docs/developers/local-devnet.md deleted file mode 100644 index 40a68db3e7b7..000000000000 --- a/docs/docs/developers/local-devnet.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: Local Devnet ---- - -# Setting up a local Aztec development network - -You can set up a local Aztec network for development purposes using docker compose scripts. - -## Steps - -### Install Docker - -From [here](https://docs.docker.com/get-docker/). - -### Start the network - -Run the relevant docker compose file for your needs. Make sure you have at least 8 GB of RAM allocated to Docker--the more you can allocate, the better. - -:::info -Mac M1s run this on an emulator so they will be slower. -::: - -#### Basic Network - -For a simple, fresh Ethereum network + Aztec sequencer without any bridge contracts, run - -```bash -curl -s https://raw.githubusercontent.com/AztecProtocol/dev-rel/main/docker-compose.dev.yml | docker compose -f - up --force-recreate --pull always -``` - -This will be useful for testing basic functionality of the Aztec network like deposits, withdrawals, account registrations, account migrations, account recovery and asset transfers. - -#### Mainnet fork with bridge contracts - -Or for a an Ethereum fork of mainnet along with all of the mainnet Aztec bridge contracts deployed + Aztec sequencer, run: - -You will need to add a `FORK_URL` with a valid API key. - -```bash -curl -s https://raw.githubusercontent.com/AztecProtocol/dev-rel/main/docker-compose.fork.yml | NETWORK=DONT_CARE CHAIN_ID=3567 FORK_URL=https://mainnet.infura.io/v3/{infura_api_key} docker compose -f - up --force-recreate --pull always -``` - -This network will be useful for testing functionality associated with bridge contracts and interacting with other contracts/protocols that are on Ethereum. - -Note the `CHAIN_ID=3567` and `FORK_URL=https://mainnet.infura.io/v3/{infura_api_key}` when running the mainnet fork. Specifying chain id 3567 will run the contract deployment script so that all of the bridge contracts that are on mainnet will be deployed to this dev network. - -:::note -This mainnet fork deployment takes considerably longer than the basic devnet. -::: - -These scripts will get the docker compose file from a github gist and run it. - -You can download the [docker-compose.dev.yml here](https://raw.githubusercontent.com/AztecProtocol/dev-rel/main/docker-compose.dev.yml) or [docker-compose.fork.yml here](https://raw.githubusercontent.com/AztecProtocol/dev-rel/main/docker-compose.fork.yml). - -### Check the sequencer - -Check that the aztec sequencer (falafel) is running by visiting this url in your browser at [http://localhost:8081/status](http://localhost:8081/status). - -Once it is up and running, you can use it to run testing scripts against or point your web application to it for testing. - -### Connect the SDK - -For a web application, point Metamask to the locally running Ethereum network (details below). - -Connect the Aztec SDK to `http://localhost:8081`. - -You can also interact with your local aztec network directly via the [CLI](https://github.com/critesjosh/azteccli#development) or the [frontend boilerplate](https://github.com/AztecProtocol/aztec-frontend-boilerplate). - -If you see this error - -```bash -Error: Version mismatch with rollup provider. Error: Rollup provider / SDK version mismatch. Hard refresh your browser or update SDK. -``` - -check that you are using the [latest SDK version](https://www.npmjs.com/package/@aztec/sdk?activeTab=versions) and Docker images. - -You should [pull](https://docs.docker.com/engine/reference/commandline/pull/) the latest `aztecprotocol` docker images to see if they have been updated. - - ```bash - docker pull aztecprotocol/falafel:latest - docker pull aztecprotocol/contracts:latest - ``` - -You can also get the exact backend release that matches the SDK [directly from Docker Hub](https://hub.docker.com/r/aztecprotocol/falafel/tags). - -### Deploy custom bridges - -You can deploy your own bridge contracts to the mainnet fork devnet. - -Here is an [example script](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/deployment/example/ExampleDeployment.s.sol) that shows how you would deploy the [ExampleBridge.sol](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/bridges/example/ExampleBridge.sol) contract in the [aztec-connect-bridges repo](https://github.com/AztecProtocol/aztec-connect-bridges). - -Set these local environment variables before running the deployment script. - -```bash -export NETWORK=None -export SIMULATE_ADMIN=false # to broadcast your deployment to the devnet -export LISTER_ADDRESS=0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 -``` - -Check the `rollupProcessorContract` address on your local Aztec sequencer at [http://localhost:8081/status](http://localhost:8081/status) and export it as an environment variable as well. - -For example: - -```bash -export ROLLUP_PROCESSOR_ADDRESS=0xDA437738D931677e83a480C9c397d2d0A473c209 -``` - -Then run the deployment script. - -```bash -forge script ExampleDeployment --sig "deployAndList()" --broadcast --fork-url http://localhost:8545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 -``` - -Run this from the aztec connect bridges repo containing the deployment script. The private key here is associated with the first [anvil](https://book.getfoundry.sh/anvil/) account. It has enough ETH and permission to deploy and list new bridges. - -Make sure you run `yarn setup` in the aztec-connect-bridges repo to set up forge for this repo. - -See more example deployment scripts in the [aztec-connect-bridges repo here](https://github.com/AztecProtocol/aztec-connect-bridges/tree/master/src/deployment). - -#### Update runtime config - -After your bridge contract is deployed to your local Ethereum network, you need to update the Aztec sequencer (falafel) with information about how to interact with the new bridge. - -Do this by appending the appropriate info for your bridge to the "bridgeConfigs" array in [config.json](https://github.com/AztecProtocol/dev-rel/blob/main/falafel-runtime-config.json) and sending it as a PATCH request to http://localhost:8081/runtime-config. You will need to set a couple of headers in the request for this to work: `server-auth-token`: `!changeme#` and `Content-Type`: `application/json`. - -For the ExampleBridge, it might looks like - -```json -{ - "bridgeConfigs": [ - // ... other configs here - { - "numTxs": 1, - "gas": 250000, - "bridgeAddressId": 14, - "permittedAssets": [0] - } - ], - "feePayingAssetIds": [0, 1] -} -``` - -where `numTxs` is the number of transactions per batch for the bridge. `gas` is the max gas that a bridge call requires. The rollup contract needs to know how much gas to send with a transaction. `bridgeAddressId` will be the `id` of the bridge that you deployed and `permittedAssets` are the [asset ids](../glossary#asset-ids) of the assets that can be sent to the bridge (you can check what assets are currently configured by checking the `localhost:8081/status` endpoint). - -To get you up and running, here is a [postman collection](https://raw.githubusercontent.com/AztecProtocol/dev-rel/main/local-devnet-postman-collection.json) that is plug and play. You learn how to import postman collections [here](https://learning.postman.com/docs/getting-started/importing-and-exporting-data/). - -### Connect Metamask - -Add anvil accounts and network information to Metamask. - -These devnets start the local Ethereum network at `http://localhost:8545`, so you will have to update the info associated with this network in Metamask. - -Chain id is `1337` or `3567` (when running mainnet fork devnet). - -[Anvil](https://book.getfoundry.sh/anvil/) private keys: - -``` -(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 -(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d -(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a -(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6 -(4) 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a -(5) 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba -(6) 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e -(7) 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356 -(8) 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97 -(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6 -Mnemonic: test test test test test test test test test test test junk -Derivation path: m/44'/60'/0'/0/ -``` - -If you have questions, please reach out on [Discord](https://discord.com/invite/UDtJr9u). - -### Add Custom Token - -To add support for a custom token that is deployed to the developer network, call `function setSupportedAsset(address _token, uint256 _gasLimit) external;` on the rollup contract. - -:::note -Permissionless token listing to mainnet is not yet supported. This only works for the testnet. -::: - -To do this: - -1. Import the [IRollupProcessor.sol](https://github.com/AztecProtocol/aztec-connect/blob/master/blockchain/contracts/interfaces/IRollupProcessor.sol) contract into [Remix](https://remix.ethereum.org) -2. Compile IRollupProcessor.sol -3. Connect Metamask to the local network -4. Connect Remix and Metamask -5. Create an instance of IRollupProcessor.sol at the proper address -6. Call `setSupportedAsset()` with your token address and `200000` for the `_gasLimit`. The `_gasLimit` tells the Aztec client how much gas token transfers use. 200,000 is an overestimate that is fine for testnet transactions, but you should test your token for more precise gas usage before deploying to mainnet. - -To get the assets that Aztec supports, call `IRollupProcessor.getSupportedAssets()`. This will return two arrays, an array of token addresses and an array of gas limits. diff --git a/docs/docs/developers/mainnet-info.md b/docs/docs/developers/mainnet-info.md deleted file mode 100644 index 827e97bc433e..000000000000 --- a/docs/docs/developers/mainnet-info.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Mainnet Resources ---- - -- [Aztec Connect (Aztec v2) mainnet block explorer](https://aztec-connect-prod-explorer.aztec.network/) -- [Aztec v1 mainnet block explorer](https://explorer.aztec.network) -- [Zk.money](https://zk.money) - -### Deployed Mainnet Contracts - -| Contract | Address | -| --- | --- | -| [Aztec Connect Proxy](https://etherscan.io/address/0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455#code) |`0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455` | -| [Element Bridge](https://etherscan.io/address/0xaeD181779A8AAbD8Ce996949853FEA442C2CDB47#code) | `0xaeD181779A8AAbD8Ce996949853FEA442C2CDB47` | -| [Lido-Curve Bridge](https://etherscan.io/address/0xe09801dA4C74e62fB42DFC8303a1C1BD68073D1a#code) | `0xe09801dA4C74e62fB42DFC8303a1C1BD68073D1a` | -| [Yearn Bridge](https://etherscan.io/address/0xE71A50a78CcCff7e20D8349EED295F12f0C8C9eF#code) | `0xE71A50a78CcCff7e20D8349EED295F12f0C8C9eF` | -| [Gas Subsidy Bridge](https://etherscan.io/address/0xABc30E831B5Cc173A9Ed5941714A7845c909e7fA#code) | `0xABc30E831B5Cc173A9Ed5941714A7845c909e7fA` | -| [Uniswap DCA Bridge](https://etherscan.io/address/0x94679A39679ffE53B53b6a1187aa1c649A101321#code) | `0x94679A39679ffE53B53b6a1187aa1c649A101321` | -| [ERC 4626 Bridge](https://etherscan.io/address/0x3578D6D5e1B4F07A48bb1c958CBfEc135bef7d98#code) | `0x3578D6D5e1B4F07A48bb1c958CBfEc135bef7d98` | - -You can find the latest bridge contract deployment info [here](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/deployments/mainnet.json). - -You can find more infrastructure contract address via the [Falafel status API here](https://api.aztec.network/aztec-connect-prod/falafel/status). diff --git a/docs/docs/developers/sequencer-api.md b/docs/docs/developers/sequencer-api.md deleted file mode 100644 index aa12b84aefaa..000000000000 --- a/docs/docs/developers/sequencer-api.md +++ /dev/null @@ -1,97 +0,0 @@ -# Sequencer API - -## Transactions - -Used to request Aztec txs - -### Transaction by ID - -Returns a specific Aztec tx, given the URL `:id` param - -**URL** : `/falafel/tx/:id` - -**Method** : `GET` - -**URL Params:** - -- `id`: Hash ID of Aztec transaction to be returned - -**Example:** - -``` -GET https://api.aztec.network/aztec-connect-prod/falafel/tx/5d8da46236f3b33d3f1c672167f219aaf2eaa6854eec7b7786ae4eff62ce03ad -``` - -### Success Response - -**Code** : `200 OK` - -**Content example** - -```json -{ - "id": "5d8da46236f3b33d3f1c672167f219aaf2eaa6854eec7b7786ae4eff62ce03ad", - "proofId": 3, - "proofData": "00000000000000000000000000000000000000000000000000000000000000032972ea1122f29feb673a4820b23eb791b63e758d1c165f379787ddb34750816d18572b5cd1901d05dd148745ddfa9645bd35c299449a16e145f4bb12d78ceb791e33da5958997253453c218cd2fe305f6eb7eb10e1b4f7bcb331068159d341a12e3a0a735c3eacb2df4283172161667f....", - "offchainTxData": "c11fc47744e518d95a3813b25ceb1c02c90272291ec0f3a089103e5797351a746b339b01deaa9ca5d63bfbc295056e57034f199400f5380a1bf0e10d23b89f82c4928f0184d95dc985160a92a26463cc2ae617a91c5ff8fcf8de085666094848b86bbe9532866f30842d2d8a49d046c6117e317a2fdf9e090a17d4408d9974ebe82aa2b4ab53bf8c07c7f842557503e86a01877c20525432ad9e12bc32de66e5cbabcef7877e0686d0318f80210f57886f0396e6c1eda3c8abd4888cff12c741fb306b874b4b0a4476b56a46ec2d55feb03ff12764765e7a1a2db361fb4abd85202f230a3b675d23b5be1cb5d305b91427ceda4c83e5927377337b740ec5dbc521283d786a3d04001a6092cad7b06ab992e2285376d73ca735c6a18fdb9ec72600000000", - "newNote1": "2972ea1122f29feb673a4820b23eb791b63e758d1c165f379787ddb34750816d", - "newNote2": "18572b5cd1901d05dd148745ddfa9645bd35c299449a16e145f4bb12d78ceb79", - "nullifier1": "1e33da5958997253453c218cd2fe305f6eb7eb10e1b4f7bcb331068159d341a1", - "nullifier2": "2e3a0a735c3eacb2df42831721616674f96ff97d4fafdf3c5010532aedb4ea94", - "publicInput": "0000000000000000000000000000000000000000000000000000000000000000", - "publicOutput": "0000000000000000000000000000000000000000000000000000000000000000", - "inputOwner": "0000000000000000000000000000000000000000000000000000000000000000", - "block": { - "id": 33, - "dataRoot": { - "type": "Buffer", - "data": [ - 27, 25, 222, 232, 222, 134, 238, 94, 81, 191, 44, 239, 234, 199, 82, ... - ] - }, - "created": "2022-06-27T08:18:35.412Z", - "processRollupCalldata": { - "type": "Buffer", - "data": [ - 248, 28, 204, 190, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... - ] - }, - "interactionResult": { - "type": "Buffer", - "data": [0, 0, 0, 0] - }, - "ethTxHash": { - "buffer": { - "type": "Buffer", - "data": [ - 98, 103, 49, 198, 246, 200, 0, 34, 173, 50, 106, 147, 89, 96, 7, 168, - 116, 210, 98, 108, 228, 80, 6, 61, 23, 255, 73, 139, 163, 22, 146, 86 - ] - } - }, - "gasPrice": { - "type": "Buffer", - "data": [ - 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, - 0, 0, 0, 4, 210, 155, 236, 253 - ] - }, - "gasUsed": 427934, - "mined": "2022-06-27T08:18:40.000Z", - "subtreeRoot": { - "type": "Buffer", - "data": [ - 37, 49, 84, 252, 200, 85, 197, 212, 41, 251, 150, 72, 251, 241, 163, - 103, 28, 55, 98, 190, 223, 16, 200, 134, 244, 212, 219, 183, 219, 197, - 161, 111 - ] - } - } -} -``` - -### Error Response - -**Condition** : If `id` param is invalid - -**Code** : `404 Not Found` diff --git a/docs/docs/developers/transaction-model.md b/docs/docs/developers/transaction-model.md deleted file mode 100644 index b53ce40a611f..000000000000 --- a/docs/docs/developers/transaction-model.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Transaction Model ---- - -Aztec uses a [UTXO model](https://en.wikipedia.org/wiki/Unspent_transaction_output) for tracking ownership of assets. For the technical details of how this is managed, refer to the [Rollup Contract specification](../spec/rollup_contract) for how data is stored in the system and the [JoinSplit Circuit specification](../spec/join_split_circuit) for reference on how transactions are created and processed. - -If you are trying to send an amount greater than the value of your largest [value note](./../glossary#value-notes), smaller notes must be merged into a value note greater than or equal to the value of the transaction. Merging value notes requires generating a proof for each note. The SDK handles merging notes automatically, but be aware that this may take a while if there are many notes that need to be merged. - -:::caution - -A max of two value notes can be used in a single transaction. If you have many small value notes that need to be aggregated into a larger note, you will have to pay transaction fees for each of these note merge transactions. The SDK will handle merging notes for you under the hood, but you will have to pay the corresponding transaction fees. - -This means that it only makes sense to make deposits and transfers that are materially greater than the Aztec transaction fee. - -::: - -## Chaining notes - -It is not required that notes are settled on Ethereum before they can be spent. This improves the user experience around sending notes. We refer to spending unsettled notes as "chaining" them together. - -Here are some rules to keep in mind about chaining notes: - -- Notes created from deposit cannot be chained from. Doing so will leak privacy. As there’s a link between two chained txs, people would be able to see that an L1 address is doing a defi deposit or withdrawing to another L1 address. - -- A pending note created from transfer/defi/withdraw can be chained from, as long as the state is available locally. For example, if I have 1 note worth 1 ETH, I can create a transfer tx, sending Alice 0.2 ETH. And then I can continue to create another tx, sending Bob 0.3 ETH. But if I clear my local storage after this, or login from another device, I will see my balance is 1 ETH, but the spendable sum is 0. And I can’t spend the 0.5 ETH before the txs are settled. - -- At most 1 pending note can be used in a chained tx. If I have 4 notes and each worth 0.5 ETH. And I send Alice 0.7 ETH, which merges 2 notes (0.5 + 0,5) and leaves me 1 pending note worth 0.3 ETH. And I send Bob 0.9 ETH, which also merges 2 notes (0.5 + 0,5) and leaves me another pending note with 0.1 ETH. I will not be able to use those two pending notes and send someone else 0.4 ETH. I will have to wait until at least one of them is settled. My spendable sum is 0.4 ETH, but the max spendable value is 0.3 ETH. diff --git a/docs/docs/glossary.md b/docs/docs/glossary.md index b0470f8c3823..b07846ff3009 100644 --- a/docs/docs/glossary.md +++ b/docs/docs/glossary.md @@ -2,79 +2,10 @@ title: Glossary --- -### Account - -An Aztec account is the user primitive on the network. See the [Accounts](how-aztec-works/accounts.mdx) page for more information. - -### Account Key - -See [Viewing Key](#viewing-key). - -### Account Migration - -Used when a user loses access to their [Account Keys](#account-key). This allows a user to keep their alias while setting new account key, spending key and recovery key. - -**Accounts can only be migrated 1 time.** - -### Account Note - -The accounts registered by users on Aztec are represented by account notes. An account note associates spending keys and aliases with an account. The spending key is used to sign transactions. - -### Account Recovery - -Used when a user loses access to all of their registered [Spending keys](#spending-key). Note that a user must have the [viewing key](#viewing-key) in order to recover an account. - -Read more about account recovery in the SDK docs [here](./sdk/usage/account-recovery.md). - -### Account Registration - -Registering an account on Aztec associates the account public key with an alias, a spending key and an optional recovery key. A recovery key must be added at registration in order to take advantage of [account recovery](#account-recovery). - -Read more about account registration on the [accounts page](how-aztec-works/accounts.mdx#account-registration) and in the SDK docs [here](./sdk/usage/register.md). - -### Alias - -The account public key is associated with a human-readable alias when the account registers a new signing key (see below). The alias can be anything (20 alphanumeric, lowercase characters or less) as long as it hasn't been claimed yet. - -### Asset Ids - -Asset Ids are unique numbers that correspond to various assets in Aztec. - -| Asset | Id | -| --- | --- | -| ETH | 0 | -| DAI | 1 | -| wstETH | 2 | -| yvDAI | 3 | -| yvWETH | 4 | -| weWETH | 5 | -| wewstETH | 6 | -| weDAI | 7 | -| wa2DAI | 8 | -| wa2WETH | 9 | - ### Barretenberg Aztec's cryptography back-end. Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture. -### Falafel - -The Aztec client. See [Sequencer](#sequencer) for more info. - -Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture. - -### Halloumi - -Aztec's Proof creation service. Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture. - -### Privacy Key - -See [Viewing Key](#viewing-key). - -### Rollup Processor Contract - -This is the smart contract on Ethereum that holds user deposits, facilitates interactions with other Ethereum contracts from Aztec and processes Aztec rollup blocks. You can find the contract on Etherscan [here](https://etherscan.io/address/0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455). - ### Sequencer This is also called the Rollup Processor. @@ -90,22 +21,8 @@ You can find the Typescript reference implementation called Falafel [here](https Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture. -### Spending Key - -A specific private key registered to an account with permission to spend asset notes on behalf of that account. See the [Accounts](how-aztec-works/accounts.mdx) page for more information. - -### Signing Key - -See [Spending Key](#spending-key). - -### Value Notes - -Asset notes (or value notes) are representations of asset in Aztec. They are sent around the network via transactions. - -### Viewing Key - -Also called the Account key, the privacy key or the decryption key. +### Smart Contract -This is the private key that is associated with plain (unregistered) Aztec account. This key is used to decrypt notes associated with the account. For an unregistered Aztec account, it is also used to spend notes. It can be used to [register](#account-registration) an account 1 time. +Programs that run on the Aztec network are called smart contracts, similar to [programs](https://ethereum.org/en/developers/docs/smart-contracts/) that run on Ethereum. -See the [Accounts](how-aztec-works/accounts.mdx) page for more information. +Smart contracts on Aztec may also optionally include private state and private functions. diff --git a/docs/docs/guides/create-bridge.md b/docs/docs/guides/create-bridge.md deleted file mode 100644 index a9ea01dc5bdd..000000000000 --- a/docs/docs/guides/create-bridge.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Build a new Aztec Connect Bridge ---- - -https://github.com/AztecProtocol/aztec-connect-bridges \ No newline at end of file diff --git a/docs/docs/how-aztec-works/accounts.mdx b/docs/docs/how-aztec-works/accounts.mdx deleted file mode 100644 index 4e6d8f24545b..000000000000 --- a/docs/docs/how-aztec-works/accounts.mdx +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: Accounts ---- - -import Image from "@theme/IdealImage"; - -Accounts in Aztec. - -For a deep dive into the technical details of Aztec accounts, see the [Account Circuit specification](../spec/account_circuit). - -## A Technical Primer on Accounts - -There are two main parts to each Aztec account, the account (private/public key pair) and signers. The account is associated with a [viewing key](../glossary.md#viewing-key) that can be used to decrypt [value notes](../glossary#value-notes) (assets on Aztec). The signers are associated with [spending keys](../glossary.md#spending-key) (or signing keys) which can be used to send notes from the associated account. - -These diagrams provide an overview of the account model and the following text goes into detail on each of the components. - -### Basic Aztec Account - - - -_The private key for an unregistered, basic account is like the viewing key AND the spending key for the account._ - -### Registered Aztec Account - - - -_For a registered account, the viewing key and spending key functionality is separated._ - -An account is a single private/public key pair until it is registered (see the [account registration](#account-registration) section below.) Before an account is registered, the private key is used to decrypt account notes as well as send value notes. The account will **not** have any registered spending keys or an [account alias](#account-alias) until is is registered. Once an account is registered, value notes that are sent to the account can either be marked to be spent by the account private key or the spending keys. It is a best practice for a sender to mark value notes as spendable by the spending keys when an account is registered. - -The SDK abstracts away much of this complexity to make it easier for developers to follow best practices. For example, when you look up an account by alias (meaning the account has been registered) a transfer automatically marks the notes as spendable by the recipients spending keys. You can still choose to mark value notes sent to an account as spendable by the account private key, but this is not recommended because the recipient may have shared that key with an other parties in order to allow it to decrypt value notes to calculate balances. - -### Compared to Ethereum - -Accounts in Aztec work differently than accounts in Ethereum. - -Aztec uses a different curve than Ethereum for SNARK efficient operations. This means that you cannot use an Ethereum private key directly for signing Aztec transactions or a public key for deriving an account address. Specifically, Aztec uses the Grumpkin curve, see [the yellow paper](https://hackmd.io/@aztec-network/ByzgNxBfd#2-Grumpkin---A-curve-on-top-of-BN-254-for-SNARK-efficient-group-operations) for more information. - -In [zk.money](https://zk.money), Aztec accounts are generated using Ethereum accounts by having a user sign a message and deriving the Aztec keys from the signed message. This ensures that as long as someone has access to their Ethereum account, they will be able to access their Aztec account by signing a message. Different messages are used to generate different keys (account decryption key and spending key). - -## Users And Accounts - -Users in Aztec will use the basic account to receive notes (via their public key) and decrypt balances (with the viewing key) and one of their registered spending keys to spend notes and initiate bridged Ethereum interactions. - -### Account - -A basic account is the first account that is generated for an Aztec user--it is a simple private/public key pair. - -The private key associated with this account can be used to decrypt notes. The private key can also be used to register many distinct spending keys. This allows for account abstraction by creating a separation between the key required to decrypt notes and the key required to spend notes. If a spending key has not been registered, the account viewing key can be used. - -Accounts can be identified by their alias or their public key. You can read more about aliases below. You can also find more information in the [SDK section on account keys](../sdk/usage/add-account#account-keys). - -### Spending keys (signer) - -An account should register a new spending key on the network in order to take advantage of account abstraction. - -When an account is first registered, you can pick a human-readable alias, a spending key and a recovery key. If the spending key is lost, a recovery flow can be initiated by the recovery account specified when the new spending key was registered (account recovery). - -Registering a spending key has an associated fee as it typically includes a token (or ETH) deposit and posts transactions to the network. - -You can add as many spending keys to an account as you want. This allows you to spend notes from the same account from multiple devices without having to share sensitive private keys across devices. - -Read more about creating and using spending keys in the SDK docs [here](./../sdk/usage/add-account#spending-keys). - -### Account Registration - -To register a new account, you need to choose an alias and a new spending public key. Optionally, you can include a recovery account public key and a deposit. - -Generally, an account with a registered spending key is considered safer than an account that only uses the default account keys. An account without a spending key uses default account viewing key for note decryption as well as spending notes. When a spending key is registered, the default private key can only be used for decrypting notes and spending must be done with a registered spending key. - -Most users will typically use an account with a registered spending key and are thus considered "safe". There are use cases (airdrops) where you might want to use an account that has not yet registered a spending key and is using the default account key for both note decryption and spending. So it is possible to use the system without registering your account. - -When you use an unregistered account, your notes are marked as spendable by the account viewing key. The sender can specify whether notes are spendable with the account viewing key. A sender can check whether an account has registered spending keys before specifying the spending key. - -You cannot mix the spending of these notes, the two balances are distinct. It is possible to merge the balances. You would send unspent notes from the basic account to yourself, marking them as spendable by the signing key. - -The SDK tries to abstract much of this complexity away and presents everything to a developer as if this notion does not exist (e.g. the account balance is the sum of all notes regardless of registered or not). - -If you want to know exactly what you can spend in one transaction, you have to tell the SDK whether you're interested in the unregistered or registered balances. - -When actually creating the zero knowledge proof, the SDK infers which balance you're drawing from based on whether you give it a spending key or the account key. - -Read more about account registration with the SDK on [this page](../sdk/usage/register). - -### Account Alias - -The account public key is associated with a human-readable alias when the account registers a new signing key (see below). The alias can be anything (20 alphanumeric, lowercase characters or less) as long as it hasn't been claimed yet. - -Do not forget your alias. If you forget your alias you will not be able to share it to make it easy for them to send you asset notes. - -There is no way to recover a forgotten alias, but you can register a new account with a new alias and transfer your notes to the new account. - -If you forget your alias you can still transfer and withdraw asset notes. - -### Account Migration - -Account migration allows you to keep your alias and just update your account (privacy) keys. This will update the public key associated with your alias as well as the key that is used to decrypt your account notes. This can only be done 1 time. - -### Account Recovery - -If you lose access to all of your spending keys for an account, the designated recovery account can help you recover access and register a new spending key that you have access to. - -This recovery information is created and registered with the account during the account registration step. - -Read more about account recovery with the SDK on [this page](../sdk/usage/account-recovery). - -## Frequently Asked Questions - -### What happens if I lose my Aztec account private key? - -Your Aztec account private keys are derived from an Ethereum signature we ask you to sign when you register with us. As long as you still control your original Ethereum account you can re-derive your Aztec account keys. - ---- - -### What happens if I lose my Aztec account private key AND my Ethereum account private key? - -At the current time, your funds would be lost. Our protocol architecture supports Aztec account social recovery but implementation into our front-end software is still under development. - ---- - -### What is the zk.money username for? - -zk.money username/alias lets other users easily lookup your encryption public key so they can send you assets. This name has to be unique and is limited to 20 characters, lowercase, alphanumeric. Please note that this isn’t an ENS domain, but it serves a similar purpose within the confines of our network. - ---- - -### I've registered to the platform, but zk.money prompts registration once again when I try to log in again? - -Please follow these instructions: - -**Step 1:** Clear browser cache. For Chrome, this is the link: chrome://settings/cookies/detail?site=zk.money - -**Step 2:** Make sure you are signing in with the Metamask account you used to register zkmoney username. - -> 💡 Sign in with Metamask account you used to register your zkmoney username (You might have previously used a different Metamask account for funding/depositing). - -**Step 3:** - -- If it shows "Claim Username," it means your previous deposit has not been used. Claim Username to proceed. -- If it asks you to "Deposit", it is likely we have a bug. Don't proceed and message the support team at [Discord](https://discord.gg/9TaSvc8f7r). diff --git a/docs/docs/how-aztec-works/aztec-connect/aztec-connect.mdx b/docs/docs/how-aztec-works/aztec-connect/aztec-connect.mdx deleted file mode 100644 index 939bb4965ae7..000000000000 --- a/docs/docs/how-aztec-works/aztec-connect/aztec-connect.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: Aztec Connect ---- -import Image from '@theme/IdealImage'; - -__Dollars and Sense: Cheap Privacy with Aztec Connect__ - -How Aztec Connect grants Ethereum cheap privacy today. - -For an in-depth technical explanation of how Aztec Connect bridges work, please refer to [the official GitHub repository here](https://github.com/AztecProtocol/aztec-connect-bridges). - - - -Aztec is laser-focused on shipping Aztec Connect, a set of tools connecting Ethereum DeFi protocols to Aztec's private rollup, allowing for composable, private DeFi to be done on Ethereum for the first time ever. - -Aztec Connect is able to unlock private DeFi with the help of three components: - -1. __Layer 1 DeFi protocols__: your favorite Ethereum protocols like Lido, Element, Aave, Compound, Uniswap, and more -2. __Aztec Connect Bridge Contracts__: an interface that enables the Aztec rollup contract to talk to Layer 1 DeFi protocols -3. __Aztec Connect SDK__: allows users to create & submit transactions to the Aztec rollup. Think of this as a crypto library for application front-ends — the zk-equivalent of ethers.js, which lets users send transactions to Ethereum nodes via their favorite applications. - -The Aztec Connect toolkit essentially functions [like a proxy service](https://medium.com/aztec-protocol/private-defi-with-the-aztec-connect-bridge-76c3da76d982) for DeFi— allowing anyone to deposit into Aztec's system, interact with Ethereum DeFi, and rely on the trusted contracts, liquidity, and execution of Layer 1, while also adding cheap privacy. - -## ✈️ Aztec Connect Supercharges Layer 1 DeFi -Aztec Connect relies on Layer 1 for transaction execution, using DeFi batching to achieve cost savings. These design decisions represent serious benefits to our partners: - -- No additional audits; no redeployment of core contracts -- Simple ~100–200 line Bridge Contract interfaces to enable cost savings -- Retention of Layer 1 liquidity and composability - -This last point bears repeating: unlike alt-L1 EVM implementations or L2's with their own execution environment, Aztec Connect allows developers to gain access to cheap privacy today, retaining composability with other protocols. - -Take [Element.fi](http://element.fi/) for example. Element fixed-rate vaults are integrated with and built on top of a huge number of existing protocols: - -- MakerDAO -- Yearn -- Curve - -In order for Element to retain similar levels of composability, liquidity, and functionality on a new chain, those protocols would have to collectively migrate in a coordinated fashion. In Element CTO -[jonny rhea](https://medium.com/u/916b1bfb656?source=post_page-----f35db037a04--------------------------------) -'s own words: - -> What's unique about Aztec is that their rollups interact directly with existing smart contracts and liquidity on mainnet. So, the integration with Aztec will allow us to avoid liquidity fragmentation because it postpones the necessity of deploying Element Finance on multiple L2 networks. - -Cheap privacy, today. So how do we lower costs if everything executes on L1? Simple: by using our zkRollup to spread the costs of not only proof verification for privacy but also DeFi transaction costs across large number of users. - -This means the formula for understanding cost savings is incredibly straightforward: - -## 🍰 Layer 1 Execution Costs - -Remember the simple formula for rollup math [from our last post](https://medium.com/aztec-protocol/privacy-for-pennies-scaling-aztecs-zkrollup-9f2b36615cc6)? That math holds for all Aztec deposits, withdrawals, and internal sends. Just like other rollups, off-chain execution costs are amortized over a very large number of transactions. - -Aztec Connect is an extension of batching from just deposits, withdrawals and sends to all kinds of DeFi transactions. - -And the more transactions occur, the more rollups fill up and “ship” down to L1, reducing system latency and transaction costs: - - - -_The Aztec rollup flywheel._ - -## 📩 Privacy for All - -Because rollups are amortized across all network transactions, including deposits, withdrawals, internal transactions, and DeFi, we anticipate sufficient transaction throughput to make rollup verification — and therefore privacy —very close to free for the user. - -DeFi transactions will be cheaper in direct relation to batch size, with gas savings being 1/n, where n is the number of users in a given batch. - -From the above, we can come to an Ultimate Calculation™ for the cost of Aztec Connect transactions at launch: - -- Share of rollup verification costs (896 txn rollup): 614 gas -- Call data costs: 14,672 gas -- __Total cost of privacy__: 15,376 (less than the 21,000 base transaction cost on Ethereum, meaning private transactions are always cheaper than L1) -- Cost of DeFi transaction: L1 execution cost (~500,000 gas in the case of Element vault entry) / batch size (say 50 users per rollup) = 10,000 gas -- __Total transaction cost: ~24,672 gas__ (95% cost savings over L1, or 20x cheaper) or ~$3.70 in today's gas regime - -In plain English: - -- __Privacy is free.__ It will always be cheaper to do an Aztec private transaction than a Layer 1 Ethereum transaction. -- __Cost savings are roughly ~1/n__, where n is the size of the DeFi transaction batch. - -## 🤑 Spinning the DeFi Flywheel - -Remember the rollup flywheel from above? DeFi interactions have a similar flywheel effect. It takes time to aggregate users in a batch to access cost savings. - -That's why we're starting with vault entry (Element.fi) and Staking (Lido), use cases that lend themselves to large batches and don't demand immediate settlement. - -In order to deliver steady-state performance as the flywheel starts spinning, we are committed to backstopping transaction batch speed. That means from day 0, it will seem like batches are running full. - -We've already pursued grants with some of the leading DeFi projects, including Compound, Aave, and Lido, to backstop DeFi batch timing and ensure users get maximum cost savings. - -Even if a batch doesn't fill, it will fire across to L1 and execute, with us and our partners covering any remaining cost. - -[Polynya](https://medium.com/u/923c922a6d67?source=post_page-----f35db037a04--------------------------------) puts it best [in a post](https://twitter.com/epolynya/status/1474990044154793984?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1474990044154793984%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fepolynya%2Fstatus%2F1474990044154793984image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07) about loss-leading as a way to bootstrap rollup speed and throughput: - -> Showerthought: ZKRs should be loss-leading, with max ~$0.10 transaction fees* for the end user. Verification price capped at ~250 gas. Cost to rollup: $12,000/day, decreasing rapidly with growing activity, with break-even at 3.33 TPS*. From there, tx fees will keep decreasing. - -We have experience here — we already did it for private payments on [zk.money](http://zk.money/). Initial rollups on zk.money didn't run full, but we backstopped rollup timing until throughput caught up. It worked. What happened when we made sure users had the best experience from day 0? Over 1,000 full rollups since mid-November. - -## 🧗 Continuous Improvement: Kaizen for Connect - -It's worth noting that a full 1/3 of the call data costs for a DeFi transaction come from posting transaction viewing keys on Ethereum. - -We plan to implement an off-chain viewing key system later this year, which will cut the total cost of call data by ~58%. That means the total cost of privacy will go from 15,376 gas to 6,896 gas on Aztec Connect. - -With Aztec Connect, privacy on Ethereum isn't just free, it's better than free. - -## 📕 Tl;dr -Aztec Connect is a transformative set of tools that showcase what is possible with our back-end zk architecture. It leans on L1 execution and contracts to bring privacy and cost savings to DeFi projects immediately, without having to redeploy and re-audit. - -- Privacy is free -- DeFi fees are reduced proportionally with batch size -- Fees are fixed to their cheap, long-term level and backstopped by Aztec and our partners - -From day 0 users will experience cost savings as if transaction batches are running full, whether they are or not. Meaning 95%+ cost savings on the most popular DeFi transactions. - -Aztec Connect extends the functionality of our network beyond private payments, showcasing cheap private DeFi today. It is a gigantic step toward our vision for generalized private smart contracts: Noir. - -Stay tuned. - ---- - -## 🏗 Build with Aztec Connect - -Are you a developer who wants to bring privacy to your favorite DeFi protocol? If you build it, we'll fund it. - -Aztec Grants Program: https://aztec.network/grants/ - -Connect Starter: https://github.com/AztecProtocol/aztec-connect-starter. - -Help make privacy a no-brainer. diff --git a/docs/docs/how-aztec-works/aztec-connect/technical-intro.md b/docs/docs/how-aztec-works/aztec-connect/technical-intro.md deleted file mode 100644 index ce3212c976da..000000000000 --- a/docs/docs/how-aztec-works/aztec-connect/technical-intro.md +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: Technical Introduction ---- - -This page is taken from the [Aztec Connect Bridges repository](https://github.com/AztecProtocol/aztec-connect-bridges) README on Github. - -### What is Aztec? - -Aztec is a privacy focused L2, that enables cheap private interactions with Layer 1 smart contracts and liquidity, via a process called DeFi Aggregation. We use advanced zero-knowledge technology "zk-zk rollups" to add privacy and significant gas savings any Layer 1 protocol via Aztec Connect bridges. - -#### What is a bridge? - -A bridge is a Layer 1 Solidity contract deployed on mainnet that conforms a DeFi protocol to the interface the Aztec rollup expects. This allows the Aztec rollup contract to interact with the DeFi protocol via the bridge. - -A bridge contract models any Layer 1 DeFi protocol as an asynchronous asset swap. You can specify up to two input assets and two output assets per bridge. - -#### How does this work? - -Users who have shielded assets on Aztec can construct a zero-knowledge proof instructing the Aztec rollup contract to make an external L1 contract call. - -Rollup providers batch multiple L2 transaction intents on the Aztec Network together in a rollup. The rollup contract then makes aggregate transaction against L1 DeFi contracts and returns the funds pro-rata to the users on L2. - -#### How much does this cost? - -Aztec Connect transactions can be batched together into one rollup. Each user in the batch pays a base fee to cover the verification of the rollup proof and their share of the L1 DeFi transaction gas cost. A single Aztec Connect transaction requires 3 base fees or approximately ~8000 gas. - -The user then pays their share of the L1 Defi transaction. The rollup will call a bridge contract with a fixed deterministic amount of gas so the total fee is simple ~8000 gas + BRIDGE_GAS / BATCH_SIZE. - -#### What is private? - -The source of funds for any Aztec Connect transaction is an Aztec shielded asset. When a user interacts with an Aztec Connect Bridge contract, their identity is kept hidden, but balances sent to the bridge are public. - -#### Batching - -Rollup providers are incentivised to batch any transaction with the same `bridgeId`. This reduces the cost of the L1 transaction for similar trades. A `bridgeId` consists of: - -## Virtual Assets - -Aztec uses the concept of Virtual Assets or Position tokens to represent a share of assets held by a Bridge contract. This is far more gas efficient than minting ERC20 tokens. These are used when the bridge holds an asset that Aztec doesn't support (e.g. Uniswap Position NFT's or other non-fungible assets). - -If the output asset of any interaction is specified as "VIRTUAL", the user will receive encrypted notes on Aztec representing their share of the position, but no tokens or ETH need to be transferred. The position tokens have an `assetId` that is the `interactionNonce` of the DeFi Bridge call. This is globally unique. Virtual assets can be used to construct complex flows, such as entering or exiting LP positions (e.g. one bridge contract can have multiple flows which are triggered using different input assets). - -## Aux Input Data - -The `auxData` field can be used to provide data to the bridge contract, such as slippage, tokenIds etc. - -### Bridge Contract Interface - -```ts -// SPDX-License-Identifier: GPL-2.0-only -// Copyright 2020 Spilsbury Holdings Ltd -pragma solidity >=0.6.6 <0.8.0; -pragma experimental ABIEncoderV2; - -import { Types } from "../Types.sol"; - -interface IDefiBridge { - /** - * Input cases: - * Case1: 1 real input. - * Case2: 1 virtual asset input. - * Case3: 1 real 1 virtual input. - * - * Output cases: - * Case1: 1 real - * Case2: 2 real - * Case3: 1 real 1 virtual - * Case4: 1 virtual - * - * Example use cases with asset mappings - * 1 1: Swapping. - * 1 2: Swapping with incentives (2nd output reward token). - * 1 3: Borrowing. Lock up collateral, get back loan asset and virtual position asset. - * 1 4: Opening lending position OR Purchasing NFT. - Input real asset, get back virtual asset representing NFT or position. - * 2 1: Selling NFT. Input the virtual asset, get back a real asset. - * 2 2: Closing a lending position. Get back original asset and reward asset. - * 2 3: Claiming fees from an open position. - * 2 4: Voting on a 1 4 case. - * 3 1: Repaying a borrow. Return loan plus interest. Get collateral back. - * 3 2: Repaying a borrow. Return loan plus interest. - Get collateral plus reward token. (AAVE) - * 3 3: Partial loan repayment. - * 3 4: DAO voting stuff. - */ - - /* - @dev This function is called from the RollupProcessor.sol contract via the DefiBridgeProxy. - It receives the aggregate sum of all users funds for the input assets. - @param AztecAsset inputAssetA a struct detailing the first input asset, - this will always be set - @param AztecAsset inputAssetB an optional struct detailing the second input asset, - this is used for repaying borrows and should be virtual - @param AztecAsset outputAssetA a struct detailing the first output asset, - this will always be set - @param AztecAsset outputAssetB a struct detailing an optional second output asset - @param uint256 inputValue, the total amount input, - if there are two input assets, equal amounts of both assets will have been input - @param uint256 interactionNonce a globally unique identifier for this DeFi interaction. - This is used as the assetId if one of the output assets is virtual - @param uint64 auxData other data to be passed into the bridge contract (slippage / nftID etc) - @return uint256 outputValueA the amount of outputAssetA returned from this interaction, - should be 0 if async - @return uint256 outputValueB the amount of outputAssetB returned from this interaction, - should be 0 if async or bridge only returns 1 asset. - @return bool isAsync a flag to toggle if this bridge interaction will return assets - at a later date after some third party contract has interacted with it via finalise() - */ - function convert( - Types.AztecAsset calldata inputAssetA, - Types.AztecAsset calldata inputAssetB, - Types.AztecAsset calldata outputAssetA, - Types.AztecAsset calldata outputAssetB, - uint256 inputValue, - uint256 interactionNonce, - uint64 auxData - ) - external - payable - returns ( - uint256 outputValueA, - uint256 outputValueB, - bool isAsync - ); - - /* - @dev This function is called from the RollupProcessor.sol contract via the DefiBridgeProxy. - It receives the aggregate sum of all users funds for the input assets. - @param AztecAsset inputAssetA a struct detailing the first input asset, - this will always be set - @param AztecAsset inputAssetB an optional struct detailing the second input asset, - this is used for repaying borrows and should be virtual - @param AztecAsset outputAssetA a struct detailing the first output asset, - this will always be set - @param AztecAsset outputAssetB a struct detailing an optional second output asset - @param uint256 interactionNonce - @param uint64 auxData other data to be passed into the bridge contract (slippage / nftID etc) - @return uint256 outputValueA the return value of output asset A - @return uint256 outputValueB optional return value of output asset B - @dev this function should have a modifier on it to ensure - it can only be called by the Rollup Contract - */ - function finalise( - Types.AztecAsset calldata inputAssetA, - Types.AztecAsset calldata inputAssetB, - Types.AztecAsset calldata outputAssetA, - Types.AztecAsset calldata outputAssetB, - uint256 interactionNonce, - uint64 auxData - ) external payable returns (uint256 outputValueA, uint256 outputValueB, bool interactionComplete); -} - -``` - -### Async flow explainer - -If a Defi Bridge interaction is asynchronous, it must be finalised at a later date once the DeFi interaction has completed. - -This is achieved by calling `RollupProcessor.processAsyncDefiInteraction(uint256 interactionNonce)`. This internally will call `finalise` and ensure the correct amount of tokens have been transferred. - -#### convert() - -This function is called from the Aztec Rollup Contract via the DeFi Bridge Proxy. Before this function on your bridge contract is called the rollup contract will have sent you ETH or tokens defined by the input params. - -This function should interact with the DeFi protocol (e.g Uniswap) and transfer tokens or ETH back to the Aztec Rollup Contract. The Rollup contract will check if it received the correct amount. - - -At a later date, this interaction can be finalised by prodding the rollup contract to call `finalise` on the bridge. - -#### finalise() - -This function will be called from the Aztec Rollup contract. The Aztec Rollup contract will check that it received the correct amount of ETH and tokens specified by the return values and trigger the settlement step on Aztec. diff --git a/docs/docs/how-aztec-works/faq.md b/docs/docs/how-aztec-works/faq.md deleted file mode 100644 index eebf21052447..000000000000 --- a/docs/docs/how-aztec-works/faq.md +++ /dev/null @@ -1,164 +0,0 @@ -# Frequently Asked Questions - -## General Questions - -### What happens when I shield a token? - -Aztec has an offchain UTXO architecture that functions like cash. Shielding a token functionally means depositing it into Aztec's Ethereum smart contracts, which then communicate with Aztec's offchain UTXO state system to generate cash-like encrypted notes. - -The entire system accounts for a user's claim on Layer 1 tokens and assets via a fully encrypted state system (kind of like the briefcase of IOU's from Dumb and Dumber: https://www.youtube.com/watch?v=7GSXbgfKFWg). - -When assets are deposited to Aztec, withdrawn from Aztec, sent within Aztec, or exchanged for other assets via Aztec Connect, the state tree is updated with new encrypted notes. Because no one can peer inside a note except its owner, user identity and account balance is fully preserved. - -For more information on Aztec's UTXO architecture, see this blog post: https://medium.com/aztec-protocol/fully-confidential-ethereum-transactions-aztec-networks-privacy-architecture-274f968b13d4 - -**Your transaction can go in two directions:** - -1. Send zkETH/DAI to a username (@name) on zk.money. The recipient will get zkETH/DAI. - -2. Send zkETH/DAI to any Ethereum address outside of zk.money - the wallet will receive regular ETH/DAI tokens. (Etherscan will show the funds were sent from Aztec’s contract, which doesn’t expose the sender 🕵️. If you have trouble seeing the funds on the public transaction log, please click the "Internal Txn" tab). - -![](https://user-images.githubusercontent.com/15220860/172720151-19349841-17b6-4861-a101-eacd5724144d.png) - ---- - -### What happens when someone sends me zkETH/DAI? - -1. **If your wallet is connected to zk.money -** you’ll receive zkETH/DAI directly to your account. You’ll be able to “un-shield” it back to L1 and have regular ETH or continue transacting with zkETH. - -2. **If your wallet isn’t connected to zk.money** - you’ll be able to receive regular ETH/DAI directly into your wallet. The sender’s side will be anonymous. (Etherscan will show the funds were sent from an Aztec contract). - ---- - -### Is there a transaction limit on zk.money? - -Currently, users are limited to shielding **up to 5 $ETH or 10,000 $DAI at a time**.** - ---- - -### What if my deposit fails mid-way through? - -**If your deposit fails mid-way through or you accidentally close the tab, your funds are safe on the contract.** - -You can retry your transaction by re-shielding via the shield form. The text under the input box will show any pending deposit balance. - -![zkmoney1](/img/zkmoney1.png) - ---- - -### How can I track my transactions? - -**You’ll be able to see and track your transactions' status on the dashboard.** - -And you can also track your transactions in real-time in the Aztec explorer via the transaction link. If you shield to a username that isn’t your own, the amount and recipient will not show in the transaction history, because the data is encrypted. - ---- - -### Is zk.money decentralized? - -zk-money is powered by Aztec. The current release of Aztec's L2 Rollup technology is run with Aztec as the sole rollup provider, with more rollup providers onboarding later this year. At that point, the system will be decentralised. Currently, users rely on Aztec to relay rolled up transactions to the chain. In case Aztec suddenly disappears, there is an emergency mode to allow users to withdraw funds from the system directly from the contract. - ---- - -### If I send somebody a private transaction, will they know I am the sender? Will they be able to read my balance? - -No. In the future, you will be able to choose to reveal your identity to the recipient if required, but this feature is still under development. - ---- - -### How quickly can I withdraw? - -Initially, we will be publishing rollup blocks every 4 hours. This time interval will decrease with increased use. - -If you wish to immediately withdraw, you can increase your transaction fee to pay for a rollup block to be immediately constructed and published. It will take approximately 10 mins for a block to be published on main-net and the withdrawal finalised. - -### Can I deposit and then immediately withdraw from Aztec? - -We do not recommend this if you want privacy. If you deposit and immediately withdraw, observers might be able to deduce that the deposit and withdrawal belong to the same user, especially if the deposit/withdraw values are unique. - -Ideally, you should wait at least until the rollup has processed a block of transactions before you withdraw. The longer you wait, the larger the anonymity set. - -### Are there ANY conditions under which I cannot withdraw my funds? - -All of the information required to create an escape hatch withdrawal transaction can be extracted from published blocks on the Ethereum main-net. - -There are two worst-case 'failure states' that would cause a loss of user funds: - -1. The Ethereum protocol itself is compromised and we cannot rely on its consensus algorithm -2. There is a bug in our protocol that enables a hacker to steal funds - -As long as both the Aztec and Ethereum protocol architectures are sound, it is not possible for user funds to be locked or stolen. - -For more information about our bug bounty program and internal audit, please read [this article](https://medium.com/aztec-protocol/aztec-2-0-pre-launch-notes-aabad022808d). - -### Are private send amounts fixed? - -No. You can send any value internally within our rollup. - - -### Are deposit amounts fixed? - -No. You can deposit any value into our system. - -### Are withdrawal amounts fixed? - -No, but it is recommended that your withdrawal transactions are either 0.1 Eth or 1 Eth. The more 'unique' your withdrawal value, the easier it is for observers to guess the deposit transactions that created your withdrawal transaction. - -If you withdraw 0.1 Eth, for example, your withdraw tx looks like all of the other 0.1 Eth withdraw transactions that have occurred since your deposit transaction. - -### Why can't I send Aztec transactions from an iPhone? - -We are aware of an issue with the Safari web browser on iPhones. Our prover algorithms require 900MB of RAM, which iPhone Safari tabs do not currently allow for. We are working hard to resolve this issue and will update this FAQ once this is resolved. - ---- - -## Rollup - -### How long does it take for a transaction to settle? - -The Rollup allows zk.money to batch a few transactions together (up to 112) and help users save on gas fees. - -Aztec pays the network fees on behalf of the users - in that setup, users that broadcasted a transaction are paying a small share of the total cost according to their pro-rata share in the Rollup. - -The more transactions are made, the faster each Roll will fill up, and completion time will be quicker. In case of slow periods, Aztec will subsidise remaining fees for the Rollup to ensure Rollup is sent at least every 6 hours. If users don't want to wait long, they may speed up transaction times by paying higher fees. - -### Can the rollup provider censor my transactions and refuse to add them to a block? - -The rollup provider cannot extract any information from your private transaction - to them, it looks like a list of random numbers. If the rollup provider wishes to censor a specific user, they are unable to do so. - -### What happens if the rollup provider refuses to publish any blocks? Can I still withdraw? - -Yes. Our 'escape hatch' mechanism enables withdrawals if the rollup provider goes down. For 2 hours per day, users can create 'escape hatch' proofs and send them directly to our rollup contract. This enables unconditional withdrawals from our system. Escape hatch proofs are time-consuming and expensive to create so this should only be used as a last resort. - -### Will ordinary people be able to run a rollup? - -Technically anyone can currently be a rollup provider for 2 out of every 10 hours right now. It is how the escape hatch mode works. We expect to decentralise further with community providers in ~3 months. - ---- -## Fees - -### How does the protocol decide on the fee? - -Currently, there are 28 slots in a rollup (we can increase this up to 128), the base fee is calculated as (1/28 of the proof verification gas costs + tx_type_feeConstant) *** the gas price at the last rollup *** a buffer of 1.2. The tx type fee constant is calculated as the fixed cost of calldata plus a constant depending on the assetId and the transaction type (shield, send, unshielded). For base fees, Aztec guarantees a rollup goes on-chain every 6 hours currently. - -The rollup provider will automatically create a rollup proof whenever it has sufficient fees to cover an L1 transaction, or when the 6 hour block time has elapsed. The last fee slot is the cost for paying for 28 slots in the rollup and will trigger the rollup to create a proof instantly. The in-between fees levels are equivalent to paying for 10% and 50% of the slots in the rollup and reducing the 6 hour block time by 10% and 50% respectively. The idea here is to try and encourage users to pay a bit more so we can bring the block time down for everyone once we reach sustained throughput at say 4h. - -One small side note, the rollup provider receives a refund for the gas cost of the L1 transaction, any surplus fees are owned by a contract and used to offset future rollups that may not be full. - -We wanted to try and encourage a fee market and create a flow where Aztec does not make money from the fees, instead of a user overpaying, that payment helps to subsidise future transactions. As more rollup providers come online we will be changing this. - -### How much do transactions cost? - -- Deposit: 51,000 gas -- Internal send: 17,000 gas -- Withdraw: 5,000 gas for ETH to EOA 30,000 gas to contract. - -### Do I pay any fees to Aztec for my zkETH/DAI transactions? - -Aztec doesn’t make any money from transaction fees on the platform, surplus transaction fees accumulate on a smart contract and are used to subsided future transactions in busy periods with high gas prices. - ---- - -### Have other questions? - -Join our [Discord channel](https://discord.com/invite/UDtJr9u) and get an answer from the community. diff --git a/docs/docs/how-aztec-works/fees.md b/docs/docs/how-aztec-works/fees.md deleted file mode 100644 index ad5037d5286b..000000000000 --- a/docs/docs/how-aztec-works/fees.md +++ /dev/null @@ -1 +0,0 @@ -** Big title ** diff --git a/docs/docs/how-aztec-works/privacy-sets.md b/docs/docs/how-aztec-works/privacy-sets.md deleted file mode 100644 index 3bdc742a4960..000000000000 --- a/docs/docs/how-aztec-works/privacy-sets.md +++ /dev/null @@ -1,180 +0,0 @@ ---- -title: Infinite Privacy (Sets) ---- - -In the last article in our series on Aztec’s privacy architecture, we explored how a private network is even possible on a public blockchain. - -Today we’re exploring why a private network is endlessly more private than simple solutions like privacy mixers. - -Just like mixers, Aztec offers basic deposits and withdrawals — meant to break the link between a sending address and receiving address: our current private payments front-end zk.money has been live on mainnet since March and recently crossed 4,800 ETH in deposits bridged. - -But zk.money also offers private internal transfers and will soon offer a full suite of Ethereum Layer 1 Defi functionality enabled by our bridge, Aztec Connect. - -The addition of these anonymizing activities means Aztec will offer a large and dynamic privacy set that will become increasingly more difficult to de-anonymize —a concept we like to call Infinite Privacy. - -## The Infinite City - -Imagine Aztec as a walled city. All an outside observer can see is users entering and leaving Aztec via our bridge. - -Within the walls of the city, users can exchange assets with fully private transactions. Neither the network nor its participants can see the senders and recipients of transactions, nor their amounts. - -In addition, once inside the system, users can batch transactions and teleport back to L1 — to swap, stake for yield, lend funds, vote in DAOs, or buy NFTs. In the near future the contributors to ConstitutionDAO will be able to do so privately, and with nearly 0 gas. - -Because Aztec allows for these two new anonymizing activities — internal transactions and batched interactions with Layer 1 Ethereum— the privacy set is significantly harder for an observer to calculate than, for instance, on a privacy mixer without those features. - -That’s a very good thing. - -## Sleuthing and Deducing - -Let’s put ourselves in the shoes of an adversary attempting to run de-anonymizing transaction graph analysis. - -As an observer watching Ethereum activity, we might watch deposits to and from Aztec, and attempt to deduce what set of deposits a certain withdrawal might belong to. - -This is what we mean by privacy or anonymity set — the group or set of users a forensic target could be. If the privacy set the target belongs to is large, then we can only guess with a small probability which addresses and transactions the target is associated with. - -Once the privacy set you belong to approaches 1, the probability an observer knows who you are also approaches 1, and your privacy is no longer protected. - -Let’s talk through an example. - -## Anonymity Sets 101: Mixer Math - -Pretend Aztec were a simple privacy mixer without internal transactions, and we were internet sleuths trying to de-anonymize the network 🕵.️ - -If we saw someone withdraw 1 ETH, we’d know for certain that they’d deposited at least 1 ETH into the mixer. Because there are no internal transfers, aggregation of multiple deposits into a larger withdrawal simply isn’t possible. - -“So,” we’d puzzle, “all we need to figure out is how many people have ever deposited at least 1 ETH, and then the withdrawer must be one of those people!” - -Good thing we have Dune Analytics to help us visualize how some of these privacy sets might work! You can see our privacy set dashboard here: https://dune.xyz/jaosef/Aztec-2. - -The answer to the question of who the 1 ETH withdrawal could be in this case would be “everyone to the right of 1 ETH in this diagram,” which turns out to be 1,174 deposits. - -![image](https://user-images.githubusercontent.com/15220860/174936505-ea2afa43-ba15-4921-b8ea-6c8c3d69c0f7.png) - - -## The privacy set in a world without internal transfers. - -Of course, the probability that a 1-ETH withdrawer came from the 1 ETH deposit set is much higher than the probability that she came from the >1 ETH deposit set, for a purely behavioral reason: - -It’s annoying to break 5-, 10-, or 30-ETH deposits into smaller 1 ETH withdrawals. It’s much simpler to do one big monolithic withdrawal. - -So as sophisticated sleuths, our investigative instincts would say that there is some non-zero but small probability that the withdrawer deposited an amount >1 ETH, with that probability diminishing for larger deposits: - -![image](https://user-images.githubusercontent.com/15220860/174936543-5f6c3606-2271-41de-a5db-c4c73724cea6.png) - -This is an example of a simple probability distribution — and the “spikier” it is, the more certainty an adversary has about user behaviors. - -In this case, based on observations of other privacy mixers and other comparable behaviors on Defi, a forensic analyst might think the probability of a 1 ETH withdrawal coming from a 5 ETH deposit is 5x lower than the probability of a 1 ETH withdrawal coming from a 1 ETH deposit. - -## Standing In or Standing Out - -Let’s establish a rough heuristic guide to thinking about privacy sets: - -In order to figure out how to blend in, figure out how to stand out, and then do the opposite. - -The most obvious way for me to stand out in the case without internal transactions would be if I bridged a massive monolithic deposit and withdrew the same amount shortly afterward. - -To make myself even more highly identifiable, I would use a unique quantity of a certain asset (e.g. depositing 69.696969 ETH to Aztec, then subsequently withdrawing 69.696969 ETH). To prevent de-anonymizing behavior, the zk.money front-end suggests round-number deposits and withdrawals — so you don’t stand out — and will soon also nudge users toward the largest anonymity sets. - -As users what we want to do is introduce uncertainty into any forensic analysis. Keen observers should feel frustrated by our actions. They should say something like, “Dang, calculating the probability that these two addresses are affiliated is so complex and low-probability that it’s not meaningful for me to try to figure out which deposit is related to which withdrawal.” - -I sum our conclusions in this extremely sophisticated 2x2 matrix of behaviors: -![image](https://user-images.githubusercontent.com/15220860/174936558-a0f87f4f-dadb-4724-97b2-812a30bd99cc.png) - - -## Very. Sophisticated. - -So given what we know, how as a collective can we introduce more uncertainty into the adversary’s analysis? - -Increase the size of each deposit set, especially large deposits -“Spread out” the probability that the withdrawal could have come from any deposit set! -Simple mixers focus on #1. Let’s talk about what #2 adds. - -### Internal Transfers: The Inner Sanctum - -There is a big caveat here that differentiates our current zk.money front-end from mixers — there is a possibility that your anonymity set includes deposits that are smaller than your withdrawal amount. - -How? Because internal transfers. - -Say you withdraw 10 ETH. You could have deposited 10 ETH. - -Or you could have deposited 5 ETH, used or coordinated offchain with 5 unassociated addresses to deposit and send you 1 ETH each internally, and then in the end withdrew 10 ETH. Suddenly you could be, well, pretty much anyone, so long as two things hold: - -The amount of assets in the system is sufficient to support the hypothetical withdrawal scenario -The number of transactions in the intervening time exceeds the number needed to compose the hypothetical withdrawal scenario -So in this case, you could be some combination of internal transactions summing to 10E: - -* 10 internal 1E transfers -* 100 internal 0.1E transfers -* 1,000 internal 0.01E transfers -* Some combination of the above - -Of course, as the number of internal transfers needed to sum to a withdrawal amount increases, the less likely it actually happened — realistically, who’s going to coordinate 1,000 unaffiliated addresses to privately send them funds! - -That’s why the internal economy of Aztec matters, and why Aztec Connect — a bridge allowing anyone to interact with defi contracts on Layer 1 — will help explode the anonymity set, making it highly improbable to associate any deposits with withdrawals. - -Internal transfers muddy up anonymity set calculations, but only if there are a sufficient number of internal transfers and a large enough quantity of deposits in the system. - -## Aztec Connect: The Bridge to Infinity - -Now let’s introduce the idea of Aztec Connect, an expansion of zk.money’s functionality to include batch interactions with any Layer 1 smart contract. - -That means to begin with, any Layer 1 Defi functionality will be available to Aztec users. - -Deposit $ETH on zk.money? On a mixer, you’d have to wait for the funds to be “seasoned” before withdrawal— essentially waiting for the privacy set to grow before withdrawing funds. That’s why for instance there are billions sitting in privacy mixers. - -Using Aztec Connect, you can bridge funds back to Layer 1 and make shielded assets productive while you wait — meaning you might not want to ever withdraw! - -With a simple conventional privacy mixer, you deposit funds and simply wait — for what, you ask? For the anonymity set to grow! Meanwhile, deposited funds are completely unproductive. Capital efficiency, schmapital efficiency. - -Here are some arbitrary possible examples of using private assets while they are inside the system: - -- Staking ETH in Lido for stETH, depositing it in the stETH-ETH pool and getting double yield -- Entering into an Element.fi fixed rate yield vault -- Swapping ETH for OHM on OlympusDAO, staking for sOHM, and (3, 3)ing privately - -This is just a teaser! We’ll cover Aztec Connect in depth later in this series, but for now I want to focus on the idea that investing capital for yield on Aztec will grow the value locked in the system. - -Bridging back to Ethereum functionally has the same privacy-set-expanding benefits as having new users deposit fresh funds or having you deposit more funds, while being privacy-protected. - -This spreads out the probability distribution: - -![image](https://user-images.githubusercontent.com/15220860/174936603-8563d1dc-3404-49bc-8f6d-1ff216bf0062.png) - -And makes it less and less likely that you belong to any one given depositor set. Imagine depositing 0.1 ETH and (3, 3)ing on OlympusDAO until your OHM is worth 1 ETH! Now you’ve really thrown off the scent. - -## Purify Before Entering - -Now, what Aztec doesn’t do is protect users on mainnet, and poor security hygiene on Ethereum can hurt user privacy. - -But there’s some good news here — simply follow privacy best-practices. - -Let’s start with one of the biggest no-no’s for any privacy preservation system: withdrawing to the same address. - -**Don’t do this.** - -Why is withdrawing to the same address “bad?” In addition to reducing your own anonymity, you’re basically screwing everyone else over. You’re reducing the anonymity set by removing yourself from it, saying, “I’m taking my ball back.” - -Now there’s no way your deposit could actually be the source of anyone else’s withdrawal but your own! - -While Aztec isn’t a mixer, this analogy might help clear things up: - -Everyone chucks their balls into a giant ball pit. Now we play in the ball pit, trading balls, mixing them up, splashing around. And at the end of the day, everyone takes a ball and goes home. - -It’s unclear who brought and took home which balls, right? - -Withdrawing to the same address you deposited is akin to saying, “This is the ball I brought! It’s special because my mommy gave it to me.” Okay Jimmy, that’s fine, but imagine if everyone did that. If everyone identified themselves and their funds, it would: - -* defeat the purpose of using private transfers in the first place -* harm everyone else’s ability to blend in! - -Now consider the inverse: a large number of addresses deposit, and a large number (but not the same!) addresses withdraw. Now we’d have a very hard time associating one wallet with another. - -Critically, any transaction graph analysis on Layer 1 may be able to associate those accounts and therefore collapse many addresses. Depositing to Aztec and withdrawing to an address already associated with the depository address is akin to withdrawing to the same address. That’s why withdrawals should only happen to untouched or otherwise unaffiliated wallets. - -## Hygiene takeaways: - -* Use common deposit and withdrawal amounts -* Avoid making large deposits or large withdrawals (though large withdrawals are worse) -* Don’t withdraw to the same address you deposited to - -Remember that internal L2 transfers are always fully privacy protected and do NOT require privacy set considerations! diff --git a/docs/docs/how-aztec-works/privacy.mdx b/docs/docs/how-aztec-works/privacy.mdx deleted file mode 100644 index a6e46b544cf1..000000000000 --- a/docs/docs/how-aztec-works/privacy.mdx +++ /dev/null @@ -1,211 +0,0 @@ -# Privacy Architecture - -import Image from '@theme/IdealImage'; - -__Fully Confidential Ethereum Transactions: Aztec Network's Privacy Architecture__ - -_An overview of how Aztec preserves privacy._ - - - -[Aztec](https://aztec.network/) is a privacy-first zero-knowledge rollup on Ethereum: that means it's the only [Layer 2](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/) built from the ground up to be fully privacy preserving. - -To understand the paradigm-changing nature of private transactions and why it's important to build privacy directly into a network's architecture, we have to first discuss why Ethereum is not private. - -### Ethereum: A Public Blockchain - -You might've heard of the term public ledger, which consists of two parts: accounts and balances. - -The most primitive transaction on Ethereum is sending Ether from one account (address) to another. The way the network keeps track of this is by incrementing one account's balance and decrementing the other's — in other words, the ETH doesn't really “move” in any sense. - -Let's look at an example transaction in detail: say my man snoopdogg.eth wants to send a transaction to cozomomedici.eth. - - - -Here's how it shakes out: Snoop starts with 100 ETH and his account is debited 20 ETH. Cozomo starts with 0 ETH and his account is credited 20 ETH. Snoop's ending account balance is 80 ETH. Cozomo's is 20 ETH. Transfer complete. - - - -We can see a representation of credits and debits for each account right on etherscan.io, with the “ins” and “outs” tracked in public for everyone to see. Here's the recent transaction history for an ENS named twinkienft.eth (a name I quite like): - - - -You might be wondering: “Who's twinkienft.eth?” I don't have a clue, but I can see all their transactions! If you go to [etherscan.io](https://etherscan.io/) you can witness all transactions being written to the blockchain. - - - -*0x9dae… right on the front-page of etherscan.io!* - -You can see the obvious problem here. Not only can we see all account transactions, we can see all the amounts, assets, and counterparties. - -That's in fact the power of public blockchains! Due to their public nature they are eminently auditable and verifiable. - -But that means if someone's privacy is compromised, whether intentionally or by accident — we know their entire transaction history. - -Cracking the public transaction graph is big business: companies like [Chainalysis](https://www.chainalysis.com/) and [Nansen](https://www.nansen.ai/) run sophisticated forensic analysis to associate various wallets, monitor activity, and make probabilistic assumptions about who owns what. - -Imagine if every time you swiped a credit card to buy a croissant you showed every person in the world your bank statement. That'd be, like, pretty goofy, right? - -That's the state of Ethereum today. - -### The Obvious Answer: Encrypted Accounts -“Uhm, okay,” I hear you saying. “This is so easy to solve, just encrypt the accounts, balances, and owners.” Duh, idiot! How could I be so stupid. - -Except let's actually talk through how encrypted accounts would work: - -Recall the ledger from before. With encrypted accounts and transactions, it would instead look like this: - - - -*Useful.* - -How would the network check the accounting, ensuring no double spend or collusive funny business? It turns out solving this is pretty f-ing hard! - -Back to our businessmen Snoop & Cozomo to help us figure it out. If they need to do a transaction, they'll have to interact, since the network can't help check that they did a valid transaction. - -If it did, someone somewhere would have knowledge of what went down. Instead, Snoop initiates the interaction: - -1. Snoop requests Cozomo's encrypted account state -2. Cozomo sends the encrypted state to Snoop -3. Snoop decrypts Cozomo's state, confirming the pre-transaction balance -4. Snoop sends an encrypted payment to Cozomo -5. Cozomo sends his updated encrypted state to Snoop -6. Snoop decrypts Cozomo's new state, confirming the post-transaction balance (and that Cozomo actually got the $$ he was promised) - -This elaborate dance has serious drawbacks: it's expensive, it's time consuming, and you can only dance with one person at a time — both parties have to be online at the same time to facilitate. - -Worst of all, at the end of this dual-sided dialogue, neither party has convinced the rest of the world of anything — they've only mutually validated their one transaction. - -*Non bene.* - -### Ain't Note Fun? -But hol' up — what if we flipped the attribution structure on its head? Ethereum defaults to an account model where an account has a balance. In other words, look up the account, and you get the balance. - -What if we instead structured it to say a certain amount of money — described by a note — HAS an owner? Look up the note, and see who it belongs to. - - - -*Account has balance → note has owner.* - -This is how Bitcoin works and it's called [UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output) (unspent transaction output). But forget the terminology. Think of UTXO's as cash (bank notes). - -Let's think for a second about why cash is inherently more secure and private — or more precisely, more secure and private than account-based systems. - -Got it? It's secure because only the two parties transacting the cash know that ownership has changed hands! Everyone else in the entire universe can be kept in the dark. - -You can think of a cash transaction as **a change in ownership of an object** (the note), whereas an accounting transaction is **a change in the state of two accounts.** - - - -*What an ownership change looks like for an encrypted note, probably.* - -When an Aztec transaction processes, rather than doing an account balance update (incrementing and decrementing balance), the network simply re-assigns ownership for a given note. - -Why is this helpful? Well it turns out it's *way easier* to encrypt a note, because it really only needs two things written on it: how much it's worth, and who it's owned by. When it changes hands, you scribble out the old owner's name and write the new owner's name. *Ecco qua!* - -### Simple Transfers on Aztec -So what exactly happens in a simple note transaction? - -Say Snoop has two 50 ETH notes totaling 100 ETH and Cozomo has 0 notes. - -Snoop's two 50 ETH notes need to be destroyed, and two new notes created: an 80 ETH note that stays with Snoop, and a 20 ETH note that goes on to its new owner, Cozomo. - -But how can privacy be preserved if the values of the notes have to be revealed? - -Well — they don't! Not publicly at least. Of course, Snoop and Cozomo know the value of their transaction, just like an exchange of cash, but they don't have to reveal it to the world. - -To protect their mutual privacy, Snoop publishes the transaction with a **lock that he knows only Cozomo can unlock with his private key.** The analogy here is kind of like putting the note in a little lock box. Of course, they both know what's in the box (20 ETH), so Snoop has to trust Cozomo not to shout from the rooftop, “Someone just sent me 20 ETH!” - -But otherwise, the note that was assigned new ownership goes back into a data structure holding all the notes that were ever created — a [Merkle Tree hash](https://en.wikipedia.org/wiki/Merkle_tree), which we'll cover in brief below. - - - -*What the state of the system looks like to an observer — the values and owners of each note fully encrypted.* - -### Good Housekeeping - -We know that Snoop destroyed two notes, created two new ones, and then sent one of the two new notes to his friend Cozomo. How can we make sure the two of them don't collude to, for instance, double-spend? What if Snoop destroyed two notes worth 100 ETH in total, and created two new notes worth 200 ETH in total? Or, hell, an arbitrarily large amount? - -Recall the two steps: - -1. Snoop destroys two 50 ETH notes and creates a 20 ETH note and an 80 ETH note -2. Snoop sends the 20 ETH note to Cozomo - -To ensure nothing fishy happens in step 1, all Snoop needs to do is prove to the system (Aztec) that the two notes he intends to create are equivalent in value to the two notes he intends to destroy. - -This is known as a join-split transaction, and it conforms to this simple equivalence: __A + B = C + D.__ - -__Here comes the psycho part. Buckle up.__ - -In order to prove that the output notes (C + D) are equivalent in value to the input notes (A + B, or 100 ETH), Snoop generates a [zero-knowledge proof](https://en.wikipedia.org/wiki/Zero-knowledge_proof) (ZKP) locally, in his browser. - -The black magic of ZKPs¹ means __he can prove the equivalence A + B = C + D without revealing any of their individual values.__ - -Aztec then validates the proof and says, “By the powers of Zero Knowledge, this must be true,” at which point the smart contract destroys the two input notes, generates the two output notes, and records the new output notes as an encrypted commitment in the note registry. - -### Proving Ownership - -It's worth discussing how ownership of notes is proven in Aztec, which has analogies to Ethereum-world. How do you prove you control access to an address in Ethereum? You sign a message using your wallet. - -How do you prove you control access to a note in Aztec? With a very very fancy cryptographic signature called a zero knowledge proof. - -The proof says, “Somewhere in Aztec's state, there: a) exists a note with a certain value, and b) I own it.” - -And how's the state of the Aztec system stored? In two [Merkle Trees](https://en.wikipedia.org/wiki/Merkle_tree): - -- A note tree, containing all the notes that have ever been created; and -- A nullifier tree, containing all the notes that have ever been destroyed - -Saying you own a note indicates to Aztec that the note exists in the note tree, and that no corresponding note-nullifier exists in the nullifier tree. - -When we talk about “destroying” a note, that actually means _adding_ a nullifier to the nullifier tree rather than deleting a note from the note tree. - - - -_A humble Merkle Tree._ - -In order to send notes that I've proven I own, an entirely new Merkle tree (and Merkle root) is created. Once the Merkle roots of both the note tree and nullifier tree have moved to new values — in other words, the state of the system has been updated — those roots are published (settled) on Ethereum's main chain and the transactions are deemed recorded. - -### Face Down, Bottom's Up - -I hope this gives you a solid grounding for understanding why privacy is challenging: we need to __verify__ that transactions are legitimate and properly executed without __violating__ or exposing user data. - -These unique constraints mean privacy-preserving architecture must be constructed from the ground up. Aztec is the only L2 built this way — with privacy protected by its core architecture and facilitated by the magic of zero knowledge. *Grazie mille!* - -Notes - -1. Want to a basic primer on zero-knowledge proofs? Check out [this helpful YouTube video](https://www.youtube.com/watch?v=0Sy6nb72gCk), [this illustrated primer](https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/) or Packy McCormick's [piece on the magic of ZK's](https://www.notboring.co/p/zero-knowledge). - -This article was originally published on Medium [here](https://medium.com/aztec-protocol/fully-confidential-ethereum-transactions-aztec-networks-privacy-architecture-274f968b13d4). - -## Frequenty Asked Questions - -### What are 'private transactions'? - -Transactions within the Aztec rollup are hidden from observers and the Aztec rollup provider. Both the identities of sender/recipient and the values transferred are encrypted. - - - ---- - -### Are deposits private? - -When you deposit into our rollup, people can see the Eth address you deposited from, and how much you deposited. They cannot see the identity of the Aztec address you deposited into. - ---- - -### Are withdrawals private? - -When you withdraw to a regular ETH address, the address you withdrew to is shown on the block explorer. Using this data, the withdrawn amount can be traced. - - - -These 6 characters are the last 6 characters of the withdrawal address - -**For privacy, you need to withdraw to a different Ethereum address.** Use a different address than the one you fund or register zk.money username with. - ---- - -### What information about my transaction will be shown on explorer like Etherscan? - -It will show the funds were sent from an “Aztec Contract / Private Rollup”. diff --git a/docs/docs/how-aztec-works/scalability.mdx b/docs/docs/how-aztec-works/scalability.mdx deleted file mode 100644 index f6d42cb37442..000000000000 --- a/docs/docs/how-aztec-works/scalability.mdx +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Scalability ---- -import Image from '@theme/IdealImage'; - -Our goal at Aztec is to make privacy a no-brainer. That's why our rollup is designed to give you fully private Ethereum transactions at dramatically lower cost than mainnet. - -We consider privacy a critical missing component of Ethereum's scalability roadmap, given that its user functionality is non-economic in nature. - -But privacy must also be affordable, and in order to understand how we'll get to privacy for cheap, we need to do a deeper study of rollup economics. - -## 📖 Background on Ethereum scaling - -You might already be familiar with the difference between the two consensus Ethereum scaling solutions: Optimistic Rollups (ORUs) and zkRollups (ZKRs). I'll let Vitalik explain [here](https://vitalik.ca/general/2021/01/05/rollup.html). - -But in case you want my take, here's the basic trade-off between Optimistic Rollups and zkRollups: - -## 😅 Optimistic - -Optimistic rollup block producers post an Ethereum transaction containing a state root. The ecosystem “optimistically” takes the state of the system to be valid. - -During a 7 day challenge period, anyone can prove the invalidity of the state transition by downloading the block of transactions and comparing the previous Merkle root state to the new Merkle root state. - -If there is an invalid state transition, they can submit a fraud proof, causing the block producer to be slashed and the blockchain state to be rolled back to its original state. - -Note that the cost of executing transactions with an optimistic rollup is very close to free, since it's essentially the cost of computation as done by a single sequencer (just like, a computer somewhere). However, there is still a variable cost of posting data to Ethereum. - -## ⚫ Zero-knowledge - -In a zero-knowledge rollup, the rollup incurs a significant fixed cost. Rather than passively awaiting fraud proofs, ZKRs proactively post a succinct zero knowledge proof to Ethereum Layer 1 validating a set of off-chain computations (a “validity proof”). - -While the security of off-chain transactions in a zkRollup is unimpeachable due to the deterministic nature of zero knowledge proofs, there must be sufficiently high transaction throughput to amortize the cost of posting the proof to Ethereum. - -Tl;dr: - -- **Optimistic:** no fixed costs, finality delayed by 7 day challenge & withdrawal period; in case of fraud, blockchain state gets rolled back -- **zk:** high fixed costs, finality limited by speed of rollup, no challenge or withdrawal period, no possible fraud (caveat: as long as the cryptography works as intended) - -## 🧮 Simple rollup math - -Aztec, of course is a zero-knowledge rollup. (In fact, it's a recursive zk-rollup–a zk-zk-rollup, but we'll get to that). - -That means it does incur the fixed cost of posting a SNARK-based proof to Ethereum. But it also means it's highly scalable. - -## 📈 Scalability - -What do we mean by scalability? In a blockchain context, **scalability means the marginal cost of transactions goes down with each incremental transaction.** The faster the marginal cost falls, the more scalable something is. - -In terms of cost, optimistic rollups have no fixed expense, but over a large enough number of transactions, zkRollups quickly overcome their fixed cost disadvantage and win over optimistic roll-ups with superior data compression. - -So: zkRollups are more scalable. - -Now, if you think about most Layer 1's, including Ethereum, they're anti-scalable. The more transactions go through Ethereum, the higher the cost of each marginal transaction. - -## ➗ zkRollups for kids -Here's a school child's diagram of the scalability equation for Aztec and other zkRollups: - - - -Hopefully this gives you a picture of how Aztec's path to scaling our own rollup: - -- Reduce the cost of posting a rollup (we control this) -- Increase the number of transactions per rollup (we mostly control this) -- Lower the per-transaction cost of posting call data (we don't control this for Ethereum, but we can select a lower-cost data availability solution) - -Let's tackle these one by one, compare the current system relative to performance a year ago, and discuss what they mean for future network performance. - -## 💸 Cost of posting rollups -In Aztec's current technological paradigm, an improvement of our proving system called UltraPlonk, the cost of posting a proof to Ethereum is approximately 550,000 gas, ~30% cheaper than it was when [zk.money](https://zk.money) was first launched. - -We anticipate this coming down to ~180,000 gas with the advent of our next-generation proving system, [super secret code name redacted]. - -## 🚌 Transactions per rollup -Our current system was recently upgraded from 112 transactions per rollup at zk.money's launch to 896 transactions per rollup, an improvement in throughput of 8x. - -The way Aztec worked under the hood prior to this most recent upgrade is: - -- A proof is generated client-side in-browser -- 28 client proofs are then aggregated into an “inner” rollup proof -- 4 inner rollup proofs are then aggregated into an “outer” rollup proof - -That “outer” rollup proof is then verified in what we call the root rollup circuit — the circuit that establishes the validity of all the underlying work that goes into ensuring execution on Aztec happened as expected. Then that final proof gets posted on-chain for posterity. - -It's proofs on proofs on proofs. - - - -For the release of Aztec Connect SDK, we've increased the outer rollup's capacity to 32 inner proofs by optimizing the outer rollup circuit. 28 * 32 = 896. Magic. - -That's why we go through all this headache, writing circuits that can efficiently verify recursive Plonk proofs. - -If you're following so far, the share of rollup costs per transaction fell from: - -- 750k / 112 = 6,700 gas; to -- 550k / 896 = 614 gas → an 11x improvement! - -We think that's well worth inventing novel forms of cryptography. - -## ☎ Per-txn cost of call data -In addition to the proof, which validates Aztec's off-chain transactions, Aztec also has to post call data¹ for each transaction, such that anyone can reconstruct the state of Aztec's rollup and prove the validity of off-chain computation. - -Currently, the cost of posting call data to Ethereum is 16 gas per byte. Vitalik has submitted [EIP-4488](https://eips.ethereum.org/EIPS/eip-4488) lowering the cost of call data to 3 gas per byte, while there's another proposal, confusingly named [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), which offers a new data format specifically designed to lower the cost to rollups of posting data on Ethereum. - -Aztec broadly supports efforts to reduce the cost of data on Ethereum, and we'll discuss the minutiae of the two EIPs in a separate post. - -For now, it's true for our architecture that scaling costs beyond a few hundred transactions asymptotically approach the cost of call data. ([reference](https://twitter.com/adeets_22/status/1485671418687803394)) - -Note that the chain on which Aztec posts call data is critical for security, because data availability is of chief concern in case Aztec's rollup provider ceases to function and system state needs to be reconstructed once the provider comes back online. - -Note that while a rollup provider going down can only freeze users' funds in place, with no ability to steal funds, recomputing blockchain state can only happen if state is available (hence data availability). - -That's why for the foreseeable future, we intend to post the rollup's state to Ethereum–it is for now the Lindy-est, most secure chain with consistent and proven uptime. We're also excited about exploring our own first-party offchain data availability solution and 3rd-party chains like Celestia. - -For now, an Aztec transaction requires the storage of a number of items on-chain: - -- Transaction viewing keys (8,480 gas)² -- Join-split call data (2,064 gas)³ -- For DeFi transactions, call data for deposit and claim (2,064 * 2)⁴ -- Total: 14,672 gas - -## 🕔 Recap & what the future holds -Aztec's zkRollup has scaled efficiently since the launch of zk.money on mainnet. The impending launch of the Aztec Connect SDK brings up to 100x cost savings for Ethereum DeFi services, all while offering full privacy. - -The cost of a private transaction on Aztec will always be cheaper than the cost of a public transaction on Ethereum, despite the added complexity of encrypted transactions — you always get privacy for free (or better than free). - -The one elephant in the room is data cost on Ethereum. Call data represents the vast majority (88.8%) of the gas cost for a DeFi transaction. And over time, as proof verification costs fall and the rollup scales further, call data will represent nearly 100% of transaction costs. - -At that point, scaling Aztec will also mean optimizing Ethereum. - -Notes: - -1. Call data is currently the cheapest form of data storage on Ethereum. It’s a special form of memory used to store function parameters (hence “call” data, because it’s used to call external functions). -2. Viewing keys are required to view encrypted transactions and read the details of a transaction. Unlike state, they’re not critical for system liveness. -3. The join-split circuit is a simple formula that ensures Aztec encrypted notes are added (joined) and divided (split) correctly. It follows the simple equivalence (a + b) = (c + d). -4. The DeFi circuit ensures assets are correctly delivered to the Aztec Rollup (deposited) and returned from the Aztec Rollup (withdrawn). \ No newline at end of file diff --git a/docs/docs/how-aztec-works/talks-videos.md b/docs/docs/how-aztec-works/talks-videos.md deleted file mode 100644 index e3e639bb23af..000000000000 --- a/docs/docs/how-aztec-works/talks-videos.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Talks and Videos ---- - -Talks and Videos from the Aztec community. - -- [Is there still a bull case for privacy? - The Blockcrunch Podcast](https://www.youtube.com/watch?v=OzMeCFUSass) -- Bankless [Aztec - Joe Andrews (CPO) and Zac Williamson (CTO)](https://www.youtube.com/watch?v=NyBwdcIMT0M) -- Epicenter [Tom Pocock & Zac Williamson: AZTEC Protocol – Bringing Zero-Knowledge Transactions to Ethereum](https://podcasts.apple.com/us/podcast/tom-pocock-zac-williamson-aztec-protocol-bringing-zero/id792338939?i=1000471465052) -- Epicenter [Joe Andrews & Zac Williamson: Aztec Protocol – Bringing Scalable Privacy to DeFi](https://podcasts.apple.com/dk/podcast/joe-andrews-zac-williamson-aztec-protocol-bringing/id792338939?i=1000532298424&l=fr) -- ETHGlobal ["Aztec 2.0 - A new layer 2 built with privacy at its core" - Joe Andrews](https://www.youtube.com/watch?v=ksmJahvYKSc) -- Zero Knowledge Podcast [Episode 75: Exploring Aztec with Zac Williamson](https://zeroknowledge.fm/75-2/) -- [How Plookup is used for sha256](https://www.youtube.com/watch?v=nz_VdPbCT64&t=906s&ab_channel=DystopiaLabs) -- [ZK HACK #5 - Introduction to Aztec Connect](https://www.youtube.com/watch?v=Cs9cI2v1hdE#t=1m36s&ab_channel=ZeroKnowledge) -- [Privacy on blockchains and future of rollups | Joe from Aztec](https://www.youtube.com/watch?v=3ZxyHTlkH9E) Feb 11, 2022 on [DeFi 2.71](https://www.youtube.com/channel/UC9nRBkM8vq1y7_0jNbfLQaw) diff --git a/docs/docs/how-aztec-works/tokens.md b/docs/docs/how-aztec-works/tokens.md deleted file mode 100644 index 08d51b317197..000000000000 --- a/docs/docs/how-aztec-works/tokens.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Tokens ---- - -## Frequently Asked Questions -### What is zkETH/zkDAI? - -zkETH is a shielded ETH token, which has a zkSNARK layer that protects its transaction data. zkETH has the same behaviour as regular ETH, and users can send it to any Ethereum address from zk.money. The same concept applies to other assets on the platform. - ---- - -### Which tokens are supported on zk.money? - -Currently, ETH, DAI and renBTC are supported. We will be adding more tokens to the platform. - ---- - -### Does Aztec have a token? - -We think it's important to build an amazing product before we think about building in a token economics. Decentralization is a key part of our roadmap, but in the short term we are just focusing on the product and expanding zk.money to work with private DeFi, so are not currently thinking about a token. \ No newline at end of file diff --git a/docs/docs/introduction.md b/docs/docs/introduction.md index 8384ea1ef2da..1f0bf4218212 100644 --- a/docs/docs/introduction.md +++ b/docs/docs/introduction.md @@ -1,36 +1,97 @@ --- id: intro title: Introduction -slug: '/' +slug: "/" --- -[Aztec Network](https://aztec.network/) is the first private [ZK-rollup](https://ethereum.org/en/developers/docs/scaling/zk-rollups/) on [Ethereum](https://ethereum.org/), enabling decentralized applications to access privacy and scale. Aztec’s rollup is secured by its industry-standard [PLONK](https://cryptocurrencywiki.org/PLONK) proving mechanism used by the leading zero-knowledge scaling projects. +[Aztec Network](https://aztec.network/) is building the first private, programmable [ZK-rollup](https://ethereum.org/en/developers/docs/scaling/zk-rollups/) on [Ethereum](https://ethereum.org/), enabling decentralized applications to access privacy and scale. At Aztec we believe decentralization is premised on individual rights. Without widely accessible privacy, we compromise our ability to choose how we live our lives and earn our livelihoods. That’s why we’re building Aztec Network to deliver privacy without compromise: -- __Private.__ Aztec is the only zero-knowledge rollup built with a privacy-first architecture from the ground up, allowing users to access their favorite apps on Layer 1 completely privately. -- __Accessible.__ Proving Aztec transaction validity through zero-knowledge proofs on Ethereum reduces transaction costs by up to 100x. -- __Compliant.__ Our programmably private system supports opt-in auditability and compliance while fully preserving confidentiality. +- **Private.** Aztec is the only zero-knowledge rollup built with a privacy-first architecture from the ground up, allowing developers to build privacy preserving applications on the Aztec rollup with the option to integrate favorite apps on Ethereum, completely privately. +- **Accessible.** Proving Aztec transaction validity through zero-knowledge proofs on Ethereum significantly reduces transaction costs. +- **Compliant.** Our programmable, private system supports opt-in auditability and compliance while fully preserving confidentiality and maintaining credible neutrality at the protocol layer. > “When we started Aztec, the technology to scale blockchains privately didn’t exist. Since then, we’ve assembled a team of world-class cryptographers who continuously redefine the state-of-the-art. Inventing PLONK — the paradigm-defining universal zk-SNARK — showcases our ability to produce technology that matches our ambitions: unlocking an entire universe of blockchain applications that couldn’t exist without privacy.” _- Zac Williamson, CEO and Cofounder, Aztec_ -## Zk.money +To realize our vision, we are pioneering the next generation of privacy preserving zk roll-ups by building Aztec 3. -Our first product is [zk.money](https://zk.money), a private transfer protocol built on Aztec. Since launch, zk.money has had over 75,000 registered users, 225,000+ transactions, and over $80 million in total transactions, all while being 96% cheaper than existing private transfer protocols. +## Aztec 3 -You can view some of the latest statistics on the [block explorer](https://aztec-connect-prod-explorer.aztec.network/) and on [Dune Analytics](https://dune.com/flashback/Aztec-2). +What is Aztec 3? -## Aztec Connect +First, some context. A public blockchain utilizes a peer-to-peer network and a consensus protocol to establish the correct record of events, and records this on a shared ledger. Nodes are penalized for lying, and correctness is enforced by other nodes "checking" the work of the current node as the data is public. Ethereum is an example of this, specifically an example that enables the processing of transactions with arbitrary, Turing complete computation. -Aztec Connect is a VPN-like privacy tool for Ethereum’s decentralized finance ecosystem. It allows users to confidentially access world-class DeFi services on Ethereum with up to 100x cost savings, all while strengthening Aztec’s existing privacy guarantees. +Aztec 3 is an encrypted blockchain, where the core unit of a transaction is a zero-knowledge proof that proves the correctness of a specific transaction. -At launch, Aztec Connect extends the capabilities of zk.money, adding functionality from blue-chip DeFi partners. The Aztec SDK allows any Ethereum project to permissionlessly integrate Aztec, unlocking instant privacy and cost-savings. +The Aztec peer-to-peer network receives these proofs, and an Aztec network [sequencer](./glossary#sequencer) assembles these proofs into a block. They compute a final aggregation zero-knowledge proof with the help of a distributed prover network which prove the correctness of the set of transactions which make up a block. For a transaction to be accepted by the network, it must be provably correct. It is not possible for invalid proofs to be accepted by the network. -Aztec Connect accomplishes the above while maintaining two significant advantages over other scaling solutions: +The aggregation proof is sent to a smart contract on Ethereum for validation. If the proofs are verified as correct by the smart contract, it will record the new state of the Aztec blockchain as a ledger entry on Ethereum. -- No redeployment of core contracts. Developers write a simple 50–100 line interface connecting Aztec Network Layer 1 smart contracts. -- Preservation of Layer 1 liquidity. Users interact directly with Layer 1 liquidity, reducing fragmentation and liquidity leakage to Layer 2. +Updates to this state can only occur based on proving the correct execution of a block of Aztec transactions. This allows Aztec 3 to rely on Ethereum's consensus for the correct record of events.The Aztec execution environment can be thought of as an extension of Ethereum, but where a subset of transactions can be encrypted. -Read more about Aztec Connect [here](./how-aztec-works/aztec-connect). +```mermaid +flowchart BT + + + subgraph Ethereum Mainnet + + direction BT + subgraph Smart Contracts + direction LR + RollupContract + Uniswap + Aave + + + end + + + subgraph Block + EthereumTX --> RollupContract + EthereumTx2 + EthereumTx3 + EthereumTx4 + EthereumTx5 + + end + subgraph Consensus Layer + direction LR + Node2 --> Block + end + end + subgraph Aztec + direction TB + subgraph Aztec Tx Pool + direction LR + zkProofTx + zkProofTx2 + end + + subgraph Aggregation Layer + direction BT + zkProofTx2 --> Sequencer + zkProofTx --> Sequencer + + Sequencer --> AztecBlock + Prover1 --> AztecBlock + Prover2--> AztecBlock + Prover3--> AztecBlock + + + + + end + subgraph Ethereum Tx + direction TB + AztecBlock --> RollupProof + RollupProof --> Node2 + + end + + end +``` + +Read more about Aztec 3 [here](./aztec3). diff --git a/docs/docs/developers/noir.md b/docs/docs/noir.md similarity index 100% rename from docs/docs/developers/noir.md rename to docs/docs/noir.md diff --git a/docs/docs/sdk/overview.md b/docs/docs/sdk/overview.md deleted file mode 100644 index 76721d5ad28f..000000000000 --- a/docs/docs/sdk/overview.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: SDK Overview ---- - -The Aztec SDK is the gateway for developers to access the Aztec network and benefit from low gas fees and privacy on Ethereum. The SDK connects to Ethereum and an Aztec client and can be integrated with a few lines of code. - -The SDK is designed to abstract away the complexities of zero-knowledge proofs from the developer and end users. It provides a simple API for creating accounts, depositing and withdrawing tokens and interacting with Ethereum smart contracts anonymously. Aztec native transfers with the SDK are private by default. - -Under the hood the SDK keeps track of a users private balances across multiples assets and provides easy to use helper methods to the developer to create seamless private UI's. - -The SDK is written in Typescript and requires a Javascript context (web browser, web view or Node.js). This makes it well suited for developing web interfaces for maximum accessibility. - -## What can you do with the SDK? - -The Aztec SDK has many capabilities, many of which are associated with the following user actions: - -- Connect to the Aztec network -- Add accounts to decrypt notes and show balances -- Register new accounts -- Handle signing keys to spend notes or withdraw assets to Ethereum -- Query Aztec transaction fees and specify settlement time -- Lookup user aliases associated with spending account to make transferring assets easier -- Migrate accounts to a new public key -- Recover accounts for which a spending key was lost -- Initiate interactions with smart contracts on Ethereum (i.e. defi deposits, token swaps, or unique interactions with custom [bridge contracts](https://github.com/AztecProtocol/aztec-connect-bridges)) - -## Controllers - -Most of the above capabilities are possible through the use of `Controllers`. Controllers make it easy to prompt users for relevant transactions when an action requires an Ethereum transaction or signature and create proofs or send transactions to the Aztec network. - -For example, the `RegisterController` is used for registering accounts, the `DepositController` for sending Ether or tokens to an Aztec account from an Ethereum account and the `TransferController` for spending notes within the Aztec network. - -## Accounts - -Aztec accounts may have two or more associated private keys. A new Aztec account should register a unique spending key before handling funds. Please review the [account overview page](../how-aztec-works/accounts) for a high level overview or dig into the code in the [Add Accounts to the SDK page](./usage/add-account). - -## Transaction Fee Payers - -Aztec allows the account is paying transaction fees for a transaction to be different than the account that is sending assets. You can read more about how to use this functionality on the [Fee Controller page](./usage/feecontroller). - -## SDK Flavours - -The SDK comes in 3 flavours. The users environment will typically automatically determine which flavour is used, but it is good to be aware of them because they do have tradeoffs. - -In [zk.money](https://zk.money), the SDK is set up as `PLAIN`. - -### Plain - -`PLAIN` is used with a node backend or gets used in the iframe if shared workers are not supported in the execution context. - -### Shared worker - -An application can make the SDK available to users via `SHARED_WORKER` if the SDK at the `HOSTED` endpoint is unavailable. - -This option is preferred over `PLAIN` because it allows similar work to be shared. For example, if you were using `PLAIN` in multiple tabs, each tab would be doing the same work. The `SHARED_WORKER` is more efficient in terms of networking and storage. - -### Hosted - -`HOSTED` does everything that the `SHARED_WORKER` does plus more, except in the case that your browser does not support shared workers. You can check shared worker browser compatibility [here](https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker#browser_compatibility). - -The `HOSTED` flavour is dependent on being able to access the SDK via a URL endpoint. The endpoint is `https://sdk.aztec.network`, where the Aztec team hosts an instance of the SDK. - -When accessing the SDK via this method, users are trusting the provider at that URL with proper management of their Aztec keys within their browsers. The host also chooses which rollup provider the SDK talks to (ie mainnet vs a testnet). - -This flavor needs more testing before it is considered production grade. diff --git a/docs/docs/sdk/types/1_overview.md b/docs/docs/sdk/types/1_overview.md deleted file mode 100644 index ff3c7d6696f4..000000000000 --- a/docs/docs/sdk/types/1_overview.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Overview ---- - -This section includes an incomplete list of the types, interfaces and classes that are defined in the SDK. - -I included the ones that I've used the most or that are referenced elsewhere in these docs. diff --git a/docs/docs/sdk/types/_category_.json b/docs/docs/sdk/types/_category_.json deleted file mode 100644 index 2abc1fe2a1a7..000000000000 --- a/docs/docs/sdk/types/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Types, Classes, Interfaces", - "collapsible": true, - "collapsed": true, - "link": { - "type": "generated-index" - } - } \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/AssetValue.md b/docs/docs/sdk/types/barretenberg/AssetValue.md deleted file mode 100644 index 8d5276d551eb..000000000000 --- a/docs/docs/sdk/types/barretenberg/AssetValue.md +++ /dev/null @@ -1,6 +0,0 @@ -```ts -interface AssetValue { - assetId: number; - value: bigint; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/BridgeCallData.md b/docs/docs/sdk/types/barretenberg/BridgeCallData.md deleted file mode 100644 index 891b55ab9266..000000000000 --- a/docs/docs/sdk/types/barretenberg/BridgeCallData.md +++ /dev/null @@ -1,31 +0,0 @@ -```ts -import { BitConfig } from './bit_config'; -export declare class BridgeCallData { - readonly bridgeAddressId: number; - readonly inputAssetIdA: number; - readonly outputAssetIdA: number; - readonly inputAssetIdB?: number | undefined; - readonly outputAssetIdB?: number | undefined; - readonly auxData: number; - static ZERO: BridgeCallData; - static ENCODED_LENGTH_IN_BYTES: number; - readonly bitConfig: BitConfig; - constructor(bridgeAddressId: number, inputAssetIdA: number, outputAssetIdA: number, inputAssetIdB?: number | undefined, outputAssetIdB?: number | undefined, auxData?: number); - static random(): BridgeCallData; - static fromBigInt(val: bigint): BridgeCallData; - static fromBuffer(buf: Buffer): BridgeCallData; - static fromString(str: string): BridgeCallData; - get firstInputVirtual(): boolean; - get secondInputVirtual(): boolean; - get firstOutputVirtual(): boolean; - get secondOutputVirtual(): boolean; - get secondInputInUse(): boolean; - get secondOutputInUse(): boolean; - get numInputAssets(): 1 | 2; - get numOutputAssets(): 1 | 2; - toBigInt(): bigint; - toBuffer(): Buffer; - toString(): string; - equals(id: BridgeCallData): boolean; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/DefiSettlementTime.md b/docs/docs/sdk/types/barretenberg/DefiSettlementTime.md deleted file mode 100644 index 487f7afae2f2..000000000000 --- a/docs/docs/sdk/types/barretenberg/DefiSettlementTime.md +++ /dev/null @@ -1,7 +0,0 @@ -```ts -enum DefiSettlementTime { - DEADLINE = 0, - NEXT_ROLLUP = 1, - INSTANT = 2 -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/EthAddress.md b/docs/docs/sdk/types/barretenberg/EthAddress.md deleted file mode 100644 index 9f6976200a79..000000000000 --- a/docs/docs/sdk/types/barretenberg/EthAddress.md +++ /dev/null @@ -1,19 +0,0 @@ -```ts -export interface EthAddress { - isZero(): boolean; - equals(rhs: EthAddress): boolean; - toString(): string; - toBuffer(): Buffer; - toBuffer32(): Buffer; -} -export declare class EthAddress { - private buffer; - static ZERO: EthAddress; - constructor(buffer: Buffer); - static fromString(address: string): EthAddress; - static random(): EthAddress; - static isAddress(address: string): boolean; - static checkAddressChecksum(address: string): boolean; - static toChecksumAddress(address: string): string; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/EthereumProvider.md b/docs/docs/sdk/types/barretenberg/EthereumProvider.md deleted file mode 100644 index f1e99f51c4f0..000000000000 --- a/docs/docs/sdk/types/barretenberg/EthereumProvider.md +++ /dev/null @@ -1,15 +0,0 @@ -```ts -interface EthereumProvider { - request(args: RequestArguments): Promise; - on(notification: 'connect', listener: (connectInfo: ProviderConnectInfo) => void): this; - on(notification: 'disconnect', listener: (error: ProviderRpcError) => void): this; - on(notification: 'chainChanged', listener: (chainId: string) => void): this; - on(notification: 'accountsChanged', listener: (accounts: string[]) => void): this; - on(notification: 'message', listener: (message: ProviderMessage) => void): this; - removeListener(notification: 'connect', listener: (connectInfo: ProviderConnectInfo) => void): this; - removeListener(notification: 'disconnect', listener: (error: ProviderRpcError) => void): this; - removeListener(notification: 'chainChanged', listener: (chainId: string) => void): this; - removeListener(notification: 'accountsChanged', listener: (accounts: string[]) => void): this; - removeListener(notification: 'message', listener: (message: ProviderMessage) => void): this; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/GrumpkinAddress.md b/docs/docs/sdk/types/barretenberg/GrumpkinAddress.md deleted file mode 100644 index fe0af18a9598..000000000000 --- a/docs/docs/sdk/types/barretenberg/GrumpkinAddress.md +++ /dev/null @@ -1,24 +0,0 @@ -```ts -class GrumpkinAddress { - private buffer; - static SIZE: number; - static ZERO: GrumpkinAddress; - constructor(buffer: Buffer); - static isAddress(address: string): boolean; - static fromString(address: string): GrumpkinAddress; - /** - * NOT a valid address! Do not use in proofs. - */ - static random(): GrumpkinAddress; - /** - * A valid address (is a point on the curve). - */ - static one(): GrumpkinAddress; - equals(rhs: GrumpkinAddress): boolean; - toBuffer(): Buffer; - x(): Buffer; - y(): Buffer; - toString(): string; - toShortString(): string; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/RollupProvider.md b/docs/docs/sdk/types/barretenberg/RollupProvider.md deleted file mode 100644 index d762c2e6bf74..000000000000 --- a/docs/docs/sdk/types/barretenberg/RollupProvider.md +++ /dev/null @@ -1,16 +0,0 @@ -```ts -interface RollupProvider extends BlockSource { - sendTxs(txs: Tx[]): Promise; - getStatus(): Promise; - getTxFees(assetId: number): Promise; - getDefiFees(bridgeId: BridgeId): Promise; - getPendingTxs(): Promise; - getPendingNoteNullifiers(): Promise; - getPendingDepositTxs(): Promise; - clientLog(msg: any): Promise; - getInitialWorldState(): Promise; - isAccountRegistered(accountPublicKey: GrumpkinAddress): Promise; - isAliasRegistered(alias: string): Promise; - isAliasRegisteredToAccount(accountPublicKey: GrumpkinAddress, alias: string): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/SchnorrSignature.md b/docs/docs/sdk/types/barretenberg/SchnorrSignature.md deleted file mode 100644 index 29434cafe4fb..000000000000 --- a/docs/docs/sdk/types/barretenberg/SchnorrSignature.md +++ /dev/null @@ -1,14 +0,0 @@ -```ts -class SchnorrSignature { - private buffer; - static SIZE: number; - constructor(buffer: Buffer); - static isSignature(signature: string): boolean; - static fromString(signature: string): SchnorrSignature; - static randomSignature(): SchnorrSignature; - s(): Buffer; - e(): Buffer; - toBuffer(): Buffer; - toString(): string; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/TxId.md b/docs/docs/sdk/types/barretenberg/TxId.md deleted file mode 100644 index 647031d97031..000000000000 --- a/docs/docs/sdk/types/barretenberg/TxId.md +++ /dev/null @@ -1,16 +0,0 @@ -```ts -class TxId { - private buffer; - constructor(buffer: Buffer); - static deserialize(buffer: Buffer, offset: number): { - elem: TxId; - adv: number; - }; - static fromString(hash: string): TxId; - static random(): TxId; - equals(rhs: TxId): boolean; - toBuffer(): Buffer; - toString(): string; - toDepositSigningData(): Buffer; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/barretenberg/TxSettlementTime.md b/docs/docs/sdk/types/barretenberg/TxSettlementTime.md deleted file mode 100644 index a759e93444e9..000000000000 --- a/docs/docs/sdk/types/barretenberg/TxSettlementTime.md +++ /dev/null @@ -1,6 +0,0 @@ -```ts -enum TxSettlementTime { - NEXT_ROLLUP = 0, - INSTANT = 1 -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/bridge-clients/BridgeData.md b/docs/docs/sdk/types/bridge-clients/BridgeData.md deleted file mode 100644 index 83a3a1dab2b2..000000000000 --- a/docs/docs/sdk/types/bridge-clients/BridgeData.md +++ /dev/null @@ -1,45 +0,0 @@ -```ts -export interface AssetValue { - assetId: bigint; - amount: bigint; -} -export declare enum AztecAssetType { - ETH = 0, - ERC20 = 1, - VIRTUAL = 2, - NOT_USED = 3 -} -export declare enum SolidityType { - uint8 = 0, - uint16 = 1, - uint24 = 2, - uint32 = 3, - uint64 = 4, - boolean = 5, - string = 6, - bytes = 7 -} -export interface AztecAsset { - id: bigint; - assetType: AztecAssetType; - erc20Address: string; -} -export interface AuxDataConfig { - start: number; - length: number; - description: string; - solidityType: SolidityType; -} -export interface BridgeDataFieldGetters { - getInteractionPresentValue?(interactionNonce: bigint): Promise; - getAuxData?(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset): Promise; - auxDataConfig: AuxDataConfig[]; - getExpectedOutput(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, inputValue: bigint): Promise; - getExpiration?(interactionNonce: bigint): Promise; - hasFinalised?(interactionNonce: bigint): Promise; - getExpectedYield?(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, inputValue: bigint): Promise; - getMarketSize?(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint): Promise; - getCurrentYield?(interactionNonce: bigint): Promise; - lPAuxData?(data: bigint[]): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/bridge-clients/ElementBridgeData.md b/docs/docs/sdk/types/bridge-clients/ElementBridgeData.md deleted file mode 100644 index ba725a801498..000000000000 --- a/docs/docs/sdk/types/bridge-clients/ElementBridgeData.md +++ /dev/null @@ -1,44 +0,0 @@ -```ts -export declare type BatchSwapStep = { - poolId: string; - assetInIndex: number; - assetOutIndex: number; - amount: string; - userData: string; -}; -export declare enum SwapType { - SwapExactIn = 0, - SwapExactOut = 1 -} -export declare type FundManagement = { - sender: string; - recipient: string; - fromInternalBalance: boolean; - toInternalBalance: boolean; -}; -export declare type ChainProperties = { - eventBatchSize: number; -}; -export declare class ElementBridgeData implements BridgeDataFieldGetters { - private elementBridgeContract; - private balancerContract; - private rollupContract; - private chainProperties; - scalingFactor: bigint; - private interactionBlockNumbers; - private constructor(); - static create(provider: EthereumProvider, elementBridgeAddress: EthAddress, balancerAddress: EthAddress, rollupContractAddress: EthAddress, chainProperties?: ChainProperties): ElementBridgeData; - private storeEventBlocks; - private getCurrentBlock; - private findDefiEventForNonce; - getInteractionPresentValue(interactionNonce: bigint): Promise; - getCurrentYield(interactionNonce: bigint): Promise; - getAuxData(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset): Promise; - auxDataConfig: AuxDataConfig[]; - getExpectedOutput(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, precision: bigint): Promise; - getExpectedYield(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, precision: bigint): Promise; - getMarketSize(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint): Promise; - getExpiration(interactionNonce: bigint): Promise; - hasFinalised(interactionNonce: bigint): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/bridge-clients/LidoBridgeData.md b/docs/docs/sdk/types/bridge-clients/LidoBridgeData.md deleted file mode 100644 index 6cdad1e41db0..000000000000 --- a/docs/docs/sdk/types/bridge-clients/LidoBridgeData.md +++ /dev/null @@ -1,18 +0,0 @@ -```ts -import { AssetValue, AuxDataConfig, AztecAsset, BridgeDataFieldGetters } from "../bridge-data"; -import { EthereumProvider } from "@aztec/barretenberg/blockchain"; -import { EthAddress } from "@aztec/barretenberg/address"; -export declare class LidoBridgeData implements BridgeDataFieldGetters { - private wstETHContract; - private lidoOracleContract; - private curvePoolContract; - scalingFactor: bigint; - private constructor(); - static create(provider: EthereumProvider, wstEthAddress: EthAddress, lidoOracleAddress: EthAddress, curvePoolAddress: EthAddress): LidoBridgeData; - auxDataConfig: AuxDataConfig[]; - getInteractionPresentValue(interactionNonce: bigint): Promise; - getAuxData(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset): Promise; - getExpectedOutput(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, inputValue: bigint): Promise; - getExpectedYield(inputAssetA: AztecAsset, inputAssetB: AztecAsset, outputAssetA: AztecAsset, outputAssetB: AztecAsset, auxData: bigint, precision: bigint): Promise; - getMarketS -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/AddSpendingKeyController.md b/docs/docs/sdk/types/sdk/AddSpendingKeyController.md deleted file mode 100644 index 06839cac3b2c..000000000000 --- a/docs/docs/sdk/types/sdk/AddSpendingKeyController.md +++ /dev/null @@ -1,19 +0,0 @@ -```ts -export declare class AddSpendingKeyController { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly spendingPublicKey1: GrumpkinAddress; - readonly spendingPublicKey2: GrumpkinAddress | undefined; - readonly fee: AssetValue; - private readonly core; - private readonly requireFeePayingTx; - private proofOutput?; - private feeProofOutputs; - private txIds; - constructor(userId: GrumpkinAddress, userSigner: Signer, spendingPublicKey1: GrumpkinAddress, spendingPublicKey2: GrumpkinAddress | undefined, fee: AssetValue, core: CoreSdkInterface); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/AztecSdk.md b/docs/docs/sdk/types/sdk/AztecSdk.md deleted file mode 100644 index 654c77bf9f5d..000000000000 --- a/docs/docs/sdk/types/sdk/AztecSdk.md +++ /dev/null @@ -1,165 +0,0 @@ -```ts -export declare class AztecSdk extends EventEmitter { - private core; - private blockchain; - private provider; - private feeCalculator; - private txValueCalculator; - constructor(core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - run(): Promise; - destroy(): Promise; - awaitSynchronised(timeout?: number): Promise; - isUserSynching(userId: GrumpkinAddress): Promise; - awaitUserSynchronised(userId: GrumpkinAddress, timeout?: number): Promise; - awaitSettlement(txId: TxId, timeout?: number): Promise; - awaitDefiDepositCompletion(txId: TxId, timeout?: number): Promise; - awaitDefiFinalisation(txId: TxId, timeout?: number): Promise; - awaitDefiSettlement(txId: TxId, timeout?: number): Promise; - awaitAllUserTxsSettled(timeout?: number): Promise; - awaitAllUserTxsClaimed(timeout?: number): Promise; - getLocalStatus(): Promise; - getRemoteStatus(): Promise; - isAccountRegistered(accountPublicKey: GrumpkinAddress, includePending?: boolean): Promise; - isAliasRegistered(alias: string, includePending?: boolean): Promise; - isAliasRegisteredToAccount(accountPublicKey: GrumpkinAddress, alias: string, includePending?: boolean): Promise; - getAccountPublicKey(alias: string): Promise; - getTxFees(assetId: number, { feeSignificantFigures }?: { - feeSignificantFigures?: number | undefined; - }): Promise; - userExists(accountPublicKey: GrumpkinAddress): Promise; - addUser(accountPrivateKey: Buffer, noSync?: boolean): Promise; - removeUser(userId: GrumpkinAddress): Promise; - /** - * Returns a AztecSdkUser for a locally resolved user. - */ - getUser(userId: GrumpkinAddress): Promise; - getUserSyncedToRollup(userId: GrumpkinAddress): Promise; - getUsers(): Promise; - getAccountKeySigningData(): Buffer; - getSpendingKeySigningData(): Buffer; - generateAccountKeyPair(account: EthAddress, provider?: EthereumProvider): Promise<{ - publicKey: GrumpkinAddress; - privateKey: Buffer; - }>; - generateSpendingKeyPair(account: EthAddress, provider?: EthereumProvider): Promise<{ - publicKey: GrumpkinAddress; - privateKey: Buffer; - }>; - createSchnorrSigner(privateKey: Buffer): Promise; - derivePublicKey(privateKey: Buffer): Promise; - getAssetIdByAddress(address: EthAddress, gasLimit?: number): number; - getAssetIdBySymbol(symbol: string, gasLimit?: number): number; - fromBaseUnits({ assetId, value }: AssetValue, symbol?: boolean, precision?: number): string; - toBaseUnits(assetId: number, value: string): { - assetId: number; - value: bigint; - }; - getAssetInfo(assetId: number): import("@aztec/barretenberg/blockchain").BlockchainAsset; - isFeePayingAsset(assetId: number): Promise; - isVirtualAsset(assetId: number): boolean; - mint({ assetId, value }: AssetValue, account: EthAddress, options?: SendTxOptions): Promise; - setSupportedAsset(assetAddress: EthAddress, assetGasLimit?: number, options?: SendTxOptions): Promise; - getBridgeAddressId(address: EthAddress, gasLimit?: number): number; - setSupportedBridge(bridgeAddress: EthAddress, bridgeGasLimit?: number, options?: SendTxOptions): Promise; - processAsyncDefiInteraction(interactionNonce: number, options?: SendTxOptions): Promise; - getDepositFees(assetId: number, options?: { - feeSignificantFigures?: number; - }): Promise; - getPendingDepositTxs(): Promise; - createDepositController(depositor: EthAddress, assetValue: AssetValue, fee: AssetValue, recipient: GrumpkinAddress, recipientSpendingKeyRequired?: boolean, provider?: EthereumProvider): DepositController; - getWithdrawFees(assetId: number, options?: GetFeesOptions & { - recipient?: EthAddress; - assetValue?: AssetValue; - }): Promise; - getMaxWithdrawValue(userId: GrumpkinAddress, assetId: number, options?: GetMaxTxValueOptions & { - recipient?: EthAddress; - }): Promise<{ - assetId: number; - value: bigint; - fee: { - assetId: number; - value: bigint; - }; - }>; - createWithdrawController(userId: GrumpkinAddress, userSigner: Signer, assetValue: AssetValue, fee: AssetValue, to: EthAddress): WithdrawController; - getTransferFees(assetId: number, options?: GetFeesOptions & { - assetValue?: AssetValue; - }): Promise; - getMaxTransferValue(userId: GrumpkinAddress, assetId: number, options?: GetMaxTxValueOptions): Promise<{ - assetId: number; - value: bigint; - fee: { - assetId: number; - value: bigint; - }; - }>; - createTransferController(userId: GrumpkinAddress, userSigner: Signer, assetValue: AssetValue, fee: AssetValue, recipient: GrumpkinAddress, recipientSpendingKeyRequired?: boolean): TransferController; - getDefiFees(bridgeCallData: BridgeCallData, options?: GetFeesOptions & { - assetValue?: AssetValue; - }): Promise; - getMaxDefiValue(userId: GrumpkinAddress, bridgeCallData: BridgeCallData, options?: Omit & { - txSettlementTime?: DefiSettlementTime; - }): Promise<{ - assetId: number; - value: bigint; - fee: { - assetId: number; - value: bigint; - }; - }>; - createDefiController(userId: GrumpkinAddress, userSigner: Signer, bridgeCallData: BridgeCallData, assetValue: AssetValue, fee: AssetValue): DefiController; - generateAccountRecoveryData(accountPublicKey: GrumpkinAddress, alias: string, trustedThirdPartyPublicKeys: GrumpkinAddress[]): Promise; - getRegisterFees(assetId: number, options?: { - feeSignificantFigures?: number; - }): Promise; - createRegisterController(userId: GrumpkinAddress, alias: string, accountPrivateKey: Buffer, spendingPublicKey: GrumpkinAddress, recoveryPublicKey: GrumpkinAddress | undefined, deposit: AssetValue, fee: AssetValue, depositor?: EthAddress, provider?: EthereumProvider): RegisterController; - getRecoverAccountFees(assetId: number, options?: { - feeSignificantFigures?: number; - }): Promise; - createRecoverAccountController(recoveryPayload: RecoveryPayload, deposit: AssetValue, fee: AssetValue, depositor?: EthAddress, provider?: EthereumProvider): RecoverAccountController; - getAddSpendingKeyFees(assetId: number, options?: { - feeSignificantFigures?: number; - }): Promise<{ - value: bigint; - assetId: number; - }[]>; - createAddSpendingKeyController(userId: GrumpkinAddress, userSigner: Signer, spendingPublicKey1: GrumpkinAddress, spendingPublicKey2: GrumpkinAddress | undefined, fee: AssetValue): AddSpendingKeyController; - getMigrateAccountFees(assetId: number, options?: { - feeSignificantFigures?: number; - }): Promise<{ - value: bigint; - assetId: number; - }[]>; - createMigrateAccountController(userId: GrumpkinAddress, userSigner: Signer, newAccountPrivateKey: Buffer, newSpendingPublicKey: GrumpkinAddress, recoveryPublicKey: GrumpkinAddress | undefined, deposit: AssetValue, fee: AssetValue, depositor?: EthAddress, provider?: EthereumProvider): MigrateAccountController; - getProofTxsFees(assetId: number, proofTxs: Tx[], options?: GetFeesOptions): Promise<{ - value: bigint; - assetId: number; - }[]>; - createFeeController(userId: GrumpkinAddress, userSigner: Signer, proofTxs: Tx[], fee: AssetValue): FeeController; - depositFundsToContract({ assetId, value }: AssetValue, from: EthAddress, provider?: EthereumProvider): Promise; - getUserPendingDeposit(assetId: number, account: EthAddress): Promise; - getUserPendingFunds(assetId: number, account: EthAddress): Promise; - isContract(address: EthAddress): Promise; - validateSignature(publicOwner: EthAddress, signature: Buffer, signingData: Buffer): boolean; - getTransactionReceipt(txHash: TxHash, timeout?: number, interval?: number): Promise; - flushRollup(userId: GrumpkinAddress, userSigner: Signer): Promise; - getSpendingKeys(userId: GrumpkinAddress): Promise; - getPublicBalance(ethAddress: EthAddress, assetId: number): Promise<{ - assetId: number; - value: bigint; - }>; - getBalances(userId: GrumpkinAddress): Promise; - getBalance(userId: GrumpkinAddress, assetId: number): Promise<{ - assetId: number; - value: bigint; - }>; - getFormattedBalance(userId: GrumpkinAddress, assetId: number, symbol?: boolean, precision?: number): Promise; - getSpendableSum(userId: GrumpkinAddress, assetId: number, spendingKeyRequired?: boolean, excludePendingNotes?: boolean): Promise; - getSpendableSums(userId: GrumpkinAddress, spendingKeyRequired?: boolean, excludePendingNotes?: boolean): Promise; - getMaxSpendableValue(userId: GrumpkinAddress, assetId: number, spendingKeyRequired?: boolean, excludePendingNotes?: boolean, numNotes?: number): Promise; - getUserTxs(userId: GrumpkinAddress): Promise<(UserAccountTx | UserDefiTx | import("../user_tx").UserDefiClaimTx | UserPaymentTx)[]>; - getPaymentTxs(userId: GrumpkinAddress): Promise; - getAccountTxs(userId: GrumpkinAddress): Promise; - getDefiTxs(userId: GrumpkinAddress): Promise; -} -``` diff --git a/docs/docs/sdk/types/sdk/AztecSdkUser.md b/docs/docs/sdk/types/sdk/AztecSdkUser.md deleted file mode 100644 index c1cb29a39e51..000000000000 --- a/docs/docs/sdk/types/sdk/AztecSdkUser.md +++ /dev/null @@ -1,22 +0,0 @@ -```ts -export declare class AztecSdkUser { - id: GrumpkinAddress; - private sdk; - constructor(id: GrumpkinAddress, sdk: AztecSdk); - isSynching(): Promise; - awaitSynchronised(timeout?: number): Promise; - getSyncedToRollup(): Promise; - getSpendingKeys(): Promise; - getBalance(assetId: number): Promise<{ - assetId: number; - value: bigint; - }>; - getSpendableSum(assetId: number, spendingKeyRequired?: boolean, excludePendingNotes?: boolean): Promise; - getSpendableSums(spendingKeyRequired?: boolean, excludePendingNotes?: boolean): Promise; - getMaxSpendableValue(assetId: number, spendingKeyRequired?: boolean, excludePendingNotes?: boolean, numNotes?: number): Promise; - getTxs(): Promise<(import("..").UserAccountTx | import("..").UserDefiTx | import("..").UserDefiClaimTx | import("..").UserPaymentTx)[]>; - getPaymentTxs(): Promise; - getAccountTxs(): Promise; - getDefiTxs(): Promise; -} -``` diff --git a/docs/docs/sdk/types/sdk/DefiController.md b/docs/docs/sdk/types/sdk/DefiController.md deleted file mode 100644 index 3c706eaa58c8..000000000000 --- a/docs/docs/sdk/types/sdk/DefiController.md +++ /dev/null @@ -1,24 +0,0 @@ -```ts -export declare class DefiController { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly bridgeCallData: BridgeCallData; - readonly assetValue: AssetValue; - readonly fee: AssetValue; - private readonly core; - private readonly requireFeePayingTx; - private proofOutput?; - private jsProofOutputs; - private feeProofOutputs; - private txIds; - constructor(userId: GrumpkinAddress, userSigner: Signer, bridgeCallData: BridgeCallData, assetValue: AssetValue, fee: AssetValue, core: CoreSdkInterface); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitDefiDepositCompletion(timeout?: number): Promise; - awaitDefiFinalisation(timeout?: number): Promise; - awaitSettlement(timeout?: number): Promise; - getInteractionNonce(): Promise; - private getDefiTxId; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/DepositController.md b/docs/docs/sdk/types/sdk/DepositController.md deleted file mode 100644 index 8c4d2601ed88..000000000000 --- a/docs/docs/sdk/types/sdk/DepositController.md +++ /dev/null @@ -1,16 +0,0 @@ -```ts -export declare class DepositController extends DepositHandler { - readonly assetValue: AssetValue; - readonly fee: AssetValue; - readonly depositor: EthAddress; - readonly recipient: GrumpkinAddress; - readonly recipientSpendingKeyRequired: boolean; - protected readonly core: CoreSdkInterface; - private txIds; - constructor(assetValue: AssetValue, fee: AssetValue, depositor: EthAddress, recipient: GrumpkinAddress, recipientSpendingKeyRequired: boolean, core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/DepositHandler.md b/docs/docs/sdk/types/sdk/DepositHandler.md deleted file mode 100644 index f25ab92865d4..000000000000 --- a/docs/docs/sdk/types/sdk/DepositHandler.md +++ /dev/null @@ -1,40 +0,0 @@ -```ts -export declare class DepositHandler { - readonly assetValue: AssetValue; - readonly fee: AssetValue; - readonly depositor: EthAddress; - readonly recipient: GrumpkinAddress; - readonly recipientSpendingKeyRequired: boolean; - protected readonly core: CoreSdkInterface; - private readonly blockchain; - private readonly provider; - protected readonly publicInput: AssetValue; - private depositProofOutput?; - private pendingFundsStatus; - constructor(assetValue: AssetValue, fee: AssetValue, depositor: EthAddress, recipient: GrumpkinAddress, recipientSpendingKeyRequired: boolean, core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - getPendingFunds(): Promise; - getRequiredFunds(): Promise; - getPublicAllowance(): Promise; - hasPermitSupport(): boolean; - approve(permitDeadline?: bigint): Promise; - awaitApprove(timeout?: number, interval?: number): Promise; - depositFundsToContract(permitDeadline?: bigint): Promise; - depositFundsToContractWithNonStandardPermit(permitDeadline?: bigint): Promise; - awaitDepositFundsToContract(timeout?: number, interval?: number): Promise; - createProof(txRefNo?: number): Promise; - getProofOutput(): ProofOutput; - getProofHash(): Buffer; - isProofApproved(): Promise; - approveProof(): Promise; - awaitApproveProof(timeout?: number, interval?: number): Promise; - getSigningData(): Buffer; - sign(): Promise; - isSignatureValid(): boolean; - private getPendingFundsStatus; - private createPermitArgs; - private createPermitArgsNonStandard; - private getContractChainId; - private sendTransactionAndCheckOnchainData; - private awaitTransaction; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/FeeController.md b/docs/docs/sdk/types/sdk/FeeController.md deleted file mode 100644 index 2adc3ca0808b..000000000000 --- a/docs/docs/sdk/types/sdk/FeeController.md +++ /dev/null @@ -1,15 +0,0 @@ -```ts -export declare class FeeController { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly proofTxs: Tx[]; - readonly fee: AssetValue; - private readonly core; - private feeProofOutputs; - private txIds; - constructor(userId: GrumpkinAddress, userSigner: Signer, proofTxs: Tx[], fee: AssetValue, core: CoreSdkInterface); - createProof(): Promise; - send(): Promise; - awaitSettlement(timeout?: number): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/MigrateAccountController.md b/docs/docs/sdk/types/sdk/MigrateAccountController.md deleted file mode 100644 index 7e7f6d3fddd6..000000000000 --- a/docs/docs/sdk/types/sdk/MigrateAccountController.md +++ /dev/null @@ -1,22 +0,0 @@ -```ts -export declare class MigrateAccountController extends DepositHandler { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly newAccountPrivateKey: Buffer; - readonly newSpendingPublicKey: GrumpkinAddress; - readonly recoveryPublicKey: GrumpkinAddress | undefined; - readonly deposit: AssetValue; - readonly fee: AssetValue; - readonly depositor: EthAddress; - protected readonly core: CoreSdkInterface; - private proofOutput?; - private txIds; - private requireDeposit; - constructor(userId: GrumpkinAddress, userSigner: Signer, newAccountPrivateKey: Buffer, newSpendingPublicKey: GrumpkinAddress, recoveryPublicKey: GrumpkinAddress | undefined, deposit: AssetValue, fee: AssetValue, depositor: EthAddress, core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; - private getProofOutputs; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/RecoverAccountController.md b/docs/docs/sdk/types/sdk/RecoverAccountController.md deleted file mode 100644 index a158c4600a6d..000000000000 --- a/docs/docs/sdk/types/sdk/RecoverAccountController.md +++ /dev/null @@ -1,18 +0,0 @@ -```ts -export declare class RecoverAccountController extends DepositHandler { - readonly recoveryPayload: RecoveryPayload; - readonly deposit: AssetValue; - readonly fee: AssetValue; - readonly depositor: EthAddress; - protected readonly core: CoreSdkInterface; - private proofOutput; - private txIds; - private requireDeposit; - constructor(recoveryPayload: RecoveryPayload, deposit: AssetValue, fee: AssetValue, depositor: EthAddress, core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; - private getProofOutputs; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/RecoveryData.md b/docs/docs/sdk/types/sdk/RecoveryData.md deleted file mode 100644 index ff633419277f..000000000000 --- a/docs/docs/sdk/types/sdk/RecoveryData.md +++ /dev/null @@ -1,11 +0,0 @@ -```ts -export declare class RecoveryData { - accountPublicKey: GrumpkinAddress; - signature: SchnorrSignature; - constructor(accountPublicKey: GrumpkinAddress, signature: SchnorrSignature); - static fromBuffer(data: Buffer): RecoveryData; - static fromString(data: string): RecoveryData; - toBuffer(): Buffer; - toString(): string; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/RecoveryPayload.md b/docs/docs/sdk/types/sdk/RecoveryPayload.md deleted file mode 100644 index 0430bbd7827a..000000000000 --- a/docs/docs/sdk/types/sdk/RecoveryPayload.md +++ /dev/null @@ -1,12 +0,0 @@ -```ts -class RecoveryPayload { - trustedThirdPartyPublicKey: GrumpkinAddress; - recoveryPublicKey: GrumpkinAddress; - recoveryData: RecoveryData; - constructor(trustedThirdPartyPublicKey: GrumpkinAddress, recoveryPublicKey: GrumpkinAddress, recoveryData: RecoveryData); - static fromBuffer(data: Buffer): RecoveryPayload; - static fromString(data: string): RecoveryPayload; - toBuffer(): Buffer; - toString(): string; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/RegisterController.md b/docs/docs/sdk/types/sdk/RegisterController.md deleted file mode 100644 index 3e8101703f36..000000000000 --- a/docs/docs/sdk/types/sdk/RegisterController.md +++ /dev/null @@ -1,22 +0,0 @@ -```ts -class RegisterController extends DepositHandler { - readonly userId: GrumpkinAddress; - readonly alias: string; - private readonly accountPrivateKey; - readonly spendingPublicKey: GrumpkinAddress; - readonly recoveryPublicKey: GrumpkinAddress | undefined; - readonly deposit: AssetValue; - readonly fee: AssetValue; - readonly depositor: EthAddress; - protected readonly core: CoreSdkInterface; - private proofOutput?; - private txIds; - private requireDeposit; - constructor(userId: GrumpkinAddress, alias: string, accountPrivateKey: Buffer, spendingPublicKey: GrumpkinAddress, recoveryPublicKey: GrumpkinAddress | undefined, deposit: AssetValue, fee: AssetValue, depositor: EthAddress, core: CoreSdkInterface, blockchain: ClientEthereumBlockchain, provider: EthereumProvider); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; - private getProofOutputs; -} -``` diff --git a/docs/docs/sdk/types/sdk/SchnorrSigner.md b/docs/docs/sdk/types/sdk/SchnorrSigner.md deleted file mode 100644 index 2f37b894ad95..000000000000 --- a/docs/docs/sdk/types/sdk/SchnorrSigner.md +++ /dev/null @@ -1,10 +0,0 @@ -```ts -class SchnorrSigner implements Signer { - private schnorr; - private publicKey; - private privateKey; - constructor(schnorr: Schnorr, publicKey: GrumpkinAddress, privateKey: Buffer); - getPublicKey(): GrumpkinAddress; - signMessage(message: Buffer): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/Signer.md b/docs/docs/sdk/types/sdk/Signer.md deleted file mode 100644 index bab8096a7c51..000000000000 --- a/docs/docs/sdk/types/sdk/Signer.md +++ /dev/null @@ -1,6 +0,0 @@ -```ts -interface Signer { - getPublicKey(): GrumpkinAddress; - signMessage(message: Buffer): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/TransferController.md b/docs/docs/sdk/types/sdk/TransferController.md deleted file mode 100644 index e0f0238c1675..000000000000 --- a/docs/docs/sdk/types/sdk/TransferController.md +++ /dev/null @@ -1,20 +0,0 @@ -```ts -export declare class TransferController { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly assetValue: AssetValue; - readonly fee: AssetValue; - readonly recipient: GrumpkinAddress; - readonly recipientSpendingKeyRequired: boolean; - private readonly core; - private readonly requireFeePayingTx; - private proofOutputs; - private feeProofOutputs; - private txIds; - constructor(userId: GrumpkinAddress, userSigner: Signer, assetValue: AssetValue, fee: AssetValue, recipient: GrumpkinAddress, recipientSpendingKeyRequired: boolean, core: CoreSdkInterface); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/types/sdk/WithdrawController.md b/docs/docs/sdk/types/sdk/WithdrawController.md deleted file mode 100644 index c52ff6c7d391..000000000000 --- a/docs/docs/sdk/types/sdk/WithdrawController.md +++ /dev/null @@ -1,19 +0,0 @@ -```ts -export declare class WithdrawController { - readonly userId: GrumpkinAddress; - private readonly userSigner; - readonly assetValue: AssetValue; - readonly fee: AssetValue; - readonly recipient: EthAddress; - private readonly core; - private readonly requireFeePayingTx; - private proofOutputs; - private feeProofOutputs; - private txIds; - constructor(userId: GrumpkinAddress, userSigner: Signer, assetValue: AssetValue, fee: AssetValue, recipient: EthAddress, core: CoreSdkInterface); - createProof(): Promise; - exportProofTxs(): import("@aztec/barretenberg/rollup_provider").Tx[]; - send(): Promise; - awaitSettlement(timeout?: number): Promise; -} -``` \ No newline at end of file diff --git a/docs/docs/sdk/usage/account-recovery.md b/docs/docs/sdk/usage/account-recovery.md deleted file mode 100644 index e64893b08a21..000000000000 --- a/docs/docs/sdk/usage/account-recovery.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Recover Accounts ---- - -Recover an Aztec account. - -Aztec allows for recovery of an account for which all of the registered spending keys have been lost. The recovering party will still need the account privacy key to decrypt the associated account notes. - -At a high level, what the [RecoverAccountController](./../types/sdk/RecoverAccountController) does is it adds a trusted third party key as a new spending key for the account. This trusted third party key can then be used to [add new spending keys](add-spending-keys) to the account, so only add a recovery account that is managed by someone that you trust! - -The `RecoverAccountController` does not require an Aztec account and can be used with only a funded Ethereum account. This allows anyone to initiate an account recovery. - -The trusted third party key is **different** than the `recoveryPublicKey` passed to the `RegistrationController` during [setup](register#setup). - -## Recovery Payload - -In practice, a user generates a [RecoveryPayload](../types/sdk/RecoveryPayload) from their account public key, their alias and a trusted third party public key. The `RecoveryPayload` includes the `recoveryPublicKey`. - -To be able to recover an account, a user must have the `RecoveryPayload` generated using the SDK. Generating a `RecoveryPayload` is **not** deterministic, you will not be able to regenerate a `RecoveryPayload` with the same inputs later. Store the recovery payload someplace safe! - -Using the SDK to generate a `RecoveryPayload`: - -```ts -// Store this third party key! Its what is used to recover the account. -const thirdPartySigner = await sdk.createSchnorrSigner(Buffer.alloc(32, 3, "hex"; -const trustedThirdPartyPublicKey = thirdPartySigner.getPublicKey(); - -// Store this recovery payload! It cannot be regenerated--it includes randomness -const recoveryPayloads = await sdk.generateAccountRecoveryData( - accounts[defaultAccountIndex].privacyAccount.id, - alias, - [trustedThirdPartyPublicKey] -); -``` - -You can add additional `recoveryPublicKeys` to an account that is already registered using the [AddSpendingKeyController](../types/sdk/AddSpendingKeyController). See [this page](../usage/add-spending-keys) for more info. - -## Setup `RecoverAccountController` - -```ts -AztecSdk.createRecoverAccountController( - recoveryPayload: RecoveryPayload, - deposit: AssetValue, - fee: AssetValue, - depositor: EthAddress, - provider?: EthereumProvider): - Promise; -``` - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| recoveryPayload | [RecoveryPayload](../types/sdk/RecoveryPayload) | Contains data used to add a trusted third party spending key to an Aztec account. | -| deposit | [AssetValue](./../types/barretenberg/AssetValue) | The `assetId` (number) and `value` (bigint) to deposit. This can be 0. | -| fee | [AssetValue](./../types/barretenberg/AssetValue) | The Aztec network fee for processing the transaction. | -| depositor | [EthAddress](../types/barretenberg/EthAddress) | The Ethereum account from which to deposit funds. | -| provider? | [EthereumProvider](./../types/barretenberg/EthereumProvider) | Optional Ethereum provider. | - -### Returns - -| Return Type | Description | -| --------- | ----------- | -| [RecoverAccountController](../types/sdk/RecoverAccountController) | A user instance with apis bound to the user's account id. | - -## Usage - -```ts -const controller = await sdk.createRecoverAccountController( - recoveryPayloads[0], - deposit, - tokenTransferFee, - depositor -); - -await controller.createProof(); -await controller.depositFundsToContract(); -await controller.awaitDepositFundsToContract(); -await controller.sign(); -let txId = await controller.send(); -``` \ No newline at end of file diff --git a/docs/docs/sdk/usage/add-account.md b/docs/docs/sdk/usage/add-account.md deleted file mode 100644 index ce9b0bb3919b..000000000000 --- a/docs/docs/sdk/usage/add-account.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Add Accounts to the SDK ---- - -Add accounts with the account (viewing/privacy) key. - -Because all notes representing value on Aztec network are encrypted, the SDK requires access to a user's account key in order to decrypt the notes and calculate the account balance. - -Please review [the page on Accounts](../../how-aztec-works/accounts) if you haven't already as it will help you understand the difference between Ethereum and Aztec accounts. - -:::info - -Aztec will support the same elliptic curve as Ethereum in the future so Ethereum accounts will be Aztec accounts. - -::: - -## Account Keys - -Privacy keys can be any random 32 bytes. The SDK allows you to generate keys deterministically from Ethereum accounts by deriving Aztec keys from signed Ethereum messages. - -### Generate - -You can generate the account key from an Ethereum private key by signing this message: - -`Sign this message to generate your Aztec Privacy Key. This key lets the application decrypt your balance on Aztec.\n\nIMPORTANT: Only sign this message if you trust the application.` - -and taking the first 32 bytes of the resulting signed message. You can find an example in the SDK [here](https://github.com/AztecProtocol/aztec-connect/blob/ec87601503c6425b6a578a19117ead5a582df91c/sdk/src/aztec_sdk/aztec_sdk.ts#L196). - -```ts -const { publicKey, privateKey } = sdk.generateAccountKeyPair(ethereumAccount); -``` - -### Add to SDK - -With the account key, adding the user to the SDK is as simple as passing the key and the nonce for the account. - -```ts -const account = await sdk.addUser(accountKey); -``` - -### Read - -Now just make sure the SDK account has synced and you can read account balances: - -```ts -await account.awaitSynchronised(); -const zkEthBalance = await account.getBalance(sdk.getAssetIdBySymbol("ETH")); -``` - -## Spending Keys - -Once a spending key has been registered, either the account key or a registered spending key can be used to spend notes. This creates a useful separation between account (or "viewing/privacy keys") and spending keys. The sender of a note can specify whether the note is spendable by the account key or a registered spending key. This is specified with the `recipientSpendingKeyRequired` flag when setting up a controller. See the [TransferController](./transfer#controller-setup) for an example. - -It is considered best practice to register a new spending key as soon as possible. You can read more about registering new accounts for users on the [Register Users page](./register). Here, we will briefly review how to add a spending key to the SDK that has already been registered. - -You can create an Aztec signer by passing the signing key to the `createSchnorrSigner(privateKey: Buffer)` method. It returns a signer that you can pass to various `Controllers` to sign transactions on the network on behalf of the account. - -```ts -const signer = await sdk.createSchnorrSigner(signingPrivateKey); -``` - -Like account keys, spending keys can be 32 random bytes, but the SDK allows you to generate them deterministically from Ethereum accounts by deriving them from a signed message. The message used for creating signing keys is: - -`Sign this message to generate your Aztec Spending Key. This key lets the application spend your funds on Aztec.\n\nIMPORTANT: Only sign this message if you trust the application.` - -You can see an example in the SDK source code [here](https://github.com/AztecProtocol/aztec-connect/blob/ec87601503c6425b6a578a19117ead5a582df91c/sdk/src/aztec_sdk/aztec_sdk.ts#L205). - -## Add User - -```ts -sdk.addUser(accountPrivateKey: Buffer, noSync?: boolean): Promise; -``` - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| privateKey | Buffer | The privacy key of the user. | -| noSync | boolean | Whether to skip sync. Default is `false`. | - -| Return Type | Description | -| --------- | ----------- | -| [AztecSdkUser](../types/sdk/AztecSdkUser) | A user instance with apis bound to the user's account id. | - -## Get User - -```ts -sdk.getUser(userId: GrumpkinAddress): Promise; -``` - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key of the user. | - -| Return Type | Description | -| --------- | ----------- | -| [AztecSdkUser](./../types/sdk/AztecSdkUser) | A user instance with apis bound to the user's account id. | \ No newline at end of file diff --git a/docs/docs/sdk/usage/add-spending-keys.md b/docs/docs/sdk/usage/add-spending-keys.md deleted file mode 100644 index 837450623aee..000000000000 --- a/docs/docs/sdk/usage/add-spending-keys.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Add Spending Keys ---- - -Add spending keys to a registered Aztec account. - -The [Accounts page](../../how-aztec-works/accounts) contains helpful context if you are unfamiliar with how Aztec accounts work. - -There is no limit to the number of spending keys that can be added to an Aztec account. This decreases the need for insecure key sharing between devices. For example, you can register a unique spending key on each one of your devices for the same Aztec account, so you don't have to copy and paste private keys. - -You can also use the [AddSpendingKeyController](../types/sdk/AddSpendingKeyController) to add additional recovery public keys to an account after it has been registered. Read more about account recovery [here](account-recovery). - -## Setup - -```ts -AztecSdk.createAddSpendingKeyController( - userId: GrumpkinAddress, - userSigner: Signer, - spendingPublicKey1: GrumpkinAddress, - spendingPublicKey2: GrumpkinAddress | undefined, - fee: AssetValue): - AddSpendingKeyController; -``` - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key of the account registering the new signing keys. | -| userSigner | [Signer](../types/sdk/Signer) | A signer associated with the userId. | -| spendingPublicKey1 | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key of a new spending key. | -| spendingPublicKey2 | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key of a new spending key. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | The Aztec transaction fee. | - -### Returns - -| Return Type | Description | -| --- | --- | -| [AddSpendingKeyController](../types/sdk/AddSpendingKeyController) | A user instance with apis bound to the user's account id. | - -## Usage - -The follow code is an example of how you could set up and use the `AddSpendingKeyController`. Obviously, you'll want to save the spending key private keys to use them later or generate them using a different method. - -```ts -const newSpendingKey1 = await sdk.createSchnorrSigner(randomBytes(32)); -const newSpendingKey2 = await sdk.createSchnorrSigner(randomBytes(32)); - -const fee = (await sdk.getAddSpendingKeyFees( - sdk.getAssetIdBySymbol("ETH")))[TxSettlementTime.NEXT_ROLLUP]; - -const controller = sdk.createAddSpendingKeyController( - user, - signer, - newSpendingKey1.getPublicKey(), - newSpendingKey2.getPublicKey(), - fee -); -await controller.createProof(); -let txId = await controller.send(); -``` - -### Transaction Fees - -The transaction fee can be paid in ETH or DAI. - -The settlement time can either be `NEXT_ROLLUP` or `INSTANT`. Refer to the [fees section](./register#calculating-fees) on the registration page for a more detailed explanation. diff --git a/docs/docs/sdk/usage/deposit.md b/docs/docs/sdk/usage/deposit.md deleted file mode 100644 index 63791163b48b..000000000000 --- a/docs/docs/sdk/usage/deposit.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: Deposit (Shield) ---- - -Deposit assets from Ethereum to Aztec. - -Review the [general page on deposits](../../developers/deposit) for a higher level review of how deposits work on Aztec. - -The SDK comes with a `DepositController` that makes it easy to create and track deposit transactions from Ethereum to Aztec. - -Deposits require sending Ethereum transactions from a user's account to the Aztec deposit contract. Any Etheruem account can make a deposit to any Aztec account. - -An example to help clarify. Say Alice is an entity on L1 that wants to make a deposit of 10 DAI into Bob's account on Aztec. She knows that Bob owns the bob.eth ENS (Ethereum Name Service) name, so she can make a deposit like (ens inserted instead of address for clarity): - -```js -aztecRollupContract.depositPendingFunds(1, 10e18, bob.eth, bytes32(0)); -``` - -After this transaction is executed, there is now 10 DAI in Bob's pending balance on Aztec. Bob then creates a deposit proof (only on L2, no L1 transaction), where he uses the 10 DAI. Bob now has the 10 DAI in an Aztec account and he never sent a L1 tx himself. If there have been multiple deposits, he can make the deposit proof of the sum of them if he wants to, e.g., for 3 deposits of 10 DAI he could make a deposit proof spending all 30 DAI. - -The SDK simplifies making deposits to the Aztec rollup contract as well as generating the proofs for claiming pending deposits. - -You can find the interface for the `DepositController` class [here](../types/sdk/DefiController). - -### Controller Setup - -```ts -AztecSdk.createDepositController( - depositor: EthAddress, - value: AssetValue, - fee: AssetValue, - recipient: GrumpkinAddress, - recipientSpendingKeyRequired?: boolean, - provider?: EthereumProvider) - : Promise -``` - -### Controller Inputs - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| depositor | [EthAddress](../types/barretenberg/EthAddress) | Ethereum account making the deposit. | -| value | [AssetValue](../types/barretenberg/AssetValue) | Type and amount of deposit. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | Type and amount for the Aztec transaction fee. | -| recipient | [GrupmkinAddress](../types/barretenberg/GrumpkinAddress) | The account public key of the Aztec account. | -| recipientSpendingKeyRequired? | boolean | Optional flag that specifies whether the recipient account should already be registered. | -| provider? | [EthereumProvider](../types/barretenberg/EthereumProvider) | Optional Ethereum Provider. When unspecified it defaults to the provider used in setup (`createAztecSdk`). | - -#### Returns - -| Return Type | Description | -| --------- | ----------- | -| [DepositController](../types/sdk/DepositController) | A user instance with apis bound to the user's account id. | - -### Executing a Deposit - -The complete deposit flow for Ether using the `DepositController` looks like this: - -```ts -const tokenAssetId = sdk.getAssetIdBySymbol('ETH'); -const tokenDepositFee = (await sdk.getDepositFees(tokenAssetId))[ - settlementTime -]; -const tokenAssetValue: AssetValue = { - assetId: tokenAssetId, - value: tokenQuantity, -}; -const tokenDepositController = sdk.createDepositController( - depositor, - tokenAssetValue, - tokenDepositFee, - recipient, - true, -); -await tokenDepositController.createProof(); -await tokenDepositController.sign(); -// check if there are pending deposits -if ( - (await tokenDepositController.getPendingFunds()) < tokenAssetValue.value -) { - if (asset === "dai") { - if ( - (await tokenDepositController.getPublicAllowance()) < - tokenAssetValue.value - ) { - await tokenDepositController.approve(); - await tokenDepositController.awaitApprove(); - } - } - await tokenDepositController.depositFundsToContract(); - await tokenDepositController.awaitDepositFundsToContract(); -} -let txId = await tokenDepositController.send(); -``` - -Not all ERC-20s (specifically DAI) have correctly implemented the permit spec. So in the case of DAI you call `depositFundsToContractWithNonStandardPermit` instead of `depositFundsToContract`. Note that the DAI contract has hardcoded chain ids for Ethereum networks ([source](https://github.com/makerdao/developerguides/blob/master/dai/how-to-use-permit-function/how-to-use-permit-function.md#permit-in-the-dai-contract)), so this method won't work on the Aztec testnet. - -#### Required Approvals - -When depositing an ERC-20 token like DAI, you will need to approve Aztec as an authorized spender before depositing. The `DepositController` includes a method for this, `DepositController.approve()` which will request approval for the amount required for the deposit. - -### Advanced Usage - -#### Depositing from a Smart Contract - -A smart contract can deposit assets into Aztec and specify an externally owned account as the `owner` which enables that Ethereum account to sign a message and claim the deposit on Aztec. But this deposit method reveals some data about the recipient in the Ethereum L1 transaction and may not have the privacy guarantees you are looking for. - -To hide the recipient when the depositing account is a smart contract, the `owner` input can be set to the depositing smart contract address when calling the `depositPendingFunds` on the [rollup processor contract](https://github.com/AztecProtocol/aztec-connect/blob/b0a71b01c5f1aa3b4b9a61d417aa4c479e01ef47/blockchain/contracts/interfaces/IRollupProcessor.sol#L33) and include a `proofHash` input. This input specifies which transaction id on Aztec is authorized to claim the pending deposit, so it hides the intended recipient. This transaction id (`proofHash`) must be computed beforehand and passed to `depositPendingFunds`. When the `depositPendingFunds` transaction has settled on Ethereum, the corresponding proof must be generated and sent to the Aztec sequencer to make the deposit. - -This deposit method using the `proofHash` is also useful when a smart contract (e.g. multisig) is depositing assets to an Aztec native multisig account and a single Ethereum EOA cannot be trusted. This is necessary in these cases because there is no way to create a signature to generate a proof that corresponds to a smart contract address on Ethereum. - -To get the transaction id (`proofHash`), create the `tokenDepositController`, as shown above, with the desired inputs. The `depositor` is the address of the smart contract doing the deposit. - -Once you have the `tokenDepositController`: - -```js -await tokenDepositController.createProof(); -const proofHash = await tokenDepositController.getProofHash(); -``` - -You do not need to call `sign()` on the DepositController, like in the previous example. - -Once the `depositPendingFunds` transaction settles on Ethereum, send the funds to the Aztec account designated in the deposit proof by sending the deposit proof to the Aztec sequencer with `await tokenDepositController.send()`. The proof could be saved from before or regenerated from the same inputs. diff --git a/docs/docs/sdk/usage/ethereum-interaction.md b/docs/docs/sdk/usage/ethereum-interaction.md deleted file mode 100644 index c2f5a5a292c5..000000000000 --- a/docs/docs/sdk/usage/ethereum-interaction.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: Ethereum Interactions ---- - -One of the most exciting features of Aztec Connect is the ability to interact directly with Ethereum from Aztec. Interactions with Ethereum are facilitated by bridge contracts. You can read more about bridge contracts in the [Aztec Connect bridges repo](https://github.com/AztecProtocol/aztec-connect-bridges) on Github. - -The [DefiController](../types/sdk/DefiController) makes it easy to interact directly with deployed Ethereum bridge contracts. Bridge contracts make the connection between the Aztec rollup processor contract and various Ethereum contracts. - -## Setup - -```ts -AztecSdk.createDefiController( - userId: GrumpkinAddress, - userSigner: Signer, - bridgeCallData: BridgeCallData, - value: AssetValue, - fee: AssetValue) - : Promise -``` - -### Inputs - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | Owner of the value note to be sent. | -| userSigner | [Signer](../types/sdk/Signer) | A signer associated with the `userId`. | -| bridgeCallData | [BridgeCallData](../types/barretenberg/BridgeCallData) | A unique id corresponding to the bridge that the `value` is sent to. | -| value | [AssetValue](../types/barretenberg/AssetValue) | Asset type and amount to send. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | Asset type and amount to pay for the Aztec transaction fee. | - -#### Returns - -| Return Type | Description | -| --------- | ----------- | -| [DefiController](../types/sdk/DefiController) | A user instance with apis bound to the user's account id. | - -## BridgeCallData Setup - -A bridge `addressId` is required to setup [BridgeCallData](../types/barretenberg/BridgeCallData). The `addressId` is a number associated with the bridge. It increments by 1 as new bridges are deployed to Ethereum and added to the rollup processor contract. - -You can get the bridge `addressId`s from the published [Deployed Bridge Info table](https://github.com/AztecProtocol/aztec-connect-bridges#deployed-bridge-info). - -You can also query the bridge ids on the rollup processor contracts directly. [Here is the link](https://etherscan.io/address/0xff1f2b4adb9df6fc8eafecdcbf96a2b351680455#readProxyContract -) to read the contract Etherscan. You can get the bridge contract addresses from the `getSupportedBridge` or `getSupportedBridges` functions. The bridge `addressId` corresponds to it's index in the supported bridges array returned by `getSupportedBridges`. - -Once you have the bridge `addressId`, you can initialize a new bridge instance. The `BridgeCallData` constructor looks like this: - -```ts -const bridge = new BridgeCallData( - addressId: number, - inputAssetIdA: number, - outputAssetIdA: number, - inputAssetIdB?: number | undefined, - outputAssetIdB?: number | undefined, - auxData?: number); -``` - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| addressId | number | The id of the bridge in the rollup processor contract. | -| inputAssetIdA | number | The [asset id](../../glossary#asset-ids) of the first input asset. | -| outputAssetIdA | number | The [asset id](../../glossary#asset-ids) of the first output asset. | -| inputAssetIdB | number | Optional. The [asset id](../../glossary#asset-ids) of the second input asset. | -| outputAssetIdB | number | Optional. The [asset id](../../glossary#asset-ids) of the second output asset. | -| auxData | number | Custom auxiliary data for bridge-specific logic. | - -The `BridgeCallData` is passed to the `DefiController` to specify how to construct the interaction. - -For example, you can create the `BridgeCallData` for the ETH to wstETH Lido bridge like this: - -```ts -const ethToWstEthBridge = new BridgeCallData(2, 0, 2); // IN: ETH (0), OUT: wstETH (2) -``` - -The Lido bridge contract is `addressId` 2, takes 1 input asset (ETH, `assetId` = 0) and returns 1 output asset (wstETH, `assetId` = 2). This bridge doesn't take any `auxData` since it is just a simple exchange of ETH to wstETH. - -### Advanced usage - -The Element bridge is a bit more complicated than the Lido bridge, so it's worth going through. The Element bridge allows users to deposit funds into Element directly from Aztec to earn yield. - -The Element bridge is asynchronous, meaning there is a user action to deposit funds and then another action later to withdraw. The bridge also uses `auxData` to track which [tranche](https://docs.element.fi/element/element-smart-contracts/core-protocol-contracts/tranche) a user is interacting with. - -#### Typescript Bridge Connectors - -The bridges repo contains a `client` directory that contains useful helper functions for interacting with deployed bridge contracts. You can review the full Element bridge file [here](https://github.com/AztecProtocol/aztec-connect-bridges/blob/master/src/client/element/element-bridge-data.ts). This file includes functions to get the expected `auxData` values, get expected yields and historical interaction information. - -For this Element connector, we need to pass in an Ethereum provider, the rollup contract address, the bridge contract address and a mainnet flag (useful for testing). You can view the `ElementBridgeData` class interface [here](../types/bridge-clients/ElementBridgeData). - -For example: - -```ts -const elementAdaptor = createElementAdaptor( - ethereumProvider, - "0xFF1F2B4ADb9dF6FC8eAFecDcbF96A2B351680455", // rollup contract - "0xaeD181779A8AAbD8Ce996949853FEA442C2CDB47", // bridge contract - false // mainnet flag -); -``` - -Once it's set up, we can ask it for the expected `auxData` values with: - -```ts -await elementAdaptor.getAuxData?( - inputAssetA: AztecAsset, - inputAssetB: AztecAsset, - outputAssetA: AztecAsset, - outputAssetB: AztecAsset): Promise; -``` - -This function returns an index of numbers corresponding to various tranche expiry times that correspond to the inputAsset. This will determine which tranche the user interacts with. So you could set up `BridgeCallData` for a user to interact with the latest tranche by passing the last index of the array of returned expiry times. - -Looking at the [Deployed Bridge Info table](https://github.com/AztecProtocol/aztec-connect-bridges#deployed-bridge-info), the Element bridge is id 1, it takes DAI (asset id 1) and returns DAI and you can pass an element from the `auxData` array from the connector and pass this to the `DefiController`. - -```ts -const elementBridge = new BridgeCallData(1, 1, 1, undefined, undefined, Number(elementAuxData[0])); // IN: DAI (1), OUT: DAI (1) -``` - -#### Async `finalise` - -Since the Element bridge is asynchronous, the `finalise` function must be called on the bridge contract after the Element tranche has matured to get the deposit + interest back in the Aztec account. - -In the case of the Element bridge, this is handled automatically by users entering new Element positions. The bridge contract checks if there are any positions available to finalise and if there are, it will process them. You can view the relevant code in the bridge [here](https://github.com/AztecProtocol/aztec-connect-bridges/blob/25cb63d8092350527ab143be97142119bec638fe/src/bridges/element/ElementBridge.sol#L511). - -If you want to finalise a defi interaction without having to rely on interactions from others or do it independently of other bridge contract interactions, you can. There is a `processAsyncDefiInteraction` function on the [rollup processor contract](https://github.com/AztecProtocol/aztec-connect/blob/b2103376608e46ffe50cf56f9ca5ce031f34c671/blockchain/contracts/RollupProcessor.sol#L748) that takes an `interactionNonce`. You can call this from any Ethereum account. You can fetch defi transaction `interactionNonces` from an Aztec account using the `getUserTxs` method in the [SDK](../types/sdk/AztecSdk). - -## Fees - -Similarly to other controllers, the SDK comes with a helper method to calculate fees. It requires the `BridgeCallData` since different bridges cost different amounts of gas. `settlementTime` is type [DefiSettlementTime](../types/barretenberg/DefiSettlementTime). - -`DefiSettlementTime` is an enum with members `DEADLINE`, `NEXT_ROLLUP` and `INSTANT`. `DEADLINE` is the slowest and cheapest. It provides a longer opportunity for your transaction to be batched with other similar interactions. `NEXT_ROLLUP` is the next most expensive and will process in the next regardless of the number of similar interactions. `INSTANT` is the most expensive and will pay the cost to settle the rollup and process the interaction immediately. - -```ts -const fee = (await sdk.getDefiFees(bridgeId))[settlementTime]; -``` - -The settlement time is inferred from the fee a user pays, it is not explicitly sent to the controller. - -## Bridge Address Ids - -You can find the latest bridge contract `addressId`s and Ethereum contract addresses in the [Aztec Connect Bridges repo](https://github.com/AztecProtocol/aztec-connect-bridges). \ No newline at end of file diff --git a/docs/docs/sdk/usage/feecontroller.md b/docs/docs/sdk/usage/feecontroller.md deleted file mode 100644 index 540703c6a166..000000000000 --- a/docs/docs/sdk/usage/feecontroller.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Fee Controller ---- - -Pay transaction fees for other accounts. - -High level overview of creating paying transaction fees for another user: - -### Context - -Alice is generating transaction proofs that will be sent to the [sequencer](../../glossary.md#sequencer) by Bob. Bob will pay the transaction fees to process Alice's transaction proofs. - -### Process - -1. Alice sets up the transaction creation [controller](../overview.md#controllers). - 1. `registerController = aztecSdk.createRegisterController(...)` -2. Alice generates the transaction proof using the controller. - 1. `registerController.createProof()` -3. Alice exports the proof data and sends it to Bob. - 1. `proofTxs = registerController.exportProofTxs()` -4. Bob queries the Aztec client for the current transaction fee rate. - 1. `fee = aztecSdk.getProofTxsFees(assetId, proofTxs)` -5. Bob creates a [FeeController](../types/sdk/FeeController.md), generates the proof and sends the transactions to the [sequencer](./../../glossary.md#sequencer). - 1. `feeController = aztecSdk.createFeeController(alicesUserId, bobsSigner, proofTxs, fee)` - 2. `feeController.createProof()` - 3. `feeController.send()` diff --git a/docs/docs/sdk/usage/register.md b/docs/docs/sdk/usage/register.md deleted file mode 100644 index 042c658c6d91..000000000000 --- a/docs/docs/sdk/usage/register.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Register ---- - -Register an Aztec spending key, alias and (optional) recovery key. - -Please review the [Accounts overview](../../how-aztec-works/accounts) and [Add User](./add-account) pages if you haven't already. - -As mentioned in the above pages, there is an important difference between the account (privacy) keys and spending keys. The account key is used to decrypt notes, calculate balances and track transactions associated with an account. The spending key associated with an account is used to spend notes associated with an account. - -A spending key must be registered on the network before it can be used. The SDK makes it easy to register a new spending key using the `RegisterController`. - -You can find the interface for the `RegisterController` class [here](../types/sdk/RegisterController). - -## Setup - -You can find the type definition of the RegisterController class [here](../types/sdk/RegisterController). - -```ts -AztecSdk.createRegisterController( - userId: GrumpkinAddress, - alias: string, - accountPrivateKey: Buffer, - spendingPublicKey: GrumpkinAddress, - recoveryPublicKey: GrumpkinAddress | undefined, - deposit: AssetValue, - fee: AssetValue, - depositor: EthAddress, - provider?: EthereumProvider) : Promise; -``` - -### Controller Inputs - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key of the account registering the new signing key. | -| alias | string | The alias to register the new account with. This is typically a human-readable, easy to remember identifier. | -| accountPrivateKey | Buffer | The account private key. | -| spendingPublicKey | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The public key for the new account. Users must remember the corresponding private key (or the derivation method). | -| recoveryPublicKey | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) or `undefined` | An optional recovery key that allows the account to be recovered if the spending key is lost. | -| deposit | [AssetValue](../types/barretenberg/AssetValue) | The `assetId` (number) and `value` (bigint) to deposit. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | The network fee for registering the account. | -| depositor | [EthAddress](../types/barretenberg/EthAddress) | The Ethereum account from which to deposit the funds. | -| provider? | [EthereumProvider](../types/barretenberg/EthereumProvider) | Optional Ethereum Provider. When unspecified it defaults to the provider used in setup (`createAztecSdk`). | - -#### Returns - -| Return Type | Description | -| --------- | ----------- | -| [RegisterController](../types/sdk/RegisterController) | A user instance with apis bound to the user's account id. | - -### Calculating Fees - -Registering an account costs a fee to cover gas costs for posting calldata on Ethereum as well as to prevent alias squatting. - -`(await AztecSdk.getRegisterFees(deposit: AssetValue))[settlementTime: TxSettlementTime]` will help determine how much the transaction will cost. Settlement time can either be `NEXT_ROLLUP` or `INSTANT`. `INSTANT` is more expensive because it indicates you will pay for the rollup to settle "instantly" (on the order of minutes rather than hours) rather than waiting for it to fill up with other transactions. When there are more transactions in the rollup, users are splitting the cost among more transactions so each one is cheaper. - -Note that the cost of `INSTANT` is the same regardless of how full the rollup is at the time of requesting the quote. The settlement time is inferred from the fee a user pays, it is not explicitly sent to the controller. - -### Full Registration Flow - -Once the `RegisterController` has been created, you can use it to deposit funds, create proofs, and sign and send transactions. For example: - -```ts -const assetId = sdk.getAssetIdByAddress(tokenAddress); -const deposit = { assetId, value: tokenQuantity }; -const txFee = (await sdk.getRegisterFees(deposit))[TxSettlementTime.NEXT_ROLLUP]; - -const controller = await sdk.createRegisterController( - user, - signer, - alias, - newSigner.getPublicKey(), - recoveryPublicKey, - deposit, - txFee, - depositer -); - -// check if there is a pending deposit -if ((await controller.getPendingFunds()) < tokenQuantity) { - await controller.depositFundsToContract(); - await controller.awaitDepositFundsToContract(); -} - -await controller.createProof(); -await controller.sign(); -await controller.send(); -``` - -You can find the full example script that calls this method [here](https://github.com/critesjosh/aztec-sdk-starter/blob/mainnet-fork/src/latest/registerAccount.ts). diff --git a/docs/docs/sdk/usage/setup.mdx b/docs/docs/sdk/usage/setup.mdx deleted file mode 100644 index 3ce5c2b0cf2f..000000000000 --- a/docs/docs/sdk/usage/setup.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Setup ---- -import Image from '@theme/IdealImage'; - -Setting up the SDK. - -This explainer will frequently reference code snippets from -[the CLI reference repository](https://github.com/critesjosh/azteccli). You can pull this repo and follow along to run the examples yourself. - -If you are building a web app, check out the [create react app reference repo](https://github.com/AztecProtocol/aztec-frontend-boilerplate). - -The following examples are written in Typescript and assumes users will be creating keys using Metamask in a browser. - -## Install - -```shell -yarn add @aztec/sdk -``` - -Once the SDK is installed, import it into your project. Using Typescript is highly recommended. - -```ts -import { createAztecSdk } from "@aztec/sdk"; -``` - -## Provider Setup - -You need to set up a connection to an Ethereum network and import a private key. Since this is assuming a Nodejs context there is no direct access to an Ethereum wallet. - -Import `EthersAdapter` from `@aztec/sdk` and `JsonRpcSigner` from `@ethersproject/providers`. - -```ts title="/src/latest/index.ts" -const ethersProvider = new ethers.providers.JsonRpcProvider("http://localhost:24012/rpc") // local connection to metamask -const ethereumProvider = new EthersAdapter(ethersProvider); -``` - -## SDK setup - -Once the provider is set up you can create an instance of the Aztec SDK, specifying the rollup host. When working on the mainnet fork [local development environment](../../developers/local-devnet), the corresponding sequencer endpoint is: - -```shell -http://localhost:8081 -``` - -You can connect to the Aztec sequencer that is connected to Ethereum at: - -```shell -https://api.aztec.network/aztec-connect-prod/falafel -``` - -```ts title="/src/base.ts" -const setupSdk = async () => { - sdk = await createAztecSdk(ethereumProvider, { - serverUrl: "http://localhost:8081", // local devnet - pollInterval: 1000, - memoryDb: true, // set to false to save chain data - debug: "bb:*", // print debug logs - flavour: SdkFlavour.PLAIN, // Use PLAIN with Nodejs - minConfirmation: 1, // ETH block confirmations - }); - - await sdk.run(); - await sdk.awaitSynchronised(); -}; -``` - -### Debug - -Run `export DEBUG=bb:*` in your terminal before running a Nodejs script to also turn on the debug logs. - -## Browser debugging - -If you have the `debug` flag set to `bb:*` to log output during development, make sure the browser console log level includes "verbose" to be able to see all of the output. - - - ---- - -You can enable debugging when you create the SDK instance. - -```ts -const sdk = await createAztecSdk(ethereumProvider, { - serverUrl: "http://localhost:8081", // local devnet - pollInterval: 1000, - memoryDb: true, // set to false to save DB in a project file rather than memory - debug: "bb:*", - minConfirmation: 1, // ETH block confirmations -}); -``` diff --git a/docs/docs/sdk/usage/transfer.md b/docs/docs/sdk/usage/transfer.md deleted file mode 100644 index 9e5f24333aad..000000000000 --- a/docs/docs/sdk/usage/transfer.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Transfer ---- - -Transfer asset notes on the Aztec network. - -Use the `TransferController` to spend notes (assets) within the Aztec rollup. - -You can find the type definition of the `TransferController` class [here](../types/sdk/TransferController). - -### Controller Setup - -```ts -AztecSdk.createTransferController( - userId: GrumpkinAddress, - userSigner: Signer, - value: AssetValue, - fee: AssetValue, - recipient: GrumpkinAddress, - recipientSpendingKeyRequired?: boolean) - : Promise; -``` - -### Inputs - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | Current owner of the asset note (the sender). | -| userSigner | [Signer](../types/sdk/Signer) | A signer for the sending account. | -| value | [AssetValue](../types/barretenberg/AssetValue) | Asset type and amount to send. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | Asset type and amount to pay for the Aztec transaction fee. | -| recipient | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | Public key of the receiving account. | -| recipientSpendingKeyRequired? | boolean | Optional flag to ensure that the recipient has registered an account. Defaults to true. | - -#### Returns - -| Return Type | Description | -| --------- | ----------- | -| [TransferController](../types/sdk/TransferController) | A user instance with apis bound to the user's account id. | - -### Get Asset Id - -The SDK includes a utility function to get the the AssetId (assetId: number) from the Ethereum token address. When sending Ether, you can specify the `0x0` address as `EthAddress.ZERO`. - -```ts -const assetId = sdk.getAssetIdByAddress(tokenAddress); -const zkETH = sdk.getAssetIdByAddress(EthAddress.ZERO); -``` - -### Transfer fees - -You calculate transfer fees similar to how it is done with registrations or deposits, but there is an additional `options` object where you can pass additional information to get a more specific fee quote. - -```ts -// optional fee options -// not relevant if using FeeController -const feeOptions = { - userId: aztecPublicKey, - userSpendingKeyRequired: true, - excludePendingNotes: true, - feeSignificantFigures: 2, - assetValue: tokenAssetValue -} - -const tokenTransferFee = (await sdk.getTransferFees(assetId, feeOptions))[settlementTime]; -``` - -Where `settlementTime` is `TxSettlementTime.INSTANT` or `TxSettlementTime.NEXT_ROLLUP`. `INSTANT` settlement is faster, but more expensive. `NEXT_ROLLUP` will wait until the rollup is filled with transactions and then is posted to Ethereum. - -The settlement time is inferred from the fee a user pays, it is not explicitly sent to the controller. - -### Create Proof & Send - -Once the `TransferController` is created, you can create a proof and send the transaction with: - -```ts -await tokenTransferController.createProof(); -await tokenTransferController.send(); -``` - -You can review the full reference code [here](https://github.com/critesjosh/aztec-sdk-starter/blob/mainnet-fork/src/latest/transferNotes.ts). diff --git a/docs/docs/sdk/usage/withdraw.md b/docs/docs/sdk/usage/withdraw.md deleted file mode 100644 index edb012c4c161..000000000000 --- a/docs/docs/sdk/usage/withdraw.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Withdraw ---- - -Withdraw assets from Aztec to Ethereum. - -Use the `WithdrawController` to withdraw assets from Aztec to Ethereum. - -You can find the interface of the `WithdrawController` [here](../types/sdk/WithdrawController). - -### Controller Setup - -```ts -AztecSdk.createWithdrawController( - userId: GrumpkinAddress, - userSigner: Signer, - value: AssetValue, - fee: AssetValue, - to: EthAddress) - : Promise -``` - -### Inputs - -| Arguments | Type | Description | -| --------- | ---- | ----------- | -| userId | [GrumpkinAddress](../types/barretenberg/GrumpkinAddress) | The Aztec account to make the withdrawal from. | -| userSigner | [Signer](../types/sdk/Signer) | A signer for the provided `userId`. | -| value | [AssetValue](../types/barretenberg/AssetValue) | The asset type and amount to withdraw. | -| fee | [AssetValue](../types/barretenberg/AssetValue) | The asset type and amount to pay for the Aztec transaction fee. | -| to | [EthAddress](../types/barretenberg/EthAddress) | The Ethereum address to send the funds on Ethereum. | - -#### Returns - -| Return Type | Description | -| --------- | ----------- | -| [WithdrawController](../types/sdk/WithdrawController) | A user instance with apis bound to the user's account id. | - -### Fees - -Fees for withdrawals are calculated using a similar method as for [registrations](register#calculating-fees), deposits and [transfers](transfer#transfer-fees), but using the `getWithdrawalFees` method. - -`getWithdrawalFees` has a second optional options argument. - -```ts -interface GetFeeOptions { - userId?: GrumpkinAddress; - userSpendingKeyRequired?: boolean; - excludePendingNotes?: boolean; - feeSignificantFigures?: number; -} & { recipient?: EthAddress; assetValue?: AssetValue } -``` - -`recipient?: EthAddress` is used to check if the recipient address is a contract wallet, for which the fees are higher. - -The settlement time is inferred from the fee a user pays, it is not explicitly sent to the controller. - -### Executing a Withdrawal - -A withdrawal setup and execution looks like this: - -```ts -const tokenAssetId = sdk.getAssetIdByAddress(tokenAddress); - -const tokenAssetValue = { assetId: tokenAssetId, value: tokenQuantity }; - -// optional fee options -// not relevant if using FeeController -const feeOptions = { - userId: aztecPublicKey, - userSpendingKeyRequired: true, - excludePendingNotes: true, - feeSignificantFigures: 2, - assetValue: tokenAssetValue, - recipient: ethAddress -} - -const tokenWithdrawFee = (await sdk.getWithdrawFees(tokenAssetId, feeOptions))[settlementTime]; - -const tokenWithdrawController = sdk.createWithdrawController( - user, - signer, - tokenAssetValue, - tokenWithdrawFee, - recipientEthereumAddress -); - -await tokenWithdrawController.createProof(); -let txId = await tokenWithdrawController.send(); -``` - -Once the transaction is sent, you just have to wait for the rollup to settle on Ethereum and the Rollup processor contract will send the funds. diff --git a/docs/docs/spec/SUMMARY.md b/docs/docs/spec/SUMMARY.md deleted file mode 100644 index b5eed0833ddc..000000000000 --- a/docs/docs/spec/SUMMARY.md +++ /dev/null @@ -1,27 +0,0 @@ -# Summary - -- [Intro](./intro.md) -# Other - -- [Primitives](./primitives.md) - - [Schnorr Signatures](./schnorr.md) - - [Schnorr Multi-Signatures](./schnorr_multisig.md) - - [Unsigned integers](./uint.md) -- [Notes & Nullifiers](./notes_and_nullifiers.md) -- [Defi Bridge Interface](./defi_bridge_interface.md) - -# 'App' Circuits - -- [Account Circuit](./account_circuit.md) -- [Join-Split Circuit](./join_split_circuit.md) -- [Claim Circuit](./claim_circuit.md) - -# Rollup Circuits - -- [Rollup Circuit](./rollup_circuit.md) -- [Root Rollup Circuit](./root_rollup_circuit.md) -- [Root Verifier Circuit](./root_verifier_circuit.md) - -# Contracts - -- [Rollup Contract](./rollup_contract.md) \ No newline at end of file diff --git a/docs/docs/spec/account_circuit.md b/docs/docs/spec/account_circuit.md deleted file mode 100644 index a5c1c5fb44f3..000000000000 --- a/docs/docs/spec/account_circuit.md +++ /dev/null @@ -1,209 +0,0 @@ -# Account Circuit - -## Background - -Aztec accounts are different from Ethereum addresses, mainly because deriving an Ethereum address is expensive (constraint-wise) within a circuit. Also, Aztec accounts have several extra features: - -- A human-readable name (an `alias`) can be associated with an account public key. -- Multiple (unlimited) spending keys (a.k.a. signing keys) can be associated with an `alias` and its `account_public_key`, to enable users to more-easily spend from multiple devices (for example). -- Spending keys can also be used for account recovery (e.g. with the aid of a 3rd party). -- If the account private key is compromised, a user can migrate to a new `account_public_key`. (They would also need to transfer all of their existing value notes to be owned by this new `account_public_key`). -- If a spending private key is compromised, a user can also migrate to a new `account_public_key`, and a brand new set of spending keys can be associated with this new `account_public_key`. (They would also need to transfer all of their existing value notes to be owned by this new `account_public_key`). - -Keys: - -- Spending/signing keys are used to _spend_ value notes. -- Account keys are used to decrypt encrypted value note data. - - Also, initially (before any alias or signing keys are linked to the account), the 0th account key serves as a spending key for a user's value notes. Thereafter only spending keys can be used to spend notes. - -_See the diagram (below) for derivations of the various keys._ - -## Keys - -| Key Name | Derivation | -| --------------------- | ---- | -| `eth_private_key` | Random 256 bits | -| `eth_public_key` | `eth_private_key * secp256k1.generator` | -| `eth_address` | The right-most 160-bits of `keccak256(eth_public_key)` | -| `account_private_key` | The first 32-bytes of the signature:
`eth_sign("\x19Ethereum Signed Message:\n" + len(message) + message, eth_address)`*

where `message = "Sign this message to generate your Aztec Privacy Key. This key lets the application decrypt your balance on Aztec.\n\nIMPORTANT: Only sign this message if you trust the application."`

*using a client which has access to your `eth_address`'s private key, for signing.| -| `account_public_key` | `account_private_key * grumpkin.generator` | -| `spending_private_key`
a.k.a. `signing_private_key`| Random 256 bits | -| `spending_public_key`
a.k.a. `signing_public_key` | `spending_private_key * grumpkin.generator` | - - -## Account Glossary - -| Name | Definition | Description | -| --------------------- | --- | --- | -| account | | An account is generally used to mean an `(alias_hash, account_public_key)` pair.| -| `alias` | E.g. `alice` | Some unique human-readable string. | -| `alias_hash` | The first 28-bytes of `blake2s_to_field(alias)`.
QUESTION: how does the output of blake2s get mapped to a field element? | A constant-sized representation of an `alias`, for use in circuits. | -| `account_note` | 
{
  alias_hash,
  account_public_key
  spending_public_key
}
| Links together a user's `alias_hash`, their `account_public_key` and one of their `spending_public_key`s.

A user can register multiple account notes as a way of registering multiple `spending_public_keys` against their account. They might, for example, want to be able to spend from different devices without needing to share keys between them.

A user can also create a new account note as a way of registering a new `account_public_key` against their `alias_hash`. Ideally, a user would use just one `account_public_key` at a time (and transfer all value notes to be owned by that `account_public_key`), but this is not enforced by the protocol. | -| `account_note.commitment` | 
pedersen::compress(
  alias_hash,
  account_public_key.x,
  spending_public_key.x
)
| Each account note commitment is stored in the data tree, so that our circuits can check whether spending and account keys have been correctly registered and actually belong to the user executing the transaction. | -| `alias_hash_nullifier` | 
pedersen::compress(
  alias_hash
)
| This nullifier is added to the nullifier tree (by the rollup circuit) when executing the account circuit in `create` mode. It prevents an `alias` from ever being registered again by another user. | -| `account_public_key_nullifier` | 
pedersen::compress(
  account_public_key.x,
  account_public_key.y
)
| This nullifier is added to the nullifier tree (by the rollup circuit) when executing the account circuit in `create` or `migrate` modes. It prevents an `account_public_key` from ever being registered again by another user. | - -## Modes: create, update, migrate - -The account circuit can be executed in one of three 'modes': - -- **Create** - - Used to register a new `alias`. - - A new 'account' is registered by generating nullifiers for a new `alias_hash` and a new `account_public_key`. This ensures the `alias_hash` and `account_public_key` haven't already been registered by someone else. - - Two new `account_notes` may be created, as a way of registering the first two new `spending_public_keys` against the new account. - - The circuit enforces that the caller knows the private key of `account_public_key`, by checking that a signature over the circuit's inputs has been signed by the `account_private_key`. We need to do this, in part, because the owner of this `account_public_key` might already have been sent value notes, even before registering it with Aztec Connect. - - > Note: there are no protocol checks to ensure these new `spending_public_keys` (which are added to `account_notes`) are new or unique. - - > Note: There are no protocol checks during `create`, to ensure the user knows private keys to these `spending_public_keys`. -- **Update** - - Used to add _additional_ spending keys to an account. - - Every account tx in `update` mode adds up-to two new spending keys to an account. - - Two new `account_notes` are created, as a way of registering the two new `spending_public_keys` against the account. - - No nullifiers are produced. - - The circuit enforces that the caller knows the private key of an existing `signing_public_key` for this account, by: - - checking that a signature over the circuit's inputs has been signed by a `signing_private_key`; and - - checking that this `signing_public_key` is contained in an `account_note`'s commitment and that this commitment exists in the data tree. - - > Note: There are no protocol checks during `update`, to ensure the user knows private key to the `account_public_key`. -- **Migrate** - - Used to update a user's `account_public_key` without changing their `alias`. - - The new 'account' is registered by generating a nullifier for the new `account_public_key`. - - Two new `account_notes` may be created, as a way of registering the first two new `spending_public_keys` against this new account. - - The circuit enforces that the caller knows the private key of an existing `signing_public_key` for this account, by: - - checking that a signature over the circuit's inputs has been signed by a `signing_private_key`; and - - checking that this `signing_public_key` is contained in an `account_note`'s commitment and that this commitment exists in the data tree. - - > Note: There are no protocol checks during `migrate`, to ensure the user knows private key to the `account_public_key`. - -### When to migrate? - -If a user, Alice, suspects their `account_private_key` or `spending_private_key` have been compromised, then they should run the account circuit in `migrate` mode. As already stated, this will associate a new `account_public_key` to their `alias` and allow them to register new `spending_public_keys` against this new `account_public_key`. Two new account notes get created by the account circuit in `migrate` mode. - -HOWEVER, the previous, 'old' account notes (containing the 'old' compromised key(s)), DO NOT get nullified. They are forever 'valid' notes in the data tree. Therefore, if Alice still owns _value_ notes which are owned by one of her old `account_public_keys`, an attacker (who somehow knows the _private_ key and a corresponding old `spending_private_key`) would still be able to spend such value notes. Therefore, after migrating their account, a user MUST ALSO transfer all of their existing notes to be owned by their new `account_public_key`. - -## Example of account circuit modes - -Each row of the table shows the data created by one execution of the account circuit. Rows are chronologically ordered. - -| Mode | alias | alias_hash | account public key | new spending keys | signer | new `alias_hash_`
`nullifier` emitted | new `account_`
`public_key_`
`nullifier` emitted | new account note commitments | -|---|---|---|---|---|---|---|---|---| -| create | `alice` | `h(alice)` | `apk_1` | `spk_1a, spk_1b` | `apk_1` | `h(h(alice))` | `h(apk_1.x, apk_1.y)` | `h(h(alice), apk_1, spk_1a)`

`h(h(alice), apk_1, spk_1b)` | -| update | `alice` | `h(alice)` | `apk_1` | `spk_1c, spk_1d` | `spk_1b` (e.g.) | - | - | `h(h(alice), apk_1, spk_1c)`

`h(h(alice), apk_1, spk_1d)` | -| update | `alice` | `h(alice)` | `apk_1` | `spk_1e, spk_1f` | `spk_1a` (e.g.) | - | - | `h(h(alice), apk_1, spk_1e)`

`h(h(alice), apk_1, spk_1f)` | -| migrate | `alice` | `h(alice)` | `apk_2` | `spk_2a, spk_2b` | `spk_1d` (e.g.) | - | `h(apk_2.x, apk_2.y)` | `h(h(alice), apk_2, spk_2a)`

`h(h(alice), apk_2, spk_2b)` | -| update | `alice` | `h(alice)` | `apk_2` | `spk_2c, spk_2d` | `spk_2b` (e.g.) | - | - | `h(h(alice), apk_2, spk_2c)`

`h(h(alice), apk_2, spk_2d)` | - -> Note: `h` is lazy notation, being used interchangeably in this table for different hashes. Consult the earlier tables or the below pseudocode for clarity on which hashes specifically are used. -> Note: after an account `migrate`, all previous value notes should be transferred (via the join-split circuit) to be owned by the new account public key. - -## More on Nullifiers - -Unlike the join-split circuit (for example), which always produces nullifiers, the account circuit only conditionally produces nullifiers (see the different modes above). It's possible for `nullifier_1` or `nullifier_2` to be `0`: - -- `nullifier_1 = create ? pedersen::compress(account_alias_hash) : 0;` - -- `nullifier_2 = (create || migrate) ? pedersen::compress(account_public_key) : 0` - -> Note: The rollup circuit for Aztec Connect permits unlimited `0` nullifiers to be added to the nullifier tree, because: -> - Each nullifier is added to the nullifier tree at the leaf index which is equal to the nullifier value. -> - So the rollup circuit will try to add `nullifier = 0` to `leafIndex = 0`. -> - First it checks whether the leaf is empty. Well `0` implies "empty", so this check will pass, and the value `0` will be once-again added to the 0th leaf. - -## Diagram - -[Here's](https://drive.google.com/file/d/1iscYm-B89I9LIB7YgM_L9cHaV6SSMjRT/view?usp=sharing) a detailed diagram of how all of Aztec's different keypairs are derived, and the flow of account creation and migration. (Edits are welcome - let Mike know if the link doesn't work). - -# The circuit - -## Account Circuit: Worked Example - -_There's a little diagram at the diagrams link too._ - -1. Alice generates a grumpkin key pair `(account_private_key, account_public_key)`. -1. Alice can receive funds prior to registering an `alias` at `(account_public_key)` - - I.e. a sender can send Alice funds by creating a value note with preimage values: - - `owner = account_public_key` - - `requires_account = false` -1. Alice can register the alias `alice` against her `account_public_key` using the account circuit. - - The `alias_hash = hash('alice')` gets nullified, effectively 'reserving' the alias `alice` to prevent anyone else using it. - - The `account_public_key` gets nullified, to prevent anyone else using it. - - Alice's `new_account_public_key`, her `alias_hash`, and two new spending keys, are all linked together via two new account notes which get added to the data tree. -2. Alice must then transfer any previously-received funds that were sent to `(account_public_key)` (i.e. value notes where `requires_account = false`), to value notes whose primage values contain `(account_public_key, requires_account = true)`. -3. Alice can register unlimited additional spending keys to `(alice, account_public_key)`, via additional calls to the account circuit (in `upgrade` mode). -4. If a `spending_public_key` becomes compromised, Alice must do the following: - -- generate a _new_ account note with a `new_account_public_key` and her existing `alice` alias (using the `migrate` flow). The new account note's spending keys SHOULD be different to the compromised key (although there are no protocol checks to enforce this). -- Use the account `update` flow to assign additional _non-compromised_ spending keys to her new account note`. -- Alice transfers funds assigned to `(account_public_key, alice)` and sends them to `(new_account_public_key, alice)` - -1. Similarly, if Alice's `account_private_key` becomes compromised, she can use the account circuit to migrate to a new `account_public_key`. - -## Circuit Inputs: Summary - -The inputs for the account circuit are: - -$$ -\text{Account Inputs} = (\text{Public Inputs}, \text{Private Inputs}) \in \mathbb{F}\_p^{13} \times \mathbb{F}\_p^{25} -$$ - -As previously, the field $\mathbb{F}_p$ is from the BN254 specification. - -### Public Inputs: Detail - -Recall that all inner circuits must have the **same number of public inputs** as they will be used homogeneously by the rollup circuit. Hence, most of the account circuit's public inputs are 0, because they're not actually needed for the account circuit's functionality. - -1. `proof_id = PublicInputs::ACCOUNT` (i.e. this is effectively a witness which can only take one valid value). -1. `output_note_commitment_1` -1. `output_note_commitment_2` -1. `nullifier_1` -1. `nullifier_2` -1. `public_value = 0` -1. `public_owner = 0` -1. `asset_id = 0` -1. `data_tree_root` -1. `tx_fee = 0` -1. `tx_fee_asset_id = 0` -1. `bridge_call_data = 0` -1. `defi_deposit_value = 0` -1. `defi_root = 0` -1. `backward_link = 0` -1. `allow_chain = 0` - -### Private Inputs: Detail - -1. `account_public_key` -1. `new_account_public_key` -1. `signing_public_key` -1. `signature` -1. `new_signing_public_key_1` -1. `new_signing_public_key_1` -1. `alias_hash = blake2s(alias).slice(0, 28)` -1. `account_nonce` -1. `create` (bool) -1. `migrate` (bool) -1. `account_note_index` -1. `account_note_path` - -## Circuit Logic (Pseudocode) - -Computed vars: - -- `signer` = `signing_public_key` -- `message` = `pedersen::compress(alias_hash, account_public_key.x, new_account_public_key.x, spending_public_key_1.x, spending_public_key_2.x, nullifier_1, nullifier_2)` -- `account_note_commitment` = `pedersen::compress(alias_hash, account_public_key.x, signer.x)` - -Computed public inputs: - -- `output_note_commitment_1` = `pedersen::compress(alias_hash, new_account_public_key.x, spending_public_key_1.x)` -- `output_note_commitment_2` = `pedersen::compress(alias_hash, new_account_public_key.x, spending_public_key_2.x)` -- `nullifier_1` = `create ? pedersen::compress(alias_hash) : 0;` -- `nullifier_2` = `create || migrate ? pedersen::compress(new_account_public_key)` - -Circuit constraints: - -- `create == 1 || create == 0` -- `migrate == 1 || migrate == 0` -- `require(create && migrate == 0)` -- `require(new_account_public_key != spending_public_key_1)` -- `require(new_account_public_key != spending_public_key_2)` -- `if (migrate == 0) { require(account_public_key == new_account_public_key) }` -- `verify_signature(message, signer, signature) == true` -- `if (create == false) { require(membership_check(account_note_data, account_note_index, account_note_path, data_tree_root) == true) }` -- Assert all 'zeroed' public inputs are indeed zero. diff --git a/docs/docs/spec/claim_circuit.md b/docs/docs/spec/claim_circuit.md deleted file mode 100644 index b6f058809695..000000000000 --- a/docs/docs/spec/claim_circuit.md +++ /dev/null @@ -1,182 +0,0 @@ -# Claim circuit - -This circuit enables converting a claim note into two value notes, according to the defi interaction result. - -## Diagrams - -- [The entire defi process](https://drive.google.com/file/d/1rbBywUqM78RkCNcI0jmie6-N79PY0lqv/view?usp=sharing) - -## Before the claim circuit - -A defi interaction is a multi-step process which _ends_ with the claim circuit being verified on-chain. There are more complete explanations of the whole process for many individual dApps on hackmd under the 'Aztec Connect' tag. -Here's a very brief summary of the defi interaction process: - -- A user wishes to interact with an Ethereum L1 dApp privately. They can use Aztec Connect to hide their identity from observers. The values they send will still be visible (but not traceable back to them). Let's use Uniswap as an example. -- The user wishes to convert 1 ETH to DAI tokens. -- They submit a 'defi deposit' of 1 ETH. - - A join-split proof is generated in 'defi deposit' mode, which spends the 1 ETH and creates a partial claim note (see the diagrams or the join-split markdown file). -- The rollup provider bundles (sums) the user's request to deposit 1 ETH into uniswap with the requests of any other users who wanted to deposit ETH to uniswap. User costs are amortised this way. -- The rollup provider is able to assign a `bridge_call_data` to each 'bundle', and with knowledge of this `bridge_call_data` and the `total_input_value` being deposited, the rollup provider can 'complete' each user's partial claim note. I.e. the rollup provider creates a completed 'claim note' for each user. This claim note can be used later in the process to withdraw DAI via the claim circuit. -- This bundled (summed) deposit of X ETH is sent to a 'Defi Bridge Contract' - a contract specifically designed to perform swaps between Aztec Connect users and Uniswap. -- The Defi Bridge Contract sends the `total_input_value = X` ETH to Uniswap (along with some parameters which we won't go into here), and receives back Y DAI. -- The rollup contract emits an event which says "X ETH was swapped for Y DAI, and here is a 'defi interaction nonce' which represents this interaction". -- The rollup provider listens for this event to learn whether their interaction was successful, and to learn the new data: `total_output_value_a = Y`, `defi_interaction_nonce = defi_interaction_nonce`. -- The rollup provider is now in a position to submit a _claim_ (using the claim circuit) _on behalf of_ each user who partook in the defi interaction. - - Take note of this. Submission of a claim needn't be done by the user; no private key is required. The rollup provider is incentivised to generate a claim proof by being offered a fee via the earlier join-split proof. - -Now we can get into the details of the claim circuit. - -## Claim circuit - -At a high level, the claim circuit does the following: - -- Spends a user's claim note; -- Refers to a particular defi interaction note (which contains uniquely-identifying details of a particular defi interaction); -- Outputs up-to two output 'value notes' whose values are proportional to the amount originally defi-deposited by this user. - - `output_note_1.value = ( user_input_amount / total_input_amount ) * total_output_amount_a` - - `output_note_2.value = ( user_input_amount / total_input_amount ) * total_output_amount_b` - -(In our earlier example, `ouput_note_1.value = ( 1 / X ) * Y` DAI). - -### Details - -#### Inputs - -Recall that all inner circuits must have the **same number of public inputs** as they will be used homogeneously by the rollup circuit. Hence, some of the inputs to a claim circuit are unused and so set to 0. - -##### Public Inputs - -- `proof_id = ProofIds::DEFI_CLAIM` -- `output_note_commitment_1` -- `output_note_commitment_2` -- `nullifier1` -- `nullifier2` -- `public_value = 0` -- `public_owner = 0` -- `asset_id = 0` -- `data_root` -- `claim_note.fee` -- `claim_note_data.bridge_call_data_local.input_asset_id` -- `claim_note.bridge_call_data` -- `defi_deposit_value = 0` -- `defi_root` -- `backward_link = 0` -- `allow_chain = 0` - -##### Private Inputs - -- `claim_note_index` -- `claim_note_path` -- ``` - claim_note: { - deposit_value, - bridge_call_data, // actually a public input - defi_interaction_nonce, - fee, // actually a public input - value_note_partial_commitment, - input_nullifier, - } - ``` -- `defi_interaction_note_path` -- ``` - defi_interaction_note: { - bridge_call_data, - defi_interaction_nonce, - total_input_value, - total_output_value_a, - total_output_value_b, - defi_interaction_result, - commitment, - } - ``` -- `output_value_a` -- `output_value_b` - -#### Circuit Logic (Pseudocode) - -_Note: for Pedersen commitments, different generators are used for different types of commitment._ - -Computed vars: - -- Extract data from the `claim_note.bridge_call_data`: - - - ``` - bridge_call_data_local = { - bridge_address_id, // represents a defi bridge contract address - input_asset_id_a, - input_asset_id_b, // if virtual, is the defi_interaction nonce from when a loan/LP position was opened - output_asset_id_a, - output_asset_id_b, - - // during some earlier defi interaction by the user - bit_config, - aux_data, - } - ``` - -- The same data is also currently extracted from the `defi_interaction_note.bridge_call_data`. This is redundant, but we'll only need to remove these extra constraints if we ever approach the next power of 2. -- Extract config data from `bit_config`: - - ``` - bit_config = { - second_input_in_use, - second_output_in_use, - } - ``` -- ``` - claim_note.commitment = pedersen( - pedersen(deposit_value, bridge_call_data, value_note_partial_commitment, input_nullifier), - defi_interaction_nonce, - fee, - ) - ``` -- ``` - defi_interaction_note.commitment = pedersen( - bridge_call_data, - total_input_value, - total_output_value_a, - total_output_value_b, - defi_interaction_nonce, - defi_interaction_result, - ) - ``` -- `output_value_1 = defi_interaction_result ? output_value_a : claim_note.deposit_value` (give a refund if the interaction failed). -- `output_asset_id_1 = defi_interaction_result ? output_asset_id_a : input_asset_id` -- `output_value_2 = second_output_virtual ? output_value_a : output_value_b` - - If the second output is virtual, its value must equal that of the first output. -- `output_asset_id_2 = second_output_virtual ? concat(1, defi_interaction_nonce) : output_asset_id_b` - - If virtual, attach a record of this 'opening defi interaction nonce' to the note, via the asset_id field. - -Checks: - -- Many values are range-checked. See [constants.hpp](https://github.com/AztecProtocol/aztec-connect/blob/master/barretenberg/src/aztec/rollup/proofs/notes/constants.hpp) and [constants.hpp](https://github.com/AztecProtocol/aztec-connect/blob/master/barretenberg/src/aztec/rollup/constants.hpp) for the variables whose bit-lengths are constrained. -- Check `bit_config` vars: -- Extract `second_input_in_use` and `second_output_in_use` from `claim_note_data.bridge_call_data_local.config` -// The below six constraints are exercised in bridge_call_data.hpp, see comments there for elaboration -- `!(input_asset_id_b.is_zero) must_imply config.second_input_in_use` -- `!(input_asset_id_b.is_zero) must_imply config.second_output_in_use` -- `config.second_input_in_use must_imply input_asset_id_a != input_asset_id_b` -- `config.second_output_in_use && both_outputs_real must_imply output_asset_id_a != output_asset_id_b` -- `first_output_virtual must_imply output_asset_id_a == virtual_asset_id_placeholder` -- `second_output_virtual must_imply output_asset_id_b == virtual_asset_id_placeholder` -- `require(claim_note.deposit_value != 0)` -- `require(deposit_value <= total_input_value)` -- `require(output_value_a <= total_output_value_a)` -- `require(output_value_b <= total_output_value_b)` -- `require(claim_note.bridge_call_data == defi_interaction_note.bridge_call_data)` -- `require(claim_note.defi_interaction_nonce == defi_interaction_note.defi_interaction_nonce)` -- Check claim note exists in the data tree using `data_root, claim_note_path, claim_note_index, claim_note.commitment`. -- Check defi interaction note exists in the data tree using `defi_root, defi_interaction_note_path, defi_interaction_nonce`. - - Note: the leaf index of a defi interaction note is its `defi_interaction_nonce`. The `defi_interaction_nonce` is derived in the rollup circuit at the time the defi deposit (join split) is processed. - -Ratio Checks (very complex code): - -- Ensure `output_value_a == (deposit / total_input_value) * total_output_value_a`, unless `output_value_a == 0 && total_output_value_a == 0` (i.e. unless no value was returned by the bridge contract for output_a). -- Ensure `output_value_b == (deposit / total_input_value) * total_output_value_b`, unless `output_value_b == 0 && total_output_value_b == 0` (i.e. unless no value was returned by the bridge contract for output_b). -- (Also prevent zero denominators `total_input_value`, `total_output_value_a`, and `total_output_value_b`). - -Computed public inputs: - -- `nullifier_1 = pedersen(claim_note.commitment)` -- `nullifier_2 = pedersen(defi_interaction_note.commitment, claim_note.commitment)` -- `output_note_commitment1 = pedersen(value_note_partial_commitment, output_value_1, output_asset_id_1, nullifier_1)` -- `output_note_commitment2 = (second_output_virtual ^ second_output_real) ? pedersen(value_note_partial_commitment, output_value_2, output_asset_id_2, nullifier_2) : 0` diff --git a/docs/docs/spec/defi_bridge_interface.md b/docs/docs/spec/defi_bridge_interface.md deleted file mode 100644 index ca62706fd72c..000000000000 --- a/docs/docs/spec/defi_bridge_interface.md +++ /dev/null @@ -1,98 +0,0 @@ -# Defi Bridge Contract Interface - -## Types - -``` -library AztecTypes { - enum AztecAssetType { - NOT_USED, - ETH, - ERC20, - VIRTUAL - } - - struct AztecAsset { - uint256 id; - address erc20Address; - AztecAssetType assetType; - } -} -``` - -The `AztecAsset` struct is an attempt at a more developer-friendly description of an Aztec asset that does not rely on bit flags. - -The _type_ of the asset is described by an enum. For virtual or not used assets, the `erc20Address` will be 0. - -For input virtual assets, the `id` field will contain the interaction nonce of the interaction that created the asset. - -For output virtual assets, the `id` field will be the current interaction nonce. - -## External Methods - -### convert - -Initiate a DeFi interaction and inform the rollup contract of the proceeds. If the DeFi interaction cannot proceed for any reason, it is expected that the convert method will throw. - -```solidity - function convert( - AztecTypes.AztecAsset memory inputAssetA, - AztecTypes.AztecAsset memory inputAssetB, - AztecTypes.AztecAsset memory outputAssetA, - AztecTypes.AztecAsset memory outputAssetB, - uint256 totalInputValue, - uint256 interactionNonce, - uint64 auxData - ) - external - payable - override - returns ( - uint256 outputValueA, - uint256 outputValueB, - bool _isAsync - ) -``` - -###### Input Values: - -| Name | Type | Description | -| ------------------ | ------------ | ------------------------------------------------------------------------------------------------ | -| `inputAssetA` | _AztecAsset_ | first input asset | -| `inputAssetB` | _AztecAsset_ | second input asset. Either VIRTUAL or NOT_USED | -| `outputAssetA` | _AztecAsset_ | first output asset. Cannot be virtual | -| `outputAssetB` | _AztecAsset_ | second output asset. Can be real or virtual (or NOT_USED) | -| `totalInputValue` | _uint256_ | The amount of `inputAsset` this bridge contract is allowed to transfer from the rollup contract. | -| `interactionNonce` | _uint256_ | The current defi interaction nonce | -| `auxData` | _uint64_ | Custom auxiliary metadata | - -###### Return Values: - -| Name | Type | Description | -| -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `outputValueA` | _uint256_ | The amount of `outputAssetA` the rollup contract will be able to transfer from this bridge contract. Must be greater than 0 if `numOutputAssets` is 1. | -| `outputValueB` | _uint256_ | The amount of `outputAssetB` the rollup contract will be able to transfer from this bridge contract. Must be 0 if `numOutputAssets` is 1. | - -In the unfortunate event when both output values are zeros, this function should throw so that the rollup contract could refund `inputValue` back to the users. - -[^1]: BridgeCallData is a 250-bit concatenation of the following data (starting at the most significant bit position): - -| bit position | bit length | definition | description | -| ------------ | ---------- | ----------------- | ----------------------------------------------------------------------------------- | -| 0 | 64 | `auxData` | custom auxiliary data for bridge-specific logic | -| 64 | 32 | `bitConfig` | flags that describe asset types | -| 96 | 32 | `openingNonce` | (optional) reference to a previous defi interaction nonce (used for virtual assets) | -| 128 | 30 | `outputAssetB` | asset id of 2nd output asset | -| 158 | 30 | `outputAssetA` | asset id of 1st output asset | -| 188 | 30 | `inputAsset` | asset id of 1st input asset | -| 218 | 32 | `bridgeAddressId` | id of bridge smart contract address | - -Bit Config Definition - -| bit | meaning | -| --- | --- | -| 0 | firstInputVirtual | -| 1 | secondInputVirtual | -| 2 | firstOutputVirtual | -| 3 | secondOutputVirtual | -| 4 | secondInputReal | -| 5 | secondOutputReal | diff --git a/docs/docs/spec/intro.md b/docs/docs/spec/intro.md deleted file mode 100644 index 82b14454c688..000000000000 --- a/docs/docs/spec/intro.md +++ /dev/null @@ -1,17 +0,0 @@ -# Intro - -This directory contains the Aztec Connect specifications. - -The protocol is broken up into explicit subcomponents each with a specification: - -* The rollup smart contract architecture -* Definitions of notes and nullifiers -* ZK-SNARK circuit primitives -* circuit specification for evaluating unsigned integer arithmetic -* Schnorr signature specification -* Account circuit specification -* Join-split circuit specification -* Defi claim circuit specification -* Rollup circuit specification (sometimes referred to as "inner rollup") -* Root rollup circuit specification (sometimes referred to as "outer rollup") -* Root verifier circuit specification \ No newline at end of file diff --git a/docs/docs/spec/join_split_circuit.md b/docs/docs/spec/join_split_circuit.md deleted file mode 100644 index f2c769c7001d..000000000000 --- a/docs/docs/spec/join_split_circuit.md +++ /dev/null @@ -1,377 +0,0 @@ -# JoinSplit Circuit - -### Circuit Description - -This circuit allows notes to be spent. - -The circuit takes in two input notes, and two new output notes, and updates the Note Tree and Nullifier Tree accordingly. - -### Circuit Inputs: Summary - -The inputs for the join-split circuit are all elements of the field $\mathbb{F}_p$ from the BN254 specification. - -### Public Inputs: Detail - -1. `proof_id` -1. `output_note_commitment_1` -1. `output_note_commitment_2` -1. `nullifier_1` -1. `nullifier_2` -1. `public_value` -1. `public_owner` -1. `public_asset_id` - -1. `old_data_tree_root` -1. `tx_fee` -1. `tx_fee_asset_id` -1. `bridge_call_data` -1. `defi_deposit_value` -1. `defi_root` // Note: this will not be used by the circuit, but is included so that the number of public inputs is uniform across base-level circuits. -1. `backward_link` -1. `allow_chain` - -### Private Inputs: Detail - -```js -{ - asset_id, - num_input_notes, - - input_note_1_index, - input_note_2_index, - - input_note_1_path, - input_note_2_path, - - input_note_1: { - value, - secret, - owner, - asset_id, - account_required, - creator_pk, - input_nullifier, - }, - - input_note_2: { - value, - secret, - owner, - asset_id, - account_required, - creator_pk, - input_nullifier, - }, - - output_note_1: { - value, - secret, - owner, - asset_id, - account_required, - creator_pk, // (creator_pk = optional public key of note creator) - input_nullifier, - }, - - output_note_2: { - value, - secret, - owner, - asset_id, - account_required, - creator_pk, // (creator_pk = optional public key of note creator) - input_nullifier, - }, - - partial_claim_note_data: { - deposit_value, - bridge_call_data_local: { - bridge_address_id, - input_asset_id_a, - input_asset_id_b, - output_asset_id_a, - output_asset_id_b, - config: { - second_input_in_use, - second_output_in_use, - }, - aux_data, - }, - note_secret, - input_nullifier, - }, - - account_private_key, - alias_hash, - account_required, - account_note_index, - account_note_path, - - signing_pk, // (a.k.a. spending public key) - signature, -} -``` - -### Index of Functions - -In the Pseudocode to follow, we use the following function names. See [notes & nullifiers](./notes_and_nullifiers.md) for more details. - -- `public_key()` derives a public key from a given secret key. -- `value_note_commit()` - **Value note commitment function**, which is assumed to be - - Collision-resistant - - Field-friendly, which means the output value only depends on the inputs as field elements, and doesn’t change e.g. when input changes from a to a+r as bit string. -- `partial_value_note_commit()` - **Partial value note commitment function**. Has the same assumptions as `value_note_commit`. Uses a different generator. Stresses that the data being committed to is _partial_ - a subset of the data committed to by `value_note_commit`. -- `partial_claim_note_commit()` - **Partial claim note commitment function**. Has the same assumptions as `value_note_commit`. Uses a different generator. Stresses that the data being committed to is _partial_ - a subset of the data committed to by `claim_note_commit` (in the claim circuit). -- `account_note_commit()` - **Account note commitment function**, which is assumed to be collision resistant. -- `compute_nullifier()` - **Nullifier Function**, which we assume can be modeled as a random oracle, and only depends on `account_private_key` $mod r$. - -### Circuit Logic (Pseudocode) - -```js - -// range checks: - for i = 1,2: - { - check: - input_note_i_index < 2 ** DATA_TREE_DEPTH - input_note_i.value < 2 ** NOTE_VALUE_BIT_LENGTH - output_note_i.value < 2 ** NOTE_VALUE_BIT_LENGTH - } - - partial_claim_note.deposit_value < 2 ** DEFI_DEPOSIT_VALUE_BIT_LENGTH - - asset_id < 2 ** MAX_NUM_ASSETS_BIT_LENGTH - public_value < 2 ** NOTE_VALUE_BIT_LENGTH - tx_fee < 2 ** TX_FEE_BIT_LENGTH - - account_note_index < 2 ** DATA_TREE_DEPTH - alias_hash < 2 ** ALIAS_HASH_BIT_LENGTH - account_required < 2 - - num_input_notes in {0, 1, 2} - allow_chain in {0, 1, 2, 3} - -// tx type initialisations: - const is_deposit = proof_id == DEPOSIT - const is_withdraw = proof_id == WITHDRAW - const is_send = proof_id == SEND - const is_defi_deposit = proof_id == DEFI_DEPOSIT - const is_public_tx = is_deposit || is_withdraw - -// public value initialisations - const public_asset_id = is_public_tx ? asset_id : 0; - const public_input = is_deposit ? public_value : 0; - const public_output = is_withdraw ? public_value : 0; - -// account initialisations - const account_pk = public_key(account_private_key); - const signer_pk = account_required ? signing_pk.x : account_pk.x; - - const account_note = { - alias_hash, - account_pk, - signer_pk, - }; - const account_note_commitment = account_note_commit(account_note); - -// commitments - for i in 1,2 - { - input_note_i.commitment = value_note_commit(input_note_i); - output_note_i.commitment = value_note_commit(output_note_i); - } - -// Data validity checks: - require(num_input_notes = 0 || 1 || 2); // it's pseudocode! - require(is_deposit || is_send || is_withdraw || is_defi_deposit); - - if(num_input_notes == 0) require(is_deposit); - - if (is_public_tx) { - require(public_value > 0); - require(public_owner > 0); - } else { - require(public_value == 0); - require(public_owner == 0); - } - - require(input_note_1.commitment != input_note_2.commitment); - - require( - (asset_id == input_note_1.asset_id) && - (asset_id == output_note_1.asset_id) && - (asset_id == output_note_2.asset_id) && - ); - - if ( - (num_input_notes == 2) && - !is_defi_deposit - ) { - require(input_note_1.asset_id == input_note_2.asset_id); - } - - require(account_private_key != 0); - - const account_public_key = public_key(account_private_key); - require( - account_public_key == input_note_1.owner && - account_public_key == input_note_2.owner - ); - - require( - account_required == input_note_1.account_required && - account_required == input_note_2.account_required - ); - - if (output_note_1.creator_pubkey) { - require(account_public_key == output_note_1.creator_pubkey); - } - - if (output_note_2.creator_pubkey) { - require(account_public_key == output_note_2.creator_pubkey); - } - -// Defi deposit - - let output_note_1_commitment = output_note_1.commitment; // supersedes output_note_1.commitment frin here on in. - let input_note_2_value = input_note_2.value; // supersedes input_note_2.value from here on in. - let output_note_1_value = output_note_1.value; - let defi_deposit_value = 0; - if (is_defi_deposit) { - const partial_value_note = { - secret: partial_claim_note_data.note_secret, - owner: input_note_1.owner, - account_required: input_note_1.account_required, - creator_pubkey = 0, - }; - const partial_value_note_commitment = partial_value_note_commit(partial_value_note); - - const partial_claim_note = { - deposit_value: partial_claim_note_data.deposit_value, - bridge_call_data: partial_claim_note_data.bridge_call_data_local.to_field(), - partial_value_note_commitment, - input_nullifier: partial_claim_note_data.input_nullifier, - } - const partial_claim_note_commitment = partial_claim_note_commit(partial_claim_note) - - output_note_1_commitment = partial_claim_note_commitment; - - defi_deposit_value = partial_claim_note.deposit_value; - - require(defi_deposit_value > 0); - - const { bridge_call_data_local } = partial_claim_note_data; - const bridge_call_data = bridge_call_data_local.to_field(); - - require(bridge_call_data_local.input_asset_id_a == input_note_1.asset_id); - - if (input_note_2_in_use && (input_note_1.asset_id != input_note_2.asset_id)) { - require(defi_deposit_value == input_note_2.value); - require(bridge_call_data_local.config.second_input_in_use); - input_note_2_value = 0; // set to 0 for the 'conservation of value' equations below. - } - - if (bridge_call_data_local.config.second_input_in_use) { - require(input_note_2_in_use); - require(input_note_2.asset_id == bridge_call_data_local.input_asset_id_b); - } - - output_note_1_value = 0; // set to 0, since the partial claim note replaces it. - } - -// Conservation of value: no value created or destroyed: - const total_in_value = public_input + input_note_1.value + input_note_2_value - const total_out_value = public_output + (is_defi_deposit ? defi_deposit_value : output_note_1_value) + output_note_2.valuue - -// fee - const tx_fee = total_in_value - total_out_value // (no underflow allowed) - - -// Check input notes are valid: - let input_note_1_in_use = num_input_notes >= 1; - let input_note_2_in_use = num_input_notes == 2; - - for i = 1,2: - { - if (input_note_i_in_use) { - const input_note_commitment_i = value_note_commit(input_note_i); - const exists = check_membership( - input_note_commitment_i, input_note_i_index, input_note_i_path, old_data_tree_root - ); - require(exists); - } else { - require(input_note_i.value == 0); - } - } - -// Compute nullifiers - for i = 1,2: - { - nullifier_i = compute_nullifier( - input_note_i.commitment, - account_private_key, - input_note_i_in_use, - ); - } - - require( - output_note_1.input_nullifier == nullifier_1 && - output_note_2.input_nullifier == nullifier_2 && - partial_claim_note.input_nullifier == is_defi_deposit ? nullifier_1 : 0; - ) - -// Verify account ownership - check_membership(account_note_commitment, account_note_index, account_note_path, old_data_tree_root); - - message = ( - public_value, - public_owner, - public_asset_id, - output_note_1_commitment, // notice this is NOT output_note_1.commitment - output_note_2.commitment, - nullifier_1, - nullifier_2, - backward_link, - allow_chain, - ); - - verify_signature( - message, - signature, - signer_public_key - ); - -// Check chained transaction inputs are valid: - const backward_link_in_use = inputs.backward_link != 0; - const note1_propagated = inputs.backward_link == input_note_1.commitment; - const note2_propagated = inputs.backward_link == input_note_2.commitment; - - if (backward_link_in_use) require(note1_propagated || note2_propagated); - - if (is_defi_deposit) require(allow_chain != 1); - - if (inputs.allow_chain == 1) require(output_note_1.owner == input_note_1.owner); - if (inputs.allow_chain == 2) require(output_note_2.owner == input_note_1.owner); - -// Constrain unused public inputs to zero: - require(defi_root == 0); - -// Set public inputs (simply listed here without syntax): - proof_id, - output_note_1_commitment, - output_note_2.commitment, - nullifier_1, - nullifier_2, - public_value, - public_owner, - public_asset_id, - - old_data_tree_root, - tx_fee, - asset_id, - bridge_call_data, - defi_deposit_value, - defi_root, - backward_link, - allow_chain -``` diff --git a/docs/docs/spec/notes_and_nullifiers.md b/docs/docs/spec/notes_and_nullifiers.md deleted file mode 100644 index acda83d8fdf5..000000000000 --- a/docs/docs/spec/notes_and_nullifiers.md +++ /dev/null @@ -1,173 +0,0 @@ -# Notes and Nullifiers - -## Global Constants - -See [constants.hpp](https://github.com/AztecProtocol/aztec-connect/blob/master/barretenberg/src/aztec/rollup/proofs/notes/constants.hpp) and [constants.hpp](https://github.com/AztecProtocol/aztec-connect/blob/master/barretenberg/src/aztec/rollup/constants.hpp) for constants. - -## Pedersen background - -A note on pedersen hashing. - -- `pedersen::commit` returns a point. -- `pedersen::compress` returns the x-coordinate of `pedersen::commit`. - -A different generator is used for each type of note and nullifier (including different generators for partial vs complete commitments). See the hackmd https://hackmd.io/gRsmqUGkSDOCI9O22qWXBA?view for a detailed description of pedersen hashing using turbo plonk. - -Note: `pedersen::compress` is collision resistant (see the large comment above the `hash_single` function in the codebase, see the hackmd https://hackmd.io/urZOnB1gQimMqsMdf7ZBvw for a formal proof), so this can be used in place of `pedersen::commit` for note commitments & nullifiers. - -## Notes and Commitments - -### Account note - -An **Account Note** associates a spending key with an account. It consists of the following field elements. See the dedicated [account_circuit.md](./account_circuit.md) for more details. - -- `alias_hash`: the 224 bit `alias_hash` -- `account_public_key.x`: the x-coordinate of the account public key -- `spending_public_key.x`: the x-coordinate of the spending key that is been assigned to this account via this note. - -An account note commitment is: - -- `pedersen::compress(alias_hash, account_public_key.x, signing_pub_key.x)` - - Pedersen GeneratorIndex: `ACCOUNT_NOTE_COMMITMENT` - -### Value note - -Consists of the following: - -- `secret`: a random value to hide the contents of the - commitment. -- `owner.x` and `owner.y`: the public key of the owner of the value note. This is a Grumpkin point. -- `account_required`: Is the note linked to an existing account or can the note be spent without an account, by directly signing with the owner key -- `creator_pubkey`: Optional. Allows the sender of a value note to inform the recipient who the note came from. -- `value`: the value contained in this note. -- `asset_id`: unique identifier for the 'currency' of this note. The RollupProcessor.sol maps asset_id's with either ETH or the address of some ERC-20 contract. -- `input_nullifier`: In order to create a value note, another value note must be nullified (except when depositing, where a 'gibberish' nullifier is generated). We include the `input_nullifier` here to ensure the commitment is unique (which, in turn, will ensure this note's nullifier will be unique). - -**partial commitment** - -- `pedersen::compress(secret, owner.x, owner.y, account_required, creator_pubkey)` - - Pedersen GeneratorIndex: `VALUE_NOTE_PARTIAL_COMMITMENT` - - `creator_pubkey` can be zero. - -> _Note:_ The `secret` is to construct a hiding Pedersen commitment to hide the note details. - -**complete commitment** - -- `pedersen::compress(value_note_partial_commitment, value, asset_id, input_nullifier)` - - Pedersen GeneratorIndex: `VALUE_NOTE_COMMITMENT` - - `value` and `asset_id` can be zero - -In other words: - -$$ -\begin{align} -&Comm(\text{ValueNote}) = \big( [(\text{note.secret} \cdot g_0 + \text{note.owner.x} \cdot g_1 + \text{note.owner.y} \cdot g_2 + \text{note.account-required} \cdot g_3 \\ -&+ \text{note.creator-pubkey} \cdot g_4).x] \cdot h_0 + \text{note.value} \cdot h_1 + \text{note.asset-id} \cdot h_2 + \text{note.input-nullifier} \cdot h_3 \big) .x -\end{align} -$$ - -(The generator indexing is just for illustration. Consult the code.) - -### Claim note - -Claim notes are created to document the amount a user deposited in the first stage of a defi interaction. Whatever the output token values of the defi interaction, the data in the claim note will allow the correct share to be apportioned to the user. See the [claim circuit doc](./claim_circuit.md) for more details. - -Consists of the following: - -- `deposit_value`: The value that the user deposited in the first stage of their defi interaction. -- `bridge_call_data`: Contains an encoding of the bridge being interacted with. -- `value_note_partial_commitment`: See the above 'value note' section. -- `input_nullifier`: In order to create a claim note, a value note must be nullified as part of the 'defi deposit' join-split transaction. We include that `input_nullifier` here to ensure the claim commitment is unique (which, in turn, will ensure this note's nullifier will be unique). -- `defi_interaction_nonce`: A unique identifier for a particular defi interaction that took place. This is assigned by the RollupProcessor.sol contract, and emitted as an event. -- `fee`: The fee to be paid to the rollup processor, specified as part of the defi deposit join-split tx. Half gets paid to process the defi deposit tx, and half to process the later claim tx. - -**partial commitment** - -- `pedersen::compress(deposit_value, bridge_call_data, value_note_partial_commitment, input_nullifier)` - - Pedersen GeneratorIndex: `CLAIM_NOTE_PARTIAL_COMMITMENT` - - `bridge_call_data` can be zero. - -**complete commitment** - -- `pedersen::compress(claim_note_partial_commitment, defi_interaction_nonce, fee)` - - Pedersen GeneratorIndex: `CLAIM_NOTE_COMMITMENT` - - `fee` and `defi_interaction_nonce` could be zero. - -### Defi Interaction note - -A defi interaction note records the details of a particular defi interaction. It records the total deposited by all users and the totals output by the defi bridge. These totals get apportioned to each user based on the contents of each user's claim note. - -Consists of the following: - -- `bridge_call_data`: Contains an encoding of the bridge that was interacted with. -- `total_input_value`: The total deposited to the bridge by all users who took part in this defi interaction. -- `total_output_value_a`: The sum returned by the defi bridge denominated in 'token A'. (The details of 'token A' are contained in the `bridge_call_data`). -- `total_output_value_b`: The sum returned by the defi bridge denominated in 'token B'. (The details of 'token B' are contained in the `bridge_call_data`). -- `interaction_nonce`: (a.k.a. defi interaction nonce) A unique identifier for a particular defi interaction that took place. This is assigned by the RollupProcessor.sol contract, and emitted as an event. -- `interaction_result`: true/false - was the L1 transaction a success? - -**commitment** - -- `pedersen::compress(bridge_call_data, total_input_value, total_output_value_a, total_output_value_b, interaction_nonce, interaction_result)` - - Pedersen GeneratorIndex: `DEFI_INTERACTION_NOTE_COMMITMENT` - -# Note encryption and decryption - -Details on this are found [here](https://hackmd.io/@aztec-network/BJKHah_4d) - -# Nullifiers - -## Value note nullifier - -**Objectives** of this nullifier: - -- Only the owner of a note may be able to produce the note's nullifier. -- No collisions. Each nullifier can only be produced for one value note commitment. Duplicate nullifiers must not be derivable from different note commitments. -- No collisions between nullifiers of other notes (i.e. claim notes or defi interaction notes). -- No double-spending. Each commitment must have one, and only one, nullifier. -- The nullifier must only be accepted and added to the nullifier tree if it is the output of a join-split circuit which 'spends' the corresponding note. - -**Calculation** -We set out the computation steps below, with suggestions for changes: - -- `hashed_pk = account_private_key * G` (where `G` is a generator unique to this operation). - - This `hashed_pk` is useful to demonstrate to a 3rd party that you've nullified something without having to provide your secret key. -- `compressed_inputs = pedersen::compress(value_note_commitment, hashed_pk.x, hashed_pk.y, is_real_note)` - - This compression step reduces the cost (constrain-wise) of the blake2s hash which is done next. -- `nullifier = blake2s(compressed_inputs);` - - blake2s is needed, because a pedersen commitment alone can leak data (see comment in the code for more details on this). - -Pedersen GeneratorIndex: - -- `JOIN_SPLIT_NULLIFIER_ACCOUNT_PRIVATE_KEY` for the hashed_pk -- `JOIN_SPLIT_NULLIFIER` to compress the inputs - -## Claim note nullifier - -**Objectives** of this nullifier: - -- Anyone (notably the rollup provider) may be able to produce this nullifier. -- No collisions. Each nullifier can only be produced for one claim note commitment. Duplicate nullifiers must not be derivable from different claim note commitments. -- No collisions between nullifiers of other notes (i.e. value notes or defi interaction notes). -- This nullifier must only be added to the nullifier tree if it is the output of a claim circuit which 'spends' the corresponding claim note. -- No double-spending. Each claim note commitment must have one, and only one, nullifier. - -**Calculation** - -- `nullifier = pedersen::compress(claim_note_commitment);` - - Note: it is ok that observers can see which claim note is being nullified, since values in a defi interaction are public (only owners are private). Furthermore, the rollup priovider needs to be able to generate the claim proof and doesn't have access to any user secrets - so this nullifier allows this use case. - - Pedersen GeneratorIndex:`CLAIM_NOTE_NULLIFIER` - -## Defi Interaction nullifier - -**Objectives** of this nullifier: - -- This is not a 'conventional' nullifier, in the sense that it doesn't prevent others from 'referring' to the defi interaction note. It's really only needed so that _something_ unique may be fed into the `output_note_2` output of the claim circuit. -- Anyone (notably the rollup provider) may be able to produce a valid nullifier on behalf of any user who partook in the corresponding defi interaction. -- No collisions between nullifiers of other notes (i.e. value notes or claim notes). -- This nullifier must only be added to the nullifier tree if it is the output of a claim circuit which 'refers' the corresponding defi interaction note note and 'spends' a claim note which was created during that defi interaction. - -**Calculation:** - -- `nullifier = pedersen::compress(defi_interaction_note_commitment, claim_note_commitment);` -- Pedersen GeneratorIndex:`DEFI_INTERACTION_NULLIFIER` diff --git a/docs/docs/spec/primitives.md b/docs/docs/spec/primitives.md deleted file mode 100644 index c8b993bab94d..000000000000 --- a/docs/docs/spec/primitives.md +++ /dev/null @@ -1,143 +0,0 @@ -# Cryptography Primitives - -### 1. Pairing Groups on BN-254 - -Aztec uses the [Ethereum-native version](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md) of the BN254 elliptic curve for its principal group: - -#### First pairing source group - -A BN curve of size $2^{254}$, with field size $2^{254}$, and security of roughly 110 bits (practically, this can be closer to 128 bits as the stronger attacks require unproven assumptions related to number field sive algorithms and have never been fully specified or implemented). - -+ **Equation** $E: X^2 = Y^3 + 3$ -+ *Parameters* - + **Field** $\mathbb{F}_p$ for prime $p = 21888242871839275222246405745257275088696311157297823662689037894645226208583$ in decimal representation (size$\sim 2^{254}$) - + **Group** $\mathbb{G}_1 = E / \mathbb{F}_p$ of prime order $r = 21888242871839275222246405745257275088548364400416034343698204186575808495617$ (size$\sim 2^{254}$) - + **Generator** $P_1 = (1, 2) \in \mathbb{G}_1$ - -We have $2^{253}0$: used to compute hashes for large data strings with inputs of size $> 31 \text{ bytes}$ -1. $h_0, h_1, h_2, h_3$ are used for all Pedersen Hashes in the Note Tree and Nullifier Tree - -The generator algorithm for computing the $h_i$ in pseudocode is: - -``` -counter = 0 -h = [] - -do - { - compute x = keccak256(pad(i)), pad(i) = 32-byte pad of i - find y = sqrt (x³ + ax + b)) - if y = error - { - \\ unsuccessful: point does not exist (50% chance) - } - else - { - \\ successful: point exists and add to list (50% chance) - set h[counter] = (x, y) - } - counter = counter + 1 - } -while counter < 1024 -``` diff --git a/docs/docs/spec/rollup_circuit.md b/docs/docs/spec/rollup_circuit.md deleted file mode 100644 index 6cbc6a39215b..000000000000 --- a/docs/docs/spec/rollup_circuit.md +++ /dev/null @@ -1,144 +0,0 @@ -# Rollup circuit - -### Circuit Description - -The rollup circuit aggregates proofs from a defined set of ‘inner’ circuits. - -Each inner circuit has 16 public inputs. The rollup circuit will execute several defined subroutines on the public inputs. - -#### Notation - -We use the following definitions in this spec: - -- $n_B:$ `NUM_BRIDGE_CALLS_PER_BLOCK` -- $n_A:$ `NUM_ASSETS` -- $n_P:$ `NUM_FIELDS` (number of inner-circuit public inputs propagated by rollup circuit) -- $R:$ rollup size (i.e. number of transaction proofs in a single rollup) - -### Public Inputs: Detail - -There are $28 + 2(n_B + n_A) + n_P \cdot R$ public inputs, in three sections: - -1. **Rollup Proof Data:** $12 + 2(n_B + n_A)$ elements from $\mathbb{F}_p$ that define the rollup block information (described below) -2. **Rolled-Up Transactions Data:** Inner-circuit public inputs (a total of $n_P \times R$ inputs; $n_P = 8$ inputs per rolled up transaction)[^1] -3. **Recursive Proof Data:** $4$ elements from $\mathbb{F}_q$, represented as $16$ elements from $\mathbb{F}_p$, whose values are $<2^{68}$; see [here](https://hackmd.io/LoEG5nRHQe-PvstVaD51Yw) for explanation. - -All are field elements. The first $(12 + 2n_B + 2n_A)$ public inputs are the following: - -1. `rollup_id` -2. `rollup_size` -3. `data_start_index` -4. `old_data_root` -5. `new_data_root` -6. `old_null_root` -7. `new_null_root` -8. `old_data_roots_root` -9. `new_data_roots_root` -10. `old_defi_root = 0` -11. `new_defi_root` -12. `defi_bridge_call_datas` (size: $n_B$) -13. `defi_bridge_deposits` (size: $n_B$) -14. `asset_ids` (size: $n_A$) -15. `total_tx_fees` (size: $n_A$) -16. `public_inputs_hash` - -The `public_inputs_hash` value is a SHA256 hash of the set of all join-split public inputs that will be broadcasted on-chain. These are: - -1. `proof_id` -1. `output_note_commitment_1` -1. `output_note_commitment_2` -1. `nullifier_1` -1. `nullifier_2` -1. `public_value` -1. `public_owner` -1. `public_asset_id` - -### Private Inputs: Detail - -The following inputs are private to reduce proof size: - -1. The recursive proof output of each inner proof (4 $\mathbb{F}_q$ elements represented as 16 $\mathbb{F}_p$ elements, see above) -1. The remaining public inputs of each inner-circuit proof (see footnote [^1]) -1. `old_data_path` -1. `linked_commitment_paths` -1. `linked_commitment_indices` -1. `new_null_roots` (except the latest one since that becomes a public input) -1. `old_null_paths` -1. `data_roots_paths` -1. `data_roots_indices` - -### Index of Functions - -- `Extract` **Extraction Function** extracts the public inputs from an inner proof, and validates the result matches the rollup’s inner public inputs -- `Aggregate` **Proof Aggregation Function** for ultimate batch verification outside the circuit, given a verification key and (optional, defined by 4th input parameter) a previous output of Aggregate. Returns a BN254 point pair -- `NonMembershipUpdate` **Nullifier Update Function** checks a nullifier is not in a nullifier set given its root, then inserts the nullifier and validates the correctness of the associated merkle root update -- `BatchUpdate` **Batch Update Function** inserts a set of compressed note commitments into the note tree and validates the corretness of the associated merkle root update - Update - inserts a single leaf into the root tree and validates the correctness of the associated merkle root update -- `ProcessDefiDeposit` **Processes Defi Deposit** ensures that if a given inner proof is a defi deposit proof, it has a valid bridge call data that matches one of the input bridge call data to the rollup. Further, it also adds the `defi_interaction_nonce` in the encrypted claim note of a defi deposit proof. -- `ProcessClaim` **Process Claims** checks if the claim proof is using the correct defi root. - -### Circuit Logic (Pseudocode) - -1. Let `Q_0 = [0, 0]` -1. Validate `num_inputs == N` -1. Let `previous_note_commitment_1 = 0; previous_note_commitment_2 = 0; previous_allow_chain = 0;` -1. For `i = 1, ..., num_inputs` - - 1. Let `pub_inputs = Extract(PI_i)` - 1. Let `vk = vks[proof_id_i]` - 1. Let `Q_i = Aggregate(PI_i, pub_inputs, vk, Q_{i-1}, (i > 1))` - 1. Let $\text{leaf}_{2i}$ = `output_note_commitment_1_i` - 1. Let $\text{leaf}_{2i+1}$ = `output_note_commitment_2_i` - 1. Validate `NonMembershipUpdate(`$\text{null root}_{2i}$, $\text{nullroot}_{2i+1}$, `nullifier_1_i)` - 1. Validate `NonMembershipUpdate(`$\text{null root}_{2i + 1}$, $\text{null root}_{2i+2}$`, nullifier_2_i)` - 1. Validate `Membership(old_data_roots_root, data_roots_indices[i], data_roots_pths[i], data_tree_root_i)` - 1. If `pub_inputs.PROOF_ID = DEFI_DEPOSIT` then `ProcessDefiDeposit`: - - Check `pub_inputs.ASSET_ID` matches _only_ one (say `k`th) bridge call data in `bridge_call_datas` - - Update `defi_bridge_deposits[k] += pub_inputs.PUBLIC_OUTPUT` - - Update `encrypted_claim_note += (defi_interaction_nonce * rollup_id + k) * G_j`, `k ⋹ 0, 1, 2, 3` - 1. Validate `ProcessClaim(pub_inputs, new_defi_root)` - - 1. Let `chaining = propagated_input_index != 0` - 1. Let `propagating_previous_output_1 = backward_link == previous_note_commitment_1` - 1. Let `propagating_previous_output_2 = backward_link == previous_note_commitment_2` - 1. Let `previous_tx_linked = propagating_previous_output_1 || propagating_previous_output_2` - 1. Let `start_of_subchain = chaining && !previous_tx_linked` - 1. Let `middle_of_chain = chaining && previous_tx_linked` - 1. If `start_of_subchain` then: - - Validate `Membership(old_data_root, linked_commitment_indices[i], linked_commitment_paths[i], backward_link)` - 1. Let - - ``` - propagating_previous_output_index = - propagating_previous_output_1 ? 1 : - propagating_previous_output_2 ? 2 : 0 - ``` - - 19. If `middle_of_chain` then: - - `require(previous_allow_chain == propagating_previous_output_index, "not permitted to propagate this note")` - - Set the inner proof value corresponding to the commitment being propagated to `0`. - - Set the inner proof value corresponding to the nullifier of the commitment being propagated to `0`. - -1. Validate `[P1, P2] = Q_{num_inputs}` -1. Validate `BatchUpdate(old_data_root, new_data_root, data_start_index, leaf_1, ..., leaf_{2 * num_inputs})` -1. Validate `old_null_root = null_root_1` -1. Validate `new_null_root = null_root_{2 * num_inputs + 1}` - -[^1]: - A transaction proof (i.e. inner proof) contains a total of 16 public inputs but the rollup circuit _propagates_ only 8 of them as its public inputs. Those public inputs of the inner proof marked as ✅ are propagated: - ✅ `proof_id` - ✅ `output_note_1_commitment` - ✅ `output_note_2_commitment` - ✅ `input_note_1_nullifier` - ✅ `input_note_2_nullifier` - ✅ `public_value` - ✅ `public_owner` - ✅ `public_asset_id` - ❌ `merkle_root` - ❌ `tx_fee` - ❌ `asset_id` - ❌ `bridge_call_data` - ❌ `defi_deposit_value` - ❌ `defi_root` - ❌ `backward_link` - ❌ `allow_chain` diff --git a/docs/docs/spec/rollup_contract.md b/docs/docs/spec/rollup_contract.md deleted file mode 100644 index 9deb87141646..000000000000 --- a/docs/docs/spec/rollup_contract.md +++ /dev/null @@ -1,266 +0,0 @@ -# Rollup Contract - -Rollup contract is responsible for processing Aztec zkRollups, relaying them to a verifier contract for validation and performing all relevant token transfers and defi bridge interactions. - -## High-Level Overview of Layer 2 Architecture - -The specifics of the Layer 2 architecture are not explicitly in scope for the smart contract audit, as the rules/transaction semantics are defined via the logic in our ZK-SNARK cryptographic circuits, not the L1 smart contracts. - -However, understanding the architecture may be useful to better understand the logic of the rollup processor smart contract, and the logic it executes when processing a rollup block. - -### State Model - -L2 state is recorded in 5 append-only databases, represented as Merkle trees. The Rollup contract records the roots of each tree via the rollupStateHash variable. - -A call to the _processRollup(...)_ method is, at its core, a request to update the roots of the above Merkle trees due to changes in the underlying databases from a block of L2 transactions. - -The main databases/Merkle trees are: - -- **dataTree** contains UTXO notes that contain all created _value notes_ and _account notes_ -- **defiTree** contains the results of previous L1 contract interactions instigated from the rollup contract -- **rootTree** contains all past (and the present) Merkle roots of the dataTree. -Used in L2 transactions to prove the existence of notes in the dataTree. - -The _dataTree_ and _defiTree_ have with it associated a shared nullifier set. -A nullifier set is an additional database which is also represented as a Merkle tree whose roots are included in _rollupStateHash_. -This nullifier set can be shared because there is no risk of collisions. - -Nullifier sets record all items that have been deleted from their linked database. -The encryption algorithm used to encrypt nullifiers is different from the encryption used for their counterpart objects in their linked database. -This gives us the property of unlinkability - observers cannot link note creation to note destruction, which obscures the transaction graph. - -The _rootTree_ has no linked nullifier set as it is not possible to delete members of _rootTree_. - -## L2 data structures - -The following is a brief description of the data structures in the Aztec L2 architecture. -See [notes_and_nullifiers](./notes_and_nullifiers.md) for a more complete descriptions. - -**Value notes** are stored in the _dataTree_. -They represent a discrete sum of ETH, ERC20 tokens or virtual assets held by a user. - -**Account notes** are stored in the _dataTree_. -They link a human-readable alias to both an account public key and to a spending public key. -A user can have multiple account notes with multiple spending keys, but all must share the same alias and account key. -> Note: Account keys are used to decrypt/view notes, spending keys are required to spend notes. -The security requirements for the former are weaker than the latter, as spending keys are required to move user funds. - -**DeFi notes** are stored in the _defiTree_. -They represent a result of an L1 contract interaction instigated by the rollup processor contract. -This type of note records the number of input/output assets from the interaction (as well as their asset types) and information about whether the corresponding interaction succeeded/failed. - -**Claim notes** are stored in the _dataTree_. -This type of note represents a claim on the future proceeds of an L1 contract interaction. -Claim notes are created from value notes, and are converted back into value notes with the help of a defi note. - -## L2 high-level circuit architecture - -The Aztec network utilizes the following ZK-SNARK circuits to describe and validate L2 transactions: - -### Single transaction circuits - -**Join-Split circuit** -Describes a single _deposit/withdraw/spend/defiDeposit_ transaction. -Proof is created by the user on their local hardware. - -**Account circuit** -Describes a single _account_ transaction. -Proof is created by the user on their local hardware. - -**Claim circuit** -Describes a single _defiClaim_ transaction. -Proof is created by the rollup provider since no secret information is required to create a proof. -This is for convenience since in theory this proof could be created by a user locally. -Proof creation is deferred to the rollup provider for better user UX. - -### Rollup circuits -There are 3 circuit types used in AztecConnect: -1. **Inner rollup circuit** verifies up to 28 single transaction proofs and performs required L2 state updates. - -2. **Root rollup circuit** is referred to as a rollup circuit in the smart contract code/comments. -This circuit verifies up to 28 inner rollup proofs. - -3. **Root verifier circuit** verifies a single root rollup proof. - -The inner rollup/root rollup design was introduced in order to enable better parallelism. - -Knowledge of the existence of the _root verifier circuit_ is likely beyond the scope of this audit. -It is used to simplify the computations required by the smart contract [PLONK verifier](https://github.com/AztecProtocol/aztec-connect/blob/master/blockchain/contracts/verifier/StandardVerifier.sol). -All other circuits/proofs are created using the “Turbo PLONK” ZK-SNARK proving system. - -Regular PLONK proofs are slower to construct but faster to verify compared to Turbo PLONK proofs. -The _root verifier circuit_ is made using regular PLONK, and it verifies the Turbo PLONK _root rollup circuit_. -This reduces the computations (and gas costs) required to verify the proof on-chain. - -Aztec uses recursive ZK-SNARK constructions to ensure that only the final ZK-SNARK proof in the transaction stack needs to be verified on-chain. If the root verifier proof is correct, one can prove inductively that all other proofs in the transaction stack are correct. - -## L2 transaction types - -An Aztec rollup block contains up to 896 individual user transactions, which represent one of seven transaction types. -Each transaction type is defined via a _proofId_ variable attached to the transaction. - -| proofId | transaction type | description | -| ------- | ---------------- | ---------------------------------------------------------------------------------------------- | -| 0 | padding | An empty transaction - present when there are not enough user transactions to fill the block | -| 1 | deposit | Converts public L1 ETH/ERC20 tokens into value notes | -| 2 | withdraw | Converts value notes into public ETH/ERC20 tokens on L1 | -| 3 | spend | Private L2 transaction - converts value notes into different value notes | -| 4 | account | Creates a user account note | -| 5 | defiDeposit | Converts a value note into a claim note | -| 6 | defiClaim | Converts a claim note into a value note | - -### Anatomy of an L2 transaction - -Each user transaction in the rollup block will have 8 `uint256` variables associated with it, present in the transaction calldata when `processRollup(...)` is called. -While represented as a `uint256` in the smart contract, these variables are big integers taken modulo the BN254 elliptic curve group order. -This is verified in [StandardVerifier.sol](https://github.com/AztecProtocol/aztec-connect/blob/master/blockchain/contracts/verifier/StandardVerifier.sol). -Not all fields are used by all transaction types. - -| publicInput | name | description | -| ----------- | --------------- | ----------------------------------------------------------------------------------- | -| 0 | proofId | Defines the transaction type (checked in the rollup ZK-SNARK) | -| 1 | noteCommitment1 | The 1st note created by the transaction (if applicable) | -| 2 | noteCommitment2 | The 2nd note created by the transaction (if applicable) | -| 3 | nullifier1 | The 1st nullifier for any notes destroyed by the transaction (if applicable) | -| 4 | nullifier2 | The 2nd nullifier for any notes destroyed by the transaction (if applicable) | -| 5 | publicValue | Amount being deposited/withdrawn (if applicable) | -| 6 | publicOwner | Ethereum address of a user depositing/withdrawing funds (if applicable) | -| 7 | assetId | 30-bit variable that represents the asset being deposited/withdrawn (if applicable) | - -As not all fields are used by all transaction types, a custom encoding algorithm is used to reduce the calldata payload of these transactions. Transactions are decoded in Decoder.sol. - -### Data included in a rollup transaction - -When the `processRollup(...)` function is called, the input variable bytes calldata `encodedProofData` contains the core information required to validate and process an Aztec rollup block. - -Due to significant gas inefficiencies in the Solidity ABI decoding logic, custom encoding is used and the overall data structure is wrapped in a bytes variable. - -The proofData can be split into 3 key components: - -1. **Rollup header** - a fixed-size block of data that records the key properties of the rollup block. -2. **Transaction data** - a variable-size block that records the encoded user transaction data -3. **PLONK proof** - fixed-size block of data that contains a PLONK ZK-SNARK validity proof that proves the L2 transaction logic has been correctly followed. - -Rollup Header Structure - -| byte range | num bytes | name | description | -| --------------- | --------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 0x00 - 0x20 | 32 | rollupId | Unique rollup block identifier. Equivalent to block number | -| 0x20 - 0x40 | 32 | rollupSize | Max number of transactions in the block | -| 0x40 - 0x60 | 32 | dataStartIndex | Position of the next empty slot in the Aztec _dataTree_ | -| 0x60 - 0x80 | 32 | oldDataRoot | Root of the _dataTree_ prior to rollup block’s state updates | -| 0x80 - 0xa0 | 32 | newDataRoot | Root of the _dataTree_ after rollup block’s state updates | -| 0xa0 - 0xc0 | 32 | oldNullRoot | Root of the nullifier tree prior to rollup block’s state updates | -| 0xc0 - 0xe0 | 32 | newNullRoot | Root of the nullifier tree after rollup block’s state updates | -| 0xe0 - 0x100 | 32 | oldDataRootsRoot | Root of the tree of _dataTree_ roots prior to rollup block’s state updates | -| 0x100 - 0x120 | 32 | newDataRootsRoot | Root of the tree of _dataTree_ roots after rollup block’s state updates | -| 0x120 - 0x140 | 32 | oldDefiRoot | Root of the _defiTree_ prior to rollup block’s state updates | -| 0x140 - 0x160 | 32 | newDefiRoot | Root of the _defiTree_ after rollup block’s state updates | -| 0x160 - 0x560 | 1024 | bridgeCallDatas[NUMBER_OF_BRIDGE_CALLS] | Size-32 array of `bridgeCallDatas` for bridges being called in this block. If `bridgeCallData` == 0, no bridge is called. | -| 0x560 - 0x960 | 1024 | depositSums[NUMBER_OF_BRIDGE_CALLS] | Size-32 array of deposit values being sent for bridges being called in this block | -| 0x960 - 0xb60 | 512 | assetIds[NUMBER_OF_ASSETS] | Size-16 array of the assetIds for assets being deposited/withdrawn/used to pay fees in this block | -| 0xb60 - 0xd60 | 512 | txFees[NUMBER_OF_ASSETS] | Size-16 array of transaction fees paid to the rollup beneficiary, denominated in each assetId | -| 0xd60 - 0x1160 | 1024 | interactionNotes[NUMBER_OF_BRIDGE_CALLS] | Size-32 array of defi interaction result commitments that must be inserted into the _defiTree_ at this rollup block | -| 0x1160 - 0x1180 | 32 | prevDefiInteractionHash | A SHA256 hash of the data used to create each interaction result commitment. Used to validate correctness of interactionNotes | -| 0x1180 - 0x11a0 | 32 | rollupBeneficiary | The address that the fees from this rollup block should be sent to. Prevents a rollup proof being taken from the transaction pool and having its fees redirected | -| 0x11a0 - 0x11c0 | 32 | numRollupTxs | Number of “inner rollup” proofs used to create the block proof. “inner rollup” circuits process 3-28 user txns, the outer rollup circuit processes 1-28 inner rollup proofs. | - -N.B. our documentation will sometimes refer to a “note” as a “commitment” (they are effectively synonyms in our architecture). - -## Security properties of Aztec - -The tokens/ETH in every un-spent value note in the _dataTree_ must be fully collateralised on-chain. -That is, the _RollupProcessor.sol_ contract must own enough ERC20 tokens/ETH to cover the value represented in all of its un-spent notes. - -Consequently, whenever a user creates a deposit transaction, they must have previously transferred/approved an equivalent amount of ETH/tokens to _RollupProcessor.sol_. - -It should also not be possible for an attacker to create value notes that are linked to ETH/tokens deposited by a different user without their express permission. - -More generally it is essential that front-running attacks are not possible. -Front-running attacks are attacks where an attacker takes a transaction out of the transaction pool and manipulates it to re-route value to/from an account not intended by the original transaction sender. - -Value can also be deposited to the system via defi interactions. -When claim notes are converted into value notes, an equivalent amount of ETH/tokens must have been deposited into the bridge by a defi interaction (described in the next section). - -When value is extracted from _RollupProcessor.sol_, an equivalent amount of value recorded in value notes must have been destroyed. - -Assuming the cryptography is correct, this means that in `processRollup(...)`’s call-data, there must be a withdraw transaction whose value field matches the amount being withdrawn. - -Alternatively, value can be extracted if the rollup header contains a non-zero value inside the `depositSums` array (this implies that value notes have been converted into claim notes and we are instructing the rollup to send tokens to a specified bridge contract). - -## Anatomy of an Aztec Connect defi transaction - -An outbound defi interaction is described by an instance of a `FullBridgeCallData` and a `depositSum` (present in the rollup header in the `bridgeCallDatas` and `depositSums` arrays). - -An instance of the struct uniquely defines the expected inputs/outputs of a defi interaction. -Before being unpacked to the aforementioned struct the values (other than `bridgeGasLimit` and `bridgeAddress`) are being encoded in a `unit256` bit-string containing multiple fields. -When unpacked, its data is used to create the `FullBridgeCallData` struct: - -``` -struct FullBridgeCallData { - uint256 bridgeAddressId; - address bridgeAddress; - uint256 inputAssetIdA; - uint256 inputAssetIdB; - uint256 outputAssetIdA; - uint256 outputAssetIdB; - uint256 auxData; - bool firstInputVirtual; - bool secondInputVirtual; - bool firstOutputVirtual; - bool secondOutputVirtual; - bool secondInputInUse; - bool secondOutputInUse; - uint256 bridgeGasLimit; -} -``` - -For specific encoding/decoding logic see comments in _RollupProcessor.sol_. - -A bridge contract is an L1 smart contract that translates the interface of a generic smart contract into the Aztec Connect interface. - -Interactions are modelled as synchronous or asynchronous token transfers. -Input assets are sent to a bridge contract and up to two different output assets are returned. -The exchange rate between the input/output assets is assumed to be unknown until the transaction is mined. - -Input/output assets can be either “real” or “virtual”. -A “real” token has an underlying ERC20 smart contract (or is ETH). -A “virtual” token exists entirely inside the Aztec network, with no L1 counterpart. -It is used to efficiently track synthetic values (such as the amount of outstanding value in a loan, or votes in a DAO). - -_RollupProcessor_ enforces that `_totalInputValue` is non-zero. -If both input assets are used, `_totalInputValue` amount of both input assets is transferred to the bridge before a bridge is called. - -**BOTH** output assets could be virtual but since their `assetId` is currently assigned as an interaction nonce of a given interaction it would simply mean that more of the same virtual asset is minted. - -## DeFi Transaction Flow - -If a rollup block contains DeFi interactions a `processBridgeCalls(...)` function is called. -In the function, the following occurs: - -1. All outbound defi interactions in the rollup block are iterated over. For each interaction: -2. Input tokens are transferred to the specified bridge contract -3. The bridge contract has to return 3 parameters: `uint256 outputValueA`, `uint256 outputValueB`, `bool isAsync` -4. When some of the output assets is an `ERC20` token and the corresponding output value is non-zero, the contract attempts to recover the tokens via calling `transferFrom(...)`. -If the asset is ETH, bridge transfers it in to the _RollupProcessor_ and _RollupProcessor_ validates it has received a correctly-sized ETH payment. -This payment is linked to the defi interaction through `_interactionNonce`. -5. A `defiInteractionResult` object is constructed based on the results of the above. - -The logic for processing a single defi transaction is wrapped in a _DefiBridgeProxy_ smart contract. -This smart contract is called from the _RollupProcessor_ via `delegateCall(...)`. -The purpose of this is to enable the call stack to be partially unwound if any step of the defi interaction fails. - ->E.g. consider a defi interaction where 10 ETH is sent to the and the expected return asset is DAI. -If the defi bridge contract reverts, we want to recover the 10 ETH that was sent to the contract, without causing the entire rollup block to revert (which would enable griefing attacks). -Similarly imagine we send 10 ETH to a bridge, which claims its outputValueA is 100 DAI. -If a call to `DAI.transferFrom(...)` fails, we want to unwind the call stack such that 10 ETH never left _RollupProcessor_. - -If the _DefiBridgeProxy_ call fails, we record this in the `defiInteractionResult`. -This allows for a future _defiClaim_ transaction to convert any linked claim notes back into value notes. -This effectively returns the value (less the fee) to the user. - -The expected interface for defi bridges is defined in [IDefiBridge](https://github.com/AztecProtocol/aztec-connect/blob/master/blockchain/contracts/interfaces/IDefiBridge.sol). - -## Encoding and Decoding of Proof Data - -For info about proof data encoding check out documentation of [Decoder](https://github.com/AztecProtocol/aztec-connect/blob/master/blockchain/contracts/Decoder.sol) contract. diff --git a/docs/docs/spec/root_rollup_circuit.md b/docs/docs/spec/root_rollup_circuit.md deleted file mode 100644 index f8ed67765179..000000000000 --- a/docs/docs/spec/root_rollup_circuit.md +++ /dev/null @@ -1,75 +0,0 @@ -# Root Rollup circuit - -### Circuit Description - -This circuit rolls up other rollup proofs. - -It is defined by a parameter `rollup_num`, of inner rollups. Let's also denote $M:=$`rollup_num` for convenience. - -### Circuit Inputs: Summary - -The inputs for the root rollup circuit are: - -$$ -\text{Root Rollup Inputs} = (\text{Public Inputs}, \text{Private Inputs}) \in \mathbb{F}_p^{27 + M * (12 * 32)} \times \mathbb{F}_p^{27M} -$$ - -As previously, the field $\mathbb{F}_p$ is from the BN254 specification. - -### Public Inputs - -The root rollup circuit contains `17` public inputs. - -The first pubic input is a SHA256 hash (reduced modulo the BN254 group order) of the following parameters: - -1. `rollup_id` (The location where `new_root_M` will be inserted in the roots tree) -1. `rollup_size` -1. `data_start_index` -1. `old_data_root` -1. `new_data_root` -1. `old_null_root` -1. `new_null_root` -1. `old_root_root` -1. `new_root_root` -1. `old_defi_root` -1. `new_defi_root` -1. `bridge_call_datas` (size is `NUM_BRIDGE_CALLS_PER_BLOCK`) -1. `defi_deposit_sums` (size is `NUM_BRIDGE_CALLS_PER_BLOCK`) -1. `encrypted_defi_interaction_notes` (size is `NUM_BRIDGE_CALLS_PER_BLOCK`) -1. `previous_defi_interaction_hash` -1. `rollup_benficiary` -1. For $i=1,..,M$ - 1. The `public_inputs_hash` of the rollup - -The remaining 16 public inputs are 68-bit limbs of two BN254 $\mathbb{G}_1$ elements. Each element is split into two $\mathbb{F}_q$ elements, which is in turn split into 4 68-bit limbs. - -The two $\mathbb{G}_1$ elements, $[P_1], [P_2]$, represent the `recursive_proof_output` - group elements that must satisfy the following pairing check in order for the set of recursive proofs in the root rollup circuit to be valid: - -$e([P_1], [x]) == e([P_2], [1])$, where $[x]$ is the $\mathbb{G}_2$ element produced by the Ignition trusted setup ceremony. - -### Broadcasted Inputs - -In addition to the public inputs, the preimage to the above SHA256 hash is also broadcasted with the proof. - -The purpose of the SHA256 compression is not to hide information, it is solely to reduce the number of public inputs to the circuit. - -This is because, for a verifier smart contract on the Ethereum blockchain network, the computational cost of processing a public input is ~160 gas. The computational cost of including a 32-byte value in a SHA256 hash is 6 gas. Therefore reducing the public inputs via SHA256 hashing represents a significant gas saving, lowering the cost of processing a rollup block. - -The `rollup_benficiary` is just added to the circuit to ensure the proof constructor can pay who they intend. - -### Private Inputs - -1. The recursive proof output of each inner rollup proof (4 $\mathbb{F}_q$ elements represented as 16 $\mathbb{F}_p$ elements, see above) -2. The remaining public inputs of each rollup proof - -### Circuit Logic (Pseudocode) -1. For $i=2,..,M+1$, check that $Q_i = aggregate(PI_{i-1}, \pi_{i-1}, vk, Q_{i-1}, (i > 1))$ -2. For $i=2,..,M$, check that `new_data_root`$_{i-1}$=`old_data_root`$_i$. -3. Validate `Update(old_data_roots_root, new_data_roots_root, rollup_id, new_data_root_M)` -4. Validate that the `new_defi_root` of each real inner rollup proof is equal to the input `new_defi_root` to the root rollup -5. Validate that the `bridge_call_datas` in each real inner rollup proof match the input `bridge_call_datas` to the root rollup -6. Accumulate defi deposits across inner rollup proofs -7. Add the input `defi_interaction_notes` in the `defi_tree` and compute `previous_defi_interaction_hash := Hash(defi_interaction_notes)` -8. Range constrain that `rollup_beneficiary` is an ethereum address, - -where $vk$ is the verification key of the rollup circuit. diff --git a/docs/docs/spec/root_verifier_circuit.md b/docs/docs/spec/root_verifier_circuit.md deleted file mode 100644 index ac6e988c9f0d..000000000000 --- a/docs/docs/spec/root_verifier_circuit.md +++ /dev/null @@ -1,23 +0,0 @@ -# Root Verifier Circuit -We use the notation of the Aztec Yellow Paper. In particular, $\text{BN254}$ is a curve defined over a finite field $\mathbb{F}_p$, $r$ is a prime on the order of $p$, and $\mathbb{G}_1$ is a subgroup of BN254 of order $r$. - -### Circuit Description - -This is a standard PLONK circuit that verifies a TurboPLONK root rollup proof. At the time the root verifier circuit $C_{RV}$ is constructed, it is supplied a list $L_{vk}$ of TurboPLONK verification keys, one for each root rollup circuit that is to be verifiable by $C_{RV}$. Let $N_{vk}=L_{vk}$ denote the number of root rollup shapes that are accepted by the root verifier circuit. - -### Circuit Inputs: Summary -The inputs for the root verifier circuit have the form - -$$ -\text{Root Verifier Inputs} = (\text{Public Inputs}, \text{Private Inputs}) \in \mathbb{F}_r^{17} \times \mathbb{F}_r^{16 + N_{vk} \cdot 120}. -$$ - -### Public Inputs - -The root verifier receives $17$ public inputs. The first public input is a mod-$r$ SHA256 hash of broadcast data. This is, in fact, the same datum that appears as a public input to the root rollup circuit. The next 16 public inputs encode the recursion output of the root verifier circuit. This is the data of two points of $\mathbb{G}_1$. Each point consists of two $\mathbb{F}_p$ elements, which is in turn split into 4 68-bit limbs that are regarded as elements of $\mathbb{F}_r$. - -### Private Inputs - The root verifier has $16 + N_{vk}\cdot 120$ private inputs. Each verification key $k\in L_{vk}$ consists of 15 $\mathbb{G}_1$ elements (11 corresponding to constraint selectors, and 4 corresponding to permutation selectors), each one contributing 8 limbs in $\mathbb{F}_r$, leading to a total of $120 N_{vk}$ inputs. The remaining private inputs to the root verifier circuit are the 16 limbs in $\mathbb{F}_r$ that make up the recursive proof output of the root rollup circuit. - -### Circuit Logic - Then, when verifying a root rollup circuit $C_{RR}$, a the verification key $k$ of $C_{RR}$ is instantiated as a witness variable in the circuit $C_{RV}$, which imposes the constraint that $k$ lies in $L_{vk}$ using a Pedersen hash-like `compress` function. The remaining constraints defining this circuit are generated by the standard library's recursive verifier. These constraints are, roughly speaking, those described in the verifier's algorithm in the PLONK paper. More specifically, one should look at the VIP Edition of the paper, making minor changes to include a simplification proposed by Kev Wedderburn for smaller proof size (see IACR version 20210707:125953). \ No newline at end of file diff --git a/docs/docs/spec/schnorr.md b/docs/docs/spec/schnorr.md deleted file mode 100644 index 541097406ee9..000000000000 --- a/docs/docs/spec/schnorr.md +++ /dev/null @@ -1,207 +0,0 @@ -# Code Freeze Fall 2021: Schnorr signatures - -The code is templated in such a way that the primes $q$ and $r$ are defined relative to the group `G1`, which is unfortunate, since $r$ is chosen as a fixed, definite value in our specs. An alternative would be to have the templates in schnorr.tcc refer to `F_nat` and `F_em` (for 'native' and 'emulated') or something like this. The easier and probably better alternative for now is to just rename our primes in the Yellow Paper as $p_{\text{B}}$ and $p_{\text{G}}$. - -For Aztec's current uses cases, `G1` is a cyclic subgroup of an elliptic curve defined over a field $\mathbb{F}_q$ (implemented as a class `Fq`), and `Fr` (aka `field_t`) is the a field of size equal to the size of `G1`, so `Fr` is the field acting on `G1` by scalar multiplication. - -## Role: - -Yellow paper only mentions them here: _The Blake2s hash is utilized for computing nullifiers and for generating pseudorandom challenges, when verifying Schnorr signatures and when recursively verifying Plonk proofs_. - -They are used by the account circuit and the join-split circuit. - -## Data types - -`crypto::schnorr::signature` is a pair $(s, e)$ of two 256-bit integers represented as length-32 `std::array`'s of `uint32_t`'s. - -`crypto::schnorr::signature_b` is a pair $(s, r)$ of the same type. - -`wnaf_record` is a vector of `bool_t`'s along with a skew. - -`signature_bits` is four `field_t`'s, representing a signature $(s, e)$ by splitting component into two. - -## Formulas - -### Elliptic curve addition - -We restrict in this code to working with curves described by Weierstrass equations of the form $y^2 = x^3 + B$ defined over a $\mathbb{F}_r$ with $r$ prime. Consider two non-identity points $P_1 = (x_1, y_1)$, $P_2 = (x_2, y_2)$. If $x_1 = x_2$, then $y_1 = \pm y_2$, so the two points are equal or one is the inverse of the other. If $y_1 = y_2$, then one has $x_1 = \zeta x_2$ with $\zeta^3=1$. In the case of Grumpkin, the equation $X^3-1$ splits over $\mathbb{F}_r$, there are indeed distinct pairs of points satisfying this relation (for an example of how we handle this elsewhere in the code base, see https://github.com/AztecProtocol/aztec2-internal/issues/437). - -Suppose $P_1 \neq - P_2$. Then $P_1 + P_2 = (x_3, y_3)$ with - -$$ -x_3 = \lambda^2 - (x_1 + x_2), \quad y_3 = \lambda.(x_1 - x_3) - y_1 -$$ - -where $\lambda = \dfrac{y_2 - y_1}{x_2 - x_1}$ if $P_1 \neq P_2$ and $\lambda = \dfrac{3x_1^2}{2y_1}$ if $P_1 = P_2$. - -## Algorithms - -Let $g$ be a generator of $\mathbb{G}_1$. - -### HMAC - -We the HMAC algorithm as Pseudo-Random Function (PRF) to generate a randomly distributed Schnorr signature nonce $k$ in a deterministic way. -HMAC is the Hash-based Message Authentication Code specification as defined in [RFC4231](https://tools.ietf.org/html/rfc4231). - -The HMAC algorithm: Given a message $m$, and a PRF key $\text{priv}$, the $\text{output}$ value is computed as - -$$\text{output} = \text{HMAC}( \text{priv}, \mathtt{m}) = h(s' \oplus \text{opad} || h((s' \oplus \text{ipad} || m)))$$ -where: - -- $h$ is a hash function modeling a random oracle, whose block size is 64 bytes -- $s'$ is a block-sized key derived from $\text{priv}$. - - If $\text{priv}$ is larger than the block size, we first hash it using $h$ and set $s' = h(\text{priv}) \vert\vert (0 \ldots 0)$ - - Otherwise, $s' = \text{priv} \vert\vert (0 \ldots 0)$ - - In both cases, $s'$ is right-padded with 0s up to the 64 byte block size. -- $\text{opad}$ is a 64-byte string, consisting of repeated bytes valued `0x5c` -- $\text{ipad}$ is a 64-byte string, consisting of repeated bytes valued `0x36` -- $||$ denotes concatenation -- $\oplus$ denotes bitwise exclusive or -- $text{output}$ is a 32-byte string - -In order to derive a secret nonce $k \in \mathbb{F}_r$, we need to expand $text{output}$ in order to derive a 512 bit integer -$$ -k_{512} = h\big(\text{HMAC}( \text{priv}, \mathtt{m}) \ \vert \vert \ 1 \big) \ \vert \vert \ h\big(\text{HMAC}( \text{priv}, \mathtt{m}) \ \vert \vert\ 0 \big) \in [0,\ldots,2^{512}-1]. -$$ -Modeling $k_{512}$ as a uniformly sampled integer, taking $k = k_{512} \bmod r$ ensures that the statistical distance between the distribution of $k$ and the uniform distribution over $\mathbb{F}_r$ is negligible. - -### Sign - -We use signatures with compression as described in Section 19.2.3 of [BS], in the sense that the signature contains the hash, meaning that the signature contains a hash and a field element, rather than a group element and a field element. - -The algorithm: Given a message $m$, an account $(\text{priv}, \text{pub})\in \mathbb{F}_r \times \mathbb{G}_1$ produces the signature -$$\text{Sig} = (s, e) \in \{0,1\}^{256} \times \{0,1\}^{256}$$ - -where: - -- $s = \big( \mathbb{F}_r(k) - \text{priv} \cdot \mathbb{F}_r(e) \big) \bmod r \in \{0,1\}^{256}$. -- $k = h\big(\text{HMAC}( \text{priv}, \mathtt{m}) \ \vert \vert \ 0 \big) \ \vert \vert \ h\big(\text{HMAC}( \text{priv}, \mathtt{m}) \ \vert \vert\ 1 \big) \in \{0,1\}^{512}$ is the signer's secret nonce. -- $R = (R.x,R.y) = \mathbb{F}_r(k) \cdot g \in \mathbb{G}_1$, is a commitment to the signer's nonce $k$. -- $e= h(p(R.x, \text{pub}.x, \text{pub.y}) \ \vert \vert \ m) \in \{0,1\}^{256}$ is the Fiat-Shamir response. -- $\text{pub} = (x,y) \in \mathbb{F}_q \times \mathbb{F}_q \approx \mathbb{G}_1$ is the affine representation of the signer's public key -- $\mathbb{F}_r (\cdot) : \{0,1\}^{\star} \rightarrow \mathbb{F}_r$ is a function interpreting a binary string as an integer and applying the modular reduction by $r$. -- $p$ is a collisian-resistant pedersen hash function. -- $h$ is a hash function modeling a random oracle, which is instantiated with BLAKE2s. - -The purpose of $p(r, \text{pub}.x, \text{pub.y})$ is to include the public key in the parameter $e$ whilst ensuring the input to $h$ is no more than 64 bytes. - -### Verify - -Given $\text{Sig} = (s, e)\in \{0,1\}^{256} \times \{0,1\}^{256}$, purported to be the signature of a messages $m$ by an account $(\text{priv}, \text{pub})\in \mathbb{F}_r \times \mathbb{G}_1$ with respect to a random oracle hash function $h$, compute - -- $R = (R.x, R.y) = \mathbb{F}_r(e)\cdot \text{pub} + \mathbb{F}_r(s)\cdot g \in \mathbb{G}_1$; -- $e' = h(p(R.x, \text{pub}.x, \text{pub}.y)\ \vert\vert\ m) \in \{0,1\}^{256}$. - -The signature is verified if and only if $e'== e$, where the comparison is done bit-wise. - -Imprecise rationale: The verification equation is $e = h((e.pub + s.g).x, m)$ where both sides of the equation are represented as an array of 256 bits. -VERIFIER has seen that SIGNER can produce a preimage for a given $e$ which is outside of SIGNER's control by choosing a particular value of $s$. -The difficulty of this assumption is documented, in the case where $\mathbb{G}_1$ is the units group of a finite field, in Schnorr's original paper [Sch] (cf especially pages 10-11). - -### Variable base multiplication - -scalar presented as `bit_array` - -scalar presented as a `wnaf_record`, provided along with a `current_accumulator` - -## Code Paths - -### `verify_signature` - -- There is an aborted state reached if $s\cdot g$ and $e\cdot pub$ have the same x-coordinate. -- Normal signature verification path. - -### `variable_base_mul(pub_key, current_accumulator, wnaf)` - -- This function is only called inside of `variable_base_mul(pub_key, low_bits, high_bits)`. There is an `init` predicate given by: "`current_accumulator` and `pub_key` have the same x-coordinate". This is intended as a stand-in for the more general check that these two points are equal. This condition distinguishes between two modes in which the function is used in the implementation of the function `variable_base_mul(pub_key, low_bits, high_bits)`: on the second call, the condition `init` is expected to be false, so that the results of the first call, recorded in `current_accumulator`, are incorporated in the output. -- There is branching depending on whether on the parity of the scalar represented by `wnaf`. - -### `variable_base_mul(pub_key, low_bits, high_bits)` - -- There is an aborted state that is reached when either of the field elements is zero. - -### `convert_signature(scontext, signature)` - -There is no branching here. - -### `convert_message(context, message_string)` - -This function has not been investigated since I propose it be removed. It is not used or tested. - -### `convert_field_into_wnaf(context, limb)` - -- When accumulating a `field_t` element using the proposed wnaf representation, there is branching at each bit position depending on the 32nd digit of the current `uint64_t` element `wnaf_entries[i+1]`. - -## Security Notes - -### Usage of HMAC for deterministic signatures - -There are two main reasons why one may want deterministic signatures. -In some instances, the entropy provided by the system may be insufficient to guarantee uniform `k`, and using `HMAC` with a proper cryptographic hash function should therefore ensure this property. -By deriving it from the secret key, it also ensures that `k` remains private to the signer. -Nowadays, and especially with the types of devices we would be creating signatures, we can assume that the system's randomness source is strong enough for creating signatures. - -There are different ways of achieving this property, such as [RFC 6979](https://datatracker.ietf.org/doc/html/rfc6979), or as defined by the [EdDSA](https://ed25519.cr.yp.to/eddsa-20150704.pdf) specification. - -Our approach is closer to RFC 6979, though we do not use rejection sampling and instead generate a 512-bit value and apply modular reduction by $r$. -This ensures that the statistical difference between the distribution of `k` and the uniform distribution over $\\{ 0,1, \ldots, r-1\\}$ is negligible. -Note that any leakage of the value of `k` may be catastrophic, especially in ECDSA. - -Unfortunately, by using the secret key $\text{priv}$ for signing and as input to `HMAC`, the original security proof of the signature scheme no longer applies. -We would need to derive two independent signing and PRF keys from one 256-bit secret seed. - - -### Signature malleability - -Given a valid signature $(s,e) \in \{0,1\}^{256} \times \{0,1\}^{256}$ , it is possible to generate another valid signature $(s',e) \in \{0,1\}^{256} \times \{0,1\}^{256}$, -where $s'\neq s$ but $\mathbb{F}_r(s') = \mathbb{F}_r(s)$ (take $s'$ to be congruent to $s$ modulo $r$). -The solution would be to check that $\text{int}(s) < r$, but this would incur an additional range check within the circuit -which we avoid for efficiency reasons. - -In our context, signatures are used within the `account` and `join_split` circuits to link the public inputs to the user's spending key -It is essentially a proof of knowledge of the private spending key, parametrized over the public inputs. -The circuits ensures that the user is able to create a valid signature for the specific transaction. -The signatures themselves are private inputs to the circuit and are not therefore not revealed, used in other places, or checked for uniqueness. -The user is already able to create two different proofs for the same set of public inputs since proofs are never unique due to the ZK property. - -It is impossible to distinguish between proofs where: - -- the signature was created honestly using a deterministic nonce -- the signature was created honestly using a random nonce -- the signature's $s$ value was modified, given an original honestly generated signature. - -Since malleability is only possible given an original valid signature signature, the user must have already approved the transaction. -Therefore, we can also accept the modified signature. - -### Missing $R.y$ component in Pedersen hash - -As mentioned, we use the collision-resistant Pedersen hash to compress $R$ and $\text{pub}$ when computing the Fiat-Shamir challenge $e$. - -For efficiency reasons, we do not pass the $y$ coordinate of $R$ into the Pedersen hash. This optimization only incurs a loss of 1 bit of security, because there are only two valid values of $y$ given the $x$ coordinate of $R$. - -### Biased sampling of Fiat-Shamir challenge $e$ - -When we interpret $e \in \{0,1\}^{256}$ as a field element by reducing the corresponding integer modulo $r$, -the resulting field element is slightly biased in favor of "smaller" field elements, since $r \not\vert\ \ 2^{256}$. -Fixing this issue would require a technique similar to the method we use to derive $k$ without bias. -Unfortunately, this would require many more gates inside the circuit verification algorithm (additional hash computation and modular reduction of a 512 bit integer). - -We are no longer in the random oracle model since the distribution of the challenge is not uniform. -We are looking into alternative proofs to guarantee correctness. - -### Domain separation - -We do not use domain separation when generating the Fiat-Shamir challenge $e$ with BLAKE2s. -Other components using the same hash function as random oracle should be careful that this could not lead to collisions when similar inputs are being processed. - -We also note that we do not hash the group generator into the hash function. - -## References - -WNAF representation: https://github.com/bitcoin-core/secp256k1/blob/master/src/ecmult_impl.h, circa line 151 - -NOTE: the original NAF paper Morain, Olivos, "Speeding up the computations...", 1990 has a sign error in displayed equation (7). This is not present in our `variable_base_mul` function. - -[BS20] Boneh, D., Shoup, V "A Graduate Course in Applied Cryptography" Version 0.5, January 2020. - -[Sch] Schnorr, C. "Efficient Identification and Signatures for Smart Cards", 1990. diff --git a/docs/docs/spec/schnorr_multisig.md b/docs/docs/spec/schnorr_multisig.md deleted file mode 100644 index 4b2c1c56ca5c..000000000000 --- a/docs/docs/spec/schnorr_multisig.md +++ /dev/null @@ -1,97 +0,0 @@ -# Schnorr Multi Signatures - -We implement the SpeedyMuSig protocol by E. Crites, C. Komlo and M. Maller described in [ePrint 2021/1375](https://eprint.iacr.org/2021/1375) in Fig. 7. -Given a group of $n$ signers with public/private key pairs $\\{ (\mathsf{pk}_i,\mathsf{sk}_i) \\}_i$, the protocol allows the group to generate a Schnorr signature for an aggregate public key $\mathsf{pk}$ derived from the group's public keys. -We use it to generate Schnorr signatures over aggregated spending keys, which are used inside of circuits to validate the public inputs. - -The Schnorr signatures produced are defined over the Grumpkin curve, using BLAKE2s as random-oracle to derive Fiat-Shamir challenges. - -## Protocol description - -SpeedyMuSig is a two round multi-party computation. - -### Setup - -Each user $P_i$ with signing key-pair $(\mathsf{pk}_i,\mathsf{sk}_i)$ generates a Proof of Possession $\pi_i$ which is a variant of a Schnorr proof of knowledge of the discrete logarithm of a group element. -Its purpose is to attest that $P_i$ actually knows the secret key $\mathsf{sk}_i$ associated to the public key $\mathsf{pk}_i \in \mathbb{G}$ such that $\mathsf{pk}_i = \mathsf{sk}_i \cdot G$. - -The users share their public keys and associated proofs $(\mathsf{pk}_i, \pi_i)$, and verify the proofs. -If all checks succeed, the aggregated public key can be computed as $\mathsf{pk} = \sum_{i} \mathsf{pk}_i$. - -The proof of possession implementation follows the specification in the paper and can be instantiated over any curve and hash function used as random oracle. We deviate slightly from the paper since we implement the signature variant where we send $(\bar{c},\bar{z})$ _(defined as `(e,s)` in the code)_ instead of $(\bar{R},\bar{z})$. These representations are equivalent. - -We disallow the usage of the same hash function for both the signature scheme and the proof of knowledge (and later the nonce generation). -This is done to ensure that all three hash functions $H_{reg}, H_{non}, H_{sig}$ are properly domain separated. -To maintain compatibility with the existing circuits, we use BLAKE2s for $H_{sig}$ without domain separation. -This means that we cannot use the same function for the other two hash functions, even if we include prefixes for the latter ones. -We therefore use the Keccak function, with proper domain separation strings, for $H_{reg}$ and $H_{non}$. -In both functions, we also pass in the group generator $G$ as first argument. We do not apply this to the $H_{sig}$ function as we maintain backwards compatibility with the existing circuit. - -Proofs of possession are deterministic, with the nonce $k$ derived in a similar was as in our Schnorr implementation using HMAC. - -There is a slight bias in the generation of the Fiat-Shamir challenge $e$ due to the modular reduction by $|\mathbb{F}|$. - - -### Round 1 - -Each party $P_i$ generates a random secret nonce pair $(r_i,s_i) \in \mathbb{F}^2$ which is saves in its private state. -The parties broadcast the corresponding commitments $(R_i,S_i)$ where $R_i = r_i \cdot G$ and $S_i = s_i \cdot G$. - -This round can be performed in advance and multiple times in order to generate several sets of commitments, -so that subsequent signing can be done faster. - -### Round 2 - -After receiving a list of commitments $\\{(R_i,S_i)\\}_i$ from all parties, each party computes their additive share $z_i$ of the final signature's $s$ component. - -The nonce challenge $a$ is computed slightly differently as in the paper, in order to prevent accidental collisions. -Indeed, since the length of the message is variable, we add both a fixed prefix and suffix so that the message cannot be interpreted as the nonce from another signing session. -We have $a = H_{non}\Big(\mathsf{pk} \ \vert\vert\ \mathtt{"m\_start"} \ \vert\vert\ m \ \vert\vert\ \mathtt{"m\_end"} \ \vert\vert\ (R_1,S_1)\ \vert\vert\ \cdots \ \vert\vert\ (R_n,S_n)\Big)$ -(we interpret $a$ as a field element by reducing modulo $|\mathbb{F}|$, noting the slight bias from the uniform distribution). - -The Schnorr challenge $R$ is then computed as $R = \sum_{i} (R_i + a \cdot S_i) = \Big(\sum_{i} R_i \Big) + a \cdot \Big( \sum_{i} S_i \Big)$, -which is used to derive the final signature's Fiat-Shamir challenge $e$ (using the different hash function). - -Each user then computes $z_i = r_i + a\cdot s_i - \mathsf{sk}_i \cdot e$. -At this point, these shares can simply be sent to a single trusted "signature coordinator", along with the public outputs from the first two rounds, -who can compute the final signature $(s,e)$. - -### Signature Aggregation - -Once all parties have produced their round 2 output $z_i$, they can either broadcast this value to all other parties so that everyone can produce the final signature, -or they can send it to a central coordinator who will produce the final signature. - - -Given the set of round 1 nonce commitments $\\{ (R_i,S_i)\\}_i$, and the signature shares $\\{z_i\\}_i$, the final signature is computed as follows: -- validate all public keys with their proofs of possession. -- validate round 1 and round 2 messages -- recompute aggregate public key -- recompute values $a, R$ and derive the signature's Fiat-Shamir challenge $e$ -- compute the $s$ component of the signature as $s = \sum_i z_i$. - -The final signature is $(s, e)$ as defined by the single party Schnorr signature algorithm implementation. - -## Known issues - -### Bias in Fiat-Shamir challenges - -When the protocol is instantiated over an elliptic curve whose subgroup's order is far from $2^{256}-1$ (the range of the output of our hash functions), -the field element we obtain from the Fiat-Shamir transform will not exactly follow the uniform distribution over $\mathbb{F}$. -Applying the modular reduction over the 256-bit hash output (which we assume is uniform) induces a small bias in favor of "smaller" field elements. -Therefore, the field element $e$ does not actually follow a uniform distribution over $\mathbb{F}$. - -Since fixing this issue would require circuit changes, we chose to accept this slight bias. - -## Usage notes - -### Non-deterministic signatures - -Signatures produced with this protocol cannot be made deterministic as there is no easy way of ensuring that all participants are generating their shares of the nonce deterministically. -While deterministic signatures are handy in the single party case where the signer may not have access to strong randomness (in the browser for example), -multisignature nonces essentially combine each signer's randomness using the unpredictable output of a hash function. - -### Message ordering - -When the parties are broadcasting the round 1 nonce commitements $(R_i,S_i)$, -the signature will only succeed if all parties agree on the same ordering. -Otherwise, parties would end up with different $a$ values. \ No newline at end of file diff --git a/docs/docs/spec/uint.md b/docs/docs/spec/uint.md deleted file mode 100644 index b13cb3561ca3..000000000000 --- a/docs/docs/spec/uint.md +++ /dev/null @@ -1,74 +0,0 @@ -# Code Freeze Fall 2021: unsigned integers - -A standard library `uint` is a circit manifestation of a fixed width unsigned integer. The type is parameterized by a composer and one of the built-in types `uintN_t` for `N = 8, 16, 32, 64`. The value here is referred to as the `width` of the type. - -Shorthand: write `uint_ct` for a generic `uint`, and refer to an instance of such a class a simply a `uint_ct`. - -## Role: - -One wants such a type, for example, to implement traditional "numeric" hash functions, as we do for BLAKE2s and SHA256. - -## Data types - -The state of a `uint_ct` is described by the following `protected` members: - - - `Composer* context` - - `mutable uint256_t additive_constant`: A component of the value. - - `mutable WitnessStatus witness_status`: An indicator of the extent to which the instance has been normalized (see below). - - `mutable std::vector accumulators`: Accumulators encoding the base-4 expansion of the witness value, as produced by `TurboComposer::decomposer_into_base4_accumulators`. This vector is populated when the `uint_ct` is normalized. We record the values for later use in some operators (e.g., shifting). - - `mutable uint32_t witness_index`: The index of a witness giving part of the value. - -## Key concepts - -### Value and constancy - -Similar to the value of an instance of `field_t`, the value (a `uint256_t`) of a `uint_ct` consists of a "constant part" and possibly a witness value. To be precise, the function `get_value` returns - - (uint256_t(context->get_variable(witness_index)) + additive_constant) & MASK, - -where `MASK` enforces that the result is reduced modulo `width`. There is also an "unbounded" version that does not mask off any overflowing values. - -The value of a `uint_ct` $a$ consists of a witness $a_w$ and a constant part $a_c$. We will use this notation throughout. If the index of the witness $a_w$ is the special `IS_CONSTANT` value, then $a$ is said to be constant. - -### Normalization - -A naive implementation of the class `uint_ct` would take `field_t` and enrich it with structure to ensure that the value is always appropriately range constrained. Our implementation is more efficient in several ways. - -We track an `additive_constant` to reduce the number of divisions (by $2^{width}$) that must be recorded by the prover; for instance, if a uint $a$ is to be repeatedly altered by adding circuit constants $c_1, ... , c_m$, the circuit writer is happy to save the prover some effort by computing $c = (c_1 + ... + c_m) \% 2^{width}$ and, instead, asking the prover to demonstrate that they have computed the long division of $a + c$ by $2^{width}$. - -We also allow for the deferral of range constraints for efficiency reasons. - -If $a$ is constant, then it is regarded as "normalized"--the prover does not need to provide any constraints on it showing that its value is of the appropriate width. - -If $a$ is not constant, then it is allowed to exist in an 'unnormalized' state. By definition, normalizing $a$ means replacing it by a new `uint_ct` $rem$ with $rem_{c}=0$ and $rem_w$ proven to equal to $a_w + a_c \% 2^{width}$. To prove this equation, one must impose the following two constraints: - -1) $a_w + a_c = 2^{width} q + r$ for some integers $q, r$; -2) $r$ lies in the range $[0, 2^{width}-1]$. - -We track whether these two constraints have been applied independently. If the first constrain has been applied, then $a$ is said to be weakly normalized. If both have been applied, $a$ is said to be noramlized. This status is tracked through an enum called `WitnessStatus` that can take on three values. - -### Example: Addition - -Our function `operator+` on `uint_ct`s does not return a normalized value. Suppose we apply it to compute $b = a_1 + a_2$ where $a_1, a_2$ are two `uint_ct`s both having zero additive constants. Abusing notation to conflate a `uint_ct` with its value, the constraints imposed by `operator+` are: $a_1 + a_2 = 2^{width} q_1 + b$ and $q_1\in \{0, 1, 2\}.$ That is, $b$ is only weakly normalized. Without appropriately range constraining $b$, it is not known that $b$ is the remainder of division of $a_1 + a_2$ by $2^{width}$. - -Suppose we know ahead of time that we actually want to compute $a_1 + a_2 + a_3$ with $a_3$ also having additive zero additive constant. Computing this sum as $c = b + a_3$, the result $c$ is weakly normalized, backed by a constraint $b + a_3 = 2^{width} q_2 + c$. Now suppose that $c$ normalized. Altogether, we - -$$ -2^{width} q_2 + c = b + a_3 = a_1 + a_2 - 2^{width} q_1 + a_3 \quad{} \Rightarrow \quad{} a_1 + a_2 + a_3 = 2^{width} (q_1 + q_2) + c -$$ - -and $c \in [0, 2^{width}-1]$. This shows that we can defer range constraints and correctly compute `uint_ct` additions. -This, of course, has the tradeoff that the circuit writer must take care to manually impose range constraints when they are needed. - -## Descriptions of algorithms - -Extensive comments were added to code to document complicated formulas and describe our algorithms. Some of the logic has been delegated to the widgets, having been 'absorbed', so to speak, into the protocol definition itself. In particular, `create_balanced_add_gate` imposes an addition constraint and a range constraint, and this is described in the turbo arithmetic widget. Similarly `create_big_add_gate_with_bit_extraction` extract bits information from a scalar represented in terms of two-bit 'quads'. The audit added around these TurboPLONK gates and widgets. - -A reader coming to the task of understanding this code with little or no preparation is advised to begin bu reading the function `TurboComposer::decompose_into_base4_accumulators`. This is the TurboPLONK function that imposes a range constraint by building a base-4 expansion of a given witness, recording this information in a vector of witnesses that accumulate to the given input (in the case of a correct proof). The decomposition there is used repeatedly for operations on uints (e.g., bit shifting). - - -## Code Paths - -There is branching in `operator>`, where the conditions for `>` and `<=` are unified. This affects all of the other comparisons, which are implemented in terms of `>`. - -Otherwise, the code avoids branching as much as possible. Some circuit construction algorithms divide into cases, (e.g., whether a bit shift is by an even or an odd amount), but the predicates in those cases are known at compile time, not just at proving time. \ No newline at end of file diff --git a/docs/docs/zk-money/assetvaluation.md b/docs/docs/zk-money/assetvaluation.md deleted file mode 100644 index 6523d244c691..000000000000 --- a/docs/docs/zk-money/assetvaluation.md +++ /dev/null @@ -1,16 +0,0 @@ -# Asset Valuation - -All dollar valuations seen in zk.money are derived with use of oracles provided by [Chainlink](https://chain.link/). - -| Asset | Chainlink Oracle | -| ----- | ---------------------------------------------------------------------------------------------------- | -| ETH | [ethereum/mainnet/crypto-usd/eth-usd](https://data.chain.link/ethereum/mainnet/crypto-usd/eth-usd) | -| DAI | [ethereum/mainnet/stablecoins/dai-usd](https://data.chain.link/ethereum/mainnet/stablecoins/dai-usd) | - -## wstETH - -Chainlink provides no direct oracle for wstETH, but does provide an [oracle for stETH](https://data.chain.link/ethereum/mainnet/crypto-usd/steth-usd). We use this stETH oracle in conjunction with the `getStETHByWstETH` method on the [Lido contract](https://etherscan.io/address/0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0#readContract) to calculate a wstETH dollar valuation. - -## Element fixed yield positions - -Over time we interpolate between the asset quantity locked in your position and its promised output. The interpolated quantity is then given a dollar valuation with use of Chainlink. diff --git a/docs/docs/zk-money/fees.md b/docs/docs/zk-money/fees.md deleted file mode 100644 index e7305e6c4e0f..000000000000 --- a/docs/docs/zk-money/fees.md +++ /dev/null @@ -1,58 +0,0 @@ -# Fees - -## Fee Calculation - -Fees on zk.money are calculated depending on the user action. - -There are broadly two types of actions: - -1) simple payment transactions (deposits, withdrawals, and internal sends) -2) DeFi interactions - -## Simple Payments - -The first class of simple transactions has the basic cost of being included in a rollup. - -Being included in a rollup also has two components: - -a) rollup verification costs - -Total rollup verification cost is approximately 550,000 gas. A transaction's share of total verification costs is calculated by dividing this total rollup verification by the number of transactions. For an 896 transaction rollup, the base fee is 614 gas. - -b) call data costs - -Call data has to be posted to Ethereum to update Aztec's state tree with the new offchain system state. The cost of posting call data is approximately 15,376 gas, less than the base transaction cost on Ethereum. - -**This means the cost of executing a private transaction is always cheaper than doing a public transaction on Ethereum.** - -For deposits, withdrawals, and internal transfers, the story stops there. - -## Defi Interactions - -Defi interactions are actually comprised of multiple simple transactions, as they are structured like swaps: one or two input assets are sent from the Aztec rollup to another Layer 1 protocol, and then one or two output assets are received. Therefore, the rollup verification cost is typically double the cost of a simple transaction (essentially because they are comprised of 2 transactions). - -Call data costs--the cost to update state--remain the same. - -However, DeFi interactions also carry a Layer 1 execution cost--the cost of processing a DeFi transaction on Layer 1. DeFi interactions are batched to different sizes depending on the bridge. - -Therefore, the cost of Layer 1 execution costs for a given contract interaction is t/n, t being the total cost of Layer 1 execution and n being the size of transaction batch processed by that particular bridge. Information on individual batch sizes can be found when determining fees for zk.money transactions. - - -## Transaction Speed - -As mentioned in the zk.money User Guide, there are three potential speeds you might see for simple transactions and DeFi transactions: - -1) Batched -2) Fast Track (only available for DeFi transactions) -3) Instant - -Batched transactions fully split costs for both the rollup and, if there's a DeFi transaction involved, the DeFi transaction. Transactions in the DeFi batch enter the rollup once the batch is full (e.g. all 10 of the Element vault entry transactions in a batch are full), and the rollup is posted to Ethereum Layer 1 once it is full. - -Fast Track transactions accelerate the "filling" of a DeFi batch, allowing users to pay the remainder of the batch costs for inclusion in the next Aztec rollup. - -Instant transactions both fill a DeFi batch and fill a rollup, ensuring the transaction (along with others in the DeFi batch and overall rollup) goes to Layer 1 Ethereum as soon as possible. - -For all transactions, the Aztec rollup includes a small markup to the total fee as a buffer in case Ethereum gas costs experience a sharp rise between the time an order is executed and the time the rollup is published to Layer 1. - -For more information on how we scale our rollup, refer to this Medium post: https://medium.com/aztec-protocol/dollars-and-sense-cheap-privacy-with-aztec-connect-f35db037a04 - diff --git a/docs/docs/zk-money/june2021update.md b/docs/docs/zk-money/june2021update.md deleted file mode 100644 index da8a9aff5fa7..000000000000 --- a/docs/docs/zk-money/june2021update.md +++ /dev/null @@ -1,27 +0,0 @@ -# June 2021 Security Update - -TL;DR - -- This update is not part of the new zk.money migration process. -- If you're being asked to update your account on [old.zk.money](https://old.zk.money), your alias is currently inaccessible in the new system. We are working to make it recoverable. - -If you have not logged into the old system since June 2021 you will be prompted to update your account before being able to login. - -### Explanation - -In June 2021 zk.money's key signing system was changed in two ways: - -1. The signing message for generating an Aztec account public key was changed to be human readable (priorly a hex string) -2. Accounts were required to register a spending key, also derived by signing a human readable message, removing risk of funds being stolen via snooping keys from browser storage. (Priorly viewing and spending was done with a single key, which had to be stored.) - -To bring users onto this new system, it was necessary to have each user individually update their account by registering a new public key derived from the new signing message at the same time as transferring their alias and exist funds to this new public key. - -Users were (and still are) guided through the necessary steps to perform this update when attempting to log into the system. If today you are being prompted to update your account, it's because you haven't logged in since June 2021. - -## How this affects your alias on the new zk.money - -If you didn't login to your account between June 2021 and June 2022 your alias is currently in accessible in the new zk.money. The team is currently working on tool to enable users in this situation to transfer their inaccessible alias to a new account. - -### Explanation - -In June **2022** (roughly one year following the security update) the registrations of all existing aliases were copied into the new Aztec Connect system. The most recent rollup then was #3120, published 01 June 2022 09:59:23 UTC. This means that every migrated alias in the new system is associated with the last Aztec account public key to have registered it for that specific point in time. Aliases that were still associated with a public key generated from the retired signing message are currently inaccessible in the new zk.money because support for signing over the retired message was dropped as an oversight. diff --git a/docs/docs/zk-money/troubleshooting.md b/docs/docs/zk-money/troubleshooting.md deleted file mode 100644 index 62260cef7391..000000000000 --- a/docs/docs/zk-money/troubleshooting.md +++ /dev/null @@ -1,58 +0,0 @@ -# Troubleshooting Guide - -## Account Not Registered Error - -Most "Account Not Registered" errors can be resolved with one of two methods: - -1. Double-checking your Ethereum address. Please connect to zk.money using the Ethereum address you used to sign up for your alias. - -2. Mistyping or misremembering your alias. Remember that your alias is critical to access your account and forgetting or misplacing it means you may not be able to access your funds. - -If either approach does not work, you may belong to one of the below cohorts whose account aliases were not migrated: - -1. Users who registered **prior** to July, 2021 but **did not do an account migration in the old system**. From July, 2021 to June, 2022, accounts were required to undergo [a security update](june2021update.md). If you did not update prior to June, 2022, your alias is inaccessible in the new system. This includes users who attempted migration on old.zk.money after June, 2022. - -2. Users who forgot their alias after June, 2022 and had to go through the "Forgot alias" flow on old.zk.money. If you forgot your alias for old.zk.money and recovered your account using the "Forgot alias" flow, including registering a new alias, the new alias will NOT be migrated. Your old (forgotten) alias **has** been migrated if you want to try remembering it in the new system. - -### - -## Hung on "Connecting to Rollup Provider" on sign-up or log-in - -If you see "Connecting to Rollup Provider" for more than 60 seconds, please troubleshoot using the below steps. - -You may also be presented with an "AbortError: Transaction Aborted" when attempted to sign up or log-in after a system update. - -In either case, navigate to your browser console (F12 or Alt-Cmd-J) and the Application tab on the top bar. Once there, click "Storage" under the "Application" group and click "Clear site data." Refresh the page. - -![image](https://user-images.githubusercontent.com/15220860/177643292-e39ce717-8a58-4916-ad51-74e10c7685d4.png) - -### Firefox - -If you are using Firefox, open the browser console (F12 or right click and select Inspect). Go to the Storage tab on the top bar. Select the Indexed DB tab, select https://zk.money and right click "hummus" and delete it. Refresh the page. - -![firefox dev tools](https://user-images.githubusercontent.com/18372439/178279060-8c8b6d58-f0ae-4986-9649-390deaa611cb.png) - -## Known issue: Deposited funds not showing in zkmoney wallet balance - -Step 1: Clear Site Data - [link](#hung-on-connecting-to-rollup-provider-on-sign-up-or-log-in) - -Step 2: Login to https://zk.money/balance, wait till the dashboard has loaded. - -Step 3: Open Developer tool (F12). Select all levels in the console including Verbose. - -![verbose](https://user-images.githubusercontent.com/4763902/184890333-a23068ae-d181-4038-8e28-f07b3e0f132d.png) - - -Step 4: Right click anywhere in the logs and “Save as…” to download the file. - -![2022-08-16 21_00_06-zk money](https://user-images.githubusercontent.com/4763902/184889636-d2f84bfe-0dd1-4005-8573-c54f4b6a6d02.png) - - -Step 5: Open ticket in Discord and send over the file. - - -## Frequently Asked Questions - -Check the [frequently asked questions page](/how-aztec-works/faq) to see if your problem is addressed there. - -If it isn't, join our [Discord server](https://discord.com/invite/UDtJr9u) and get an answer from the community. diff --git a/docs/docs/zk-money/userguide.md b/docs/docs/zk-money/userguide.md deleted file mode 100644 index ad7d2d71fc71..000000000000 --- a/docs/docs/zk-money/userguide.md +++ /dev/null @@ -1,145 +0,0 @@ -# User Guide - -Welcome to the new zk.money! - -Here you can find all information about zk.money and how to use it safely. We recommend going through the docs before using the app. - -# Overview - -zk.money is a Layer 2 privacy app built on top of Aztec network. - -Ethereum users can use it to shield tokens and protect their transaction data from the public. Shielding a token means having it under a zkSNARK (zero-knowledge proof cryptography) shield that protects the user’s privacy. Sending and receiving a token is anonymous, and does not publish any of the transaction’s data publicly. - -### Existing Users -If you're an existing [zk.money](https://zk.money) user, please see [here](https://medium.com/aztec-protocol/zk-money-migration-guide-5bd45584b1b) for a guide to migrating funds to the new system. - -If you're a new user, read on! - -# Shielding Funds - -### Step 1: Start shielding -When you land on the homepage, click on “Shield Now” to be taken to the wallet connection screen. - -![image](https://user-images.githubusercontent.com/15220860/172759597-7394a992-7869-45e6-9ec7-684f883c194e.png) - -### Step 2: Connect your crypto wallet -Connect your wallet with MetaMask or other wallets via WalletConnect. - -![image](https://user-images.githubusercontent.com/15220860/172760020-8ce905ad-a046-4cc4-854e-751491078f23.png) - -### Step 3: Pick a memorable alias -Your username is a recognizable alias that makes it easy for your friends to send you crypto. -- Write it down! Aztec does not keep a record, it is all encrypted. Only you know it. -- If you've forgotten your alias, you cannot re-register a new one. - -⚠️ Write down your alias! Losing your alias means losing account access! ⚠️ - - -![image](https://user-images.githubusercontent.com/15220860/172760386-bc32708c-bdf2-4310-bc5d-b9bc90082fdf.png) - -Click "Register" to register your account. This may take several minutes. Do not close the window until you see the dashboard. - -### Step 4: Shield ETH -Deposit at least 0.01 ETH. In order to prevent spam, you must shield at the same time as claiming an alias. You'd be able to withdraw your tokens later at any time. - -If you registered with an empty wallet, or wallet has insufficient ETH, you may change to another wallet (while still connected to existing one) and shield ETH. - -![image](https://user-images.githubusercontent.com/15220860/172760503-9cfd9928-721d-47a3-a72b-3b573b02539c.png) - -### Step 5: The Wallet page -As you noticed when you scroll down, your initial shield deposit is confirmed but not settled. -![image](https://user-images.githubusercontent.com/15220860/172760715-87ed8103-3033-467d-8a76-c2fc897aa04d.png) - -It should show one green check ✅ , which means the transaction has been sent to the Rollup Provider for settlement to Layer 1. - -Hovering over the ✅ will also tell you approximately when the transaction will settle (updated in real time!). - -Once you see ✅ ✅, the transaction is settled and your balance will show up in the “Net Worth” component up top on the Wallet page. - -Note that “Net Worth” reflects the value of all your positions — liquid or illiquid — whereas “Available” funds reflects just your spendable balance. - -These figures can therefore differ — don’t be alarmed. - -![image](https://user-images.githubusercontent.com/15220860/172760977-0b8e35e9-4419-4097-99eb-80109bd64456.png) - -This is how it looks once the initial registration and shield transaction have been confirmed and settled. - -Congrats, now you have zkAssets! What can you do with shielded assets? - - -## Shield more -You can always add more funds to your account from the Wallet page by clicking on "Shield More." - -![image](https://user-images.githubusercontent.com/15220860/172760777-67133ff2-c224-46c3-ac40-4c73bdd20c73.png) - -It’s worth repeating deposit best practices: - -- Do not deposit idiosyncratic amounts (e.g. 0.696969) -- Depositing many smaller quantities is better than depositing extremely large quantities -- Deposits are capped at launch to 5 ETH / 10,000 DAI - -![image](https://user-images.githubusercontent.com/15220860/172760637-e1ee8849-d9de-44db-a442-ce17321bfc49.png) - - -## Send -Send zkETH / zkDAI to other zk.money usernames or any Ethereum address. - -Select "Withdraw to L1" to withdraw funds to Ethereum, or "Send to L2" to send funds privately to another zk.money user. - -![image](https://user-images.githubusercontent.com/15220860/172761821-36477974-ee21-4f5a-8b72-ceb7c10eb606.png) - -After making your selection, simply paste the recipient details into the recipient section. For L2 transactions (the recipient is a zk.money username), the recipient will get zkETH/DAI directly into their account balance. In case the recipient is a regular Ethereum address, they will receive regular "unshielded" ETH/DAI tokens to their wallet. - -On this screen you can also select your transaction speed and fee quantity. “Slow” transactions ride along with many others, and settlement time average approximately an hour. “Instant” transactions involve paying for the entire rollup to go, prompting the rollup to settle to Ethereum as soon as the proof is constructed. - -Once you’ve entered your amount and speed, click Next! - -After confirming transaction details, click "Confirm Transaction." - -![image](https://user-images.githubusercontent.com/15220860/172761896-e141bcef-0451-4d5f-870f-896d9aaef891.png) - - -# Earn -Explore various DeFi protocols integrated into Aztec. At the **Earn** tab, you can filter by: - -- **Type:** Fixed Yield, Staking -- **Project:** Element, Lido -- **Asset:** DAI, ETH, wstETH - -![image](https://user-images.githubusercontent.com/15220860/172763263-954995a1-9edb-4025-9899-be8d5e39436e.png) - -Each DeFi card shows you how many users are in the batch headed to Layer 1. The more there are in the batch, the closer the batch is to running and offering you cost savings! - -## Lido - -### Entering a position -On this screen you can select the amount of ETH you would like to swap for wrapped staked ETH (wstETH) - -![image](https://user-images.githubusercontent.com/15220860/172762361-bdec3cac-a90c-4b0a-a801-b6a68d0c5ece.png) - -You can also see an additional transaction speed and fee option called "Fast Track": -- **Batched** Is slowest and batches your transaction along with many others doing the same Lido swap for wstETH. -- **Fast Track** Is faster and pays for the full DeFi transaction. -- **Instant** Is fastest and pays for the full DeFi transaction _and_ sends the Aztec rollup to mainnet instantly. - -Once the transaction is confirmed, you are returned to the Earn page where you can see your Lido staking action under DeFi Investments: -![image](https://user-images.githubusercontent.com/15220860/172763467-85547030-99f2-4893-84fe-e9da92dbcbef.png) - - -### Exiting a position -If you want to leave a position, navigate to your open positions on the Earn page and click "Claim and Exit." - -![image](https://user-images.githubusercontent.com/15220860/172764596-35130ead-3396-4be5-a2f7-555beb985691.png) - -From there you will be taken to the exit modal where you can unstake. - -![image](https://user-images.githubusercontent.com/15220860/172764695-cc60078e-9566-480e-a2ce-590121b526d0.png) - - -## On Security - -Disclaimer: It is responsible for projects using bleeding-edge cryptography, to highlight the risks of use. Given the absence of an external audit, zk.money should be viewed as experimental software. Internally the Aztec team has conducted two internal audits of the network, described here. After patching the resultant security flaws, we have high confidence in the soundness and security of our cryptography. Users are nonetheless reminded to use any new cryptographic system with extreme caution, and to remember that you do so at your own risk. - -## Community Support - -For any remaining questions and live troubleshooting help, visit our [Discord](https://discord.gg/aztec) for support. diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index c91fc7d4a0a6..4b12e0259c5f 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -29,7 +29,10 @@ const config = { defaultLocale: "en", locales: ["en"], }, - + markdown: { + mermaid: true, + }, + themes: ['@docusaurus/theme-mermaid'], presets: [ [ "@docusaurus/preset-classic", @@ -104,11 +107,6 @@ const config = { position: "left", label: "Aztec Protocol", }, - { - type: "doc", - docId: "zk-money/userguide", - label: "Zk.money", - }, ], }, footer: { @@ -121,10 +119,6 @@ const config = { label: "Introduction", to: "/", }, - { - label: "How Aztec Works", - to: "/category/how-aztec-works", - }, ], }, { diff --git a/docs/netlify.toml b/docs/netlify.toml new file mode 100644 index 000000000000..c0b86a0013d5 --- /dev/null +++ b/docs/netlify.toml @@ -0,0 +1,19 @@ +[[redirects]] + from = "/how-aztec-works/*" + to = "/" + +[[redirects]] + from = "/sdk/*" + to = "/" + +[[redirects]] + from = "/developers/*" + to = "/" + +[[redirects]] + from = "/spec/*" + to = "/" + +[[redirects]] + from = "/compliance" + to = "/" \ No newline at end of file diff --git a/docs/package.json b/docs/package.json index 96bbe2d10dc7..c4bcc2fb60d4 100644 --- a/docs/package.json +++ b/docs/package.json @@ -15,20 +15,22 @@ "update-specs": "./scripts/update_specs.sh" }, "dependencies": { - "@docusaurus/core": "^2.2.0", - "@docusaurus/plugin-ideal-image": "^2.2.0", - "@docusaurus/preset-classic": "^2.2.0", + "@docusaurus/core": "^2.3.1", + "@docusaurus/plugin-ideal-image": "^2.3.1", + "@docusaurus/preset-classic": "^2.3.1", + "@docusaurus/theme-mermaid": "^2.3.1", "@mdx-js/react": "^1.6.22", "clsx": "^1.1.1", "hast-util-is-element": "1.1.0", "prism-react-renderer": "^1.3.1", "react": "^17.0.2", "react-dom": "^17.0.2", + "react-player": "^2.12.0", "rehype-katex": "5", "remark-math": "3" }, "devDependencies": { - "@docusaurus/module-type-aliases": "^2.2.0", + "@docusaurus/module-type-aliases": "^2.3.1", "@tsconfig/docusaurus": "^1.0.5", "typescript": "^4.7.2" }, diff --git a/docs/scripts/update_specs.sh b/docs/scripts/update_specs.sh deleted file mode 100755 index 97f6566d1cdf..000000000000 --- a/docs/scripts/update_specs.sh +++ /dev/null @@ -1,5 +0,0 @@ -#/bin/bash - -git clone "https://github.com/AztecProtocol/aztec-connect.git" "./tmp/" -cp -R ./tmp/specs/aztec-connect/src/ ./docs/spec -rm -rf ./tmp \ No newline at end of file diff --git a/docs/sidebars.js b/docs/sidebars.js index f15a7559fb3e..ed835c7b07f3 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -15,161 +15,11 @@ const sidebars = { docsSidebar: [ "intro", - { - type: "category", - label: "How Aztec Works", - link: { - type: "generated-index", - }, - collapsed: false, - items: [ - { - type: "category", - label: "Privacy", - link: { - type: "doc", - id: "how-aztec-works/privacy", - }, - items: ["how-aztec-works/privacy-sets"], - }, - "how-aztec-works/scalability", - { - type: "category", - label: "Aztec Connect", - link: { - type: "doc", - id: "how-aztec-works/aztec-connect/aztec-connect", - }, - items: ["how-aztec-works/aztec-connect/technical-intro"], - }, - "how-aztec-works/accounts", - "how-aztec-works/tokens", - "how-aztec-works/talks-videos", - "how-aztec-works/faq", - ], - }, - { - type: "category", - label: "Developers", - items: [ - "developers/getting-started", - "developers/cli", - { - type: "category", - label: "Aztec Connect Bridges", - items: [ - "developers/bridges/bridges", - "developers/bridges/subsidy", - "developers/bridges/dataprovider", - ], - }, - "developers/local-devnet", - "developers/deposit", - "developers/transaction-model", - "developers/sequencer-api", - "developers/mainnet-info", - "developers/noir", - ], - }, - { - type: "category", - label: "SDK", - link: { - type: "generated-index", - }, - items: [ - "sdk/overview", - { - type: "category", - label: "Usage", - link: { - type: "generated-index", - }, - items: [ - "sdk/usage/setup", - "sdk/usage/add-account", - "sdk/usage/register", - "sdk/usage/add-spending-keys", - "sdk/usage/account-recovery", - "sdk/usage/deposit", - "sdk/usage/transfer", - "sdk/usage/withdraw", - "sdk/usage/ethereum-interaction", - "sdk/usage/feecontroller", - ], - }, - { - type: "category", - label: "Types, Classes, Interfaces", - link: { - type: "generated-index", - }, - items: [ - { - type: "autogenerated", - dirName: "sdk/types", - }, - ], - }, - ], - }, - { - type: "category", - label: "Technical Specification", - items: [ - "spec/SUMMARY", - "spec/intro", - { - type: "category", - label: "General", - items: [ - "spec/primitives", - { - type: "doc", - id: "spec/schnorr", - label: "Schnorr Signatures", - }, - "spec/schnorr_multisig", - { - type: "doc", - id: "spec/uint", - label: "Unsigned Integers", - }, - "spec/notes_and_nullifiers", - "spec/defi_bridge_interface", - ], - }, - { - type: "category", - label: "'App' Circuits", - items: [ - "spec/account_circuit", - "spec/join_split_circuit", - "spec/claim_circuit", - ], - }, - { - type: "category", - label: "Rollup Circuits", - items: [ - "spec/rollup_circuit", - "spec/root_rollup_circuit", - "spec/root_verifier_circuit", - ], - }, - "spec/rollup_contract", - ], - }, - "compliance", + "aztec3", + "noir", + "aztec-connect-sunset", "glossary", ], - zkmoneySidebar: [ - "zk-money/userguide", - "zk-money/fees", - "zk-money/assetvaluation", - "zk-money/troubleshooting", - "zk-money/june2021update", - ], }; module.exports = sidebars; diff --git a/docs/static/img/basic-user-acct.png b/docs/static/img/basic-user-acct.png deleted file mode 100644 index 7f368aacf4bc..000000000000 Binary files a/docs/static/img/basic-user-acct.png and /dev/null differ diff --git a/docs/static/img/blue-notes.png b/docs/static/img/blue-notes.png deleted file mode 100644 index d8f9d6e14548..000000000000 Binary files a/docs/static/img/blue-notes.png and /dev/null differ diff --git a/docs/static/img/browser-dev-log.png b/docs/static/img/browser-dev-log.png deleted file mode 100644 index c4d7e719b2dd..000000000000 Binary files a/docs/static/img/browser-dev-log.png and /dev/null differ diff --git a/docs/static/img/chests.png b/docs/static/img/chests.png deleted file mode 100644 index d6a81d9c9b91..000000000000 Binary files a/docs/static/img/chests.png and /dev/null differ diff --git a/docs/static/img/defiexit1.png b/docs/static/img/defiexit1.png new file mode 100644 index 000000000000..4f1c865c3b2c Binary files /dev/null and b/docs/static/img/defiexit1.png differ diff --git a/docs/static/img/defiexit2.png b/docs/static/img/defiexit2.png new file mode 100644 index 000000000000..3e0fcce7a280 Binary files /dev/null and b/docs/static/img/defiexit2.png differ diff --git a/docs/static/img/defiexit3.png b/docs/static/img/defiexit3.png new file mode 100644 index 000000000000..f58d8f0abe2d Binary files /dev/null and b/docs/static/img/defiexit3.png differ diff --git a/docs/static/img/defiexit4.png b/docs/static/img/defiexit4.png new file mode 100644 index 000000000000..148ab37af970 Binary files /dev/null and b/docs/static/img/defiexit4.png differ diff --git a/docs/static/img/defiexit5.png b/docs/static/img/defiexit5.png new file mode 100644 index 000000000000..f0fdaf6fb256 Binary files /dev/null and b/docs/static/img/defiexit5.png differ diff --git a/docs/static/img/defiexit6.png b/docs/static/img/defiexit6.png new file mode 100644 index 000000000000..9622139b1006 Binary files /dev/null and b/docs/static/img/defiexit6.png differ diff --git a/docs/static/img/defiexit7.png b/docs/static/img/defiexit7.png new file mode 100644 index 000000000000..89640483b01a Binary files /dev/null and b/docs/static/img/defiexit7.png differ diff --git a/docs/static/img/docusaurus.png b/docs/static/img/docusaurus.png deleted file mode 100644 index f458149e3c8f..000000000000 Binary files a/docs/static/img/docusaurus.png and /dev/null differ diff --git a/docs/static/img/encrypted-ledger.png b/docs/static/img/encrypted-ledger.png deleted file mode 100644 index a71512b44943..000000000000 Binary files a/docs/static/img/encrypted-ledger.png and /dev/null differ diff --git a/docs/static/img/etherscan-frontpage.png b/docs/static/img/etherscan-frontpage.png deleted file mode 100644 index baadff7e7e14..000000000000 Binary files a/docs/static/img/etherscan-frontpage.png and /dev/null differ diff --git a/docs/static/img/etherscan.png b/docs/static/img/etherscan.png deleted file mode 100644 index cbaf3ffb7669..000000000000 Binary files a/docs/static/img/etherscan.png and /dev/null differ diff --git a/docs/static/img/flywheel.png b/docs/static/img/flywheel.png deleted file mode 100644 index 8bfdb8824a52..000000000000 Binary files a/docs/static/img/flywheel.png and /dev/null differ diff --git a/docs/static/img/lusdexit1.png b/docs/static/img/lusdexit1.png new file mode 100644 index 000000000000..cd2ea23ebce1 Binary files /dev/null and b/docs/static/img/lusdexit1.png differ diff --git a/docs/static/img/lusdexit2.png b/docs/static/img/lusdexit2.png new file mode 100644 index 000000000000..271d42ac0ca5 Binary files /dev/null and b/docs/static/img/lusdexit2.png differ diff --git a/docs/static/img/lusdexit3.png b/docs/static/img/lusdexit3.png new file mode 100644 index 000000000000..0279458567f8 Binary files /dev/null and b/docs/static/img/lusdexit3.png differ diff --git a/docs/static/img/lusdexit4.png b/docs/static/img/lusdexit4.png new file mode 100644 index 000000000000..db3a6bc86aed Binary files /dev/null and b/docs/static/img/lusdexit4.png differ diff --git a/docs/static/img/lusdexit5.png b/docs/static/img/lusdexit5.png new file mode 100644 index 000000000000..35d0f44bdb10 Binary files /dev/null and b/docs/static/img/lusdexit5.png differ diff --git a/docs/static/img/merkle-tree.png b/docs/static/img/merkle-tree.png deleted file mode 100644 index 5a0274146242..000000000000 Binary files a/docs/static/img/merkle-tree.png and /dev/null differ diff --git a/docs/static/img/note-owner.png b/docs/static/img/note-owner.png deleted file mode 100644 index cf1728ac3f83..000000000000 Binary files a/docs/static/img/note-owner.png and /dev/null differ diff --git a/docs/static/img/private-txs.png b/docs/static/img/private-txs.png deleted file mode 100644 index 27a076deb5d3..000000000000 Binary files a/docs/static/img/private-txs.png and /dev/null differ diff --git a/docs/static/img/private-withdraw.png b/docs/static/img/private-withdraw.png deleted file mode 100644 index 4c51311ba8d7..000000000000 Binary files a/docs/static/img/private-withdraw.png and /dev/null differ diff --git a/docs/static/img/proofs-on-proofs.png b/docs/static/img/proofs-on-proofs.png deleted file mode 100644 index 5d2e50ac1746..000000000000 Binary files a/docs/static/img/proofs-on-proofs.png and /dev/null differ diff --git a/docs/static/img/registered-user-acct.png b/docs/static/img/registered-user-acct.png deleted file mode 100644 index 9d4fc617b107..000000000000 Binary files a/docs/static/img/registered-user-acct.png and /dev/null differ diff --git a/docs/static/img/rollup-tx-cost.png b/docs/static/img/rollup-tx-cost.png deleted file mode 100644 index 90d76574653c..000000000000 Binary files a/docs/static/img/rollup-tx-cost.png and /dev/null differ diff --git a/docs/static/img/snoop-ledger.png b/docs/static/img/snoop-ledger.png deleted file mode 100644 index a5a86e9b40a2..000000000000 Binary files a/docs/static/img/snoop-ledger.png and /dev/null differ diff --git a/docs/static/img/snoop-medici.png b/docs/static/img/snoop-medici.png deleted file mode 100644 index d00275e7bb7e..000000000000 Binary files a/docs/static/img/snoop-medici.png and /dev/null differ diff --git a/docs/static/img/twitter-rollup-cost.png b/docs/static/img/twitter-rollup-cost.png deleted file mode 100644 index 163b94ec9c26..000000000000 Binary files a/docs/static/img/twitter-rollup-cost.png and /dev/null differ diff --git a/docs/static/img/undraw_docusaurus_mountain.svg b/docs/static/img/undraw_docusaurus_mountain.svg deleted file mode 100644 index af961c49a888..000000000000 --- a/docs/static/img/undraw_docusaurus_mountain.svg +++ /dev/null @@ -1,171 +0,0 @@ - - Easy to Use - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/static/img/undraw_docusaurus_react.svg b/docs/static/img/undraw_docusaurus_react.svg deleted file mode 100644 index 94b5cf08f88f..000000000000 --- a/docs/static/img/undraw_docusaurus_react.svg +++ /dev/null @@ -1,170 +0,0 @@ - - Powered by React - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/static/img/undraw_docusaurus_tree.svg b/docs/static/img/undraw_docusaurus_tree.svg deleted file mode 100644 index d9161d33920c..000000000000 --- a/docs/static/img/undraw_docusaurus_tree.svg +++ /dev/null @@ -1,40 +0,0 @@ - - Focus on What Matters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/static/img/withdraw1.png b/docs/static/img/withdraw1.png new file mode 100644 index 000000000000..15271e4e1e40 Binary files /dev/null and b/docs/static/img/withdraw1.png differ diff --git a/docs/static/img/withdraw2.png b/docs/static/img/withdraw2.png new file mode 100644 index 000000000000..6dac197a9fae Binary files /dev/null and b/docs/static/img/withdraw2.png differ diff --git a/docs/static/img/withdraw3.png b/docs/static/img/withdraw3.png new file mode 100644 index 000000000000..a2865012c6d8 Binary files /dev/null and b/docs/static/img/withdraw3.png differ diff --git a/docs/static/img/withdraw4.png b/docs/static/img/withdraw4.png new file mode 100644 index 000000000000..24f7ac921cf4 Binary files /dev/null and b/docs/static/img/withdraw4.png differ diff --git a/docs/static/img/withdraw5.png b/docs/static/img/withdraw5.png new file mode 100644 index 000000000000..45ee8969b27a Binary files /dev/null and b/docs/static/img/withdraw5.png differ diff --git a/docs/static/img/zkmoney-envelope.jpeg b/docs/static/img/zkmoney-envelope.jpeg deleted file mode 100644 index 394700417106..000000000000 Binary files a/docs/static/img/zkmoney-envelope.jpeg and /dev/null differ diff --git a/docs/static/img/zkmoney1.png b/docs/static/img/zkmoney1.png deleted file mode 100644 index e819298f1635..000000000000 Binary files a/docs/static/img/zkmoney1.png and /dev/null differ diff --git a/docs/yarn.lock b/docs/yarn.lock index 4fe9da6556ed..5b5bc2c34380 100644 --- a/docs/yarn.lock +++ b/docs/yarn.lock @@ -130,7 +130,7 @@ "@algolia/logger-common" "4.14.3" "@algolia/requester-common" "4.14.3" -"@ampproject/remapping@^2.1.0": +"@ampproject/remapping@^2.2.0": version "2.2.0" resolved "https://registry.yarnpkg.com/@ampproject/remapping/-/remapping-2.2.0.tgz#56c133824780de3174aed5ab6834f3026790154d" integrity sha512-qRmjj8nj9qmLTQXXmaR1cck3UXSRMPrbsLJAasZpF+t3riI71BXed5ebIOYwQntykeZuhjsdweEc9BxH5Jc26w== @@ -146,9 +146,9 @@ "@babel/highlight" "^7.18.6" "@babel/compat-data@^7.17.7", "@babel/compat-data@^7.20.1", "@babel/compat-data@^7.20.5": - version "7.20.10" - resolved "https://registry.yarnpkg.com/@babel/compat-data/-/compat-data-7.20.10.tgz#9d92fa81b87542fff50e848ed585b4212c1d34ec" - integrity sha512-sEnuDPpOJR/fcafHMjpcpGN5M2jbUGUHwmuWKM/YdPzeEDJg8bgmbcWQFUfE32MQjti1koACvoPVsDe8Uq+idg== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/compat-data/-/compat-data-7.21.0.tgz#c241dc454e5b5917e40d37e525e2f4530c399298" + integrity sha512-gMuZsmsgxk/ENC3O/fRw5QY8A9/uxQbbCEypnLIiYYc/qVJtEV7ouxC3EllIIwNzMqAQee5tanFabWsUOutS7g== "@babel/core@7.12.9": version "7.12.9" @@ -173,33 +173,34 @@ source-map "^0.5.0" "@babel/core@^7.18.6", "@babel/core@^7.19.6": - version "7.20.12" - resolved "https://registry.yarnpkg.com/@babel/core/-/core-7.20.12.tgz#7930db57443c6714ad216953d1356dac0eb8496d" - integrity sha512-XsMfHovsUYHFMdrIHkZphTN/2Hzzi78R08NuHfDBehym2VsPDL6Zn/JAD/JQdnRvbSsbQc4mVaU1m6JgtTEElg== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/core/-/core-7.21.0.tgz#1341aefdcc14ccc7553fcc688dd8986a2daffc13" + integrity sha512-PuxUbxcW6ZYe656yL3EAhpy7qXKq0DmYsrJLpbB8XrsCP9Nm+XCg9XFMb5vIDliPD7+U/+M+QJlH17XOcB7eXA== dependencies: - "@ampproject/remapping" "^2.1.0" + "@ampproject/remapping" "^2.2.0" "@babel/code-frame" "^7.18.6" - "@babel/generator" "^7.20.7" + "@babel/generator" "^7.21.0" "@babel/helper-compilation-targets" "^7.20.7" - "@babel/helper-module-transforms" "^7.20.11" - "@babel/helpers" "^7.20.7" - "@babel/parser" "^7.20.7" + "@babel/helper-module-transforms" "^7.21.0" + "@babel/helpers" "^7.21.0" + "@babel/parser" "^7.21.0" "@babel/template" "^7.20.7" - "@babel/traverse" "^7.20.12" - "@babel/types" "^7.20.7" + "@babel/traverse" "^7.21.0" + "@babel/types" "^7.21.0" convert-source-map "^1.7.0" debug "^4.1.0" gensync "^1.0.0-beta.2" json5 "^2.2.2" semver "^6.3.0" -"@babel/generator@^7.12.5", "@babel/generator@^7.18.7", "@babel/generator@^7.20.7": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/generator/-/generator-7.20.7.tgz#f8ef57c8242665c5929fe2e8d82ba75460187b4a" - integrity sha512-7wqMOJq8doJMZmP4ApXTzLxSr7+oO2jroJURrVEp6XShrQUObV8Tq/D0NCcoYg2uHqUrjzO0zwBjoYzelxK+sw== +"@babel/generator@^7.12.5", "@babel/generator@^7.18.7", "@babel/generator@^7.21.0", "@babel/generator@^7.21.1": + version "7.21.1" + resolved "https://registry.yarnpkg.com/@babel/generator/-/generator-7.21.1.tgz#951cc626057bc0af2c35cd23e9c64d384dea83dd" + integrity sha512-1lT45bAYlQhFn/BHivJs43AiW2rg3/UbLyShGfF3C0KmHvO5fSghWd5kBJy30kpRRucGzXStvnnCFniCR2kXAA== dependencies: - "@babel/types" "^7.20.7" + "@babel/types" "^7.21.0" "@jridgewell/gen-mapping" "^0.3.2" + "@jridgewell/trace-mapping" "^0.3.17" jsesc "^2.5.1" "@babel/helper-annotate-as-pure@^7.18.6": @@ -228,27 +229,27 @@ lru-cache "^5.1.1" semver "^6.3.0" -"@babel/helper-create-class-features-plugin@^7.18.6", "@babel/helper-create-class-features-plugin@^7.20.5", "@babel/helper-create-class-features-plugin@^7.20.7": - version "7.20.12" - resolved "https://registry.yarnpkg.com/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.20.12.tgz#4349b928e79be05ed2d1643b20b99bb87c503819" - integrity sha512-9OunRkbT0JQcednL0UFvbfXpAsUXiGjUk0a7sN8fUXX7Mue79cUSMjHGDRRi/Vz9vYlpIhLV5fMD5dKoMhhsNQ== +"@babel/helper-create-class-features-plugin@^7.18.6", "@babel/helper-create-class-features-plugin@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.21.0.tgz#64f49ecb0020532f19b1d014b03bccaa1ab85fb9" + integrity sha512-Q8wNiMIdwsv5la5SPxNYzzkPnjgC0Sy0i7jLkVOCdllu/xcVNkr3TeZzbHBJrj+XXRqzX5uCyCoV9eu6xUG7KQ== dependencies: "@babel/helper-annotate-as-pure" "^7.18.6" "@babel/helper-environment-visitor" "^7.18.9" - "@babel/helper-function-name" "^7.19.0" - "@babel/helper-member-expression-to-functions" "^7.20.7" + "@babel/helper-function-name" "^7.21.0" + "@babel/helper-member-expression-to-functions" "^7.21.0" "@babel/helper-optimise-call-expression" "^7.18.6" "@babel/helper-replace-supers" "^7.20.7" "@babel/helper-skip-transparent-expression-wrappers" "^7.20.0" "@babel/helper-split-export-declaration" "^7.18.6" "@babel/helper-create-regexp-features-plugin@^7.18.6", "@babel/helper-create-regexp-features-plugin@^7.20.5": - version "7.20.5" - resolved "https://registry.yarnpkg.com/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.20.5.tgz#5ea79b59962a09ec2acf20a963a01ab4d076ccca" - integrity sha512-m68B1lkg3XDGX5yCvGO0kPx3v9WIYLnzjKfPcQiwntEQa5ZeRkPmo2X/ISJc8qxWGfwUr+kvZAeEzAwLec2r2w== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.21.0.tgz#53ff78472e5ce10a52664272a239787107603ebb" + integrity sha512-N+LaFW/auRSWdx7SHD/HiARwXQju1vXTW4fKr4u5SgBUTm51OKEjKgj+cs00ggW3kEvNqwErnlwuq7Y3xBe4eg== dependencies: "@babel/helper-annotate-as-pure" "^7.18.6" - regexpu-core "^5.2.1" + regexpu-core "^5.3.1" "@babel/helper-define-polyfill-provider@^0.3.3": version "0.3.3" @@ -274,13 +275,13 @@ dependencies: "@babel/types" "^7.18.6" -"@babel/helper-function-name@^7.18.9", "@babel/helper-function-name@^7.19.0": - version "7.19.0" - resolved "https://registry.yarnpkg.com/@babel/helper-function-name/-/helper-function-name-7.19.0.tgz#941574ed5390682e872e52d3f38ce9d1bef4648c" - integrity sha512-WAwHBINyrpqywkUH0nTnNgI5ina5TFn85HKS0pbPDfxFfhyR/aNQEn4hGi1P1JyT//I0t4OgXUlofzWILRvS5w== +"@babel/helper-function-name@^7.18.9", "@babel/helper-function-name@^7.19.0", "@babel/helper-function-name@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helper-function-name/-/helper-function-name-7.21.0.tgz#d552829b10ea9f120969304023cd0645fa00b1b4" + integrity sha512-HfK1aMRanKHpxemaY2gqBmL04iAPOPRj7DxtNbiDOrJK+gdwkiNRVpCpUJYbUT+aZyemKN8brqTOxzCaG6ExRg== dependencies: - "@babel/template" "^7.18.10" - "@babel/types" "^7.19.0" + "@babel/template" "^7.20.7" + "@babel/types" "^7.21.0" "@babel/helper-hoist-variables@^7.18.6": version "7.18.6" @@ -289,12 +290,12 @@ dependencies: "@babel/types" "^7.18.6" -"@babel/helper-member-expression-to-functions@^7.20.7": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.20.7.tgz#a6f26e919582275a93c3aa6594756d71b0bb7f05" - integrity sha512-9J0CxJLq315fEdi4s7xK5TQaNYjZw+nDVpVqr1axNGKzdrdwYBD5b4uKv3n75aABG0rCCTK8Im8Ww7eYfMrZgw== +"@babel/helper-member-expression-to-functions@^7.20.7", "@babel/helper-member-expression-to-functions@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.21.0.tgz#319c6a940431a133897148515877d2f3269c3ba5" + integrity sha512-Muu8cdZwNN6mRRNG6lAYErJ5X3bRevgYR2O8wN0yn7jJSnGDu6eG59RfT29JHxGUovyfrh6Pj0XzmR7drNVL3Q== dependencies: - "@babel/types" "^7.20.7" + "@babel/types" "^7.21.0" "@babel/helper-module-imports@^7.18.6": version "7.18.6" @@ -303,10 +304,10 @@ dependencies: "@babel/types" "^7.18.6" -"@babel/helper-module-transforms@^7.12.1", "@babel/helper-module-transforms@^7.18.6", "@babel/helper-module-transforms@^7.20.11": - version "7.20.11" - resolved "https://registry.yarnpkg.com/@babel/helper-module-transforms/-/helper-module-transforms-7.20.11.tgz#df4c7af713c557938c50ea3ad0117a7944b2f1b0" - integrity sha512-uRy78kN4psmji1s2QtbtcCSaj/LILFDp0f/ymhpQH5QY3nljUZCaNWz9X1dEj/8MBdBEFECs7yRhKn8i7NjZgg== +"@babel/helper-module-transforms@^7.12.1", "@babel/helper-module-transforms@^7.18.6", "@babel/helper-module-transforms@^7.20.11", "@babel/helper-module-transforms@^7.21.0", "@babel/helper-module-transforms@^7.21.2": + version "7.21.2" + resolved "https://registry.yarnpkg.com/@babel/helper-module-transforms/-/helper-module-transforms-7.21.2.tgz#160caafa4978ac8c00ac66636cb0fa37b024e2d2" + integrity sha512-79yj2AR4U/Oqq/WOV7Lx6hUjau1Zfo4cI+JLAVYeMV5XIlbOhmjEk5ulbTc9fMpmlojzZHkUUxAiK+UKn+hNQQ== dependencies: "@babel/helper-environment-visitor" "^7.18.9" "@babel/helper-module-imports" "^7.18.6" @@ -314,8 +315,8 @@ "@babel/helper-split-export-declaration" "^7.18.6" "@babel/helper-validator-identifier" "^7.19.1" "@babel/template" "^7.20.7" - "@babel/traverse" "^7.20.10" - "@babel/types" "^7.20.7" + "@babel/traverse" "^7.21.2" + "@babel/types" "^7.21.2" "@babel/helper-optimise-call-expression@^7.18.6": version "7.18.6" @@ -387,10 +388,10 @@ resolved "https://registry.yarnpkg.com/@babel/helper-validator-identifier/-/helper-validator-identifier-7.19.1.tgz#7eea834cf32901ffdc1a7ee555e2f9c27e249ca2" integrity sha512-awrNfaMtnHUr653GgGEs++LlAvW6w+DcPrOliSMXWCKo597CwL5Acf/wWdNkf/tfEQE3mjkeD1YOVZOUV/od1w== -"@babel/helper-validator-option@^7.18.6": - version "7.18.6" - resolved "https://registry.yarnpkg.com/@babel/helper-validator-option/-/helper-validator-option-7.18.6.tgz#bf0d2b5a509b1f336099e4ff36e1a63aa5db4db8" - integrity sha512-XO7gESt5ouv/LRJdrVjkShckw6STTaB7l9BrpBaAHDeF5YZT+01PCwmR0SJHnkW6i8OwW/EVWRShfi4j2x+KQw== +"@babel/helper-validator-option@^7.18.6", "@babel/helper-validator-option@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helper-validator-option/-/helper-validator-option-7.21.0.tgz#8224c7e13ace4bafdc4004da2cf064ef42673180" + integrity sha512-rmL/B8/f0mKS2baE9ZpyTcTavvEuWhTTW8amjzXNvYG4AwBsqTLikfXsEofsJEfKHf+HQVQbFOHy6o+4cnC/fQ== "@babel/helper-wrap-function@^7.18.9": version "7.20.5" @@ -402,14 +403,14 @@ "@babel/traverse" "^7.20.5" "@babel/types" "^7.20.5" -"@babel/helpers@^7.12.5", "@babel/helpers@^7.20.7": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/helpers/-/helpers-7.20.7.tgz#04502ff0feecc9f20ecfaad120a18f011a8e6dce" - integrity sha512-PBPjs5BppzsGaxHQCDKnZ6Gd9s6xl8bBCluz3vEInLGRJmnZan4F6BYCeqtyXqkk4W5IlPmjK4JlOuZkpJ3xZA== +"@babel/helpers@^7.12.5", "@babel/helpers@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/helpers/-/helpers-7.21.0.tgz#9dd184fb5599862037917cdc9eecb84577dc4e7e" + integrity sha512-XXve0CBtOW0pd7MRzzmoyuSj0e3SEzj8pgyFxnTT1NJZL38BD1MK7yYrm8yefRPIDvNNe14xR4FdbHwpInD4rA== dependencies: "@babel/template" "^7.20.7" - "@babel/traverse" "^7.20.7" - "@babel/types" "^7.20.7" + "@babel/traverse" "^7.21.0" + "@babel/types" "^7.21.0" "@babel/highlight@^7.18.6": version "7.18.6" @@ -420,10 +421,10 @@ chalk "^2.0.0" js-tokens "^4.0.0" -"@babel/parser@^7.12.7", "@babel/parser@^7.18.8", "@babel/parser@^7.20.7": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/parser/-/parser-7.20.7.tgz#66fe23b3c8569220817d5feb8b9dcdc95bb4f71b" - integrity sha512-T3Z9oHybU+0vZlY9CiDSJQTD5ZapcW18ZctFMi0MOAl/4BjFF4ul7NVSARLdbGO5vDqy9eQiGTV0LtKfvCYvcg== +"@babel/parser@^7.12.7", "@babel/parser@^7.18.8", "@babel/parser@^7.20.7", "@babel/parser@^7.21.0", "@babel/parser@^7.21.2": + version "7.21.2" + resolved "https://registry.yarnpkg.com/@babel/parser/-/parser-7.21.2.tgz#dacafadfc6d7654c3051a66d6fe55b6cb2f2a0b3" + integrity sha512-URpaIJQwEkEC2T9Kn+Ai6Xe/02iNaVCuT/PtoRz3GPVJVDpPd7mLo+VddTbhCRU9TXqW5mSrQfXZyi8kDKOVpQ== "@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression@^7.18.6": version "7.18.6" @@ -460,11 +461,11 @@ "@babel/helper-plugin-utils" "^7.18.6" "@babel/plugin-proposal-class-static-block@^7.18.6": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-class-static-block/-/plugin-proposal-class-static-block-7.20.7.tgz#92592e9029b13b15be0f7ce6a7aedc2879ca45a7" - integrity sha512-AveGOoi9DAjUYYuUAG//Ig69GlazLnoyzMw68VCDux+c1tsnnH/OkYcpz/5xzMkEFC6UxjR5Gw1c+iY2wOGVeQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-class-static-block/-/plugin-proposal-class-static-block-7.21.0.tgz#77bdd66fb7b605f3a61302d224bdfacf5547977d" + integrity sha512-XP5G9MWNUskFuP30IfFSEFB0Z6HzLIUcjYM4bYOPHXl7eiJ9HFv8tWj6TXTN5QODiEhDZAeI4hLok2iHFFV4hw== dependencies: - "@babel/helper-create-class-features-plugin" "^7.20.7" + "@babel/helper-create-class-features-plugin" "^7.21.0" "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-syntax-class-static-block" "^7.14.5" @@ -545,9 +546,9 @@ "@babel/plugin-syntax-optional-catch-binding" "^7.8.3" "@babel/plugin-proposal-optional-chaining@^7.18.9", "@babel/plugin-proposal-optional-chaining@^7.20.7": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-optional-chaining/-/plugin-proposal-optional-chaining-7.20.7.tgz#49f2b372519ab31728cc14115bb0998b15bfda55" - integrity sha512-T+A7b1kfjtRM51ssoOfS1+wbyCVqorfyZhT99TvxxLMirPShD8CzKMRepMlCBGM5RpHMbn8s+5MMHnPstJH6mQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-optional-chaining/-/plugin-proposal-optional-chaining-7.21.0.tgz#886f5c8978deb7d30f678b2e24346b287234d3ea" + integrity sha512-p4zeefM72gpmEe2fkUr/OnOXpWEf8nAgk7ZYVqqfFiyIG7oFfVZcCrU64hWn5xp4tQ9LkV4bTIa5rD0KANpKNA== dependencies: "@babel/helper-plugin-utils" "^7.20.2" "@babel/helper-skip-transparent-expression-wrappers" "^7.20.0" @@ -562,12 +563,12 @@ "@babel/helper-plugin-utils" "^7.18.6" "@babel/plugin-proposal-private-property-in-object@^7.18.6": - version "7.20.5" - resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-private-property-in-object/-/plugin-proposal-private-property-in-object-7.20.5.tgz#309c7668f2263f1c711aa399b5a9a6291eef6135" - integrity sha512-Vq7b9dUA12ByzB4EjQTPo25sFhY+08pQDBSZRtUAkj7lb7jahaHR5igera16QZ+3my1nYR4dKsNdYj5IjPHilQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-proposal-private-property-in-object/-/plugin-proposal-private-property-in-object-7.21.0.tgz#19496bd9883dd83c23c7d7fc45dcd9ad02dfa1dc" + integrity sha512-ha4zfehbJjc5MmXBlHec1igel5TJXXLDDRbuJ4+XT2TJcyD9/V1919BA8gMvsdHcNMBy4WBUBiRb3nw/EQUtBw== dependencies: "@babel/helper-annotate-as-pure" "^7.18.6" - "@babel/helper-create-class-features-plugin" "^7.20.5" + "@babel/helper-create-class-features-plugin" "^7.21.0" "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-syntax-private-property-in-object" "^7.14.5" @@ -729,21 +730,21 @@ "@babel/helper-plugin-utils" "^7.18.6" "@babel/plugin-transform-block-scoping@^7.20.2": - version "7.20.11" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.20.11.tgz#9f5a3424bd112a3f32fe0cf9364fbb155cff262a" - integrity sha512-tA4N427a7fjf1P0/2I4ScsHGc5jcHPbb30xMbaTke2gxDuWpUfXDuX1FEymJwKk4tuGUvGcejAR6HdZVqmmPyw== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.21.0.tgz#e737b91037e5186ee16b76e7ae093358a5634f02" + integrity sha512-Mdrbunoh9SxwFZapeHVrwFmri16+oYotcZysSzhNIVDwIAb1UV+kvnxULSYq9J3/q5MDG+4X6w8QVgD1zhBXNQ== dependencies: "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-transform-classes@^7.20.2": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-classes/-/plugin-transform-classes-7.20.7.tgz#f438216f094f6bb31dc266ebfab8ff05aecad073" - integrity sha512-LWYbsiXTPKl+oBlXUGlwNlJZetXD5Am+CyBdqhPsDVjM9Jc8jwBJFrKhHf900Kfk2eZG1y9MAG3UNajol7A4VQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-classes/-/plugin-transform-classes-7.21.0.tgz#f469d0b07a4c5a7dbb21afad9e27e57b47031665" + integrity sha512-RZhbYTCEUAe6ntPehC4hlslPWosNHDox+vAs4On/mCLRLfoDVHf6hVEd7kuxr1RnHwJmxFfUM3cZiZRmPxJPXQ== dependencies: "@babel/helper-annotate-as-pure" "^7.18.6" "@babel/helper-compilation-targets" "^7.20.7" "@babel/helper-environment-visitor" "^7.18.9" - "@babel/helper-function-name" "^7.19.0" + "@babel/helper-function-name" "^7.21.0" "@babel/helper-optimise-call-expression" "^7.18.6" "@babel/helper-plugin-utils" "^7.20.2" "@babel/helper-replace-supers" "^7.20.7" @@ -789,11 +790,11 @@ "@babel/helper-plugin-utils" "^7.18.6" "@babel/plugin-transform-for-of@^7.18.8": - version "7.18.8" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.18.8.tgz#6ef8a50b244eb6a0bdbad0c7c61877e4e30097c1" - integrity sha512-yEfTRnjuskWYo0k1mHUqrVWaZwrdq8AYbfrpqULOJOaucGSp4mNMVps+YtA8byoevxS/urwU75vyhQIxcCgiBQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.21.0.tgz#964108c9988de1a60b4be2354a7d7e245f36e86e" + integrity sha512-LlUYlydgDkKpIY7mcBWvyPPmMcOphEyYA27Ef4xpbh1IiDNLr0kZsos2nf92vz3IccvJI25QUwp86Eo5s6HmBQ== dependencies: - "@babel/helper-plugin-utils" "^7.18.6" + "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-transform-function-name@^7.18.9": version "7.18.9" @@ -827,11 +828,11 @@ "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-transform-modules-commonjs@^7.19.6": - version "7.20.11" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.20.11.tgz#8cb23010869bf7669fd4b3098598b6b2be6dc607" - integrity sha512-S8e1f7WQ7cimJQ51JkAaDrEtohVEitXjgCGAS2N8S31Y42E+kWwfSz83LYz57QdBm7q9diARVqanIaH2oVgQnw== + version "7.21.2" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.21.2.tgz#6ff5070e71e3192ef2b7e39820a06fb78e3058e7" + integrity sha512-Cln+Yy04Gxua7iPdj6nOV96smLGjpElir5YwzF0LBPKoPlLDNJePNlrGGaybAJkd0zKRnOVXOgizSqPYMNYkzA== dependencies: - "@babel/helper-module-transforms" "^7.20.11" + "@babel/helper-module-transforms" "^7.21.2" "@babel/helper-plugin-utils" "^7.20.2" "@babel/helper-simple-access" "^7.20.2" @@ -912,15 +913,15 @@ "@babel/plugin-transform-react-jsx" "^7.18.6" "@babel/plugin-transform-react-jsx@^7.18.6": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-jsx/-/plugin-transform-react-jsx-7.20.7.tgz#025d85a1935fd7e19dfdcb1b1d4df34d4da484f7" - integrity sha512-Tfq7qqD+tRj3EoDhY00nn2uP2hsRxgYGi5mLQ5TimKav0a9Lrpd4deE+fcLXU8zFYRjlKPHZhpCvfEA6qnBxqQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-react-jsx/-/plugin-transform-react-jsx-7.21.0.tgz#656b42c2fdea0a6d8762075d58ef9d4e3c4ab8a2" + integrity sha512-6OAWljMvQrZjR2DaNhVfRz6dkCAVV+ymcLUmaf8bccGOHn2v5rHJK3tTpij0BuhdYWP4LLaqj5lwcdlpAAPuvg== dependencies: "@babel/helper-annotate-as-pure" "^7.18.6" "@babel/helper-module-imports" "^7.18.6" "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-syntax-jsx" "^7.18.6" - "@babel/types" "^7.20.7" + "@babel/types" "^7.21.0" "@babel/plugin-transform-react-pure-annotations@^7.18.6": version "7.18.6" @@ -946,12 +947,12 @@ "@babel/helper-plugin-utils" "^7.18.6" "@babel/plugin-transform-runtime@^7.18.6": - version "7.19.6" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.19.6.tgz#9d2a9dbf4e12644d6f46e5e75bfbf02b5d6e9194" - integrity sha512-PRH37lz4JU156lYFW1p8OxE5i7d6Sl/zV58ooyr+q1J1lnQPyg5tIiXlIwNVhJaY4W3TmOtdc8jqdXQcB1v5Yw== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.21.0.tgz#2a884f29556d0a68cd3d152dcc9e6c71dfb6eee8" + integrity sha512-ReY6pxwSzEU0b3r2/T/VhqMKg/AkceBT19X0UptA3/tYi5Pe2eXgEUH+NNMC5nok6c6XQz5tyVTUpuezRfSMSg== dependencies: "@babel/helper-module-imports" "^7.18.6" - "@babel/helper-plugin-utils" "^7.19.0" + "@babel/helper-plugin-utils" "^7.20.2" babel-plugin-polyfill-corejs2 "^0.3.3" babel-plugin-polyfill-corejs3 "^0.6.0" babel-plugin-polyfill-regenerator "^0.4.1" @@ -993,12 +994,12 @@ dependencies: "@babel/helper-plugin-utils" "^7.18.9" -"@babel/plugin-transform-typescript@^7.18.6": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/plugin-transform-typescript/-/plugin-transform-typescript-7.20.7.tgz#673f49499cd810ae32a1ea5f3f8fab370987e055" - integrity sha512-m3wVKEvf6SoszD8pu4NZz3PvfKRCMgk6D6d0Qi9hNnlM5M6CFS92EgF4EiHVLKbU0r/r7ty1hg7NPZwE7WRbYw== +"@babel/plugin-transform-typescript@^7.21.0": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/plugin-transform-typescript/-/plugin-transform-typescript-7.21.0.tgz#f0956a153679e3b377ae5b7f0143427151e4c848" + integrity sha512-xo///XTPp3mDzTtrqXoBlK9eiAYW3wv9JXglcn/u1bi60RW11dEUxIgA8cbnDhutS1zacjMRmAwxE0gMklLnZg== dependencies: - "@babel/helper-create-class-features-plugin" "^7.20.7" + "@babel/helper-create-class-features-plugin" "^7.21.0" "@babel/helper-plugin-utils" "^7.20.2" "@babel/plugin-syntax-typescript" "^7.20.0" @@ -1122,23 +1123,35 @@ "@babel/plugin-transform-react-pure-annotations" "^7.18.6" "@babel/preset-typescript@^7.18.6": - version "7.18.6" - resolved "https://registry.yarnpkg.com/@babel/preset-typescript/-/preset-typescript-7.18.6.tgz#ce64be3e63eddc44240c6358daefac17b3186399" - integrity sha512-s9ik86kXBAnD760aybBucdpnLsAt0jK1xqJn2juOn9lkOvSHV60os5hxoVJsPzMQxvnUJFAlkont2DvvaYEBtQ== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/preset-typescript/-/preset-typescript-7.21.0.tgz#bcbbca513e8213691fe5d4b23d9251e01f00ebff" + integrity sha512-myc9mpoVA5m1rF8K8DgLEatOYFDpwC+RkMkjZ0Du6uI62YvDe8uxIEYVs/VCdSJ097nlALiU/yBC7//3nI+hNg== dependencies: - "@babel/helper-plugin-utils" "^7.18.6" - "@babel/helper-validator-option" "^7.18.6" - "@babel/plugin-transform-typescript" "^7.18.6" + "@babel/helper-plugin-utils" "^7.20.2" + "@babel/helper-validator-option" "^7.21.0" + "@babel/plugin-transform-typescript" "^7.21.0" + +"@babel/regjsgen@^0.8.0": + version "0.8.0" + resolved "https://registry.yarnpkg.com/@babel/regjsgen/-/regjsgen-0.8.0.tgz#f0ba69b075e1f05fb2825b7fad991e7adbb18310" + integrity sha512-x/rqGMdzj+fWZvCOYForTghzbtqPDZ5gPwaoNGHdgDfF2QA/XZbCBp4Moo5scrkAMPhB7z26XM/AaHuIJdgauA== "@babel/runtime-corejs3@^7.18.6": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/runtime-corejs3/-/runtime-corejs3-7.20.7.tgz#a1e5ea3d758ba6beb715210142912e3f29981d84" - integrity sha512-jr9lCZ4RbRQmCR28Q8U8Fu49zvFqLxTY9AMOUz+iyMohMoAgpEcVxY+wJNay99oXOpOcCTODkk70NDN2aaJEeg== + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/runtime-corejs3/-/runtime-corejs3-7.21.0.tgz#6e4939d9d9789ff63e2dc58e88f13a3913a24eba" + integrity sha512-TDD4UJzos3JJtM+tHX+w2Uc+KWj7GV+VKKFdMVd2Rx8sdA19hcc3P3AHFYd5LVOw+pYuSd5lICC3gm52B6Rwxw== dependencies: core-js-pure "^3.25.1" regenerator-runtime "^0.13.11" -"@babel/runtime@^7.1.2", "@babel/runtime@^7.10.2", "@babel/runtime@^7.10.3", "@babel/runtime@^7.12.13", "@babel/runtime@^7.12.5", "@babel/runtime@^7.18.6", "@babel/runtime@^7.8.4": +"@babel/runtime@^7.1.2", "@babel/runtime@^7.10.3", "@babel/runtime@^7.12.13", "@babel/runtime@^7.12.5", "@babel/runtime@^7.18.6", "@babel/runtime@^7.8.4": + version "7.21.0" + resolved "https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.21.0.tgz#5b55c9d394e5fcf304909a8b00c07dc217b56673" + integrity sha512-xwII0//EObnq89Ji5AKYQaRYiW/nZ3llSv29d49IuxPhKbtJoLP+9QUUZ4nVragQVtaVGeZrpB+ZtG/Pdy/POw== + dependencies: + regenerator-runtime "^0.13.11" + +"@babel/runtime@^7.10.2": version "7.20.7" resolved "https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.20.7.tgz#fcb41a5a70550e04a7b708037c7c32f7f356d8fd" integrity sha512-UF0tvkUtxwAgZ5W/KrkHf0Rn0fdnLDU9ScxBrEVNUprE/MzirjK4MJUX1/BVDv00Sv8cljtukVK1aky++X1SjQ== @@ -1154,36 +1167,46 @@ "@babel/parser" "^7.20.7" "@babel/types" "^7.20.7" -"@babel/traverse@^7.12.9", "@babel/traverse@^7.18.8", "@babel/traverse@^7.20.10", "@babel/traverse@^7.20.12", "@babel/traverse@^7.20.5", "@babel/traverse@^7.20.7": - version "7.20.12" - resolved "https://registry.yarnpkg.com/@babel/traverse/-/traverse-7.20.12.tgz#7f0f787b3a67ca4475adef1f56cb94f6abd4a4b5" - integrity sha512-MsIbFN0u+raeja38qboyF8TIT7K0BFzz/Yd/77ta4MsUsmP2RAnidIlwq7d5HFQrH/OZJecGV6B71C4zAgpoSQ== +"@babel/traverse@^7.12.9", "@babel/traverse@^7.18.8", "@babel/traverse@^7.20.5", "@babel/traverse@^7.20.7", "@babel/traverse@^7.21.0", "@babel/traverse@^7.21.2": + version "7.21.2" + resolved "https://registry.yarnpkg.com/@babel/traverse/-/traverse-7.21.2.tgz#ac7e1f27658750892e815e60ae90f382a46d8e75" + integrity sha512-ts5FFU/dSUPS13tv8XiEObDu9K+iagEKME9kAbaP7r0Y9KtZJZ+NGndDvWoRAYNpeWafbpFeki3q9QoMD6gxyw== dependencies: "@babel/code-frame" "^7.18.6" - "@babel/generator" "^7.20.7" + "@babel/generator" "^7.21.1" "@babel/helper-environment-visitor" "^7.18.9" - "@babel/helper-function-name" "^7.19.0" + "@babel/helper-function-name" "^7.21.0" "@babel/helper-hoist-variables" "^7.18.6" "@babel/helper-split-export-declaration" "^7.18.6" - "@babel/parser" "^7.20.7" - "@babel/types" "^7.20.7" + "@babel/parser" "^7.21.2" + "@babel/types" "^7.21.2" debug "^4.1.0" globals "^11.1.0" -"@babel/types@^7.12.7", "@babel/types@^7.18.6", "@babel/types@^7.18.9", "@babel/types@^7.19.0", "@babel/types@^7.20.0", "@babel/types@^7.20.2", "@babel/types@^7.20.5", "@babel/types@^7.20.7", "@babel/types@^7.4.4": - version "7.20.7" - resolved "https://registry.yarnpkg.com/@babel/types/-/types-7.20.7.tgz#54ec75e252318423fc07fb644dc6a58a64c09b7f" - integrity sha512-69OnhBxSSgK0OzTJai4kyPDiKTIe3j+ctaHdIGVbRahTLAT7L3R9oeXHC2aVSuGYt3cVnoAMDmOCgJ2yaiLMvg== +"@babel/types@^7.12.7", "@babel/types@^7.18.6", "@babel/types@^7.18.9", "@babel/types@^7.20.0", "@babel/types@^7.20.2", "@babel/types@^7.20.5", "@babel/types@^7.20.7", "@babel/types@^7.21.0", "@babel/types@^7.21.2", "@babel/types@^7.4.4": + version "7.21.2" + resolved "https://registry.yarnpkg.com/@babel/types/-/types-7.21.2.tgz#92246f6e00f91755893c2876ad653db70c8310d1" + integrity sha512-3wRZSs7jiFaB8AjxiiD+VqN5DTG2iRvJGQ+qYFrs/654lg6kGTQWIOFjlBo5RaXuAZjBmP3+OQH4dmhqiiyYxw== dependencies: "@babel/helper-string-parser" "^7.19.4" "@babel/helper-validator-identifier" "^7.19.1" to-fast-properties "^2.0.0" +"@braintree/sanitize-url@^6.0.0": + version "6.0.2" + resolved "https://registry.yarnpkg.com/@braintree/sanitize-url/-/sanitize-url-6.0.2.tgz#6110f918d273fe2af8ea1c4398a88774bb9fc12f" + integrity sha512-Tbsj02wXCbqGmzdnXNk0SOF19ChhRU70BsroIi4Pm6Ehp56in6vch94mfbdQ17DozxkL3BAVjbZ4Qc1a0HFRAg== + "@colors/colors@1.5.0": version "1.5.0" resolved "https://registry.yarnpkg.com/@colors/colors/-/colors-1.5.0.tgz#bb504579c1cae923e6576a4f5da43d25f97bdbd9" integrity sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ== +"@discoveryjs/json-ext@0.5.7": + version "0.5.7" + resolved "https://registry.yarnpkg.com/@discoveryjs/json-ext/-/json-ext-0.5.7.tgz#1d572bfbbe14b7704e0ba0f39b74815b84870d70" + integrity sha512-dBVuXR082gk3jsFp7Rd/JI4kytwGHecnCoTtXFb7DB6CNHp4rg5k1bhg0nWdLGLnOV71lmDzGQaLMy8iPLY0pw== + "@docsearch/css@3.3.2": version "3.3.2" resolved "https://registry.yarnpkg.com/@docsearch/css/-/css-3.3.2.tgz#2c49995e6fbc7834c75f317b277ed6e4019223a4" @@ -1199,10 +1222,10 @@ "@docsearch/css" "3.3.2" algoliasearch "^4.0.0" -"@docusaurus/core@2.2.0", "@docusaurus/core@^2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/core/-/core-2.2.0.tgz#64c9ee31502c23b93c869f8188f73afaf5fd4867" - integrity sha512-Vd6XOluKQqzG12fEs9prJgDtyn6DPok9vmUWDR2E6/nV5Fl9SVkhEQOBxwObjk3kQh7OY7vguFaLh0jqdApWsA== +"@docusaurus/core@2.3.1", "@docusaurus/core@^2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/core/-/core-2.3.1.tgz#32849f2ffd2f086a4e55739af8c4195c5eb386f2" + integrity sha512-0Jd4jtizqnRAr7svWaBbbrCCN8mzBNd2xFLoT/IM7bGfFie5y58oz97KzXliwiLY3zWjqMXjQcuP1a5VgCv2JA== dependencies: "@babel/core" "^7.18.6" "@babel/generator" "^7.18.7" @@ -1214,13 +1237,13 @@ "@babel/runtime" "^7.18.6" "@babel/runtime-corejs3" "^7.18.6" "@babel/traverse" "^7.18.8" - "@docusaurus/cssnano-preset" "2.2.0" - "@docusaurus/logger" "2.2.0" - "@docusaurus/mdx-loader" "2.2.0" + "@docusaurus/cssnano-preset" "2.3.1" + "@docusaurus/logger" "2.3.1" + "@docusaurus/mdx-loader" "2.3.1" "@docusaurus/react-loadable" "5.5.2" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-common" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-common" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" "@slorber/static-site-generator-webpack-plugin" "^4.0.7" "@svgr/webpack" "^6.2.1" autoprefixer "^10.4.7" @@ -1241,7 +1264,7 @@ del "^6.1.1" detect-port "^1.3.0" escape-html "^1.0.3" - eta "^1.12.3" + eta "^2.0.0" file-loader "^6.2.0" fs-extra "^10.1.0" html-minifier-terser "^6.1.0" @@ -1276,44 +1299,44 @@ webpack-merge "^5.8.0" webpackbar "^5.0.2" -"@docusaurus/cssnano-preset@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/cssnano-preset/-/cssnano-preset-2.2.0.tgz#fc05044659051ae74ab4482afcf4a9936e81d523" - integrity sha512-mAAwCo4n66TMWBH1kXnHVZsakW9VAXJzTO4yZukuL3ro4F+JtkMwKfh42EG75K/J/YIFQG5I/Bzy0UH/hFxaTg== +"@docusaurus/cssnano-preset@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/cssnano-preset/-/cssnano-preset-2.3.1.tgz#e042487655e3e062417855e12edb3f6eee8f5ecb" + integrity sha512-7mIhAROES6CY1GmCjR4CZkUfjTL6B3u6rKHK0ChQl2d1IevYXq/k/vFgvOrJfcKxiObpMnE9+X6R2Wt1KqxC6w== dependencies: cssnano-preset-advanced "^5.3.8" postcss "^8.4.14" postcss-sort-media-queries "^4.2.1" tslib "^2.4.0" -"@docusaurus/logger@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/logger/-/logger-2.2.0.tgz#ea2f7feda7b8675485933b87f06d9c976d17423f" - integrity sha512-DF3j1cA5y2nNsu/vk8AG7xwpZu6f5MKkPPMaaIbgXLnWGfm6+wkOeW7kNrxnM95YOhKUkJUophX69nGUnLsm0A== +"@docusaurus/logger@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/logger/-/logger-2.3.1.tgz#d76aefb452e3734b4e0e645efc6cbfc0aae52869" + integrity sha512-2lAV/olKKVr9qJhfHFCaqBIl8FgYjbUFwgUnX76+cULwQYss+42ZQ3grHGFvI0ocN2X55WcYe64ellQXz7suqg== dependencies: chalk "^4.1.2" tslib "^2.4.0" -"@docusaurus/lqip-loader@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/lqip-loader/-/lqip-loader-2.2.0.tgz#46ccf0da970cd7817c885e09ff14d8bccd64d434" - integrity sha512-nER3YokwkkNA1c2bAQzyqH8nfdbzkNtgwbuWvwnNuxW6kyhMopLcIy9qQYpSzcA0S7xcfj7+ysdB/DX7+nWoMw== +"@docusaurus/lqip-loader@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/lqip-loader/-/lqip-loader-2.3.1.tgz#eba7832067a6cb96aa12fff198cfe804bdb60139" + integrity sha512-pdZUh6FjvoVszGTaMHX4nhLfORdQ7ZnOv9wcfncsiR/iUzpHin+Dq3yOXPgB9C/yPvsaITzpCrJdGYfET29/dQ== dependencies: - "@docusaurus/logger" "2.2.0" + "@docusaurus/logger" "2.3.1" file-loader "^6.2.0" lodash "^4.17.21" sharp "^0.30.7" tslib "^2.4.0" -"@docusaurus/mdx-loader@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/mdx-loader/-/mdx-loader-2.2.0.tgz#fd558f429e5d9403d284bd4214e54d9768b041a0" - integrity sha512-X2bzo3T0jW0VhUU+XdQofcEeozXOTmKQMvc8tUnWRdTnCvj4XEcBVdC3g+/jftceluiwSTNRAX4VBOJdNt18jA== +"@docusaurus/mdx-loader@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/mdx-loader/-/mdx-loader-2.3.1.tgz#7ec6acee5eff0a280e1b399ea4dd690b15a793f7" + integrity sha512-Gzga7OsxQRpt3392K9lv/bW4jGppdLFJh3luKRknCKSAaZrmVkOQv2gvCn8LAOSZ3uRg5No7AgYs/vpL8K94lA== dependencies: "@babel/parser" "^7.18.8" "@babel/traverse" "^7.18.8" - "@docusaurus/logger" "2.2.0" - "@docusaurus/utils" "2.2.0" + "@docusaurus/logger" "2.3.1" + "@docusaurus/utils" "2.3.1" "@mdx-js/mdx" "^1.6.22" escape-html "^1.0.3" file-loader "^6.2.0" @@ -1328,13 +1351,13 @@ url-loader "^4.1.1" webpack "^5.73.0" -"@docusaurus/module-type-aliases@2.2.0", "@docusaurus/module-type-aliases@^2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/module-type-aliases/-/module-type-aliases-2.2.0.tgz#1e23e54a1bbb6fde1961e4fa395b1b69f4803ba5" - integrity sha512-wDGW4IHKoOr9YuJgy7uYuKWrDrSpsUSDHLZnWQYM9fN7D5EpSmYHjFruUpKWVyxLpD/Wh0rW8hYZwdjJIQUQCQ== +"@docusaurus/module-type-aliases@2.3.1", "@docusaurus/module-type-aliases@^2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/module-type-aliases/-/module-type-aliases-2.3.1.tgz#986186200818fed999be2e18d6c698eaf4683a33" + integrity sha512-6KkxfAVOJqIUynTRb/tphYCl+co3cP0PlHiMDbi+SzmYxMdgIrwYqH9yAnGSDoN6Jk2ZE/JY/Azs/8LPgKP48A== dependencies: "@docusaurus/react-loadable" "5.5.2" - "@docusaurus/types" "2.2.0" + "@docusaurus/types" "2.3.1" "@types/history" "^4.7.11" "@types/react" "*" "@types/react-router-config" "*" @@ -1342,18 +1365,18 @@ react-helmet-async "*" react-loadable "npm:@docusaurus/react-loadable@5.5.2" -"@docusaurus/plugin-content-blog@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-blog/-/plugin-content-blog-2.2.0.tgz#dc55982e76771f4e678ac10e26d10e1da2011dc1" - integrity sha512-0mWBinEh0a5J2+8ZJXJXbrCk1tSTNf7Nm4tYAl5h2/xx+PvH/Bnu0V+7mMljYm/1QlDYALNIIaT/JcoZQFUN3w== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/logger" "2.2.0" - "@docusaurus/mdx-loader" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-common" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" +"@docusaurus/plugin-content-blog@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-blog/-/plugin-content-blog-2.3.1.tgz#236b8ee4f20f7047aa9c285ae77ae36683ad48a3" + integrity sha512-f5LjqX+9WkiLyGiQ41x/KGSJ/9bOjSD8lsVhPvYeUYHCtYpuiDKfhZE07O4EqpHkBx4NQdtQDbp+aptgHSTuiw== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/logger" "2.3.1" + "@docusaurus/mdx-loader" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-common" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" cheerio "^1.0.0-rc.12" feed "^4.2.2" fs-extra "^10.1.0" @@ -1364,18 +1387,18 @@ utility-types "^3.10.0" webpack "^5.73.0" -"@docusaurus/plugin-content-docs@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-docs/-/plugin-content-docs-2.2.0.tgz#0fcb85226fcdb80dc1e2d4a36ef442a650dcc84d" - integrity sha512-BOazBR0XjzsHE+2K1wpNxz5QZmrJgmm3+0Re0EVPYFGW8qndCWGNtXW/0lGKhecVPML8yyFeAmnUCIs7xM2wPw== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/logger" "2.2.0" - "@docusaurus/mdx-loader" "2.2.0" - "@docusaurus/module-type-aliases" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" +"@docusaurus/plugin-content-docs@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-docs/-/plugin-content-docs-2.3.1.tgz#feae1555479558a55182f22f8a07acc5e0d7444d" + integrity sha512-DxztTOBEruv7qFxqUtbsqXeNcHqcVEIEe+NQoI1oi2DBmKBhW/o0MIal8lt+9gvmpx3oYtlwmLOOGepxZgJGkw== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/logger" "2.3.1" + "@docusaurus/mdx-loader" "2.3.1" + "@docusaurus/module-type-aliases" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" "@types/react-router-config" "^5.0.6" combine-promises "^1.1.0" fs-extra "^10.1.0" @@ -1386,101 +1409,112 @@ utility-types "^3.10.0" webpack "^5.73.0" -"@docusaurus/plugin-content-pages@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-pages/-/plugin-content-pages-2.2.0.tgz#e3f40408787bbe229545dd50595f87e1393bc3ae" - integrity sha512-+OTK3FQHk5WMvdelz8v19PbEbx+CNT6VSpx7nVOvMNs5yJCKvmqBJBQ2ZSxROxhVDYn+CZOlmyrC56NSXzHf6g== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/mdx-loader" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" +"@docusaurus/plugin-content-pages@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-content-pages/-/plugin-content-pages-2.3.1.tgz#f534a37862be5b3f2ba5b150458d7527646b6f39" + integrity sha512-E80UL6hvKm5VVw8Ka8YaVDtO6kWWDVUK4fffGvkpQ/AJQDOg99LwOXKujPoICC22nUFTsZ2Hp70XvpezCsFQaA== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/mdx-loader" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" fs-extra "^10.1.0" tslib "^2.4.0" webpack "^5.73.0" -"@docusaurus/plugin-debug@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-debug/-/plugin-debug-2.2.0.tgz#b38741d2c492f405fee01ee0ef2e0029cedb689a" - integrity sha512-p9vOep8+7OVl6r/NREEYxf4HMAjV8JMYJ7Bos5fCFO0Wyi9AZEo0sCTliRd7R8+dlJXZEgcngSdxAUo/Q+CJow== +"@docusaurus/plugin-debug@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-debug/-/plugin-debug-2.3.1.tgz#26fef904713e148f6dee44957506280f8b7853bb" + integrity sha512-Ujpml1Ppg4geB/2hyu2diWnO49az9U2bxM9Shen7b6qVcyFisNJTkVG2ocvLC7wM1efTJcUhBO6zAku2vKJGMw== dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" + "@docusaurus/core" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" fs-extra "^10.1.0" react-json-view "^1.21.3" tslib "^2.4.0" -"@docusaurus/plugin-google-analytics@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-2.2.0.tgz#63c7137eff5a1208d2059fea04b5207c037d7954" - integrity sha512-+eZVVxVeEnV5nVQJdey9ZsfyEVMls6VyWTIj8SmX0k5EbqGvnIfET+J2pYEuKQnDIHxy+syRMoRM6AHXdHYGIg== +"@docusaurus/plugin-google-analytics@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-analytics/-/plugin-google-analytics-2.3.1.tgz#e2e7db4cf6a7063e8ba5e128d4e413f4d6a0c862" + integrity sha512-OHip0GQxKOFU8n7gkt3TM4HOYTXPCFDjqKbMClDD3KaDnyTuMp/Zvd9HSr770lLEscgPWIvzhJByRAClqsUWiQ== dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" + "@docusaurus/core" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" tslib "^2.4.0" -"@docusaurus/plugin-google-gtag@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-2.2.0.tgz#7b086d169ac5fe9a88aca10ab0fd2bf00c6c6b12" - integrity sha512-6SOgczP/dYdkqUMGTRqgxAS1eTp6MnJDAQMy8VCF1QKbWZmlkx4agHDexihqmYyCujTYHqDAhm1hV26EET54NQ== +"@docusaurus/plugin-google-gtag@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-gtag/-/plugin-google-gtag-2.3.1.tgz#b8da54a60c0a50aca609c3643faef78cb4f247a0" + integrity sha512-uXtDhfu4+Hm+oqWUySr3DNI5cWC/rmP6XJyAk83Heor3dFjZqDwCbkX8yWPywkRiWev3Dk/rVF8lEn0vIGVocA== dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" + "@docusaurus/core" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" tslib "^2.4.0" -"@docusaurus/plugin-ideal-image@^2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-ideal-image/-/plugin-ideal-image-2.2.0.tgz#bd2fc4d8f8c4a4526b288297d892cb76e61e1382" - integrity sha512-1tnyPotxLEglt497nmccxWOpAA6ulMf4nc2k8tReEljmwHebefWV9wbK1RK/44Na8GiGb709/Zs+HHdNRied8w== +"@docusaurus/plugin-google-tag-manager@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-google-tag-manager/-/plugin-google-tag-manager-2.3.1.tgz#f19bc01cc784fa4734187c5bc637f0574857e15d" + integrity sha512-Ww2BPEYSqg8q8tJdLYPFFM3FMDBCVhEM4UUqKzJaiRMx3NEoly3qqDRAoRDGdIhlC//Rf0iJV9cWAoq2m6k3sw== dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/lqip-loader" "2.2.0" + "@docusaurus/core" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" + tslib "^2.4.0" + +"@docusaurus/plugin-ideal-image@^2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-ideal-image/-/plugin-ideal-image-2.3.1.tgz#002ad1958f7fa2ffa0bd185e9947359a8e1af9cd" + integrity sha512-hN/TbpG8Hsct06RNRZz69iCpxsXzryq+5o/8r62sGwhTAmMCN8ms8an+ubRk4bub0y3Gvg7YUcwmmFf6kE2fJg== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/lqip-loader" "2.3.1" "@docusaurus/responsive-loader" "^1.7.0" - "@docusaurus/theme-translations" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" + "@docusaurus/theme-translations" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" "@endiliey/react-ideal-image" "^0.0.11" react-waypoint "^10.3.0" sharp "^0.30.7" tslib "^2.4.0" webpack "^5.73.0" -"@docusaurus/plugin-sitemap@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/plugin-sitemap/-/plugin-sitemap-2.2.0.tgz#876da60937886032d63143253d420db6a4b34773" - integrity sha512-0jAmyRDN/aI265CbWZNZuQpFqiZuo+5otk2MylU9iVrz/4J7gSc+ZJ9cy4EHrEsW7PV8s1w18hIEsmcA1YgkKg== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/logger" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-common" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" +"@docusaurus/plugin-sitemap@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/plugin-sitemap/-/plugin-sitemap-2.3.1.tgz#f526ab517ca63b7a3460d585876f5952cb908aa0" + integrity sha512-8Yxile/v6QGYV9vgFiYL+8d2N4z4Er3pSHsrD08c5XI8bUXxTppMwjarDUTH/TRTfgAWotRbhJ6WZLyajLpozA== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/logger" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-common" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" fs-extra "^10.1.0" sitemap "^7.1.1" tslib "^2.4.0" -"@docusaurus/preset-classic@^2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/preset-classic/-/preset-classic-2.2.0.tgz#bece5a043eeb74430f7c6c7510000b9c43669eb7" - integrity sha512-yKIWPGNx7BT8v2wjFIWvYrS+nvN04W+UameSFf8lEiJk6pss0kL6SG2MRvyULiI3BDxH+tj6qe02ncpSPGwumg== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/plugin-content-blog" "2.2.0" - "@docusaurus/plugin-content-docs" "2.2.0" - "@docusaurus/plugin-content-pages" "2.2.0" - "@docusaurus/plugin-debug" "2.2.0" - "@docusaurus/plugin-google-analytics" "2.2.0" - "@docusaurus/plugin-google-gtag" "2.2.0" - "@docusaurus/plugin-sitemap" "2.2.0" - "@docusaurus/theme-classic" "2.2.0" - "@docusaurus/theme-common" "2.2.0" - "@docusaurus/theme-search-algolia" "2.2.0" - "@docusaurus/types" "2.2.0" +"@docusaurus/preset-classic@^2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/preset-classic/-/preset-classic-2.3.1.tgz#f0193f06093eb55cafef66bd1ad9e0d33198bf95" + integrity sha512-OQ5W0AHyfdUk0IldwJ3BlnZ1EqoJuu2L2BMhqLbqwNWdkmzmSUvlFLH1Pe7CZSQgB2YUUC/DnmjbPKk/qQD0lQ== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/plugin-content-blog" "2.3.1" + "@docusaurus/plugin-content-docs" "2.3.1" + "@docusaurus/plugin-content-pages" "2.3.1" + "@docusaurus/plugin-debug" "2.3.1" + "@docusaurus/plugin-google-analytics" "2.3.1" + "@docusaurus/plugin-google-gtag" "2.3.1" + "@docusaurus/plugin-google-tag-manager" "2.3.1" + "@docusaurus/plugin-sitemap" "2.3.1" + "@docusaurus/theme-classic" "2.3.1" + "@docusaurus/theme-common" "2.3.1" + "@docusaurus/theme-search-algolia" "2.3.1" + "@docusaurus/types" "2.3.1" "@docusaurus/react-loadable@5.5.2", "react-loadable@npm:@docusaurus/react-loadable@5.5.2": version "5.5.2" @@ -1497,23 +1531,23 @@ dependencies: loader-utils "^2.0.0" -"@docusaurus/theme-classic@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-classic/-/theme-classic-2.2.0.tgz#a048bb1bc077dee74b28bec25f4b84b481863742" - integrity sha512-kjbg/qJPwZ6H1CU/i9d4l/LcFgnuzeiGgMQlt6yPqKo0SOJIBMPuz7Rnu3r/WWbZFPi//o8acclacOzmXdUUEg== - dependencies: - "@docusaurus/core" "2.2.0" - "@docusaurus/mdx-loader" "2.2.0" - "@docusaurus/module-type-aliases" "2.2.0" - "@docusaurus/plugin-content-blog" "2.2.0" - "@docusaurus/plugin-content-docs" "2.2.0" - "@docusaurus/plugin-content-pages" "2.2.0" - "@docusaurus/theme-common" "2.2.0" - "@docusaurus/theme-translations" "2.2.0" - "@docusaurus/types" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-common" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" +"@docusaurus/theme-classic@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-classic/-/theme-classic-2.3.1.tgz#8e6e194236e702c0d4e8d7b7cbb6886ae456e598" + integrity sha512-SelSIDvyttb7ZYHj8vEUhqykhAqfOPKk+uP0z85jH72IMC58e7O8DIlcAeBv+CWsLbNIl9/Hcg71X0jazuxJug== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/mdx-loader" "2.3.1" + "@docusaurus/module-type-aliases" "2.3.1" + "@docusaurus/plugin-content-blog" "2.3.1" + "@docusaurus/plugin-content-docs" "2.3.1" + "@docusaurus/plugin-content-pages" "2.3.1" + "@docusaurus/theme-common" "2.3.1" + "@docusaurus/theme-translations" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-common" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" "@mdx-js/react" "^1.6.22" clsx "^1.2.1" copy-text-to-clipboard "^3.0.1" @@ -1528,17 +1562,17 @@ tslib "^2.4.0" utility-types "^3.10.0" -"@docusaurus/theme-common@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-common/-/theme-common-2.2.0.tgz#2303498d80448aafdd588b597ce9d6f4cfa930e4" - integrity sha512-R8BnDjYoN90DCL75gP7qYQfSjyitXuP9TdzgsKDmSFPNyrdE3twtPNa2dIN+h+p/pr+PagfxwWbd6dn722A1Dw== - dependencies: - "@docusaurus/mdx-loader" "2.2.0" - "@docusaurus/module-type-aliases" "2.2.0" - "@docusaurus/plugin-content-blog" "2.2.0" - "@docusaurus/plugin-content-docs" "2.2.0" - "@docusaurus/plugin-content-pages" "2.2.0" - "@docusaurus/utils" "2.2.0" +"@docusaurus/theme-common@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-common/-/theme-common-2.3.1.tgz#82f52d80226efef8c4418c4eacfc5051aa215f7f" + integrity sha512-RYmYl2OR2biO+yhmW1aS5FyEvnrItPINa+0U2dMxcHpah8reSCjQ9eJGRmAgkZFchV1+aIQzXOI1K7LCW38O0g== + dependencies: + "@docusaurus/mdx-loader" "2.3.1" + "@docusaurus/module-type-aliases" "2.3.1" + "@docusaurus/plugin-content-blog" "2.3.1" + "@docusaurus/plugin-content-docs" "2.3.1" + "@docusaurus/plugin-content-pages" "2.3.1" + "@docusaurus/utils" "2.3.1" "@types/history" "^4.7.11" "@types/react" "*" "@types/react-router-config" "*" @@ -1546,42 +1580,57 @@ parse-numeric-range "^1.3.0" prism-react-renderer "^1.3.5" tslib "^2.4.0" + use-sync-external-store "^1.2.0" utility-types "^3.10.0" -"@docusaurus/theme-search-algolia@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-search-algolia/-/theme-search-algolia-2.2.0.tgz#77fd9f7a600917e6024fe3ac7fb6cfdf2ce84737" - integrity sha512-2h38B0tqlxgR2FZ9LpAkGrpDWVdXZ7vltfmTdX+4RsDs3A7khiNsmZB+x/x6sA4+G2V2CvrsPMlsYBy5X+cY1w== +"@docusaurus/theme-mermaid@^2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-mermaid/-/theme-mermaid-2.3.1.tgz#cdaff255ac414bd7130139ac471e952049f56f92" + integrity sha512-Hh1I4FSt+5qlrq6dBOgj/klv2Ijmzbn0ysa5XMDHeD6Fa3fK63vvf0KJMR6VzB9VHU8QjMqqAR+n9500/Kq4lw== + dependencies: + "@docusaurus/core" "2.3.1" + "@docusaurus/module-type-aliases" "2.3.1" + "@docusaurus/theme-common" "2.3.1" + "@docusaurus/types" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" + "@mdx-js/react" "^1.6.22" + mermaid "^9.2.2" + tslib "^2.4.0" + +"@docusaurus/theme-search-algolia@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-search-algolia/-/theme-search-algolia-2.3.1.tgz#d587b40913119e9287d14670e277b933d8f453f0" + integrity sha512-JdHaRqRuH1X++g5fEMLnq7OtULSGQdrs9AbhcWRQ428ZB8/HOiaN6mj3hzHvcD3DFgu7koIVtWPQnvnN7iwzHA== dependencies: "@docsearch/react" "^3.1.1" - "@docusaurus/core" "2.2.0" - "@docusaurus/logger" "2.2.0" - "@docusaurus/plugin-content-docs" "2.2.0" - "@docusaurus/theme-common" "2.2.0" - "@docusaurus/theme-translations" "2.2.0" - "@docusaurus/utils" "2.2.0" - "@docusaurus/utils-validation" "2.2.0" + "@docusaurus/core" "2.3.1" + "@docusaurus/logger" "2.3.1" + "@docusaurus/plugin-content-docs" "2.3.1" + "@docusaurus/theme-common" "2.3.1" + "@docusaurus/theme-translations" "2.3.1" + "@docusaurus/utils" "2.3.1" + "@docusaurus/utils-validation" "2.3.1" algoliasearch "^4.13.1" algoliasearch-helper "^3.10.0" clsx "^1.2.1" - eta "^1.12.3" + eta "^2.0.0" fs-extra "^10.1.0" lodash "^4.17.21" tslib "^2.4.0" utility-types "^3.10.0" -"@docusaurus/theme-translations@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/theme-translations/-/theme-translations-2.2.0.tgz#5fbd4693679806f80c26eeae1381e1f2c23d83e7" - integrity sha512-3T140AG11OjJrtKlY4pMZ5BzbGRDjNs2co5hJ6uYJG1bVWlhcaFGqkaZ5lCgKflaNHD7UHBHU9Ec5f69jTdd6w== +"@docusaurus/theme-translations@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/theme-translations/-/theme-translations-2.3.1.tgz#b2b1ecc00a737881b5bfabc19f90b20f0fe02bb3" + integrity sha512-BsBZzAewJabVhoGG1Ij2u4pMS3MPW6gZ6sS4pc+Y7czevRpzxoFNJXRtQDVGe7mOpv/MmRmqg4owDK+lcOTCVQ== dependencies: fs-extra "^10.1.0" tslib "^2.4.0" -"@docusaurus/types@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/types/-/types-2.2.0.tgz#02c577a4041ab7d058a3c214ccb13647e21a9857" - integrity sha512-b6xxyoexfbRNRI8gjblzVOnLr4peCJhGbYGPpJ3LFqpi5nsFfoK4mmDLvWdeah0B7gmJeXabN7nQkFoqeSdmOw== +"@docusaurus/types@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/types/-/types-2.3.1.tgz#785ade2e0f4e35e1eb7fb0d04c27d11c3991a2e8" + integrity sha512-PREbIRhTaNNY042qmfSE372Jb7djZt+oVTZkoqHJ8eff8vOIc2zqqDqBVc5BhOfpZGPTrE078yy/torUEZy08A== dependencies: "@types/history" "^4.7.11" "@types/react" "*" @@ -1592,31 +1641,32 @@ webpack "^5.73.0" webpack-merge "^5.8.0" -"@docusaurus/utils-common@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/utils-common/-/utils-common-2.2.0.tgz#a401c1b93a8697dd566baf6ac64f0fdff1641a78" - integrity sha512-qebnerHp+cyovdUseDQyYFvMW1n1nv61zGe5JJfoNQUnjKuApch3IVsz+/lZ9a38pId8kqehC1Ao2bW/s0ntDA== +"@docusaurus/utils-common@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/utils-common/-/utils-common-2.3.1.tgz#1abe66846eb641547e4964d44f3011938e58e50b" + integrity sha512-pVlRpXkdNcxmKNxAaB1ya2hfCEvVsLDp2joeM6K6uv55Oc5nVIqgyYSgSNKZyMdw66NnvMfsu0RBylcwZQKo9A== dependencies: tslib "^2.4.0" -"@docusaurus/utils-validation@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/utils-validation/-/utils-validation-2.2.0.tgz#04d4d103137ad0145883971d3aa497f4a1315f25" - integrity sha512-I1hcsG3yoCkasOL5qQAYAfnmVoLei7apugT6m4crQjmDGxq+UkiRrq55UqmDDyZlac/6ax/JC0p+usZ6W4nVyg== +"@docusaurus/utils-validation@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/utils-validation/-/utils-validation-2.3.1.tgz#b65c718ba9b84b7a891bccf5ac6d19b57ee7d887" + integrity sha512-7n0208IG3k1HVTByMHlZoIDjjOFC8sbViHVXJx0r3Q+3Ezrx+VQ1RZ/zjNn6lT+QBCRCXlnlaoJ8ug4HIVgQ3w== dependencies: - "@docusaurus/logger" "2.2.0" - "@docusaurus/utils" "2.2.0" + "@docusaurus/logger" "2.3.1" + "@docusaurus/utils" "2.3.1" joi "^17.6.0" js-yaml "^4.1.0" tslib "^2.4.0" -"@docusaurus/utils@2.2.0": - version "2.2.0" - resolved "https://registry.yarnpkg.com/@docusaurus/utils/-/utils-2.2.0.tgz#3d6f9b7a69168d5c92d371bf21c556a4f50d1da6" - integrity sha512-oNk3cjvx7Tt1Lgh/aeZAmFpGV2pDr5nHKrBVx6hTkzGhrnMuQqLt6UPlQjdYQ3QHXwyF/ZtZMO1D5Pfi0lu7SA== +"@docusaurus/utils@2.3.1": + version "2.3.1" + resolved "https://registry.yarnpkg.com/@docusaurus/utils/-/utils-2.3.1.tgz#24b9cae3a23b1e6dc88f95c45722c7e82727b032" + integrity sha512-9WcQROCV0MmrpOQDXDGhtGMd52DHpSFbKLfkyaYumzbTstrbA5pPOtiGtxK1nqUHkiIv8UwexS54p0Vod2I1lg== dependencies: - "@docusaurus/logger" "2.2.0" + "@docusaurus/logger" "2.3.1" "@svgr/webpack" "^6.2.1" + escape-string-regexp "^4.0.0" file-loader "^6.2.0" fs-extra "^10.1.0" github-slugger "^1.4.0" @@ -1648,19 +1698,19 @@ dependencies: "@hapi/hoek" "^9.0.0" -"@jest/schemas@^29.0.0": - version "29.0.0" - resolved "https://registry.yarnpkg.com/@jest/schemas/-/schemas-29.0.0.tgz#5f47f5994dd4ef067fb7b4188ceac45f77fe952a" - integrity sha512-3Ab5HgYIIAnS0HjqJHQYZS+zXc4tUmTmBH3z83ajI6afXp8X3ZtdLX+nXx+I7LNkJD7uN9LAVhgnjDgZa2z0kA== +"@jest/schemas@^29.4.3": + version "29.4.3" + resolved "https://registry.yarnpkg.com/@jest/schemas/-/schemas-29.4.3.tgz#39cf1b8469afc40b6f5a2baaa146e332c4151788" + integrity sha512-VLYKXQmtmuEz6IxJsrZwzG9NvtkQsWNnWMsKxqWNu3+CnfzJQhp0WDDKWLVV9hLKr0l3SLLFRqcYHjhtyuDVxg== dependencies: - "@sinclair/typebox" "^0.24.1" + "@sinclair/typebox" "^0.25.16" -"@jest/types@^29.3.1": - version "29.3.1" - resolved "https://registry.yarnpkg.com/@jest/types/-/types-29.3.1.tgz#7c5a80777cb13e703aeec6788d044150341147e3" - integrity sha512-d0S0jmmTpjnhCmNpApgX3jrUZgZ22ivKJRvL2lli5hpCRoNnp1f85r2/wpKfXuYu8E7Jjh1hGfhPyup1NM5AmA== +"@jest/types@^29.5.0": + version "29.5.0" + resolved "https://registry.yarnpkg.com/@jest/types/-/types-29.5.0.tgz#f59ef9b031ced83047c67032700d8c807d6e1593" + integrity sha512-qbu7kN6czmVRc3xWFQcAN03RAUamgppVUdXrvl1Wr3jlNF93o9mJbGcDWrwGB6ht44u7efB1qCFgVQmca24Uog== dependencies: - "@jest/schemas" "^29.0.0" + "@jest/schemas" "^29.4.3" "@types/istanbul-lib-coverage" "^2.0.0" "@types/istanbul-reports" "^3.0.0" "@types/node" "*" @@ -1707,7 +1757,7 @@ resolved "https://registry.yarnpkg.com/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.4.14.tgz#add4c98d341472a289190b424efbdb096991bb24" integrity sha512-XPSJHWmi394fuUuzDnGz1wiKqWfo1yXecHQMRf2l6hztTO+nPru658AyDngaBe7isIxEkRsPR3FZh+s7iVa4Uw== -"@jridgewell/trace-mapping@^0.3.14", "@jridgewell/trace-mapping@^0.3.9": +"@jridgewell/trace-mapping@^0.3.14", "@jridgewell/trace-mapping@^0.3.17", "@jridgewell/trace-mapping@^0.3.9": version "0.3.17" resolved "https://registry.yarnpkg.com/@jridgewell/trace-mapping/-/trace-mapping-0.3.17.tgz#793041277af9073b0951a7fe0f0d8c4c98c36985" integrity sha512-MCNzAp77qzKca9+W/+I0+sEpaUnZoeasnghNeVc41VZCEKaCH73Vq3BZZ/SzWIgrqE4H4ceI+p+b6C0mHf9T4g== @@ -1788,7 +1838,7 @@ dependencies: "@hapi/hoek" "^9.0.0" -"@sideway/formula@^3.0.0": +"@sideway/formula@^3.0.1": version "3.0.1" resolved "https://registry.yarnpkg.com/@sideway/formula/-/formula-3.0.1.tgz#80fcbcbaf7ce031e0ef2dd29b1bfc7c3f583611f" integrity sha512-/poHZJJVjx3L+zVD6g9KgHfYnb443oi7wLu/XKojDviHy6HOEOA6z1Trk5aR1dGcmPenJEgb2sK2I80LeS3MIg== @@ -1798,10 +1848,10 @@ resolved "https://registry.yarnpkg.com/@sideway/pinpoint/-/pinpoint-2.0.0.tgz#cff8ffadc372ad29fd3f78277aeb29e632cc70df" integrity sha512-RNiOoTPkptFtSVzQevY/yWtZwf/RxyVnPy/OcA9HBM3MlGDnBEYL5B41H0MTn0Uec8Hi+2qUtTfG2WWZBmMejQ== -"@sinclair/typebox@^0.24.1": - version "0.24.51" - resolved "https://registry.yarnpkg.com/@sinclair/typebox/-/typebox-0.24.51.tgz#645f33fe4e02defe26f2f5c0410e1c094eac7f5f" - integrity sha512-1P1OROm/rdubP5aFDSZQILU0vrLCJ4fvHt6EoqHEM+2D/G5MK3bIaymUKLit8Js9gbns5UyJnkP/TZROLw4tUA== +"@sinclair/typebox@^0.25.16": + version "0.25.24" + resolved "https://registry.yarnpkg.com/@sinclair/typebox/-/typebox-0.25.24.tgz#8c7688559979f7079aacaf31aa881c3aa410b718" + integrity sha512-XJfwUVUKDHF5ugKwIcxEgc9k8b7HbznCp6eUfWgu710hMPNIO4aw4/zB5RogDQz8nd6gyCDpU9O/m6qYEWY6yQ== "@sindresorhus/is@^0.14.0": version "0.14.0" @@ -1979,9 +2029,9 @@ "@types/estree" "*" "@types/eslint@*": - version "8.4.10" - resolved "https://registry.yarnpkg.com/@types/eslint/-/eslint-8.4.10.tgz#19731b9685c19ed1552da7052b6f668ed7eb64bb" - integrity sha512-Sl/HOqN8NKPmhWo2VBEPm0nvHnu2LL3v9vKo8MEq0EtbJ4eVzGPl41VNPvn5E1i5poMk4/XD8UriLHpJvEP/Nw== + version "8.21.1" + resolved "https://registry.yarnpkg.com/@types/eslint/-/eslint-8.21.1.tgz#110b441a210d53ab47795124dbc3e9bb993d1e7c" + integrity sha512-rc9K8ZpVjNcLs8Fp0dkozd5Pt2Apk1glO4Vgz8ix1u6yFByxfqo5Yavpy65o+93TAe24jr7v+eSBtFLvOQtCRQ== dependencies: "@types/estree" "*" "@types/json-schema" "*" @@ -1996,22 +2046,22 @@ resolved "https://registry.yarnpkg.com/@types/estree/-/estree-0.0.51.tgz#cfd70924a25a3fd32b218e5e420e6897e1ac4f40" integrity sha512-CuPgU6f3eT/XgKKPqKd/gLZV1Xmvf1a2R5POBOGQa6uv82xpls89HU5zKeVoyR8XzHd1RGNOlQlvUe3CFkjWNQ== -"@types/express-serve-static-core@*", "@types/express-serve-static-core@^4.17.31": - version "4.17.32" - resolved "https://registry.yarnpkg.com/@types/express-serve-static-core/-/express-serve-static-core-4.17.32.tgz#93dda387f5516af616d8d3f05f2c4c79d81e1b82" - integrity sha512-aI5h/VOkxOF2Z1saPy0Zsxs5avets/iaiAJYznQFm5By/pamU31xWKL//epiF4OfUA2qTOc9PV6tCUjhO8wlZA== +"@types/express-serve-static-core@*", "@types/express-serve-static-core@^4.17.33": + version "4.17.33" + resolved "https://registry.yarnpkg.com/@types/express-serve-static-core/-/express-serve-static-core-4.17.33.tgz#de35d30a9d637dc1450ad18dd583d75d5733d543" + integrity sha512-TPBqmR/HRYI3eC2E5hmiivIzv+bidAfXofM+sbonAGvyDhySGw9/PQZFt2BLOrjUUR++4eJVpx6KnLQK1Fk9tA== dependencies: "@types/node" "*" "@types/qs" "*" "@types/range-parser" "*" "@types/express@*", "@types/express@^4.17.13": - version "4.17.15" - resolved "https://registry.yarnpkg.com/@types/express/-/express-4.17.15.tgz#9290e983ec8b054b65a5abccb610411953d417ff" - integrity sha512-Yv0k4bXGOH+8a+7bELd2PqHQsuiANB+A8a4gnQrkRWzrkKlb6KHaVvyXhqs04sVW/OWlbPyYxRgYlIXLfrufMQ== + version "4.17.17" + resolved "https://registry.yarnpkg.com/@types/express/-/express-4.17.17.tgz#01d5437f6ef9cfa8668e616e13c2f2ac9a491ae4" + integrity sha512-Q4FmmuLGBG58btUnfS1c1r/NQdlp3DMfGDGig8WhfpA2YRUtEkxAjkZb0yvplJGYdF1fsQ81iMDcH24sSCNC/Q== dependencies: "@types/body-parser" "*" - "@types/express-serve-static-core" "^4.17.31" + "@types/express-serve-static-core" "^4.17.33" "@types/qs" "*" "@types/serve-static" "*" @@ -2033,9 +2083,9 @@ integrity sha512-oh/6byDPnL1zeNXFrDXFLyZjkr1MsBG667IM792caf1L2UPOOMf65NFzjUH/ltyfwjAGfs1rsX1eftK0jC/KIg== "@types/http-proxy@^1.17.8": - version "1.17.9" - resolved "https://registry.yarnpkg.com/@types/http-proxy/-/http-proxy-1.17.9.tgz#7f0e7931343761efde1e2bf48c40f02f3f75705a" - integrity sha512-QsbSjA/fSk7xB+UXlCT3wHBy5ai9wOcNDWwZAtud+jXhwOM3l+EYZh8Lng4+/6n8uar0J7xILzqftJdJ/Wdfkw== + version "1.17.10" + resolved "https://registry.yarnpkg.com/@types/http-proxy/-/http-proxy-1.17.10.tgz#e576c8e4a0cc5c6a138819025a88e167ebb38d6c" + integrity sha512-Qs5aULi+zV1bwKAg5z1PWnDXWmsn+LxIvUGv6E2+OOMYhclZMO+OXd9pYVf2gLykf2I7IV2u7oTHwChPNsvJ7g== dependencies: "@types/node" "*" @@ -2081,9 +2131,9 @@ integrity sha512-Y4XFY5VJAuw0FgAqPNd6NNoV44jbq9Bz2L7Rh/J6jLTiHBSBJa9fxqQIvkIld4GsoDOcCbvzOUAbLPsSKKg+uA== "@types/node@*": - version "18.11.18" - resolved "https://registry.yarnpkg.com/@types/node/-/node-18.11.18.tgz#8dfb97f0da23c2293e554c5a50d61ef134d7697f" - integrity sha512-DHQpWGjyQKSHj3ebjFI/wRKcqQcdR+MoFBygntYOZytCqNfkd2ZC4ARDJ2DQqhjH5p85Nnd3jhUJIXrszFX/JA== + version "18.14.6" + resolved "https://registry.yarnpkg.com/@types/node/-/node-18.14.6.tgz#ae1973dd2b1eeb1825695bb11ebfb746d27e3e93" + integrity sha512-93+VvleD3mXwlLI/xASjw0FzKcwzl3OdTCzm1LaRfqgS21gfFtK3zDXM5Op9TeeMsJVOaJ2VRDpT9q4Y3d0AvA== "@types/node@^17.0.5": version "17.0.45" @@ -2142,9 +2192,9 @@ "@types/react" "*" "@types/react@*": - version "18.0.27" - resolved "https://registry.yarnpkg.com/@types/react/-/react-18.0.27.tgz#d9425abe187a00f8a5ec182b010d4fd9da703b71" - integrity sha512-3vtRKHgVxu3Jp9t718R9BuzoD4NcQ8YJ5XRzsSKxNDiDonD2MXIT1TmSkenxuCycZJoQT5d2vE8LwWJxBC1gmA== + version "18.0.28" + resolved "https://registry.yarnpkg.com/@types/react/-/react-18.0.28.tgz#accaeb8b86f4908057ad629a26635fe641480065" + integrity sha512-RD0ivG1kEztNBdoAK7lekI9M+azSnitIn85h4iOiaLjaTrMjzslhaqCGaI4IyCJ1RljWiLCEu4jyrLLgqxBTew== dependencies: "@types/prop-types" "*" "@types/scheduler" "*" @@ -2175,9 +2225,9 @@ "@types/express" "*" "@types/serve-static@*", "@types/serve-static@^1.13.10": - version "1.15.0" - resolved "https://registry.yarnpkg.com/@types/serve-static/-/serve-static-1.15.0.tgz#c7930ff61afb334e121a9da780aac0d9b8f34155" - integrity sha512-z5xyF6uh8CbjAu9760KDKsH2FcDxZ2tFCsA4HIMWE6IkiYMXfVoa+4f9KX+FN0ZLsaMw1WNG2ETLA6N+/YA+cg== + version "1.15.1" + resolved "https://registry.yarnpkg.com/@types/serve-static/-/serve-static-1.15.1.tgz#86b1753f0be4f9a1bee68d459fcda5be4ea52b5d" + integrity sha512-NUo5XNiAdULrJENtJXZZ3fHtfMolzZwczzBbnAeBbqBwG+LaG6YaJtuwzwGSQZ2wsCrxjEhNNjAkKigy3n8teQ== dependencies: "@types/mime" "*" "@types/node" "*" @@ -2207,9 +2257,9 @@ integrity sha512-iO9ZQHkZxHn4mSakYV0vFHAVDyEOIJQrV2uZ06HxEPcx+mt8swXoZHIbaaJ2crJYFfErySgktuTZ3BeLz+XmFA== "@types/yargs@^17.0.8": - version "17.0.20" - resolved "https://registry.yarnpkg.com/@types/yargs/-/yargs-17.0.20.tgz#107f0fcc13bd4a524e352b41c49fe88aab5c54d5" - integrity sha512-eknWrTHofQuPk2iuqDm1waA7V6xPlbgBoaaXEgYkClhLOnB0TtbW+srJaOToAgawPxPlHQzwypFA2bhZaUGP5A== + version "17.0.22" + resolved "https://registry.yarnpkg.com/@types/yargs/-/yargs-17.0.22.tgz#7dd37697691b5f17d020f3c63e7a45971ff71e9a" + integrity sha512-pet5WJ9U8yPVRhkwuEIp5ktAeAqRZOq4UdAyWLWzxbtpyXnzbtLdKiXAjJzi/KLmPGS9wk86lUFWZFN6sISo4g== dependencies: "@types/yargs-parser" "*" @@ -2363,9 +2413,9 @@ acorn-walk@^8.0.0: integrity sha512-k+iyHEuPgSw6SbuDpGQM+06HQUa04DZ3o+F6CSzXMvvI5KMvnaEqXe+YVe555R9nn6GPt404fos4wcgpw12SDA== acorn@^8.0.4, acorn@^8.5.0, acorn@^8.7.1: - version "8.8.1" - resolved "https://registry.yarnpkg.com/acorn/-/acorn-8.8.1.tgz#0a3f9cbecc4ec3bea6f0a80b66ae8dd2da250b73" - integrity sha512-7zFpHzhnqYKrkYdUjF1HI1bzd0VygEGX8lFk4k5zVMqHEoES+P+7TKI+EvLO9WVMJ8eekdO0aDEK044xTXwPPA== + version "8.8.2" + resolved "https://registry.yarnpkg.com/acorn/-/acorn-8.8.2.tgz#1b2f25db02af965399b9776b0c2c391276d37c4a" + integrity sha512-xjIYgE8HBrkpd/sJqOGNspf8uHG+NOHGOw6a/Urj8taM2EXfdNAH2oFcPeIFfsv3+kz/mJrS5VuMqbNLjCa2vw== address@^1.0.1, address@^1.1.2: version "1.2.2" @@ -2732,15 +2782,15 @@ braces@^3.0.2, braces@~3.0.2: dependencies: fill-range "^7.0.1" -browserslist@^4.0.0, browserslist@^4.14.5, browserslist@^4.16.6, browserslist@^4.18.1, browserslist@^4.21.3, browserslist@^4.21.4: - version "4.21.4" - resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.21.4.tgz#e7496bbc67b9e39dd0f98565feccdcb0d4ff6987" - integrity sha512-CBHJJdDmgjl3daYjN5Cp5kbTf1mUhZoS+beLklHIvkOWscs83YAhLlF3Wsh/lciQYAcbBJgTOD44VtG31ZM4Hw== +browserslist@^4.0.0, browserslist@^4.14.5, browserslist@^4.18.1, browserslist@^4.21.3, browserslist@^4.21.4, browserslist@^4.21.5: + version "4.21.5" + resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.21.5.tgz#75c5dae60063ee641f977e00edd3cfb2fb7af6a7" + integrity sha512-tUkiguQGW7S3IhB7N+c2MV/HZPSCPAAiYBZXLsBhFB/PCy6ZKKsZrmBayHV9fdGV/ARIfJ14NkxKzRDjvp7L6w== dependencies: - caniuse-lite "^1.0.30001400" - electron-to-chromium "^1.4.251" - node-releases "^2.0.6" - update-browserslist-db "^1.0.9" + caniuse-lite "^1.0.30001449" + electron-to-chromium "^1.4.284" + node-releases "^2.0.8" + update-browserslist-db "^1.0.10" buffer-from@^1.0.0: version "1.1.2" @@ -2819,10 +2869,10 @@ caniuse-api@^3.0.0: lodash.memoize "^4.1.2" lodash.uniq "^4.5.0" -caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001400, caniuse-lite@^1.0.30001426: - version "1.0.30001445" - resolved "https://registry.yarnpkg.com/caniuse-lite/-/caniuse-lite-1.0.30001445.tgz#cf2d4eb93f2bcdf0310de9dd6d18be271bc0b447" - integrity sha512-8sdQIdMztYmzfTMO6KfLny878Ln9c2M0fc7EH60IjlP4Dc4PiCy7K2Vl3ITmWgOyPgVQKa5x+UP/KqFsxj4mBg== +caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001426, caniuse-lite@^1.0.30001449: + version "1.0.30001462" + resolved "https://registry.yarnpkg.com/caniuse-lite/-/caniuse-lite-1.0.30001462.tgz#b2e801e37536d453731286857c8520d3dcee15fe" + integrity sha512-PDd20WuOBPiasZ7KbFnmQRyuLE7cFXW2PVd7dmALzbkUXEP46upAuCDm9eY9vho8fgNMGmbAX92QBZHzcnWIqw== ccount@^1.0.0: version "1.1.0" @@ -2917,14 +2967,14 @@ ci-info@^2.0.0: integrity sha512-5tK7EtrZ0N+OLFMthtqOj4fI2Jeb88C4CAZPu25LDVUgXJ0A3Js4PMGqrn0JU1W0Mh1/Z8wZzYPxqUrXeBboCQ== ci-info@^3.2.0: - version "3.7.1" - resolved "https://registry.yarnpkg.com/ci-info/-/ci-info-3.7.1.tgz#708a6cdae38915d597afdf3b145f2f8e1ff55f3f" - integrity sha512-4jYS4MOAaCIStSRwiuxc4B8MYhIe676yO1sYGzARnjXkWpmzZMMYxY6zu8WYWDhSuth5zhrQ1rhNSibyyvv4/w== + version "3.8.0" + resolved "https://registry.yarnpkg.com/ci-info/-/ci-info-3.8.0.tgz#81408265a5380c929f0bc665d62256628ce9ef91" + integrity sha512-eXTggHWSooYhq49F2opQhuHWgzucfF2YgODK4e1566GQs5BIfP30B0oenwBJHfWxAs2fyPB1s7Mg949zLf61Yw== clean-css@^5.2.2, clean-css@^5.3.0: - version "5.3.1" - resolved "https://registry.yarnpkg.com/clean-css/-/clean-css-5.3.1.tgz#d0610b0b90d125196a2894d35366f734e5d7aa32" - integrity sha512-lCr8OHhiWCTw4v8POJovCoh4T7I9U11yVsPjMWWnnMmp9ZowCxyad1Pathle/9HjaDp+fdQKjO9fQydE6RHTZg== + version "5.3.2" + resolved "https://registry.yarnpkg.com/clean-css/-/clean-css-5.3.2.tgz#70ecc7d4d4114921f5d298349ff86a31a9975224" + integrity sha512-JVJbM+f3d3Q704rF4bqQ5UUyTtuJ0JRKNbTKVEeujCCBoMdkEi+V+e8oktO9qGQNSvHrFTM6JZRXrUvGR1czww== dependencies: source-map "~0.6.0" @@ -3038,6 +3088,11 @@ comma-separated-tokens@^1.0.0: resolved "https://registry.yarnpkg.com/comma-separated-tokens/-/comma-separated-tokens-1.0.8.tgz#632b80b6117867a158f1080ad498b2fbe7e3f5ea" integrity sha512-GHuDRO12Sypu2cV70d1dkA2EUmXHgntrzbpvOB+Qy+49ypNfGgFQIC2fhhXbnyrJRynDCAARsT7Ou0M6hirpfw== +commander@7, commander@^7.2.0: + version "7.2.0" + resolved "https://registry.yarnpkg.com/commander/-/commander-7.2.0.tgz#a36cb57d0b501ce108e4d20559a150a391d97ab7" + integrity sha512-QrWXB+ZQSVPmIWIhtEO9H+gwHaMGYiF5ChvoJ+K9ZGHG/sVsa6yiesAD1GC/x46sET00Xlwo1u49RVVVzvcSkw== + commander@^2.20.0: version "2.20.3" resolved "https://registry.yarnpkg.com/commander/-/commander-2.20.3.tgz#fd485e84c03eb4881c20722ba48035e8531aeb33" @@ -3048,11 +3103,6 @@ commander@^5.1.0: resolved "https://registry.yarnpkg.com/commander/-/commander-5.1.0.tgz#46abbd1652f8e059bddaef99bbdcb2ad9cf179ae" integrity sha512-P0CysNDQ7rtVw4QIQtm+MRxV66vKFSvlsQvGYXZWR3qFU0jlMKHZZZgw8e+8DSah4UDKMqnknRDQz+xuQXQ/Zg== -commander@^7.2.0: - version "7.2.0" - resolved "https://registry.yarnpkg.com/commander/-/commander-7.2.0.tgz#a36cb57d0b501ce108e4d20559a150a391d97ab7" - integrity sha512-QrWXB+ZQSVPmIWIhtEO9H+gwHaMGYiF5ChvoJ+K9ZGHG/sVsa6yiesAD1GC/x46sET00Xlwo1u49RVVVzvcSkw== - commander@^8.0.0, commander@^8.3.0: version "8.3.0" resolved "https://registry.yarnpkg.com/commander/-/commander-8.3.0.tgz#4837ea1b2da67b9c616a67afbb0fafee567bca66" @@ -3128,9 +3178,9 @@ content-disposition@0.5.4: safe-buffer "5.2.1" content-type@~1.0.4: - version "1.0.4" - resolved "https://registry.yarnpkg.com/content-type/-/content-type-1.0.4.tgz#e138cc75e040c727b1966fe5e5f8c9aee256fe3b" - integrity sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA== + version "1.0.5" + resolved "https://registry.yarnpkg.com/content-type/-/content-type-1.0.5.tgz#8b773162656d1d1086784c8f23a54ce6d73d7918" + integrity sha512-nTjqfcBFEipKdXCv4YDQWCfmcLZKm81ldF0pAopTvyrFGVbcR6P/VAAd5G7N+0tTr8QqiU0tFadD6FK4NtJwOA== convert-source-map@^1.7.0: version "1.9.0" @@ -3165,27 +3215,41 @@ copy-webpack-plugin@^11.0.0: serialize-javascript "^6.0.0" core-js-compat@^3.25.1: - version "3.27.2" - resolved "https://registry.yarnpkg.com/core-js-compat/-/core-js-compat-3.27.2.tgz#607c50ad6db8fd8326af0b2883ebb987be3786da" - integrity sha512-welaYuF7ZtbYKGrIy7y3eb40d37rG1FvzEOfe7hSLd2iD6duMDqUhRfSvCGyC46HhR6Y8JXXdZ2lnRUMkPBpvg== + version "3.29.0" + resolved "https://registry.yarnpkg.com/core-js-compat/-/core-js-compat-3.29.0.tgz#1b8d9eb4191ab112022e7f6364b99b65ea52f528" + integrity sha512-ScMn3uZNAFhK2DGoEfErguoiAHhV2Ju+oJo/jK08p7B3f3UhocUrCCkTvnZaiS+edl5nlIoiBXKcwMc6elv4KQ== dependencies: - browserslist "^4.21.4" + browserslist "^4.21.5" core-js-pure@^3.25.1: - version "3.27.2" - resolved "https://registry.yarnpkg.com/core-js-pure/-/core-js-pure-3.27.2.tgz#47e9cc96c639eefc910da03c3ece26c5067c7553" - integrity sha512-Cf2jqAbXgWH3VVzjyaaFkY1EBazxugUepGymDoeteyYr9ByX51kD2jdHZlsEF/xnJMyN3Prua7mQuzwMg6Zc9A== + version "3.29.0" + resolved "https://registry.yarnpkg.com/core-js-pure/-/core-js-pure-3.29.0.tgz#0e1ac889214398641ea4bb1c6cf25ff0959ec1d2" + integrity sha512-v94gUjN5UTe1n0yN/opTihJ8QBWD2O8i19RfTZR7foONPWArnjB96QA/wk5ozu1mm6ja3udQCzOzwQXTxi3xOQ== core-js@^3.23.3: - version "3.27.2" - resolved "https://registry.yarnpkg.com/core-js/-/core-js-3.27.2.tgz#85b35453a424abdcacb97474797815f4d62ebbf7" - integrity sha512-9ashVQskuh5AZEZ1JdQWp1GqSoC1e1G87MzRqg2gIfVAQ7Qn9K+uFj8EcniUFA4P2NLZfV+TOlX1SzoKfo+s7w== + version "3.29.0" + resolved "https://registry.yarnpkg.com/core-js/-/core-js-3.29.0.tgz#0273e142b67761058bcde5615c503c7406b572d6" + integrity sha512-VG23vuEisJNkGl6XQmFJd3rEG/so/CNatqeE+7uZAwTSwFeB/qaO0be8xZYUNWprJ/GIwL8aMt9cj1kvbpTZhg== core-util-is@~1.0.0: version "1.0.3" resolved "https://registry.yarnpkg.com/core-util-is/-/core-util-is-1.0.3.tgz#a6042d3634c2b27e9328f837b965fac83808db85" integrity sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ== +cose-base@^1.0.0: + version "1.0.3" + resolved "https://registry.yarnpkg.com/cose-base/-/cose-base-1.0.3.tgz#650334b41b869578a543358b80cda7e0abe0a60a" + integrity sha512-s9whTXInMSgAp/NVXVNuVxVKzGH2qck3aQlVHxDCdAEPgtMKwc4Wq6/QKhgdEdgbLSi9rBTAcPoRa6JpiG4ksg== + dependencies: + layout-base "^1.0.0" + +cose-base@^2.2.0: + version "2.2.0" + resolved "https://registry.yarnpkg.com/cose-base/-/cose-base-2.2.0.tgz#1c395c35b6e10bb83f9769ca8b817d614add5c01" + integrity sha512-AzlgcsCbUMymkADOJtQm3wO9S3ltPfYOFD5033keQn9NJzIbtnZj+UdBJe7DYml/8TdbtHJW3j58SOnKhWY/5g== + dependencies: + layout-base "^2.0.0" + cosmiconfig@^6.0.0: version "6.0.0" resolved "https://registry.yarnpkg.com/cosmiconfig/-/cosmiconfig-6.0.0.tgz#da4fee853c52f6b1e6935f41c1a2fc50bd4a9982" @@ -3301,33 +3365,33 @@ cssesc@^3.0.0: integrity sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg== cssnano-preset-advanced@^5.3.8: - version "5.3.9" - resolved "https://registry.yarnpkg.com/cssnano-preset-advanced/-/cssnano-preset-advanced-5.3.9.tgz#99e1cdf81a467a5e6c366cfc6d874a166c4d9a67" - integrity sha512-njnh4pp1xCsibJcEHnWZb4EEzni0ePMqPuPNyuWT4Z+YeXmsgqNuTPIljXFEXhxGsWs9183JkXgHxc1TcsahIg== + version "5.3.10" + resolved "https://registry.yarnpkg.com/cssnano-preset-advanced/-/cssnano-preset-advanced-5.3.10.tgz#25558a1fbf3a871fb6429ce71e41be7f5aca6eef" + integrity sha512-fnYJyCS9jgMU+cmHO1rPSPf9axbQyD7iUhLO5Df6O4G+fKIOMps+ZbU0PdGFejFBBZ3Pftf18fn1eG7MAPUSWQ== dependencies: autoprefixer "^10.4.12" - cssnano-preset-default "^5.2.13" + cssnano-preset-default "^5.2.14" postcss-discard-unused "^5.1.0" postcss-merge-idents "^5.1.1" postcss-reduce-idents "^5.2.0" postcss-zindex "^5.1.0" -cssnano-preset-default@^5.2.13: - version "5.2.13" - resolved "https://registry.yarnpkg.com/cssnano-preset-default/-/cssnano-preset-default-5.2.13.tgz#e7353b0c57975d1bdd97ac96e68e5c1b8c68e990" - integrity sha512-PX7sQ4Pb+UtOWuz8A1d+Rbi+WimBIxJTRyBdgGp1J75VU0r/HFQeLnMYgHiCAp6AR4rqrc7Y4R+1Rjk3KJz6DQ== +cssnano-preset-default@^5.2.14: + version "5.2.14" + resolved "https://registry.yarnpkg.com/cssnano-preset-default/-/cssnano-preset-default-5.2.14.tgz#309def4f7b7e16d71ab2438052093330d9ab45d8" + integrity sha512-t0SFesj/ZV2OTylqQVOrFgEh5uanxbO6ZAdeCrNsUQ6fVuXwYTxJPNAGvGTxHbD68ldIJNec7PyYZDBrfDQ+6A== dependencies: css-declaration-sorter "^6.3.1" cssnano-utils "^3.1.0" postcss-calc "^8.2.3" - postcss-colormin "^5.3.0" + postcss-colormin "^5.3.1" postcss-convert-values "^5.1.3" postcss-discard-comments "^5.1.2" postcss-discard-duplicates "^5.1.0" postcss-discard-empty "^5.1.1" postcss-discard-overridden "^5.1.0" postcss-merge-longhand "^5.1.7" - postcss-merge-rules "^5.1.3" + postcss-merge-rules "^5.1.4" postcss-minify-font-values "^5.1.0" postcss-minify-gradients "^5.1.1" postcss-minify-params "^5.1.4" @@ -3342,7 +3406,7 @@ cssnano-preset-default@^5.2.13: postcss-normalize-url "^5.1.0" postcss-normalize-whitespace "^5.1.1" postcss-ordered-values "^5.1.3" - postcss-reduce-initial "^5.1.1" + postcss-reduce-initial "^5.1.2" postcss-reduce-transforms "^5.1.0" postcss-svgo "^5.1.0" postcss-unique-selectors "^5.1.1" @@ -3353,11 +3417,11 @@ cssnano-utils@^3.1.0: integrity sha512-JQNR19/YZhz4psLX/rQ9M83e3z2Wf/HdJbryzte4a3NSuafyp9w/I4U+hx5C2S9g41qlstH7DEWnZaaj83OuEA== cssnano@^5.1.12, cssnano@^5.1.8: - version "5.1.14" - resolved "https://registry.yarnpkg.com/cssnano/-/cssnano-5.1.14.tgz#07b0af6da73641276fe5a6d45757702ebae2eb05" - integrity sha512-Oou7ihiTocbKqi0J1bB+TRJIQX5RMR3JghA8hcWSw9mjBLQ5Y3RWqEDoYG3sRNlAbCIXpqMoZGbq5KDR3vdzgw== + version "5.1.15" + resolved "https://registry.yarnpkg.com/cssnano/-/cssnano-5.1.15.tgz#ded66b5480d5127fcb44dac12ea5a983755136bf" + integrity sha512-j+BKgDcLDQA+eDifLx0EO4XSA56b7uut3BQFH+wbSaSTuGLuiyTa/wbRYthUXX8LC9mLg+WWKe8h+qJuwTAbHw== dependencies: - cssnano-preset-default "^5.2.13" + cssnano-preset-default "^5.2.14" lilconfig "^2.0.3" yaml "^1.10.2" @@ -3373,6 +3437,285 @@ csstype@^3.0.2: resolved "https://registry.yarnpkg.com/csstype/-/csstype-3.1.1.tgz#841b532c45c758ee546a11d5bd7b7b473c8c30b9" integrity sha512-DJR/VvkAvSZW9bTouZue2sSxDwdTN92uHjqeKVm+0dAqdfNykRzQ95tay8aXMBAAPpUiq4Qcug2L7neoRh2Egw== +cytoscape-cose-bilkent@^4.1.0: + version "4.1.0" + resolved "https://registry.yarnpkg.com/cytoscape-cose-bilkent/-/cytoscape-cose-bilkent-4.1.0.tgz#762fa121df9930ffeb51a495d87917c570ac209b" + integrity sha512-wgQlVIUJF13Quxiv5e1gstZ08rnZj2XaLHGoFMYXz7SkNfCDOOteKBE6SYRfA9WxxI/iBc3ajfDoc6hb/MRAHQ== + dependencies: + cose-base "^1.0.0" + +cytoscape-fcose@^2.1.0: + version "2.2.0" + resolved "https://registry.yarnpkg.com/cytoscape-fcose/-/cytoscape-fcose-2.2.0.tgz#e4d6f6490df4fab58ae9cea9e5c3ab8d7472f471" + integrity sha512-ki1/VuRIHFCzxWNrsshHYPs6L7TvLu3DL+TyIGEsRcvVERmxokbf5Gdk7mFxZnTdiGtnA4cfSmjZJMviqSuZrQ== + dependencies: + cose-base "^2.2.0" + +cytoscape@^3.23.0: + version "3.23.0" + resolved "https://registry.yarnpkg.com/cytoscape/-/cytoscape-3.23.0.tgz#054ee05a6d0aa3b4f139382bbf2f4e5226df3c6d" + integrity sha512-gRZqJj/1kiAVPkrVFvz/GccxsXhF3Qwpptl32gKKypO4IlqnKBjTOu+HbXtEggSGzC5KCaHp3/F7GgENrtsFkA== + dependencies: + heap "^0.2.6" + lodash "^4.17.21" + +"d3-array@2 - 3", "d3-array@2.10.0 - 3", "d3-array@2.5.0 - 3", d3-array@3, d3-array@^3.2.0: + version "3.2.2" + resolved "https://registry.yarnpkg.com/d3-array/-/d3-array-3.2.2.tgz#f8ac4705c5b06914a7e0025bbf8d5f1513f6a86e" + integrity sha512-yEEyEAbDrF8C6Ob2myOBLjwBLck1Z89jMGFee0oPsn95GqjerpaOA4ch+vc2l0FNFFwMD5N7OCSEN5eAlsUbgQ== + dependencies: + internmap "1 - 2" + +d3-axis@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-axis/-/d3-axis-3.0.0.tgz#c42a4a13e8131d637b745fc2973824cfeaf93322" + integrity sha512-IH5tgjV4jE/GhHkRV0HiVYPDtvfjHQlQfJHs0usq7M30XcSBvOotpmH1IgkcXsO/5gEQZD43B//fc7SRT5S+xw== + +d3-brush@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-brush/-/d3-brush-3.0.0.tgz#6f767c4ed8dcb79de7ede3e1c0f89e63ef64d31c" + integrity sha512-ALnjWlVYkXsVIGlOsuWH1+3udkYFI48Ljihfnh8FZPF2QS9o+PzGLBslO0PjzVoHLZ2KCVgAM8NVkXPJB2aNnQ== + dependencies: + d3-dispatch "1 - 3" + d3-drag "2 - 3" + d3-interpolate "1 - 3" + d3-selection "3" + d3-transition "3" + +d3-chord@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-chord/-/d3-chord-3.0.1.tgz#d156d61f485fce8327e6abf339cb41d8cbba6966" + integrity sha512-VE5S6TNa+j8msksl7HwjxMHDM2yNK3XCkusIlpX5kwauBfXuyLAtNg9jCp/iHH61tgI4sb6R/EIMWCqEIdjT/g== + dependencies: + d3-path "1 - 3" + +"d3-color@1 - 3", d3-color@3: + version "3.1.0" + resolved "https://registry.yarnpkg.com/d3-color/-/d3-color-3.1.0.tgz#395b2833dfac71507f12ac2f7af23bf819de24e2" + integrity sha512-zg/chbXyeBtMQ1LbD/WSoW2DpC3I0mpmPdW+ynRTj/x2DAWYrIY7qeZIHidozwV24m4iavr15lNwIwLxRmOxhA== + +d3-contour@4: + version "4.0.2" + resolved "https://registry.yarnpkg.com/d3-contour/-/d3-contour-4.0.2.tgz#bb92063bc8c5663acb2422f99c73cbb6c6ae3bcc" + integrity sha512-4EzFTRIikzs47RGmdxbeUvLWtGedDUNkTcmzoeyg4sP/dvCexO47AaQL7VKy/gul85TOxw+IBgA8US2xwbToNA== + dependencies: + d3-array "^3.2.0" + +d3-delaunay@6: + version "6.0.2" + resolved "https://registry.yarnpkg.com/d3-delaunay/-/d3-delaunay-6.0.2.tgz#7fd3717ad0eade2fc9939f4260acfb503f984e92" + integrity sha512-IMLNldruDQScrcfT+MWnazhHbDJhcRJyOEBAJfwQnHle1RPh6WDuLvxNArUju2VSMSUuKlY5BGHRJ2cYyoFLQQ== + dependencies: + delaunator "5" + +"d3-dispatch@1 - 3", d3-dispatch@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-dispatch/-/d3-dispatch-3.0.1.tgz#5fc75284e9c2375c36c839411a0cf550cbfc4d5e" + integrity sha512-rzUyPU/S7rwUflMyLc1ETDeBj0NRuHKKAcvukozwhshr6g6c5d8zh4c2gQjY2bZ0dXeGLWc1PF174P2tVvKhfg== + +"d3-drag@2 - 3", d3-drag@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-drag/-/d3-drag-3.0.0.tgz#994aae9cd23c719f53b5e10e3a0a6108c69607ba" + integrity sha512-pWbUJLdETVA8lQNJecMxoXfH6x+mO2UQo8rSmZ+QqxcbyA3hfeprFgIT//HW2nlHChWeIIMwS2Fq+gEARkhTkg== + dependencies: + d3-dispatch "1 - 3" + d3-selection "3" + +"d3-dsv@1 - 3", d3-dsv@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-dsv/-/d3-dsv-3.0.1.tgz#c63af978f4d6a0d084a52a673922be2160789b73" + integrity sha512-UG6OvdI5afDIFP9w4G0mNq50dSOsXHJaRE8arAS5o9ApWnIElp8GZw1Dun8vP8OyHOZ/QJUKUJwxiiCCnUwm+Q== + dependencies: + commander "7" + iconv-lite "0.6" + rw "1" + +"d3-ease@1 - 3", d3-ease@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-ease/-/d3-ease-3.0.1.tgz#9658ac38a2140d59d346160f1f6c30fda0bd12f4" + integrity sha512-wR/XK3D3XcLIZwpbvQwQ5fK+8Ykds1ip7A2Txe0yxncXSdq1L9skcG7blcedkOX+ZcgxGAmLX1FrRGbADwzi0w== + +d3-fetch@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-fetch/-/d3-fetch-3.0.1.tgz#83141bff9856a0edb5e38de89cdcfe63d0a60a22" + integrity sha512-kpkQIM20n3oLVBKGg6oHrUchHM3xODkTzjMoj7aWQFq5QEM+R6E4WkzT5+tojDY7yjez8KgCBRoj4aEr99Fdqw== + dependencies: + d3-dsv "1 - 3" + +d3-force@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-force/-/d3-force-3.0.0.tgz#3e2ba1a61e70888fe3d9194e30d6d14eece155c4" + integrity sha512-zxV/SsA+U4yte8051P4ECydjD/S+qeYtnaIyAs9tgHCqfguma/aAQDjo85A9Z6EKhBirHRJHXIgJUlffT4wdLg== + dependencies: + d3-dispatch "1 - 3" + d3-quadtree "1 - 3" + d3-timer "1 - 3" + +"d3-format@1 - 3", d3-format@3: + version "3.1.0" + resolved "https://registry.yarnpkg.com/d3-format/-/d3-format-3.1.0.tgz#9260e23a28ea5cb109e93b21a06e24e2ebd55641" + integrity sha512-YyUI6AEuY/Wpt8KWLgZHsIU86atmikuoOmCfommt0LYHiQSPjvX2AcFc38PX0CBpr2RCyZhjex+NS/LPOv6YqA== + +d3-geo@3: + version "3.1.0" + resolved "https://registry.yarnpkg.com/d3-geo/-/d3-geo-3.1.0.tgz#74fd54e1f4cebd5185ac2039217a98d39b0a4c0e" + integrity sha512-JEo5HxXDdDYXCaWdwLRt79y7giK8SbhZJbFWXqbRTolCHFI5jRqteLzCsq51NKbUoX0PjBVSohxrx+NoOUujYA== + dependencies: + d3-array "2.5.0 - 3" + +d3-hierarchy@3: + version "3.1.2" + resolved "https://registry.yarnpkg.com/d3-hierarchy/-/d3-hierarchy-3.1.2.tgz#b01cd42c1eed3d46db77a5966cf726f8c09160c6" + integrity sha512-FX/9frcub54beBdugHjDCdikxThEqjnR93Qt7PvQTOHxyiNCAlvMrHhclk3cD5VeAaq9fxmfRp+CnWw9rEMBuA== + +"d3-interpolate@1 - 3", "d3-interpolate@1.2.0 - 3", d3-interpolate@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-interpolate/-/d3-interpolate-3.0.1.tgz#3c47aa5b32c5b3dfb56ef3fd4342078a632b400d" + integrity sha512-3bYs1rOD33uo8aqJfKP3JWPAibgw8Zm2+L9vBKEHJ2Rg+viTR7o5Mmv5mZcieN+FRYaAOWX5SJATX6k1PWz72g== + dependencies: + d3-color "1 - 3" + +"d3-path@1 - 3", d3-path@3, d3-path@^3.1.0: + version "3.1.0" + resolved "https://registry.yarnpkg.com/d3-path/-/d3-path-3.1.0.tgz#22df939032fb5a71ae8b1800d61ddb7851c42526" + integrity sha512-p3KP5HCf/bvjBSSKuXid6Zqijx7wIfNW+J/maPs+iwR35at5JCbLUT0LzF1cnjbCHWhqzQTIN2Jpe8pRebIEFQ== + +d3-polygon@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-polygon/-/d3-polygon-3.0.1.tgz#0b45d3dd1c48a29c8e057e6135693ec80bf16398" + integrity sha512-3vbA7vXYwfe1SYhED++fPUQlWSYTTGmFmQiany/gdbiWgU/iEyQzyymwL9SkJjFFuCS4902BSzewVGsHHmHtXg== + +"d3-quadtree@1 - 3", d3-quadtree@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-quadtree/-/d3-quadtree-3.0.1.tgz#6dca3e8be2b393c9a9d514dabbd80a92deef1a4f" + integrity sha512-04xDrxQTDTCFwP5H6hRhsRcb9xxv2RzkcsygFzmkSIOJy3PeRJP7sNk3VRIbKXcog561P9oU0/rVH6vDROAgUw== + +d3-random@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-random/-/d3-random-3.0.1.tgz#d4926378d333d9c0bfd1e6fa0194d30aebaa20f4" + integrity sha512-FXMe9GfxTxqd5D6jFsQ+DJ8BJS4E/fT5mqqdjovykEB2oFbTMDVdg1MGFxfQW+FBOGoB++k8swBrgwSHT1cUXQ== + +d3-scale-chromatic@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-scale-chromatic/-/d3-scale-chromatic-3.0.0.tgz#15b4ceb8ca2bb0dcb6d1a641ee03d59c3b62376a" + integrity sha512-Lx9thtxAKrO2Pq6OO2Ua474opeziKr279P/TKZsMAhYyNDD3EnCffdbgeSYN5O7m2ByQsxtuP2CSDczNUIZ22g== + dependencies: + d3-color "1 - 3" + d3-interpolate "1 - 3" + +d3-scale@4: + version "4.0.2" + resolved "https://registry.yarnpkg.com/d3-scale/-/d3-scale-4.0.2.tgz#82b38e8e8ff7080764f8dcec77bd4be393689396" + integrity sha512-GZW464g1SH7ag3Y7hXjf8RoUuAFIqklOAq3MRl4OaWabTFJY9PN/E1YklhXLh+OQ3fM9yS2nOkCoS+WLZ6kvxQ== + dependencies: + d3-array "2.10.0 - 3" + d3-format "1 - 3" + d3-interpolate "1.2.0 - 3" + d3-time "2.1.1 - 3" + d3-time-format "2 - 4" + +"d3-selection@2 - 3", d3-selection@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-selection/-/d3-selection-3.0.0.tgz#c25338207efa72cc5b9bd1458a1a41901f1e1b31" + integrity sha512-fmTRWbNMmsmWq6xJV8D19U/gw/bwrHfNXxrIN+HfZgnzqTHp9jOmKMhsTUjXOJnZOdZY9Q28y4yebKzqDKlxlQ== + +d3-shape@3: + version "3.2.0" + resolved "https://registry.yarnpkg.com/d3-shape/-/d3-shape-3.2.0.tgz#a1a839cbd9ba45f28674c69d7f855bcf91dfc6a5" + integrity sha512-SaLBuwGm3MOViRq2ABk3eLoxwZELpH6zhl3FbAoJ7Vm1gofKx6El1Ib5z23NUEhF9AsGl7y+dzLe5Cw2AArGTA== + dependencies: + d3-path "^3.1.0" + +"d3-time-format@2 - 4", d3-time-format@4: + version "4.1.0" + resolved "https://registry.yarnpkg.com/d3-time-format/-/d3-time-format-4.1.0.tgz#7ab5257a5041d11ecb4fe70a5c7d16a195bb408a" + integrity sha512-dJxPBlzC7NugB2PDLwo9Q8JiTR3M3e4/XANkreKSUxF8vvXKqm1Yfq4Q5dl8budlunRVlUUaDUgFt7eA8D6NLg== + dependencies: + d3-time "1 - 3" + +"d3-time@1 - 3", "d3-time@2.1.1 - 3", d3-time@3: + version "3.1.0" + resolved "https://registry.yarnpkg.com/d3-time/-/d3-time-3.1.0.tgz#9310db56e992e3c0175e1ef385e545e48a9bb5c7" + integrity sha512-VqKjzBLejbSMT4IgbmVgDjpkYrNWUYJnbCGo874u7MMKIWsILRX+OpX/gTk8MqjpT1A/c6HY2dCA77ZN0lkQ2Q== + dependencies: + d3-array "2 - 3" + +"d3-timer@1 - 3", d3-timer@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-timer/-/d3-timer-3.0.1.tgz#6284d2a2708285b1abb7e201eda4380af35e63b0" + integrity sha512-ndfJ/JxxMd3nw31uyKoY2naivF+r29V+Lc0svZxe1JvvIRmi8hUsrMvdOwgS1o6uBHmiz91geQ0ylPP0aj1VUA== + +"d3-transition@2 - 3", d3-transition@3: + version "3.0.1" + resolved "https://registry.yarnpkg.com/d3-transition/-/d3-transition-3.0.1.tgz#6869fdde1448868077fdd5989200cb61b2a1645f" + integrity sha512-ApKvfjsSR6tg06xrL434C0WydLr7JewBB3V+/39RMHsaXTOG0zmt/OAXeng5M5LBm0ojmxJrpomQVZ1aPvBL4w== + dependencies: + d3-color "1 - 3" + d3-dispatch "1 - 3" + d3-ease "1 - 3" + d3-interpolate "1 - 3" + d3-timer "1 - 3" + +d3-zoom@3: + version "3.0.0" + resolved "https://registry.yarnpkg.com/d3-zoom/-/d3-zoom-3.0.0.tgz#d13f4165c73217ffeaa54295cd6969b3e7aee8f3" + integrity sha512-b8AmV3kfQaqWAuacbPuNbL6vahnOJflOhexLzMMNLga62+/nh0JzvJ0aO/5a5MVgUFGS7Hu1P9P03o3fJkDCyw== + dependencies: + d3-dispatch "1 - 3" + d3-drag "2 - 3" + d3-interpolate "1 - 3" + d3-selection "2 - 3" + d3-transition "2 - 3" + +d3@^7.4.0, d3@^7.8.2: + version "7.8.2" + resolved "https://registry.yarnpkg.com/d3/-/d3-7.8.2.tgz#2bdb3c178d095ae03b107a18837ae049838e372d" + integrity sha512-WXty7qOGSHb7HR7CfOzwN1Gw04MUOzN8qh9ZUsvwycIMb4DYMpY9xczZ6jUorGtO6bR9BPMPaueIKwiDxu9uiQ== + dependencies: + d3-array "3" + d3-axis "3" + d3-brush "3" + d3-chord "3" + d3-color "3" + d3-contour "4" + d3-delaunay "6" + d3-dispatch "3" + d3-drag "3" + d3-dsv "3" + d3-ease "3" + d3-fetch "3" + d3-force "3" + d3-format "3" + d3-geo "3" + d3-hierarchy "3" + d3-interpolate "3" + d3-path "3" + d3-polygon "3" + d3-quadtree "3" + d3-random "3" + d3-scale "4" + d3-scale-chromatic "3" + d3-selection "3" + d3-shape "3" + d3-time "3" + d3-time-format "4" + d3-timer "3" + d3-transition "3" + d3-zoom "3" + +dagre-d3-es@7.0.9: + version "7.0.9" + resolved "https://registry.yarnpkg.com/dagre-d3-es/-/dagre-d3-es-7.0.9.tgz#aca12fccd9d09955a4430029ba72ee6934542a8d" + integrity sha512-rYR4QfVmy+sR44IBDvVtcAmOReGBvRCWDpO2QjYwqgh9yijw6eSHBqaPG/LIOEy7aBsniLvtMW6pg19qJhq60w== + dependencies: + d3 "^7.8.2" + lodash-es "^4.17.21" + +dayjs@^1.11.7: + version "1.11.7" + resolved "https://registry.yarnpkg.com/dayjs/-/dayjs-1.11.7.tgz#4b296922642f70999544d1144a2c25730fce63e2" + integrity sha512-+Yw9U6YO5TQohxLcIkrXBeY73WP3ejHWVvx8XCk3gxvQDCTEmS48ZrSZCKciI7Bhl/uCMyxYtE9UqRILmFphkQ== + debug@2.6.9, debug@^2.6.0: version "2.6.9" resolved "https://registry.yarnpkg.com/debug/-/debug-2.6.9.tgz#5d128515df134ff327e90a4c93f4e077a536341f" @@ -3406,10 +3749,10 @@ deep-extend@^0.6.0: resolved "https://registry.yarnpkg.com/deep-extend/-/deep-extend-0.6.0.tgz#c4fa7c95404a17a9c3e8ca7e1537312b736330ac" integrity sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA== -deepmerge@^4.2.2: - version "4.2.2" - resolved "https://registry.yarnpkg.com/deepmerge/-/deepmerge-4.2.2.tgz#44d2ea3679b8f4d4ffba33f03d865fc1e7bf4955" - integrity sha512-FJ3UgI4gIl+PHZm53knsuSFpE+nESMr7M4v9QcgB7S63Kj/6WqMiFQJpBBYz1Pt+66bZpP3Q7Lye0Oo9MPKEdg== +deepmerge@^4.0.0, deepmerge@^4.2.2: + version "4.3.0" + resolved "https://registry.yarnpkg.com/deepmerge/-/deepmerge-4.3.0.tgz#65491893ec47756d44719ae520e0e2609233b59b" + integrity sha512-z2wJZXrmeHdvYJp/Ux55wIjqo81G5Bp4c+oELTW+7ar6SogWHajt5a9gO3s3IDaGSAXjDk0vlQKN3rms8ab3og== default-gateway@^6.0.3: version "6.0.3" @@ -3429,9 +3772,9 @@ define-lazy-prop@^2.0.0: integrity sha512-Ds09qNh8yw3khSjiJjiUInaGX9xlqZDY7JVryGxdxV7NPeuqQfplOpQ66yJFZut3jLa5zOwkXw1g9EI2uKh4Og== define-properties@^1.1.4: - version "1.1.4" - resolved "https://registry.yarnpkg.com/define-properties/-/define-properties-1.1.4.tgz#0b14d7bd7fbeb2f3572c3a7eda80ea5d57fb05b1" - integrity sha512-uckOqKcfaVvtBdsVkdPv3XjveQJsNQqmhXgRi8uhvWWuPYZCNlzT8qAyblUgNoXdHdjMTzAqeGjAoli8f+bzPA== + version "1.2.0" + resolved "https://registry.yarnpkg.com/define-properties/-/define-properties-1.2.0.tgz#52988570670c9eacedd8064f4a990f2405849bd5" + integrity sha512-xvqAVKGfT1+UAvPwKTVw/njhdQ8ZhXK4lI0bCIuCMrp2up9nPnaDftrLtmpTazqd1o+UY4zgzU+avtMbDP+ldA== dependencies: has-property-descriptors "^1.0.0" object-keys "^1.1.1" @@ -3450,6 +3793,13 @@ del@^6.1.1: rimraf "^3.0.2" slash "^3.0.0" +delaunator@5: + version "5.0.0" + resolved "https://registry.yarnpkg.com/delaunator/-/delaunator-5.0.0.tgz#60f052b28bd91c9b4566850ebf7756efe821d81b" + integrity sha512-AyLvtyJdbv/U1GkiS6gUUzclRoAY4Gs75qkMygJJhU75LW4DNuSF2RMzpxs9jw9Oz1BobHjTdkG3zdP55VxAqw== + dependencies: + robust-predicates "^3.0.0" + depd@2.0.0: version "2.0.0" resolved "https://registry.yarnpkg.com/depd/-/depd-2.0.0.tgz#b696163cc757560d09cf22cc8fad1571b79e76df" @@ -3561,6 +3911,11 @@ domhandler@^5.0.1, domhandler@^5.0.2, domhandler@^5.0.3: dependencies: domelementtype "^2.3.0" +dompurify@2.4.3: + version "2.4.3" + resolved "https://registry.yarnpkg.com/dompurify/-/dompurify-2.4.3.tgz#f4133af0e6a50297fc8874e2eaedc13a3c308c03" + integrity sha512-q6QaLcakcRjebxjg8/+NP+h0rPfatOgOzc46Fst9VAA3jF2ApfKBNKMzdP4DYTqtUMXSCd5pRS/8Po/OmoCHZQ== + domutils@^2.5.2, domutils@^2.8.0: version "2.8.0" resolved "https://registry.yarnpkg.com/domutils/-/domutils-2.8.0.tgz#4437def5db6e2d1f5d6ee859bd95ca7d02048135" @@ -3614,10 +3969,15 @@ ee-first@1.1.1: resolved "https://registry.yarnpkg.com/ee-first/-/ee-first-1.1.1.tgz#590c61156b0ae2f4f0255732a158b266bc56b21d" integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow== -electron-to-chromium@^1.4.251: - version "1.4.284" - resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.284.tgz#61046d1e4cab3a25238f6bf7413795270f125592" - integrity sha512-M8WEXFuKXMYMVr45fo8mq0wUrrJHheiKZf6BArTKk9ZBYCKJEOU5H8cdWgDT+qCVZf7Na4lVUaZsA+h6uA9+PA== +electron-to-chromium@^1.4.284: + version "1.4.325" + resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.325.tgz#7b97238a61192d85d055d97f3149832b3617d37b" + integrity sha512-K1C03NT4I7BuzsRdCU5RWkgZxtswnKDYM6/eMhkEXqKu4e5T+ck610x3FPzu1y7HVFSiQKZqP16gnJzPpji1TQ== + +elkjs@^0.8.2: + version "0.8.2" + resolved "https://registry.yarnpkg.com/elkjs/-/elkjs-0.8.2.tgz#c37763c5a3e24e042e318455e0147c912a7c248e" + integrity sha512-L6uRgvZTH+4OF5NE/MBbzQx/WYpru1xCBE9respNj6qznEewGUIfhzmm7horWWxbNO2M0WckQypGctR8lH79xQ== emoji-regex@^8.0.0: version "8.0.0" @@ -3741,10 +4101,10 @@ esutils@^2.0.2: resolved "https://registry.yarnpkg.com/esutils/-/esutils-2.0.3.tgz#74d2eb4de0b8da1293711910d50775b9b710ef64" integrity sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g== -eta@^1.12.3: - version "1.13.0" - resolved "https://registry.yarnpkg.com/eta/-/eta-1.13.0.tgz#fff245d667ee663f614cb73eed8bf20917fe5843" - integrity sha512-GTgHqxvbQbNoUfkbdgHMVTY3bXVRJUWkfWEImZ2TPjln6nFlsYvu2fIVGWQmsa3qQ1ck0HwGq8OhS0wPCnsjMw== +eta@^2.0.0: + version "2.0.1" + resolved "https://registry.yarnpkg.com/eta/-/eta-2.0.1.tgz#199e675359cb6e19d38f29e1f405e1ba0e79a6df" + integrity sha512-46E2qDPDm7QA+usjffUWz9KfXsxVZclPOuKsXs4ZWZdI/X1wpDF7AO424pt7fdYohCzWsIkXAhNGXSlwo5naAg== etag@~1.8.1: version "1.8.1" @@ -3991,9 +4351,9 @@ follow-redirects@^1.0.0, follow-redirects@^1.14.7: integrity sha512-VQLG33o04KaQ8uYi2tVNbdrWp1QWxNNea+nmIB4EVM28v0hmP17z7aG1+wAkNzVq4KeXTq3221ye5qTJP91JwA== fork-ts-checker-webpack-plugin@^6.5.0: - version "6.5.2" - resolved "https://registry.yarnpkg.com/fork-ts-checker-webpack-plugin/-/fork-ts-checker-webpack-plugin-6.5.2.tgz#4f67183f2f9eb8ba7df7177ce3cf3e75cdafb340" - integrity sha512-m5cUmF30xkZ7h4tWUgTAcEaKmUW7tfyUyTqNNOz7OxWJ0v1VWKTcOvH8FWHUwSjlW/356Ijc9vi3XfcPstpQKA== + version "6.5.3" + resolved "https://registry.yarnpkg.com/fork-ts-checker-webpack-plugin/-/fork-ts-checker-webpack-plugin-6.5.3.tgz#eda2eff6e22476a2688d10661688c47f611b37f3" + integrity sha512-SbH/l9ikmMWycd5puHJKTkZJKddF4iRLyW3DeZ08HTI7NGyLS38MXd/KGgeWumQO7YNQbW2u/NtPT2YowbPaGQ== dependencies: "@babel/code-frame" "^7.8.3" "@types/json-schema" "^7.0.5" @@ -4074,9 +4434,9 @@ gensync@^1.0.0-beta.1, gensync@^1.0.0-beta.2: integrity sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg== get-intrinsic@^1.0.2, get-intrinsic@^1.1.1: - version "1.1.3" - resolved "https://registry.yarnpkg.com/get-intrinsic/-/get-intrinsic-1.1.3.tgz#063c84329ad93e83893c7f4f243ef63ffa351385" - integrity sha512-QJVz1Tj7MS099PevUG5jvnt9tSkXN8K14dxQlikJuPt4uD9hHAHjLyLBiLR5zELelBdD9QNRAXZzsJx0WaDL9A== + version "1.2.0" + resolved "https://registry.yarnpkg.com/get-intrinsic/-/get-intrinsic-1.2.0.tgz#7ad1dc0535f3a2904bba075772763e5051f6d05f" + integrity sha512-L049y6nFOuom5wGyRc3/gdTLO94dySVKRACj1RmJZBQXlbTMhtNIgkWkUHq+jYmZvKf14EW1EoJnnjbmoHij0Q== dependencies: function-bind "^1.1.1" has "^1.0.3" @@ -4363,6 +4723,11 @@ he@^1.2.0: resolved "https://registry.yarnpkg.com/he/-/he-1.2.0.tgz#84ae65fa7eafb165fddb61566ae14baf05664f0f" integrity sha512-F/1DnUGPopORZi0ni+CvrCgHQ5FyEAHRLSApuYWMmrbSwoN2Mn/7k+Gl38gJnR7yyDZk6WLXwiGod1JOWNDKGw== +heap@^0.2.6: + version "0.2.7" + resolved "https://registry.yarnpkg.com/heap/-/heap-0.2.7.tgz#1e6adf711d3f27ce35a81fe3b7bd576c2260a8fc" + integrity sha512-2bsegYkkHO+h/9MGbn6KWcE45cHZgPANo5LXF7EvWdT0yT2EguSVO1nDgU5c8+ZOPwp2vMNa7YFsJhVcDR9Sdg== + history@^4.9.0: version "4.10.1" resolved "https://registry.yarnpkg.com/history/-/history-4.10.1.tgz#33371a65e3a83b267434e2b3f3b1b4c58aad4cf3" @@ -4452,9 +4817,9 @@ htmlparser2@^8.0.1: entities "^4.3.0" http-cache-semantics@^4.0.0: - version "4.1.0" - resolved "https://registry.yarnpkg.com/http-cache-semantics/-/http-cache-semantics-4.1.0.tgz#49e91c5cbf36c9b94bcfcd71c23d5249ec74e390" - integrity sha512-carPklcUh7ROWRK7Cv27RPtdhYhUsela/ue5/jKzjegVvXDqM2ILE9Q2BGn9JZJh1g87cp56su/FgQSzcWS8cQ== + version "4.1.1" + resolved "https://registry.yarnpkg.com/http-cache-semantics/-/http-cache-semantics-4.1.1.tgz#abe02fcb2985460bf0323be664436ec3476a6d5a" + integrity sha512-er295DKPVsV82j5kw1Gjt+ADA/XYHsajl82cGNQG2eyoPkvgUhX+nDIyelzhIWbbsXP39EHcI6l5tYs2FYqYXQ== http-deceiver@^1.2.7: version "1.2.7" @@ -4519,6 +4884,13 @@ iconv-lite@0.4.24: dependencies: safer-buffer ">= 2.1.2 < 3" +iconv-lite@0.6: + version "0.6.3" + resolved "https://registry.yarnpkg.com/iconv-lite/-/iconv-lite-0.6.3.tgz#a52f80bf38da1952eb5c681790719871a1a72501" + integrity sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw== + dependencies: + safer-buffer ">= 2.1.2 < 3.0.0" + icss-utils@^5.0.0, icss-utils@^5.1.0: version "5.1.0" resolved "https://registry.yarnpkg.com/icss-utils/-/icss-utils-5.1.0.tgz#c6be6858abd013d768e98366ae47e25d5887b1ae" @@ -4542,9 +4914,9 @@ image-size@^1.0.1: queue "6.0.2" immer@^9.0.7: - version "9.0.18" - resolved "https://registry.yarnpkg.com/immer/-/immer-9.0.18.tgz#d2faee58fd0e34f017f329b98cdab37826fa31b8" - integrity sha512-eAPNpsj7Ax1q6Y/3lm2PmlwRcFzpON7HSNQ3ru5WQH1/PSpnyed/HpNOELl2CxLKoj4r+bAHgdyKqW5gc2Se1A== + version "9.0.19" + resolved "https://registry.yarnpkg.com/immer/-/immer-9.0.19.tgz#67fb97310555690b5f9cd8380d38fc0aabb6b38b" + integrity sha512-eY+Y0qcsB4TZKwgQzLaE/lqYMlKhv5J9dyd2RhhtGhNo2njPXDqU9XPfcNfa3MIDsdtZt5KlkIsirlo4dHsWdQ== import-fresh@^3.1.0, import-fresh@^3.2.1, import-fresh@^3.3.0: version "3.3.0" @@ -4607,6 +4979,11 @@ inline-style-parser@0.1.1: resolved "https://registry.yarnpkg.com/inline-style-parser/-/inline-style-parser-0.1.1.tgz#ec8a3b429274e9c0a1f1c4ffa9453a7fef72cea1" integrity sha512-7NXolsK4CAS5+xvdj5OMMbI962hU/wvwoxk+LWR9Ek9bVtyuuYScDN6eS0rUm6TxApFpw7CX1o4uJzcd4AyD3Q== +"internmap@1 - 2": + version "2.0.3" + resolved "https://registry.yarnpkg.com/internmap/-/internmap-2.0.3.tgz#6685f23755e43c524e251d29cbc97248e3061009" + integrity sha512-5Hh7Y1wQbvY5ooGgPbDaL5iYLAPzMTUrjMulskHLH6wnv/A+1q5rgEaiuqEjB+oxGXIVZs1FF+R/KPN3ZSQYYg== + interpret@^1.0.0: version "1.4.0" resolved "https://registry.yarnpkg.com/interpret/-/interpret-1.4.0.tgz#665ab8bc4da27a774a40584e812e3e0fa45b1a1e" @@ -4832,12 +5209,12 @@ isobject@^3.0.1: resolved "https://registry.yarnpkg.com/isobject/-/isobject-3.0.1.tgz#4e431e92b11a9731636aa1f9c8d1ccbcfdab78df" integrity sha512-WhB9zCku7EGTj/HQQRz5aUQEUeoQZH2bWcltRErOpymJ4boYE6wL9Tbr23krRPSZ+C5zqNSrSw+Cc7sZZ4b7vg== -jest-util@^29.3.1: - version "29.3.1" - resolved "https://registry.yarnpkg.com/jest-util/-/jest-util-29.3.1.tgz#1dda51e378bbcb7e3bc9d8ab651445591ed373e1" - integrity sha512-7YOVZaiX7RJLv76ZfHt4nbNEzzTRiMW/IiOG7ZOKmTXmoGBxUDefgMAxQubu6WPVqP5zSzAdZG0FfLcC7HOIFQ== +jest-util@^29.5.0: + version "29.5.0" + resolved "https://registry.yarnpkg.com/jest-util/-/jest-util-29.5.0.tgz#24a4d3d92fc39ce90425311b23c27a6e0ef16b8f" + integrity sha512-RYMgG/MTadOr5t8KdhejfvUU82MxsCu5MF6KuDUHl+NuwzUt+Sm6jJWxTJVrDR1j5M/gJVCPKQEpWXY+yIQ6lQ== dependencies: - "@jest/types" "^29.3.1" + "@jest/types" "^29.5.0" "@types/node" "*" chalk "^4.0.0" ci-info "^3.2.0" @@ -4854,24 +5231,24 @@ jest-worker@^27.4.5: supports-color "^8.0.0" jest-worker@^29.1.2: - version "29.3.1" - resolved "https://registry.yarnpkg.com/jest-worker/-/jest-worker-29.3.1.tgz#e9462161017a9bb176380d721cab022661da3d6b" - integrity sha512-lY4AnnmsEWeiXirAIA0c9SDPbuCBq8IYuDVL8PMm0MZ2PEs2yPvRA/J64QBXuZp7CYKrDM/rmNrc9/i3KJQncw== + version "29.5.0" + resolved "https://registry.yarnpkg.com/jest-worker/-/jest-worker-29.5.0.tgz#bdaefb06811bd3384d93f009755014d8acb4615d" + integrity sha512-NcrQnevGoSp4b5kg+akIpthoAFHxPBcb5P6mYPY0fUNT+sSvmtu6jlkEle3anczUKIKEbMxFimk9oTP/tpIPgA== dependencies: "@types/node" "*" - jest-util "^29.3.1" + jest-util "^29.5.0" merge-stream "^2.0.0" supports-color "^8.0.0" joi@^17.6.0: - version "17.7.0" - resolved "https://registry.yarnpkg.com/joi/-/joi-17.7.0.tgz#591a33b1fe1aca2bc27f290bcad9b9c1c570a6b3" - integrity sha512-1/ugc8djfn93rTE3WRKdCzGGt/EtiYKxITMO4Wiv6q5JL1gl9ePt4kBsl1S499nbosspfctIQTpYIhSmHA3WAg== + version "17.8.3" + resolved "https://registry.yarnpkg.com/joi/-/joi-17.8.3.tgz#d772fe27a87a5cda21aace5cf11eee8671ca7e6f" + integrity sha512-q5Fn6Tj/jR8PfrLrx4fpGH4v9qM6o+vDUfD4/3vxxyg34OmKcNqYZ1qn2mpLza96S8tL0p0rIw2gOZX+/cTg9w== dependencies: "@hapi/hoek" "^9.0.0" "@hapi/topo" "^5.0.0" "@sideway/address" "^4.1.3" - "@sideway/formula" "^3.0.0" + "@sideway/formula" "^3.0.1" "@sideway/pinpoint" "^2.0.0" "js-tokens@^3.0.0 || ^4.0.0", js-tokens@^4.0.0: @@ -4952,6 +5329,11 @@ keyv@^3.0.0: dependencies: json-buffer "3.0.0" +khroma@^2.0.0: + version "2.0.0" + resolved "https://registry.yarnpkg.com/khroma/-/khroma-2.0.0.tgz#7577de98aed9f36c7a474c4d453d94c0d6c6588b" + integrity sha512-2J8rDNlQWbtiNYThZRvmMv5yt44ZakX+Tz5ZIp/mN1pt4snn+m030Va5Z4v8xA0cQFDXBwO/8i42xL4QPsVk3g== + kind-of@^6.0.0, kind-of@^6.0.2: version "6.0.3" resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.3.tgz#07c05034a6c349fa06e24fa35aa76db4580ce4dd" @@ -4974,21 +5356,36 @@ latest-version@^5.1.0: dependencies: package-json "^6.3.0" +layout-base@^1.0.0: + version "1.0.2" + resolved "https://registry.yarnpkg.com/layout-base/-/layout-base-1.0.2.tgz#1291e296883c322a9dd4c5dd82063721b53e26e2" + integrity sha512-8h2oVEZNktL4BH2JCOI90iD1yXwL6iNW7KcCKT2QZgQJR2vbqDsldCTPRU9NifTCqHZci57XvQQ15YTu+sTYPg== + +layout-base@^2.0.0: + version "2.0.1" + resolved "https://registry.yarnpkg.com/layout-base/-/layout-base-2.0.1.tgz#d0337913586c90f9c2c075292069f5c2da5dd285" + integrity sha512-dp3s92+uNI1hWIpPGH3jK2kxE2lMjdXdr+DH8ynZHpd6PUlH6x6cbuXnoMmiNumznqaNO31xu9e79F0uuZ0JFg== + leven@^3.1.0: version "3.1.0" resolved "https://registry.yarnpkg.com/leven/-/leven-3.1.0.tgz#77891de834064cccba82ae7842bb6b14a13ed7f2" integrity sha512-qsda+H8jTaUaN/x5vzW2rzc+8Rw4TAQ/4KjB46IwK5VH+IlVeeeje/EoZRpiXvIqjFgK84QffqPztGI3VBLG1A== lilconfig@^2.0.3: - version "2.0.6" - resolved "https://registry.yarnpkg.com/lilconfig/-/lilconfig-2.0.6.tgz#32a384558bd58af3d4c6e077dd1ad1d397bc69d4" - integrity sha512-9JROoBW7pobfsx+Sq2JsASvCo6Pfo6WWoUW79HuB1BCoBXD4PLWJPqDF6fNj67pqBYTbAHkE57M1kS/+L1neOg== + version "2.1.0" + resolved "https://registry.yarnpkg.com/lilconfig/-/lilconfig-2.1.0.tgz#78e23ac89ebb7e1bfbf25b18043de756548e7f52" + integrity sha512-utWOt/GHzuUxnLKxB6dk81RoOeoNeHgbrXiuGk4yyF5qlRz+iIVWu56E2fqGHFrXz0QNUhLB/8nKqvRH66JKGQ== lines-and-columns@^1.1.6: version "1.2.4" resolved "https://registry.yarnpkg.com/lines-and-columns/-/lines-and-columns-1.2.4.tgz#eca284f75d2965079309dc0ad9255abb2ebc1632" integrity sha512-7ylylesZQ/PV29jhEDl3Ufjo6ZX7gCqJr5F7PKrqc93v7fzSymt1BpwEU8nAUXs8qzzvqhbjhK5QZg6Mt/HkBg== +load-script@^1.0.0: + version "1.0.0" + resolved "https://registry.yarnpkg.com/load-script/-/load-script-1.0.0.tgz#0491939e0bee5643ee494a7e3da3d2bac70c6ca4" + integrity sha512-kPEjMFtZvwL9TaZo0uZ2ml+Ye9HUMmPwbYRJ324qF9tqMejwykJ5ggTyvzmrbBeapCAbk98BSbTeovHEEP1uCA== + loader-runner@^4.2.0: version "4.3.0" resolved "https://registry.yarnpkg.com/loader-runner/-/loader-runner-4.3.0.tgz#c1b4a163b99f614830353b16755e7149ac2314e1" @@ -5030,6 +5427,11 @@ locate-path@^6.0.0: dependencies: p-locate "^5.0.0" +lodash-es@^4.17.21: + version "4.17.21" + resolved "https://registry.yarnpkg.com/lodash-es/-/lodash-es-4.17.21.tgz#43e626c46e6591b7750beb2b50117390c609e3ee" + integrity sha512-mKnC+QJ9pWVzv+C4/U3rRsHapFfHvQFoFB92e52xeyGMcX6/OlIl78je1u8vePzYZSkkogMPJ2yjxxsb89cxyw== + lodash.curry@^4.0.1: version "4.1.1" resolved "https://registry.yarnpkg.com/lodash.curry/-/lodash.curry-4.1.1.tgz#248e36072ede906501d75966200a86dab8b23170" @@ -5165,6 +5567,11 @@ memfs@^3.1.2, memfs@^3.4.3: dependencies: fs-monkey "^1.0.3" +memoize-one@^5.1.1: + version "5.2.1" + resolved "https://registry.yarnpkg.com/memoize-one/-/memoize-one-5.2.1.tgz#8337aa3c4335581839ec01c3d594090cebe8f00e" + integrity sha512-zYiwtZUcYyXKo/np96AGZAckk+FWWsUdJ3cHGGmld7+AhvcWmQyGCYUh1hc4Q/pkOhb65dQR/pqCyK0cOaHz4Q== + merge-descriptors@1.0.1: version "1.0.1" resolved "https://registry.yarnpkg.com/merge-descriptors/-/merge-descriptors-1.0.1.tgz#b00aaa556dd8b44568150ec9d1b953f3f90cbb61" @@ -5180,6 +5587,28 @@ merge2@^1.3.0, merge2@^1.4.1: resolved "https://registry.yarnpkg.com/merge2/-/merge2-1.4.1.tgz#4368892f885e907455a6fd7dc55c0c9d404990ae" integrity sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg== +mermaid@^9.2.2: + version "9.4.3" + resolved "https://registry.yarnpkg.com/mermaid/-/mermaid-9.4.3.tgz#62cf210c246b74972ea98c19837519b6f03427f2" + integrity sha512-TLkQEtqhRSuEHSE34lh5bCa94KATCyluAXmFnNI2PRZwOpXFeqiJWwZl+d2CcemE1RS6QbbueSSq9QIg8Uxcyw== + dependencies: + "@braintree/sanitize-url" "^6.0.0" + cytoscape "^3.23.0" + cytoscape-cose-bilkent "^4.1.0" + cytoscape-fcose "^2.1.0" + d3 "^7.4.0" + dagre-d3-es "7.0.9" + dayjs "^1.11.7" + dompurify "2.4.3" + elkjs "^0.8.2" + khroma "^2.0.0" + lodash-es "^4.17.21" + non-layered-tidy-tree-layout "^2.0.2" + stylis "^4.1.2" + ts-dedent "^2.2.0" + uuid "^9.0.0" + web-worker "^1.2.0" + methods@~1.1.2: version "1.1.2" resolved "https://registry.yarnpkg.com/methods/-/methods-1.1.2.tgz#5529a4d67654134edcc5266656835b0f851afcee" @@ -5238,9 +5667,9 @@ mimic-response@^3.1.0: integrity sha512-z0yWI+4FDrrweS8Zmt4Ej5HdJmky15+L2e6Wgn3+iK5fWzb6T3fhNFq2+MeTRb064c6Wr4N/wv0DzQTjNzHNGQ== mini-css-extract-plugin@^2.6.1: - version "2.7.2" - resolved "https://registry.yarnpkg.com/mini-css-extract-plugin/-/mini-css-extract-plugin-2.7.2.tgz#e049d3ea7d3e4e773aad585c6cb329ce0c7b72d7" - integrity sha512-EdlUizq13o0Pd+uCp+WO/JpkLvHRVGt97RqfeGhXqAcorYo1ypJSpkV+WDT0vY/kmh/p7wRdJNJtuyK540PXDw== + version "2.7.3" + resolved "https://registry.yarnpkg.com/mini-css-extract-plugin/-/mini-css-extract-plugin-2.7.3.tgz#794aa4d598bf178a66b2a35fe287c3df3eac394e" + integrity sha512-CD9cXeKeXLcnMw8FZdtfrRrLaM7gwCl4nKuKn2YkY2Bw5wdlB8zU2cCzw+w2zS9RFvbrufTBkMCJACNPwqQA0w== dependencies: schema-utils "^4.0.0" @@ -5256,7 +5685,12 @@ minimatch@3.1.2, minimatch@^3.0.4, minimatch@^3.0.5, minimatch@^3.1.1: dependencies: brace-expansion "^1.1.7" -minimist@^1.2.0, minimist@^1.2.3, minimist@^1.2.5: +minimist@^1.2.0, minimist@^1.2.5: + version "1.2.8" + resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.8.tgz#c1a464e7693302e082a075cee0c057741ac4772c" + integrity sha512-2yyAR8qBkN3YuheJanUpWC5U3bb5osDywNB8RzDVlDwDHbocAJveqqj1u8+SVD7jkWT4yvsHCpWqqWqAxb0zCA== + +minimist@^1.2.3: version "1.2.7" resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.7.tgz#daa1c4d91f507390437c6a8bc01078e7000c4d18" integrity sha512-bzfL1YUZsP41gmu/qjrEk0Q6i2ix/cVeAhbCbqH9u3zYutS1cLg00qhrD0M2MVdCcx4Sc0UpP2eBWo9rotpq6g== @@ -5353,10 +5787,15 @@ node-forge@^1: resolved "https://registry.yarnpkg.com/node-forge/-/node-forge-1.3.1.tgz#be8da2af243b2417d5f646a770663a92b7e9ded3" integrity sha512-dPEtOeMvF9VMcYV/1Wb8CPoVAXtp6MKMlcbAt4ddqmGqUJ6fQZFXkNZNkNlfevtNkGtaSoXf/vNNNSvgrdXwtA== -node-releases@^2.0.6: - version "2.0.8" - resolved "https://registry.yarnpkg.com/node-releases/-/node-releases-2.0.8.tgz#0f349cdc8fcfa39a92ac0be9bc48b7706292b9ae" - integrity sha512-dFSmB8fFHEH/s81Xi+Y/15DQY6VHW81nXRj86EMSL3lmuTmK1e+aT4wrFCkTbm+gSwkw4KpX+rT/pMM2c1mF+A== +node-releases@^2.0.8: + version "2.0.10" + resolved "https://registry.yarnpkg.com/node-releases/-/node-releases-2.0.10.tgz#c311ebae3b6a148c89b1813fd7c4d3c024ef537f" + integrity sha512-5GFldHPXVG/YZmFzJvKK2zDSzPKhEp0+ZR5SVaoSag9fsL5YgHbUHDfnG5494ISANDcK4KwPXAx2xqVEydmd7w== + +non-layered-tidy-tree-layout@^2.0.2: + version "2.0.2" + resolved "https://registry.yarnpkg.com/non-layered-tidy-tree-layout/-/non-layered-tidy-tree-layout-2.0.2.tgz#57d35d13c356643fc296a55fb11ac15e74da7804" + integrity sha512-gkXMxRzUH+PB0ax9dUN0yYF0S25BqeAYqhgMaLUFmpXLEk7Fcu8f4emJuOAY0V8kjDICxROIKsTAKsV/v355xw== normalize-path@^3.0.0, normalize-path@~3.0.0: version "3.0.0" @@ -5454,9 +5893,9 @@ onetime@^5.1.2: mimic-fn "^2.1.0" open@^8.0.9, open@^8.4.0: - version "8.4.0" - resolved "https://registry.yarnpkg.com/open/-/open-8.4.0.tgz#345321ae18f8138f82565a910fdc6b39e8c244f8" - integrity sha512-XgFPPM+B28FtCCgSb9I+s9szOC1vZRSwgWsRUA5ylIxRTgKozqjOCrVOqGsYABPYK5qnfqClxZTFBa8PKt2v6Q== + version "8.4.2" + resolved "https://registry.yarnpkg.com/open/-/open-8.4.2.tgz#5b5ffe2a8f793dcd2aad73e550cb87b59cb084f9" + integrity sha512-7x81NCL719oNbsq/3mh+hVrAWmFuEYUqrq/Iw3kUzH8ReypT9QQ0BLoJS7/G9k6N81XjW4qHWtjWwe/9eLy1EQ== dependencies: define-lazy-prop "^2.0.0" is-docker "^2.1.1" @@ -5696,12 +6135,12 @@ postcss-calc@^8.2.3: postcss-selector-parser "^6.0.9" postcss-value-parser "^4.2.0" -postcss-colormin@^5.3.0: - version "5.3.0" - resolved "https://registry.yarnpkg.com/postcss-colormin/-/postcss-colormin-5.3.0.tgz#3cee9e5ca62b2c27e84fce63affc0cfb5901956a" - integrity sha512-WdDO4gOFG2Z8n4P8TWBpshnL3JpmNmJwdnfP2gbk2qBA8PWwOYcmjmI/t3CmMeL72a7Hkd+x/Mg9O2/0rD54Pg== +postcss-colormin@^5.3.1: + version "5.3.1" + resolved "https://registry.yarnpkg.com/postcss-colormin/-/postcss-colormin-5.3.1.tgz#86c27c26ed6ba00d96c79e08f3ffb418d1d1988f" + integrity sha512-UsWQG0AqTFQmpBegeLLc1+c3jIqBNB0zlDGRWR+dQ3pRKJL1oeMzyqmH3o2PIfn9MBdNrVPWhDbT769LxCTLJQ== dependencies: - browserslist "^4.16.6" + browserslist "^4.21.4" caniuse-api "^3.0.0" colord "^2.9.1" postcss-value-parser "^4.2.0" @@ -5766,10 +6205,10 @@ postcss-merge-longhand@^5.1.7: postcss-value-parser "^4.2.0" stylehacks "^5.1.1" -postcss-merge-rules@^5.1.3: - version "5.1.3" - resolved "https://registry.yarnpkg.com/postcss-merge-rules/-/postcss-merge-rules-5.1.3.tgz#8f97679e67cc8d08677a6519afca41edf2220894" - integrity sha512-LbLd7uFC00vpOuMvyZop8+vvhnfRGpp2S+IMQKeuOZZapPRY4SMq5ErjQeHbHsjCUgJkRNrlU+LmxsKIqPKQlA== +postcss-merge-rules@^5.1.4: + version "5.1.4" + resolved "https://registry.yarnpkg.com/postcss-merge-rules/-/postcss-merge-rules-5.1.4.tgz#2f26fa5cacb75b1402e213789f6766ae5e40313c" + integrity sha512-0R2IuYpgU93y9lhVbO/OylTtKMVcHb67zjWIfCiKR9rWL3GUk1677LAqD/BcHizukdZEjT8Ru3oHRoAYoJy44g== dependencies: browserslist "^4.21.4" caniuse-api "^3.0.0" @@ -5914,10 +6353,10 @@ postcss-reduce-idents@^5.2.0: dependencies: postcss-value-parser "^4.2.0" -postcss-reduce-initial@^5.1.1: - version "5.1.1" - resolved "https://registry.yarnpkg.com/postcss-reduce-initial/-/postcss-reduce-initial-5.1.1.tgz#c18b7dfb88aee24b1f8e4936541c29adbd35224e" - integrity sha512-//jeDqWcHPuXGZLoolFrUXBDyuEGbr9S2rMo19bkTIjBQ4PqkaO+oI8wua5BOUxpfi97i3PCoInsiFIEBfkm9w== +postcss-reduce-initial@^5.1.2: + version "5.1.2" + resolved "https://registry.yarnpkg.com/postcss-reduce-initial/-/postcss-reduce-initial-5.1.2.tgz#798cd77b3e033eae7105c18c9d371d989e1382d6" + integrity sha512-dE/y2XRaqAi6OvjzD22pjTUQ8eOfc6m/natGHgKFBK9DxFmIm69YmaRVQrGgFlEfc1HePIurY0TmDeROK05rIg== dependencies: browserslist "^4.21.4" caniuse-api "^3.0.0" @@ -6082,9 +6521,9 @@ punycode@^1.3.2: integrity sha512-jmYNElW7yvO7TV33CjSmvSiE2yco3bV2czu/OzDKdMNVZQWfxCblURLhf+47syQRBntjfLdd/H0egrzIG+oaFQ== punycode@^2.1.0: - version "2.2.0" - resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.2.0.tgz#2092cc57cd2582c38e4e7e8bb869dc8d3148bc74" - integrity sha512-LN6QV1IJ9ZhxWTNdktaPClrNfp8xdSAYS0Zk2ddX7XsXZAxckMHPCBcHRo0cTcEIgYPRiGEkmji3Idkh2yFtYw== + version "2.3.0" + resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.3.0.tgz#f67fa67c94da8f4d0cfff981aee4118064199b8f" + integrity sha512-rRV+zQD8tVFys26lAGR9WUuS4iUAngJScM+ZRSKtvl5tKeZ2t5bvdNFdNHBW9FWR4guGHlgmsZ1G7BSm2wTbuA== pupa@^2.1.1: version "2.1.1" @@ -6208,7 +6647,7 @@ react-error-overlay@^6.0.11: resolved "https://registry.yarnpkg.com/react-error-overlay/-/react-error-overlay-6.0.11.tgz#92835de5841c5cf08ba00ddd2d677b6d17ff9adb" integrity sha512-/6UZ2qgEyH2aqzYZgQPxEnz33NJ2gNsnHA2o5+o4wW9bLM/JYQitNP9xPhsXwC08hMMovfGe/8retsdDsczPRg== -react-fast-compare@^3.2.0: +react-fast-compare@^3.0.1, react-fast-compare@^3.2.0: version "3.2.0" resolved "https://registry.yarnpkg.com/react-fast-compare/-/react-fast-compare-3.2.0.tgz#641a9da81b6a6320f270e89724fb45a0b39e43bb" integrity sha512-rtGImPZ0YyLrscKI9xTpV8psd6I8VAtjKCzQDlzyDvqJA8XOW78TXYQwNRNd8g8JZnDu8q9Fu/1v4HPAVwVdHA== @@ -6256,6 +6695,17 @@ react-loadable-ssr-addon-v5-slorber@^1.0.1: dependencies: "@babel/runtime" "^7.10.3" +react-player@^2.12.0: + version "2.12.0" + resolved "https://registry.yarnpkg.com/react-player/-/react-player-2.12.0.tgz#2fc05dbfec234c829292fbca563b544064bd14f0" + integrity sha512-rymLRz/2GJJD+Wc01S7S+i9pGMFYnNmQibR2gVE3KmHJCBNN8BhPAlOPTGZtn1uKpJ6p4RPLlzPQ1OLreXd8gw== + dependencies: + deepmerge "^4.0.0" + load-script "^1.0.0" + memoize-one "^5.1.1" + prop-types "^15.7.2" + react-fast-compare "^3.0.1" + react-router-config@^5.1.1: version "5.1.1" resolved "https://registry.yarnpkg.com/react-router-config/-/react-router-config-5.1.1.tgz#0f4263d1a80c6b2dc7b9c1902c9526478194a988" @@ -6319,9 +6769,9 @@ react@^17.0.2: object-assign "^4.1.1" readable-stream@^2.0.1: - version "2.3.7" - resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.3.7.tgz#1eca1cf711aef814c04f62252a36a62f6cb23b57" - integrity sha512-Ebho8K4jIbHAxnuxi7o42OrZgF/ZTNcsZj6nRKyUmkhLFq8CHItp/fy6hQZuZmP/n3yZ9VBUbp4zz/mX8hmYPw== + version "2.3.8" + resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.3.8.tgz#91125e8042bba1b9887f49345f6277027ce8be9b" + integrity sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA== dependencies: core-util-is "~1.0.0" inherits "~2.0.3" @@ -6331,7 +6781,16 @@ readable-stream@^2.0.1: string_decoder "~1.1.1" util-deprecate "~1.0.1" -readable-stream@^3.0.6, readable-stream@^3.1.1, readable-stream@^3.4.0: +readable-stream@^3.0.6: + version "3.6.1" + resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-3.6.1.tgz#f9f9b5f536920253b3d26e7660e7da4ccff9bb62" + integrity sha512-+rQmrWMYGA90yenhTYsLWAsLsqVC8osOw6PKE1HDYiO0gdPeKe/xDHNzIAIn4C91YQ6oenEhfYqqc1883qHbjQ== + dependencies: + inherits "^2.0.3" + string_decoder "^1.1.1" + util-deprecate "^1.0.1" + +readable-stream@^3.1.1, readable-stream@^3.4.0: version "3.6.0" resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-3.6.0.tgz#337bbda3adc0706bd3e024426a286d4b4b2c9198" integrity sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA== @@ -6390,14 +6849,14 @@ regenerator-transform@^0.15.1: dependencies: "@babel/runtime" "^7.8.4" -regexpu-core@^5.2.1: - version "5.2.2" - resolved "https://registry.yarnpkg.com/regexpu-core/-/regexpu-core-5.2.2.tgz#3e4e5d12103b64748711c3aad69934d7718e75fc" - integrity sha512-T0+1Zp2wjF/juXMrMxHxidqGYn8U4R+zleSJhX9tQ1PUsS8a9UtYfbsF9LdiVgNX3kiX8RNaKM42nfSgvFJjmw== +regexpu-core@^5.3.1: + version "5.3.1" + resolved "https://registry.yarnpkg.com/regexpu-core/-/regexpu-core-5.3.1.tgz#66900860f88def39a5cb79ebd9490e84f17bcdfb" + integrity sha512-nCOzW2V/X15XpLsK2rlgdwrysrBq+AauCn+omItIz4R1pIcmeot5zvjdmOBRLzEH/CkC6IxMJVmxDe3QcMuNVQ== dependencies: + "@babel/regjsgen" "^0.8.0" regenerate "^1.4.2" regenerate-unicode-properties "^10.1.0" - regjsgen "^0.7.1" regjsparser "^0.9.1" unicode-match-property-ecmascript "^2.0.0" unicode-match-property-value-ecmascript "^2.1.0" @@ -6416,11 +6875,6 @@ registry-url@^5.0.0: dependencies: rc "^1.2.8" -regjsgen@^0.7.1: - version "0.7.1" - resolved "https://registry.yarnpkg.com/regjsgen/-/regjsgen-0.7.1.tgz#ee5ef30e18d3f09b7c369b76e7c2373ed25546f6" - integrity sha512-RAt+8H2ZEzHeYWxZ3H2z6tF18zyyOnlcdaafLrm21Bguj7uZy6ULibiAFdXEtKQY4Sy7wDTwDiOazasMLc4KPA== - regjsparser@^0.9.1: version "0.9.1" resolved "https://registry.yarnpkg.com/regjsparser/-/regjsparser-0.9.1.tgz#272d05aa10c7c1f67095b1ff0addae8442fc5709" @@ -6589,6 +7043,11 @@ rimraf@^3.0.2: dependencies: glob "^7.1.3" +robust-predicates@^3.0.0: + version "3.0.1" + resolved "https://registry.yarnpkg.com/robust-predicates/-/robust-predicates-3.0.1.tgz#ecde075044f7f30118682bd9fb3f123109577f9a" + integrity sha512-ndEIpszUHiG4HtDsQLeIuMvRsDnn8c8rYStabochtUeCvfuvNptb5TUbVD68LRAILPX7p9nqQGh4xJgn3EHS/g== + rtl-detect@^1.0.4: version "1.0.4" resolved "https://registry.yarnpkg.com/rtl-detect/-/rtl-detect-1.0.4.tgz#40ae0ea7302a150b96bc75af7d749607392ecac6" @@ -6611,6 +7070,11 @@ run-parallel@^1.1.9: dependencies: queue-microtask "^1.2.2" +rw@1: + version "1.3.3" + resolved "https://registry.yarnpkg.com/rw/-/rw-1.3.3.tgz#3f862dfa91ab766b14885ef4d01124bfda074fb4" + integrity sha512-PdhdWy89SiZogBLaw42zdeqtRJ//zFd2PgQavcICDUgJT5oW10QCRKbJ6bg4r0/UY2M6BWd5tkxuGFRvCkgfHQ== + rxjs@^7.5.4: version "7.8.0" resolved "https://registry.yarnpkg.com/rxjs/-/rxjs-7.8.0.tgz#90a938862a82888ff4c7359811a595e14e1e09a4" @@ -6628,7 +7092,7 @@ safe-buffer@5.2.1, safe-buffer@>=5.1.0, safe-buffer@^5.0.1, safe-buffer@^5.1.0, resolved "https://registry.yarnpkg.com/safe-buffer/-/safe-buffer-5.2.1.tgz#1eaf9fa9bdb1fdd4ec75f58f9cdb4e6b7827eec6" integrity sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ== -"safer-buffer@>= 2.1.2 < 3": +"safer-buffer@>= 2.1.2 < 3", "safer-buffer@>= 2.1.2 < 3.0.0": version "2.1.2" resolved "https://registry.yarnpkg.com/safer-buffer/-/safer-buffer-2.1.2.tgz#44fa161b0187b9549dd84bb91802f9bd8385cd6a" integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg== @@ -6844,9 +7308,9 @@ shebang-regex@^3.0.0: integrity sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A== shell-quote@^1.7.3: - version "1.7.4" - resolved "https://registry.yarnpkg.com/shell-quote/-/shell-quote-1.7.4.tgz#33fe15dee71ab2a81fcbd3a52106c5cfb9fb75d8" - integrity sha512-8o/QEhSSRb1a5i7TFR0iM4G16Z0vYB2OQVs4G3aAFXjn3T6yEx8AZxy1PgDF7I00LZHYA3WxaSYIf5e5sAX8Rw== + version "1.8.0" + resolved "https://registry.yarnpkg.com/shell-quote/-/shell-quote-1.8.0.tgz#20d078d0eaf71d54f43bd2ba14a1b5b9bfa5c8ba" + integrity sha512-QHsz8GgQIGKlRi24yFc6a6lN69Idnx634w49ay6+jA5yFh7a1UY+4Rp6HPx/L/1zcEDPEij8cIsiqR6bQsE5VQ== shelljs@^0.8.5: version "0.8.5" @@ -7017,9 +7481,9 @@ statuses@2.0.1: integrity sha512-OpZ3zP+jT1PI7I8nemJX4AKmAX070ZkYPVWV/AaKTJl+tXCTGyVdC1a4SL8RUQYEwk/f34ZX8UTykN68FwrqAA== std-env@^3.0.1: - version "3.3.1" - resolved "https://registry.yarnpkg.com/std-env/-/std-env-3.3.1.tgz#93a81835815e618c8aa75e7c8a4dc04f7c314e29" - integrity sha512-3H20QlwQsSm2OvAxWIYhs+j01MzzqwMwGiiO1NQaJYZgJZFPuAbf95/DiKRBSTYIJ2FeGUc+B/6mPGcWP9dO3Q== + version "3.3.2" + resolved "https://registry.yarnpkg.com/std-env/-/std-env-3.3.2.tgz#af27343b001616015534292178327b202b9ee955" + integrity sha512-uUZI65yrV2Qva5gqE0+A7uVAvO40iPo6jGhs7s8keRfHCmtg+uB2X6EiLGCI9IgL1J17xGhvoOqSz79lzICPTA== string-width@^4.0.0, string-width@^4.1.0, string-width@^4.2.0, string-width@^4.2.2: version "4.2.3" @@ -7111,6 +7575,11 @@ stylehacks@^5.1.1: browserslist "^4.21.4" postcss-selector-parser "^6.0.4" +stylis@^4.1.2: + version "4.1.3" + resolved "https://registry.yarnpkg.com/stylis/-/stylis-4.1.3.tgz#fd2fbe79f5fed17c55269e16ed8da14c84d069f7" + integrity sha512-GP6WDNWf+o403jrEp9c5jibKavrtLW+/qYGhFxFrG8maXhwTBI7gLLhiBb0o7uFccWN+EOS9aMO6cGHWAO07OA== + supports-color@^5.3.0: version "5.5.0" resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-5.5.0.tgz#e2e69a44ac8772f78a1ec0b35b689df6530efc8f" @@ -7198,9 +7667,9 @@ terser-webpack-plugin@^5.1.3, terser-webpack-plugin@^5.3.3: terser "^5.14.1" terser@^5.10.0, terser@^5.14.1: - version "5.16.1" - resolved "https://registry.yarnpkg.com/terser/-/terser-5.16.1.tgz#5af3bc3d0f24241c7fb2024199d5c461a1075880" - integrity sha512-xvQfyfA1ayT0qdK47zskQgRZeWLoOQ8JQ6mIgRGVNwZKdQMU+5FkCBjmv4QjcrTzyZquRw2FVtlJSRUmMKQslw== + version "5.16.5" + resolved "https://registry.yarnpkg.com/terser/-/terser-5.16.5.tgz#1c285ca0655f467f92af1bbab46ab72d1cb08e5a" + integrity sha512-qcwfg4+RZa3YvlFh0qjifnzBHjKGNbtDo9yivMqMFDy9Q6FSaQWSB/j1xKhsoUFJIqDOM3TsN6D5xbrMrFcHbg== dependencies: "@jridgewell/source-map" "^0.3.2" acorn "^8.5.0" @@ -7274,10 +7743,15 @@ trough@^1.0.0: resolved "https://registry.yarnpkg.com/trough/-/trough-1.0.5.tgz#b8b639cefad7d0bb2abd37d433ff8293efa5f406" integrity sha512-rvuRbTarPXmMb79SmzEp8aqXNKcK+y0XaB298IXueQ8I2PsrATcPBCSPyK/dDNa2iWOhKlfNnOjdAOTBU/nkFA== +ts-dedent@^2.2.0: + version "2.2.0" + resolved "https://registry.yarnpkg.com/ts-dedent/-/ts-dedent-2.2.0.tgz#39e4bd297cd036292ae2394eb3412be63f563bb5" + integrity sha512-q5W7tVM71e2xjHZTlgfTDoPF/SmqKG5hddq9SzR49CH2hayqRKJtQ4mtRlSxKaJlR/+9rEM+mnBHf7I2/BQcpQ== + tslib@^2.0.3, tslib@^2.1.0, tslib@^2.4.0: - version "2.4.1" - resolved "https://registry.yarnpkg.com/tslib/-/tslib-2.4.1.tgz#0d0bfbaac2880b91e22df0768e55be9753a5b17e" - integrity sha512-tGyy4dAjRIEwI7BzsB0lynWgOpfqjUdq91XXAlIWD2OwKBH7oCl/GZG/HT4BOHrTlPMOASlMQ7veyTqpmRcrNA== + version "2.5.0" + resolved "https://registry.yarnpkg.com/tslib/-/tslib-2.5.0.tgz#42bfed86f5787aeb41d031866c8f402429e0fddf" + integrity sha512-336iVw3rtn2BUK7ORdIAHTyxHGRIHVReokCR3XjbckJMK7ms8FysBfhLR8IXnAgy7T0PTPNBWKiH514FOW/WSg== tunnel-agent@^0.6.0: version "0.6.0" @@ -7458,7 +7932,7 @@ unpipe@1.0.0, unpipe@~1.0.0: resolved "https://registry.yarnpkg.com/unpipe/-/unpipe-1.0.0.tgz#b2bf4ee8514aae6165b4817829d21b2ef49904ec" integrity sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ== -update-browserslist-db@^1.0.9: +update-browserslist-db@^1.0.10: version "1.0.10" resolved "https://registry.yarnpkg.com/update-browserslist-db/-/update-browserslist-db-1.0.10.tgz#0f54b876545726f17d00cd9a2561e6dade943ff3" integrity sha512-OztqDenkfFkbSG+tRxBeAnCVPckDBcvibKd35yDONx6OU8N7sqgwc7rCbkJ/WcYtVRZ4ba68d6byhC21GFh7sQ== @@ -7526,6 +8000,11 @@ use-latest@^1.2.1: dependencies: use-isomorphic-layout-effect "^1.1.1" +use-sync-external-store@^1.2.0: + version "1.2.0" + resolved "https://registry.yarnpkg.com/use-sync-external-store/-/use-sync-external-store-1.2.0.tgz#7dbefd6ef3fe4e767a0cf5d7287aacfb5846928a" + integrity sha512-eEgnFxGQ1Ife9bzYs6VLi8/4X6CObHMw9Qr9tPY43iKwsPw8xE8+EFsf/2cFZ5S3esXgpWgtSCtLNS41F+sKPA== + util-deprecate@^1.0.1, util-deprecate@^1.0.2, util-deprecate@~1.0.1: version "1.0.2" resolved "https://registry.yarnpkg.com/util-deprecate/-/util-deprecate-1.0.2.tgz#450d4dc9fa70de732762fbd2d4a28981419a0ccf" @@ -7551,6 +8030,11 @@ uuid@^8.3.2: resolved "https://registry.yarnpkg.com/uuid/-/uuid-8.3.2.tgz#80d5b5ced271bb9af6c445f21a1a04c606cefbe2" integrity sha512-+NYs2QeMWy+GWFOEm9xnn6HCDp0l7QBD7ml8zLUmJ+93Q5NF0NocErnwkTkXVFNiX3/fpC6afS8Dhb/gz7R7eg== +uuid@^9.0.0: + version "9.0.0" + resolved "https://registry.yarnpkg.com/uuid/-/uuid-9.0.0.tgz#592f550650024a38ceb0c562f2f6aa435761efb5" + integrity sha512-MXcSTerfPa4uqyzStbRoTgt5XIe3x5+42+q1sDuy3R5MDk66URdLMOZe5aPX/SQd+kuYAh0FdP/pO28IkQyTeg== + value-equal@^1.0.1: version "1.0.1" resolved "https://registry.yarnpkg.com/value-equal/-/value-equal-1.0.1.tgz#1e0b794c734c5c0cade179c437d356d931a34d6c" @@ -7615,16 +8099,22 @@ web-namespaces@^1.0.0: resolved "https://registry.yarnpkg.com/web-namespaces/-/web-namespaces-1.1.4.tgz#bc98a3de60dadd7faefc403d1076d529f5e030ec" integrity sha512-wYxSGajtmoP4WxfejAPIr4l0fVh+jeMXZb08wNc0tMg6xsfZXj3cECqIK0G7ZAqUq0PP8WlMDtaOGVBTAWztNw== +web-worker@^1.2.0: + version "1.2.0" + resolved "https://registry.yarnpkg.com/web-worker/-/web-worker-1.2.0.tgz#5d85a04a7fbc1e7db58f66595d7a3ac7c9c180da" + integrity sha512-PgF341avzqyx60neE9DD+XS26MMNMoUQRz9NOZwW32nPQrF6p77f1htcnjBSEV8BGMKZ16choqUG4hyI0Hx7mA== + webidl-conversions@^3.0.0: version "3.0.1" resolved "https://registry.yarnpkg.com/webidl-conversions/-/webidl-conversions-3.0.1.tgz#24534275e2a7bc6be7bc86611cc16ae0a5654871" integrity sha512-2JAn3z8AR6rjK8Sm8orRC0h/bcl/DqL7tRPdGZ4I1CjdF+EaMLmYxBHyXuKL849eucPFhvBoxMsflfOb8kxaeQ== webpack-bundle-analyzer@^4.5.0: - version "4.7.0" - resolved "https://registry.yarnpkg.com/webpack-bundle-analyzer/-/webpack-bundle-analyzer-4.7.0.tgz#33c1c485a7fcae8627c547b5c3328b46de733c66" - integrity sha512-j9b8ynpJS4K+zfO5GGwsAcQX4ZHpWV+yRiHDiL+bE0XHJ8NiPYLTNVQdlFYWxtpg9lfAQNlwJg16J9AJtFSXRg== + version "4.8.0" + resolved "https://registry.yarnpkg.com/webpack-bundle-analyzer/-/webpack-bundle-analyzer-4.8.0.tgz#951b8aaf491f665d2ae325d8b84da229157b1d04" + integrity sha512-ZzoSBePshOKhr+hd8u6oCkZVwpVaXgpw23ScGLFpR6SjYI7+7iIWYarjN6OEYOfRt8o7ZyZZQk0DuMizJ+LEIg== dependencies: + "@discoveryjs/json-ext" "0.5.7" acorn "^8.0.4" acorn-walk "^8.0.0" chalk "^4.1.0" @@ -7695,9 +8185,9 @@ webpack-sources@^3.2.2, webpack-sources@^3.2.3: integrity sha512-/DyMEOrDgLKKIG0fmvtz+4dUX/3Ghozwgm6iPp8KRhvn+eQf9+Q7GWxVNMk3+uCPWfdXYC4ExGBckIXdFEfH1w== webpack@^5.73.0: - version "5.75.0" - resolved "https://registry.yarnpkg.com/webpack/-/webpack-5.75.0.tgz#1e440468647b2505860e94c9ff3e44d5b582c152" - integrity sha512-piaIaoVJlqMsPtX/+3KTTO6jfvrSYgauFVdt8cr9LTHKmcq/AMd4mhzsiP7ZF/PGRNPGA8336jldh9l2Kt2ogQ== + version "5.76.0" + resolved "https://registry.yarnpkg.com/webpack/-/webpack-5.76.0.tgz#f9fb9fb8c4a7dbdcd0d56a98e56b8a942ee2692c" + integrity sha512-l5sOdYBDunyf72HW8dF23rFtWq/7Zgvt/9ftMof71E/yUb1YLOBmTgA2K4vQthB3kotMrSj609txVE0dnr2fjA== dependencies: "@types/eslint-scope" "^3.7.3" "@types/estree" "^0.0.51" @@ -7799,9 +8289,9 @@ wrap-ansi@^7.0.0: strip-ansi "^6.0.0" wrap-ansi@^8.0.1: - version "8.0.1" - resolved "https://registry.yarnpkg.com/wrap-ansi/-/wrap-ansi-8.0.1.tgz#2101e861777fec527d0ea90c57c6b03aac56a5b3" - integrity sha512-QFF+ufAqhoYHvoHdajT/Po7KoXVBPXS2bgjIam5isfWJPfIOnQZ50JtUiVvCv/sjgacf3yRrt2ZKUZ/V4itN4g== + version "8.1.0" + resolved "https://registry.yarnpkg.com/wrap-ansi/-/wrap-ansi-8.1.0.tgz#56dc22368ee570face1b49819975d9b9a5ead214" + integrity sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ== dependencies: ansi-styles "^6.1.0" string-width "^5.0.1" @@ -7828,9 +8318,9 @@ ws@^7.3.1: integrity sha512-F+P9Jil7UiSKSkppIiD94dN07AwvFixvLIj1Og1Rl9GGMuNipJnV9JzjD6XuqmAeiswGvUmNLjr5cFuXwNS77Q== ws@^8.4.2: - version "8.12.0" - resolved "https://registry.yarnpkg.com/ws/-/ws-8.12.0.tgz#485074cc392689da78e1828a9ff23585e06cddd8" - integrity sha512-kU62emKIdKVeEIOIKVegvqpXMSTAMLJozpHZaJNDYqBjzlSYXQGviYwN1osDLJ9av68qHd4a2oSjd7yD4pacig== + version "8.12.1" + resolved "https://registry.yarnpkg.com/ws/-/ws-8.12.1.tgz#c51e583d79140b5e42e39be48c934131942d4a8f" + integrity sha512-1qo+M9Ba+xNhPB+YTWUlK6M17brTut5EXbcBaMRN5pH5dFrXz7lzz1ChFSUq3bOUl8yEvSenhHmYUNJxFzdJew== xdg-basedir@^4.0.0: version "4.0.0"