From cdf32639ca09c34c066c7994379dc7b787035d3a Mon Sep 17 00:00:00 2001 From: Harry Kalodner Date: Mon, 16 Dec 2024 22:29:33 -0500 Subject: [PATCH] chore: Update generated content --- arbitrum-docs/partials/_glossary-partial.mdx | 2 +- .../_troubleshooting-stylus-partial.mdx | 2 +- website/static/building-orbit-faqs.json | 92 +--- website/static/building-stylus-faqs.json | 68 +-- website/static/glossary.json | 492 ++++-------------- 5 files changed, 129 insertions(+), 527 deletions(-) diff --git a/arbitrum-docs/partials/_glossary-partial.mdx b/arbitrum-docs/partials/_glossary-partial.mdx index c30481c51..18b0ec234 100644 --- a/arbitrum-docs/partials/_glossary-partial.mdx +++ b/arbitrum-docs/partials/_glossary-partial.mdx @@ -434,7 +434,7 @@ The STF (State Transition Function) defines how new blocks are produced from inp ### Stylus {#stylus}

-Upgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more). +Upgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more).

### Timeboost {#timeboost} diff --git a/arbitrum-docs/partials/_troubleshooting-stylus-partial.mdx b/arbitrum-docs/partials/_troubleshooting-stylus-partial.mdx index 80c58bc16..d701ee5e5 100644 --- a/arbitrum-docs/partials/_troubleshooting-stylus-partial.mdx +++ b/arbitrum-docs/partials/_troubleshooting-stylus-partial.mdx @@ -68,7 +68,7 @@ You deploy a Stylus contract the same way that Solidity contracts are deployed.

-You can find instructions for deploying a Stylus contract in our Quickstart. +You can find instructions for deploying a Stylus contract in our Quickstart.

diff --git a/website/static/building-orbit-faqs.json b/website/static/building-orbit-faqs.json index 066b9bfe8..1bded4aac 100644 --- a/website/static/building-orbit-faqs.json +++ b/website/static/building-orbit-faqs.json @@ -1,77 +1,17 @@ [ - { - "question": "Can I use Orbit to deploy a mainnet chain?", - "answer": "

\nYes! Arbitrum Orbit's core technology has undergone a comprehensive audit and is now able to support deployments to mainnet. You can read more about it here.\n

\n\n

\n\n

\n\n", - "key": "can-i-use-orbit-to-deploy-a-mainnet-chain" - }, - { - "question": "How can I deploy an Orbit-based Layer 3 (L3) chain?", - "answer": "

\nCheck our Quickstart to learn how to launch your own Orbit chain today.\n

\n\n

\n\n

\n\n", - "key": "how-can-i-deploy-an-orbitbased-layer-3-l3-chain" - }, - { - "question": "Do I need permission/license to launch an Orbit chain?", - "answer": "

\nYou can launch any Orbit chain permissionlessly. Nitro is licensed under a Business Source license, similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova. However, Orbit chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the AEP.\n

\n\n

\nNote that launching a testnet doesn't require any license.\n

\n\n

\n\n

\n\n", - "key": "do-i-need-permissionlicense-to-launch-an-orbit-chain" - }, - { - "question": "Does Arbitrum officially deploy and/or maintain L3s for external teams?", - "answer": "

\nNo. Teams are required to deploy and maintain their Orbit chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain the Orbit chain for you.\n

\n\n

\n\n

\n\n", - "key": "does-arbitrum-officially-deploy-andor-maintain-l3s-for-external-teams" - }, - { - "question": "Can I modify Orbit's underlying technology to customize my chain?", - "answer": "

\nYes, you can make any changes you require to the underlying Nitro code base.\n

\n\n

\n\n

\n\n", - "key": "can-i-modify-orbits-underlying-technology-to-customize-my-chain" - }, - { - "question": "What Data Availability (DA) solutions are currently available for Orbit chains?", - "answer": "

\nArbitrum Orbit currently supports 3 different DA solutions:\n

\n\n\n

\nNote that using AnyTrust gives the chain owner the most flexibility and cheapest fees.\n

\n\n

\n\n

\n\n", - "key": "what-data-availability-da-solutions-are-currently-available-for-orbit-chains" - }, - { - "question": "What token is used to pay gas fees on Orbit chains?", - "answer": "

\nBy default, Orbit chains pay gas in ETH. However, Orbit chains using AnyTrust can be configured to use any ERC-20 token as the gas fee token of the chain.\n

\n\n

\n\n

\n\n", - "key": "what-token-is-used-to-pay-gas-fees-on-orbit-chains" - }, - { - "question": "Can I use Ethereum toolkits to develop on my Orbit chain?", - "answer": "

\nOrbit chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Orbit chain. There are, however, certain differences that developers need to keep in mind when building on an Orbit chain. You can find them here.\n

\n\n

\n\n

\n\n", - "key": "can-i-use-ethereum-toolkits-to-develop-on-my-orbit-chain" - }, - { - "question": "Do Orbit chains have any built-in AA solution?", - "answer": "

\nNot by default, but they can be customized to have native AA.\n

\n\n", - "key": "do-orbit-chains-have-any-builtin-aa-solution" - }, - { - "question": "Is there any cross-chain bridging solution between two Orbit chains?", - "answer": "

\nThere is currently no Orbit-to-Orbit native bridging solution, other than going through the parent chain (if they share the same parent chain). However, there are many third-party bridges that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n", - "key": "is-there-any-crosschain-bridging-solution-between-two-orbit-chains" - }, - { - "question": "Is there an official block explorer for Orbit chains?", - "answer": "

\nOrbit chains deployments usually come with an open-source blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n", - "key": "is-there-an-official-block-explorer-for-orbit-chains" - }, - { - "question": "Is there any indexing solution that supports Orbit chains?", - "answer": "

\nSimilar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n", - "key": "is-there-any-indexing-solution-that-supports-orbit-chains" - }, - { - "question": "Can I increase the maximum contract size for my Orbit chain?", - "answer": "

\nYes, Orbit supports an increased smart contract size limit of up to 96kB. You can use our Orbit SDK and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig. Note that the smart contract size limit parameters can't be changed via upgrade after deployment.\n

\n\n

\n\n

\n\n", - "key": "can-i-increase-the-maximum-contract-size-for-my-orbit-chain" - }, - { - "question": "How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?", - "answer": "

\nForcing an invalid assertion in the chain is not supported at the moment. However, if you're building Nitro locally, you can run the following test that goes through the whole rollup/challenge mechanism:\n

\n\n```shell\ngo test ./system_tests/ -tags=challengetest -run=TestChallenge\n\n```\n

\n\n

\n\n", - "key": "how-can-i-modify-nitro-to-force-posting-an-invalid-assertion-and-test-the-fraud-proof-mechanism" - }, - { - "question": "What fee collectors can be configured on my chain?", - "answer": "

\nThere are 4 fee types that can be configured on an Orbit chain:\n

\n\n\n

\nMore detailed information about fees can be found in the L1 fees and L2 fees pages.\n

\n\n

\nInformation about the precompiles methods can be found in the Precompiles reference page.\n

\n\n", - "key": "what-fee-collectors-can-be-configured-on-my-chain" - } -] +{"question": "Can I use Orbit to deploy a mainnet chain?","answer": "

\nYes! Arbitrum Orbit's core technology has undergone a comprehensive audit and is now able to support deployments to mainnet. You can read more about it here.\n

\n\n

\n\n

\n\n","key": "can-i-use-orbit-to-deploy-a-mainnet-chain"}, +{"question": "How can I deploy an Orbit-based Layer 3 (L3) chain?","answer": "

\nCheck our Quickstart to learn how to launch your own Orbit chain today.\n

\n\n

\n\n

\n\n","key": "how-can-i-deploy-an-orbitbased-layer-3-l3-chain"}, +{"question": "Do I need permission/license to launch an Orbit chain?","answer": "

\nYou can launch any Orbit chain permissionlessly. \n

\n\n

\nNitro is licensed under a Business Source license, similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova. \n

\n\n

\nHowever, Orbit chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the AEP.\n

\n\n

\n\n

\n\n

\n\n

\n\n","key": "do-i-need-permissionlicense-to-launch-an-orbit-chain"}, +{"question": "Does Arbitrum officially deploy and/or maintain L3s for external teams?","answer": "

\nNo. Teams are required to deploy and maintain their Orbit chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain the Orbit chain for you.\n

\n\n

\n\n

\n\n","key": "does-arbitrum-officially-deploy-andor-maintain-l3s-for-external-teams"}, +{"question": "Can I modify Orbit's underlying technology to customize my chain?","answer": "

\nYes, you can make any changes you require to the underlying Nitro code base.\n

\n\n

\n\n

\n\n","key": "can-i-modify-orbits-underlying-technology-to-customize-my-chain"}, +{"question": "What Data Availability (DA) solutions are currently available for Orbit chains?","answer": "

\nArbitrum Orbit currently supports 3 different DA solutions:\n

\n\n\n

\nNote that using AnyTrust gives the chain owner the most flexibility and cheapest fees.\n

\n\n

\n\n

\n\n","key": "what-data-availability-da-solutions-are-currently-available-for-orbit-chains"}, +{"question": "What token is used to pay gas fees on Orbit chains?","answer": "

\nBy default, Orbit chains pay gas in ETH. However, Orbit chains using AnyTrust can be configured to use any ERC-20 token as the gas fee token of the chain.\n

\n\n

\n\n

\n\n","key": "what-token-is-used-to-pay-gas-fees-on-orbit-chains"}, +{"question": "Can I use Ethereum toolkits to develop on my Orbit chain?","answer": "

\nOrbit chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Orbit chain. There are, however, certain differences that developers need to keep in mind when building on an Orbit chain. You can find them here.\n

\n\n

\n\n

\n\n","key": "can-i-use-ethereum-toolkits-to-develop-on-my-orbit-chain"}, +{"question": "Do Orbit chains have any built-in AA solution?","answer": "

\nNot by default, but they can be customized to have native AA.\n

\n\n","key": "do-orbit-chains-have-any-builtin-aa-solution"}, +{"question": "Is there any cross-chain bridging solution between two Orbit chains?","answer": "

\nThere is currently no Orbit-to-Orbit native bridging solution, other than going through the parent chain (if they share the same parent chain). However, there are many third-party bridges that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n","key": "is-there-any-crosschain-bridging-solution-between-two-orbit-chains"}, +{"question": "Is there an official block explorer for Orbit chains?","answer": "

\nOrbit chains deployments usually come with an open-source blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n","key": "is-there-an-official-block-explorer-for-orbit-chains"}, +{"question": "Is there any indexing solution that supports Orbit chains?","answer": "

\nSimilar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Orbit chains.\n

\n\n

\n\n

\n\n","key": "is-there-any-indexing-solution-that-supports-orbit-chains"}, +{"question": "Can I increase the maximum contract size for my Orbit chain?","answer": "

\nYes, Orbit supports an increased smart contract size limit of up to 96kB. You can use our Orbit SDK and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig. Note that the smart contract size limit parameters can't be changed via upgrade after deployment.\n

\n\n

\n\n

\n\n","key": "can-i-increase-the-maximum-contract-size-for-my-orbit-chain"}, +{"question": "How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?","answer": "

\nForcing an invalid assertion in the chain is not supported at the moment. However, if you're building Nitro locally, you can run the following test that goes through the whole rollup/challenge mechanism:\n

\n\n```shell\ngo test ./system_tests/ -tags=challengetest -run=TestChallenge\n\n```\n

\n\n

\n\n","key": "how-can-i-modify-nitro-to-force-posting-an-invalid-assertion-and-test-the-fraud-proof-mechanism"}, +{"question": "What fee collectors can be configured on my chain?","answer": "

\nThere are 4 fee types that can be configured on an Orbit chain:\n

\n\n\n

\nMore detailed information about fees can be found in the L1 fees and L2 fees pages.\n

\n\n

\nInformation about the precompiles methods can be found in the Precompiles reference page.\n

\n\n","key": "what-fee-collectors-can-be-configured-on-my-chain"} +] \ No newline at end of file diff --git a/website/static/building-stylus-faqs.json b/website/static/building-stylus-faqs.json index 1846a8eeb..5baef3006 100644 --- a/website/static/building-stylus-faqs.json +++ b/website/static/building-stylus-faqs.json @@ -1,57 +1,13 @@ [ - { - "question": "How does Stylus manage security issues in smart contracts when interacting with so many different languages?", - "answer": "

\nAll languages are compiled to WASM for them to be able to work with Stylus. So it just needs to verify that the produced WASM programs behave as they should inside the new virtual machine.\n

\n\n

\n\n

\n\n", - "key": "how-does-stylus-manage-security-issues-in-smart-contracts-when-interacting-with-so-many-different-languages" - }, - { - "question": "Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK?", - "answer": "

\nCurrently there isn't any analogue. However, you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call.\n

\n\n

\n\n

\n\n", - "key": "is-there-any-analogue-of-the-fallback-function-from-solidity-in-the-rust-stylus-sdk" - }, - { - "question": "Why are constructors not yet supported for Stylus contracts?", - "answer": "

\nConstructors use EVM bytecode to initialize state. While one could add EVM bytecode manually to their Stylus deployment, we don't allow WASM execution in the constructor so there's no way to express this in the SDK.\n

\n\n

\nWe're working on models that will make init easier, so there might be better solutions available in the future. For now, we suggest calling an init method after deploying.\n

\n\n

\n\n

\n\n", - "key": "why-are-constructors-not-yet-supported-for-stylus-contracts" - }, - { - "question": "Is it possible to verify Stylus contracts on the block explorer?", - "answer": "

\nCurrently it is not possible to verify contracts compiled to WASM on the block explorer, but we are actively working with providers to have the verification process ready for when Stylus reaches mainnet-ready status.\n

\n\n

\n\n

\n\n", - "key": "is-it-possible-to-verify-stylus-contracts-on-the-block-explorer" - }, - { - "question": "Do Stylus contracts compile down to EVM bytecode like prior other attempts?", - "answer": "

\nNo. Stylus contracts are compiled down to WASM. The user writes a program in Rust / C / C++ which is then compiled down to WebAssembly.\n

\n\n

\n\n

\n\n", - "key": "do-stylus-contracts-compile-down-to-evm-bytecode-like-prior-other-attempts" - }, - { - "question": "How is a Stylus contract deployed?", - "answer": "

\nStylus contracts are deployed on chain as a blob of bytes, just like EVM ones. The only difference is that when the contract is executed, instead of invoking the EVM, we invoke a separate WASM runtime. Note that a special EOF-inspired prefix distinguishes Stylus contracts from traditional EVM contracts: when a contract's bytecode starts with the magic 0xEFF00000 prefix, it's a Stylus WASM contract.\n

\n\n

\n\n

\n\n", - "key": "how-is-a-stylus-contract-deployed" - }, - { - "question": "Is there a new transaction type to deploy Stylus contracts?", - "answer": "

\nYou deploy a Stylus contract the same way that Solidity contracts are deployed. There are no special transaction types. As a UX note: a WASM will revert until a special instrumentation operation is performed by a call to the new  ArbWasm precompile, which readies the program for calls on-chain.\n

\n\n

\nYou can find instructions for deploying a Stylus contract in our Quickstart.\n

\n\n", - "key": "is-there-a-new-transaction-type-to-deploy-stylus-contracts" - }, - { - "question": "Do Stylus contracts use a different type of ABI?", - "answer": "

\nStylus contracts use solidity ABIs. Methods, signatures, logs, calls, etc. work exactly as in the EVM. From a user's / explorer's perspective, it all just looks and behaves like solidity.\n

\n\n

\n\n

\n\n", - "key": "do-stylus-contracts-use-a-different-type-of-abi" - }, - { - "question": "Does the Stylus SDK for Rust support custom data structures?", - "answer": "

\nFor in-memory usage, you should be able to use any implementation of custom data structures without problems.\n

\n\n

\nFor storage usage, it might be a bit more complicated. Stylus uses the EVM storage system, so you'll need to define the data structure on top of it. However, in the SDK there's a storage trait that custom types can implement to back their collections with the EVM state trie. The SDK macros are compatible with them too, although fundamentally it's still a global key-value system.\n

\n\n

\nYou can read more about it in the Stylus Rust SDK page.\n

\n\n

\nAs an alternative solution, you can use entrypoint-style contracts for your custom data structures.\n

\n\n

\n\n

\n\n

\n\n

\n\n", - "key": "does-the-stylus-sdk-for-rust-support-custom-data-structures" - }, - { - "question": "Why do I get an error \"no library targets found in package\" when trying to compile and old example?", - "answer": "

\nSome of the first Stylus examples were built and deployed using a previous version of cargo-stylus (0.1.x). In that version, Stylus projects were structured as regular Rust binaries.\n

\n\n

\nSince cargo-stylus v0.2.1, Stylus projects are structured as libraries, so when trying to compile old projects you might get an error no library targets found in package.\n

\n\n

\nTo solve this, it's usually enough to rename the main.rs file to a lib.rs file.\n

\n\n

\n\n

\n\n", - "key": "why-do-i-get-an-error-no-library-targets-found-in-package-when-trying-to-compile-and-old-example" - }, - { - "question": "How can I generate the ABI of my Stylus contract?", - "answer": "

\nThe cargo-stylus tool has a command that allows you to export the ABI of your Stylus contract: cargo stylus export-abi.\n

\n\n

\nIf you're using the Stylus Rust SDK, you'll need to enable the export-abi feature in your Cargo.toml file like so:\n

\n\n```rust\n[features]\nexport-abi = [\"stylus-sdk/export-abi\"]\n```\n

\nYou'll also need to have a main.rs file that selects that feature.\n

\n\n

\nThis is an example of a main.rs file that allows you to export the abi of the stylus-hello-world example project:\n

\n\n```rust\n#![cfg_attr(not(feature = \"export-abi\"), no_main)]\n\n#[cfg(feature = \"export-abi\")]\nfn main() {\n stylus_hello_world::main();\n}\n```\n

\n\n

\n\n", - "key": "how-can-i-generate-the-abi-of-my-stylus-contract" - } -] +{"question": "How does Stylus manage security issues in smart contracts when interacting with so many different languages?","answer": "

\nAll languages are compiled to WASM for them to be able to work with Stylus. So it just needs to verify that the produced WASM programs behave as they should inside the new virtual machine.\n

\n\n

\n\n

\n\n","key": "how-does-stylus-manage-security-issues-in-smart-contracts-when-interacting-with-so-many-different-languages"}, +{"question": "Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK?","answer": "

\nCurrently there isn't any analogue. However, you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call.\n

\n\n

\n\n

\n\n","key": "is-there-any-analogue-of-the-fallback-function-from-solidity-in-the-rust-stylus-sdk"}, +{"question": "Why are constructors not yet supported for Stylus contracts?","answer": "

\nConstructors use EVM bytecode to initialize state. While one could add EVM bytecode manually to their Stylus deployment, we don't allow WASM execution in the constructor so there's no way to express this in the SDK.\n

\n\n

\nWe're working on models that will make init easier, so there might be better solutions available in the future. For now, we suggest calling an init method after deploying.\n

\n\n

\n\n

\n\n","key": "why-are-constructors-not-yet-supported-for-stylus-contracts"}, +{"question": "Is it possible to verify Stylus contracts on the block explorer?","answer": "

\nCurrently it is not possible to verify contracts compiled to WASM on the block explorer, but we are actively working with providers to have the verification process ready for when Stylus reaches mainnet-ready status.\n

\n\n

\n\n

\n\n","key": "is-it-possible-to-verify-stylus-contracts-on-the-block-explorer"}, +{"question": "Do Stylus contracts compile down to EVM bytecode like prior other attempts?","answer": "

\nNo. Stylus contracts are compiled down to WASM. The user writes a program in Rust / C / C++ which is then compiled down to WebAssembly.\n

\n\n

\n\n

\n\n","key": "do-stylus-contracts-compile-down-to-evm-bytecode-like-prior-other-attempts"}, +{"question": "How is a Stylus contract deployed?","answer": "

\nStylus contracts are deployed on chain as a blob of bytes, just like EVM ones. The only difference is that when the contract is executed, instead of invoking the EVM, we invoke a separate WASM runtime. Note that a special EOF-inspired prefix distinguishes Stylus contracts from traditional EVM contracts: when a contract's bytecode starts with the magic 0xEFF00000 prefix, it's a Stylus WASM contract.\n

\n\n

\n\n

\n\n","key": "how-is-a-stylus-contract-deployed"}, +{"question": "Is there a new transaction type to deploy Stylus contracts?","answer": "

\nYou deploy a Stylus contract the same way that Solidity contracts are deployed. There are no special transaction types. As a UX note: a WASM will revert until a special instrumentation operation is performed by a call to the new  ArbWasm precompile, which readies the program for calls on-chain.\n

\n\n

\nYou can find instructions for deploying a Stylus contract in our Quickstart.\n

\n\n","key": "is-there-a-new-transaction-type-to-deploy-stylus-contracts"}, +{"question": "Do Stylus contracts use a different type of ABI?","answer": "

\nStylus contracts use solidity ABIs. Methods, signatures, logs, calls, etc. work exactly as in the EVM. From a user's / explorer's perspective, it all just looks and behaves like solidity.\n

\n\n

\n\n

\n\n","key": "do-stylus-contracts-use-a-different-type-of-abi"}, +{"question": "Does the Stylus SDK for Rust support custom data structures?","answer": "

\nFor in-memory usage, you should be able to use any implementation of custom data structures without problems.\n

\n\n

\nFor storage usage, it might be a bit more complicated. Stylus uses the EVM storage system, so you'll need to define the data structure on top of it. However, in the SDK there's a storage trait that custom types can implement to back their collections with the EVM state trie. The SDK macros are compatible with them too, although fundamentally it's still a global key-value system.\n

\n\n

\nYou can read more about it in the Stylus Rust SDK page.\n

\n\n

\nAs an alternative solution, you can use entrypoint-style contracts for your custom data structures.\n

\n\n

\n\n

\n\n

\n\n

\n\n","key": "does-the-stylus-sdk-for-rust-support-custom-data-structures"}, +{"question": "Why do I get an error \"no library targets found in package\" when trying to compile and old example?","answer": "

\nSome of the first Stylus examples were built and deployed using a previous version of cargo-stylus (0.1.x). In that version, Stylus projects were structured as regular Rust binaries.\n

\n\n

\nSince cargo-stylus v0.2.1, Stylus projects are structured as libraries, so when trying to compile old projects you might get an error no library targets found in package.\n

\n\n

\nTo solve this, it's usually enough to rename the main.rs file to a lib.rs file.\n

\n\n

\n\n

\n\n","key": "why-do-i-get-an-error-no-library-targets-found-in-package-when-trying-to-compile-and-old-example"}, +{"question": "How can I generate the ABI of my Stylus contract?","answer": "

\nThe cargo-stylus tool has a command that allows you to export the ABI of your Stylus contract: cargo stylus export-abi.\n

\n\n

\nIf you're using the Stylus Rust SDK, you'll need to enable the export-abi feature in your Cargo.toml file like so:\n

\n\n```rust\n[features]\nexport-abi = [\"stylus-sdk/export-abi\"]\n```\n

\nYou'll also need to have a main.rs file that selects that feature.\n

\n\n

\nThis is an example of a main.rs file that allows you to export the abi of the stylus-hello-world example project:\n

\n\n```rust\n#![cfg_attr(not(feature = \"export-abi\"), no_main)]\n\n#[cfg(feature = \"export-abi\")]\nfn main() {\n stylus_hello_world::main();\n}\n```\n

\n\n

\n\n","key": "how-can-i-generate-the-abi-of-my-stylus-contract"} +] \ No newline at end of file diff --git a/website/static/glossary.json b/website/static/glossary.json index 85784af0e..3ae3cd4e2 100644 --- a/website/static/glossary.json +++ b/website/static/glossary.json @@ -1,394 +1,100 @@ { - "active-validator": { - "title": "Active Validator", - "text": "

\nA staked Validator that makes disputable assertions to advance the state of an Arbitrum chain or to challenge the validity of others' assertions. (Not to be confused with the Sequencer ).\n

" - }, - "address-alias": { - "title": "Address Alias", - "text": "

\nAn address deterministically generated from an L1 contract address used on L2 to safely identify the source of an L1 to L2 message.\n

" - }, - "arb-token-bridge": { - "title": "Arb Token Bridge", - "text": "

\nA series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.\n

" - }, - "arbified-token-list": { - "title": "Arbified Token List", - "text": "

\nA token list that conforms to Uniswap's token list specification; Arbified lists are generated by inputting externally maintained list (i.e., coinmarketcap's list) and outputting a list that includes all of the instances of token contracts on the Arbitrum chain bridged via the canonical Arb Token Bridge from tokens on the inputted list. (See code here.)\n

" - }, - "arbitrum": { - "title": "Arbitrum", - "text": "

\nA suite of Ethereum layer-2 scaling technologies built with the Arbitrum Nitro tech stack that includes Arbitrum One (a live implementation of the Arbitrum Rollup Protocol) and Arbitrum Nova (a live implementation of the Arbitrum AnyTrust Protocol).\n

" - }, - "arbitrum-anytrust-chain": { - "title": "Arbitrum AnyTrust Chain", - "text": "

\nAn Arbitrum chain that implements the Arbitrum AnyTrust Protocol.\n

" - }, - "arbitrum-anytrust-protocol": { - "title": "Arbitrum AnyTrust Protocol", - "text": "

\nAn Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). This protocol reduces transaction fees by introducing an additional trust assumption for data availability in lieu of Ethereum's Trustless data availability mechanism. Arbitrum Nova is an example of an AnyTrust chain; Arbitrum One is an alternative chain that implements the purely trustless (and more L1-gas intensive) Arbitrum Rollup Protocol.\n

" - }, - "arbitrum-bridge-ui": { - "title": "Arbitrum Bridge UI", - "text": "

\nWeb application built and maintained by Offchain Labs for user-interactions with the Arb Token Bridge; visit it here.\n

" - }, - "arbitrum-chain": { - "title": "Arbitrum chain", - "text": "

\nA blockchain that runs on the Arbitrum protocol. Arbitrum chains are EVM compatible, and use an underlying EVM chain (e.g., Ethereum) for settlement and for succinct fraud-proofs (as needed). Arbitrum chains come in two forms: Arbitrum Rollup Chains and Arbitrum AnyTrust Chains. \n

" - }, - "arbitrum-classic": { - "title": "Arbitrum Classic", - "text": "

\nOld Arbitrum stack that used custom virtual machine (\"AVM\"); no public Arbitrum chain uses the classic stack as of 8/31/2022 (they instead use Arbitrum Nitro ).\n

" - }, - "arbitrum-full-node": { - "title": "Arbitrum Full Node", - "text": "

\nA party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-staking L1 Ethereum node.\n

" - }, - "arbitrum-nitro": { - "title": "Arbitrum Nitro", - "text": "

\nCurrent Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.\n

" - }, - "arbitrum-nova": { - "title": "Arbitrum Nova", - "text": "

\nThe first Arbitrum AnyTrust Chain running on Ethereum mainnet. Introduces cheaper transactions; great for gaming and social use-cases. Implements the Arbitrum AnyTrust Protocol, not the Arbitrum Rollup Protocol protocol. Governed by the Arbitrum DAO.\n

" - }, - "arbitrum-one": { - "title": "Arbitrum One", - "text": "

\nThe first Arbitrum Rollup Chain running on Ethereum mainnet. Great for decentralized finance and other use-cases that demand strong security guarantees. Governed by the Arbitrum DAO.\n

" - }, - "arbitrum-orbit": { - "title": "Arbitrum Orbit", - "text": "

\nArbitrum Orbit refers to the ability for anyone to permissionlessly deploy Layer 3 (L3) chains on top of Arbitrum Layer 2 (L2) chains.\n

" - }, - "arbitrum-rollup-chain": { - "title": "Arbitrum Rollup Chain", - "text": "

\nAn Arbitrum chain that implements the Arbitrum Rollup Protocol.\n

" - }, - "arbitrum-rollup-protocol": { - "title": "Arbitrum Rollup Protocol", - "text": "

\nA trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain. \n

" - }, - "arbos": { - "title": "ArbOS", - "text": "

\nArbitrum's \"operating system\" that trustlessly handles system-level operations; includes the ability to emulate the EVM.\n

" - }, - "assertion": { - "title": "Assertion", - "text": "

\nA staked claim by an Arbitrum Validator. An assertion may, e.g., propose a new RBlock, or may be a step in a Challenge.\n

" - }, - "auction-contract": { - "title": "Auction Contract", - "text": "

\nA smart contract that handles the state, accounting of funds for bids, and various operations of the Timeboost auction. The contract is deployed on the target chain for which Timeboost is enabled.\n

" - }, - "autonomous-auctioneer": { - "title": "Autonomous Auctioneer", - "text": "

\nOff chain software that receives bids from Timeboost participants, processes and validates bids, and then posts the top valid bid (or top two valid bids in the case of a tie) to the Auction Contract to resolve the on-going Timeboost auction. The autonomous auctioneer, for a given chain, is provisioned & deployed by an entity designated by the chain's owner.\n

" - }, - "batch": { - "title": "Batch", - "text": "

\nA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Fast Inbox by the Sequencer.\n

" - }, - "blockchain": { - "title": "Blockchain", - "text": "

\nA distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols. \n

" - }, - "bls-signature": { - "title": "BLS Signature", - "text": "

\nA cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.\n

" - }, - "bold": { - "title": "BoLD", - "text": "

\nShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). Not currently on mainnet. \n

" - }, - "bridge": { - "title": "Bridge", - "text": "

\nA set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain. \n

" - }, - "chain-owner": { - "title": "Chain Owner", - "text": "

\nAn entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.\n

" - }, - "chain-state": { - "title": "Chain state", - "text": "

\nA particular point in the history of an Arbitrum chain. A chain's state is determined by applying Arbitrum state-transition function to sequence of transactions (i.e., the chain's history).\n

" - }, - "challenge": { - "title": "Challenge", - "text": "

\nWhen two Stakers disagree about the correct verdict on an Assertion, those stakers can be put in a challenge. The challenge is refereed by the contracts on the underlying chain. Eventually one staker wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their stake. \n

" - }, - "challenge-period": { - "title": "Challenge Period", - "text": "

\nWindow of time (1 week on Arbitrum One) over which an asserted RBlock can be challenged, and after which the RBlock can be confirmed.\n

" - }, - "challenge-protocol": { - "title": "Challenge protocol", - "text": "

\nThe protocol by which RBlocks are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid RBlocks will be confirmed provided that there is at least one honest Active Validator.\n

" - }, - "child-chain": { - "title": "Child chain", - "text": "

\nAn Arbitrum Chain that settles to an underlying Parent chain . For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.\n

" - }, - "client": { - "title": "Client", - "text": "

\nA 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.\n

" - }, - "confirmation": { - "title": "Confirmation", - "text": "

\nThe decision by an Arbitrum chain to finalize an RBlock as part of the chain's history. Once an RBlock is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.\n

" - }, - "crosschain-message": { - "title": "Cross-chain message", - "text": "

\nAn action taken on some chain A which asynchronously initiates an additional action on chain B. \n

" - }, - "custom-arbtoken": { - "title": "Custom Arb-Token", - "text": "

\nAny 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 ).\n

" - }, - "custom-gateway": { - "title": "Custom gateway", - "text": "

\nAny Token Gateway that isn't the StandardERC20 gateway.\n

" - }, - "dapp": { - "title": "dApp", - "text": "

\nShort for \"decentralized application.\" A dApp typically consists of smart contracts as well as a user-interface for interacting with them.\n

" - }, - "data-availability-certificate": { - "title": "Data Availability Certificate", - "text": "

\nSigned promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.\n

" - }, - "data-availability-committee-dac": { - "title": "Data Availability Committee (DAC)", - "text": "

\nA permissioned set of parties responsible for enforcing data availability in an Arbitrum AnyTrust Protocol chain. See Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions to learn more.\n

\n\n" - }, - "defensive-validator": { - "title": "Defensive Validator", - "text": "

\nA Validator that watches an Arbitrum chain and takes action (i.e., stakes and challenges) only when and if an invalid Assertion occurs.\n

" - }, - "delayed-inbox": { - "title": "Delayed Inbox", - "text": "

\nA contract that holds Parent chain initiated messages to be eventually included in the Fast Inbox. Inclusion of messages doesn't depend on the Sequencer.\n

" - }, - "devtools-dashboard": { - "title": "Dev-Tools Dashboard", - "text": "

\nWeb application built and maintained by Offchain Labs for developers and users to debug Arbitrum transactions; i.e., executing or checking the status of Cross-chain messages; visit it here. \n

" - }, - "dissection": { - "title": "Dissection", - "text": "

\nA step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.\n

" - }, - "ethereum-wallet": { - "title": "Ethereum Wallet", - "text": "

\nA software application used for transacting with the Ethereum Blockchain.\n

" - }, - "evm": { - "title": "EVM+", - "text": "

\nThe paradigm introduced by Stylus in which Arbitrum's EVM compatibility is preserved while new features and improvements are introduced.\n

" - }, - "express-lane": { - "title": "Express Lane", - "text": "

\nA component of Timeboost, the express lane is a special endpoint on the Sequencer that immediately sequences incoming, valid transactions signed by the current express lane controller. \n

" - }, - "express-lane-controller": { - "title": "Express Lane Controller", - "text": "

\nAn address, defined in the Auction Contract, that is granted the privilege to use the Express Lane. These privileges are granted after verifying that the incoming transactions were properly signed by the express lane controller, among other checks.\n

" - }, - "fair-ordering-algorithm": { - "title": "Fair Ordering Algorithm", - "text": "

\nBFT algorithm in which a committee comes to consensus on transaction ordering; current single-party Sequencer on Arbitrum may eventually be replaced by a fair-ordering committee.\n

" - }, - "fast-exit--liquidity-exit": { - "title": "Fast Exit / Liquidity Exit", - "text": "

\nA means by which a user can bypass an Arbitrum chain's Challenge Period when withdrawing fungible assets (or more generally, executing some \"fungible\" L2 to L1 operation); for trustless fast exits, a liquidity provider facilitates an atomic swap of the asset on L2 directly to L1.\n

" - }, - "fast-inbox": { - "title": "Fast Inbox", - "text": "

\nContract that holds a sequence of messages sent by clients to an Arbitrum Chain; a message can be put into the fast Inbox directly by the Sequencer or indirectly through the Delayed Inbox.\n

" - }, - "first-come-first-serve-fcfs": { - "title": "First Come First Serve (FCFS)", - "text": "

\nA type of Transaction Ordering Policy used by the sequencer in Arbitrum chains whereby incoming transactions are sequenced into a block in the order that the transactions arrived.\n

" - }, - "forceinclusion": { - "title": "Force-Inclusion", - "text": "

\nCensorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.\n

" - }, - "fraud-proof": { - "title": "Fraud proof", - "text": "

\nThe means by which an Active Validator proves to its underlying chain that an invalid state transition has taken place.\n

" - }, - "gas-price-floor": { - "title": "Gas Price Floor", - "text": "

\nProtocol-enforced minimum gas price on an Arbitrum chain; currently 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova.\n

" - }, - "gateway-router": { - "title": "Gateway Router", - "text": "

\nContracts in the Arb Token Bridge responsible for mapping tokens to their appropriate Token Gateway.\n

" - }, - "genericcustom-gateway": { - "title": "Generic-Custom Gateway", - "text": "

\nA particular Custom gateway via which an L1 token contract can be registered to a token contract deployed to L2. A useful alternative to the StandardERC20 gateway for projects that wish to control the address of their L2 token contract, maintain L2 token contract upgradability, and for various other use-cases. \n

" - }, - "geth": { - "title": "Geth", - "text": "

\nAn execution-layer client that defines the Ethereum state transition function and handles network-layer logic like transaction memory pooling. Arbitrum Nitro utilizes a fork of Geth to implement Arbitrum's state transition function.\n

" - }, - "ink": { - "title": "Ink", - "text": "

\nThe equivalent of gas in the Stylus vm. Ink is introduced for finer granularity than gas offers since Stylus's operations are considerably cheaper than their EVM analogs. \n

" - }, - "l2-block": { - "title": "L2 Block", - "text": "

\nData structure that represents a group of L2 transactions (analogous to L1 blocks).\n

" - }, - "l2-to-l1-message": { - "title": "L2 to L1 Message", - "text": "

\nA message initiated from within an Arbitrum chain to be eventually executed on Layer 1 (L1) (e.g., token or Ether withdrawals). On Rollup chains like Arbitrum One, the Challenge Period must pass before an L2 to L1 message is executed.\n

" - }, - "layer-1-l1": { - "title": "Layer 1 (L1)", - "text": "

\nThe base protocol and underlying blockchain of the Ethereum network. Responsible for maintaining the integrity of the distributed ledger and executing smart contracts. Contains both Ethereum's execution layer and consensus layer.\n

" - }, - "layer-2-l2": { - "title": "Layer 2 (L2)", - "text": "

\nTrustless scaling solutions built on top of Ethereum's Layer 1 (L1) base protocol, such as state channels, plasma chains, optimistic rollups, and ZK-rollups. Layer 2 solutions aim to increase scalability and reduce the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions.\n

" - }, - "layer-3-l3": { - "title": "Layer 3 (L3)", - "text": "

\nAn Arbitrum chain whose core contract reside on an Arbitrum Layer 2 (L2) chain.\n

" - }, - "native-fee-token": { - "title": "Native Fee Token", - "text": "

\nAn ERC-20 token used as the native currency for gas fees on an Arbitrum chain (i.e., as opposed to using Ether). Arbitrum Orbit introduced the option for chains to use native fee tokens. \n

" - }, - "offchain-labs": { - "title": "Offchain Labs", - "text": "

\nThe initial builders Arbitrum; current contributors to the Arbitrum ecosystem and service providers to the Arbitrum DAO. Offchain also runs and maintains the Sequencers for Arbitrum One and Arbitrum Nova. \n

" - }, - "one-step-proof": { - "title": "One Step Proof", - "text": "

\nFinal step in a challenge; a single operation of the Arbitrum VM (WASM ) is executed on the underlying chain, and the validity of its state transition is verified.\n

" - }, - "outbox": { - "title": "Outbox", - "text": "

\nAn L1 contract responsible for tracking L2 to L1 Messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.\n

" - }, - "parent-chain": { - "title": "Parent chain", - "text": "

\nEVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). E.g., Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with \"underlying chain.\" \n

" - }, - "portal": { - "title": "Portal", - "text": "

\nA web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.\n

" - }, - "rblock": { - "title": "RBlock", - "text": "

\nAn assertion by an Arbitrum Validator that represents a claim about an Arbitrum chain's state.\n

" - }, - "reorg": { - "title": "Reorg", - "text": "

\nA situation in which transactions on a chain that were at some point considered accepted then get rejected. In the context of an Arbitrum chain, once transactions are posted in the chain's Fast Inbox, the only way the chain can experience a reorg is if its Underlying Chain itself reorgs. Of note, Fraud proofs do not cause reorgs. \n

" - }, - "retryable-autoredeem": { - "title": "Retryable Autoredeem", - "text": "

\nThe \"automatic\" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.\n

" - }, - "retryable-redeem": { - "title": "Retryable Redeem", - "text": "

\nThe execution of a Retryable Ticket on L2; can be automatic (see Retryable Autoredeem) or manual via a user-initiated L2 transaction.\n

" - }, - "retryable-ticket": { - "title": "Retryable Ticket", - "text": "

\nAn L1 to L2 cross chain message initiated by an L1 transaction sent to an Arbitrum chain for execution (e.g., a token deposit).\n

" - }, - "reverse-token-gateway": { - "title": "Reverse Token Gateway", - "text": "

\nA Token Gateway in which the Child chain gateway contract escrows and releases tokens, which the Parent chain Gateway contract mints and burns tokens. This in the inverse to how \"typical\" gateways work.\n

" - }, - "sequencer": { - "title": "Sequencer", - "text": "

\nAn entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the Fast Inbox over a fixed window of time, who can thus give clients sub-blocktime Soft Confirmations. (Not to be confused with a Validator).\n

" - }, - "sequencer-feed": { - "title": "Sequencer Feed", - "text": "

\nOff chain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in Batches.\n

" - }, - "shared-sequencing": { - "title": "Shared Sequencing", - "text": "

\nA protocol design space in which multiple rollups use the same entity as their Sequencer; potential benefits include enhanced interoperability and credible neutrality. \n

" - }, - "smart-contract": { - "title": "Smart Contract", - "text": "

\nA computer program whose operations are defined and executed within a blockchain consensus protocol.\n

" - }, - "soft-confirmation": { - "title": "Soft Confirmation", - "text": "

\nA semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain's block times)\n

" - }, - "speed-limit": { - "title": "Speed Limit", - "text": "

\nTarget computation limit for an Arbitrum chain. Arbitrum One and Arbitrum Nova currently target 7,000,000 gas / second. When computation exceeds this limit, fees rise, ala EIP-1559.\n

" - }, - "staker": { - "title": "Staker", - "text": "

\nA Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular RBlock 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.\n

" - }, - "standard-arbtoken": { - "title": "Standard Arb-Token", - "text": "

\nAn token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC20 functionality in addition to deposit / withdrawal affordances.\n

" - }, - "standarderc20-gateway": { - "title": "StandardERC20 gateway", - "text": "

\nToken Gateway via which any underlying chain's ERC20 token can permissionlessly bridge; the StandardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.\n

" - }, - "state-transition-function": { - "title": "State Transition Function", - "text": "

\nThe STF (State Transition Function) defines how new blocks are produced from input messages (i.e. transactions) in an Arbitrum chain.\n

" - }, - "stylus": { - "title": "Stylus", - "text": "

\nUpgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more).\n

" - }, - "timeboost": { - "title": "Timeboost", - "text": "

\nA transaction ordering policy in which entities can bid for the right to access an express lane on the Sequencer for faster transaction inclusion. See the research specification to learn more. \n

" - }, - "token-gateway": { - "title": "Token Gateway", - "text": "

\nA pair of contracts in the token bridge — one on the Parent chain , one on the Child chain — that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge include the StandardERC20 gateway , the Generic-Custom Gateway , and the WETH Gateway.\n

" - }, - "transaction": { - "title": "Transaction", - "text": "

\nA user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees. \n

" - }, - "transaction-ordering-policy": { - "title": "Transaction Ordering Policy", - "text": "

\nThe rules and logic employed by a chain to order incoming transactions into a block.\n

" - }, - "trustless": { - "title": "Trustless", - "text": "

\nIn 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.\n
\n\n
\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.\n

\n\n

\n\n

\n\n" - }, - "underlying-chain": { - "title": "Underlying Chain", - "text": "

\nSynonymous with Parent chain.\n

" - }, - "validator": { - "title": "Validator", - "text": "

\nAn Arbitrum Full Node that tracks the status of the chains' Assertions. A validator may be a Watchtower Validator, a Defensive Validator, or an Active Validator. \n

" - }, - "wasm": { - "title": "WASM", - "text": "

\nWidely supported binary code format for executable programs. Used by Arbitrum Nitro for Fraud proofs , and more broadly used by Stylus to support performant smart contracts in a wide variety of languages.\n

" - }, - "wasmer": { - "title": "WASMer", - "text": "

\nA popular WebAssembly runtime for executing WASM binaries. A fork of WASMer is used for executing Stylus programs. WASMer executes considerably faster than Geth executes EVM code, contributing to Stylus's lower fees.\n

" - }, - "watchtower-validator": { - "title": "Watchtower Validator", - "text": "

\nA 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.\n

" - }, - "weth-gateway": { - "title": "WETH Gateway", - "text": "

\nToken Gateway 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. \n

" - } -} +"active-validator":{"title":"Active Validator","text":"

\nA staked Validator that makes disputable assertions to advance the state of an Arbitrum chain or to challenge the validity of others' assertions. (Not to be confused with the Sequencer ).\n

"}, +"address-alias":{"title":"Address Alias","text":"

\nAn address deterministically generated from an L1 contract address used on L2 to safely identify the source of an L1 to L2 message.\n

"}, +"arb-token-bridge":{"title":"Arb Token Bridge","text":"

\nA series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.\n

"}, +"arbified-token-list":{"title":"Arbified Token List","text":"

\nA token list that conforms to Uniswap's token list specification; Arbified lists are generated by inputting externally maintained list (i.e., coinmarketcap's list) and outputting a list that includes all of the instances of token contracts on the Arbitrum chain bridged via the canonical Arb Token Bridge from tokens on the inputted list. (See code here.)\n

"}, +"arbitrum":{"title":"Arbitrum","text":"

\nA suite of Ethereum layer-2 scaling technologies built with the Arbitrum Nitro tech stack that includes Arbitrum One (a live implementation of the Arbitrum Rollup Protocol) and Arbitrum Nova (a live implementation of the Arbitrum AnyTrust Protocol).\n

"}, +"arbitrum-anytrust-chain":{"title":"Arbitrum AnyTrust Chain","text":"

\nAn Arbitrum chain that implements the Arbitrum AnyTrust Protocol.\n

"}, +"arbitrum-anytrust-protocol":{"title":"Arbitrum AnyTrust Protocol","text":"

\nAn Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). This protocol reduces transaction fees by introducing an additional trust assumption for data availability in lieu of Ethereum's Trustless data availability mechanism. Arbitrum Nova is an example of an AnyTrust chain; Arbitrum One is an alternative chain that implements the purely trustless (and more L1-gas intensive) Arbitrum Rollup Protocol.\n

"}, +"arbitrum-bridge-ui":{"title":"Arbitrum Bridge UI","text":"

\nWeb application built and maintained by Offchain Labs for user-interactions with the Arb Token Bridge; visit it here.\n

"}, +"arbitrum-chain":{"title":"Arbitrum chain","text":"

\nA blockchain that runs on the Arbitrum protocol. Arbitrum chains are EVM compatible, and use an underlying EVM chain (e.g., Ethereum) for settlement and for succinct fraud-proofs (as needed). Arbitrum chains come in two forms: Arbitrum Rollup Chains and Arbitrum AnyTrust Chains. \n

"}, +"arbitrum-classic":{"title":"Arbitrum Classic","text":"

\nOld Arbitrum stack that used custom virtual machine (\"AVM\"); no public Arbitrum chain uses the classic stack as of 8/31/2022 (they instead use Arbitrum Nitro ).\n

"}, +"arbitrum-full-node":{"title":"Arbitrum Full Node","text":"

\nA party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-staking L1 Ethereum node.\n

"}, +"arbitrum-nitro":{"title":"Arbitrum Nitro","text":"

\nCurrent Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.\n

"}, +"arbitrum-nova":{"title":"Arbitrum Nova","text":"

\nThe first Arbitrum AnyTrust Chain running on Ethereum mainnet. Introduces cheaper transactions; great for gaming and social use-cases. Implements the Arbitrum AnyTrust Protocol, not the Arbitrum Rollup Protocol protocol. Governed by the Arbitrum DAO.\n

"}, +"arbitrum-one":{"title":"Arbitrum One","text":"

\nThe first Arbitrum Rollup Chain running on Ethereum mainnet. Great for decentralized finance and other use-cases that demand strong security guarantees. Governed by the Arbitrum DAO.\n

"}, +"arbitrum-orbit":{"title":"Arbitrum Orbit","text":"

\nArbitrum Orbit refers to the ability for anyone to permissionlessly deploy Layer 3 (L3) chains on top of Arbitrum Layer 2 (L2) chains.\n

"}, +"arbitrum-rollup-chain":{"title":"Arbitrum Rollup Chain","text":"

\nAn Arbitrum chain that implements the Arbitrum Rollup Protocol.\n

"}, +"arbitrum-rollup-protocol":{"title":"Arbitrum Rollup Protocol","text":"

\nA trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain. \n

"}, +"arbos":{"title":"ArbOS","text":"

\nArbitrum's \"operating system\" that trustlessly handles system-level operations; includes the ability to emulate the EVM.\n

"}, +"assertion":{"title":"Assertion","text":"

\nA staked claim by an Arbitrum Validator. An assertion may, e.g., propose a new RBlock, or may be a step in a Challenge.\n

"}, +"auction-contract":{"title":"Auction Contract","text":"

\nA smart contract that handles the state, accounting of funds for bids, and various operations of the Timeboost auction. The contract is deployed on the target chain for which Timeboost is enabled.\n

"}, +"autonomous-auctioneer":{"title":"Autonomous Auctioneer","text":"

\nOff chain software that receives bids from Timeboost participants, processes and validates bids, and then posts the top valid bid (or top two valid bids in the case of a tie) to the Auction Contract to resolve the on-going Timeboost auction. The autonomous auctioneer, for a given chain, is provisioned & deployed by an entity designated by the chain's owner.\n

"}, +"batch":{"title":"Batch","text":"

\nA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Fast Inbox by the Sequencer.\n

"}, +"blockchain":{"title":"Blockchain","text":"

\nA distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols. \n

"}, +"bls-signature":{"title":"BLS Signature","text":"

\nA cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.\n

"}, +"bold":{"title":"BoLD","text":"

\nShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). Not currently on mainnet. \n

"}, +"bridge":{"title":"Bridge","text":"

\nA set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain. \n

"}, +"chain-owner":{"title":"Chain Owner","text":"

\nAn entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.\n

"}, +"chain-state":{"title":"Chain state","text":"

\nA particular point in the history of an Arbitrum chain. A chain's state is determined by applying Arbitrum state-transition function to sequence of transactions (i.e., the chain's history).\n

"}, +"challenge":{"title":"Challenge","text":"

\nWhen two Stakers disagree about the correct verdict on an Assertion, those stakers can be put in a challenge. The challenge is refereed by the contracts on the underlying chain. Eventually one staker wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their stake. \n

"}, +"challenge-period":{"title":"Challenge Period","text":"

\nWindow of time (1 week on Arbitrum One) over which an asserted RBlock can be challenged, and after which the RBlock can be confirmed.\n

"}, +"challenge-protocol":{"title":"Challenge protocol","text":"

\nThe protocol by which RBlocks are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid RBlocks will be confirmed provided that there is at least one honest Active Validator.\n

"}, +"child-chain":{"title":"Child chain","text":"

\nAn Arbitrum Chain that settles to an underlying Parent chain . For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.\n

"}, +"client":{"title":"Client","text":"

\nA 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.\n

"}, +"confirmation":{"title":"Confirmation","text":"

\nThe decision by an Arbitrum chain to finalize an RBlock as part of the chain's history. Once an RBlock is confirmed its L2 to L1 Messages (e.g., withdrawals) can be executed.\n

"}, +"crosschain-message":{"title":"Cross-chain message","text":"

\nAn action taken on some chain A which asynchronously initiates an additional action on chain B. \n

"}, +"custom-arbtoken":{"title":"Custom Arb-Token","text":"

\nAny 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 ).\n

"}, +"custom-gateway":{"title":"Custom gateway","text":"

\nAny Token Gateway that isn't the StandardERC20 gateway.\n

"}, +"dapp":{"title":"dApp","text":"

\nShort for \"decentralized application.\" A dApp typically consists of smart contracts as well as a user-interface for interacting with them.\n

"}, +"data-availability-certificate":{"title":"Data Availability Certificate","text":"

\nSigned promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.\n

"}, +"data-availability-committee-dac":{"title":"Data Availability Committee (DAC)","text":"

\nA permissioned set of parties responsible for enforcing data availability in an Arbitrum AnyTrust Protocol chain. See Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions to learn more.\n

\n\n"}, +"defensive-validator":{"title":"Defensive Validator","text":"

\nA Validator that watches an Arbitrum chain and takes action (i.e., stakes and challenges) only when and if an invalid Assertion occurs.\n

"}, +"delayed-inbox":{"title":"Delayed Inbox","text":"

\nA contract that holds Parent chain initiated messages to be eventually included in the Fast Inbox. Inclusion of messages doesn't depend on the Sequencer.\n

"}, +"devtools-dashboard":{"title":"Dev-Tools Dashboard","text":"

\nWeb application built and maintained by Offchain Labs for developers and users to debug Arbitrum transactions; i.e., executing or checking the status of Cross-chain messages; visit it here. \n

"}, +"dissection":{"title":"Dissection","text":"

\nA step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.\n

"}, +"ethereum-wallet":{"title":"Ethereum Wallet","text":"

\nA software application used for transacting with the Ethereum Blockchain.\n

"}, +"evm":{"title":"EVM+","text":"

\nThe paradigm introduced by Stylus in which Arbitrum's EVM compatibility is preserved while new features and improvements are introduced.\n

"}, +"express-lane":{"title":"Express Lane","text":"

\nA component of Timeboost, the express lane is a special endpoint on the Sequencer that immediately sequences incoming, valid transactions signed by the current express lane controller. \n

"}, +"express-lane-controller":{"title":"Express Lane Controller","text":"

\nAn address, defined in the Auction Contract, that is granted the privilege to use the Express Lane. These privileges are granted after verifying that the incoming transactions were properly signed by the express lane controller, among other checks.\n

"}, +"fair-ordering-algorithm":{"title":"Fair Ordering Algorithm","text":"

\nBFT algorithm in which a committee comes to consensus on transaction ordering; current single-party Sequencer on Arbitrum may eventually be replaced by a fair-ordering committee.\n

"}, +"fast-exit--liquidity-exit":{"title":"Fast Exit / Liquidity Exit","text":"

\nA means by which a user can bypass an Arbitrum chain's Challenge Period when withdrawing fungible assets (or more generally, executing some \"fungible\" L2 to L1 operation); for trustless fast exits, a liquidity provider facilitates an atomic swap of the asset on L2 directly to L1.\n

"}, +"fast-inbox":{"title":"Fast Inbox","text":"

\nContract that holds a sequence of messages sent by clients to an Arbitrum Chain; a message can be put into the fast Inbox directly by the Sequencer or indirectly through the Delayed Inbox.\n

"}, +"first-come-first-serve-fcfs":{"title":"First Come First Serve (FCFS)","text":"

\nA type of Transaction Ordering Policy used by the sequencer in Arbitrum chains whereby incoming transactions are sequenced into a block in the order that the transactions arrived.\n

"}, +"forceinclusion":{"title":"Force-Inclusion","text":"

\nCensorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.\n

"}, +"fraud-proof":{"title":"Fraud proof","text":"

\nThe means by which an Active Validator proves to its underlying chain that an invalid state transition has taken place.\n

"}, +"gas-price-floor":{"title":"Gas Price Floor","text":"

\nProtocol-enforced minimum gas price on an Arbitrum chain; currently 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova.\n

"}, +"gateway-router":{"title":"Gateway Router","text":"

\nContracts in the Arb Token Bridge responsible for mapping tokens to their appropriate Token Gateway.\n

"}, +"genericcustom-gateway":{"title":"Generic-Custom Gateway","text":"

\nA particular Custom gateway via which an L1 token contract can be registered to a token contract deployed to L2. A useful alternative to the StandardERC20 gateway for projects that wish to control the address of their L2 token contract, maintain L2 token contract upgradability, and for various other use-cases. \n

"}, +"geth":{"title":"Geth","text":"

\nAn execution-layer client that defines the Ethereum state transition function and handles network-layer logic like transaction memory pooling. Arbitrum Nitro utilizes a fork of Geth to implement Arbitrum's state transition function.\n

"}, +"ink":{"title":"Ink","text":"

\nThe equivalent of gas in the Stylus vm. Ink is introduced for finer granularity than gas offers since Stylus's operations are considerably cheaper than their EVM analogs. \n

"}, +"l2-block":{"title":"L2 Block","text":"

\nData structure that represents a group of L2 transactions (analogous to L1 blocks).\n

"}, +"l2-to-l1-message":{"title":"L2 to L1 Message","text":"

\nA message initiated from within an Arbitrum chain to be eventually executed on Layer 1 (L1) (e.g., token or Ether withdrawals). On Rollup chains like Arbitrum One, the Challenge Period must pass before an L2 to L1 message is executed.\n

"}, +"layer-1-l1":{"title":"Layer 1 (L1)","text":"

\nThe base protocol and underlying blockchain of the Ethereum network. Responsible for maintaining the integrity of the distributed ledger and executing smart contracts. Contains both Ethereum's execution layer and consensus layer.\n

"}, +"layer-2-l2":{"title":"Layer 2 (L2)","text":"

\nTrustless scaling solutions built on top of Ethereum's Layer 1 (L1) base protocol, such as state channels, plasma chains, optimistic rollups, and ZK-rollups. Layer 2 solutions aim to increase scalability and reduce the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions.\n

"}, +"layer-3-l3":{"title":"Layer 3 (L3)","text":"

\nAn Arbitrum chain whose core contract reside on an Arbitrum Layer 2 (L2) chain.\n

"}, +"native-fee-token":{"title":"Native Fee Token","text":"

\nAn ERC-20 token used as the native currency for gas fees on an Arbitrum chain (i.e., as opposed to using Ether). Arbitrum Orbit introduced the option for chains to use native fee tokens. \n

"}, +"offchain-labs":{"title":"Offchain Labs","text":"

\nThe initial builders Arbitrum; current contributors to the Arbitrum ecosystem and service providers to the Arbitrum DAO. Offchain also runs and maintains the Sequencers for Arbitrum One and Arbitrum Nova. \n

"}, +"one-step-proof":{"title":"One Step Proof","text":"

\nFinal step in a challenge; a single operation of the Arbitrum VM (WASM ) is executed on the underlying chain, and the validity of its state transition is verified.\n

"}, +"outbox":{"title":"Outbox","text":"

\nAn L1 contract responsible for tracking L2 to L1 Messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.\n

"}, +"parent-chain":{"title":"Parent chain","text":"

\nEVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). E.g., Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with \"underlying chain.\" \n

"}, +"portal":{"title":"Portal","text":"

\nA web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.\n

"}, +"rblock":{"title":"RBlock","text":"

\nAn assertion by an Arbitrum Validator that represents a claim about an Arbitrum chain's state.\n

"}, +"reorg":{"title":"Reorg","text":"

\nA situation in which transactions on a chain that were at some point considered accepted then get rejected. In the context of an Arbitrum chain, once transactions are posted in the chain's Fast Inbox, the only way the chain can experience a reorg is if its Underlying Chain itself reorgs. Of note, Fraud proofs do not cause reorgs. \n

"}, +"retryable-autoredeem":{"title":"Retryable Autoredeem","text":"

\nThe \"automatic\" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.\n

"}, +"retryable-redeem":{"title":"Retryable Redeem","text":"

\nThe execution of a Retryable Ticket on L2; can be automatic (see Retryable Autoredeem) or manual via a user-initiated L2 transaction.\n

"}, +"retryable-ticket":{"title":"Retryable Ticket","text":"

\nAn L1 to L2 cross chain message initiated by an L1 transaction sent to an Arbitrum chain for execution (e.g., a token deposit).\n

"}, +"reverse-token-gateway":{"title":"Reverse Token Gateway","text":"

\nA Token Gateway in which the Child chain gateway contract escrows and releases tokens, which the Parent chain Gateway contract mints and burns tokens. This in the inverse to how \"typical\" gateways work.\n

"}, +"sequencer":{"title":"Sequencer","text":"

\nAn entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the Fast Inbox over a fixed window of time, who can thus give clients sub-blocktime Soft Confirmations. (Not to be confused with a Validator).\n

"}, +"sequencer-feed":{"title":"Sequencer Feed","text":"

\nOff chain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in Batches.\n

"}, +"shared-sequencing":{"title":"Shared Sequencing","text":"

\nA protocol design space in which multiple rollups use the same entity as their Sequencer; potential benefits include enhanced interoperability and credible neutrality. \n

"}, +"smart-contract":{"title":"Smart Contract","text":"

\nA computer program whose operations are defined and executed within a blockchain consensus protocol.\n

"}, +"soft-confirmation":{"title":"Soft Confirmation","text":"

\nA semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain's block times)\n

"}, +"speed-limit":{"title":"Speed Limit","text":"

\nTarget computation limit for an Arbitrum chain. Arbitrum One and Arbitrum Nova currently target 7,000,000 gas / second. When computation exceeds this limit, fees rise, ala EIP-1559.\n

"}, +"staker":{"title":"Staker","text":"

\nA Validator who deposits a stake (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular RBlock 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.\n

"}, +"standard-arbtoken":{"title":"Standard Arb-Token","text":"

\nAn token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC20 functionality in addition to deposit / withdrawal affordances.\n

"}, +"standarderc20-gateway":{"title":"StandardERC20 gateway","text":"

\nToken Gateway via which any underlying chain's ERC20 token can permissionlessly bridge; the StandardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.\n

"}, +"state-transition-function":{"title":"State Transition Function","text":"

\nThe STF (State Transition Function) defines how new blocks are produced from input messages (i.e. transactions) in an Arbitrum chain.\n

"}, +"stylus":{"title":"Stylus","text":"

\nUpgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more).\n

"}, +"timeboost":{"title":"Timeboost","text":"

\nA transaction ordering policy in which entities can bid for the right to access an express lane on the Sequencer for faster transaction inclusion. See the research specification to learn more. \n

"}, +"token-gateway":{"title":"Token Gateway","text":"

\nA pair of contracts in the token bridge — one on the Parent chain , one on the Child chain — that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge include the StandardERC20 gateway , the Generic-Custom Gateway , and the WETH Gateway.\n

"}, +"transaction":{"title":"Transaction","text":"

\nA user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees. \n

"}, +"transaction-ordering-policy":{"title":"Transaction Ordering Policy","text":"

\nThe rules and logic employed by a chain to order incoming transactions into a block.\n

"}, +"trustless":{"title":"Trustless","text":"

\nIn 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.\n
\n\n
\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.\n

\n\n

\n\n

\n\n"}, +"underlying-chain":{"title":"Underlying Chain","text":"

\nSynonymous with Parent chain.\n

"}, +"validator":{"title":"Validator","text":"

\nAn Arbitrum Full Node that tracks the status of the chains' Assertions. A validator may be a Watchtower Validator, a Defensive Validator, or an Active Validator. \n

"}, +"wasm":{"title":"WASM","text":"

\nWidely supported binary code format for executable programs. Used by Arbitrum Nitro for Fraud proofs , and more broadly used by Stylus to support performant smart contracts in a wide variety of languages.\n

"}, +"wasmer":{"title":"WASMer","text":"

\nA popular WebAssembly runtime for executing WASM binaries. A fork of WASMer is used for executing Stylus programs. WASMer executes considerably faster than Geth executes EVM code, contributing to Stylus's lower fees.\n

"}, +"watchtower-validator":{"title":"Watchtower Validator","text":"

\nA 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.\n

"}, +"weth-gateway":{"title":"WETH Gateway","text":"

\nToken Gateway 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. \n

"} +} \ No newline at end of file