Merge pull request #233 from scroll-tech/develop

Update prod with latest PR cleanup

Author: dghelm

src/components/Tabs/TabsContent.tsx

@@ -0,0 +1,103 @@
+/** @jsxImportSource preact */
+import type { ComponentChild } from "preact"
+import { useRef } from "preact/hooks"
+import { useTabState } from "./useTabState"
+import styles from "./Tabs.module.css"
+import { clsx } from "~/lib"
+const tabSlotKey = "tab." as const
+const panelSlotKey = "panel." as const
+
+type TabSlot = `${typeof tabSlotKey}${string}`
+type PanelSlot = `${typeof panelSlotKey}${string}`
+
+function isTabSlotEntry(entry: [string, ComponentChild]): entry is [TabSlot, ComponentChild] {
+  const [key] = entry
+  return key.startsWith(tabSlotKey)
+}
+
+function isPanelSlotEntry(entry: [string, ComponentChild]): entry is [PanelSlot, ComponentChild] {
+  const [key] = entry
+  return key.startsWith(panelSlotKey)
+}
+
+function getBaseKeyFromTab(slot: TabSlot) {
+  return slot.replace(new RegExp(`^${tabSlotKey}`), "")
+}
+
+function getBaseKeyFromPanel(slot: PanelSlot) {
+  return slot.replace(new RegExp(`^${panelSlotKey}`), "")
+}
+
+type Props = {
+  [key: TabSlot | PanelSlot]: ComponentChild
+  sharedStore?: string
+}
+
+export function TabsContent({ sharedStore, ...slots }: Props) {
+  const tabs = Object.entries(slots).filter(isTabSlotEntry)
+  const panels = Object.entries(slots).filter(isPanelSlotEntry)
+
+  /** Used to focus next and previous tab on arrow key press */
+  const tabButtonRefs = useRef<Record<TabSlot, HTMLButtonElement | null>>({})
+
+  const firstPanelKey = panels[0] ? getBaseKeyFromPanel(panels[0][0]) : ""
+  const [curr, setCurrStore] = useTabState(firstPanelKey, sharedStore)
+
+  function moveFocus(event: KeyboardEvent) {
+    if (event.key === "ArrowLeft") {
+      const currIdx = tabs.findIndex(([key]) => getBaseKeyFromTab(key) === curr)
+      if (currIdx > 0) {
+        const [prevTabKey] = tabs[currIdx - 1]
+        setCurrStore(getBaseKeyFromTab(prevTabKey))
+        tabButtonRefs.current[prevTabKey]?.focus()
+      }
+    }
+    if (event.key === "ArrowRight") {
+      const currIdx = tabs.findIndex(([key]) => getBaseKeyFromTab(key) === curr)
+      if (currIdx < tabs.length - 1) {
+        const [nextTabKey] = tabs[currIdx + 1]
+        setCurrStore(getBaseKeyFromTab(nextTabKey))
+        tabButtonRefs.current[nextTabKey]?.focus()
+      }
+    }
+  }
+
+  return (
+    <div className={styles.contentContainer}>
+      <div role="tablist" onKeyDown={moveFocus}>
+        {tabs.map(([key, content]) => (
+          <button
+            ref={(el) => (tabButtonRefs.current[key] = el)}
+            onClick={() => {
+              setCurrStore(getBaseKeyFromTab(key))
+            }}
+            aria-selected={curr === getBaseKeyFromTab(key)}
+            tabIndex={curr === getBaseKeyFromTab(key) ? 0 : -1}
+            role="tab"
+            type="button"
+            data-astro-tab
+            id={key}
+            key={key}
+            class={clsx(
+              curr === getBaseKeyFromTab(key) ? styles.contentTabPrimary : styles.contentTabSecondary,
+              styles.contentTab
+            )}
+          >
+            {content}
+          </button>
+        ))}
+      </div>
+      {panels.map(([key, content]) => (
+        <div
+          hidden={curr !== getBaseKeyFromPanel(key)}
+          role="tabpanel"
+          aria-labelledby={`${tabSlotKey}${getBaseKeyFromPanel(key)}`}
+          key={key}
+          class={styles.panel}
+        >
+          {content}
+        </div>
+      ))}
+    </div>
+  )
+}

src/components/Tabs/index.ts

@@ -1 +1,3 @@
 export { Tabs } from "./Tabs"
+
+export { TabsContent } from "./TabsContent"

src/content/docs/en/article-components.mdx

@@ -14,6 +14,7 @@ import ToggleElement from "../../../components/ToggleElement.astro"
 import Aside from "../../../components/Aside.astro"
 import MarkmapView from "../../../components/MarkmapView/index.astro"
 import RPCTable from "../../../components/RPCTable/RPCTable.astro"
+import { Tabs, TabsContent } from "../../../components/Tabs"
 
 This is body text right under the article title. It typically is just paragraph text that's pretty straightforward. Then there's **bold text**, and _italic text_, and **_bold-italic text_**, and `inline-code` and **`bold inline code`** and even _`italic inline code`_ and **_`bold italic inline code`_**. And of course don't forget [links](#), and [**bold links**](#), and [_italic links_](#), and [**_bold-italic links_**](#).
 
@@ -164,6 +165,59 @@ stateDiagram
     step_context --> ConstraintBuilder
 ```
 
+### Tabs
+
+<Tabs client:visible>
+  <Fragment slot="tab.1">npm</Fragment>
+  <Fragment slot="tab.2">yarn</Fragment>
+  <Fragment slot="panel.1">```console npm install @chainlink/hardhat-chainlink ```</Fragment>
+  <Fragment slot="panel.2">```console yarn add @chainlink/hardhat-chainlink ```</Fragment>
+</Tabs>
+
+### TabsContent
+
+<TabsContent sharedStore="vrfMethod" client:visible>
+<Fragment slot="tab.1">Subscription</Fragment>
+<Fragment slot="tab.2">Direct funding</Fragment>
+<Fragment slot="panel.1">
+
+For Chainlink VRF v2 to fulfill your requests, you must maintain a sufficient amount of LINK in your subscription balance. Gas cost calculation includes the following variables:
+
+- **Gas price:** The current gas price, which fluctuates depending on network conditions.
+
+- **Callback gas:** The amount of gas used for the callback request that returns your requested random values.
+
+- **Verification gas:** The amount of gas used to verify randomness on-chain.
+
+The gas price depends on current network conditions. The callback gas depends on your callback function, and the number of random values in your request. The cost of each request is final only after the transaction is complete, but you define the limits you are willing to spend for the request with the following variables:
+
+- **Gas lane:** The maximum gas price you are willing to pay for a request in wei. Define this limit by specifying the appropriate `keyHash` in your request. The limits of each gas lane are important for handling gas price spikes when Chainlink VRF bumps the gas price to fulfill your request quickly.
+
+- **Callback gas limit:** Specifies the maximum amount of gas you are willing to spend on the callback request. Define this limit by specifying the `callbackGasLimit` value in your request.
+
+</Fragment>
+<Fragment slot="panel.2">
+
+For Chainlink VRF v2 to fulfill your requests, you must have a sufficient amount of LINK in your consuming contract. Gas cost calculation includes the following variables:
+
+- **Gas price:** The current gas price, which fluctuates depending on network conditions.
+
+- **Callback gas:** The amount of gas used for the callback request that returns your requested random values. The callback gas depends on your callback function and the number of random values in your request. Set the **callback gas limit** to specify the maximum amount of gas you are willing to spend on the callback request.
+
+- **Verification gas:** The amount of gas used to verify randomness on-chain.
+
+- **Wrapper overhead gas:** The amount of gas used by the VRF Wrapper contract. See the [Request and Receive Data](/vrf/v2/direct-funding#request-and-receive-data) section for details about the VRF v2 Wrapper contract design.
+
+Because the consuming contract directly pays the LINK for the request, the cost is calculated during the request and not during the callback when the randomness is fulfilled. Test your callback function to learn how to correctly estimate the callback gas limit.
+
+- If the gas limit is underestimated, the callback fails and the consuming contract is still charged for the work done to generate the requested random values.
+- If the gas limit is overestimated, the callback function will be executed but your contract is not refunded for the excess gas amount that you paid.
+
+Make sure that your consuming contracts are funded with enough LINK tokens to cover the transaction costs. If the consuming contract doesn't have enough LINK tokens, your request will revert.
+
+</Fragment>
+</TabsContent>
+
 ### RPC Table
 
 <RPCTable />

src/content/docs/en/developers/index.mdx

@@ -80,7 +80,7 @@ ensuring that all code executed on the Scroll Layer 2 behaves just as if it were
   <p>
     We know the challenges of building in the open and getting user engagement! Scroll has a blossoming community of
     users and builders, and with a Discord community of over 500,000 members eager to try out applications on our
-    testnet or mainnet, we’re excited to connect builders with users that can provide real-world feedback.
+    testnet or mainnet, we’re excited to connect builders with users who can provide real-world feedback.
   </p>
 </ToggleElement>
 

src/content/docs/en/developers/l1-and-l2-bridging.mdx

@@ -26,12 +26,12 @@ In addition to token transfers, the Scroll Messenger contract enables cross-chai
 
 <ClickToZoom src={L1GatewayWHITE} />
 
-There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter` . If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion.
+There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter`. If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion.
 
 ## L2 Gateway architecture
 
 <ClickToZoom src={withdrawWHITE} />
 
-Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger` . All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1.
+Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger`. All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1.
 
-In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities.
+In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities.

src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx

@@ -52,7 +52,7 @@ interface IScrollERC1155 {
   /// @notice Batch mint some token to recipient's account.
   /// @dev Gateway Utilities, only gateway contract can call
   /// @param _to The address of recipient.
-  /// @param _tokenIds The token id to mint.
+  /// @param _tokenIds The list of token ids to mint.
   /// @param _amounts The list of corresponding amount of token to mint.
   /// @param _data The data passed to recipient
   function batchMint(
@@ -158,5 +158,5 @@ Update the mapping that connects an ERC1155 token contract from L2 to L1.
 
 | Parameter | Description                                       |
 | --------- | ------------------------------------------------- |
-| \_l1Token | The address of th ERC1155 token in L1.            |
+| \_l1Token | The address of the ERC1155 token in L1.            |
 | \_l2Token | The address of corresponding ERC1155 token in L2. |

src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx

@@ -33,7 +33,7 @@ All Gateway contracts will form the message and send it to the `L1ScrollMessenge
   address of the `L1ScrollMessenger`. 
 </Aside>
 
-When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessagner` contract for execution on L2.
+When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessenger` contract for execution on L2.
 
 ## Withdraw ETH and ERC20 tokens from L2
 
@@ -76,7 +76,7 @@ interface IScrollStandardERC20 {
   /// @param _amount The amount of token to mint.
   function mint(address _to, uint256 _amount) external;
 
-  /// @notice Mint some token from account.
+  /// @notice Burn some token from account.
   /// @dev Gateway Utilities, only gateway contract can call
   /// @param _from The address of account to burn token.
   /// @param _amount The amount of token to mint.

src/content/docs/en/developers/verifying-smart-contracts.mdx

@@ -76,7 +76,7 @@ npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7
 ```
 
 <Aside type="danger" title="Warning">
-  You may receive an error stating `etherscan.apiKey.trim is not a function` . If so, you need to update
+  You may receive an error stating `etherscan.apiKey.trim is not a function`. If so, you need to update
   `@nomiclabs/hardhat-etherscan` to be able to support custom chains. Try running `npm update
   @nomiclabs/hardhat-etherscan`
 </Aside>
@@ -98,4 +98,4 @@ forge verify-contract <contract address> <contract name> \
 ```
 <Aside type="caution" title="Caution">
   Do not specify the chain ID.
-</Aside>
+</Aside>

src/content/docs/en/getting-started/overview.md

@@ -10,7 +10,7 @@ whatsnext: { "User Guide": "/en/user-guide/", "Building on Scroll": "/en/develop
 
 #### Welcome to the Scroll docs!
 
-Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive, and can support more users at once than Ethereum alone, and if you've ever used or developed an application on Ethereum, you'll be right at home on Scroll.
+Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive and can support more users at once than Ethereum alone. If you've ever used or developed an application on Ethereum, you'll be right at home on Scroll.
 
 Want to try out the Scroll Sepolia testnet with free assets before using Scroll? Check out our [User Guide](/user-guide/).
 
@@ -20,7 +20,7 @@ Scroll is building the technology to scale Ethereum.
 
 While Ethereum is the leading blockchain network for powering decentralized applications, its popularity also brings higher costs, creating a barrier to adoption for the next wave of users and developers.
 
-Leveraging cutting-edge research in zero knowledge proofs (”zk”), Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum.
+Leveraging cutting-edge research in zero knowledge (”zk”) proofs , Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum.
 
 Ultimately, Ethereum smart contracts verify that every transaction on Scroll is valid for these proofs, lending the network incredible security, decentralization, and censorship resistance. This level of security and scalability for Ethereum is only possible with recent breakthroughs in zero knowledge cryptography, blockchain protocol design, and hardware acceleration.
 

src/content/docs/en/learn/intro-to-rollups.md

@@ -10,7 +10,7 @@ whatsnext: { "Scroll Rollup Process": "/en/technology/chain/rollup" }
 
 ## What’s a rollup?
 
-Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem, and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap.
+Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap.
 
 A rollup processes batches of transactions off-chain (i.e. not on layer 1), and then posts the resulting data on-chain (i.e. on layer 1).
 
@@ -22,13 +22,13 @@ In order for a rollup to be secure, it must prove that its off-chain computation
 
 An optimistic rollup is a rollup that uses fraud proofs to assert the validity of its computation.
 
-Fraud proofs are a mechanism that allow users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed.
+Fraud proofs are a mechanism that allows users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed.
 
 ## What’s a ZK rollup?
 
 A ZK rollup is a rollup that uses validity proofs to assert the validity of its computation.
 
-When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state which results from correctly executing the batch of transactions.
+When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state that results from correctly executing the batch of transactions.
 
 Today, there are multiple types of ZK rollups, broadly defined as either zkVMs (zk Virtual Machines) or zkEVMs (zk Ethereum Virtual Machines).