Merge branch 'master' into docs-fix

docs/Glossary.md

@@ -4,25 +4,100 @@ title: Glossary of Arbitrum Terms
 custom_edit_url: https://github.com/OffchainLabs/arbitrum/edit/master/docs/Glossary.md
 ---
 
-- ArbOS: Layer 2 "operating system" that trustlessly handles system-level operations
-- ArbGas: Unit for pricing execution on Arbitrum; denominated in Ether, Arbitrum's native currency. ArgGas is somewhat analogous to gas on L1 Ethereum, though different factors go into its calculation. ( See [ArbGas and Fees](Inside_Arbitrum.md#arbgas-and-fees).)
-- Arbitrum Full Node: A party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-mining L1 Ethereum node.
-- Aggregator: An Arbitrum Full Node that also receives transactions from users and submits them in batches on their behalf.
-- Assertion: A claim, made by a validator, about what the contracts on a chain will do. An assertion is considered _pending_ until it is confirmed.
-- Arbitrum Chain: A chain running on Arbitrum, containing some contracts. Many Arbitrum chains can exist at the same time.
-- AVM: The Arbitrum Virtual Machine
-- Token Bridge: A series of contracts on Ethereum and Arbitrum for trustlessly moving tokens between the L1 and L2.
-- Chain factory: A contract running on Ethereum which, when called, creates a new Arbitrum Chain.
-- Chain state: A particular point in the history of an Arbitrum Chain. A chain state corresponds to a sequence of assertions that have been made, and a verdict about whether each of those assertions was accepted.
-- Challenge: When two stakers disagree about the correct verdict on an assertion, those stakers can be put in a challenge. The challenge is refereed by the EthBridge. Eventually one staker wins the challenge. The loser forfeits their stake. Half of the loser's stake is given to the winner, and the other half is burned.
-- Client: A program running on a user's machine, often in the user's browser, that interacts with contracts on an Arbitrum chain and provides a user interface.
-- Confirmation: The final decision by an Arbitrum chain to accept a node as being a settled part of the chain's history. When a node is confirmed, any funds paid out by the chain to the main Ethereum chain are transferred.
-- EthBridge: A group of contracts running on the Ethereum chain, which act as a record-keeper and rule enforcer for Arbitrum chains.
-- Inbox: Holds a sequence of messages sent by clients to the contracts on an Arbitrum Chain. Every chain's inbox is managed by the on-chain EthBridge.
-- Outbox: An L1 contract responsible for tracking outgoing (Arbitrum to Ethereum) messages, including withdrawals, which can be executed by users once they are confirmed.
-- Outbox Entry: A Merkle root of a series of outgoing messages posted over some period of time, stored in the Outbox.
-- Staker: A party who deposits a stake, in Eth, to vouch for a particular node in an Arbitrum Chain. A party who stakes on a false node can expect to lose their stake. An honest staker can recover their stake once the node they are staked on has been confirmed.
-- Sequencer: an entity given rights to reorder transactions in the Inbox over a small window of time, who can thus give clients sub-blocktime soft confirmations.
-- Sequencer Chain: An Arbitrum chain that includes Sequencer support.
-- Validator: A party who makes staked, disputable assertions about the state of the Arbitrum chain; i.e., proposing state updates or passively monitoring other validator’s assertions and disputing them if they’re invalid.
-- Virtual Machine (VM): A program that "runs" on the Arbitrum chain, which tracks the states of all of the contracts on the chain and all of the Eth and tokens deposited into the chain.
+### General
+
+- **Any-Trust Model**: Security model that only requires that any one participating party behave honestly. Any trust model + permissionless participation = trustless (i.e., Arbitrum Rollup).
+
+- **Arbitrum Chain**: A chain running on Ethereum, containing some contracts. Many Arbitrum chains can exist simultaneously.
+
+- **Arbitrum Rollup**: Trustless Arbitrum L2 protocol in which participation is permissionless and underlying layer is used for data availability (e.g., Arbitrum One).
+
+- **Arbitrum Channels**: Trustless L2 protocol in which participation is permissioned, data is kept off chain, and participants update the state via unanimous consent. (Not yet in production).
+
+- **Arbitrum One**: The first Arbitrum chain running on Ethereum mainnet! (Currently in Beta).
+
+- **Arbitrum Sidechains**: Arbitrum protocol in which data is kept off chain and an any-trusted committee is responsible for updating the chain's state via unanimous consent.
+
+- **ArbGas**: Unit for pricing execution on Arbitrum; denominated in the chain's native currency (Ether on Arbitrum One). ArbGas is somewhat analogous to gas on L1 Ethereum, though different factors go into its calculation. ( See [ArbGas and Fees](Inside_Arbitrum.md#arbgas-and-fees).)
+
+- **Arbitrum Full Node**: A party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-mining L1 Ethereum node.
+
+- **ArbOS**: Layer 2 "operating system" that trustlessly handles system-level operations; includes the ability to emulate the EVM.
+
+- **AVM**: The Arbitrum Virtual Machine; the environment in which execution takes place in an Arbitrum chain. Tracks the states of all of the contracts on the chain and all of the Eth and tokens deposited into the chain.
+
+- **Chain state**: A particular point in the history of an Arbitrum Chain. A chain state corresponds to a sequence of assertions that have been made, and a verdict about whether each of those assertions was accepted.
+
+- **Client**: A program running on a user's machine, often in the user's browser, that interacts with contracts on an Arbitrum chain and provides a user interface.
+
+- **EthBridge**: A group of contracts running on the Ethereum chain, which act as a record-keeper and rule enforcer for Arbitrum chains.
+
+- **Rollup Protocol**: Protocol for tracking the tree of assertions in an Arbitrum chain their confirmation status.
+
+- **Speed Limit**: Target computation limit for an Arbitrum chain; currently, on Arbitrum One targets 80,000 ArbGas per second.
+
+## Proving Fraud
+
+- **Assertion**: A claim, made by a validator, about what the contracts on a chain will do. An assertion is considered _pending_ until it is confirmed.
+
+- **Challenge**: When two stakers disagree about the correct verdict on an assertion, those stakers can be put in a challenge. The challenge is refereed by the EthBridge. Eventually one staker wins the challenge. The loser forfeits their stake. Half of the loser's stake is given to the winner, and the other half is burned.
+
+- **Confirmation**: The final decision by an Arbitrum chain to accept a node as being a settled part of the chain's history. Once an assertion is confirmed, any L2 to L1 messages (i.e., withdrawals) can be executed.
+
+- **Challenge Period**: Window of time (1 week on Arbitrum One) over which an assertion can be challenged, and after which an assertion can be confirmed.
+
+- **Dissection**: Process by which two challenging parties interactively narrow down their disagreement to a single computational step.
+
+- **One Step Proof**: Final step in a challenge; a single operation of the L2 VM is executed, and the validity of its state transition is verified.
+
+- **Staker**: A party who deposits a stake, in Eth, to vouch for a particular node in an Arbitrum Chain. A party who stakes on a false node can expect to lose their stake. An honest staker can recover their stake once the node they are staked on has been confirmed.
+
+- **Active Validator**: A party who makes staked, disputable assertions about the state of the Arbitrum chain; i.e., proposing state updates or challenging the validity of assertions. (Not to be confused with the Sequencer)
+
+- **Defensive Validator**: A validator that watches the Arbitrum chain and takes action (i.e., stake and challenges) only when and if an invalid assertion occurs.
+
+- **Watchtower Validator**: A validator that never stakes / never takes on chain action, who raises the alarm (by whatever off-chain means it chooses) if it witnesses an invalid assertion.
+
+## Cross Chain Communication
+
+- **Address Alias**: A deterministically generated address to be used on L2 that corresponds to an address on L1 for the purpose of L1 to L2 cross-chain messaging.
+
+- **Fast Exit / Liquidity Exit**: A means by which a user can bypass Arbitrum's challenge period when withdrawing fungible assets (or more generally, executing some "fungible" L2 to L1 operation); a liquidity provider facilitates an atomic swap of the asset on L2 directly to L1.
+
+- **Outbox**: An L1 contract responsible for tracking outgoing (Arbitrum to Ethereum) messages, including withdrawals, which can be executed by users once they are confirmed.
+
+- **Outbox Entry**: A Merkle root of a series of outgoing messages posted over some period of time, stored in the Outbox.
+
+- **Retryable Ticket**: An L1 to L2 cross chain message created by an L1 contract sent to an Arbitrum chain for execution (e.g., a token deposit).
+
+- **Retryable Autoredeem**: The "automatic" execution of a retryable ticket on Arbitrum (using provided ArbGas).
+
+## Token Bridging
+
+- **Arb Token Bridge**: A series of contracts on Ethereum and Arbitrum for trustlessly moving tokens between the L1 and L2.
+
+- **Token Gateway**: A pair of contracts in the token bridge — one on L1, one on L2 — that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge are the StandardERC20 Gateway, the CustomERC20 Gateway, and the WETH Gateway.
+
+- **Gateway Router**: Contracts in the token bridge responsible for mapping tokens to their appropriate gateways.
+
+- **Standard Arb-Token**: An L2 token contract deployed via the StandardERC20 gateway; offers basic ERC20 functionality in addition to deposit / withdrawal affordances.
+
+- **Custom Arb-Token**: Any L2 token contract registered to the Arb Token Bridge that isn't a standard arb-token (i.e., a token that uses any gateway other than the StandardERC20 Gateway).
+
+## Transaction Ordering
+
+- **Batch**: A group of L2 transactions posted in a single L1 transaction by the Sequencer.
+
+- **Fair Ordering Algorithm**: BFT algorithm in which a committee comes to consensus on transaction ordering; current single-party Sequencer on Arbitrum one will eventually be replaced by a fair-ordering committee.
+
+- **Forced-Inclusion**: Censorship resistant path for including a message into L2; bypasses any Sequencer involvement.
+
+- **Sequencer**: An entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the Inbox over a small window of time, who can thus give clients sub-blocktime soft confirmations. (not a validator)
+
+- **Sequencer Chain**: An Arbitrum chain that includes Sequencer support (e.g., Arbitrum One).
+
+- **Soft Confirmation**: A semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on L1, and thus can be given near-instantaneously (i.e., faster than L1 block times)
+
+- **Slow Inbox**: Sequence of L1 initiated message that offer an alternative path for inclusion into the fast Inbox.
+
+- **Fast Inbox**: Contract that holds a sequence of messages sent by clients to the contracts on an Arbitrum Chain; message can be put into the Inbox directly by the Sequencer or indirectly through the slow inbox.

docs/Inside_Arbitrum.md

@@ -517,7 +517,7 @@ The sequencer is a specially designated full node, which is given limited power
 
 Clients interact with the sequencer in exactly the same way they would interact with any full node, for example by giving their wallet software a network URL that happens to point to the sequencer.
 
-### Instant finality
+### Instant confirmation
 
 Without a sequencer, a node can predict what the results of a client transaction will be, but the node can't be sure, because it can't know or control how the transactions it submits will be ordered in the inbox, relative to transactions submitted by other nodes.
 
@@ -538,7 +538,7 @@ A well-behaved sequencer will accept transactions from all requesters and treat
 
 It will also minimize the delay it imposes on non-sequencer transactions by minimizing how far it backdates transactions, consistent with the goal of providing strong promises of transaction results. Specifically, if the sequencer believes that 20 confirmation blocks are needed to have finality on Ethereum, then it will backdate transactions by 20 blocks. This is enough to ensure that the sequencer knows exactly which transactions will precede its current transaction, because those preceding transactions have finality. There is no need for a benign sequencer to backdate more than that, so it won't.
 
-This does mean that transactions that go through the regular inbox will take longer to get finality. Their time to finality will roughly double: if finality requires C confirmation blocks, then a regular-inbox tranasaction at block B be processed after sequencer transactions that are inserted at time B+C-1 (but labeled with block B-1), and those sequencer transactions won't have finality until time B+2C-1.
+This does mean that transactions that go through the regular inbox will take longer to get finality. Their time to finality will roughly double: if finality requires C confirmation blocks, then a regular-inbox transaction at block B be processed after sequencer transactions that are inserted at time B+C-1 (but labeled with block B-1), and those sequencer transactions won't have finality until time B+2C-1.
 
 This is the basic tradeoff of having a sequencer: if you use the sequencer, finality is C blocks faster; but if you don't use the sequencer, finality is C blocks slower. This is usually a good tradeoff, because most transactions will use the sequencer; and because the practical difference between instant and 5-minute finality is bigger than the difference between 5-minute and 10-minute finality.
 

docs/L1_L2_Messages.md

@@ -80,7 +80,8 @@ In a future release, the base submission fee will be calculated using the 1559 `
 When a retryable ticket is initiated from the L1, the following things take place:
 
 - DepositValue is credited to the sender’s account on L2.
-  - If DepositValue is less than MaxSubmissionCost + Callvalue, the Retryable Ticket fails.
+  - If the L2 account's balance (which now includes the DepositValue) is less than MaxSubmissionCost + Callvalue, the Retryable Ticket creation fails.
+  - If MaxSubmissionCost is less than the submission fee, the Retryable Ticket creation fails.
 - Submission fee is collected: submission fee is deducted from the sender’s L2 account; MaxSubmissionCost - submission fee is credited to Credit-Back Address.
 
 - Callvalue is deducted from sender’s L2 account and a Retryable Ticket is successfully created.

docs/Mainnet.md

@@ -26,7 +26,7 @@ A good place to start is to connect your favorite Ethereum wallet to the Arbitru
 
 **Chain Info:**
 
-Name:** Arbitrum One**
+Name: **Arbitrum One**
 
 ChainID: **42161**
 

docs/Solidity_Support.md

@@ -18,6 +18,7 @@ Although Arbitrum supports Solidity code, there are differences in the effects o
 - `gasleft` returns the amount of ArbGas remaining
 - `block.number` on a non-Sequencer Arbitrum chain, returns the L1 block number at which the transaction was submitted to the inbox; on a Sequencer Arbitrum chain, returns an "estimate" of the L1 block number at which the Sequencer received the transaction (see [Time in Arbitrum](Time_in_Arbitrum.md))
 - `msg.sender` works the same way it does on Ethereum for normal L2-to-L2 transactions; for L1-to-L2 "retryable ticket" transactions, it will return the L2 address alias of the L1 contract that triggered the message. See [retryable ticket address aliasing](L1_L2_Messages.md#address-aliasing) for more.
+- blake2f and ripemd160 precompiles are not currently supported.
 
 # Time
 

docs/Tx_Lifecycle.md

@@ -23,7 +23,7 @@ There are a number of different phases that a transaction goes through before a
 
 Most users will only need to wait for confirmation by the sequencer when the outcome is guaranteed (assuming the sequencer doesn't violate its promise). Initially we’ll be running the sequencer, and over time we’ll shift over to a more decentralized sequencer with slashing so the risk here to users is low.
 
-For users that want a higher level of security, they can wait until the sequencer posts a batch, which currently we’re doing once an hour, but once we open up to users this will occur every 15 minutes or less most likely. The time between batches just needs to be enough to amortize the relatively low constant costs of posting a batch. It's likely that exchanges supporting direct withdrawals will want to wait for some number of L1 confirmations on a batch transaction before releasing funds, similarly to how they wait for a certain number of confirmations on L1 chains.
+For users that want a higher level of security, they can wait until the sequencer posts a batch, which will [typically](https://arbiscan.io/batches) happen every few minutes. The time between batches just needs to be enough to amortize the relatively low constant costs of posting a batch. It's likely that exchanges supporting direct withdrawals will want to wait for some number of L1 confirmations on a batch transaction before releasing funds, similarly to how they wait for a certain number of confirmations on L1 chains.
 
 Additionally, users always have the option of avoiding reliance on the sequencer altogether by posting transactions directly on-chain themselves (i.e., skipping steps A and B above). In this scenario, their transaction will be queued up for validators to include in an assertion once the sequencer posts its next batch or a protocol enforced time-period elapses (set to 24 hours for mainnet beta), whichever comes first. Users should rarely, if ever, need to go this route to include their transaction, but the recourse to do so ensures that Arbitrum’s censorship resistance properties are ensured even if the sequencer goes offline.
 

docs/talks.md

@@ -1,6 +1,6 @@
 ---
 id: talks
-title: ArbOS: Public Talks & Appearances
+title: Public Talks & Appearances
 sidebar_label: Talks & Appearances
 ---
 

packages/arb-bridge-peripherals/_deployments/1_queued-updates.json

@@ -1 +1,14 @@
-{}
+{
+  "L1GatewayRouter": {
+    "address": "0x32f39fa08c1e0bba551cbda4197e543c53b3fc53",
+    "deployTxn": "0x0db4fd99600533113346de3a6081d83d103fe3d4ab4f58dff80a91365aa67616",
+    "arbitrumCommitHash": "8eb4685d3e44fa059901e423a70e6dd5c80508a3",
+    "buildInfo": ""
+  },
+  "L1CustomGateway": {
+    "address": "0xcD224c5dC33e059C661fba01FaE2843b7d707362",
+    "deployTxn": "0xf832f17c433a45d4ece2adf29865a8c44c5e5340b9f2f0e006991aa38efb97f8",
+    "arbitrumCommitHash": "8eb4685d3e44fa059901e423a70e6dd5c80508a3",
+    "buildInfo": ""
+  }
+}

packages/arb-bridge-peripherals/contracts/tokenbridge/ethereum/ICustomToken.sol

@@ -32,7 +32,8 @@ interface ICustomToken is ArbitrumEnabledToken {
      */
     function registerTokenOnL2(
         address l2CustomTokenAddress,
-        uint256 maxSubmissionCost,
+        uint256 maxSubmissionCostForCustomBridge,
+        uint256 maxSubmissionCostForRouter,
         uint256 maxGas,
         uint256 gasPriceBid,
         address creditBackAddress