Merge branch 'master' into add-allnodes-to-rpc-providers

arbitrum-docs/partials/_glossary-partial.md

@@ -267,7 +267,7 @@ This is achieved through the use of cryptographic techniques and decentralized c
 <p>A <a href="/intro/glossary#validator">Validator</a>  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.</p>
 
 ### WETH Gateway {#weth-gateway}
-<p><a href="/intro/glossary#token-gateway">Token Gateway</a> for handing the bridging of wrapped Ether (WETH). WETH is unwrapped on L1 and rewrapped on L1 upon depositing (and vice-versa upon withdrawing), ensuring WETH on L2 always remains collateralized </p>
+<p><a href="/intro/glossary#token-gateway">Token Gateway</a> for handing the bridging of wrapped Ether (WETH). WETH is unwrapped on L1 and rewrapped on L1 upon depositing (and vice-versa upon withdrawing), ensuring WETH on L2 always remains collateralized. </p>
 
 ### 👺 Zeeverse {#zeeverse}
 <p>As you're exploring the Arbitrum world, you may bump into a world filled with monsters and Zee's.<br />

arbitrum-docs/partials/_troubleshooting-building-partial.md

@@ -116,8 +116,10 @@ To let's find out which is custom error this signature represents, we can use th
 
 
 
-### How do block.timestamp and block.number work on Arbitrum? {#how-do-blocktimestamp-and-blocknumber-work-on-arbitrum}
-<p>Solidity calls to <code>block.number</code> and <code>block.timestamp</code> on Arbitrum will return the block number/ timestamp of the underlying L1 on a slight delay; i.e., updated every few minutes. Note that L2 block numbers (i.e., as seen in block explorers / returned by RPCs) are different, and are typically updated roughly every second.</p>
+### How do block.number and block.timestamp work on Arbitrum? {#how-do-blocknumber-and-blocktimestamp-work-on-arbitrum}
+<p>Solidity calls to <code>block.number</code> on Arbitrum will return the block number/ timestamp of the underlying L1 on a slight delay; i.e., updated every few minutes. Note that L2 block numbers (i.e., as seen in block explorers / returned by RPCs) are different, and are typically updated roughly every second.</p>
+
+<p>Solidity calls to <code>block.timestamp</code> on Arbitrum are not linked to the timestamp of the L1 block, it is updated every L2 block based on the sequencer's clock.</p>
 
 <p>For more info, see <a href="https://developer.arbitrum.io/time">block numbers and time</a>.</p>
 

arbitrum-docs/partials/_troubleshooting-users-partial.md

@@ -91,7 +91,7 @@
 
 <p>Which is to say — the more important thing than decentralizing the Sequencer, i.e., the thing you ought to care more about — is decentralizing the <em>Validators</em>.</p>
 
-<p>Arbitrum One's Validator set is currently allowlisted; overtime, the allowlist will grow and then be removed entirely. For more info see <a href="https://developer.arbitrum.io/mainnet-risks">"Mainnet risks"</a>.</p>
+<p>Arbitrum One's Validator set is currently allowlisted; overtime, the allowlist will grow and then be removed entirely. For more info see <a href="https://developer.arbitrum.io/mainnet-beta">"Mainnet Beta"</a>.</p>
 
 
 

arbitrum-docs/tx-lifecycle.mdx

@@ -70,7 +70,7 @@ The Sequencer is forced to include messages from the delayed Inbox in the queued
 
 #### ~ ~ ~ FINALITY CHECK: Ethereum-Equivalent Finality! ~ ~ ~
 
-At this stage, assuming that a client believes there to be at least one well behaved active Arbitrum validator (recall that in Arbitrum Rollup, validating is permissionless), the client can treat their transaction's finality as equivalent to an ordinary Ethereum transaction. In other words, their L2 transaction has the same finality as the L1 transaction that recorded it in a batch. This means the client should use whatever finality heuristic they use for regular Ethereum transactions (i.e., waiting on L1 block confirmations, etc.), applied to the L1 batch-posting transaction. This also means that a client uncomfortable with the trust model of the Sequencer's soft confirmations (phase 2) can simply wait for the Sequencer to post their transaction in a batch (phase 3).
+At this stage, assuming that a client believes there to be at least one well behaved active Arbitrum validator. Currently, the process of validation on the Arbitrum protocol is permissioned, but it's important to be aware that our latest dispute protocol, [BOLD (Bounded Liquidity Delay)](https://medium.com/offchainlabs/bold-permissionless-validation-for-arbitrum-chains-9934eb5328cc), has the potential to allow validation on Arbitrum chains without requiring permission, thereby potentially eliminating the necessity for restricted validation. The client can treat their transaction's finality as equivalent to an ordinary Ethereum transaction. In other words, their L2 transaction has the same finality as the L1 transaction that recorded it in a batch. This means the client should use whatever finality heuristic they use for regular Ethereum transactions (i.e., waiting on L1 block confirmations, etc.), applied to the L1 batch-posting transaction. This also means that a client uncomfortable with the trust model of the Sequencer's soft confirmations (phase 2) can simply wait for the Sequencer to post their transaction in a batch (phase 3).
 
 How are we able to make such bold a claim? A few (related) things:
 

website/static/glossary.json

@@ -62,13 +62,13 @@
 "sequencer":{"title":"Sequencer","text":"<p>An entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the <a href=\"/intro/glossary#fast-inbox\">Fast Inbox</a>  over a fixed window of time, who can thus give clients sub-blocktime <a href=\"/intro/glossary#soft-confirmation\">Soft Confirmation</a>s. (Not to be confused with a <a href=\"/intro/glossary#validator\">Validator</a>).</p>"},
 "sequencer-feed":{"title":"Sequencer Feed","text":"<p>Off chain data feed published by the <a href=\"/intro/glossary#sequencer\">Sequencer</a> which clients can subscribe to for <a href=\"/intro/glossary#soft-confirmation\">Soft Confirmation</a>s of transactions before they are posted in <a href=\"/intro/glossary#batch\">Batch</a>es.</p>"},
 "smart-contract":{"title":"Smart Contract","text":"<p>A computer program whose operations are defined and executed within a blockchain consensus protocol.</p>"},
-"smolverse":{"title":"Smolverse","text":"<p>Near the core of Arbitrum community is Smolverse, a world filled with Smol Brains and Smol Bodies.<br />\n<br />\nIf you see any Smol's with giga brains, swole arms or hear the sound of \"EEEE\" in the Arbitrum community, you've encounted the Smol Brains and Smol Bodies. </p>"},
+"smolverse":{"title":"Smolverse","text":"<p>Near the core of Arbitrum community is Smolverse, a world filled with Smol Brains and Smol Bodies.<br />\n<br />\nIf you see any Smol's with giga brains, swole arms or hear the sound of \"EEEE\" in the Arbitrum community, you've encountered the Smol Brains and Smol Bodies. </p>"},
 "soft-confirmation":{"title":"Soft Confirmation","text":"<p>A semi-trusted promise from the <a href=\"/intro/glossary#sequencer\">Sequencer</a>  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)</p>"},
 "speed-limit":{"title":"Speed Limit","text":"<p>Target L2 computation limit for an Arbitrum chain. <a href=\"/intro/glossary#arbitrum-one\">Arbitrum One</a> and <a href=\"/intro/glossary#arbitrum-nova\">Arbitrum Nova</a>  currently target 7,000,000 gas / second. When computation exceeds this limit, fees rise, ala <a href=\"https://notes.ethereum.org/@vbuterin/eip-1559-faq\">EIP-1559</a>.</p>"},
 "staker":{"title":"Staker","text":"<p>A <a href=\"/intro/glossary#validator\">Validator</a> who deposits a stake (in Ether on <a href=\"/intro/glossary#arbitrum-one\">Arbitrum One</a> and <a href=\"/intro/glossary#arbitrum-nova\">Arbitrum Nova</a> ) to vouch for a particular <a href=\"/intro/glossary#rblock\">RBlock</a>  in an Arbitrum Chain. A validator who stakes on a false RBlock can expect to lose their stake. An honest staker can recover their stake once the RBlock they are staked on has been confirmed.</p>"},
 "standard-arbtoken":{"title":"Standard Arb-Token","text":"<p>An L2 token contract deployed via the <a href=\"/intro/glossary#standarderc20-gateway\">StandardERC20 gateway</a>; offers basic ERC20 functionality in addition to deposit / withdrawal affordances.</p>"},
 "standarderc20-gateway":{"title":"StandardERC20 gateway","text":"<p><a href=\"/intro/glossary#token-gateway\">Token Gateway</a> via which any L1 ERC20 token can permissionlessly bridge; the StandrardERC20 gateway contracts deploy a <a href=\"/intro/glossary#standard-arbtoken\">Standard Arb-Token</a> on L2 for each bridged token.</p>"},
-"stylus":{"title":"Stylus","text":"<p>Upcoming upgrade to the the <a href=\"/intro/glossary#arbitrum-nitro\">Arbitrum Nitro</a> virtual machine that will allow smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM (<a href=\"https://offchain.medium.com/hello-stylus-6b18fecc3a22\">read more</a>).</p>"},
+"stylus":{"title":"Stylus","text":"<p>Upcoming upgrade to the <a href=\"/intro/glossary#arbitrum-nitro\">Arbitrum Nitro</a> virtual machine that will allow smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM (<a href=\"https://offchain.medium.com/hello-stylus-6b18fecc3a22\">read more</a>).</p>"},
 "tales-of-elleria":{"title":"Tales of Elleria","text":"<p>The bow and arrow are commonly associated with the Hero's of Tales of Elleria.<br />\n<br />\nJump into the world of Elleria and go on adventures.</p>"},
 "toadstoolz":{"title":"Toadstoolz","text":"<p>Hidden in the Croakshire, you will find the friendly Toadstoolz. <br />\n<br />\nThe iconic Toads of Arbitrum love to hunt BUGZ <br />\n and collect NFTs. !CROAK</p>"},
 "token-gateway":{"title":"Token Gateway","text":"<p>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 include the <a href=\"/intro/glossary#standarderc20-gateway\">StandardERC20 gateway</a> , the <a href=\"/intro/glossary#genericcustom-gateway\">Generic-Custom Gateway</a> , and the <a href=\"/intro/glossary#weth-gateway\">WETH Gateway</a>.</p>"},
@@ -78,6 +78,6 @@
 "trustless":{"title":"Trustless","text":"<p>In the context of Ethereum, trustless refers to the ability of a system to operate without reliance on a central authority or intermediary. Instead, users place their trust in math and protocols.<br />\n<br />\nThis is achieved through the use of cryptographic techniques and decentralized consensus mechanisms that let users verify the integrity of network transactions using open-source software. Trustless systems are considered to be more secure and resistant to fraud or tampering because they don't rely on a single point of failure that can be exploited by attackers.</p>\n\n<p></p>\n\n"},
 "validator":{"title":"Validator","text":"<p>An <a href=\"/intro/glossary#arbitrum-full-node\">Arbitrum Full Node</a> that tracks the status of the chains' <a href=\"/intro/glossary#assertion\">Assertion</a>s. A validator may be a <a href=\"/intro/glossary#watchtower-validator\">Watchtower Validator</a>, a <a href=\"/intro/glossary#defensive-validator\">Defensive Validator</a>, or an <a href=\"/intro/glossary#active-validator\">Active Validator</a>. </p>"},
 "watchtower-validator":{"title":"Watchtower Validator","text":"<p>A <a href=\"/intro/glossary#validator\">Validator</a>  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.</p>"},
-"weth-gateway":{"title":"WETH Gateway","text":"<p><a href=\"/intro/glossary#token-gateway\">Token Gateway</a> for handing the bridging of wrapped Ether (WETH). WETH is upwraped on L1 and rewrapped on L1 upon depositing (and vice-versa upon withdrawing), ensuring WETH on L2 always remains collatoralized. </p>"},
+"weth-gateway":{"title":"WETH Gateway","text":"<p><a href=\"/intro/glossary#token-gateway\">Token Gateway</a> for handing the bridging of wrapped Ether (WETH). WETH is unwrapped on L1 and rewrapped on L1 upon depositing (and vice-versa upon withdrawing), ensuring WETH on L2 always remains collateralized. </p>"},
 "zeeverse":{"title":"Zeeverse","text":"<p>As you're exploring the Arbitrum world, you may bump into a world filled with monsters and Zee's.<br />\n<br />\nExplore a mythical Spirit Realm as a young Shaman and take part in strategic turn-based battles to help protect Zeeverse from the looming corrupted forces.</p>"}
 }