diff --git a/docs/build/_partials/_oracles_contract_data.md b/docs/build/_partials/_oracles_contract_data.md new file mode 100644 index 00000000000..0546d669c3f --- /dev/null +++ b/docs/build/_partials/_oracles_contract_data.md @@ -0,0 +1,18 @@ + + + + + + + + + + + + + + + + + +
Pyth contracthttps://explorer.evm.iota.org/address/0x8D254a21b3C86D32F7179855531CE99164721933
Supra Pull Contracthttps://explorer.evm.iota.org/address/0x2FA6DbFe4291136Cf272E1A3294362b6651e8517
Supra Storage Contracthttps://explorer.evm.iota.org/address/0xD02cc7a670047b6b012556A88e275c685d25e0c9
Supra Pull Contracthttps://explorer.evm.iota.org/address/0xD02cc7a670047b6b012556A88e275c685d25e0c9
\ No newline at end of file diff --git a/docs/build/apis/sidebars.js b/docs/build/apis/sidebars.js index f2eb2b5a0c0..4d133d52e71 100644 --- a/docs/build/apis/sidebars.js +++ b/docs/build/apis/sidebars.js @@ -48,6 +48,12 @@ const categories = [ collapsed: true, items: './docs/core/v2/sidebar', }, + { + type: 'category', + label: 'V3', + collapsed: true, + items: './docs/core/v3/sidebar', + }, ], }, { diff --git a/docs/build/getting-started/blastAPI.md b/docs/build/getting-started/blastAPI.md new file mode 100644 index 00000000000..caf34a9e51d --- /dev/null +++ b/docs/build/getting-started/blastAPI.md @@ -0,0 +1,29 @@ +# Blast API + +[Blast API](https://blastapi.io/) is a decentralized platform that provides reliable and scalable node infrastructure +for accessing blockchain data. It supports multiple blockchain networks, offering seamless integration and +high-performance API endpoints for cross-chain decentralized applications (dApps). + +## Enhanced Performance and Reliability + +Blast API uses a decentralized network of third-party node providers, that ensure high availability and fast response +times. This architecture provides resilient infrastructure services crucial for dApps requiring real-time data access. + +## Multi-Blockchain Support + +Besides IOTA EVM, Blast API supports a wide range of blockchain networks, allowing access to multiple blockchains +through a single unified platform, therefore simplifying the development process and expanding the potential use cases +for dApps. + +## Archival Nodes + +Blast API includes archival nodes, which store all historical transaction data from the blockchain’s +genesis block to the present. This allows developers to query and retrieve past information, which is essential for +applications needing access to comprehensive blockchain histories. + + +:::tip Blast API Endpoints + +You can find a full list of Blast API endpoints in the [Networks & Endpoints section](networks-endpoints.mdx). + +::: diff --git a/docs/build/getting-started/networks-endpoints.mdx b/docs/build/getting-started/networks-endpoints.mdx index 7ec97e7d37f..bb5632d2e93 100644 --- a/docs/build/getting-started/networks-endpoints.mdx +++ b/docs/build/getting-started/networks-endpoints.mdx @@ -16,7 +16,6 @@ tags: import { AddToMetaMaskButton } from '@theme/AddToMetaMaskButton'; import { Networks } from '@theme/constant'; import NetworkInfo from '@theme/NetworkInfo'; -import { ChainId } from '@theme/ChainId'; # Networks & Endpoints @@ -76,6 +75,7 @@ This network is subject to occasional resets (no data retention) which are usual + #### Additional Info diff --git a/docs/build/getting-started/oracles.md b/docs/build/getting-started/oracles.md index 2ababe9d917..4b4e89c8760 100644 --- a/docs/build/getting-started/oracles.md +++ b/docs/build/getting-started/oracles.md @@ -4,10 +4,15 @@ image: /img/logo/WASP_logo_dark.png tags: - Blockchain Oracles - Smart Contracts +- IOTA EVM - Shimmer EVM - Pyth Network - Supra Oracles --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import OraclesContractData from '../_partials/_oracles_contract_data.md' + # Introduction to Oracles in Blockchain @@ -36,52 +41,56 @@ multiple data points to validate the information's accuracy. This process ensure contracts is relevant and timely, maintaining the integrity and deterministic nature of the blockchain operations. -## Oracles on Shimmer EVM +## Oracles on IOTA EVM -### Supra +### Pyth -Supra Oracles validate and report prices derived from up to 21 data sources with Byzantine Fault Tolerant algorithms -for a wide array of assets and commodities using its own Distributed Oracle Agreement (DORA) to provide data for crypto -prices, forex, equities, and even Web3 data from other blockchains. Its feed gets updated from a minimum of 3 to 8 sources; if a data pair fails to meet this criterion, it gets deprecated to ensure data reliability. +The Pyth Network delivers real-time financial market data across multiple blockchains and can be used in off-chain applications. +Pyth gets contributions from over 90 publishers, including several exchanges. It offers comprehensive and accurate price +feeds for asset classes such as US equities, commodities, and cryptocurrencies. Its price feeds get updates +multiple times per second, ensuring they are current and reliable. :::tip -You can learn more about Supra Oracles in their [official documentation](https://supraoracles.com/docs/overview). +You can learn more about Pyth Oracles in their [official documentation](https://docs.pyth.network/documentation). ::: -### Pyth +### Supra -The Pyth Network delivers real-time financial market data across multiple blockchains and can be used in off-chain applications. -Pyth gets contributions from over 90 publishers, including several exchanges. It offers comprehensive and accurate price -feeds for asset classes such as US equities, commodities, and cryptocurrencies. Its price feeds get updates -multiple times per second, ensuring they are current and reliable. +Supra Oracles validate and report prices derived from up to 21 data sources with Byzantine Fault Tolerant algorithms +for a wide array of assets and commodities using its own Distributed Oracle Agreement (DORA) to provide data for crypto +prices, forex, equities, and even Web3 data from other blockchains. Its feed gets updated from a minimum of 3 to 8 sources; if a data pair fails to meet this criterion, it gets deprecated to ensure data reliability. :::tip -You can learn more about Pyth Oracles in their [official documentation](https://docs.pyth.network/documentation). +You can learn more about Supra Oracles in their [official documentation](https://supraoracles.com/docs/overview). ::: + + #### Example Code -You can use the following example code to get data from Pyth Oracles in Shimmer EVM: + + +You can use the following example code to get data from Pyth Oracles in IOTA EVM: ```typescript import {ethers} from "ethers"; import fetch from "node-fetch"; // Provider -const providerURL = "https://json-rpc.evm.shimmer.network" +const providerURL = "https://json-rpc.evm.iota.network" const provider = new ethers.JsonRpcProvider(providerURL); -// Pyth Oracle contract on ShimmerEVM Mainnet -const contractAddress = '0xA2aa501b19aff244D90cc15a4Cf739D2725B5729'; +// Pyth Oracle contract on IOTA EVM Mainnet +const contractAddress = '0x8D254a21b3C86D32F7179855531CE99164721933'; // Add Price Feed Ids obtained from https://pyth.network/developers/price-feed-ids#pyth-evm-stable const priceFeedIds = [ - //SMR/USD + //IOTA/USD '0xaf5b9ac426ae79591fde6816bc3f043b5e06d5e442f52112f76249320df22449', //BTC/USD '0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43' @@ -120,4 +129,8 @@ async function main() { } } -main(); \ No newline at end of file +main(); +``` + + + \ No newline at end of file diff --git a/docs/build/getting-started/sidebars.ts b/docs/build/getting-started/sidebars.ts index 04271736f50..6521fa257b8 100644 --- a/docs/build/getting-started/sidebars.ts +++ b/docs/build/getting-started/sidebars.ts @@ -27,7 +27,7 @@ module.exports = { items: [ { type: 'category', - label: 'IOTA', + label: 'IOTA EVM', collapsed: false, link: { type: 'generated-index', @@ -49,7 +49,7 @@ module.exports = { }, { type: 'category', - label: 'IOTA Testnet', + label: 'IOTA EVM Testnet', collapsed: false, link: { type: 'generated-index', @@ -69,9 +69,34 @@ module.exports = { }, ], }, + { + label: 'Blast API', + type: 'doc', + id: 'blastAPI', + }, + { + label: 'Oracles', + type: 'doc', + id: 'oracles', + }, + { + label: 'Subgraphs', + type: 'doc', + id: 'subgraphs', + }, + { + label: 'IOTA Safe Wallet', + type: 'doc', + id: 'safe', + }, + { + label: 'Multicall', + type: 'doc', + id: 'multicall', + }, { type: 'category', - label: 'Shimmer', + label: 'ShimmerEVM', collapsed: true, link: { type: 'generated-index', @@ -93,7 +118,7 @@ module.exports = { }, { type: 'category', - label: 'Shimmer Testnet', + label: 'ShimmerEVM Testnet', collapsed: true, link: { type: 'generated-index', @@ -113,21 +138,6 @@ module.exports = { }, ], }, - { - label: 'Oracles for IOTA EVM and ShimmerEVM', - type: 'doc', - id: 'oracles', - }, - { - label: 'IOTA Safe Wallet', - type: 'doc', - id: 'safe', - }, - { - label: 'Multicall', - type: 'doc', - id: 'multicall', - }, { type: 'link', label: 'WASP CLI', @@ -137,6 +147,7 @@ module.exports = { }, ], }, + { label: 'Explorer', type: 'link', diff --git a/docs/build/getting-started/subgraphs.md b/docs/build/getting-started/subgraphs.md new file mode 100644 index 00000000000..7516238750b --- /dev/null +++ b/docs/build/getting-started/subgraphs.md @@ -0,0 +1,100 @@ +--- +description: 'Learn about the role of in subgraphs in smart, how they can provide indexed blockchain data to your smart contracts.' +image: /img/logo/WASP_logo_dark.png +tags: + - Blockchain subgraphs + - Smart Contracts + - Shimmer EVM + - IOTA EVM +--- + +# Subgraphs + +:::info tl;dr; + +Subgraphs provide a streamlined way for developers to access blockchain data relevant to their applications, +significantly enhancing developer efficiency and user experience. + +::: + +Subgraphs collect and organize blockchain data by application needs, making it readily accessible for developers. Unlike +blockchains that store data without application context, subgraphs allow you to quickly retrieve information pertinent +to your application and simplify real-time data access, facilitating the creation of +dynamic user interfaces and interactions in your applications. + +## Subgraph Components and Operations + +Subgraphs are built on [GraphQL](https://graphql.org/) APIs, enabling you to query on-chain transaction data +efficiently. +This feature is particularly useful for developers working with complex smart contracts requiring detailed frontend +interfaces. For instance, querying transactions within a specific liquidity pool becomes straightforward with subgraphs. +By defining a schema and indexing event data, you can utilize the generated GraphQL API for effective data querying. + +### Subgraph Manifest + +The manifest details the smart contracts your subgraph indexes, the events it tracks, and how event data is mapped to +queryable entities. This foundational document ensures your subgraph accurately reflects the blockchain data your +application needs. + +### Subgraph Schema + +The schema organizes your subgraph data, defining entities like pools in DeFi applications, and their attributes. It is +crucial for structuring your data to support efficient queries. + +### Subgraph Mappings + +Mappings process incoming blockchain events, specified in your [manifest](#subgraph-manifest), and store them +according to your [schema](#subgraph-schema). +These [AssemblyScript](https://www.assemblyscript.org/) codes are essential for translating raw blockchain data into a +format your application can easily query. + +## Popular Use Cases for Subgraphs + +Subgraphs have found widespread adoption in various blockchain applications, from DeFi to NFTs and DAOs, due to their +ability to index and query data effectively. + +* **Custom Smart Contract Indexing**: Ideal for developers needing to index data for unique smart contracts, especially + those creating frontend interfaces. +* **Decentralized Finance (DeFi)**: Subgraphs provide real-time data on token prices, liquidity, and more, enhancing + DeFi + applications. +* **Non-fungible Tokens (NFTs)**: They allow for efficient querying of NFT ownership, transaction history, and off-chain + data. +* **Decentralized Autonomous Organizations (DAOs)**: Subgraphs facilitate on-chain decision-making and data analysis for + DAOs. +* **Gaming**: They support real-time data access, improving gameplay and in-game transactions. + +## Benefits of Using Subgraphs + +Subgraphs offer a developer-friendly approach to blockchain data indexing, compatible with various blockchains and +enhancing application security and resilience. + +* **Ease of Use**: With familiar tools like AssemblyScript and GraphQL, subgraphs are accessible to developers, + simplifying + the backend data management. +* **Cross-Blockchain Compatibility**: They work across multiple EVM-compatible networks, allowing applications to + operate + seamlessly on different blockchains. +* **Security and Decentralization**: Opting for decentralized querying with subgraphs can reduce reliance on single data + sources, increasing application robustness. + +## Subgraph Providers + +### Goldsky + +[Goldsky](https://goldsky.com/products/subgraphs) [supports IOTA EVM](https://docs.goldsky.com/chains/supported-networks). +You can use their public API endpoints to access subgraph data. + +:::tip Blast API Archival Nodes + +You can use the convenient Blast API on IOTA EVM to access [archival nodes](blastAPI.md#archival-nodes). + +::: + +:::tip Wasp Access Nodes + +You can find more information on how to connect to an access node in the +[#nodesharing channel](https://discordapp.com/channels/397872799483428865/398600007378272256) on the [IOTA Discord](https://discord.iota.org/). + +::: + diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_partials/_oracles_contract_data.md b/docs/build/isc/v1.0.0-rc.6/docs/_partials/_oracles_contract_data.md new file mode 100644 index 00000000000..0546d669c3f --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_partials/_oracles_contract_data.md @@ -0,0 +1,18 @@ + + + + + + + + + + + + + + + + + +
Pyth contracthttps://explorer.evm.iota.org/address/0x8D254a21b3C86D32F7179855531CE99164721933
Supra Pull Contracthttps://explorer.evm.iota.org/address/0x2FA6DbFe4291136Cf272E1A3294362b6651e8517
Supra Storage Contracthttps://explorer.evm.iota.org/address/0xD02cc7a670047b6b012556A88e275c685d25e0c9
Supra Pull Contracthttps://explorer.evm.iota.org/address/0xD02cc7a670047b6b012556A88e275c685d25e0c9
\ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx index b7db24acf49..eb383f39bda 100644 --- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx @@ -14,7 +14,6 @@ tags: --- import MetamaskButtons from '../../../../_partials/_metamask_buttons.mdx'; -import NetworkInfo from '@theme/NetworkInfo'; import { Networks } from '@theme/constant'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; @@ -53,20 +52,6 @@ If you want to fund your EVM testnet account, please refer to our [How To Get Fu 3. Select the account you want to receive testnet tokens. 4. Click "Send funds" to get testnet tokens. -## Get Simulated Bridged Tokens - -:::info ShimmerEVM Testnet - -The simulated bridged tokens are currently only available on the ShimmerEVM Testnet. - -::: - -1. Go to the [ERC20 Simulated Token Faucet](https://evm-faucet.testnet.shimmer.network/). -2. Connect your MetaMask wallet by clicking "Connect Wallet". -3. Select the account you want to receive simulated bridged tokens. -4. Choose the desired token (fETH, fBTC, fUSDT, etc.) from the dropdown list. -5. Click "Submit" to get the selected simulated bridged tokens. - ## Deploy and Interact with Smart Contracts You can now use your testnet tokens and simulated bridged tokens to deploy and interact with smart contracts on the testnets. Utilize popular development tools and frameworks, such as [Hardhat](https://hardhat.org/), or [Remix](https://remix.ethereum.org/), to build, test, and deploy your smart contracts. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx index 8b6138abb00..0637c4ea4e1 100644 --- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx @@ -24,6 +24,7 @@ import { Networks } from '@theme/constant'; import DeployAdmonition from '../_admonitions/_deploy_a_smart_contract.md'; import { ChainId } from '@theme/ChainId'; import NetworkInfo from '@theme/NetworkInfo'; +import OraclesContractData from '../_partials/_oracles_contract_data.md'; # Compatible Tools @@ -47,33 +48,74 @@ chain ID after deployment.** ::: +## Network RPCs + + + + + + + + + + + + + + + + + + + + +## IOTA EVM Tools + +The following tools are **only available on IOTA EVM**. + +### EVM Toolkit + +You can use the [IOTA EVM Toolkit](https://evm-toolkit.evm.iotaledger.net) to withdraw assets from IOTA EVM to IOTA L1. +It also includes a wrapper IOTA <\> wIOTA. + +### MultiSig Walllets + +If you require and additional level of security, you can use the [Safe{} Wallet](https://safe.iotaledger.net/) as a +Multisig solution on IOTA EVM. + +### Oracles + +If your project requires [Oracles](/build/oracles/) to provide data from the outside world, you find both Pyth and Supra have integrated IOTA EVM. + + + +### Multicall3 + +If you need to aggregate results from multiple contract reads into a single JSON-RPC request or execute multiple +state-changing calls in a single transaction, you can use the [Multicall3 contract](https://explorer.evm.iota.org/address/0xcA11bde05977b3631167028862bE2a173976CA11?tab=contract). + +### Subgraphs + +[Subgraphs](/build/subgraphs/) provide a streamlined way for developers to access blockchain data relevant to their applications, +significantly enhancing developer efficiency and user experience. IOTA EVM subgraphs available via [Goldsky](https://goldsky.com). + +### Blast API + +The [Blast API](/build/blastAPI) is a decentralized platform that provides reliable and scalable node infrastructure +for accessing blockchain data. You can find the Blast API URLs in the [Network RPCs](#network-rpcs) + +## IOTA EVM and ShimmerEVM Tools + +The following tools are available on both IOTA EVM end ShimmerEVM. + ## MetaMask [MetaMask](https://metamask.io/) is a popular EVM wallet which runs in a browser extension that allows you to interact with EVM chains and their applications (dApps). To use your EVM chain with MetaMask, simply open up MetaMask and click on the network drop-down list at the very top. At -the bottom of this list, you will see the option `Add network`. On the new page you will see a list of popular network with the option `Add a network manually`. -For example this would be the configs to add our different [EVM chains](/build/networks-endpoints): - - - - - - - - - - - - - - - - - - - +the bottom of this list, you will see the option `Add network`. On the new page you will see a list of popular network +with the option `Add a network manually`. Ensure that your `RPC Url` and `Chain ID` are set correctly and match the dashboard values. The `Network Name` can be whatever you see fit. Click "Save" to add the chain to MetaMask. @@ -118,9 +160,9 @@ often offered through block explorer APIs. ## Ethers.js/Web3.js -If you input the correct configuration parameters for the JSON-RPC endpoint to talk -to, [Ethers.js](https://docs.ethers.io/) and [Web3.js](https://web3js.readthedocs.io/) are also compatible with EVM -chains on IOTA Smart Contracts. Alternatively, you can let both interact through MetaMask instead so that it uses the +If you input the correct configuration parameters for the JSON-RPC endpoint to talk to, +[Ethers.js](https://docs.ethers.io/) and [Web3.js](https://web3js.readthedocs.io/) are also compatible with EVM chains on IOTA Smart Contracts. +Alternatively, you can let both interact through MetaMask instead so that it uses the network configured in MetaMask. For more information on this, read their documentation. ## Other Tooling diff --git a/docs/get-started/introduction/iota/staking.md b/docs/get-started/introduction/iota/staking.md deleted file mode 100644 index 30ada856fc9..00000000000 --- a/docs/get-started/introduction/iota/staking.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Staking IOTA -description: Everything you need to know about the different staking opportunities in the IOTA and Shimmer networks. -tags: - - staking IOTA - - Shimmer network - - staking rewards ---- - -# Staking in the IOTA Network Ecosystem - -In 2022, IOTA introduced a new staging network and battlefield for IOTA's core technological innovations: Shimmer. This marked a vast increase in the utility of the IOTA token. -Shimmer launched with its native tokens: SMR. With the _tokenomics_ and incentive structure around this network, it is possible to stake tokens. - -:::info - -Find the blog post introducing IOTA _staking_ [here](https://blog.iota.org/introducing-iota-staking/). -Find the announcement of the start of IOTA staking [here](https://blog.iota.org/iota-staking-start/). - -::: - -There are several ways to stake your tokens and earn staking rewards: - -- Shimmer pre-launch staking created the initial token supply for SMR and distributed it to those who stake their IOTA tokens. -- SMR token staking helps testing on the Shimmer network and supports the network. - -## Shimmer Pre-launch Staking - -The Pre-launch staking period rewarded IOTA token holders for their participation and distributed SMR tokens to them. In the case of Shimmer, it also created the total initial supply of the network. - -Starting from 28th December 2021, IOTA holders who possess IOTA tokens in the Firefly wallet and who had chosen to participate in the staking period generated Shimmer tokens for 90 days. - -The Shimmer staking period was limited to these initial 90 days. - -### IOTA Staking for SMR Rewards - -The Shimmer network was bootstrapped purely from IOTA token stakers. The initial token supply of the Shimmer network only relied on the amount of IOTA tokens staked for Shimmer in the 90-day staking period, and 80% of the initial supply was distributed to IOTA token holders, while the remaining 20% was distributed equally between the Community DAO and the Tangle Ecosystem. - -- The staking functionality in the Firefly Wallet was used for Shimmer. -- Shimmer tokens were distributed at a fixed rate of `1 SMR per 1 MIOTA per milestone`. - -![shimmer staking](/img/learn/iota-token/shimmer-staking.png) - -- With the launch of the Shimmer network, the generated Shimmer tokens were distributed to the IOTA stakers. This distribution was implemented as a functionality within the Firefly wallet. diff --git a/docs/get-started/introduction/shimmer/shimmer-token.md b/docs/get-started/introduction/shimmer/shimmer-token.md index 8f7d8cb8939..d9e577039c9 100644 --- a/docs/get-started/introduction/shimmer/shimmer-token.md +++ b/docs/get-started/introduction/shimmer/shimmer-token.md @@ -38,7 +38,7 @@ participation, community engagement, and innovation within the Shimmer ecosystem ### IOTA Stakers Allocation A significant portion of the Shimmer tokens, accounting for 80% of the total supply, is allocated to IOTA stakers. This -amounts to 1,450,896,407 SMR tokens. IOTA token holders who [staked their tokens had the opportunity](/get-started/introduction/iota/staking#iota-staking-for-smr-rewards) to receive SMR tokens as rewards for participating in the IOTA mainnet. +amounts to 1,450,896,407 SMR tokens. IOTA token holders who staked their tokens had the opportunity to receive SMR tokens as rewards for participating in the IOTA mainnet. ### Community DAO Allocation diff --git a/docs/get-started/programs/bug-bounties.md b/docs/get-started/programs/bug-bounties.md deleted file mode 100644 index 24fc881201e..00000000000 --- a/docs/get-started/programs/bug-bounties.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -image: /img/shimmer-wiki.png -description: Learn about the bug bounty programs in IOTA and Shimmer networks, incentivizing security researchers to identify and report vulnerabilities. -tags: - - bug bounties - - security researchers - - vulnerability identification - - IOTA network - - Shimmer network ---- - -# Bug Bounties - -Bug bounties are programs the IOTA and Shimmer networks implement to encourage security researchers and ethical -hackers to discover and report potential vulnerabilities in their respective systems. These programs play a crucial role -in maintaining the security and _integrity_ of the networks by proactively identifying and addressing security weaknesses. - -By offering financial rewards or other incentives, bug bounty programs attract skilled individuals who thoroughly -analyze the networks' codebase, infrastructure, and protocols. These researchers aim to identify any loopholes, -vulnerabilities, or potential _exploits_ that malicious actors could exploit. Once a vulnerability is found, it is -reported to the development teams, who can take the necessary steps to mitigate the issue and enhance the overall -security of the networks. - -Bug bounty programs enhance the security of the IOTA and Shimmer networks and foster a collaborative and -inclusive environment where security researchers and developers work together to build robust and resilient systems. By -incentivizing vulnerability identification and responsible disclosure, these programs contribute to the ongoing -improvement and evolution of the networks, ensuring they remain trustworthy and secure for all participants. - -If you are a security researcher interested in contributing to the security of the IOTA or Shimmer networks, check the official bug bounty programs and guidelines the respective projects provide. Your expertise and -discoveries can significantly impact the security and reliability of these innovative technologies. - -## Active Bug Bounties - -There are currently no active bug bounties. diff --git a/docs/get-started/sidebars.ts b/docs/get-started/sidebars.ts index 6eed4e55b74..25abaef5cb2 100644 --- a/docs/get-started/sidebars.ts +++ b/docs/get-started/sidebars.ts @@ -20,7 +20,6 @@ module.exports = { items: [ 'introduction/iota/introduction', 'introduction/iota/iota-token', - 'introduction/iota/staking', ], }, { @@ -52,11 +51,7 @@ module.exports = { { type: 'category', label: 'Programs & Funding', - items: [ - 'programs/touchpoint', - 'programs/bug-bounties', - 'programs/community-treasury', - ], + items: ['programs/touchpoint', 'programs/community-treasury'], }, { type: 'category', diff --git a/docs/maintain/hornet/2.0/docs/how_tos/post_installation.md b/docs/maintain/hornet/2.0/docs/how_tos/post_installation.md index c93ce52bcbf..86fc4a1895d 100644 --- a/docs/maintain/hornet/2.0/docs/how_tos/post_installation.md +++ b/docs/maintain/hornet/2.0/docs/how_tos/post_installation.md @@ -57,12 +57,6 @@ To generate a JWT-token to be used with the protected routes you can run: If you are running our [recommended setup](using_docker.md) then see [here](using_docker.md#tools). -### Proof-of-Work - -If you are concerned with resource consumption, consider turning off `restAPI.pow.enabled`. -This way, the clients must perform proof of work locally before submitting a block for broadcast. -If you would like to offer proof of work to clients, consider increasing the `restAPI.pow.workerCount` to provide a faster block submission experience. - ### Reverse Proxy We recommend that you provide your HTTP REST API behind a reverse proxy, such as [HAProxy](http://www.haproxy.org/), [Traefik](https://traefik.io/), [Nginx](https://www.nginx.com/), or [Apache](https://www.apache.org/) configured with TLS. diff --git a/docs/maintain/hornet/2.0/docs/how_tos/using_docker.md b/docs/maintain/hornet/2.0/docs/how_tos/using_docker.md index b5b9eb77645..157a50a2b4f 100644 --- a/docs/maintain/hornet/2.0/docs/how_tos/using_docker.md +++ b/docs/maintain/hornet/2.0/docs/how_tos/using_docker.md @@ -64,6 +64,13 @@ Once you have completed all the installation [requirements](#requirements), you mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-setup.iota.org/iota | tar -zx ``` + + + +```sh +mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-setup.iota.org/iota-testnet | tar -zx +``` + @@ -72,10 +79,10 @@ mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-s ``` - + ```sh -mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-setup.iota.org/testnet | tar -zx +mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-setup.iota.org/shimmer-testnet | tar -zx ``` @@ -133,6 +140,13 @@ Activating a Wasp node isn't enough to fully participate in a smart contract cha https://github.com/iotaledger/node-docker-setup/blob/main/iota/env_template ``` + + + +```sh reference +https://github.com/iotaledger/node-docker-setup/blob/main/iota-testnet/env_template +``` + @@ -141,10 +155,10 @@ https://github.com/iotaledger/node-docker-setup/blob/main/shimmer/env_template ``` - + ```sh reference -https://github.com/iotaledger/node-docker-setup/blob/main/testnet/env_template +https://github.com/iotaledger/node-docker-setup/blob/main/shimmer-testnet/env_template ``` diff --git a/docs/maintain/hornet/2.0/docs/welcome.md b/docs/maintain/hornet/2.0/docs/welcome.md index 373a3c8ac85..1c958bea349 100644 --- a/docs/maintain/hornet/2.0/docs/welcome.md +++ b/docs/maintain/hornet/2.0/docs/welcome.md @@ -22,7 +22,7 @@ It provides the full node capabilities including full support of the latest netw By running your own node you have the following benefits: - You have direct access to the IOTA or Shimmer network, instead of having to connect to and trust someone else's node. -- You help the network to become more distributed and resilient by validating blocks and _value transactions_. +- You help the network to become more distributed and resilient by validating blocks and value transactions. ## Source Code diff --git a/docs/maintain/iota-core/1.0/docs/getting_started/getting_started.md b/docs/maintain/iota-core/1.0/docs/getting_started/getting_started.md new file mode 100644 index 00000000000..a248c24bfdc --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/getting_started/getting_started.md @@ -0,0 +1,55 @@ +--- +description: Getting started with the recommended requirements and installation links. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - Linux + - macOS + - Windows + - Docker + - reference + - Requirements +--- + +# Getting Started + +Running a node is an efficient way to use IOTA. By doing so, you have direct access to the Tangle instead of connecting +to and trusting someone else's node. Additionally, you help the network to become more distributed and resilient. + +## Recommended Requirements + +To handle a potentially high rate of blocks per second, nodes need enough computational power to run reliably and +should have the following minimum specs: + +- 4 cores or 4 vCPU. +- 8 GB RAM. +- SSD storage. +- A public IP address. + +The amount of storage you will need will depend on whether and how often you plan on _pruning_ old data from your local +database. + +IOTA-Core exposes different functionality on different ports: + +- `15600 TCP` - Gossip protocol port. +- `14265 TCP` - REST HTTP API port (optional). + +These ports are essential for flawless node operation. The REST HTTP API port is optional and is only needed if +you want to offer access to your node's API. You can customize all ports using +the [`config.json`](../how_tos/post_installation.md) file. + +## Operating System + +The IOTA-Core software is written in Go and can be deployed on all major platforms. +The [recommended setup](../how_tos/using_docker.md) uses Docker to run IOTA-Core together with some INX extensions +secured behind a [Traefik](https://traefik.io) SSL reverse proxy. + +## Configuration + +IOTA-Core uses two JSON configuration files that you can tweak based on your deployment requirements: + +- `config.json` - Includes all core configuration parameters. +- `peering.json` - Includes connection details to node neighbors (peers). + +You can read more about the configuration in the [post installation](../how_tos/post_installation.md) article. diff --git a/docs/maintain/iota-core/1.0/docs/how_tos/post_installation.md b/docs/maintain/iota-core/1.0/docs/how_tos/post_installation.md new file mode 100644 index 00000000000..54bdb0d5fc4 --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/how_tos/post_installation.md @@ -0,0 +1,81 @@ +--- +description: Introducing the IOTA-Core node configuration files and their settings. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - Configuration + - REST API + - Dashboard + - how to +--- + +# Post-installation + +Once you have deployed IOTA-core, you can set all the parameters using configuration files. + +## Configuration Files + +The most important configuration files are: + +- `config.json` - Includes all configuration flags and their values. +- `peering.json` - Includes all connection details to your static peers (neighbors). + +## Default Configuration + +There are default configuration files available that you can use: + +- `config_testnet.json` - Includes the default values required to join the Testnet. +- `config_defaults.json` - Includes all default parameters used by IOTA-core. You can use this file as a reference when customizing your `config.json` + +You can pick one of these files and use it as your `config.json` to join the configured network. + +Please see the [`config.json`](../references/configuration.md) and `peering.json` articles for more information about the contents of the configuration files. + +## Configuring HTTP REST API + +One of the tasks the node is responsible for is exposing [API](../references/api_reference.md) to clients that would like to interact with the IOTA network, such as crypto wallets, exchanges, IoT devices, etc. + +By default, IOTA-Core will expose the [Core REST API v3](../references/api_reference.md) on port `14265`. +If you use the [recommended setup](using_docker.md) the API will be exposed on the default HTTPS port (`443`) and secured using an SSL certificate. + +Since offering the HTTP REST API to the public can consume your node's resources, there are options to restrict which routes can be called and other request limitations: + +### Routes + +- `restAPI.publicRoutes` defines which routes can be called without JWT authorization. +- `restAPI.protectedRoutes` defines which routes require JWT authorization. +- All other routes will not be exposed. + +### JWT Auth + +To generate a JWT-token to be used with the protected routes you can run: + +```sh +./iota-core tool jwt-api --databasePath --salt +``` + +If you are running our [recommended setup](using_docker.md) then see [here](using_docker.md#tools). + +### Proof-of-Work + +If you are concerned with resource consumption, consider turning off `restAPI.pow.enabled`. +This way, the clients must perform proof of work locally before submitting a block for broadcast. +If you would like to offer proof of work to clients, consider increasing the `restAPI.pow.workerCount` to provide a faster block submission experience. + +### Reverse Proxy + +We recommend that you provide your HTTP REST API behind a reverse proxy, such as [HAProxy](http://www.haproxy.org/), [Traefik](https://traefik.io/), [Nginx](https://www.nginx.com/), or [Apache](https://www.apache.org/) configured with TLS. +When using our [recommended setup](using_docker.md) this is done for you automatically. + +### Other + +You can find all the HTTP REST API related options in the [`config.json` reference](../references/configuration.md#restapi) + +## Update + +You can update IOTA-Core to the latest stable version with no breaking updates by running the following command: + +```sh +docker compose down && docker compose pull && docker compose up -d +``` diff --git a/docs/maintain/iota-core/1.0/docs/how_tos/using_docker.md b/docs/maintain/iota-core/1.0/docs/how_tos/using_docker.md new file mode 100644 index 00000000000..bc5cea67ba2 --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/how_tos/using_docker.md @@ -0,0 +1,215 @@ +--- +description: Learn how to install and run a iota-CORE node using Docker. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - Docker + - Install + - Run + - macOS + - Windows + - Linux + - how to +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import LinuxCommands from '@site/docs/_admonitions/_linux-commands.md'; + +# Install IOTA-Core using Docker + +This article guides the recommended setup to run an IOTA-Core node. +It includes everything required to set up a public node accessible by wallets and applications: + +- [IOTA-core](https://github.com/iotaledger/iota-core) +- [Traefik](https://traefik.io) - Reverse proxy using SSL certificates to secure access to the node API and dashboard. +- [Prometheus](https://prometheus.io) - Metrics scraper configured to collect all metrics from IOTA-Core and INX extensions. +- [Grafana](https://grafana.com) - Data visualizer that can be used to display the metrics collected by Prometheus. +- [inx-dashboard](https://github.com/iotaledger/inx-dashboard) - Node dashboard. +- [inx-indexer](https://github.com/iotaledger/inx-indexer) - Indexer extension for wallets and applications. +- [inx-mqtt](https://github.com/iotaledger/inx-mqtt) - MQTT extension providing the Event API. + +## Requirements + +1. A recent release of Docker enterprise or community edition. Avoid using the Docker version shipped with your OS since these are mostly out of date. You can find installation instructions in the [official Docker documentation](https://docs.docker.com/engine/install/). +2. [Docker Compose CLI plugin](https://docs.docker.com/compose/install/linux/). +3. A registered domain name pointing to the public IP address of your server. _(optional if not using HTTPS)_ +4. Opening up the following ports in your server's firewall: + +- `15600 TCP` - Used for IOTA-Core gossip. +- `80 TCP` - Used for HTTP. _(can be changed, see below)_ +- `443 TCP` - Used for HTTPS. _(optional if not using HTTPS)_ + +5. [curl](https://curl.se/). + +## Download the latest release + + + +Once you have completed all the installation [requirements](#requirements), you can download one of the latest releases, depending on the network you want to join, by running the following command: + +```sh +mkdir node-docker-setup && cd node-docker-setup && curl -L https://node-docker-setup.iota.org/iota2-testnet | tar -zx +``` + +## Prepare + + + +### 1. Generate dashboard credentials + +To access your IOTA-Core dashboard, you need to configure credentials. +Run the following command to generate a password hash and salt for the dashboard: + +```sh +docker compose run iota-core tools pwd-hash +``` + +Copy the output of the command for the next step. + +### 2. Setup your Environment + +Copy the `env_template` file to `.env` using the following command: + +```sh +cp env_template .env +``` + +Modify the `.env` file to fit your needs with the editor of your choice. +We are using `nano` in the following example: + +```sh +nano .env +``` + +Follow the instructions provided in the file. +With `nano`, you can save your changes and exit the editor using `CTRL+O` and `CTRL+X`. + +:::note + +You can configure your node to either use HTTP or HTTPS. For publicly exposed nodes, we heavily recommend using HTTPS. + +::: + +```sh reference +https://github.com/iotaledger/node-docker-setup/blob/main/iota2-testnet/env_template +``` + +### 3. Setup neighbors + +Add your IOTA-Core neighbor addresses to the `peering.json` file. + +:::note + +This step is recommended but optional if you are using autopeering. + +::: + +### 4. Create the `data` folder + +All files used by IOTA-Core, the INX extensions, Traefik & co will be stored in a directory called `data`. +Docker image runs under user with user id `65532` and group id `65532`, so this directory needs to have the correct permissions to be accessed by the containers. +To create this directory with correct permissions, run the contained script: + +```sh +./prepare_docker.sh +``` + +## Run + +### Starting the node + +You can start IOTA-Core node and INX extensions by running: + +```sh +docker compose up -d +``` + +- `-d` Instructs Docker to start the containers in the background. + +#### HTTPS + +After starting the node, you will be able to access your services at the following endpoints: + +- API: `https://node.your-domain.com/api/routes` +- IOTA-Core Dashboard: `https://node.your-domain.com/dashboard` +- Grafana: `https://node.your-domain.com/grafana` _(optional if using "monitoring" profile)_ + +:::warning + +After starting your node for the first time, please change the default grafana credentials. +**User**: `admin` +**Password**: `admin` + +::: + +You can configure your wallet software to use `https://node.your-domain.com`. + +#### HTTP + +After starting the node, you will be able to access your services at the following endpoints: + +- API: `http://localhost/api/routes` +- IOTA-Core Dashboard: `http://localhost/dashboard` +- Grafana: `http://localhost/grafana` _(optional if using "monitoring" profile)_ + +:::note + +If you changed the default `HTTP_PORT` value, you must add the port to the URLs. + +::: + +You can configure your wallet software to use `http://localhost`. + +### Displaying Log Output + +You can display IOTA-Core logs by running: + +```sh +docker compose logs -f iota-core +``` + +- `-f` + Instructs Docker to continue displaying the log to `stdout` until CTRL+C is pressed. + +### Stopping the node + +You can stop the IOTA-Core node and INX extensions by running: + +```sh +docker compose down +``` + +### Tools + +To access IOTA-Core tools, you can use the following command: + +```sh +docker compose run iota-core tool +``` + +To see the list of tools included run the following: + +```sh +docker compose run iota-core tool -h +``` + +## JWT Auth + +To generate a JWT token to be used to access protected routes, you can run the following: + +```sh +docker compose run iota-core tool jwt-api --databasePath data/p2pstore +``` + +- If you changed the `restAPI.jwtAuth.salt` value in the `config.json`, then you need to pass that value as a parameter as `--salt `. + +## INX + +This setup includes the INX extensions listed at the beginning of this guide. +If you want to disable certain extensions, you can comment out the different services in the `docker-compose.yml` file and restart the node. + +# More Information + +You can find more information in the [GitHub repository](https://github.com/iotaledger/node-docker-setup) diff --git a/docs/maintain/iota-core/1.0/docs/how_tos/validator_setup.md b/docs/maintain/iota-core/1.0/docs/how_tos/validator_setup.md new file mode 100644 index 00000000000..fe68288952c --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/how_tos/validator_setup.md @@ -0,0 +1,360 @@ +--- +description: Learn how to become a validator. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - Docker + - Install + - Run + - Validator + - Staking + - macOS + - Windows + - Linux + - how to +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import LinuxCommands from '@site/docs/_admonitions/_linux-commands.md'; + +# Validator Setup Guide + +Validators secure the network by issuing validation blocks and receive Mana as a reward. To become a validator, you need +to create an account that can issue blocks, and the account needs to stake tokens. This guide explains how to create the +account and configure the validator plugin of the docker setup. +The validator plugin will then try to make the account a validator by issuing a candidacy announcement to the network. +The validator plugin will start issuing validation blocks if selected for the committee. + +:::info + +Running a validator implies [running a full-node setup](using_docker.md). + +::: + +Throughout the guide, we will use the CLI wallet from the iota-SDK and the [node docker setup](./using_docker.md). + +:::tip notation + +This guide uses the following notation. If `Public Key` has a value of `0xff`, then running the +command `echo {Public Key}` means replacing the variable `{Public Key}` with its value, i.e., running the +command `echo 0xff`. + +::: + +## Set Up the CLI Wallet + +### 1a. Download the latest Version + +You can download the latest release of the CLI Wallet from the following link: +https://github.com/iotaledger/iota-sdk/releases/tag/cli-wallet-v2.0.0-beta.2 + +After downloading, copy the binary to your current directory. + +### 1b. Build From Source + +:::info Pre-build Release + +If you already downloaded the pre-build release version, you can skip this section and continue with [Connect to a Node](#2-connect-to-a-node) + +::: + +Please follow the instructions to build the CLI Wallet from source: + +#### 1. Clone the Repository + +You can clone the repository by running the following command: + +```bash +git clone -b 2.0 https://github.com/iotaledger/iota-sdk +``` + +#### 2. Build + +After you have downloaded the source code, you can build it by changing the current directory to `iota-sdk/cli` and +running the following command: + +```bash +cargo build --release +``` + +#### 3. (optional) Copy the Wallet + +For ease of access, you can copy the Wallet that you built into your current directory or even add it to your $PATH: + +```bash +cp ../target/release/wallet wallet +``` + +### 2. Connect to a Node + +You can use the following command to connect your wallet to a Testnet node — alternatively, your node’s URL: + +```bash +./wallet init --node-url "https://api.nova-testnet.iotaledger.net" +``` + +### 3. Configure Your Wallet + +Once you’ve connected your wallet to a node, you must answer the following setup questions: + +:::info Not Mentioned Questions + +The setup questions that aren't asked here you can configure however you prefer, there config doesn't matter for this how-to. + +::: + +#### Select secret manager. + +Unless you have a ledger, select Stronghold. + +#### Do you want to set the address of the new wallet? + +No. + +#### Select BIP path + +Select `Custom` as the BIP path and type `1/0/0/0`. + +#### Do you want to set an alias for the new wallet? + +Yes. + +Then, enter a wallet alias of your choice. + +## Create an Account + +:::tip Connect to a Node + +The following sections assume you have already set up your [CLI Wallet](#set-up-the-cli-wallet), +and [connected it to a node](#2-connect-to-a-node). + +::: + +### 1. Create an Implicit Account + +You can create an implicit account by running the following command: + +``` +implicit-account-creation-address +``` + +Please copy the implicit address returned by the command. + +### 2. Fund Your Account + +You can enter the address at the [Testnet Faucet](https://faucet.nova-testnet.iotaledger.net/) to fund your account or run the +following command + +```bash +faucet {implicit-address} --url https://faucet.nova-testnet.iotaledger.net/api/enqueue +``` + +### 3. Sync With the Node + +After creating and funding your implicit account, you should use the `sync` and `implicit-accounts` functionalities to +retrieve the implicit account creation output. + +```bash +sync +implicit-accounts +``` + +You should run this until the BIC changes from `None` to `Some(0)`, then copy the `Output Id`. + +### 4. Transition the Implicit Account to a Full Account + +You need to transition your implicit account to a full account to be able to become a validator by running the following +command: + +```bash +implicit-account-transition {Output Id} +``` + +### 5. Sync With the Node + +You can now `sync` with the node and run the `accounts` command to ensure an account is displayed with Block Issuance +Credit of `0`, which is the case if it displays `Some(0)` instead of `None`. + +```bash +sync +accounts +``` + +You now have a block issuer account and can send transactions as you wish if you have enough Mana available. + +## Adding a Block Issuer Key + +### 1. Generate an Ed25519 Keypair + +In the directory of the [node docker setup](./using_docker.md), you can run the following command to generate an +Ed25519 keypair: + +```bash +docker compose run iota-core tools ed25519-key +``` + +Please take note of the `ed25519 public key` and `ed25519 private key` and add a `0x` at the beginning of the public +key. + +### 2. Select a Validator Account + +You can now return to the wallet and `sync` it. Afterward, you should run the `accounts` command to retrieve the list of +available accounts and choose an account you want to use as a validator to issue validation block. Please take note of +its `Account ID` and `Account Address`. + +```bash +sync +accounts +``` + +### 3. Add the Account as a Block Issuer + +You can add the account as a block issuer using the following command: + +:::note + +The public key needs to have the `0x` prefix. + +::: + +```bash +add-block-issuer-key {Account ID} {ed25519 public key} +``` + +### 4. Verify + +You can verify you successfully added the key by running the `sync` and `accounts` commands. You should then copy +the `Output ID` of the account and run the `output {Output ID}` command. + +```bash +sync +account +output {Output ID} +``` + +You can find the `block_issuer_keys` list in the `features` section of the retrieved output. It should show two entries +that look like these but with different values: + +```plaintext +block_issuer_keys: BlockIssuerKeys( + [ + 0x16cbbea33ebcf2e17528737ee64b7b8290fe5c5b0d3c60a05a05bff3d2517b10, + 0x1a6709248bd6f06b103e0b3173c16c69d9a457d447409a6efc9612ffb64da964, + ], +``` + +## Start Staking + +### 1. Sync With the Node + +To start staking, you first need to run the `sync` and `accounts` commands and take note of the `Account ID` of the +account you want to use as a validator. + +```bash +sync +account +``` + +### 2. Decide Your Stake Amount + +Next, you should run the `output {Output ID}` command and take note of the `amount`. This is the highest possible amount +you can stake. Decide how much you want to stake. The `Stake Amount` can be anything between `1` and the +displayed `amount`. + +```bash +output {Output ID} +``` + +:::tip + +The higher your `Stake Amount`, the more likely you will be selected for the validator committee, so +setting `Stake Amount = amount` is preferred. + +::: + +### 3. Decide on a `Fixed Cost` + +This value is not particularly important for the Testnet. A recommended value is anywhere between 1 and 10. + +### 4. Begin Staking + +You can use the following command to start staking: + +```sh +begin-staking {Account ID} {Stake Amount} {Fixed Cost} +``` + +You can verify you successfully started staking by running the `sync` and `accounts` commands, copying the `Output ID` of the account, and then running `output {Output ID}`. You should be able to find the `StakingFeature` within the `features` section. It should show the `Stake Amount` and `Fixed Cost` you just entered. It should look like this, but with the values you entered: + +``` + +StakingFeature { +staked_amount: 1000000000, +fixed_cost: 1, +... + +``` + +The account is now registered as a validator. Next, you must set up the infrastructure to issue validation blocks to secure the network. + +## Prepare the Validator Plugin + +Running a validator requires running a full IOTA-Core node. You can follow the steps outlined in the [how to install using Docker guide](./using_docker.md) to setup the node. + +Follow the next steps after successfully setting up the node or while setting it up at your choice. + +### 1. Update the `.env` File + +You must modify the `.env` file in the following ways: + +1. Uncomment the `COMPOSE_PROFILES` line below the validator service. +2. Set the `Account Address` from earlier as the `VALIDATOR_ACCOUNT_ADDR`. +3. Set the `ed25519 private key` from earlier as the `VALIDATOR_PRV_KEY` (**with no** 0x prefix). + +### 2. Allot Mana to the Account + +The selected account needs Mana to issue candidacy announcements to the network. The Mana must be _allotted_ to the account. You can do this using the `allot-mana` command in the CLI wallet or the developer tools in Firefly. In the CLI Wallet, first check how much Mana can be allotted using `sync`, which shows you a `ManaBalance`: + +``` +ManaBalance { + total: DecayedMana { + stored: 1861687, + potential: 19380254, + }, + available: DecayedMana { + stored: 1861687, + potential: 19380254, + }, + rewards: 0, +}, +``` + +Set `Mana` as `stored + potential` from the `available` section. + +Now we allot the Mana to our account. If you happen to have multiple accounts, you also need to specify the ID of the account that will be used as the validator account. + +```bash +allot-mana {Mana} +``` + +### 3. Verify the `inx-validator` + +When you start the docker containers, an `inx-validator` container should also start. You can check the logs to see if +everything is working with the following command: + +```bash +docker logs -f inx-validator +``` + +If the logs don't show any errors, you should be good to go. The network will select you as a validator if your stake is +high enough. You can check the stake requirements as follows: The total pool stake, which consists of +your `Stake Amount` and all the stake that is delegated to your account, must be greater than the _Pool Stake_ of the +last entry in the [validator list](https://explorer.iota.org/iota2-testnet/validators/). Note that this list +might change every epoch, so the stake requirements might also change. + +You can check your _Total pool stake_ by taking the `Account Address`, opening the following URL, and checking +the `Validation` tab: + +`https://explorer.iota.org/iota2-testnet/addr/{Account Address}` diff --git a/docs/maintain/iota-core/1.0/docs/references/api_reference.md b/docs/maintain/iota-core/1.0/docs/references/api_reference.md new file mode 100644 index 00000000000..24c8f7b90e2 --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/references/api_reference.md @@ -0,0 +1,16 @@ +--- +description: Links to the REST API reference and the Node event API reference. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - REST API + - API + - Reference +--- + +# API Reference + +You can find specifications of the APIs exposed by in the links below: + +- [Core REST API v3](/apis/core/v3/iota-core-rest-api) diff --git a/docs/maintain/iota-core/1.0/docs/references/configuration.md b/docs/maintain/iota-core/1.0/docs/references/configuration.md new file mode 100755 index 00000000000..490cc9a3725 --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/references/configuration.md @@ -0,0 +1,460 @@ +--- +# !!! DO NOT MODIFY !!! +# This file is auto-generated by the gendoc tool based on the source code of the app. +description: This section describes the configuration parameters and their types for your IOTA core node. +keywords: + - IOTA Node + - Configuration + - JSON + - Customize + - Config + - reference +--- +# Configuration + +The IOTA core node uses a JSON standard format as a config file. If you are unsure about JSON syntax, you can find more information in the [official JSON specs](https://www.json.org). + +You can change the path of the config file by using the `-c` or `--config` argument while executing `iota-core` executable. + +For example: +```bash +iota-core -c config_example.json +``` + +You can always get the most up-to-date description of the config parameters by running: + +```bash +iota-core -h --full +``` + +## 1. Application + +| Name | Description | Type | Default value | +| ------------------------- | ------------------------------------------------------ | ------- | ------------- | +| checkForUpdates | Whether to check for updates of the application or not | boolean | true | +| [shutdown](#app_shutdown) | Configuration for shutdown | object | | + +### Shutdown + +| Name | Description | Type | Default value | +| ------------------------ | ------------------------------------------------------------------------------------------------------ | ------ | ------------- | +| stopGracePeriod | The maximum time to wait for background processes to finish during shutdown before terminating the app | string | "5m" | +| [log](#app_shutdown_log) | Configuration for log | object | | + +### Log + +| Name | Description | Type | Default value | +| -------- | --------------------------------------------------- | ------- | -------------- | +| enabled | Whether to store self-shutdown events to a log file | boolean | true | +| filePath | The file path to the self-shutdown log | string | "shutdown.log" | + +Example: + +```json + { + "app": { + "checkForUpdates": true, + "shutdown": { + "stopGracePeriod": "5m", + "log": { + "enabled": true, + "filePath": "shutdown.log" + } + } + } + } +``` + +## 2. Logger + +| Name | Description | Type | Default value | +| ----------- | -------------------------------------------------------------------------------------------------------------- | ------ | ------------- | +| name | The optional name of the logger instance. All log messages are prefixed with that name. | string | "" | +| level | The minimum enabled logging level | string | "info" | +| timeFormat | Sets the logger's timestamp format. (options: "rfc3339", "rfc3339nano", "datetime", "timeonly", and "iso8601") | string | "rfc3339" | +| outputPaths | A list of file paths or stdout/stderr to write logging output to | array | stdout | + +Example: + +```json + { + "logger": { + "name": "", + "level": "info", + "timeFormat": "rfc3339", + "outputPaths": [ + "stdout" + ] + } + } +``` + +## 3. Peer to Peer + +| Name | Description | Type | Default value | +| ------------------------------------------- | ----------------------------------------------------------------- | ------ | -------------------------------------------- | +| bindMultiAddresses | The bind multi addresses for p2p connections | array | /ip4/0.0.0.0/tcp/15600
/ip6/::/tcp/15600 | +| [connectionManager](#p2p_connectionmanager) | Configuration for connectionManager | object | | +| identityPrivateKey | Private key used to derive the node identity (optional) | string | "" | +| identityPrivateKeyFilePath | The file path to the private key used to derive the node identity | string | "testnet/p2p/identity.key" | +| [autopeering](#p2p_autopeering) | Configuration for autopeering | object | | + +### ConnectionManager + +| Name | Description | Type | Default value | +| ------------- | ---------------------------------------------------------------------------- | ---- | ------------- | +| highWatermark | The threshold up on which connections count truncates to the lower watermark | int | 10 | +| lowWatermark | The minimum connections count to hold after the high watermark was reached | int | 5 | + +### Autopeering + +| Name | Description | Type | Default value | +| ---------------------- | -------------------------------------------------------------------------- | ------- | ------------- | +| maxPeers | The max number of auto-peer connections. Set to 0 to disable auto-peering. | int | 5 | +| bootstrapPeers | Peers to be used as discovery for other peers | array | | +| allowLocalIPs | Allow local IPs to be used for autopeering | boolean | false | +| externalMultiAddresses | External reacheable multi addresses advertised to the network | array | | + +Example: + +```json + { + "p2p": { + "bindMultiAddresses": [ + "/ip4/0.0.0.0/tcp/15600", + "/ip6/::/tcp/15600" + ], + "connectionManager": { + "highWatermark": 10, + "lowWatermark": 5 + }, + "identityPrivateKey": "", + "identityPrivateKeyFilePath": "testnet/p2p/identity.key", + "autopeering": { + "maxPeers": 5, + "bootstrapPeers": [], + "allowLocalIPs": false, + "externalMultiAddresses": [] + } + } + } +``` + +## 4. Profiling + +| Name | Description | Type | Default value | +| ----------- | ------------------------------------------------- | ------- | ---------------- | +| enabled | Whether the profiling component is enabled | boolean | false | +| bindAddress | The bind address on which the profiler listens on | string | "localhost:6060" | + +Example: + +```json + { + "profiling": { + "enabled": false, + "bindAddress": "localhost:6060" + } + } +``` + +## 5. RestAPI + +| Name | Description | Type | Default value | +| --------------------------- | ---------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| bindAddress | The bind address on which the REST API listens on | string | "0.0.0.0:14265" | +| publicRoutes | The HTTP REST routes which can be called without authorization. Wildcards using \* are allowed | array | /health
/api/routes
/api/core/v3/info
/api/core/v3/network\*
/api/core/v3/blocks\*
/api/core/v3/transactions\*
/api/core/v3/commitments\*
/api/core/v3/outputs\*
/api/core/v3/accounts\*
/api/core/v3/validators\*
/api/core/v3/rewards\*
/api/core/v3/committee\*
/api/debug/v2/\*
/api/indexer/v2/\*
/api/mqtt/v2
/api/blockissuer/v1/\* | +| protectedRoutes | The HTTP REST routes which need to be called with authorization. Wildcards using \* are allowed | array | /api/\* | +| debugRequestLoggerEnabled | Whether the debug logging for requests should be enabled | boolean | false | +| maxPageSize | The maximum number of results per page | uint | 100 | +| maxCacheSize | The maximum size of cache for results | string | "50MB" | +| [jwtAuth](#restapi_jwtauth) | Configuration for JWT Auth | object | | +| [limits](#restapi_limits) | Configuration for limits | object | | + +### JWT Auth + +| Name | Description | Type | Default value | +| ---- | --------------------------------------------------------------------------------------------------------------------------------------- | ------ | ------------- | +| salt | Salt used inside the JWT tokens for the REST API. Change this to a different value to invalidate JWT tokens not matching this new value | string | "IOTA" | + +### Limits + +| Name | Description | Type | Default value | +| ------------- | ------------------------------------------------------------------------- | ------ | ------------- | +| maxBodyLength | The maximum number of characters that the body of an API call may contain | string | "1M" | +| maxResults | The maximum number of results that may be returned by an endpoint | int | 1000 | + +Example: + +```json + { + "restAPI": { + "bindAddress": "0.0.0.0:14265", + "publicRoutes": [ + "/health", + "/api/routes", + "/api/core/v3/info", + "/api/core/v3/network*", + "/api/core/v3/blocks*", + "/api/core/v3/transactions*", + "/api/core/v3/commitments*", + "/api/core/v3/outputs*", + "/api/core/v3/accounts*", + "/api/core/v3/validators*", + "/api/core/v3/rewards*", + "/api/core/v3/committee*", + "/api/debug/v2/*", + "/api/indexer/v2/*", + "/api/mqtt/v2", + "/api/blockissuer/v1/*" + ], + "protectedRoutes": [ + "/api/*" + ], + "debugRequestLoggerEnabled": false, + "maxPageSize": 100, + "maxCacheSize": "50MB", + "jwtAuth": { + "salt": "IOTA" + }, + "limits": { + "maxBodyLength": "1M", + "maxResults": 1000 + } + } + } +``` + +## 6. DebugAPI + +| Name | Description | Type | Default value | +| ------------------ | ----------------------------------------- | ------- | ------------- | +| enabled | Whether the DebugAPI component is enabled | boolean | false | +| [db](#debugapi_db) | Configuration for Database | object | | + +### Database + +| Name | Description | Type | Default value | +| ------------------------------- | ---------------------------------------------------------- | ------ | --------------- | +| path | The path to the database folder | string | "testnet/debug" | +| maxOpenDBs | Maximum number of open database instances | int | 2 | +| granularity | How many slots should be contained in a single DB instance | int | 100 | +| [pruning](#debugapi_db_pruning) | Configuration for pruning | object | | + +### Pruning + +| Name | Description | Type | Default value | +| --------- | ---------------------------------- | ---- | ------------- | +| threshold | How many epochs should be retained | uint | 1 | + +Example: + +```json + { + "debugAPI": { + "enabled": false, + "db": { + "path": "testnet/debug", + "maxOpenDBs": 2, + "granularity": 100, + "pruning": { + "threshold": 1 + } + } + } + } +``` + +## 7. MetricsTracker + +| Name | Description | Type | Default value | +| ------- | --------------------------------------------- | ------- | ------------- | +| enabled | Whether the Metrics Tracker plugin is enabled | boolean | true | + +Example: + +```json + { + "metricsTracker": { + "enabled": true + } + } +``` + +## 8. Database + +| Name | Description | Type | Default value | +| ---------------------- | ----------------------------------------- | ------ | ------------------ | +| engine | The used database engine (rocksdb/mapdb) | string | "rocksdb" | +| path | The path to the database folder | string | "testnet/database" | +| maxOpenDBs | Maximum number of open database instances | int | 5 | +| [pruning](#db_pruning) | Configuration for pruning | object | | + +### Pruning + +| Name | Description | Type | Default value | +| ------------------------ | -------------------------------------------- | ------ | ------------- | +| threshold | How many finalized epochs should be retained | uint | 30 | +| [size](#db_pruning_size) | Configuration for size | object | | + +### Size + +| Name | Description | Type | Default value | +| ------------------- | --------------------------------------------------------------------------------- | ------- | ------------- | +| enabled | Whether to delete old block data from the database based on maximum database size | boolean | true | +| targetSize | Target size of the database | string | "30GB" | +| reductionPercentage | The percentage the database size gets reduced if the target size is reached | float | 10.0 | +| cooldownTime | Cooldown time between two pruning by database size events | string | "5m" | + +Example: + +```json + { + "db": { + "engine": "rocksdb", + "path": "testnet/database", + "maxOpenDBs": 5, + "pruning": { + "threshold": 30, + "size": { + "enabled": true, + "targetSize": "30GB", + "reductionPercentage": 10, + "cooldownTime": "5m" + } + } + } + } +``` + +## 9. Protocol + +| Name | Description | Type | Default value | +| -------------------------------- | ---------------------------------------------------------------- | ------- | ---------------------------------- | +| [snapshot](#protocol_snapshot) | Configuration for snapshot | object | | +| commitmentCheck | Specifies whether commitment and ledger checks should be enabled | boolean | true | +| [filter](#protocol_filter) | Configuration for filter | object | | +| protocolParametersPath | The path of the protocol parameters file | string | "testnet/protocol_parameters.json" | +| [baseToken](#protocol_basetoken) | Configuration for baseToken | object | | + +### Snapshot + +| Name | Description | Type | Default value | +| ----- | ------------------------------------------------------------------------------------------ | ------ | ---------------------- | +| path | The path of the snapshot file | string | "testnet/snapshot.bin" | +| depth | Defines how many slot diffs are stored in the snapshot, starting from the full ledgerstate | int | 5 | + +### Filter + +| Name | Description | Type | Default value | +| -------------------- | ------------------------------------------------------------------------------------------ | ------ | ------------- | +| maxAllowedClockDrift | The maximum drift our wall clock can have to future blocks being received from the network | string | "5s" | + +### BaseToken + +| Name | Description | Type | Default value | +| ------------ | --------------------------------- | ------ | ------------- | +| name | The base token name | string | "Shimmer" | +| tickerSymbol | The base token ticker symbol | string | "SMR" | +| unit | The base token unit | string | "SMR" | +| subunit | The base token subunit | string | "glow" | +| decimals | The base token amount of decimals | uint | 6 | + +Example: + +```json + { + "protocol": { + "snapshot": { + "path": "testnet/snapshot.bin", + "depth": 5 + }, + "commitmentCheck": true, + "filter": { + "maxAllowedClockDrift": "5s" + }, + "protocolParametersPath": "testnet/protocol_parameters.json", + "baseToken": { + "name": "Shimmer", + "tickerSymbol": "SMR", + "unit": "SMR", + "subunit": "glow", + "decimals": 6 + } + } + } +``` + +## 10. Retainer + +| Name | Description | Type | Default value | +| ----------------------- | ----------------------------------------------------- | ------- | ------------- | +| debugStoreErrorMessages | Whether to store debug error messages in the database | boolean | false | + +Example: + +```json + { + "retainer": { + "debugStoreErrorMessages": false + } + } +``` + +## 11. Node + +| Name | Description | Type | Default value | +| ----- | ------------------------------- | ------ | ---------------- | +| alias | Set an alias to identify a node | string | "IOTA-Core node" | + +Example: + +```json + { + "node": { + "alias": "IOTA-Core node" + } + } +``` + +## 12. Prometheus + +| Name | Description | Type | Default value | +| --------------- | ---------------------------------------------------- | ------- | -------------- | +| enabled | Whether the Metrics component is enabled | boolean | true | +| bindAddress | Bind address on which the Prometheus exporter server | string | "0.0.0.0:9311" | +| goMetrics | Include go metrics | boolean | false | +| processMetrics | Include process metrics | boolean | false | +| promhttpMetrics | Include promhttp metrics | boolean | false | + +Example: + +```json + { + "prometheus": { + "enabled": true, + "bindAddress": "0.0.0.0:9311", + "goMetrics": false, + "processMetrics": false, + "promhttpMetrics": false + } + } +``` + +## 13. INX + +| Name | Description | Type | Default value | +| ----------- | ------------------------------------------------------ | ------- | ---------------- | +| enabled | Whether the INX plugin is enabled | boolean | false | +| bindAddress | The bind address on which the INX can be accessed from | string | "localhost:9029" | + +Example: + +```json + { + "inx": { + "enabled": false, + "bindAddress": "localhost:9029" + } +} +``` diff --git a/docs/maintain/iota-core/1.0/docs/welcome.md b/docs/maintain/iota-core/1.0/docs/welcome.md new file mode 100644 index 00000000000..f77e433ec75 --- /dev/null +++ b/docs/maintain/iota-core/1.0/docs/welcome.md @@ -0,0 +1,27 @@ +--- +description: The IOTA-Core is a powerful, easy to install node software written in Go. It provides the full node capabilities including full support of the latest network updates. +image: /img/icons/iota/iota_core.png +tags: + - IOTA Node + - IOTA-Core Node + - IOTA-Core + - IOTA + - Node Software + - Welcome + - explanation +--- + +# Welcome to IOTA-Core + +The IOTA-Core is a powerful, easy-to-install node software written in Go. +It provides full-node capabilities, including full support for the latest network updates. + +By running your own node, you have the following benefits: + +- You have direct access to the IOTA network instead of having to connect to and trust someone else's node. +- You help the network to become more distributed and resilient by validating blocks and value transactions. + +## Source Code + +The project's source code is available on [GitHub](https://github.com/iotaledger/iota-core). + diff --git a/docs/maintain/iota-core/1.0/sidebars.js b/docs/maintain/iota-core/1.0/sidebars.js new file mode 100644 index 00000000000..1716dce275c --- /dev/null +++ b/docs/maintain/iota-core/1.0/sidebars.js @@ -0,0 +1,315 @@ +/** + * * Creating a sidebar enables you to: + - create an ordered group of docs + - render a sidebar for each doc of that group + - provide next/previous navigation + + The sidebars can be generated from the filesystem, or explicitly defined here. + + Create as many sidebars as you want. + */ + +module.exports = { + docs: [ + { + type: 'category', + label: 'IOTA-Core', + collapsed: false, + items: [ + { + type: 'doc', + id: 'welcome', + }, + { + type: 'doc', + id: 'getting_started/getting_started', + }, + { + type: 'category', + label: 'How to', + items: [ + { + type: 'doc', + id: 'how_tos/using_docker', + label: 'Install using Docker', + }, + { + type: 'doc', + id: 'how_tos/validator_setup', + label: 'Become a validator', + }, + { + type: 'doc', + id: 'how_tos/post_installation', + label: 'Post Installation', + }, + ], + } /* + { + type: 'category', + label: 'INX-Plugins', + link: { + type: 'generated-index', + title: 'INX-Plugins', + description: + 'Use custom plugins to extend the functionality of your node.', + slug: '/inx-plugins', + keywords: ['inx', 'plugins'], + }, + items: [ + { + type: 'category', + label: 'API Core v0', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/api-core-v0/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/api-core-v0/configuration', + }, + ], + }, + { + type: 'category', + label: 'API Core v1', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/api-core-v1/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/api-core-v1/configuration', + }, + ], + }, + { + type: 'category', + label: 'Coordinator', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/coordinator/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/coordinator/configuration', + }, + ], + }, + { + type: 'category', + label: 'Dashboard', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/dashboard/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/dashboard/configuration', + }, + ], + }, + { + type: 'category', + label: 'Faucet', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/faucet/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/faucet/configuration', + }, + ], + }, + { + type: 'category', + label: 'Indexer', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/indexer/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/indexer/configuration', + }, + { + type: 'doc', + label: 'API Reference', + id: 'inx-plugins/indexer/api_reference', + }, + { + type: 'doc', + label: 'How To Query Outputs', + id: 'inx-plugins/indexer/how_to/query_outputs', + }, + ], + }, + { + type: 'category', + label: 'IRC Metadata', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/irc-metadata/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/irc-metadata/configuration', + }, + { + type: 'doc', + label: 'API Reference', + id: 'inx-plugins/irc-metadata/api_reference', + }, + ], + }, + { + type: 'category', + label: 'MQTT', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/mqtt/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/mqtt/configuration', + }, + { + type: 'doc', + label: 'API Reference', + id: 'inx-plugins/mqtt/api_reference', + }, + ], + }, + { + type: 'category', + label: 'Participation', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/participation/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/participation/configuration', + }, + { + type: 'doc', + label: 'API Reference', + id: 'inx-plugins/participation/api_reference', + }, + ], + }, + { + type: 'category', + label: 'POI', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/poi/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/poi/configuration', + }, + { + type: 'doc', + label: 'API Reference', + id: 'inx-plugins/poi/api_reference', + }, + ], + }, + { + type: 'category', + label: 'Spammer', + collapsed: true, + items: [ + { + type: 'doc', + label: 'Welcome', + id: 'inx-plugins/spammer/welcome', + }, + { + type: 'doc', + label: 'Configuration', + id: 'inx-plugins/spammer/configuration', + }, + ], + }, + { + type: 'category', + label: 'Community INX Plugins', + collapsed: true, + items: [ + { + label: 'INX Collector', + type: 'link', + href: 'https://github.com/teleconsys/inx-collector', + }, + ], + }, + ], + },*/, + { + type: 'category', + label: 'References', + items: [ + { + type: 'doc', + id: 'references/configuration', + label: 'Configuration', + } /* + { + type: 'doc', + id: 'references/peering', + label: 'Peering', + },*/, + { + type: 'doc', + id: 'references/api_reference', + label: 'API Reference', + }, + ], + }, + ], + }, + ], +}; diff --git a/docusaurus.config.js b/docusaurus.config.js index 54475f71726..c66a516cdde 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -144,6 +144,15 @@ module.exports = async () => { defaultMode: 'dark', }, switcher: switcherConfig, + + announcementBar: { + id: 'support_us', + content: + 'Experience seamless dApp development with IOTA EVM.', + backgroundColor: 'var(--ifm-color-primary)', + textColor: 'var(--ifm-font-color-base-inverse);', + isCloseable: true, + }, }, }; @@ -249,7 +258,7 @@ module.exports = async () => { id: 'openapi', docsPluginId: 'apis', // e.g. "classic" or the plugin-content-docs id config: { - coreApiShimmer: { + coreApiV2: { specPath: 'https://raw.githubusercontent.com/iotaledger/tips/main/tips/TIP-0025/core-rest-api.yaml', outputDir: path.resolve( @@ -260,6 +269,17 @@ module.exports = async () => { groupPathsBy: 'tag', }, }, + coreApiV3: { + specPath: + 'https://raw.githubusercontent.com/iotaledger/tips/tip48/tips/TIP-0048/openapi3-core.yaml', + outputDir: path.resolve( + __dirname, + 'docs/build/apis/docs/core/v3', + ), + sidebarOptions: { + groupPathsBy: 'tag', + }, + }, waspApi: { specPath: 'https://raw.githubusercontent.com/iotaledger/wasp/develop/clients/apiclient/api/openapi.yaml', diff --git a/src/components/HomeLayout/index.tsx b/src/components/HomeLayout/index.tsx index 93d79f53f17..a068a322388 100644 --- a/src/components/HomeLayout/index.tsx +++ b/src/components/HomeLayout/index.tsx @@ -18,7 +18,7 @@ const { IntegrationServices, IotaCore, PickAWallet, - Shimmer, + IotaEVM, Search, Tips, Tutorials, @@ -85,6 +85,12 @@ export default function HomeLayout() { > Start building + + Build your dApp on IOTA EVM + @@ -106,18 +112,16 @@ export default function HomeLayout() {

- +
- +
-

What is Shimmer?

+

Build on IOTA EVM

- A scalable and feeless network enabling frictionless - decentralized and scalable Web3 economies. + Experience seamless dApp development with IOTA EVM's oracles, + subgraphs, Layer 0 interoperability, and robust Blast API + endpoints.{' '}

diff --git a/src/icons/iota/index.ts b/src/icons/iota/index.ts index 5b096a14155..0c2b8d46a30 100644 --- a/src/icons/iota/index.ts +++ b/src/icons/iota/index.ts @@ -6,6 +6,7 @@ import { default as Identity } from '@site/static/icons/iota/identity.svg'; import { default as IntegrationServices } from '@site/static/icons/iota/integration_services.svg'; import { default as Iota20 } from '@site/static/icons/iota/iota_20.svg'; import { default as IotaCore } from '@site/static/icons/iota/iota_core.svg'; +import { default as IotaEVM } from '@site/static/icons/iota/iota_evm.svg'; import { default as IotaToken } from '@site/static/icons/iota/iota_token.svg'; import { default as Next } from '@site/static/icons/iota/next.svg'; import { default as PickAWallet } from '@site/static/icons/iota/pick_a_wallet.svg'; @@ -29,6 +30,7 @@ export default { IntegrationServices, Iota20, IotaCore, + IotaEVM, IotaToken, Next, PickAWallet, diff --git a/static/icons/iota/iota_evm.svg b/static/icons/iota/iota_evm.svg new file mode 100644 index 00000000000..6062f9fb96c --- /dev/null +++ b/static/icons/iota/iota_evm.svg @@ -0,0 +1,3 @@ + + + diff --git a/static/icons/iota/iota_evm_dm.svg b/static/icons/iota/iota_evm_dm.svg new file mode 100644 index 00000000000..9096955db5f --- /dev/null +++ b/static/icons/iota/iota_evm_dm.svg @@ -0,0 +1,70 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/theme/src/theme/NetworkInfo/index.tsx b/theme/src/theme/NetworkInfo/index.tsx index 15735129435..4f6fc580bd1 100644 --- a/theme/src/theme/NetworkInfo/index.tsx +++ b/theme/src/theme/NetworkInfo/index.tsx @@ -2,23 +2,22 @@ import React from 'react'; import { ChainId } from '../ChainId'; import { NetworkProps } from '../constant'; import CodeBlock from '@theme/CodeBlock'; +import Admonition from '@theme/Admonition'; function L1(props: NetworkProps) { return ( - + - - - - + - - - + + + + + + + + + + + - - - - + - - - + + + + + + + + + + + + + + - - - - - + + + + diff --git a/theme/src/theme/constant.tsx b/theme/src/theme/constant.tsx index 8882d3061df..114053c14a8 100644 --- a/theme/src/theme/constant.tsx +++ b/theme/src/theme/constant.tsx @@ -19,6 +19,14 @@ export const Networks = { 'wss://ws.json-rpc.evm.iotaledger.net', ], blockExplorerUrls: ['https://explorer.evm.iota.org'], + blastApiUrls: [ + 'https://iota-mainnet-evm.public.blastapi.io', + 'wss://iota-mainnet-evm.public.blastapi.io', + { + 'Archive RPC': + 'https://iota-mainnet-evm.blastapi.io/e7596858-fc63-4a54-8727-b885a2af4ec8', + }, + ], }, evmCustom: { chainAddress: @@ -57,6 +65,14 @@ export const Networks = { 'wss://ws.json-rpc.evm.testnet.iotaledger.net', ], blockExplorerUrls: ['https://explorer.evm.testnet.iotaledger.net'], + blastApiUrls: [ + 'https://iota-testnet-evm.public.blastapi.io', + 'wss://iota-testnet-evm.public.blastapi.io', + { + 'Archive RPC': + 'https://iota-testnet-evm.blastapi.io/e7596858-fc63-4a54-8727-b885a2af4ec8', + }, + ], }, evmCustom: { chainAddress: @@ -130,6 +146,7 @@ export interface AddEthereumChainParameter { decimals: number; }; rpcUrls?: string[]; + blastApiUrls?: Array; blockExplorerUrls?: string[]; iconUrls?: string[]; // Currently ignored. } diff --git a/versionedConfig.js b/versionedConfig.js index 58b8fbb2d32..ad3a1e5fe4d 100644 --- a/versionedConfig.js +++ b/versionedConfig.js @@ -124,6 +124,19 @@ exports.maintainPluginsConfig = [ }, ], }, + { + id: 'iota-core', + label: 'IOTA-Core', + description: "IOTA's latest node software.", + icon: 'Iota20', + subsection: 'maintain-layer-1', + versions: [ + { + label: '1.0', + badges: ['Testnet'], + }, + ], + }, { id: 'wasp', label: 'Wasp',
Base TokenProtocolHTTP REST APIEvent APIPermanode API{props.baseToken}
{props.baseToken}Protocol {props.protocol}
HTTP REST API {props.httpRestApi}
Event API {props.eventApi}
Permanode API -
Base TokenProtocolChain IDRPC URLExplorer{props.baseToken}
{props.baseToken}Protocol ISC / EVM
Chain ID
RPC URL {props.evm.rpcUrls.map((url, index) => ( {url} ))}
+ + Blast API provides highly scalable + fault-tolerant API endpoints. + + + {props.evm.blastApiUrls && + props.evm.blastApiUrls.map((object, index) => + typeof object === 'string' ? ( + {object as string} + ) : ( + + {' '} + {Object.values(object)[0]}{' '} + + ), + )} +
Explorer -
Chain AddressAlias ID
Chain Address
Alias ID {props.evmCustom.aliasId}