fix: address comments

docs/docs/developers/contracts/references/history_lib_reference.md

@@ -133,15 +133,11 @@ This proves that a contract exists in, ie had been deployed before or in, a cert
 
 `prove_contract_inclusion_at` takes 7 parameters:
 
-| Name                    | Type           | Description                                        |
-| ----------------------- | -------------- | -------------------------------------------------- |
-| deployer_public_key     | GrumpkinPoint  | Public key of the contract deployer                |
-| contract_address_salt   | Field          | Unique identifier for the contract's address       |
-| function_tree_root      | Field          | Root of the contract's function tree               |
-| constructor_hash        | Field          | Hash of the contract's constructor                 |
-| block_number            | u32            | Block number for proof verification                |
-| context                 | PrivateContext | Private context                                    |
-
-```ts
-new EthAddress(Buffer.alloc(EthAddress.SIZE_IN_BYTES));
-```
+| Name                  | Type           | Description                                  |
+| --------------------- | -------------- | -------------------------------------------- |
+| deployer_public_key   | GrumpkinPoint  | Public key of the contract deployer          |
+| contract_address_salt | Field          | Unique identifier for the contract's address |
+| function_tree_root    | Field          | Root of the contract's function tree         |
+| constructor_hash      | Field          | Hash of the contract's constructor           |
+| block_number          | u32            | Block number for proof verification          |
+| context               | PrivateContext | Private context                              |

docs/docs/developers/contracts/writing_contracts/portals/portals.md

@@ -4,4 +4,4 @@ title: Portals
 
 A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2.
 
-As outlined in [Communication](../../../../learn/concepts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal don't actually need to be a contract, it could be any address on L1.
+As outlined in [Communication](../../../../learn/concepts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal doesn't actually need to be a contract, it could be any address on L1.

docs/docs/developers/tutorials/token_portal/withdrawing_to_l1.md

@@ -18,8 +18,8 @@ The `exit_to_l1_public` function enables anyone to withdraw their L2 tokens back
 
 1. Like with our deposit function, we need to create the L2 to L1 message. The content is the _amount_ to burn, the recipient address, and who can execute the withdraw on the L1 portal on behalf of the user. It can be `0x0` for anyone, or a specified address.
 2. `context.message_portal()` passes this content to the [kernel circuit](../../../learn/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption.
-2. The `context.message_portal()` takes the recipient and content as input, and will insert a message into the outbox. We set the recipient to be the portal address read from storage of the contract. 
-3. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../writing_token_contract.md#burn_public). The nonce parameter refers to the approval message that the user creates - also refer to [authorizing token spends here](../writing_token_contract.md#authorizing-token-spends).
+3. The `context.message_portal()` takes the recipient and content as input, and will insert a message into the outbox. We set the recipient to be the portal address read from storage of the contract.
+4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../writing_token_contract.md#burn_public). The nonce parameter refers to the approval message that the user creates - also refer to [authorizing token spends here](../writing_token_contract.md#authorizing-token-spends).
    - We burn the tokens from the `msg_sender()`. Otherwise, a malicious user could burn someone else’s tokens and mint tokens on L1 to themselves. One could add another approval flow on the bridge but that might make it complex for other applications to call the bridge.
 
 ## Withdrawing Privately

docs/docs/misc/migration_notes.md

@@ -6,12 +6,14 @@ keywords: [sandbox, cli, aztec, notes, migration, updating, upgrading]
 
 Aztec is in full-speed development. Literally every version breaks compatibility with the previous ones. This page attempts to target errors and difficulties you might encounter when upgrading, and how to resolve them.
 
-## [T.B.D]
+## 0.36.0
+
+## [Aztec.nr & js] Portal addresses
 
-## [Aztec.nr & js] Portal addresses 
-The deployment have been cleansed from the portal addresses as a immutable value passed in differently to other variables and instead should be implemented using usual storage by those who require it using the storage that matches the usecase - likely the shared storage to support private and public.
+Deployments have been modified. No longer are portal addresses treated as a special class, being immutably set on creation of a contract. They are no longer passed in differently compared to the other variables and instead should be implemented using usual storage by those who require it. One should use the storage that matches the usecase - likely shared storage to support private and public.
 
 This means that you will likely add the portal as a constructor argument
+
 ```diff
 - fn constructor(token: AztecAddress) {
 -    storage.token.write(token);
@@ -23,13 +25,12 @@ This means that you will likely add the portal as a constructor argument
 ```
 
 And read it from storage whenever needed instead of from the context.
+
 ```diff
 - context.this_portal_address(),
 + storage.portal_address.read_public(),
 ```
 
-## 0.36.0
-
 ### [Aztec.nr] Oracles
 
 Oracle `get_nullifier_secret_key` was renamed to `get_app_nullifier_secret_key` and `request_nullifier_secret_key` function on PrivateContext was renamed as `request_app_nullifier_secret_key`.
@@ -123,7 +124,6 @@ and change the call to `get_portal_address`
 + let portal_address = SomeContract::at(contract_address).get_portal_address().call(&mut context);
 ```
 
-
 ### [Aztec.nr] Required gas limits for public-to-public calls
 
 When calling a public function from another public function using the `call_public_function` method, you must now specify how much gas you're allocating to the nested call. This will later allow you to limit the amount of gas consumed by the nested call, and handle any out of gas errors.

docs/docs/protocol-specs/l1-smart-contracts/index.md

@@ -12,7 +12,7 @@ The purpose of the L1 contracts are simple:
 
 - Facilitate cross-chain communication such that L1 liquidity can be used on L2
 - Act as a validating light node for L2 that every L1 node implicitly run
-:::
+  :::
 
 ## Overview
 
@@ -188,7 +188,7 @@ Insertions require a L2 transaction, and it is then to be consumed and moved to
 
 ### Portals
 
-Some contracts on L2 might wish to talk to contract on L1 - these recipients on L1 are called portals.
+Some contracts on L2 might wish to talk to contracts on L1 - these recipients on L1 are called portals.
 
 Often it is desired to constrain where messages are sent to and received from, which can be done by keeping the portal address in the storage of the L2 contract, such that it can be loaded on demand.
 
@@ -489,7 +489,7 @@ Also, some of the conditions are repetitions of what we saw earlier from the [st
 
 - For cost purposes, it can be useful to commit to the public inputs to just pass a single value into the circuit.
 - Time constraints might change depending on the exact sequencer selection mechanism.
-:::
+  :::
 
 ## Logical Execution