diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md index 07bb6295451..f8fd5c16f29 100644 --- a/docs/docs/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -35,7 +35,7 @@ Instead of implementing it at the protocol level as in Aztec, account abstractio A simple example would be Gnosis Safe (see [_Account Abstraction is NOT coming_](https://safe.mirror.xyz/9KmZjEbFkmI79s28d9xar6JWYrE50F5AHpa5CR12YGI)), where it's the multisig contract responsibility to define when an execution request is valid by checking it carries N out of M signatures, and then executing it. [Argent](https://www.argent.xyz/blog/wtf-is-account-abstraction/) has also been working on smart wallets for years, and collaborating with network teams to implement AA natively at the protocol layer. -Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://twitter.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts. +Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://x.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts. Implementing AA at the application layer has the main drawback that it's more complex than doing so at the protocol layer. It also leads to duplicated efforts in both layers (eg the wrapper transaction in a meta-transactions still needs to be checked for its ECDSA signature, and then the smart contract wallet needs to verify another set of signatures). diff --git a/docs/docs/aztec/roadmap/cryptography_roadmap.md b/docs/docs/aztec/roadmap/cryptography_roadmap.md deleted file mode 100644 index 4b732f0aa9a..00000000000 --- a/docs/docs/aztec/roadmap/cryptography_roadmap.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Cryptography Roadmap -sidebar_position: 2 ---- - - -The cryptography team is currently working on [Barretenberg here.](https://github.com/AztecProtocol/aztec-packages/tree/master/barretenberg) - -## R&D projects - -Publish the Honk paper, describing practical considerations for constructing our cutting-edge proving system Honk along with formal proofs of its security properties. - -## Honk - -Honk is a sumcheck-based zk-SNARK protocol with blazing-fast zk proof construction. We need Honk to allow users to prove correct execution of complicated, multi-step computations using recursion in a resource constraint environment like a cell phone. This is necessary for our mission, because we need to make sure our users' sensitive information never leaves their devices! - -List of Honk projects: - -- Completed: basic Honk prover and verifier with respectable construction and verification speeds, but no optimization. -- Upcoming: - - Bringing "Ultra" functionality to Honk: lookup tables, efficient range constraints, RAM, ROM, and more will result in orders-of-magnitude improvements to Honk's prover times. - - Recursion using cycles of curves will allow for efficient recursive verification of Honk proofs. Using this technique will lower the barrier to entry of our rollup providers, resulting in a more robust set of providers and greater security for the Aztec network. - -## Goblin projects - -Goblin is a deferred verification framework that allows for an order-of-magnitude increase in the complexity of computations that Aztec users can execute with full privacy. This corresponds to a 10x increase in the expressivity of Noir programs that can be run in practice without melting anybody's favorite phone or laptop. Read more [here](https://hackmd.io/@aztec-network/B19AA8812). diff --git a/docs/docs/aztec/roadmap/engineering_roadmap.md b/docs/docs/aztec/roadmap/engineering_roadmap.md deleted file mode 100644 index 14b1431f6b1..00000000000 --- a/docs/docs/aztec/roadmap/engineering_roadmap.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: Engineering Roadmap -sidebar_position: 1 ---- - -The engineering roadmap is long. There are no timings assigned here. In a loose priority order: - -## Sandbox Community Support - -- Triage on discord / discourse / github. -- Iterating on the docs and code, given people's issues. -- Encouraging contributions to 'good first issue' issues. -- Release notes. -- Versioning. -- Aztec Improvement Proposals (AZIPs) -- Aztec Requests for Comment (AZRCs) - -## Benchmarking - -- Gather metrics about everything, to guide future decisions. - -## Standardization efforts - -- Recommended Aztec smart contract coding patterns -- Access Control (whitelists/blacklists) - probably needs the Shared Mutable. -- Basic _example_ private tokens - - Including recursive calls to 'get_notes'. -- Compliant private tokens -- Private NFTs -- Public tokens -- Depositing and withdrawing tokens - - L1\<\>L2 - - public\<\>private -- The Aztec Connect bridging pattern -- Using Keys (the fully-featured version of keys that we want to build) -- Plume nullifiers -- Negative reputation example -- Anti-denial-of-service -- Combining Aztec with MPC - -## Polishing what we have - -- Refactoring sprints. - - Reduce tech debt. - - More tests. - -## Enforcing correct ordering Public & Private State Transitions - -## Enforcing correct ordering of other 'side effects' - -- Log ordering -- Enqueued public function calls - -## What data actually needs to be submitted on-chain? - -- For Public Functions: - - Just emit the initially-enqueued public function request data? (The 'inputs' of the tx); - - I.e. contract address, function selector, args, call_context. - - OR, Just emit the final state transitions? (The 'outputs' of the tx) - - I.e. the leaf indices and new values of the public data tree; and the new note hashes/nullifiers of the note hash tree; and logs; and l2->L1 messages. - -## Proper specs - -- Write detailed specs, given recent protocol changes. -- Review the code to ensure it matches what we _think_ the protocol is. -- Open issues to ensure the code matches the spec. -- (Note: bringing cryptographers into the fold (to review specs) is a separate section, later in this doc). - -## Iterate on the Sandbox - -Based on community feedback, we'll need some teams to iterate on Sandbox features and fix bugs. - -## Iterate on the Aztec Smart Contract Library - -## Iterating on CI - -CI takes up a significant amount of time. It gets its own section here, so we remember it exists. - -## Sequencer & Prover Selection protocols - -- Decide on protocol -- Spec -- Build. - -## Upgradeability - -- Decide on protocol -- Spec -- Build. - -## Fees - -- Design the Protocol - - Interdependence on the Sequencer & Upgradeability protocols. - - Pay fees in 1 currency, or fee abstraction? - - Escrowing fees - - Rebates - - L1->L2 message fees. - - L2->L1 fees - - Etc. -- Build it. - - Gas metering - - Etc. - -## Note Discovery - -- Note Discovery RFP -- Decide on the protocol -- Spec -- Build it. - -## Privacy-preserving queries to public nodes - -- Explore PIR -- Explore alternatives -- Implement - -## Keys - -- Write up keys spec -- Get internal comments -- Do a RFC from the external community -- Implement - -## Shared Mutable State - -We _need_ a way to read mutable public data from a private function. We are moving away from the old Slow Updates Tree in favor of [Shared Mutable](../../reference/developer_references/smart_contract_reference/storage/shared_state.md#sharedmutable). - -## Contract classes and instances? - -- There's a suggestion to introduce contract classes. - -## Delegatecalls vs SetCode - -- Which? (if at all) - -## Remove the contracts tree? 🤯 - -- There's a suggestion to remove the notion of a contracts tree. What do we actually need the tree for? To check that a vk hash exists for a particular contract address? -- If the contract address contains the function tree, and it also contains data about the constructor args to that contract, then perhaps we don't need the contract tree to exist. -- We might still need the notion of a 'deployment': - - to broadcast a contract's bytecode; - - to 'reserve' a contract address; - - and possibly to prevent a constructor from being executed twice (although an app could do this ("constructor abstraction")). - -## Cryptography review checkpoint - -- Once we have specs (see above), we should review the rigour and secureness to our protocol. - - Choice of hashes - - Domain separation - - Choice of encryption scheme - - Keys - - A security review of the protocol as a whole - -## Testing UX team - -A team focussed on testing and debugging UX. -This team should have free rein to design and add any features they see fit. - -Some example features: - -- Writing contract tests in Noir. - - Mocking oracles. -- Taking inspiration from other testing frameworks. -- Much more detailed logging if things go wrong. -- Errors which only spit out opaque 254-bit hex numbers are bad. - - Ensure all circuits are fed the human-readable information underlying all of these hex numbers. - - If tree root comparisons (expected vs actual) fail, human-readable details about the leaves in trees should be provided. - -## Tooling - -## Proper Circuits - -### Redesign - -- The Bus - - The bus will have an impact on the way we design the circuit logic. - - We can hopefully avoid hashing in circuit 1 and unpacking that hash in circuit 2. - - Understand the 'bus' and how we can use it to pass variable amounts of data between recursive circuit iterations. - - Redesign all circuit logic to allow for the variable-sized arrays that the 'bus' enables. -- Enable 'dynamic/variable-sized **loops**' - - allow each `for` loop (eg read requests, insertions, commitment squashing, call stack processing, bip32 key derivation, etc.) to vary in size, by deferring each loop to its own final circuit. This would require complex folding stuff. - - This would give much more flexibility over the sizes of various arrays that a circuit can output. Without it, if one array of an app circuit needs to be size 2000, but other arrays aren't used, we'd use a kernel where every array is size 2048, meaning a huge amount of unnecessary loops of computation for those empty arrays. -- Improvements - - We can definitely change how call stacks are processed within a kernel, to reduce hashing. - - Squash pending note hashes/nullifiers in every kernel iteration, to enable a deeper nested call depth. -- Topology of a rollup - - Revisit the current topology: - - We can make the rollup trees 'wonky' (rather than balanced), meaning a sequencer doesn't need to prove a load of pointless 'padding' proofs? - - This would also enable new txs (entering the tx pool) to be added to a rollup block 'on-the-fly' (mid way through a rollup being proven) - but of course, the sequencer selection protocol might require an up-front commitment, so this might not be possible for that reason (sad face). - - We can definitely redesign the public kernel circuit to be a '2x2' topology (i.e. a tree of public kernel proofs), to get a logarithmic speed-up (parallelism). The question is, with folding schemes, do we need that optimization? - -#### Refactor of packing & unpacking data in circuits - -We often pack data in circuit A, and then unpack it again in circuit B. - -- args_hash -- return_values_hash -- call stacks -- read requests -- etc. - -Also, for logs in particular, we allow arbitrary-sized logs. But this requires sha256 packing inside an app circuit (which is slow) (and sha256 unpacking in Solidity (which is relatively cheap)). Perhaps we also use the bus ideas for logs, to give _some_ variability in log length, but up to an upper bound. - -Also, we do a lot of sha256-compressing in our kernel and rollup circuits for data which must be checked on-chain, but grows exponentially with every round of iteration. E.g.: new contract deployment data, new nullifiers, new note hashes, public state transition data, etc. This might be unavoidable. Maybe all we can do is use polynomial commitments when the EIP-4844 work is done. But maybe we can use the bus for this stuff too. - -### Write proper circuits - -### The Public VM Circuit - -- Design it -- Build it - -### The Brillig Bytecode Commitment Circuit - -- A circuit which proves the brillig bytecode being emitted matches the polynomial commitment to that bytecode. - -### Decide on constants! - -### Honk -> Ultra Squisher Circuit - -### Ultra -> Standard Squisher Circuit - -## Authentication: access to private data - -- Private data must not be returned to an app, unless the user authorizes it. - -## Validation: preventing execution of malicious bytecode - -- A node should check that the bytecode provided by an application for a given app matches the leaf in the contract tree to ensure that user doesn't execute unplanned code which might access their notes. - -## Fuzz Testing - -## Formal Verification - -An investigation into how formal verification techniques might improve the security of Aztec software. - -## P2P network - -- A robust p2p network for the tx pool and the proof pool. - -## Hashes - -- An improved, standardized Pedersen hash in barretenberg. -- Poseidon hashing in barretenberg. - -## Tree epochs - -- Nullifier tree epochs -- Maybe other tree epochs. - -## Chaining txs - -- We have the ability to spend pending notes (which haven't-yet been added to the tree) _within the context of a single tx_. -- We need the ability to spend pending notes (which haven't yet been added to the tree) across different txs, within the context of a single rollup. - - This happens if Alice generates two txs X & Y, where tx Y spends notes from tx X. If we want Alice to be able to generate these txs in parallel (without interacting with the network at all), we need a way for tx Y to spend notes before they've been added to the tree. The 'chaining tx' concepts from Aztec Connect can enable this. -- This added _a lot_ of complexity to Aztec Connect. Especially around fees, iirc. Caution needed. - -## EIP-4844 - -- Understand it. Spec it. Build it. -- Includes: - - Smart Contract changes - - Circuit changes - - A circuit to prove equivalence vs a BLS12-381 polynomial commitment. - -## Make it all work in a browser - -## Code Freeze - -## Internal Audit - -## External Audits diff --git a/docs/docs/protocol-specs/cryptography/proving-system/overview.md b/docs/docs/protocol-specs/cryptography/proving-system/overview.md index 74e1c7306e5..c7d1ce69d07 100644 --- a/docs/docs/protocol-specs/cryptography/proving-system/overview.md +++ b/docs/docs/protocol-specs/cryptography/proving-system/overview.md @@ -90,7 +90,7 @@ When passing data between successive IVC steps, the canonical method is to do so The Data Bus protocol eliminates this cost by representing cross-step data via succinct commitments instead of raw field elements. -The [Plonk Data Bus](https://aztecprotocol.slack.com/files/U8Q1VAX6Y/F05G2B971FY/plonk_bus.pdf) protocol enables efficient data transfer between two Honk instances within a larger IVC protocol. +The Plonk Data Bus protocol enables efficient data transfer between two Honk instances within a larger IVC protocol. # Polynomial Commitment Schemes diff --git a/docs/docs/protocol-specs/data-publication-and-availability/overview.md b/docs/docs/protocol-specs/data-publication-and-availability/overview.md index 1a1bba6b76f..ca46010fc15 100644 --- a/docs/docs/protocol-specs/data-publication-and-availability/overview.md +++ b/docs/docs/protocol-specs/data-publication-and-availability/overview.md @@ -30,7 +30,7 @@ From distributed systems, the _security_ of a protocol or system is defined by: ::: In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node. -For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)): +For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://x.com/sreeramkannan/status/1683735050897207296)): - **Liveness**: - Data Availability - The chain data must be available for anyone to reconstruct the state and build blocks @@ -318,5 +318,5 @@ Of these, Celestia has the current best "out-the-box" solution, but Eigen-da and - https://forum.celestia.org/t/security-levels-for-data-availability-for-light-nodes/919 - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 - https://jumpcrypto.com/writing/bridging-and-finality-ethereum/ -- https://twitter.com/sreeramkannan/status/1683735050897207296 +- https://x.com/sreeramkannan/status/1683735050897207296 - https://blog.celestia.org/introducing-blobstream/ diff --git a/docs/docs/reference/developer_references/limitations.md b/docs/docs/reference/developer_references/limitations.md index cb13ddf4779..60c659119c2 100644 --- a/docs/docs/reference/developer_references/limitations.md +++ b/docs/docs/reference/developer_references/limitations.md @@ -54,7 +54,7 @@ That's right, the Sandbox doesn't actually generate or verify any zk-SNARKs yet! The main goal of the Sandbox is to enable developers to experiment with building apps, and hopefully to provide feedback. We want the developer experience to be as fast as possible, much like how Ethereum developers use Ganache or Anvil to get super-fast block times, instead of the slow-but-realistic 12-second block times that they'll encounter in production. A fast Sandbox enables fast testing, which enables developers to iterate quickly. -That's not to say a super-fast proving system isn't being worked on [as we speak](../../aztec/roadmap/cryptography_roadmap.md). +That's not to say a super-fast proving system isn't being worked on as we speak. #### What are the consequences? diff --git a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md index 2c7953a8dae..198c1a3dfc2 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md @@ -195,7 +195,7 @@ Copy the last function into your Crowdfunding contract: You should be able to compile successfully with `aztec-nargo compile`. -**Congraulations,** you have just built a multi-contract project on Aztec! +**Congratulations,** you have just built a multi-contract project on Aztec! ## Conclusion diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index f46a98abadf..fd5215f99a5 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -290,14 +290,14 @@ const config = { { type: "docSidebar", sidebarId: "protocolSpecSidebar", - target: "_blank", label: "Protocol Specification", + className: "no-external-icon", }, { type: "docSidebar", sidebarId: "roadmapSidebar", - target: "_blank", label: "Roadmap", + className: "no-external-icon", }, { to: "https://noir-lang.org/docs", @@ -317,7 +317,7 @@ const config = { rel: "noopener noreferrer", }, { - to: "https://twitter.com/aztecprotocol", + to: "https://x.com/aztecnetwork", label: "X/Twitter", target: "_blank", rel: "noopener noreferrer", @@ -359,8 +359,8 @@ const config = { href: "https://discord.gg/DgWG2DBMyB", }, { - label: "X/Twitter", - href: "https://twitter.com/aztecnetwork", + label: "X (Twitter)", + href: "https://x.com/aztecnetwork", }, { label: "Plonk Cafe", diff --git a/docs/netlify.toml b/docs/netlify.toml index c62a3038713..b1fd1528562 100644 --- a/docs/netlify.toml +++ b/docs/netlify.toml @@ -1,14 +1,74 @@ +[[redirects]] + from = "/guides/smart_contracts/writing_contracts/initializers" + to = "/guides/developer_guides/smart_contracts/writing_contracts/initializers" + +[[redirects]] + from = "/reference/aztecjs/accounts" + to = "/reference/developer_references/aztecjs/accounts" + +[[redirects]] + from = "/getting_started" + to = "/guides/developer_guides/getting_started/quickstart" + +[[redirects]] + from = "/tutorials/simple_dapp/*" + to = "/tutorials/codealong/simple_dapp" + +[[redirects]] + from = "/tutorials/simple_dapp" + to = "/tutorials/codealong/simple_dapp" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/depositing_to_aztec" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge" + +[[redirects]] + from = "/tutorials/contract_tutorials/advanced/token_bridge/setup" + to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/setup" + +[[redirects]] + from = "/tutorials/contract_tutorials/crowdfunding_contract" + to = "/tutorials/codealong/contract_tutorials/crowdfunding_contract" + +[[redirects]] + from = "/tutorials/contract_tutorials/private_voting_contract" + to = "/tutorials/codealong/contract_tutorials/private_voting_contract" + +[[redirects]] + from = "/tutorials/contract_tutorials/token_contract" + to = "/tutorials/codealong/contract_tutorials/token_contract" + +[[redirects]] + from = "/tutorials/*" + to = "/tutorials/codealong/contract_tutorials/private_voting_contract" + [[redirects]] from = "/developers/tutorials/*" to = "/tutorials/codealong/contract_tutorials/private_voting_contract" [[redirects]] from = "/developers/sandbox/*" - to = "/reference/developer_references/sandbox_reference" + to = "/guides/developer_guides/getting_started/quickstart" [[redirects]] from = "/developers/contracts/*" - to = "/reference/developer_references/smart_contract_reference" + to = "/aztec/smart_contracts_overview" [[redirects]] from = "/dev_docs/*" @@ -58,6 +118,14 @@ from = "/compliance" to = "/" +[[redirects]] + from = "/aztec/roadmap/engineering_roadmap" + to = "/" + +[[redirects]] + from = "/aztec/roadmap/cryptography_roadmap" + to = "/" + [[redirects]] from = "/protocol-specs/gas-and-fees/fee-payment-asset" to = "/protocol-specs/gas-and-fees/fee-juice" @@ -68,4 +136,8 @@ [[redirects]] from = "/reference/sandbox_reference/sandbox-reference" + to = "/guides/developer_guides/getting_started/quickstart" + +[[redirects]] + from = "/reference/sandbox_reference" to = "/guides/developer_guides/getting_started/quickstart" \ No newline at end of file diff --git a/docs/src/css/custom.css b/docs/src/css/custom.css index 07c07791dfa..c41961437a4 100644 --- a/docs/src/css/custom.css +++ b/docs/src/css/custom.css @@ -19,6 +19,7 @@ --ifm-link-color: #8C7EFF; --ifm-menu-color-active: #8C7EFF; --ifm-navbar-link-hover-color: #8C7EFF; + --docsearch-modal-background: white; } [data-theme="light"] .alert--danger { @@ -170,24 +171,6 @@ a { color: #8C7EFF; } -/* Style for tip admonitions */ -.admonition-tip { - background-color: rgba(49, 166, 123, 0.1); - border-left-color: #31A67B; -} - -.admonition-tip .admonition-icon svg { - fill: #31A67B; -} - -.admonition-warning, .admonition-danger { - background-color: rgba(255, 119, 100, 0.1); - border-left-color: #FF7764; -} - -.admonition-warning .admonition-icon svg, .admonition-danger .admonition-icon svg { - fill: #FF7764; -} .code-block-error-line { background-color: #f0000038; display: block; @@ -228,7 +211,15 @@ html[data-theme="dark"] .sidebar-divider { } [data-theme="light"] #optout-form { - background: #f6fbfc; + background: white; +} + +[data-theme="light"] .button--secondary{ + background: var(--ifm-color-primary-lightest); +} + +[data-theme="dark"] .button--secondary { + background: var(--ifm-color-primary-dark); } #optout-form { @@ -246,7 +237,7 @@ html[data-theme="dark"] .sidebar-divider { padding: 1.5rem 2rem; display: flex; flex-direction: column; - border: 1px solid #bec2c3; + border: 1px solid var(--ifm-color-primary-lightest); border-radius: 12px; } diff --git a/noir-projects/aztec-nr/authwit/src/auth.nr b/noir-projects/aztec-nr/authwit/src/auth.nr index dd3cbb900f1..0a3c991987a 100644 --- a/noir-projects/aztec-nr/authwit/src/auth.nr +++ b/noir-projects/aztec-nr/authwit/src/auth.nr @@ -62,7 +62,7 @@ use dep::aztec::{prelude::Deserialize, context::{PrivateContext, PublicContext, * contract. Since the `DeFi` contract is trying to pull funds from an account that is not its own, it needs to * convince the `Token` contract that it is allowed to do so. * - * This is where the authentication witness comes in! The `Token` contract computes a `message_hash` from the + * This is where the authentication witness comes in The `Token` contract computes a `message_hash` from the * `transfer` call, and then asks `Alice Account` contract to verify that the `DeFi` contract is allowed to * execute that call. *