feat: yellow paper cross-chain communication #3477

LHerskind · 2023-11-29T17:13:48Z

Fixing #3151.

Adding initial text for yellow paper on cross-chain communication

Checklist:

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

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

rahul-kothari · 2023-11-30T12:39:38Z

yellow-paper/docs/contracts/main.md

+- Sequencer Selection contract(s)
+
+## Registry
+The registry is a contract that holds the addresses of the other contracts. It is a simple contract that keeps track of where the other contracts are, it is to give the nodes a single source of truth for where the other contracts are. Also allows us to handle upgrades.


also stores the versions of the rollup that the contracts correspond to?

rahul-kothari · 2023-11-30T12:40:04Z

yellow-paper/docs/contracts/main.md

+The registry is a contract that holds the addresses of the other contracts. It is a simple contract that keeps track of where the other contracts are, it is to give the nodes a single source of truth for where the other contracts are. Also allows us to handle upgrades.
+
+## State transitioner
+The state transitioner is the contract that handles the state and perform the state transition on L1. It makes sure that the proof is valid and that L1 is updated accordingly.


Suggested change

The state transitioner is the contract that handles the state and perform the state transition on L1. It makes sure that the proof is valid and that L1 is updated accordingly.

The state transitioner is the contract that handles the L2 state and performs the state transition on L1. It makes sure that the proof is valid and that L1 is updated accordingly.

rahul-kothari · 2023-11-30T12:40:37Z

yellow-paper/docs/contracts/main.md

+:::info It is a fully validating light node.
+:::
+
+Whenever a block is received it is to:


Suggested change

Whenever a block is received it is to:

Whenever a block is received it will:

rahul-kothari · 2023-11-30T12:43:27Z

yellow-paper/docs/contracts/main.md

+
+When deploying a contract on L2, it is possible to specify its "portal" address. This is an immutable variable, that can be used to constrain who the L2 contract expect messages from, and who it sends to.
+
+In the current implementation, any messages that are sent from the L2 contract to L1 MUST be sent to the portal address. This was to get around the access control issue of private execution. This is enforced in the kernel.


FWIW The YP isn't about the current impl but rather what needs to be done

It was more to point that in the current paradigm that is the case. Both in implementation and in peoples minds. But guess I should just say paradigm instead in that case 🤷

rahul-kothari · 2023-11-30T12:45:17Z

yellow-paper/docs/contracts/main.md

+description: How the L1 contracts facilitate cross-chain communication
+---
+
+This section are to describe what our L1 contracts do, what each of them are responsible for and how they interact with the circuits. 


Suggested change

This section are to describe what our L1 contracts do, what each of them are responsible for and how they interact with the circuits.

This section describes what our L1 contracts do, what each of them is responsible for and how they interact with the circuits.

rahul-kothari · 2023-11-30T12:46:15Z

yellow-paper/docs/contracts/main.md

+- Blocks and their content have been defined in earlier so we will not go into detail on that here.
+:::
+
+We have multiple contracts, some that exist already, and some that are to be build. The collection of these contracts is called the L1 contracts and it was makes up the rollup precense on L1.  


Suggested change

We have multiple contracts, some that exist already, and some that are to be build. The collection of these contracts is called the L1 contracts and it was makes up the rollup precense on L1.

We have multiple contracts. The collection of these contracts is called the L1 contracts and it makes up the rollup presence on L1.

in YP we don't need to mention what's built and what's still to be built.

rahul-kothari · 2023-11-30T17:21:10Z

yellow-paper/docs/contracts/main.md

+    - - **Circuit:** MUST match the computation of the circuit
+- Validate the proof
+- Update state root to the ending state
+- Consume the L1 to L2 messages specified in the block from the inbox


since an Inbox can be for multiple versions do we add:
Consume the L1 to L2 messages specified in the block from the inbox for the particular version

If the inbox is for multiple version, there is not an inbox for a particular version, its shared. There is just a specific recipient rollup.

rahul-kothari

Don't fully understand the steps under the diagram. Added some comments. Btw Should we talk more about checks in the ciruits related to the L1 to L2 message? Or assume whoever is documenting the circuits will do it?

rahul-kothari · 2023-12-01T12:07:04Z

yellow-paper/docs/contracts/main.md

+While this can be addressed by having a queue of messages and let the sequencer specify the order, this require extra logic and might be difficult to price correctly. To keep this out of protocol, we simply allow the user to attach a fee to the message (see `fee` in `L1ToL2Msg` above). This way, the user can incentivize the sequencer to pick up the message faster.
+
+Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled. 
+


also add that message.content should < 254 bits

Should be contained by the new section Validity Conditions

rahul-kothari · 2023-12-01T12:08:14Z

yellow-paper/docs/contracts/main.md

+This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before a rollup goes through. 
+While this can be addressed by having a queue of messages and let the sequencer specify the order, this require extra logic and might be difficult to price correctly. To keep this out of protocol, we simply allow the user to attach a fee to the message (see `fee` in `L1ToL2Msg` above). This way, the user can incentivize the sequencer to pick up the message faster.
+
+Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled. 


inbox must check that deadline > block.timestamp

Should be contained by the new section Validity Conditions

rahul-kothari · 2023-12-01T12:08:47Z

yellow-paper/docs/contracts/main.md

+
+Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled. 
+
+The contract that sent the message must itself decide how it is to handle the cancellation. It could be that the contract simply ignores the message, or it could be that it refunds the user. This is up to the contract to decide. 


Suggested change

The contract that sent the message must itself decide how it is to handle the cancellation. It could be that the contract simply ignores the message, or it could be that it refunds the user. This is up to the contract to decide.

The contract that sent the message must decide itself how to handle the cancellation. It could be that the contract simply ignores the message, or it could be that it refunds the user. This is up to the contract to decide.

rahul-kothari · 2023-12-01T12:10:17Z

yellow-paper/docs/contracts/main.md

+
+Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled. 
+
+The contract that sent the message must itself decide how it is to handle the cancellation. It could be that the contract simply ignores the message, or it could be that it refunds the user. This is up to the contract to decide. 


Although the inbox contract must still implement a cancel Message method that checks that message.deadline has been achieved and that the cancellation request is coming from message.sender and this would remove the message for the entries

rahul-kothari · 2023-12-01T12:10:42Z

yellow-paper/docs/contracts/main.md

+##### L2 Inbox
+While the L2 inbox is not a real contract, it is a logical contract that apply mutations to the data similar to the L1 inbox to ensure that the sender cannot fake his position. This logic is handled by the kernel and rollup circuits.
+
+As for the L1 variant, we must populate the some fields:


Suggested change

As for the L1 variant, we must populate the some fields:

Just like the L1 variant, we must populate the some fields:

rahul-kothari · 2023-12-01T12:19:12Z

yellow-paper/docs/contracts/main.md

+1. The inbox populates the message with `sender` information
+1. The inbox contract inserts the message into its storage
+1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.
+1. The outbox ensures that the message is included, and that the caller is the recipient and knows the secret to spend. (This is practically done by the application circuit)


the application does this and not the outbox right?

Yes, that is why it is practically done by the application circuit and only logically in the outbox.

rahul-kothari · 2023-12-01T12:19:42Z

yellow-paper/docs/contracts/main.md

+1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.
+1. The outbox ensures that the message is included, and that the caller is the recipient and knows the secret to spend. (This is practically done by the application circuit)
+1. The nullifier of the message is emitted to privately spend the message (This is practically done by the application circuit)
+1. As part of the transaction, the contract wish to send a message to L1


Suggested change

1. As part of the transaction, the contract wish to send a message to L1

1. The L2 contract now wishes to send a message to L1

rahul-kothari · 2023-12-01T12:22:14Z

yellow-paper/docs/contracts/main.md

+1. The outbox ensures that the message is included, and that the caller is the recipient and knows the secret to spend. (This is practically done by the application circuit)
+1. The nullifier of the message is emitted to privately spend the message (This is practically done by the application circuit)
+1. As part of the transaction, the contract wish to send a message to L1
+1. The inbox populates the message with `sender` and `recipient` information


can we add "l2" here as in "the l2 inbox...."
same for the subsequent sentences to avoid confusion

rahul-kothari · 2023-12-01T12:24:04Z

yellow-paper/docs/contracts/main.md

+1. The inbox populates the message with `sender` information
+1. The inbox contract inserts the message into its storage
+1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.
+1. The outbox ensures that the message is included, and that the caller is the recipient and knows the secret to spend. (This is practically done by the application circuit)


I noticed we don't talk about creating a L1 to L2 merkle tree explicitly anywhere. Is that intentional?

rahul-kothari · 2023-12-01T12:26:12Z

yellow-paper/docs/contracts/main.md

+1. The nullifier of the message is emitted to privately spend the message (This is practically done by the application circuit)
+1. As part of the transaction, the contract wish to send a message to L1
+1. The inbox populates the message with `sender` and `recipient` information
+1. The inbox inserts the message into its storage


this is for L2 to L1 message ye? We don't have any storage for it though right? We simply push it to the inputs to the kernel circuit, which hashes it and the sequencer adds that to the state transitioner no? Where is the storage?

LHerskind · 2023-12-01T15:30:58Z

Don't fully understand the steps under the diagram. Added some comments. Btw Should we talk more about checks in the ciruits related to the L1 to L2 message? Or assume whoever is documenting the circuits will do it?

I'll be adding a list of check now for the checks that are closely related to the communication, and since we are also doing the rollup circuits, will be doing the same thing over there.

The list at the end was mainly to elaborate on each of the edges in the diagram

benesjan

Mostly minor comments and suggestions

benesjan · 2023-12-04T12:18:53Z

yellow-paper/docs/contracts/index.md

+Any message that is consumed on one side MUST be moved to the other side. This is to ensure that the messages exist AND are only consumed once. The L1 contracts can handle one side, but the circuits must handle the other.
+
+:::info Is `secretHash` required?
+We are using the `secretHash` to ensure that the user can spend the message privately with a generic nullifier computation. However, as the nullifier computation is almost entirely controlled by the app circuit (except the siloing) applications could be made to simply use a different nullifier computation and have it become part of the content. However, this reduces the developer burden and is quite easy to mess up. For those reasons we have decided to use the `secretHash` as part of the message.


"except the siloing"

I think that only a few people will have an idea what does siloing mean so I would either explain it here or link to an explanation.

I think the siloing should be mentioned as part of the state writeup which did not exist as the time of writing this. But I can add another of the REFERENCE in there such that it is easy to find.

benesjan · 2023-12-04T12:23:25Z

yellow-paper/docs/contracts/index.md

+### Inbox
+When we say inbox, we are generally referring to the L1 contract that handles the L1 to L2 messages.
+
+The inbox is logically a multi-set that builds messages based on the caller and user-provided content (multi-set meaning that repetition are allowed). While anyone can insert messages into the inbox, only the recipient state transitioner can consume messages from it (as specified by the version). When the state transitioner is consuming a message, it MUST insert it into the "L2 outbox" (message tree).


Suggested change

The inbox is logically a multi-set that builds messages based on the caller and user-provided content (multi-set meaning that repetition are allowed). While anyone can insert messages into the inbox, only the recipient state transitioner can consume messages from it (as specified by the version). When the state transitioner is consuming a message, it MUST insert it into the "L2 outbox" (message tree).

The inbox is logically a [multi-set](https://en.wikipedia.org/wiki/Multiset) that builds messages based on the caller and user-provided content (multi-set meaning that repetitions are allowed). While anyone can insert messages into the inbox, only the recipient state transitioner can consume messages from it (as specified by the version). When the state transitioner is consuming a message, it MUST insert it into the "L2 outbox" (message tree).

I think a lot of people would be searching for this so better to link this.

benesjan · 2023-12-04T12:26:41Z

yellow-paper/docs/contracts/index.md

+
+We MUST populate these values in the inbox, since we cannot rely on the user providing anything meaningful. From the `L1ToL2Msg` we compute a hash of the message. This hash is what is moved by the state transitioner to the L2 outbox. 
+
+Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen, it async. 


Suggested change

Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen, it async.

Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen.

"It async" is weird there.

Oh, it is async it should say, just to make the point clear. Will add the extra word.

benesjan · 2023-12-04T12:29:06Z

yellow-paper/docs/contracts/index.md

+
+Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen, it async. 
+
+This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before a rollup goes through. 


Suggested change

This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before a rollup goes through.

This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before an L2 block goes through.

As discussed a few months ago. Better to use L2 block than rollup. Especially in docs.

benesjan · 2023-12-04T12:31:19Z

yellow-paper/docs/contracts/index.md

+This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before a rollup goes through. 
+While this can be addressed by having a queue of messages and let the sequencer specify the order, this require extra logic and might be difficult to price correctly. To keep this out of protocol, we simply allow the user to attach a fee to the message (see `fee` in `L1ToL2Msg` above). This way, the user can incentivize the sequencer to pick up the message faster.
+
+Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled. 


I don't know the messaging that well since I have not worked on it but doesn't this mean that after a message deadline is reached it's "dangerous" for a sequencer to pick up a message given that it could have been cancelled?

Yes, that is what it means. You don't want to pick up stuff after the deadline.

benesjan · 2023-12-04T13:17:38Z

yellow-paper/docs/contracts/index.md

+We will walk briefly through the steps of the diagram above.
+
+1. A portal contracts on L1 want to send a message for L2
+1. The L1 nbox populates the message with `sender` information


Suggested change

1. The L1 nbox populates the message with `sender` information

1. The L1 inbox populates the message with `sender` information

benesjan · 2023-12-04T13:18:04Z

yellow-paper/docs/contracts/index.md

+1. A portal contracts on L1 want to send a message for L2
+1. The L1 nbox populates the message with `sender` information
+1. The L1 inbox contract inserts the message into its storage
+1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.


Suggested change

1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.

1. On the L2, as part of an L2 block, a transaction tries to consume a message from the L2 outbox.

benesjan · 2023-12-04T13:19:37Z

yellow-paper/docs/contracts/index.md

+1. The L2 inbox inserts the message into its storage
+1. The rollup circuit starts consuming the messages from the inbox
+1. The L2 inbox deletes the messages from its storage
+1. The rollup include messages from the L1 inbox that are to be inserted into the L2 outbox.


Suggested change

1. The rollup include messages from the L1 inbox that are to be inserted into the L2 outbox.

1. The L2 block contains messages from the L1 inbox that are to be inserted into the L2 outbox.

benesjan · 2023-12-04T13:19:56Z

yellow-paper/docs/contracts/index.md

+1. The L2 inbox deletes the messages from its storage
+1. The rollup include messages from the L1 inbox that are to be inserted into the L2 outbox.
+1. The outbox state is updated to include the messages
+1. The rollup block is submitted to L1 


Suggested change

1. The rollup block is submitted to L1

1. The L2 block is submitted to L1

benesjan · 2023-12-04T13:21:22Z

yellow-paper/docs/contracts/index.md

+1. The L1 outbox updates it local state by deleting the message
+
+:::info L2 inbox is not real
+As should be clear from above, the L1 inbox don't need to exist for itself, it keeps no state between blocks, as every message created in the block will also be consumed in the same block. 


Suggested change

As should be clear from above, the L1 inbox don't need to exist for itself, it keeps no state between blocks, as every message created in the block will also be consumed in the same block.

As should be clear from above, the L1 inbox doesn't need to exist for itself, it keeps no state between blocks, as every message created in the block will also be consumed in the same block.

@benesjan

Addressing the comments that @benesjan raised in #3477

🤖 I have created a release *beep* *boop* --- <details><summary>aztec-packages: 0.16.2</summary> ## [0.16.2](aztec-packages-v0.16.1...aztec-packages-v0.16.2) (2023-12-05) ### Features * Add tree snapshots ([#3468](#3468)) ([7a86bb3](7a86bb3)) * **AVM:** First version for mini AVM (ADD, RETURN, CALLDATACOPY) ([#3439](#3439)) ([b3af146](b3af146)) * Circuit optimized indexed tree batch insertion ([#3367](#3367)) ([187d2f7](187d2f7)) * Devnet ([#3473](#3473)) ([97c40c2](97c40c2)) * **docs:** Add simple private voting tutorial ([#3402](#3402)) ([a6e0352](a6e0352)) * **docs:** Document slow update tree ([#3416](#3416)) ([8e9f103](8e9f103)) * Flavor refactor, reduce duplication ([#3407](#3407)) ([8d6b013](8d6b013)) * Inclusion and non-inclusion proofs experiment ([#3255](#3255)) ([b911e65](b911e65)), closes [#2572](#2572) [#2584](#2584) * New Poseidon2 circuit builder gates ([#3346](#3346)) ([91cb369](91cb369)) * New Poseidon2 relations ([#3406](#3406)) ([14b9736](14b9736)) * Pull latest noir for brillig optimizations ([#3464](#3464)) ([d356bac](d356bac)) * Refactor StandardIndexedTree for abstract leaves and preimages and optimized it ([#3530](#3530)) ([63b9cdc](63b9cdc)) * Removing historical roots from circuits ([#3544](#3544)) ([9f682cb](9f682cb)) * Seperate pil files for sub machines ([#3454](#3454)) ([d09d6f5](d09d6f5)) * Throw compile time error if contract has too many fns ([#3536](#3536)) ([ad66ad0](ad66ad0)) * Use tree snapshots in aztec-node/pxe/oracles ([#3504](#3504)) ([6e40427](6e40427)) * Yellow paper cross-chain communication ([#3477](#3477)) ([d51df8c](d51df8c)) ### Bug Fixes * Check version, chainid and sender for cross-chain l1 to l2 msgs ([#3457](#3457)) ([d251703](d251703)) * **ci:** Add DEPLOY_TAG in fork log group ([#3510](#3510)) ([f021041](f021041)) * **ci:** Check if l1 contracts img has been deployed ([#3531](#3531)) ([ac1f03c](ac1f03c)) * **ci:** Comment out LB listeners (for now) ([#3519](#3519)) ([640aabc](640aabc)) * **ci:** Count for bootnode discovery service ([#3517](#3517)) ([2a38788](2a38788)) * **ci:** Define REPOSITORY in deploy_l1_contracts ([#3514](#3514)) ([b246d1b](b246d1b)) * **ci:** Don't deploy to npm on master merge ([#3502](#3502)) ([a138860](a138860)) * **ci:** Env vars for deploying l1-contracts ([#3513](#3513)) ([27106b2](27106b2)) * **ci:** Export FORK_API_KEY from setup_env ([#3512](#3512)) ([7e81e2c](7e81e2c)) * **ci:** Fix docker architecture for devnet packages ([#3505](#3505)) ([66d0287](66d0287)) * **ci:** Fix faucet vars + don't deploy contracts from node ([#3553](#3553)) ([c7176f6](c7176f6)) * **ci:** L1 contracts directories ([#3545](#3545)) ([63dd0c8](63dd0c8)) * **ci:** Login to ecr to fetch contracts image ([#3538](#3538)) ([b033538](b033538)) * **ci:** Remove unused ADDRESS vars & export private key vars ([#3520](#3520)) ([d889359](d889359)) * **ci:** Set default value for $TO_TAINT ([#3508](#3508)) ([8b6688a](8b6688a)) * **ci:** Terraform listener resources ([#3534](#3534)) ([c3b9cce](c3b9cce)) * **ci:** Terraform_deploy for devnet ([#3516](#3516)) ([ba3803e](ba3803e)) * **ci:** Tf variable references & formatting([#3522](#3522)) ([d37cf52](d37cf52)) * Disable e2e-slow-tree ([#3459](#3459)) ([5927103](5927103)) * **docs:** Update package name of aztec-cli ([#3474](#3474)) ([98d7ba0](98d7ba0)) * Double slash in deployed faucet routes ([#3555](#3555)) ([6c704a5](6c704a5)) * Faucet lb_listener priority ([#3554](#3554)) ([3f56dd7](3f56dd7)) * Handling low_nullifier.next_value equal to 0 ([#3562](#3562)) ([c800502](c800502)), closes [#3550](#3550) * Remove x86_64 form l1-contracts img tag ([#3549](#3549)) ([6828f1a](6828f1a)) * Throw error if fn sig has whitespaces ([#3509](#3509)) ([7671063](7671063)), closes [#3055](#3055) ### Miscellaneous * (yellow paper) public-vm section of yellow paper ([#3493](#3493)) ([8ff3780](8ff3780)) * Add mermaid diagram support ([#3499](#3499)) ([537d552](537d552)) * Add yellow paper build check to CI ([#3490](#3490)) ([3ebd2f2](3ebd2f2)) * **avm:** Enable AVM unit tests in CI ([#3463](#3463)) ([051dda9](051dda9)), closes [#3461](#3461) * **bb:** Pointer_view to reference-based get_all ([#3495](#3495)) ([50d7327](50d7327)) * **bb:** Reuse entities from GoblinUltra in GoblinUltraRecursive ([#3521](#3521)) ([8259636](8259636)) * Build the acir test vectors as part of CI. ([#3447](#3447)) ([1a2d1f8](1a2d1f8)) * Containers reduced to ~100MB total. ~30s installation. ([#3487](#3487)) ([b49cef2](b49cef2)) * **docs:** Fix broken Noir stdlib link ([#3496](#3496)) ([787d59a](787d59a)) * Field-agnostic and reusable transcript ([#3433](#3433)) ([d78775a](d78775a)) * Fix broken link in txs in yellow paper ([#3484](#3484)) ([798565d](798565d)) * Fix yellow paper build error ([32881a4](32881a4)) * Fixed typo in build system ([#3501](#3501)) ([3a80ac2](3a80ac2)) * Increase functions per contract from 16 to 32 ([#3503](#3503)) ([ebdeea3](ebdeea3)) * Naming fixes ([#3476](#3476)) ([1db30bf](1db30bf)) * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](#3462)) ([cb3db5d](cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](#3537)) ([5d3895a](5d3895a)) * Recursive verifier updates ([#3452](#3452)) ([dbb4a12](dbb4a12)) * Refactor `WitnessEntities` to be able to derive `WitnessCommitments` from it ([#3479](#3479)) ([9c9b561](9c9b561)) * Remove temporary logging ([#3466](#3466)) ([8c8387b](8c8387b)) * Transcript handled through shared_ptr ([#3434](#3434)) ([30fca33](30fca33)) * Typo fixes ([#3488](#3488)) ([d9a44dc](d9a44dc)) * **yellow_paper:** Public<>private messaging ([#3491](#3491)) ([6ecc406](6ecc406)) ### Documentation * Add transaction section to yellow paper ([#3418](#3418)) ([44bf30b](44bf30b)) * Apply comments from Jan on contracts ([#3539](#3539)) ([e351873](e351873)) * Fees update in yellow paper ([#3486](#3486)) ([a8b2608](a8b2608)) * First go at generated AVM instruction set doc ([#3469](#3469)) ([8cc54a4](8cc54a4)) * Further update to the yellow paper ([#3542](#3542)) ([751bb6a](751bb6a)) * Yellow paper updates ([#3478](#3478)) ([11f754d](11f754d)) * Yellow paper updates for private message delivery ([#3472](#3472)) ([6ba9e18](6ba9e18)) * **yellow-paper:** Sync, enqueued, and static calls ([#3494](#3494)) ([00835c6](00835c6)), closes [#3108](#3108) * **yellowpaper:** Instruction set updates and fixes ([#3515](#3515)) ([bfb61dd](bfb61dd)) </details> <details><summary>barretenberg.js: 0.16.2</summary> ## [0.16.2](barretenberg.js-v0.16.1...barretenberg.js-v0.16.2) (2023-12-05) ### Miscellaneous * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](#3462)) ([cb3db5d](cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](#3537)) ([5d3895a](5d3895a)) </details> <details><summary>barretenberg: 0.16.2</summary> ## [0.16.2](barretenberg-v0.16.1...barretenberg-v0.16.2) (2023-12-05) ### Features * **AVM:** First version for mini AVM (ADD, RETURN, CALLDATACOPY) ([#3439](#3439)) ([b3af146](b3af146)) * Flavor refactor, reduce duplication ([#3407](#3407)) ([8d6b013](8d6b013)) * New Poseidon2 circuit builder gates ([#3346](#3346)) ([91cb369](91cb369)) * New Poseidon2 relations ([#3406](#3406)) ([14b9736](14b9736)) * Pull latest noir for brillig optimizations ([#3464](#3464)) ([d356bac](d356bac)) * Seperate pil files for sub machines ([#3454](#3454)) ([d09d6f5](d09d6f5)) ### Miscellaneous * **avm:** Enable AVM unit tests in CI ([#3463](#3463)) ([051dda9](051dda9)), closes [#3461](#3461) * **bb:** Pointer_view to reference-based get_all ([#3495](#3495)) ([50d7327](50d7327)) * **bb:** Reuse entities from GoblinUltra in GoblinUltraRecursive ([#3521](#3521)) ([8259636](8259636)) * Build the acir test vectors as part of CI. ([#3447](#3447)) ([1a2d1f8](1a2d1f8)) * Field-agnostic and reusable transcript ([#3433](#3433)) ([d78775a](d78775a)) * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](#3462)) ([cb3db5d](cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](#3537)) ([5d3895a](5d3895a)) * Recursive verifier updates ([#3452](#3452)) ([dbb4a12](dbb4a12)) * Refactor `WitnessEntities` to be able to derive `WitnessCommitments` from it ([#3479](#3479)) ([9c9b561](9c9b561)) * Transcript handled through shared_ptr ([#3434](#3434)) ([30fca33](30fca33)) * Typo fixes ([#3488](#3488)) ([d9a44dc](d9a44dc)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).

🤖 I have created a release *beep* *boop* --- <details><summary>aztec-packages: 0.16.2</summary> ## [0.16.2](AztecProtocol/aztec-packages@aztec-packages-v0.16.1...aztec-packages-v0.16.2) (2023-12-05) ### Features * Add tree snapshots ([#3468](AztecProtocol/aztec-packages#3468)) ([7a86bb3](AztecProtocol/aztec-packages@7a86bb3)) * **AVM:** First version for mini AVM (ADD, RETURN, CALLDATACOPY) ([#3439](AztecProtocol/aztec-packages#3439)) ([b3af146](AztecProtocol/aztec-packages@b3af146)) * Circuit optimized indexed tree batch insertion ([#3367](AztecProtocol/aztec-packages#3367)) ([187d2f7](AztecProtocol/aztec-packages@187d2f7)) * Devnet ([#3473](AztecProtocol/aztec-packages#3473)) ([97c40c2](AztecProtocol/aztec-packages@97c40c2)) * **docs:** Add simple private voting tutorial ([#3402](AztecProtocol/aztec-packages#3402)) ([a6e0352](AztecProtocol/aztec-packages@a6e0352)) * **docs:** Document slow update tree ([#3416](AztecProtocol/aztec-packages#3416)) ([8e9f103](AztecProtocol/aztec-packages@8e9f103)) * Flavor refactor, reduce duplication ([#3407](AztecProtocol/aztec-packages#3407)) ([8d6b013](AztecProtocol/aztec-packages@8d6b013)) * Inclusion and non-inclusion proofs experiment ([#3255](AztecProtocol/aztec-packages#3255)) ([b911e65](AztecProtocol/aztec-packages@b911e65)), closes [#2572](AztecProtocol/aztec-packages#2572) [#2584](AztecProtocol/aztec-packages#2584) * New Poseidon2 circuit builder gates ([#3346](AztecProtocol/aztec-packages#3346)) ([91cb369](AztecProtocol/aztec-packages@91cb369)) * New Poseidon2 relations ([#3406](AztecProtocol/aztec-packages#3406)) ([14b9736](AztecProtocol/aztec-packages@14b9736)) * Pull latest noir for brillig optimizations ([#3464](AztecProtocol/aztec-packages#3464)) ([d356bac](AztecProtocol/aztec-packages@d356bac)) * Refactor StandardIndexedTree for abstract leaves and preimages and optimized it ([#3530](AztecProtocol/aztec-packages#3530)) ([63b9cdc](AztecProtocol/aztec-packages@63b9cdc)) * Removing historical roots from circuits ([#3544](AztecProtocol/aztec-packages#3544)) ([9f682cb](AztecProtocol/aztec-packages@9f682cb)) * Seperate pil files for sub machines ([#3454](AztecProtocol/aztec-packages#3454)) ([d09d6f5](AztecProtocol/aztec-packages@d09d6f5)) * Throw compile time error if contract has too many fns ([#3536](AztecProtocol/aztec-packages#3536)) ([ad66ad0](AztecProtocol/aztec-packages@ad66ad0)) * Use tree snapshots in aztec-node/pxe/oracles ([#3504](AztecProtocol/aztec-packages#3504)) ([6e40427](AztecProtocol/aztec-packages@6e40427)) * Yellow paper cross-chain communication ([#3477](AztecProtocol/aztec-packages#3477)) ([d51df8c](AztecProtocol/aztec-packages@d51df8c)) ### Bug Fixes * Check version, chainid and sender for cross-chain l1 to l2 msgs ([#3457](AztecProtocol/aztec-packages#3457)) ([d251703](AztecProtocol/aztec-packages@d251703)) * **ci:** Add DEPLOY_TAG in fork log group ([#3510](AztecProtocol/aztec-packages#3510)) ([f021041](AztecProtocol/aztec-packages@f021041)) * **ci:** Check if l1 contracts img has been deployed ([#3531](AztecProtocol/aztec-packages#3531)) ([ac1f03c](AztecProtocol/aztec-packages@ac1f03c)) * **ci:** Comment out LB listeners (for now) ([#3519](AztecProtocol/aztec-packages#3519)) ([640aabc](AztecProtocol/aztec-packages@640aabc)) * **ci:** Count for bootnode discovery service ([#3517](AztecProtocol/aztec-packages#3517)) ([2a38788](AztecProtocol/aztec-packages@2a38788)) * **ci:** Define REPOSITORY in deploy_l1_contracts ([#3514](AztecProtocol/aztec-packages#3514)) ([b246d1b](AztecProtocol/aztec-packages@b246d1b)) * **ci:** Don't deploy to npm on master merge ([#3502](AztecProtocol/aztec-packages#3502)) ([a138860](AztecProtocol/aztec-packages@a138860)) * **ci:** Env vars for deploying l1-contracts ([#3513](AztecProtocol/aztec-packages#3513)) ([27106b2](AztecProtocol/aztec-packages@27106b2)) * **ci:** Export FORK_API_KEY from setup_env ([#3512](AztecProtocol/aztec-packages#3512)) ([7e81e2c](AztecProtocol/aztec-packages@7e81e2c)) * **ci:** Fix docker architecture for devnet packages ([#3505](AztecProtocol/aztec-packages#3505)) ([66d0287](AztecProtocol/aztec-packages@66d0287)) * **ci:** Fix faucet vars + don't deploy contracts from node ([#3553](AztecProtocol/aztec-packages#3553)) ([c7176f6](AztecProtocol/aztec-packages@c7176f6)) * **ci:** L1 contracts directories ([#3545](AztecProtocol/aztec-packages#3545)) ([63dd0c8](AztecProtocol/aztec-packages@63dd0c8)) * **ci:** Login to ecr to fetch contracts image ([#3538](AztecProtocol/aztec-packages#3538)) ([b033538](AztecProtocol/aztec-packages@b033538)) * **ci:** Remove unused ADDRESS vars & export private key vars ([#3520](AztecProtocol/aztec-packages#3520)) ([d889359](AztecProtocol/aztec-packages@d889359)) * **ci:** Set default value for $TO_TAINT ([#3508](AztecProtocol/aztec-packages#3508)) ([8b6688a](AztecProtocol/aztec-packages@8b6688a)) * **ci:** Terraform listener resources ([#3534](AztecProtocol/aztec-packages#3534)) ([c3b9cce](AztecProtocol/aztec-packages@c3b9cce)) * **ci:** Terraform_deploy for devnet ([#3516](AztecProtocol/aztec-packages#3516)) ([ba3803e](AztecProtocol/aztec-packages@ba3803e)) * **ci:** Tf variable references & formatting([#3522](AztecProtocol/aztec-packages#3522)) ([d37cf52](AztecProtocol/aztec-packages@d37cf52)) * Disable e2e-slow-tree ([#3459](AztecProtocol/aztec-packages#3459)) ([5927103](AztecProtocol/aztec-packages@5927103)) * **docs:** Update package name of aztec-cli ([#3474](AztecProtocol/aztec-packages#3474)) ([98d7ba0](AztecProtocol/aztec-packages@98d7ba0)) * Double slash in deployed faucet routes ([#3555](AztecProtocol/aztec-packages#3555)) ([6c704a5](AztecProtocol/aztec-packages@6c704a5)) * Faucet lb_listener priority ([#3554](AztecProtocol/aztec-packages#3554)) ([3f56dd7](AztecProtocol/aztec-packages@3f56dd7)) * Handling low_nullifier.next_value equal to 0 ([#3562](AztecProtocol/aztec-packages#3562)) ([c800502](AztecProtocol/aztec-packages@c800502)), closes [#3550](AztecProtocol/aztec-packages#3550) * Remove x86_64 form l1-contracts img tag ([#3549](AztecProtocol/aztec-packages#3549)) ([6828f1a](AztecProtocol/aztec-packages@6828f1a)) * Throw error if fn sig has whitespaces ([#3509](AztecProtocol/aztec-packages#3509)) ([7671063](AztecProtocol/aztec-packages@7671063)), closes [#3055](AztecProtocol/aztec-packages#3055) ### Miscellaneous * (yellow paper) public-vm section of yellow paper ([#3493](AztecProtocol/aztec-packages#3493)) ([8ff3780](AztecProtocol/aztec-packages@8ff3780)) * Add mermaid diagram support ([#3499](AztecProtocol/aztec-packages#3499)) ([537d552](AztecProtocol/aztec-packages@537d552)) * Add yellow paper build check to CI ([#3490](AztecProtocol/aztec-packages#3490)) ([3ebd2f2](AztecProtocol/aztec-packages@3ebd2f2)) * **avm:** Enable AVM unit tests in CI ([#3463](AztecProtocol/aztec-packages#3463)) ([051dda9](AztecProtocol/aztec-packages@051dda9)), closes [#3461](AztecProtocol/aztec-packages#3461) * **bb:** Pointer_view to reference-based get_all ([#3495](AztecProtocol/aztec-packages#3495)) ([50d7327](AztecProtocol/aztec-packages@50d7327)) * **bb:** Reuse entities from GoblinUltra in GoblinUltraRecursive ([#3521](AztecProtocol/aztec-packages#3521)) ([8259636](AztecProtocol/aztec-packages@8259636)) * Build the acir test vectors as part of CI. ([#3447](AztecProtocol/aztec-packages#3447)) ([1a2d1f8](AztecProtocol/aztec-packages@1a2d1f8)) * Containers reduced to ~100MB total. ~30s installation. ([#3487](AztecProtocol/aztec-packages#3487)) ([b49cef2](AztecProtocol/aztec-packages@b49cef2)) * **docs:** Fix broken Noir stdlib link ([#3496](AztecProtocol/aztec-packages#3496)) ([787d59a](AztecProtocol/aztec-packages@787d59a)) * Field-agnostic and reusable transcript ([#3433](AztecProtocol/aztec-packages#3433)) ([d78775a](AztecProtocol/aztec-packages@d78775a)) * Fix broken link in txs in yellow paper ([#3484](AztecProtocol/aztec-packages#3484)) ([798565d](AztecProtocol/aztec-packages@798565d)) * Fix yellow paper build error ([32881a4](AztecProtocol/aztec-packages@32881a4)) * Fixed typo in build system ([#3501](AztecProtocol/aztec-packages#3501)) ([3a80ac2](AztecProtocol/aztec-packages@3a80ac2)) * Increase functions per contract from 16 to 32 ([#3503](AztecProtocol/aztec-packages#3503)) ([ebdeea3](AztecProtocol/aztec-packages@ebdeea3)) * Naming fixes ([#3476](AztecProtocol/aztec-packages#3476)) ([1db30bf](AztecProtocol/aztec-packages@1db30bf)) * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](AztecProtocol/aztec-packages#3462)) ([cb3db5d](AztecProtocol/aztec-packages@cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](AztecProtocol/aztec-packages#3537)) ([5d3895a](AztecProtocol/aztec-packages@5d3895a)) * Recursive verifier updates ([#3452](AztecProtocol/aztec-packages#3452)) ([dbb4a12](AztecProtocol/aztec-packages@dbb4a12)) * Refactor `WitnessEntities` to be able to derive `WitnessCommitments` from it ([#3479](AztecProtocol/aztec-packages#3479)) ([9c9b561](AztecProtocol/aztec-packages@9c9b561)) * Remove temporary logging ([#3466](AztecProtocol/aztec-packages#3466)) ([8c8387b](AztecProtocol/aztec-packages@8c8387b)) * Transcript handled through shared_ptr ([#3434](AztecProtocol/aztec-packages#3434)) ([30fca33](AztecProtocol/aztec-packages@30fca33)) * Typo fixes ([#3488](AztecProtocol/aztec-packages#3488)) ([d9a44dc](AztecProtocol/aztec-packages@d9a44dc)) * **yellow_paper:** Public<>private messaging ([#3491](AztecProtocol/aztec-packages#3491)) ([6ecc406](AztecProtocol/aztec-packages@6ecc406)) ### Documentation * Add transaction section to yellow paper ([#3418](AztecProtocol/aztec-packages#3418)) ([44bf30b](AztecProtocol/aztec-packages@44bf30b)) * Apply comments from Jan on contracts ([#3539](AztecProtocol/aztec-packages#3539)) ([e351873](AztecProtocol/aztec-packages@e351873)) * Fees update in yellow paper ([#3486](AztecProtocol/aztec-packages#3486)) ([a8b2608](AztecProtocol/aztec-packages@a8b2608)) * First go at generated AVM instruction set doc ([#3469](AztecProtocol/aztec-packages#3469)) ([8cc54a4](AztecProtocol/aztec-packages@8cc54a4)) * Further update to the yellow paper ([#3542](AztecProtocol/aztec-packages#3542)) ([751bb6a](AztecProtocol/aztec-packages@751bb6a)) * Yellow paper updates ([#3478](AztecProtocol/aztec-packages#3478)) ([11f754d](AztecProtocol/aztec-packages@11f754d)) * Yellow paper updates for private message delivery ([#3472](AztecProtocol/aztec-packages#3472)) ([6ba9e18](AztecProtocol/aztec-packages@6ba9e18)) * **yellow-paper:** Sync, enqueued, and static calls ([#3494](AztecProtocol/aztec-packages#3494)) ([00835c6](AztecProtocol/aztec-packages@00835c6)), closes [#3108](AztecProtocol/aztec-packages#3108) * **yellowpaper:** Instruction set updates and fixes ([#3515](AztecProtocol/aztec-packages#3515)) ([bfb61dd](AztecProtocol/aztec-packages@bfb61dd)) </details> <details><summary>barretenberg.js: 0.16.2</summary> ## [0.16.2](AztecProtocol/aztec-packages@barretenberg.js-v0.16.1...barretenberg.js-v0.16.2) (2023-12-05) ### Miscellaneous * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](AztecProtocol/aztec-packages#3462)) ([cb3db5d](AztecProtocol/aztec-packages@cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](AztecProtocol/aztec-packages#3537)) ([5d3895a](AztecProtocol/aztec-packages@5d3895a)) </details> <details><summary>barretenberg: 0.16.2</summary> ## [0.16.2](AztecProtocol/aztec-packages@barretenberg-v0.16.1...barretenberg-v0.16.2) (2023-12-05) ### Features * **AVM:** First version for mini AVM (ADD, RETURN, CALLDATACOPY) ([#3439](AztecProtocol/aztec-packages#3439)) ([b3af146](AztecProtocol/aztec-packages@b3af146)) * Flavor refactor, reduce duplication ([#3407](AztecProtocol/aztec-packages#3407)) ([8d6b013](AztecProtocol/aztec-packages@8d6b013)) * New Poseidon2 circuit builder gates ([#3346](AztecProtocol/aztec-packages#3346)) ([91cb369](AztecProtocol/aztec-packages@91cb369)) * New Poseidon2 relations ([#3406](AztecProtocol/aztec-packages#3406)) ([14b9736](AztecProtocol/aztec-packages@14b9736)) * Pull latest noir for brillig optimizations ([#3464](AztecProtocol/aztec-packages#3464)) ([d356bac](AztecProtocol/aztec-packages@d356bac)) * Seperate pil files for sub machines ([#3454](AztecProtocol/aztec-packages#3454)) ([d09d6f5](AztecProtocol/aztec-packages@d09d6f5)) ### Miscellaneous * **avm:** Enable AVM unit tests in CI ([#3463](AztecProtocol/aztec-packages#3463)) ([051dda9](AztecProtocol/aztec-packages@051dda9)), closes [#3461](AztecProtocol/aztec-packages#3461) * **bb:** Pointer_view to reference-based get_all ([#3495](AztecProtocol/aztec-packages#3495)) ([50d7327](AztecProtocol/aztec-packages@50d7327)) * **bb:** Reuse entities from GoblinUltra in GoblinUltraRecursive ([#3521](AztecProtocol/aztec-packages#3521)) ([8259636](AztecProtocol/aztec-packages@8259636)) * Build the acir test vectors as part of CI. ([#3447](AztecProtocol/aztec-packages#3447)) ([1a2d1f8](AztecProtocol/aztec-packages@1a2d1f8)) * Field-agnostic and reusable transcript ([#3433](AztecProtocol/aztec-packages#3433)) ([d78775a](AztecProtocol/aztec-packages@d78775a)) * Optimise bb.js package size and sandox/cli dockerfiles to unbloat final containers. ([#3462](AztecProtocol/aztec-packages#3462)) ([cb3db5d](AztecProtocol/aztec-packages@cb3db5d)) * Pin node version in docker base images and bump nvmrc ([#3537](AztecProtocol/aztec-packages#3537)) ([5d3895a](AztecProtocol/aztec-packages@5d3895a)) * Recursive verifier updates ([#3452](AztecProtocol/aztec-packages#3452)) ([dbb4a12](AztecProtocol/aztec-packages@dbb4a12)) * Refactor `WitnessEntities` to be able to derive `WitnessCommitments` from it ([#3479](AztecProtocol/aztec-packages#3479)) ([9c9b561](AztecProtocol/aztec-packages@9c9b561)) * Transcript handled through shared_ptr ([#3434](AztecProtocol/aztec-packages#3434)) ([30fca33](AztecProtocol/aztec-packages@30fca33)) * Typo fixes ([#3488](AztecProtocol/aztec-packages#3488)) ([d9a44dc](AztecProtocol/aztec-packages@d9a44dc)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).

LHerskind requested a review from rahul-kothari November 30, 2023 12:28

LHerskind mentioned this pull request Nov 30, 2023

Protocol: Calls #3108

Closed

9 tasks

rahul-kothari reviewed Nov 30, 2023

View reviewed changes

LHerskind linked an issue Nov 30, 2023 that may be closed by this pull request

Protocol: Smart contracts #3151

Closed

rahul-kothari reviewed Dec 1, 2023

View reviewed changes

LHerskind force-pushed the lh/yp-cc branch from 185f649 to 8e16b95 Compare December 1, 2023 17:20

LHerskind added 7 commits December 4, 2023 10:12

feat: initial notes

c1e6f36

docs: Extend cross-chain docs

af15ddd

docs: add info on error handling + fee

9261fe1

docs: add future work

c9ebe83

chore: Fix typos and improve clarity

16134c4

Add ref to forced inclusion at future work

0ded171

fix: add validity conditions

14ece1c

LHerskind force-pushed the lh/yp-cc branch from 8e16b95 to 14ece1c Compare December 4, 2023 10:12

LHerskind marked this pull request as ready for review December 4, 2023 10:13

LHerskind requested a review from benesjan December 4, 2023 10:13

rahul-kothari approved these changes Dec 4, 2023

View reviewed changes

LHerskind merged commit d51df8c into master Dec 4, 2023
84 checks passed

LHerskind deleted the lh/yp-cc branch December 4, 2023 13:20

AztecBot mentioned this pull request Dec 4, 2023

chore(master): Release 0.16.2 #3453

Merged

benesjan requested changes Dec 4, 2023

View reviewed changes

LHerskind mentioned this pull request Dec 4, 2023

docs: Apply comments from Jan on contracts #3539

Merged

4 tasks

LHerskind added a commit that referenced this pull request Dec 4, 2023

docs: Apply comments from Jan on contracts (#3539)

e351873

Addressing the comments that @benesjan raised in #3477

	The state transitioner is the contract that handles the state and perform the state transition on L1. It makes sure that the proof is valid and that L1 is updated accordingly.
	The state transitioner is the contract that handles the L2 state and performs the state transition on L1. It makes sure that the proof is valid and that L1 is updated accordingly.

	Whenever a block is received it is to:
	Whenever a block is received it will:


		When deploying a contract on L2, it is possible to specify its "portal" address. This is an immutable variable, that can be used to constrain who the L2 contract expect messages from, and who it sends to.

		In the current implementation, any messages that are sent from the L2 contract to L1 MUST be sent to the portal address. This was to get around the access control issue of private execution. This is enforced in the kernel.

	This section are to describe what our L1 contracts do, what each of them are responsible for and how they interact with the circuits.
	This section describes what our L1 contracts do, what each of them is responsible for and how they interact with the circuits.

	We have multiple contracts, some that exist already, and some that are to be build. The collection of these contracts is called the L1 contracts and it was makes up the rollup precense on L1.
	We have multiple contracts. The collection of these contracts is called the L1 contracts and it makes up the rollup presence on L1.

		While this can be addressed by having a queue of messages and let the sequencer specify the order, this require extra logic and might be difficult to price correctly. To keep this out of protocol, we simply allow the user to attach a fee to the message (see `fee` in `L1ToL2Msg` above). This way, the user can incentivize the sequencer to pick up the message faster.

		Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled.


		Since it is possible to land in a case where the sequencer will never pick up the message (e.g., if it is underpriced), the sender must be able to cancel the message. To ensure that this cancellation cannot happen under the feet of the sequencer we use a `deadline`, only after the deadline can it be cancelled.

		The contract that sent the message must itself decide how it is to handle the cancellation. It could be that the contract simply ignores the message, or it could be that it refunds the user. This is up to the contract to decide.

	As for the L1 variant, we must populate the some fields:
	Just like the L1 variant, we must populate the some fields:

	1. As part of the transaction, the contract wish to send a message to L1
	1. The L2 contract now wishes to send a message to L1


		We MUST populate these values in the inbox, since we cannot rely on the user providing anything meaningful. From the `L1ToL2Msg` we compute a hash of the message. This hash is what is moved by the state transitioner to the L2 outbox.

		Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen, it async.


		Since message from L1 to L2 can be inserted independently of the L2 block, the message transfer (insert into inbox move to outbox) are not synchronous as it is for L2 to L1. This means that the message can be inserted into the inbox, but not yet moved to the outbox. The message will then be moved to the outbox when the state transitioner is consuming the message as part of a block. Since the sequencers are responsible for the ordering of the messages, there is not a known time for this pickup to happen, it async.

		This is done to ensure that the messages are not used to DOS the state transitioner. If the state transitioner was forced to pick up the messages in a specific order or at a fixed rate, it could be used to DOS the state transitioner by inserting a message just before a rollup goes through.

	1. The L1 nbox populates the message with `sender` information
	1. The L1 inbox populates the message with `sender` information

	1. On the L2, as part of a rollup, a transaction tries to consume a message from the L2 outbox.
	1. On the L2, as part of an L2 block, a transaction tries to consume a message from the L2 outbox.

	1. The rollup include messages from the L1 inbox that are to be inserted into the L2 outbox.
	1. The L2 block contains messages from the L1 inbox that are to be inserted into the L2 outbox.

	1. The rollup block is submitted to L1
	1. The L2 block is submitted to L1

	As should be clear from above, the L1 inbox don't need to exist for itself, it keeps no state between blocks, as every message created in the block will also be consumed in the same block.
	As should be clear from above, the L1 inbox doesn't need to exist for itself, it keeps no state between blocks, as every message created in the block will also be consumed in the same block.

feat: yellow paper cross-chain communication #3477

feat: yellow paper cross-chain communication #3477

Conversation

LHerskind commented Nov 29, 2023 • edited Loading

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rahul-kothari left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LHerskind commented Dec 1, 2023

benesjan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LHerskind commented Nov 29, 2023 •

edited

Loading