diff --git a/articleRedirects.js b/articleRedirects.js index aa23d018481..2a7bd6f84fe 100644 --- a/articleRedirects.js +++ b/articleRedirects.js @@ -398,10 +398,6 @@ exports.articleRedirects = [ from: '/shimmer/learn/role-of-token', to: '/get-started/introduction/shimmer/shimmer-token', }, - { - from: '/shimmer/learn/smart-contracts/smart-contracts-chains', - to: '/learn/smart-contracts/isc-architecture', - }, { from: '/shimmer/learn/smart-contracts/smart-contracts-community-tutorials', to: '/learn/smart-contracts/introduction', @@ -460,7 +456,7 @@ exports.articleRedirects = [ }, { from: '/shimmer/smart-contracts/configuration', - to: '/wasp/configuration', + to: '/wasp/reference/configuration', }, { from: '/shimmer/smart-contracts/contribute', @@ -468,7 +464,7 @@ exports.articleRedirects = [ }, { from: '/shimmer/smart-contracts/metrics', - to: '/wasp/metrics', + to: '/wasp/reference/metrics', }, { from: '/shimmer/learn/smart-contracts/introduction', diff --git a/docs/build/getting-started/networks-endpoints.mdx b/docs/build/getting-started/networks-endpoints.mdx index 6bb00450915..6c9a48e0d74 100644 --- a/docs/build/getting-started/networks-endpoints.mdx +++ b/docs/build/getting-started/networks-endpoints.mdx @@ -77,14 +77,13 @@ This network is subject to occasional resets (no data retention) which are usual | ------------------------- | -------- | ----------------------------------- | ------------------------------------------------------------ | ----------------------------------------- | -------------------------------------- | | Testnet Tokens (no value) | Stardust | `https://api.testnet.shimmer.network` | wss://api.testnet.shimmer.network:443/api/mqtt/v1 (MQTT 3.1) | https://chronicle.testnet.shimmer.network | https://faucet.testnet.shimmer.network | -### Testnet EVM +### ShimmerEVM Testnet -[The Testnet EVM](https://explorer.evm.testnet.shimmer.network/) (also called ShimmerEVM Beta) runs as a layer 2 on top -of the Public Testnet. This network does not run -any IOTA protocol but instead uses ISC to facilitate an Ethereum Virtual Machine and has an enshrined bridge from to -layer 1. +[The ShimmerEVM Testnet](https://explorer.evm.testnet.shimmer.network/) runs as a layer 2 on top +of the Public Testnet. This network uses ISC to facilitate an Ethereum Virtual Machine and has an +enshrined bridge to layer 1. :::info diff --git a/docs/build/getting-started/sidebars.ts b/docs/build/getting-started/sidebars.ts index eb05e816609..449235b3c6c 100644 --- a/docs/build/getting-started/sidebars.ts +++ b/docs/build/getting-started/sidebars.ts @@ -28,12 +28,12 @@ module.exports = { { type: 'link', label: 'WASP CLI', - href: '/wasp-cli/how-tos/wasp-cli', + href: '/wasp/how-tos/wasp-cli', }, { label: 'Schema Tool', type: 'link', - href: '/wasp-wasm/how-tos/schema-tool/introduction', + href: '/isc/schema/introduction', }, { label: 'Explorer', diff --git a/docs/build/getting-started/welcome.md b/docs/build/getting-started/welcome.md index ef9c1295e8b..7d5a41ca620 100644 --- a/docs/build/getting-started/welcome.md +++ b/docs/build/getting-started/welcome.md @@ -50,5 +50,5 @@ The [IOTA Smart Contracts (ISC)](/learn/smart-contracts/introduction) bring scal contract functionality to the IOTA ecosystem. By anchoring multiple chains to the IOTA Tangle, ISC enables higher _throughput_ and lower fees than traditional single-chain solutions. Users have the freedom to create custom chains with control over gas fees and privacy settings, and the platform is virtual machine-agnostic, supporting both -[Rust/Wasm](/wasp-wasm/introduction) and [Solidity/EVM](/wasp-evm/introduction) +[Rust/Wasm](/isc/introduction) and [Solidity/EVM](/isc/introduction) smart contracts. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM-required-prior-knowledge.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM-required-prior-knowledge.md new file mode 100644 index 00000000000..c1e17089a98 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM-required-prior-knowledge.md @@ -0,0 +1,14 @@ +:::note Required Prior Knowledge + +This guide assumes you are familiar with the concept +of [tokens](https://en.wikipedia.org/wiki/Cryptocurrency#Crypto_token) +in [blockchain](https://en.wikipedia.org/wiki/Blockchain), +[Ethereum Request for Comments (ERCs)](https://eips.ethereum.org/erc)(also known as Ethereum Improvement Proposals ( +EIP)) +, [NFTs](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/introduction) +and have already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/). + +You should also have basic knowledge on how to [create](../how-tos/create-a-basic-contract.md) and [deploy](../how-tos/deploy-a-smart-contract.mdx) +a smart contract. + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM_compatibility.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM_compatibility.md new file mode 100644 index 00000000000..1f20154e1ea --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_EVM_compatibility.md @@ -0,0 +1,7 @@ +:::info EVM Compatibility + +The ISC EVM layer is also designed to be as compatible as possible with existing Ethereum +[tools](../getting-started/tools.mdx) and functionalities. However, please make sure you have checked out the current +[properties and limitations](../getting-started/compatibility.md). + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_about-accounts.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_about-accounts.md new file mode 100644 index 00000000000..4095981384d --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_about-accounts.md @@ -0,0 +1,5 @@ +:::info Accounts in ISC + +Learn more about the [different types of accounts](../explanations/how-accounts-work.md). + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_a_smart_contract.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_a_smart_contract.md new file mode 100644 index 00000000000..de4579b6d81 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_a_smart_contract.md @@ -0,0 +1,5 @@ +:::tip Deploy a Smart Contract + +Deploy a Solidity Smart Contract following our [how to Deploy a Smart Contract guide](/isc/how-tos/deploy-a-smart-contract#remix). + +::: diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_network_warning.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_network_warning.md new file mode 100644 index 00000000000..e7a18ce4286 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_network_warning.md @@ -0,0 +1,6 @@ +:::caution Only Available on Shimmer + +At the moment, Smart Contracts are only available on [Shimmer](/build/networks-endpoints/#shimmer) and +its [Public Testnet](/build/networks-endpoints/#public-testnet) network. + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_ownership.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_ownership.md new file mode 100644 index 00000000000..fa86ee2f72f --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_ownership.md @@ -0,0 +1,7 @@ +:::info Ownership + +You might want to look into making the function ownable with, for example, +[OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) +so only owners of the contract can call certain functionalities of your contract. + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_payable.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_payable.md new file mode 100644 index 00000000000..2975d1d26d4 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_payable.md @@ -0,0 +1,10 @@ +:::info Payable + +Instead of making the function payable, you could let the contract pay for the storage deposit. +If so, you will need to change the `require` statement to check if the contract's balance has enough funds: + +```solidity +require(address(this).balance > _storageDeposit); +``` + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_remix-IDE.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_remix-IDE.md new file mode 100644 index 00000000000..5cfa57d5e69 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_remix-IDE.md @@ -0,0 +1,6 @@ +:::tip Remix + +This guide will use the [Remix IDE](https://remix.ethereum.org/), but you can use this contract with any IDE you are +familiar with. + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_partials/_on_off_ledger_request.md b/docs/build/isc/v1.0.0-rc.6/docs/_partials/_on_off_ledger_request.md new file mode 100644 index 00000000000..45d59c458c3 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_partials/_on_off_ledger_request.md @@ -0,0 +1,13 @@ +### On-Ledger Requests + +An on-ledger request is a Layer 1 transaction that validator nodes retrieve from the Tangle. The Tangle acts as an +arbiter between users and chains and guarantees that the transaction is valid, making it the only way to transfer assets +to a chain or between chains. + +### Off-Ledger Requests + +If all necessary assets are in the chain already, it is possible to send a request directly to that chain's validator +nodes. +This way, you don’t have to wait for the Tangle to process the message, significantly reducing the overall confirmation +time. +Due to the shorter delay, off-ledger requests are preferred over on-ledger requests unless you need to deposit assets to the chain. \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_check_storage_deposit.md b/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_check_storage_deposit.md new file mode 100644 index 00000000000..f3b043b7ba5 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_check_storage_deposit.md @@ -0,0 +1,10 @@ +### 1. Check the Storage Deposit + +Check if the amount paid to the contract is the same as the required [storage deposit](/learn/protocols/stardust/core-concepts/storage-deposit) + and set the allowance. + +```solidity +require(msg.value == _storageDeposit*(10**12), "Please send exact funds to pay for storage deposit"); +ISCAssets memory allowance; +allowance.baseTokens = _storageDeposit; +``` \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_example_code_intro.md b/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_example_code_intro.md new file mode 100644 index 00000000000..daf06c0839b --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/_partials/how-tos/token/_example_code_intro.md @@ -0,0 +1,9 @@ +import Ownership from '../../../_admonitions/_ownership.md'; +import Payable from '../../../_admonitions/_payable.md'; +import CheckStorageDeposit from './_check_storage_deposit.md' + + + + + + diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/consensus.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/consensus.md new file mode 100644 index 00000000000..539e7c15adb --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/consensus.md @@ -0,0 +1,53 @@ +--- +description: IOTA Smart Contracts consensus is how Layer 2 validators agree to change the chain state in the same way. +image: /img/logo/WASP_logo_dark.png +tags: + - smart contracts + - consensus + - validator committee + - validators + - validator nodes + - explanation +--- + +# Consensus + +To update the chain, its committee must reach a _consensus_, meaning that more than two thirds of its validators have to +agree to change the state in the exact same way. +This prevents a single malicious node from wreaking havoc over the chain, but there are also more mundane reasons for +individual nodes to act up. + +Smart contracts are deterministic. All honest nodes will produce the same output — but only if they have received the +same input. Each validator node has its point of access to the Tangle, so it may look different to different nodes, as +new transactions take time to propagate through the network. Validator nodes will receive smart contract requests with +random delays in a random order, and, finally, all computers run on their own always slightly skewed clocks. + +## Batch Proposals + +As the first step, each node provides its vision, a _batch proposal_. The proposal contains a local timestamp, a list of +unprocessed requests, and the node's partial signature of the commitment to the current state. + +Then the nodes must agree on which batch proposals they want to work on. In short, nodes A, B, and C have to confirm +that they plan to work on proposals from A, B, and C, and from no one else. As long as there are more than two thirds of +honest nodes, they will be able to find an _asynchronous common subset_ of the batch proposals. From that point, nodes +have the same input and will produce the same result independently. + +## The Batch + +The next step is to convert the raw list of batch proposals into an actual batch. All requests from all proposals are +counted and filtered to produce the same list of requests in the same order. +The partial signatures of all nodes are combined into a full signature that is then fed to a pseudo-random function that +sorts the smart contract requests. +Validator nodes can neither affect nor predict the final order of requests in the batch. (This protects ISC +from [MEV attacks](https://ethereum.org/en/developers/docs/mev/)). + +## State Anchor + +After agreeing on the input, each node executes every smart contract request in order, independently producing the same +new block. Each node then crafts a state anchor, a Layer 1 transaction that proves the commitment to this new chain +state. The timestamp for this transaction is derived from the timestamps of all batch proposals. + +All nodes then sign the state anchor with their partial keys and exchange these signatures. This way, every node obtains +the same valid combined signature and the same valid anchor transaction, which means that any node can publish this +transaction to Layer 1. In theory, nodes could publish these state anchors every time they update the state; in +practice, they do it only every approximately ten seconds to reduce the load on the Tangle. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/context.mdx b/docs/build/isc/v1.0.0-rc.6/docs/explanations/context.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/context.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/context.mdx diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/core-contracts.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/core-contracts.md new file mode 100644 index 00000000000..acfdbf5e22c --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/core-contracts.md @@ -0,0 +1,37 @@ +--- +description: There currently are 6 core smart contracts that are always deployed on each chain, root, _default, accounts, blob, blocklog, and governance. +image: /img/banner/banner_wasp_core_contracts_overview.png +tags: + - smart contracts + - core + - initialization + - request handling + - on-chain ledger + - accounts + - data + - receipts + - reference +--- + +# Core Contracts + +![Wasp Node Core Contracts Overview](/img/banner/banner_wasp_core_contracts_overview.png) + +There are currently 7 core smart contracts that are always deployed on each +chain. These are responsible for the vital functions of the chain and +provide infrastructure for all other smart contracts: + +- [`root`](../reference/core-contracts/root.md): Responsible for the initialization of the chain, maintains registry of deployed contracts. + +- [`accounts`](../reference/core-contracts/accounts.md): Manages the on-chain ledger of accounts. + +- [`blob`](../reference/core-contracts/blob.md): Responsible for the registry of binary objects of arbitrary size. + +- [`blocklog`](../reference/core-contracts/blocklog.md): Keeps track of the blocks and receipts of requests that were processed by the chain. + +- [`governance`](../reference/core-contracts/governance.md): Handles the administrative functions of the chain. For example: rotation of the committee of validators of the chain, fees and other chain-specific configurations. + +- [`errors`](../reference/core-contracts/errors.md): Keeps a map of error codes to error messages templates. These error codes are used in request receipts. + +- [`evm`](../reference/core-contracts/evm.md): Provides the necessary infrastructure to accept Ethereum + transactions and execute EVM code. diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/how-accounts-work.md similarity index 82% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/how-accounts-work.md index 1a7036fa771..8847cb2c883 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/how-accounts-work.md @@ -1,5 +1,5 @@ --- -description: 'IOTA Smart Contracts chains keeps a ledger of on-chain account balances. On-chain accounts are identified +description: 'IOTA Smart Contracts chains keep a ledger of on-chain account balances. On-chain accounts are identified by an AgentID.' image: /img/tutorial/accounts.png tags: @@ -11,7 +11,6 @@ tags: - explanation --- - # How Accounts Work On the L1 Ledger, like with any _DLT_, we have **trustless** and **atomic** transfers of assets between addresses on the @@ -20,10 +19,14 @@ ledger. Tokens controlled by an address can be moved to another address by providing a valid signature using the private key that controls the source address. -In IOTA Smart Contracts, [each chain has a L1 address](/learn/smart-contracts/states#digital-assets-on-the-chain) (also known as the _Chain +## L1 Addresses + +In IOTA Smart Contracts, [each chain has a L1 address](../explanations/states.md#digital-assets-on-the-chain) (also known as the _Chain ID_) which enables it to control L1 assets (base tokens, native tokens and NFTs). The chain acts as a custodian of the L1 assets on behalf of different entities, thus providing a _L2 Ledger_. +## L2 Accounts + The L2 ledger is a collection of _on-chain accounts_ (sometimes called just _accounts_). L2 accounts can be owned by different entities, identified by a unique _Agent ID_. The L2 ledger is a mapping of Agent ID => balances of L2 assets. @@ -42,11 +45,11 @@ Tokens in an address account can only be moved through a request signed by the p ### Smart Contract Any _smart contract_ can be the owner of a L2 account. Recall that a smart -contract is uniquely identified in a chain by a [_hname_](/learn/smart-contracts/smart-contract-anatomy#identifying-a-smart-contract). +contract is uniquely identified in a chain by a [_hname_](smart-contract-anatomy.md#identifying-a-smart-contract). However, the hname is not enough to identify the account since a smart contract on another chain could own it. Thus, the Agent ID of a smart contract is composed as the contract hname plus the [_chain -ID_](/learn/smart-contracts/states#digital-assets-on-the-chain), with syntax `@`. For +ID_](states.md#digital-assets-on-the-chain), with syntax `@`. For example: `cebf5908@tgl1pzehtgythywhnhnz26s2vtpe2wy4y64pfcwkp9qvzhpwghzxhwkps2tk0nd`. Note that this allows trustless transfers of assets between smart contracts on the same or different chains. @@ -74,14 +77,14 @@ Tokens in an Ethereum account can only be moved by sending an Ethereum transacti The [`accounts` core contract](../reference/core-contracts/accounts.md) is responsible for managing the L2 ledger. By calling this contract, it is possible to: -- [View current account balances](../how-tos/view-account-balances.mdx) -- [Deposit funds to the chain](../how-tos/deposit-to-a-chain.mdx) -- [Withdraw funds from the chain](../how-tos/withdraw-from-a-chain.mdx) +- [View current account balances](../how-tos/core-contracts/basics/get-balance.md) +- [Deposit funds to the chain](../how-tos/send-funds-from-L1-to-L2.mdx) +- [Withdraw funds from the chain](../how-tos/core-contracts/basics/send-assets-to-l1.mdx) ## Example The following diagram illustrates an example situation. -The the IDs and hnames are shortened for simplicity. +The IDs and hnames are shortened for simplicity. [![Example situation. Two chains are deployed, with three smart contracts and one address.](/img/tutorial/accounts.png)](/img/tutorial/accounts.png) diff --git a/docs/learn/smart-contracts/invocation.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md similarity index 72% rename from docs/learn/smart-contracts/invocation.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md index 8017899911b..28756fd0713 100644 --- a/docs/learn/smart-contracts/invocation.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md @@ -14,6 +14,8 @@ tags: --- +import OnOffLedgerRequest from '../_partials/_on_off_ledger_request.md'; + # Calling a Smart Contract ## Entry Points @@ -63,31 +65,20 @@ exchange which would will the user's funds from one currency to another and send This is called _asynchronous composability_. -### On-Ledger Requests - -An on-ledger request is a Layer 1 transaction that validator nodes retrieve from the Tangle. The Tangle acts as an -arbiter between users and chains and guarantees that the transaction is valid, making it the only way to transfer assets -to a chain or between chains. However, it is the slowest way to invoke a smart contract. - -### Off-Ledger Requests - -If all necessary assets are in the chain already, it is possible to send a request directly to that chain's validator -nodes. -This way, you don’t have to wait for the Tangle to process the message, significantly reducing the overall confirmation -time. -Due to the shorter delay, off-ledger requests are preferred over on-ledger requests unless you need to move assets -between chains or Layer 1 accounts. + --- ## Gas Gas expresses the "cost" of running a request in a chain. Each operation (arithmetics, write to disk, dispatch events, -etc.) has an associated gas cost. +etc.) has an associated gas cost. The amount of gas required for a transaction depends on the complexity of the +operation. For example, simple transfers may require less gas, while interacting with smart contracts for actions such +as token swaps can require more due to the higher computational work involved. For users to specify how much they're willing to pay for a request, they need to specify a `GasBudget` in the request. This gas budget is the "maximum operations that this request can execute" and will be charged as a fee based on the -chain's current [fee policy](/wasp-wasm/reference/core-contracts/governance#fee-policy). +chain's current [fee policy](../reference/core-contracts/governance.md#fee-policy). The funds to cover the gas used will be charged directly from the user's on-chain account. @@ -95,10 +86,16 @@ The funds to cover the gas used will be charged directly from the user's on-chai ## Allowance -Any funds sent to the chain via on-ledger requests are credited to the sender's account. +An allowance is a feature within smart contracts that controls how much one address can spend on behalf +of another address. Before a third party can withdraw tokens from your account, you must explicitly set an allowance for +that third party's address, specifying the maximum amount of tokens they are allowed to transfer. This mechanism is used +in various decentralized finance (DeFi) applications, where you might allow a smart contract to interact with your +tokens to participate in staking, lending, or trading activities. The original token owner can adjust or revoke the +allowance at any time, providing control over how your tokens are used by others. -For contracts to use funds owned by the _caller_, the _caller_ must specify an `Allowance` in the request. Contracts can -then claim any of the allowed funds using the sandbox `TransferAllowedFunds` function. +Any funds sent to the chain are credited to the sender's account. If you want a contract to use +those funds, you must specify an `Allowance` in the request. Contracts can then claim any of the allowed funds using +the sandbox `TransferAllowedFunds` function. The Allowance property looks like the following: diff --git a/docs/learn/smart-contracts/sandbox.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md similarity index 88% rename from docs/learn/smart-contracts/sandbox.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md index 1cbea1b25ad..d5ff9a7add4 100644 --- a/docs/learn/smart-contracts/sandbox.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md @@ -23,21 +23,21 @@ The access to the chain's state has to be curated, too. The chain owner and deve not necessarily the same entity. A single malicious contract could ruin the whole chain if not limited to its own space. Instead of working on the state as a whole, each smart contract can only modify a part of it. -The only way for smart contracts to access data is to use the _Sandbox_ interface, which is deterministic. It provides +The only way for smart contracts to access data is to use the sandbox interface, which is deterministic. It provides their internal state as a list of key/value pairs. ![Sandbox](/img/sandbox.png) Besides reading and writing to the contract state, the Sandbox interface allows smart contracts to access: -- The [ID](/wasp-wasm/explanations/how-accounts-work) of the contract. +- The [ID](how-accounts-work.md) of the contract. - The details of the current request or view call. - The current request allowance and a way to claim the allowance. - The balances owned by the contract. - The ID of whoever had deployed the contract. - The timestamp of the current block. - Cryptographic utilities like hashing, signature verification, and so on. -- The [events](/wasp-wasm/how-tos/schema-tool/events) dispatch. +- The [events](../schema/how-tos/events.mdx) dispatch. - Entropy that emulates randomness in an unpredictable yet deterministic way. - Logging. Used for debugging in a test environment. diff --git a/docs/learn/smart-contracts/smart-contract-anatomy.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md similarity index 75% rename from docs/learn/smart-contracts/smart-contract-anatomy.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md index e2e5abefe9f..aa5539626a9 100644 --- a/docs/learn/smart-contracts/smart-contract-anatomy.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md @@ -16,20 +16,17 @@ Smart contracts are programs that are immutably stored in the chain. Through _VM abstraction_, the ISC virtual machine is agnostic about the interpreter used to execute each smart contract. It can support different _VM types_ (i.e., interpreters) simultaneously on the same chain. -For example, it is possible to have [Wasm](/wasp-wasm/introduction/) and [EVM/Solidity](/wasp-evm/introduction/) smart +For example, it is possible to have [Wasm](../getting-started/languages-and-vms.md#wasm-vm-for-isc) and [EVM/Solidity](../getting-started/languages-and-vms.md#evmsolidity-based-smart-contracts) smart contracts coexisting on the same chain. -The logical structure of IOTA Smart Contracts is independent of the _VM_ type: - ![Smart Contract Structure](/img/tutorial/SC-structure.png) ## Identifying a Smart Contract -Each smart contract on the chain is identified by a _hname_ (pronounced "aitch-name"), which is a `uint32` value -calculated as a hash of the smart contract's instance name (a string). -For example, the hname of the [`root`](/wasp-wasm/reference/core-contracts/root/) core contract -is `0xcebf5908`. This -value uniquely identifies this contract in every chain. +The ISC [core contracts](core-contracts.md) and WASM contracts on the chain are identified by a _hname_ (pronounced +"aitch-name"), which is a `uint32` value calculated as a hash of the smart contract's instance name (a string). +For example, the hname of the [`root`](../reference/core-contracts/root.md) core contract +is `0xcebf5908`. This value uniquely identifies this contract in every chain. This does not apply to EVM contracts. ## State @@ -40,7 +37,7 @@ course). You can think of the smart contract state as a partition of the chain's data state, which can only be written by the smart contract program itself. -The smart contract also owns an _account_ on the chain, stored as part of the chain state. +The smart contract also owns an account on the chain, stored as part of the chain state. The smart contract account represents the balances of base tokens, native tokens, and NFTs controlled by the smart contract. @@ -49,7 +46,7 @@ Only the smart contract program can change its data state and spend from its account. Tokens can be sent to the smart contract account by any other agent on the ledger, be it a wallet with an address or another smart contract. -See [Accounts](/wasp-wasm/explanations/how-accounts-work) for more information on sending and receiving +See [Accounts](./how-accounts-work.md) for more information on sending and receiving tokens. ## Entry Points @@ -68,7 +65,7 @@ There are two types of entry points: ## Execution Results After a request to a Smart Contract is executed (a call to a full entry point), a _receipt_ will be added to -the [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog/) core contract. The receipt details the +the [`blocklog`](../reference/core-contracts/blocklog.md) core contract. The receipt details the execution results of said request: whether it was successful, the block it was included in, and other information. Any events dispatched by the smart contract in context of this execution will also be added to the receipt. diff --git a/docs/learn/smart-contracts/smart-contracts.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md similarity index 100% rename from docs/learn/smart-contracts/smart-contracts.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md diff --git a/docs/learn/smart-contracts/state_manager.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md similarity index 100% rename from docs/learn/smart-contracts/state_manager.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md diff --git a/docs/learn/smart-contracts/states.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md similarity index 100% rename from docs/learn/smart-contracts/states.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md diff --git a/docs/learn/smart-contracts/validators.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md similarity index 96% rename from docs/learn/smart-contracts/validators.md rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md index 3e880a48d42..97ed59a19c0 100644 --- a/docs/learn/smart-contracts/validators.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md @@ -46,4 +46,4 @@ It is common for validator nodes to be part of a private subnet and have only a outside world, protecting the committee from external attacks. The management of validator and access nodes is done through -the [`governance` core contract](/wasp-wasm/reference/core-contracts/governance/). +the [`governance` core contract](../reference/core-contracts/governance.md). diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md similarity index 94% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md rename to docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md index 30e5525eeb4..93168c9f134 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md @@ -39,7 +39,7 @@ The average block time on [ShimmerEVM](/build/networks-endpoints#shimmerevm) is ### The Magic Contract -A [dedicated Ethereum contract](../how-tos/magic-contract/magic.md) exists to manage Layer 1 tokens and ISC +A [dedicated Ethereum contract](../how-tos/core-contracts/introduction.md) exists to manage Layer 1 tokens and ISC functionalities, introducing commands like `isc.send(...)` for token transfers. ### Gas Fees diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md new file mode 100644 index 00000000000..64bacc1c8b4 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md @@ -0,0 +1,87 @@ +import EVMCompatibility from '../_admonitions/_EVM_compatibility.md' +import NetworkWarning from '../_admonitions/_network_warning.md' + +# Supported Virtual Machines & Languages + + + +The current release of IOTA Smart Contracts has support for [EVM/Solidity](#evmsolidity-based-smart-contracts) smart +contracts, as well as experimental [Wasm](#wasm-vm-for-isc) smart contracts, providing compatibility with +existing smart contracts and tooling from other EVM based chains like Ethereum. This allows us to offer the existing +ecosystem around EVM/Solidity a familiar alternative. + +## EVM Smart Contracts + +### What is EVM/Solidity? + +[EVM](https://ethereum.org/en/developers/docs/evm/) stands for "Ethereum Virtual Machine" and is currently the tried and +tested virtual machine running most smart contract networks. + +[Solidity](https://soliditylang.org/) is the programming language of choice for the EVM. It was created for this +specific purpose. + +The main benefit of using EVM/Solidity is its sheer amount of resources from years of development. The IOTA +Smart Contracts implementation is fully compatible with all of them. If you have experience developing on other EVM based chains, you will feel right at home. Any existing contracts you've written will need no +changes to function on IOTA Smart Contracts. + +### How IOTA Smart Contracts Work With EVM + +Every deployed ISC chain automatically includes a core contract +called [`evm`](../reference/core-contracts/evm.md). This core contract is responsible for running EVM code and +storing the EVM state. + +The Wasp node also provides a standard JSON-RPC service, which allows you to interact with the EVM layer using existing +tooling like [MetaMask](https://metamask.io/), [Remix](https://remix.ethereum.org/) or [Hardhat](https://hardhat.org/). +Deploying EVM contracts is as easy as pointing your tools to the JSON-RPC endpoint. + + + +## Wasm VM for ISC + +:::warning Experimental + +The Wasm _VM_ is in experimental state, showcasing ISC's "VM plugin" architecture. + +Experiment but avoid using it for production applications; opt for [EVM](quick-start.mdx). + +::: + +IOTA Smart Contracts (ISC) provide a sandboxed environment through an API, facilitating secure and deterministic +interactions with ISC functions. This API supports any Virtual Machine (VM) aiming to build a system for smart contract + code execution on ISC. + +![Wasp node ISC Host](/img/wasm_vm/IscHost.png) + +You can use a [WebAssembly (Wasm)](https://webassembly.org/) VM as a compilation target, facilitated by the open-source +[Wasmtime runtime](https://wasmtime.dev/). This setup encourages dynamic smart contract operations compiled to Wasm code, +promoting security and adaptability with different programming languages. + +![Wasm VM](/img/wasm_vm/WasmVM.png) + +The Wasm VM operates with self-contained `WasmLib` libraries linked to individual Wasm codes, optimizing the ISC sandbox +functionality and smart contract state storage access. + +### Supported Functionalities + +The ISC sandbox environment offers: + +- Smart contract metadata and state data access. +- Request data retrieval for function calls. +- Token management within the contract. +- Utility functions from the host. +- Smooth initiation of other smart contract functions. +- Logging facility. + +### Supported Languages + +The WasmLib started with [Rust](https://www.rust-lang.org/) support, expanding to include [Go](https://golang.org/) +and [TypeScript](https://www.typescriptlang.org/) with the help of respective Wasm code generators: + +| Language | Wasm code generator | +|------------|----------------------------------------------------| +| Go | [TinyGo](https://tinygo.org/) | +| Rust | [wasm-pack](https://rustwasm.github.io/wasm-pack/) | +| TypeScript | [AssemblyScript](https://www.assemblyscript.org/) | + +These generators maintain a common subset of their host language, aiming for a unified coding style to simplify the +initiation into smart contract creation, welcoming developers with a C-style language background to quickly adapt. \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.mdx b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.mdx new file mode 100644 index 00000000000..f1e2718d27d --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.mdx @@ -0,0 +1,54 @@ +--- +description: Networks and endpoints in the IOTA ecosystem. +tags: + - mainnet + - shimmer + - devnet + - public testnet + - reference + - Endpoints +--- +import { AddToMetaMaskButton, EVMNetworks } from '@theme/AddToMetaMaskButton'; +import { ChainId } from '@theme/ChainId'; + +# Networks & Chains + +## ShimmerEVM + +[ShimmerEVM](https://explorer.evm.shimmer.network/) is the L2 EVM running on top of the Shimmer network. + + + +| Base Token | Protocol | Chain ID | RPC URL | Explorer | +|---------------|-----------|-------------------------------------------------------|-------------------------------------------------------------------------------|--------------------------------------| +| Shimmer Token | ISC / EVM | | https://json-rpc.evm.shimmer.network or wss://ws.json-rpc.evm.shimmer.network | https://explorer.evm.shimmer.network | + +## ShimmerEVM Testnet + + + +[The ShimmerEVM Testnet](https://explorer.evm.testnet.shimmer.network/) runs as a layer 2 on top +of the [Public Testnet](/build/networks-endpoints/#public-testnet). This network uses ISC to facilitate +an Ethereum Virtual Machine and has an enshrined bridge to layer 1. + +:::info + +This network is subject to occasional resets (no data retention) which are usually announced with a one-week grace period. + +::: + +| Base Token | Protocol | Chain ID | RPC URL | Faucet | Explorer | +|---------------------------|-----------|---------------------------------------------------------------|----------------------------------------------|--------------------------------------------|----------------------------------------------| +| Testnet Tokens (no value) | ISC / EVM | | https://json-rpc.evm.testnet.shimmer.network | https://evm-faucet.testnet.shimmer.network | https://explorer.evm.testnet.shimmer.network | + +:::note + +The other values (network name and currency symbol) can be whatever value you like. + +::: + +## Core Contracts + +Both [ShimmerEVM](#shimmerEVM) and the [TestnetEVM](#testnetEVM) networks have 7 +[core contracts](../reference/core-contracts/overview.md) deployed, as well as the +[Magic Contract](../reference/magic-contract.md). diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/quickstart.mdx b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx similarity index 67% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/quickstart.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx index 77b0ec96e54..7b4a39d0bf4 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/quickstart.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx @@ -15,9 +15,9 @@ tags: import { AddToMetaMaskButton, EVMNetworks } from '@theme/AddToMetaMaskButton'; -# Public Testnet Quickstart Guide +# ShimmerEVM Testnet Quickstart Guide -This guide will help you quickly get started with the [Public Testnet](/build/networks-endpoints/#public-testnet), where you can deploy and interact with EVM-compatible smart contracts on the Shimmer Testnet. +This guide will help you quickly get started with the [ShimmerEVM Testnet](/build/networks-endpoints/#shimmerevm-testnet), where you can deploy and interact with EVM-compatible smart contracts. ## Prerequisites @@ -29,10 +29,20 @@ Click this button: -Please read [this MetaMask guide](./compatible-tools.md#metamask) for a detailed guidance. +:::tip + +Please read [the MetaMask section in the tools guide](tools.mdx#metamask) for a detailed guide. + +::: ## Get Testnet SMR Tokens +:::tip ShimmerEVM + +If you want to fund your ShimmerEVM account, please refer to our [How To Get Funds guide](../how-tos/send-funds-from-L1-to-L2.mdx). + +::: + 1. Go to the [ShimmerEVM Testnet Toolkit](https://evm-toolkit.evm.testnet.shimmer.network/). 2. Connect your MetaMask wallet by clicking "Connect Wallet" or paste an EVM address. 3. Select the account you want to receive testnet SMR tokens. @@ -48,7 +58,7 @@ Please read [this MetaMask guide](./compatible-tools.md#metamask) for a detailed ## Deploy and Interact with Smart Contracts -You can now use your testnet SMR tokens and simulated bridged tokens to deploy and interact with smart contracts on the [Public Testnet](/build/networks-endpoints/#public-testnet). Utilize popular development tools and frameworks, such as [Truffle](https://www.trufflesuite.com/), [Hardhat](https://hardhat.org/), or [Remix](https://remix.ethereum.org/), to build, test, and deploy your smart contracts. +You can now use your testnet SMR tokens and simulated bridged tokens to deploy and interact with smart contracts on the [Public Testnet](/build/networks-endpoints/#public-testnet). 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. ## Explore the Public Testnet @@ -56,11 +66,9 @@ Visit the [Public Testnet Block Explorer](https://explorer.evm.testnet.shimmer.n ## Additional Resources -- [Wasp GitHub repository](https://github.com/iotaledger/wasp) (smart contracts node implementation) - [GitHub issues page for Wasp](https://github.com/iotaledger/wasp/issues) -- [Wiki article on configuring wasp-cli](/wasp-cli/how-tos/wasp-cli/) - [EVM toolkit](https://evm-toolkit.evm.testnet.shimmer.network/) - [ERC20 simulated token faucet](https://evm-faucet.testnet.shimmer.network) - [Firefly Shimmer](https://firefly.iota.org) -With this quickstart guide, you should now be able to set up and start exploring the [Public Testnet](/build/networks-endpoints/#public-testnet). As you begin to deploy and interact with smart contracts, remember to provide feedback on any issues or improvements you discover to help make the ShimmerEVM even better. Happy developing! +With this quickstart guide, you should now be able to set up and start exploring the [ShimmerEVM Testnet](/build/networks-endpoints/#shimmerevm-testnet). As you begin to deploy and interact with smart contracts, remember to provide feedback on any issues or improvements you discover to help make the ShimmerEVM even better. Happy developing! diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx similarity index 52% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md rename to docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx index 6ba68fff2b3..dbae2121e4b 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx @@ -16,6 +16,11 @@ tags: - reference --- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton'; +import DeployAdmonition from '../_admonitions/_deploy_a_smart_contract.md'; +import { ChainId } from '@theme/ChainId'; # Compatible Tools @@ -24,53 +29,53 @@ directly with an IOTA Smart Contracts chain running EVM as long as you take a co ## Tooling Considerations -1. Please make sure you use the correct JSON-RPC endpoint URL in your tooling for your chain. You can find the JSON-RPC - endpoint URL in the Wasp dashboard (`/wasp/dashboard` when using `node-docker-setup`). -2. Please ensure you use the correct `Chain ID` configured while starting the JSON-RPC service. If you did not - explicitly define this while starting the service, the default Chain ID will be `1073`. -3. Fees are being handled on the IOTA Smart Contracts chain level, not the EVM level. Because of this, you can simply - use a gas price of 0 on the EVM level at this time. +1. Please make sure you use the correct JSON-RPC endpoint URL in your tooling for your chain. If you're running your own chain, you can find the JSON-RPC +endpoint URL in the Wasp dashboard (`[URL]/wasp/dashboard` when using `node-docker-setup`). +2. Please ensure you use the correct `Chain ID` configured while starting the JSON-RPC service. If you did not explicitly define this while starting the service, the default Chain ID will be +for ShimmerEVM or for the EVM Testnet. +3. Fees are handled on the IOTA Smart Contracts chain level, not the EVM level. The chain will reject any requests with a different gas price than specified by the chain. :::caution -Re-using an existing Chain ID is not recommended and can be a security risk. For serious usage, register a unique Chain -ID on [Chainlist](https://chainlist.org/) and use that instead of the default. **It is not possible to changed the EVM +Re-using an existing Chain ID is not recommended and can be a security risk. For production usage, register a unique Chain +ID on [Chainlist](https://chainlist.org/) and use that instead of the default. **It is not possible to change the EVM chain ID after deployment.** ::: -## Wasp-cli - -The Wasp CLI has some basic functionalities to manage an EVM chain. Given the [compatibility](./compatibility.md) with -existing tooling, only the basics are covered to get started with IOTA Smart Contracts and EVM. - -The JSON-RPC endpoint automatically starts with Wasp, and you can use the CLI tools to deploy a new chain that spawns up -a new EVM chain automatically and to deposit tokens to an EVM chain address. The following example allows you to deposit -your network's base token (IOTA on the IOTA network, SMR on the Shimmer network) to an EVM address. For example, the EVM -address can be a [Metamask](https://metamask.io/) generated address. - -```shell -wasp-cli chain deposit <0xEthAddress> base:1000000 -``` - -After this, you will have the balance on your Ethereum account available to pay for gas fees, for example, with -Metamask. - ## MetaMask -[MetaMask](https://metamask.io/) is a popular EVM compatible wallet which runs in a browser extension that allows you to -let your wallet interact with web applications utilizing an EVM chain (dApps). +[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 config to add the [Public Testnet](/build/networks-endpoints/#public-testnet): +For example this would be the config to add the [ShimmerEVM](/build/networks-endpoints/#shimmerevm) and +the [ShimmerEVM Testnet](/build/networks-endpoints/#shimmerevm-testnet): + + + + - Network Name: `Public Testnet` - New RPC URL: `https://json-rpc.evm.testnet.shimmer.network/` -- Chain ID: `1073` +- Chain ID: **** - Currency Symbol: `SMR` - Block Explorer URL: `https://explorer.evm.testnet.shimmer.network/` + + + + +- Network Name: `ShimmerEVM` +- New RPC URL: `https://json-rpc.evm.shimmer.network/` +- Chain ID: **** +- Currency Symbol: `SMR` +- Block Explorer URL: `https://explorer.evm.shimmer.network/` + + + + 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 [Public Testnet](/build/networks-endpoints/#public-testnet) to MetaMask. @@ -81,21 +86,19 @@ issue/sign transactions with any dApp running on that network. ### Remix If you also want to use the [Remix IDE](https://remix.ethereum.org/) to deploy any regular Solidity Smart Contract, you -should set the environment as **Injected Web3**, which should then connect with your MetaMask wallet. +should set the environment as **Injected Provider - Metamask**, which should then connect with your MetaMask wallet. Click on the _Deploy & Run transactions_ button in the menu on the left and select `Injected Web3` from the `Environment` dropdown. -[![Select Injected Web3 from the Environment dropdown](https://user-images.githubusercontent.com/7383572/146169413-fd0992e3-7c2d-4c66-bf84-8dd4f2f492a7.png)](https://user-images.githubusercontent.com/7383572/146169413-fd0992e3-7c2d-4c66-bf84-8dd4f2f492a7.png) - -Metamask will ask to connect to Remix, and once connected, it will set the `Environment` to `Injected Web3` with -the `Custom (1074) network`. +![Select Injected Provider from the Environment dropdown](/img/evm/remix-injected-provider-metamask.png) -[![Environment will be set to Injected Web3](https://user-images.githubusercontent.com/7383572/146169653-fd692eab-6e74-4b17-8833-bd87dafc0ce2.png)](https://user-images.githubusercontent.com/7383572/146169653-fd692eab-6e74-4b17-8833-bd87dafc0ce2.png) + -### Video Tutorial +Metamask will ask to connect to Remix, and once connected, it will set the `Environment` to `Injected Web3` with +the "Custom () network" or "Custom () network". - +![Environment will be set to Injected Web3](/img/evm/remix-injected-provider-set.png)] ## Hardhat @@ -103,15 +106,38 @@ the `Custom (1074) network`. Solidity smart contracts on an EVM chain. EVM chains running on IOTA Smart Contracts are compatible with Hardhat; simply make sure you add the correct network parameters to your `hardhat.config.js`, for example: + + + ```javascript networks: { 'shimmerevm-testnet': { - url: 'https://json-rpc.evm.testnet.shimmer.network', - chainId: 1073, - accounts: [priv_key], + url: 'https://json-rpc.evm.testnet.shimmer.network', + chainId: CHAIN_ID, + accounts: [YOUR PRIVATE KEY], + }, +}, +``` +***** Where `CHAIN_ID`= + + + + +```javascript +networks: { + 'shimmerevm': { + url: 'https://json-rpc.evm.shimmer.network', + chainId: CHAIN_ID, + accounts: [YOUR PRIVATE KEY], }, -} +}, ``` +***** Where `CHAIN_ID`= + + + + + :::caution @@ -120,10 +146,6 @@ often offered through block explorer APIs. ::: -### Video Tutorial - - - ## Ethers.js/Web3.js If you input the correct configuration parameters for the JSON-RPC endpoint to talk diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC20.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC20.md new file mode 100644 index 00000000000..9bbd6929beb --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC20.md @@ -0,0 +1,93 @@ +--- +description: Solidity smart contract ERC20. +image: /img/logo/WASP_logo_dark.png +tags: + - smart contracts + - EVM + - Solidity + - ERC20 + - eip-20 + - token creation + - mint tokens + - how to +--- + +import DeployAdmonition from '../_admonitions/_deploy_a_smart_contract.md'; +import PriorKnowledge from '../_admonitions/_EVM-required-prior-knowledge.md'; +import RemixIDE from '../_admonitions/_remix-IDE.md'; + +# Create ERC20 Custom Tokens + +## Required Prior Knowledge + + + +## About ERC20 + +ERC20 is a standard for fungible tokens and is defined in +the [EIP-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) by Ethereum. + +With the ERC20 standard, you can create your own tokens and transfer them to the EVM on IOTA Smart Contracts without +fees. + + + +## 1. Create the Smart Contract + +Create a new Solidity file, for example, `ERC20.sol` in the contracts folder of +your [Remix IDE](https://remix.ethereum.org/) and add this code snippet: + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.7; + +import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; + +contract ExampleERC20Token is ERC20 { + constructor() ERC20("ExampleERC20Token", "EET") { + _mint(msg.sender, 1000000 * 10 ** decimals()); + } +} +``` + +This imports all functions from the [OpenZeppelin ERC20](https://docs.openzeppelin.com/contracts/4.x/erc20) smart +contract and creates a new ERC20 token with your name and Symbol. + +:::tip OpenZeppelin + +OpenZeppelin provides many audited smart contracts and is a good point to start and learn. + +::: + +:::note Customize Your Token + +You can change the token name `ExampleERC20Token` and the token symbol `EET` for anything you want. + +::: + + + +## 2. Add Your Custom Tokens to MetaMask + +Once you have deployed your contract, you can add your new custom token to your Metamask account. + +1. Open Metamask, and click on the transaction that created the contract. From there, you can simply click + on `View on block explorer` to visit the transaction details. Alternatively, you can copy the transaction ID and + visit the [ShimmerEVM Explorer](https://explorer.evm.testnet.shimmer.network/) + or [ShimmerEVM Testnet Explorer](https://explorer.evm.testnet.shimmer.network/) and use the search bar to find transaction. + +!['View on block explorer](/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png) + +2. Copy the contract address from the transaction details, and import your custom ERC20 tokens into MetaMask. + +![Copy contract address](/img/evm/how-tos/ERC20/metamask-import-tokens.png) + +## 3. Have some Fun + +Now you should see your token in MetaMask. You can send them to your friends without any fees or gas costs. + +![Copy contract address](/img/evm/how-tos/ERC20/metamask-erc20-balance.png) + +You also can ask in the [Discord Chat Server](https://discord.iota.org) to send them around and discover what the +community is building on IOTA Smart Contracts. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC721.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC721.md new file mode 100644 index 00000000000..0b66f129e59 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/ERC721.md @@ -0,0 +1,127 @@ +--- +description: Create and deploy a Solidity smart contract to mint NFTs using the ERC721 standard. +image: /img/evm/ozw-721.png +tags: + - smart contracts + - EVM + - Solidity + - ERC721 + - eip-721 + - token creation + - mint tokens + - how to +--- +import DeployAdmonition from '../_admonitions/_deploy_a_smart_contract.md'; +import PriorKnowledge from '../_admonitions/_EVM-required-prior-knowledge.md'; +import RemixIDE from '../_admonitions/_remix-IDE.md'; + +# Create ERC721 NFTs + +:::info EVM-only NFT + +Please keep in mind that this is an EVM-only NFT. It's not tied to L1 native assets. Also, these are different from L1 +NFTs. + +::: + + + +## About ERC721 + +Non-fungible tokens or NFTs are a type of token that can represent any unique object, including a real-world asset on a +decentralized network. NFTs are commonly represented by the ([ERC721 standard](https://eips.ethereum.org/EIPS/eip-721)). +You can use the +openzepplin +lib [`@openzeppelin/contracts/token/ERC721/ERC721.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +to streamline your development experience. + +You can also use the ([OpenZepplin Contracts Wizard](https://wizard.openzeppelin.com/#erc721)) to generate and customize +your smart contracts. + + + +## Create the Smart Contract + +The following is an example NFT Smart Contract called "ShimmerEVMSampleNFT". + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.20; + +import "@openzeppelin/contracts@5.0.1/token/ERC721/ERC721.sol"; +import "@openzeppelin/contracts@5.0.1/access/Ownable.sol"; + +contract ShimmerEVMSampleNFT is ERC721, Ownable { + uint256 private _nextTokenId; + + constructor(address initialOwner) + ERC721("ShimmerEVMSampleNFT", "SSNFT") + Ownable(initialOwner) + {} + + function _baseURI() internal pure override returns (string memory) { + return "https://example.com/nft/"; + } + + function safeMint(address to) public onlyOwner { + uint256 tokenId = _nextTokenId++; + _safeMint(to, tokenId); + } +} +``` + +As you can see above, the contract uses standard methods for the most part. You should pay attention to the following: + +- `pragma solidity ^0.8.20;`: This line means the contract uses solidity compiler version `0.8.20` or above. +- `contract ShimmerEVMSampleNFT is ERC721, ERC721URIStorage, Ownable`: This line defines the contract's name, and what + other contracts it implements. +- `ERC721("ShimmerEVMSampleNFT", "SNFT") {}`: This line defines the token name and symbol. You can name it + whatever you want. We recommend using the same name for the token and the contract. +- `return "https://example.com/nft/";`: You should define the base URI of your NFTs. That means the URL you provide here + will be used for all your tokens. Since this contract uses auto-incremental token IDs, your token URI will look + something like `https://example.com/nft/0`, `https://example.com/nft/1`, `https://example.com/nft/2`, and so on. +- `function safeMint(address to, string memory uri) public onlyOwner {`: The `safeMint` function will + require that you manually input a token's `to` address and a `uri` every time you want to mint. This should work for + regular use cases. + +### Customize on OpenZeppelin + +You can customize your contract depending on how you want it to behave. You should consider the following topics +and questions: + +1. **Ownership** — Who owns it? How is it stored? +2. **Creation** — Method or Type of Creation. +3. **Transfer & Allowance** — How will tokens be transferred? How will they be available to other addresses and + accounts? +4. **Burn** — Do you want to destroy it? If yes, how? + +You can click on `Copy to Clipboard` and paste it into the IDE of your choice, download it, or click on `Open in Remix` +directly. + + +:::note Set the Initial Owner + +Before you can deploy this contract, you will need to set the `Initial Owner` address; this can be your own ShimmerEVM address. + +!["Set the initial owner" img.png](/img/evm/how-tos/ERC721/set-initial-owner.png) + +::: + + + +### Mint Your Custom NFTs + +So far, you have [created](#create-the-smart-contract) and deployed the contract. But, you probably want to mint some NFTs. +To do, you should: + +1. Open the contract (listed under `Deployed Contracts`). +2. Insert your target ShimmerEVM in beside the `safeMint` button and then click the button. + + ![Safe mint](/img/evm/how-tos/ERC721/safe-mint.png) +3. Confirm the transaction on Metamask. + + ![Confirm in metamask](/img/evm/how-tos/ERC721/confirm-in-metamask.png) + +If you visit your address in the [ShimmerEVM Explorer](https://explorer.evm.testnet.shimmer.network/) or [ShimmerEVM Testnet Explorer](https://explorer.evm.testnet.shimmer.network/) +you should see your NFTs listed under `Tokens`. + diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/allow.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/allow.md new file mode 100644 index 00000000000..edf7027f439 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/allow.md @@ -0,0 +1,64 @@ +--- +description: How to allow native assets and base token +image: /img/logo/WASP_logo_dark.png +tags: + - allow + - allowance + - EVM + - magic + - solidity +--- + +# Allow + +The allowance concept is well known from the EVM contracts like ERC20. +In ISC, we have a similar concept for our native assets. You might want to use this, for example, to [send native assets to L1](../send-assets-to-l1.mdx) (which includes sending tokens to other L1 chain accounts). + +## Example Code + +### 1. Create the `allow` Function + +Create a function which allows an address or contract to access a specific ID of your account: + +```solidity +function allow(address _address, bytes32 _allowanceNFTID) public { +``` + +### 2. Create the `ISCAssets` object + +Create an `ISCAssets` object to pass as allowance: + +```solidity +NFTID[] memory nftIDs = new NFTID[](1); +nftIDs[0] = NFTID.wrap(_allowanceNFTID); +ISCAssets memory assets; +assets.nfts = nftIDs; +``` + +### 3. Use the Assets as Allowance + +With that asset, you can call `allow` to allow address to take our NFT: + +```solidity +ISC.sandbox.allow(_address, assets); +``` + +## Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract Allowance { + function allow(address _address, bytes32 _allowanceNFTID) public { + NFTID[] memory nftIDs = new NFTID[](1); + nftIDs[0] = NFTID.wrap(_allowanceNFTID); + ISCAssets memory assets; + assets.nfts = nftIDs; + ISC.sandbox.allow(_address, assets); + } +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/get-allowance.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/get-allowance.md new file mode 100644 index 00000000000..353df44011c --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/get-allowance.md @@ -0,0 +1,79 @@ +--- +description: How to get the allowance of native assets and base token +image: /img/logo/WASP_logo_dark.png +tags: + - allowance + - EVM + - magic + - solidity +--- + +# Get Allowance + +## Example Code + +There are multiple ways to check for an allowance. + +### `getAllowanceFrom()` + +`getAllowanceFrom()` fetches the funds currently allowed by the given address to the caller: + +```soliditiy +function getAllowanceFrom(address _address) public { + ISCAssets assets = ISC.sandbox.getAllowanceFrom(_address); + emit AllowanceFrom(assets) +} +``` + +### `getAllowanceTo()` + +`getAllowanceTo()` fetches the funds currently allowed by the caller to the given address: + +```soliditiy +function getAllowanceTo(address _target) public { + ISCAssets assets = ISC.sandbox.getAllowanceTo(_target); + emit AllowanceTo(assets) +} +``` + +### `getAllowance()` + +`getAllowance()` gets the funds currently allowed between the given addresses: + +```soliditiy +function getAllowance(address _from, address _to) public { + ISCAssets assets = ISC.sandbox.getAllowance(_from, _to); + emit Allowance(assets) +} +``` + +## Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract allowance { + event AllowanceFrom(ISCAssets assets) + event AllowanceTo(ISCAssets assets) + event Allowance(ISCAssets assets) + + function getAllowanceFrom(address _address) public { + ISCAssets assets = ISC.sandbox.getAllowanceFrom(_address); + emit AllowanceFrom(assets) + } + + function getAllowanceTo(address _target) public { + ISCAssets assets = ISC.sandbox.getAllowanceTo(_target); + emit AllowanceTo(assets) + } + + function getAllowance(address _from, address _to) public { + ISCAssets assets = ISC.sandbox.getAllowance(_from, _to); + emit Allowance(assets) + } +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/take-allowance.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/take-allowance.md new file mode 100644 index 00000000000..b41689fb898 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/allowance/take-allowance.md @@ -0,0 +1,56 @@ +--- +description: How to take the allowance of native assets and base token +image: /img/logo/WASP_logo_dark.png +tags: + - allowance + - EVM + - magic + - solidity +--- + +# Take allowed Funds + +After having [allowed](./allow.md) native assets, you can take the ones you need. + +## Example Code + +The following example will take the NFT which was allowed in the [allow how-to guide](./allow.md). + +### Create the `ISCAssets` + +First, you need to recreate the `ISCAssets` with the NFTID. + +```solidity +NFTID[] memory nftIDs = new NFTID[](1); +nftIDs[0] = NFTID.wrap(_allowanceNFTID); +ISCAssets memory assets; +assets.nfts = nftIDs; +``` + +### Call `takeAllowedFunds()` + +After that, you can call `takeAllowedFunds()` to take the allowance of the specified address/contract + +```solidity +ISC.sandbox.takeAllowedFunds(_address, NFTID); +``` + +## Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract allowance { + function takeAllowedFunds(address _address, bytes32 NFTID) { + NFTID[] memory nftIDs = new NFTID[](1); + nftIDs[0] = NFTID.wrap(_allowanceNFTID); + ISCAssets memory assets; + assets.nfts = nftIDs; + ISC.sandbox.takeAllowedFunds(_address, NFTID); + } +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/get-balance.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/get-balance.md new file mode 100644 index 00000000000..aa25f559ac0 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/get-balance.md @@ -0,0 +1,74 @@ +--- +description: How to get the balance of L1 assets on L2 +image: /img/logo/WASP_logo_dark.png +tags: + - native assets + - balance + - EVM + - how-to +--- + +# Get Balance + +Once you have your L1 assets on L2, you might want to check their balance. This guide explains how to do so by calling the three functions `getL2BalanceBaseTokens`, `getL2BalanceNativeTokens`and `getL2NFTAmount` for the corresponding token types. + + +## Example Code + +1. Get the [AgentID](../../../explanations/how-accounts-work.md) from the sender by calling `ISC.sandbox.getSenderAccount()`. + +```solidity +ISCAgentID memory agentID = ISC.sandbox.getSenderAccount(); +``` + +2. To get the base token balance, you can call `getL2BalanceBaseTokens` using the `agentID`. + +```solidity +uint64 baseBalance = ISC.accounts.getL2BalanceBaseTokens(agentID); +``` + +3. To get the native token balance of a specific `NativeTokenID`, use `ISC.accounts.getL2BalanceNativeTokens` with the `id` and `agentID`. + +```solidity +NativeTokenID memory id = NativeTokenID({ data: nativeTokenID}); +uint256 nativeTokens = ISC.accounts.getL2BalanceNativeTokens(id, agentID); +``` + +4. To get the number of NFTs, use `ISC.accounts.getL2NFTAmount` with the `agentID`. + +```solidity +uint256 nfts = ISC.accounts.getL2NFTAmount(agentID); +``` + +### Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract GetBalance { + event GotAgentID(bytes agentID); + event GotBaseBalance(uint64 baseBalance); + event GotNativeTokenBalance(uint256 nativeTokenBalance); + event GotNFTIDs(uint256 nftBalance); + + function getBalance(bytes memory nativeTokenID) public { + ISCAgentID memory agentID = ISC.sandbox.getSenderAccount(); + emit GotAgentID(agentID.data); + + uint64 baseBalance = ISC.accounts.getL2BalanceBaseTokens(agentID); + emit GotBaseBalance(baseBalance); + + NativeTokenID memory id = NativeTokenID({ data: nativeTokenID}); + uint256 nativeTokens = ISC.accounts.getL2BalanceNativeTokens(id, agentID); + emit GotNativeTokenBalance(nativeTokens); + + uint256 nfts = ISC.accounts.getL2NFTAmount(agentID); + emit GotNativeTokenBalance(nfts); + } +} +``` + diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/send-assets-to-l1.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/send-assets-to-l1.mdx new file mode 100644 index 00000000000..4fb8baa24da --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/basics/send-assets-to-l1.mdx @@ -0,0 +1,70 @@ +--- +description: The ISC Magic Contract allows EVM contracts to access ISC functionality. +image: /img/logo/WASP_logo_dark.png +tags: + - configure + - using + - EVM + - magic + - Ethereum + - Solidity +--- + +import AboutAccounts from '../../../_admonitions/_about-accounts.md'; + +# Send Assets and Tokens to L1 + + + +:::info + +ShimmerEVM has 18 decimal places, while Shimmer has 6. This means that any decimals beyond the 6th will be ignored by Shimmer, even though you can see them on ShimmerEVM. Please keep this in mind while sending your tokens to L1. + +::: + +This guide will show you how to use the ISC sandbox interface to send assets from L2 to L1. This includes base tokens, native tokens, and NFTs. Before you can send these assets, you need to know how you get them on L2 and how you allow a contract to use them. + +Note that assets on L1 require a storage deposit; therefore, the number of base tokens sent to L1 should cover at least the storage deposit required to hold the assets on L1. + +## Explanation + +First, you will find out what assets this contract is allowed to take from the caller by calling the `ISC.sandbox.getAllowanceFrom()` function. + +```solidity +ISCAssets memory allowance = ISC.sandbox.getAllowanceFrom(msg.sender); +``` + +Then you take the allowance, which will transfer the assets from the caller to the contract. + +```solidity +ISC.sandbox.takeAllowedFunds(msg.sender, allowance); +``` + +Finally, you can send the assets to the specified L1 address. This will create an output to hold said assets. You can use additional options to add the [timelock](/learn/protocols/stardust/core-concepts/output-unlock-conditions/#timelock) and [expiration](/learn/protocols/stardust/core-concepts/output-unlock-conditions/#expiration) unlock conditions to the output. + +```solidity +ISCSendMetadata memory metadata; +ISCSendOptions memory options; +ISC.sandbox.send(to, allowance, false, metadata, options); +``` + +## Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract L1Assets { + function withdraw(L1Address memory to) public { + ISCAssets memory allowance = ISC.sandbox.getAllowanceFrom(msg.sender); + ISC.sandbox.takeAllowedFunds(msg.sender, allowance); + + ISCSendMetadata memory metadata; + ISCSendOptions memory options; + ISC.sandbox.send(to, allowance, false, metadata, options); + } +} +``` \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/get-randomness-on-l2.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/get-randomness-on-l2.md new file mode 100644 index 00000000000..3bf4b3b35e1 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/get-randomness-on-l2.md @@ -0,0 +1,127 @@ +--- +description: You can use the ISC Magic Contract in EVM contracts to access ISC functionality, such as randomness. +image: /img/logo/WASP_logo_dark.png +tags: + - magic contract + - randomness + - EVM + - Ethereum + - Solidity + - ISC +--- + +# Get Randomness on L2 + +ISC introduces a feature not found on many other smart contract protocols: randomness. + +In the ISC protocol, for each state update, each validator proposes a batch of smart contract requests that they would like to process next. They commit to their proposals with a signature, after which a common subset of requests is found, and a combined signature is produced. + +This combined signature is unpredictable, and not only serves as protection against MEV by pseudo-randomly ordering requests, but also provides a source of verifiable entropy for randomness on L2. + +This guide will show you how you can use this entropy to generate random values in your contracts. + +:::info A note about entropy + +While entropy is random for each smart contract request, entropy is constant within a request. This means multiple calls to get entropy within the same request will return the same value. + +::: + +## Explanation + +When you want to generate multiple random values within a single request, you need to take into account that entropy is constant within a request. In this contract we use an increasing nonce in addition to the entropy, to make sure we are generating unique values: + +```solidity +uint256 private _nonce; + +function getNonce() internal returns (bytes32) { + return bytes32(_nonce++); +} +``` + +### Generating Integers + +To then generate a random integer, you can take the entropy and a unique nonce and hash them together: + +```solidity +bytes32 entropy = ISC.sandbox.getEntropy(); +bytes32 nonce = getNonce(); +bytes32 digest = keccak256(bytes.concat(entropy, nonce)); +``` + +And then cast the digest to an integer: + +```solidity +uint256 value = uint256(digest); +``` + +### Generating bytes + +Similarly to generating a random integer, you can generate any sequence of random bytes by taking the entropy and a unique nonce and hash them together: + +```solidity +bytes32 entropy = ISC.sandbox.getEntropy(); +bytes32 nonce = getNonce(); +bytes32 digest = keccak256(bytes.concat(entropy, nonce)); +``` + +And then repeatidly hash the digest and copy it in a sequence of bytes until you reach the required length. + +```solidity +bytes memory value = new bytes(length); +for (uint i = 0; i < length; i += 32) { + digest = keccak256(bytes.concat(digest)); + for (uint j = 0; j < 32 && i + j < length; j++) { + value[i + j] = digest[j]; + } +} +``` + +## Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract Random { + event Int(uint256); + event Bytes(bytes); + + uint256 private _nonce; + + function getNonce() internal returns (bytes32) { + return bytes32(_nonce++); + } + + function getInt() public returns (uint256) { + bytes32 entropy = ISC.sandbox.getEntropy(); + bytes32 nonce = getNonce(); + bytes32 digest = keccak256(bytes.concat(entropy, nonce)); + + uint256 value = uint256(digest); + + emit Int(value); + return value; + } + + function getBytes(uint length) public returns (bytes memory) { + bytes32 entropy = ISC.sandbox.getEntropy(); + bytes32 nonce = getNonce(); + bytes32 digest = keccak256(bytes.concat(entropy, nonce)); + + bytes memory value = new bytes(length); + for (uint i = 0; i < length; i += 32) { + digest = keccak256(bytes.concat(digest)); + for (uint j = 0; j < 32 && i + j < length; j++) { + value[i + j] = digest[j]; + } + } + + emit Bytes(value); + return value; + } +} + +``` \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/introduction.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/introduction.md new file mode 100644 index 00000000000..27cacfd0ced --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/introduction.md @@ -0,0 +1,67 @@ +--- +description: The ISC Core Contracts allows VMs to access ISC functionality. +image: /img/logo/WASP_logo_dark.png +tags: + - configure + - using + - EVM + - magic + - Ethereum + - Solidity + - metamask + - JSON + - RPC +--- + +# The Core Contracts + +The [core contracs](../../explanations/core-contracts.md) are contracts deployed on every chain and are vital to interact with L1 and the chain itself. They can be called in Solidity through the [ISC Magic Contract](../../reference/magic-contract.md). + +## The ISC Magic Contract + +The Magic contract is an EVM contract deployed by default on every ISC chain, in the EVM genesis block, at +address `0x1074000000000000000000000000000000000000`. +The implementation of the Magic contract is baked-in in +the [`evm`](../../reference/core-contracts/evm.md) [core contract](../../reference/core-contracts/overview.md); +i.e. it is not a pure-Solidity contract. + +The Magic contract has several methods, which are categorized into specialized +interfaces: `ISCSandbox`, `ISCAccounts`, `ISCUtil` and so on. +You can access these interfaces from any Solidity contract by importing +the [ISC library](https://www.npmjs.com/package/@iota/iscmagic): + +```bash npm2yarn +npm install @iota/iscmagic +``` + +You can import it into your contracts like this: + +```solidity +import "@iota/iscmagic/ISC.sol"; +``` + +The Magic contract also provides proxy ERC20 contracts to manipulate ISC base +tokens and native tokens on L2. + +## Call a Function + +In the example below, `ISC.sandbox.getEntropy()` calls the +[`getEntropy`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L20) +method of the `ISCSandbox` interface, which, in turn, +calls [ISC Sandbox's](../../explanations/sandbox.md) `GetEntropy`. + +```solidity +pragma solidity >=0.8.5; + +import "@iota/iscmagic/ISC.sol"; + +contract MyEVMContract { + event EntropyEvent(bytes32 entropy); + + // this will emit a "random" value taken from the ISC entropy value + function emitEntropy() public { + bytes32 e = ISC.sandbox.getEntropy(); + emit EntropyEvent(e); + } +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/create-foundry.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/create-foundry.md new file mode 100644 index 00000000000..f9636742db8 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/create-foundry.md @@ -0,0 +1,67 @@ +--- +description: How to create a L1 foundry +image: /img/logo/WASP_logo_dark.png +tags: + - foundry + - EVM + - how-to +--- +import ExampleCodeIntro from '../../../_partials/how-tos/token/_example_code_intro.md'; + +# Create a Foundry +## About Foundries + +The Stardust update allows you to create your own native tokens. Native tokens are minted by a [Foundry](/tips/tips/TIP-0018/#foundry-output). +The Foundry allows you to specify your native token's maximum supply **once** and change the circulating supply. +This guide will show you how to create an L1 foundry using a L2 smart contract. + +## Example Code + + + +### 2. Define the Token Scheme + +Define the `NativeTokenScheme` by specifying its `mintedTokens`, `meltedTokens` and `maximumSupply`: + +```solidity +NativeTokenScheme memory nativeTokenScheme = NativeTokenScheme({ + mintedTokens: _mintedTokens, + meltedTokens: _meltedTokens, + maximumSupply: _maximumSupply +}); +``` + +### 3. Create the Foundry + +Create the foundry by calling the `ISC.accounts.foundryCreateNew(nativeTokenScheme, allowance)` function: + +```solidity +uint32 foundrySN = ISC.accounts.foundryCreateNew(nativeTokenScheme, allowance); +``` + +### Full Example Code + +```solidity +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@iota/iscmagic/ISC.sol"; + +contract CreateFoundry { + event CreatedFoundry(uint32 foundrySN); + + function createFoundry(uint _mintedTokens, uint _meltedTokens, uint _maximumSupply, uint64 _storageDeposit) public payable { + require(msg.value == _storageDeposit*(10**12), "Please send exact funds to pay for storage deposit"); + ISCAssets memory allowance; + allowance.baseTokens = _storageDeposit; + NativeTokenScheme memory nativeTokenScheme = NativeTokenScheme({ + mintedTokens: _mintedTokens, + meltedTokens: _meltedTokens, + maximumSupply: _maximumSupply + }); + uint32 foundrySN = ISC.accounts.foundryCreateNew(nativeTokenScheme, allowance); + emit CreatedFoundry(foundrySN); + } +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/erc20-native-token.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/erc20-native-token.md new file mode 100644 index 00000000000..eef11254681 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/erc20-native-token.md @@ -0,0 +1,45 @@ +--- +description: How to use the custom functionality of ERC20NativeToken +image: /img/logo/WASP_logo_dark.png +tags: + - native token + - erc20 + - EVM + - how-to +--- + +# Custom ERC20 Functions + +Once you [registered your native token as ERC20](./erc20-native-token.md) you can use it like any other ERC20 token, with functions like +`transfer`, `balanceOf`, etc. But, as the ERC20 token maps the native token on L2, there are some additional ISC features +you can take advantage of. + +## Example Code + +### Get Your `nativeTokenID` + +You can use the `erc20NativeTokensAddress` function and the Foundry serial number to get the contract address: + +```solidity +ERC20NativeTokens token = ERC20NativeTokens( + ISC.sandbox.erc20NativeTokensAddress(_foundrySN) +); +``` + +* `nativeTokenID` will give you the native token ID of the ERC20 token: + +```solidity +NativeTokenID memory id =token.nativeTokenID(); +``` + +### Full Example Code + +```solidity +function nativeTokenID(uint32 _foundrySN) public view returns (bytes memory) { + ERC20NativeTokens token = ERC20NativeTokens( + ISC.sandbox.erc20NativeTokensAddress(_foundrySN) + ); + NativeTokenID memory id =token.nativeTokenID(); + return id.data; +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/introduction.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/introduction.md new file mode 100644 index 00000000000..83fb4021e47 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/introduction.md @@ -0,0 +1,18 @@ +--- +description: How to handle native tokens on L2 and use them as ERC20 +image: /img/logo/WASP_logo_dark.png +tags: + - native token + - EVM + - how-to +--- +import DocCardList from '@theme/DocCardList'; + +# Native Token and ERC20NativeToken + +The IOTA L1 has functionality to create L1 tokens, also called native tokens. To use these native tokens on L2, you have +a ERC20 contract called `ERC20NativeToken`. The following guides will show you how to [create a foundry](create-foundry.md) +that can [mint your own L1 token from L2](mint-token.md), and [register](register-token.md) it as `ERC20NativeToken`, +so it can be used like any other ERC20 token with some additional features. + + \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/mint-token.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/mint-token.md new file mode 100644 index 00000000000..9e8e8d9b3c4 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/mint-token.md @@ -0,0 +1,42 @@ +--- +description: How to mint native token on an L1 foundry. +image: /img/logo/WASP_logo_dark.png +tags: + - foundry + - EVM + - how-to + - native tokens + - mint +--- +import ExampleCodeIntro from '../../../_partials/how-tos/token/_example_code_intro.md'; + +# Mint Native Tokens + +To mint tokens from a [foundry](/tips/tips/TIP-0018/#foundry-output), you first need to be aware that only the foundry owner can mint token, +so you should execute the `ISC.accounts.mintNativeTokens` function in the same contract that [created the foundry](./create-foundry.md). + +## Example Code + + + +### 2. Mint the Native Token + +Mint the native token specifying the foundry serial number, the amount to mint and the allowance. + +```solidity +ISC.accounts.mintNativeTokens(_foundrySN, _amount, allowance); +``` + +## Full Example Code + +```solidity +event MintedNativeTokens(uint32 foundrySN, uint amount); + +function mintNativeTokens(uint32 _foundrySN, uint _amount, uint64 _storageDeposit) public payable { + require(msg.value == _storageDeposit*(10**12), "Please send exact funds to pay for storage deposit"); + ISCAssets memory allowance; + allowance.baseTokens = _storageDeposit; + ISC.accounts.mintNativeTokens(_foundrySN, _amount, allowance); + emit MintedNativeTokens(_foundrySN, _amount); +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/register-token.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/register-token.md new file mode 100644 index 00000000000..6a910327068 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/register-token.md @@ -0,0 +1,53 @@ +--- +description: How to register a native token as ERC20 +image: /img/logo/WASP_logo_dark.png +tags: + - ERC20 + - EVM + - how-to +--- +import ExampleCodeIntro from '../../../_partials/how-tos/token/_example_code_intro.md'; + +# Register Tokens + +To properly use your native tokens, you should register them as ERC20 using the `registerERC20NativeToken` function from the ISC magic contract. + +## Example Code + + + + +### 2. Register the Native Tokens + +Register the native tokens specifying: +* the foundry serial number +* a name +* a symbol +* it's decimals +* the allowance. +```solidity +ISC.sandbox.registerERC20NativeToken(_foundrySN, _name, _symbol, _decimals, allowance); +``` + +### 3. Get the Contract's Address + +Get the ERC20 contract address with `erc20NativeTokensAddress`: + +```solidity +address erc20address = ISC.sandbox.erc20NativeTokensAddress(_foundrySN); +``` + +### Full Example Code + +```solidity +event ERC20Address(address erc20address); + +function registerERC20NativeToken(uint32 _foundrySN, string calldata _name, string calldata _symbol, uint8 _decimals, uint64 _storageDeposit) public payable { +require(msg.value == _storageDeposit*(10**12), "Please send exact funds to pay for storage deposit"); +ISCAssets memory allowance; +allowance.baseTokens = _storageDeposit; +ISC.sandbox.registerERC20NativeToken(_foundrySN, _name, _symbol, _decimals, allowance); +address erc20address = ISC.sandbox.erc20NativeTokensAddress(_foundrySN); +emit ERC20Address(erc20address); +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/create-a-basic-contract.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/create-a-basic-contract.md new file mode 100644 index 00000000000..d060b3732ff --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/create-a-basic-contract.md @@ -0,0 +1,53 @@ +--- +description: Basic smart contract example. +image: /img/logo/WASP_logo_dark.png +tags: + - smart contracts + - how to + - basic contract +--- +import DeployAdmonition from '../_admonitions/_deploy_a_smart_contract.md'; + +# Basic Smart Contract Example + +[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart contracts on IOTA Smart Contracts are compatible with +Solidity smart contracts on any other network. Most smart contracts will work directly without any modification. To get +a rough indication of what a simple Solidity smart contract looks like, see the example below: + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.6; + +contract Counter { + uint private count; + + constructor() { + count = 0; + } + + function increment() public { + count += 1; + } + + function decrement() public { + require(count > 0, "Count is already zero"); + count -= 1; + } + + function getCount() public view returns (uint) { + return count; + } +} + +``` + +This contract simply updates a `count` variable. It has +three [entry points](../explanations/smart-contract-anatomy.md#entry-points): + +* `increment` and `decrement`: Two full entry points that can alter + the [state](../explanations/smart-contract-anatomy.md#state), i.e. the `count variable`. +* `getCount`: A view only entry point, which simply renders the current `count` state. + +For more information, please visit the [official Solidity documentation](https://docs.soliditylang.org/). + + \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/deploy-a-smart-contract.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/deploy-a-smart-contract.mdx new file mode 100644 index 00000000000..c70942bd287 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/deploy-a-smart-contract.mdx @@ -0,0 +1,216 @@ +--- +tags: +- Smart Contract Deployment +- Shimmer EVM +- Remix IDE +- Hardhat +- Shimmer EVM Testnet +image: /img/logo/WASP_logo_dark.png +description: 'Learn how to deploy smart contracts to Shimmer EVM and Shimmer EVM Testnet using popular tools like Remix and Hardhat.' +--- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton'; + +# Deploy a Smart Contract + +You can deploy your smart contracts to [Shimmer EVM](https://explorer.evm.shimmer.network/) and +the [Shimmer EVM Testnet](https://explorer.evm.testnet.shimmer.network/) using popular tools like [Remix](#remix) +and [Hardhat](#hardhat). + +:::tip Get a Basic Contract + +This guide will deploy the `Counter` contract you can find in +the [How to Create a Basic Solidity Contract Guide](create-a-basic-contract.md). + +::: + + + + +Deploying a Solidity smart contract using Remix is a straightforward process that doesn't require any installation or +setup of development environments on your machine. Remix is a powerful, browser-based IDE that allows you to write, +compile, and deploy smart contracts. + +### 1. Connect to Metamask + +Before you get started, make sure you have connected Metamask to your network of choice. + +:::tip Networks & Endpoints + +You can check the connection details in the [Networks & Endpoints section](/build/networks-endpoints/). + +::: + + + + + + + + + + +### 2. Access Remix IDE + +Open your web browser and navigate to [Remix IDE](https://remix.ethereum.org/). + +### 3. Create Your Smart Contract + +1. In the `File Explorer` tab on the left, click the `Create New File` icon. +2. Name your file `Counter.sol`. +3. Copy the Solidity code for the [basic counter smart contract](create-a-basic-contract.md) and paste it into + the `Counter.sol` file you just created in Remix. + +### 4. Compile Your Smart Contract + +1. Navigate to the `Solidity Compiler` tab on the left sidebar. +2. Select the appropriate compiler version that matches the version specified in your contract (`^0.8.6` or similar). + You might need to enable "Auto compile" or click the "Compile" button manually. +3. If there are errors, Remix will display them, and you'll need to correct them before proceeding. + +### 5. Deploy Your Smart Contract + +1. Switch to the "Deploy & Run Transactions" tab on the left sidebar. +2. In the "Environment" dropdown, select and select `Injected Web3` from the `Environment` dropdown. + + ![Select Injected Provider from the Environment dropdown](/img/evm/remix-injected-provider-metamask.png) + +3. After selecting the environment, make sure the contract Counter is selected in the `Contract` dropdown. +4. Click the `Deploy` button. If you're using an Ethereum network, confirm the transaction in your Web3 wallet. + +### 6. Interact with Your Deployed Contract + +Once deployed, the contract instance will appear under the `Deployed Contracts` section. +Here, you can interact with your contract by calling its functions. For the Counter contract, you'll see buttons to call +its `increment`, `decrement`, and `getCount` functions directly from Remix. + + + + +The first thing you'll need to deploy a smart contract using [Hardhat](https://hardhat.org/) is to set up a Hardhat +project. Here's a step-by-step guide: + +### Requirements + +* [Node.js](https://nodejs.org/). +* [npm](https://www.npmjs.com/) or [yarn](https://yarnpkg.com/). + +### 1. Set Up Hardhat + +1. Open a new terminal window. +2. Create a new directory for your project, and navigate into it. For example: + ```bash + mkdir deploy-a-basic-contract && + cd deploy-a-basic-contract + ``` +3. Create a new node project by running: + ```bash + npm init -y + ``` +4. Install Hardhat by running: + ```bash + npm install --save-dev hardhat + ``` +5. Create a Hardhat Project by running the following command: + ```bash + npx hardhat + ``` + + Select "Create a basic sample project" when prompted and answer the setup questions (you can just press enter to + accept defaults). + +### 2. Add Your Contract + +1. Inside the `contracts` folder, create a new file called `Counter.sol` and paste the content of + the [Counter Basic Contract](create-a-basic-contract.md). + +### 3. Create a Deployment Script + +1. Navigate to the `scripts` folder. +2. Create a new file called `deploy.js` with the following code: + + ```javascript + async function main() { + const Counter = await ethers.getContractFactory("Counter"); + const counter = await Counter.deploy(); + + await counter.deployed(); + + console.log("Counter deployed to:", counter.address); + } + + main() + .then(() => process.exit(0)) + .catch((error) => { + console.error(error); + process.exit(1); + }); + ``` + +### 4. Compile and Deploy Your Contract + +1. Add your preferred network parameters to the `hardhat.config.js`, for example: + + + + +```javascript +networks: { + 'shimmerevm-testnet': { + url: 'https://json-rpc.evm.testnet.shimmer.network', + chainId:1073, + accounts: ['YOUR PRIVATE KEY'], + }, +} +``` + + + + +```javascript +networks: { + 'shimmerevm': { + url: 'https://json-rpc.evm.shimmer.network', + chainId: 148, + accounts: [YOUR PRIVATE KEY], + }, +} +``` + + + + +:::caution + +Currently, there is no validation service available for EVM/Solidity smart contracts on IOTA Smart Contracts, which is +often offered through block explorer APIs. + +::: + +2. Compile your contract by running the following command: + + ```bash + npx hardhat compile + ``` + +3. If you have no compilation errors, you can deploy your contract by running the following command: + + ```bash + npx hardhat run scripts/deploy.js --network shimmerevm-testnet + ``` + + **Expected output**: + + ```bash + Counter deployed to: 0x123456789ABCDEFGHIJK123456789ABCDEFGHIJK + ``` + ***** `0x123456789ABCDEFGHIJK123456789ABCDEFGHIJK` is the contract unlock address. + +4. You can verify your contract by visiting + the [ShimmerEVM Testnet Explorer](https://explorer.evm.testnet.shimmer.network/), + and searching for the address from the previous step. If you access the `Contract` tab, you should be able to see + your code and interact with your contract. + + + \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/introduction.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/introduction.md new file mode 100644 index 00000000000..cb6c63bbc87 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/introduction.md @@ -0,0 +1,29 @@ +--- +description: 'Explore the how-to guides for IOTA Smart Contracts, offering step-by-step instructions on various topics and functionalities.' +image: /img/logo/WASP_logo_dark.png +tags: + + - EVM + - Solidity + - smart contracts + - Ethereum + - explanation + - how-to guides + - instructions + - code examples +--- + +# About How-to Guides + +This section has several how-to guides that provide step-by-step instructions on various topics and functionalities. You +can use these guides to understand and implement specific tasks or features within your application. Whether you are a +beginner or an experienced developer, the how-to guides offer clear and concise explanations, making integrating IOTA smart contracts +functionality into your projects easier. + +To make the most of the how-to guides in this section, identify the specific topic or functionality you want to explore. +Whether you want to [get funds on L2](send-funds-from-L1-to-L2.mdx), [add ISC specific functionality](introduction.md), +or [send funds to L1](./core-contracts/basics/send-assets-to-l1.mdx), you can find dedicated guides that walk you through the process. + +With the how-to guides in the IOTA SDK, you can overcome implementation hurdles and gain a deeper understanding +of the IOTA ecosystem. These guides empower you with the knowledge and practical examples to seamlessly integrate IOTA +functionality into your projects. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-funds-from-L1-to-L2.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-funds-from-L1-to-L2.mdx new file mode 100644 index 00000000000..242c7b5b573 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-funds-from-L1-to-L2.mdx @@ -0,0 +1,107 @@ +--- +description: How to send funds from L1 to L2. +image: /img/logo/WASP_logo_dark.png +tags: + - configure + - using + - EVM + - Ethereum + - Solidity + - deploy + - hardhat + - metamask + - JSON + - RPC + - how to +--- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton'; + +# Send Funds From L1 to L2 + +There are multiple types of assets available on both IOTA L1 and L2, here we discuss a few of them, and how to get them +onto L2. + +:::tip Testnet + +If you want to fund your ShimmerEVM Testnet account using the [ShimmerEVM Toolkit](https://evm-toolkit.evm.testnet.shimmer.network/), please refer to our [Public Testnet Quickstart Guide](../getting-started/quick-start.mdx) + +::: + +## Fund an Ethereum Account on a IOTA Smart Contracts Chain + +To send EVM transactions, you need to have an Ethereum address that owns tokens on the ISC chain (L2). These tokens will +be used to cover gas fees. + + + + +You can use your [Firefly Wallet](https://firefly.iota.org/) to easily send L1 SMR to your L2 ShimmerEVM account. + +#### Requirements + +* [Shimmer Tokens](/get-started/introduction/shimmer/shimmer-token/) +* [Firefly Wallet](https://firefly.iota.org/) +* [Metamask](https://metamask.io/) + +1. The first thing you will need to do is add ShimmerEVM to Metamask by hitting the following button. + + + + + + + + + + +2. Once you have added ShimmerEVM to Metamask, you can get your address: + + ![Copy your Metamask address](/img/evm/how-tos/get-funds/copy-your-address.png) + +3. Next, you will need to open your [Firefly Wallet](https://firefly.iota.org/) and click on `Send Assets`. + + ![Click send assets](/img/evm/how-tos/get-funds/firefly/select-send-assets.png) + +4. Select ShimmerEVM in the network dropdown. + + ![Select the ShimmerEVM network](/img/evm/how-tos/get-funds/firefly/select-shimmer-evm.png) + +5. Enter the amount of `SMR` tokens you want to transfer, and the Metamask address from step 2, and click on `Next` + + ![Enter the amount of SMR tokens and metamask address](/img/evm/how-tos/get-funds/firefly/enter-your-desired-amount-and-metamask-address.png) + +6. Review the transaction details and click on `Send`. + + ![Hit Send](/img/evm/how-tos/get-funds/firefly/hit-send.png) + + + + + +You can use your [Bloom Wallet](https://bloomwallet.io/) to easily send L1 SMR to your L2 ShimmerEVM account. + +1. First, you will need to open your [Bloom Wallet](https://firefly.iota.org/) and click on `Send`. + + ![Click send](/img/evm/how-tos/get-funds/bloom/select-send.png) + +2. Select an account with `SMR` tokens. + + ![Select an account with SMR tokens](/img/evm/how-tos/get-funds/bloom/select-the-smr-token.png) + +3. Bloom will automatically create a ShimmerEVM address for you, so you can send funds to that address from the Shimmer +EVM dropdown. Alternatively, you can input any other ShimmerEVM address. + + ![Select you ShimmerEVM Address](/img/evm/how-tos/get-funds/bloom/enter-the-recipient-address.png) + +4. Enter the amount of `SMR` tokens you want to transfer. + + ![Enter the amount of SMR tokens you want to transfer](/img/evm/how-tos/get-funds/bloom/enter-the-amount.png) + +5. Review the transaction details and click on `Confirm`. + + ![Hit Send](/img/evm/how-tos/get-funds/bloom/review-and-confirm-the-transaction.png) + + + \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/test-smart-contracts.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/test-smart-contracts.md new file mode 100644 index 00000000000..7b032b6d9bf --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/test-smart-contracts.md @@ -0,0 +1,108 @@ +--- +keywords: +- Smart Contract Testing +- Automated Testing +- Unit Tests +- Integration Tests +- Testing Frameworks +- ShimmerEVM Testnet +- Solidity Testing +description: Learn how to test smart contracts before deploying them on public networks to avoid vulnerabilities and ensure functionality aligns with requirements using unit, and integration testing, alongside frameworks and testing with the IOTA Sandbox and the ShimmerEVM Testnet. +--- + +# Testing Smart Contracts + +Once you have deployed a smart contract on a public network, altering it to fix an error can be hard, and it goes +against the principle of immutability, which can create trust issues with users. And, even if it were simple, you could +only fix an error or vulnerability after it is discovered. So, your contract and its users may be at risk if a third +party detects a vulnerability before you do. + +The best way to avoid these overheads and vulnerabilities is to test your contracts thoroughly before deploying them. +You can use [unit](#unit-tests) and [integration](#integration-tests) tests, as well +as [manual testing](#manual-testing), to ensure your contracts behave as expected. + +## Automated Testing + +You can use various tools to automatically test your smart contract’s code and for any error in execution. The great +benefit of automated testing is that it requires minimal human intervention, and it can be built right into your +deployment pipelines. + +Automated testing also allows you to run repetitive and time-consuming tasks without testing each case manually and +avoid human errors, which can happen when you manually input tons of data. + +However, you must be careful, as automated testing can lead to false positives or miss certain edge cases. + +### Unit Tests + +In a nutshell, unit testing ensures that each function and component works correctly by evaluating each independently. +You can use unit tests to ensure that functions return the expected values and modify your contract's state properly. +They should be simple, quick to run and provide helpful feedback if anything goes wrong. This makes them an ideal tool +to ensure your contracts run smoothly after any modifications. + +#### Unit Testing Guidelines + +##### Understand the logic behind your contract’s workflow + +Before you can write any tests, you should understand how your contract is supposed to behave. You should know its +functionalities and how users will access them. Your tests should cover different functions a user may call when +interacting with the contract and check that functions are disabled when they should be. + +#### Evaluate your contract’s assumptions + +It is important to verify that every internal decision the contract takes matches your assumptions on how it should +behave. This forces you to think about edge cases rather than only thinking of the “happy path” you want your users to +take. You can write negative tests to assert how your contract would respond to invalid or malicious inputs. + +##### Measure Code Coverage + +Code coverage is a key metric when it comes to understanding the effectiveness of your tests. It measures the number of +lines, statements, and branches that are actually executed during your unit tests. If you don’t have thorough code +coverage, your test may give what is commonly known as a “false negative”, where your contract passed all your tests, +but your tests didn’t evaluate all the possible vulnerabilities. + +#### Unit Testing Frameworks + +The quality of your unit test will depend on the quality of the tools you use to write and execute them. You should use +a testing framework that is regularly maintained and updated, provides features that are relevant to your contract, and +is popular amongst other developers. + +:::tip Solo + +If you want to test ISC-specific functionalities, like the [magic contract](./core-contracts/introduction.md), you should use +the [Solo Framework](../solo/getting-started.md). + +::: + +* [Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) +* [Remix](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests) +* [Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts) +* [Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html) +* [Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html) +* [Foundry](https://book.getfoundry.sh/forge/writing-tests) + +### Integration Tests + +Integration tests are beneficial when your contract adopts a modular architecture or interfaces with other contracts +during its execution. While [unit tests](#unit-tests) focus on testing functions in isolation, trying each cog in the +machine individually, so to speak, integration tests evaluate how these functions work together as a whole, testing the +machine as a whole. You should use integration tests to detect any issues arising from interactions between different +functions in your contracts' cross-contract calls and ensure that inherited or extended functions are working as +expected. + +#### Tools + +You can use the [ShimmerEVM Testnet](/build/networks-endpoints/#testnet-evm) to conduct integration tests without +incurring any fees or the [IOTA Sandbox](/iota-sandbox/getting-started/) if you want to run the tests locally. + +## Manual Testing + +Once you have a complete batch of [automated tests](#automated-testing), manually testing your contract to ensure it +behaves as expected in the real world is still good practice. However, to avoid incurring fees or deploying a faulty +contract, you can manually test your contract using a sandboxed local network and the Shimmer EVM Testnet. + +Testing using the [IOTA Sandbox](/iota-sandbox/getting-started/) serves well for the first stage of automated and manual +integration tests, as you have complete control over the entire local network. Once you are confident about how your +contract behaves locally, you can deploy and test on the [ShimmerEVM Testnet](/build/networks-endpoints/#testnet-evm), +which replicates the ShimmerEVM network but also enables cost and risk-free interactions. + + diff --git a/docs/build/isc/v1.0.0-rc.6/docs/introduction.md b/docs/build/isc/v1.0.0-rc.6/docs/introduction.md new file mode 100644 index 00000000000..c644eb4da1a --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/introduction.md @@ -0,0 +1,77 @@ +--- +description: 'The current release of IOTA Smart Contracts also has experimental support for EVM/Solidity, providing +limited compatibility with existing smart contracts and tooling from other EVM based chains like Ethereum.' +image: /img/logo/WASP_logo_dark.png +tags: + + - EVM + - Solidity + - smart contracts + - Ethereum + - explanation + +--- +import NetworkWarning from './_admonitions/_network_warning.md' +import OnOffLedgerRequest from './_partials/_on_off_ledger_request.md'; + +# Introduction + + + +Smart contracts are deterministic applications that run on a distributed network with multiple +[validators](explanations/validators.md) that execute and validate the same code. +Their deterministic and distributed nature makes them predictable, stable and trustworthy. + +## Scalable Smart Contracts + +Due to the distributed nature of smart contracts, i.e. they run on a network of validators instead of a single computer, +the execution of smart contract is resource intensive as it has to deal with the overhead of the communication between validators in the network. +This can lead to relatively high [fees](#gas) for smart contract execution, as well as scalability issues when running on +a single blockchain. However, the IOTA Smart Contract Protocol allows **many blockchains that execute smart contracts to +run in parallel** and communicate with one another, therefore solving the scalability problem. Enabling interoperability and horizontal scaling of dApps. + +At the same time, ISC provides advanced means of communication between its chains and preserves the ability to create +complex, composed smart contracts. + +## ISC Architecture + +IOTA Smart Contracts (ISC) function as a Layer 2 extension to the IOTA Multi-Asset Ledger. +As validator nodes execute the smart contracts, they tally these state changes and write them into the chain. +In turn ISC chains, each with their state and smart contracts, update their state collectively and interact with Layer 1 +and other L2 chains, offering a sophisticated multi-chain architecture. + +![IOTA Smart Contacts multichain architecture](/img/multichain.png 'Click to see the full-size image.') + +_IOTA Smart Contacts multichain architecture._ + +[Explore the comprehensive overview of IOTA Smart Contracts in the ISC white paper](https://files.iota.org/papers/ISC_WP_Nov_10_2021.pdf). + +## Supported VMs + +The IOTA Smart Contracts currently +supports [EVM/Solidity](getting-started/languages-and-vms.md#evmsolidity-based-smart-contracts) +smart contracts, as well as an **experimental** [Wasm VM](getting-started/languages-and-vms.md#wasm-vm-for-isc). + +## Sandbox Interface + +ISC Smart contracts can access the [Sandbox interface](explanations/sandbox.md). +This interface provides access to the chain state, native assets, allows interaction with other contracts/chains, as +well as various utilities like cryptographic functions and event dispatching. + +![Sandbox](/img/sandbox.png) + +## Calling a Smart Contract + +### Entry Points and Requests + +Smart contracts are activated through entry points, similar to function calls. Entry points can be view-only or allow state +modifications. They are triggered by requests, signed by senders. Smart contracts on the same chain can +synchronously invoke each other, ensuring deterministic results. However, requests between chains are asynchronous and +may involve delays. + +### Gas + +Running a request consumes 'gas'. Gas units are a measurement of "how expensive" a computation is to execute. You can specify a `GasBudget` +for each request, with costs charged to your on-chain account. + + diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/blob.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/blob.md diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md similarity index 98% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md index 7b189532fed..c78d57d17a6 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md @@ -21,7 +21,7 @@ status, receipts, block, and event details. To avoid having a monotonically increasing state size, only the latest `N` blocks (and their events and receipts) are stored. This parameter can be configured -when [deploying the chain](/wasp-cli/how-tos/setting-up-a-chain/). +when [deploying the chain](/wasp/how-tos/setting-up-a-chain). --- diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/errors.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/errors.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/evm.md similarity index 97% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/evm.md index c3e1fdd8329..99be19b75bc 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/evm.md @@ -20,11 +20,11 @@ tags: The `evm` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The `evm` core contract provides the necessary infrastructure to accept Ethereum transactions and execute EVM code. -It also includes the implementation of the [ISC Magic contract](../../how-tos/magic-contract/magic.md). +It also includes the implementation of the [ISC Magic contract](../../how-tos/core-contracts/introduction.md). :::note -For more information about how ISC supports EVM contracts, refer to the [EVM](../../introduction.md) section. +For more information about how ISC supports EVM contracts, refer to the [EVM](../../getting-started/languages-and-vms.md#evmsolidity-based-smart-contracts) section. ::: diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/governance.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/governance.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/overview.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/overview.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/root.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/root.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/root.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/root.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/json-rpc-spec.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/json-rpc-spec.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/json-rpc-spec.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/json-rpc-spec.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/magic-contract.md b/docs/build/isc/v1.0.0-rc.6/docs/reference/magic-contract.md similarity index 67% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/magic-contract.md rename to docs/build/isc/v1.0.0-rc.6/docs/reference/magic-contract.md index e8c81cdb7d0..6b4e3feb30f 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/magic-contract.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/reference/magic-contract.md @@ -30,5 +30,31 @@ registered by calling [`registerERC721NFTCollection`](./core-contracts/evm.md#registerERC721NFTCollection). There are some usage examples in -the [ISCTest.sol](https://github.com/iotaledger/wasp/blob/develop/packages/evm/evmtest/ISCTest.sol) contract (used +the [ISC How-To Guides](../how-tos/introduction.md) and the [ISCTest.sol](https://github.com/iotaledger/wasp/blob/develop/packages/evm/evmtest/ISCTest.sol) contract (used internally in unit tests). + +## Call a Native Contract + +You can call native contracts using [`ISC.sandbox.call`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L56): + +```solidity +pragma solidity >=0.8.5; + +import "@iota/iscmagic/ISC.sol"; + +contract MyEVMContract { + event EntropyEvent(bytes32 entropy); + + function callInccounter() public { + ISCDict memory params = ISCDict(new ISCDictItem[](1)); + bytes memory int64Encoded42 = hex"2A00000000000000"; + params.items[0] = ISCDictItem("counter", int64Encoded42); + ISCAssets memory allowance; + ISC.sandbox.call(ISC.util.hn("inccounter"), ISC.util.hn("incCounter"), params, allowance); + } +} +``` + +`ISC.util.hn` is used to get the `hname` of the `inccounter` contract and the +`incCounter` entry point. You can also call view entry points using +[ISC.sandbox.callView](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L59). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/data-types/types.mdx b/docs/build/isc/v1.0.0-rc.6/docs/reference/wasm-lib-data-types.mdx similarity index 87% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/data-types/types.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/reference/wasm-lib-data-types.mdx index 7057119f172..28789a1772d 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/data-types/types.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/reference/wasm-lib-data-types.mdx @@ -23,7 +23,7 @@ as human-readable text string. These are mostly simple built-in scalar data types as provided by most programming languages. Each integer data type has a clearly defined storage size. The -[Schema Tool](../../how-tos/schema-tool/usage.mdx)) will attempt to use the closest matching built-in data type when +[Schema Tool](../schema/how-tos/usage.mdx) will attempt to use the closest matching built-in data type when generating code for a specific language. - `BigInt` - An arbitrary-length unsigned integer. @@ -55,7 +55,7 @@ WasmLib provides its own implementations for each of the ISC value data types. ## Full Matrix of WasmLib Types -WasmLib implements a full set of [value proxies](../../explanations/proxies.mdx#value-proxies) for each +WasmLib implements a full set of [value proxies](../schema/proxies.mdx#value-proxies) for each predefined value type that provide access to data on the ISC host. But there is one aspect of this data that we have not considered yet. Some data provided by the host is mutable, whereas other data may be immutable. To facilitate this distinction, each value proxy type @@ -70,7 +70,7 @@ tries to bypass them, the ISC sandbox will also check these constraints at runti host. | ISC type | WasmLib type | Mutable proxy | Immutable proxy | -| --------- | ----------------- | ---------------------- | ------------------------ | +|-----------|-------------------|------------------------|--------------------------| | BigInt | Sc**BigInt** | ScMutable**BigInt** | ScImmutable**BigInt** | | Bool | _boolean_ | ScMutable**Bool** | ScImmutable**Bool** | | Bytes | _byte array_ | ScMutable**Bytes** | ScImmutable**Bytes** | @@ -97,8 +97,8 @@ The consistent naming makes it easy to remember the type names. Bool, Bytes, Str the integer types are the odd ones out. They are implemented in WasmLib by the closest equivalents in the chosen WasmLib implementation programming language. -The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the proper (im)mutable proxies +The [Schema Tool](../schema/how-tos/usage.mdx) will automatically generate the proper immutable proxies from the schema definition. For example, View functions will only be able to access the -[State](../../how-tos/schema-tool/state.mdx) map through immutable proxies. The same goes for the -[Params](../../how-tos/schema-tool/params.mdx) map that was passed into a Func or View, and for the -[Results](../../how-tos/schema-tool/results.mdx) map that was returned from a call to a Func or View. +[State](../schema/how-tos/state.mdx) map through immutable proxies. The same goes for the +[Params](../schema/how-tos/params.mdx) map that was passed into a Func or View, and for the +[Results](../schema/how-tos/results.mdx) map that was returned from a call to a Func or View. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/access.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/access.mdx similarity index 92% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/access.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/access.mdx index 26c94edaba2..a9c799a32a2 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/access.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/access.mdx @@ -25,7 +25,7 @@ You can set access identifiers with **one** of the following options: function. You should provide a mechanism to initialize and manage this variable. -The [Schema Tool](../schema-tool/usage.mdx) handles the auto-generation of the code for access verification. +The [Schema Tool](usage.mdx) handles the auto-generation of the code for access verification. ## Usage Examples diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/call.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/call.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/call.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/call.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/events.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/events.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcdesc.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx similarity index 97% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcdesc.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx index e2f5f116bfb..bb4f18ee046 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcdesc.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx @@ -16,7 +16,7 @@ import TabItem from '@theme/TabItem'; # Add Function Descriptors -You can use the [Schema Tool](../schema-tool/usage.mdx) to access, and initiate smart contract functions seamlessly using +You can use the [Schema Tool](usage.mdx) to access, and initiate smart contract functions seamlessly using function descriptors. These descriptors allow you to access optional [Params](params.mdx) and [Results](results.mdx) maps through strict compile-time checked interfaces. @@ -26,7 +26,7 @@ compile-time checked interfaces. Function descriptors are structures that: - Offer access to the optional [Params](params.mdx) and [Results](results.mdx) maps. -- Allow synchronous or asynchronous initiation of functions through [`call`](call.mdx) or [`post`](post.mdx) requests. +- Allow synchronous or asynchronous initiation of functions through [`call()`](call.mdx) or [`post()`](post.mdx) requests. ## The Schema Tool in Action @@ -391,7 +391,7 @@ export class ScFuncs { ## `dividend` Example - Generated Code -In the `dividend` example in `contract.xx`, specific structs for [Funcs and Views](../../explanations/proxies.mdx) are created. +In the `dividend` example in `contract.xx`, specific structs for [Funcs and Views](../../schema/proxies.mdx) are created. Here's how they operate: ### Access diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcs.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx similarity index 98% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcs.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx index 843d900bd7d..0c48c6c85ed 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/funcs.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx @@ -67,7 +67,7 @@ views: As you can see each of the `funcs` and `views` sections defines their functions in the -same way. The only resulting difference is in the way the [Schema Tool](../schema-tool/usage.mdx) +same way. The only resulting difference is in the way the [Schema Tool](usage.mdx) generates code for them: - The code generated for Funcs will be able to inspect and modify the smart contract state. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/init.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/init.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/init.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/init.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/params.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx similarity index 93% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/params.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx index 441e3789342..60691771f75 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/params.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx @@ -20,7 +20,7 @@ Optional parameters are denoted with a question mark `?` following the field typ ## Schema Tool Automation -The [Schema Tool](../schema-tool/usage.mdx) streamlines the creation of functions by: +The [Schema Tool](usage.mdx) streamlines the creation of functions by: - Generating an immutable structure holding parameter proxies from the [Params](params.mdx) map. - Checking the presence and data type of non-optional parameters before the function call. @@ -98,5 +98,5 @@ export class ImmutableMemberParams extends wasmtypes.ScProxy { -The [Schema Tool](../schema-tool/usage.mdx) will also generate a mutable version of the structure, +The [Schema Tool](usage.mdx) will also generate a mutable version of the structure, suitable for providing the parameters when calling this smart contract function from any [Call Context](../../explanations/context.mdx). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/post.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/post.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/post.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/post.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/results.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/results.mdx similarity index 92% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/results.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/results.mdx index 09ca73dbb26..d80691a6888 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/results.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/results.mdx @@ -19,7 +19,7 @@ This setup aligns with the field definitions seen in the [Params](params.mdx) su ## Schema Tool Features -The [Schema Tool](../schema-tool/usage.mdx) assists in this setup by: +The [Schema Tool](usage.mdx) assists in this setup by: - Creating a mutable structure that includes proxies for each result variable found in the [Results](results.mdx) map. - Enabling users to assign values to result variables via this generated structure during the function call. @@ -80,6 +80,6 @@ export class MutableGetFactorResults extends wasmtypes.ScProxy { -Note that the [Schema Tool](../schema-tool/usage.mdx) will also generate an immutable version of the +Note that the [Schema Tool](usage.mdx) will also generate an immutable version of the structure, suitable for accessing the results after by the caller of this smart contract function. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/spec.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/spec.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/spec.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/spec.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/state.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx similarity index 98% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/state.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx index 38d590b66cf..70252bfb4a1 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/state.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx @@ -55,7 +55,7 @@ state: Starting with straightforward state variables, `totalFactor`, and `owner` are characterized as Uint64 and AgentID, respectively. -These represent predefined [WasmLib value types](../../reference/data-types/types.mdx). +These represent predefined [WasmLib value types](../../reference/wasm-lib-data-types.mdx). ### Arrays and Maps @@ -173,7 +173,7 @@ export class MutableDividendState extends wasmtypes.ScProxy { Examining the `state.xx`code, generated by the [Schema Tool](usage.mdx), you can find the `MutableDividendState` struct. -This interface allows type-safe access to each state variable through mutable [proxies](../../explanations/proxies.mdx), +This interface allows type-safe access to each state variable through mutable [proxies](../../schema/proxies.mdx), establishing a one-to-one relationship with the `state` section in the schema definition file. ### Proxy Interfaces diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/structs.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/structs.mdx similarity index 97% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/structs.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/structs.mdx index 30c5ad5b50f..810c2f398b2 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/structs.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/structs.mdx @@ -16,14 +16,14 @@ import TabItem from '@theme/TabItem'; # Structured Data Types -The [Schema Tool](../../how-tos/schema-tool/usage.mdx) allows you to define your structured data types that are +The [Schema Tool](usage.mdx) allows you to define your structured data types that are composed of the predefined WasmLib value data types. The tool will generate a struct with named fields according to the definition in the schema definition file and also will generate code to serialize and deserialize the structure to a byte array so that it can be saved as a single unit of data bytes, for example in state storage. You can use structs directly as a type in state storage definitions, and the -[Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the proxy code to access and +[Schema Tool](usage.mdx) will automatically generate the proxy code to access and (de)serialize it properly. For example, let's say you are creating a `betting` smart contract. Then, you would want to @@ -49,7 +49,7 @@ state: -The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will generate the following code in `structs.xx` for the Bet +The [Schema Tool](usage.mdx) will generate the following code in `structs.xx` for the Bet struct: diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/thunks.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/thunks.mdx similarity index 97% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/thunks.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/thunks.mdx index 670366329b7..76531cd30a1 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/thunks.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/thunks.mdx @@ -23,7 +23,7 @@ facilitating type-safety and easy mapping of function names to their actual impl A thunk is a wrapper function employed to inject code before and/or after a function call. It helps in adapting functions to meet changing demands. -Through the [Schema Tool](../schema-tool/usage.mdx), +Through the [Schema Tool](usage.mdx), thunks are generated to establish correct calls to smart contract functions and to ensure type-safety. They share a common function signature, fostering a straightforward creation of a function table for generic calls. @@ -161,7 +161,7 @@ smart contract provides. When the host needs to call a function of the smart contract it will call the `on_call()` callback function with the corresponding function id, and then the `on_call()` function will dispatch the call via the `ScExportMap` mapping table that was generated by the -[Schema Tool](../schema-tool/usage.mdx) to the proper associated thunk function. +[Schema Tool](usage.mdx) to the proper associated thunk function. ## Generated Main Entry Point @@ -346,7 +346,7 @@ First, the thunk logs the contract and function name to show that the call has s Then it sets up a strongly typed function-specific context structure. First, we add the function-specific immutable [Params](params.mdx) interface structure, which is only present when the function can have parameters. Then we add the contract-specific -[State](../schema-tool/state.mdx) interface structure. In this case, it is mutable because setOwner is a +[State](state.mdx) interface structure. In this case, it is mutable because setOwner is a [Func](funcs.mdx). For [Views](views.mdx), this would be an immutable state interface. Finally, we would add the function-specific mutable [Results](results.mdx) interface structure, which is only present when the function returns results. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/transfers.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/transfers.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/typedefs.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx similarity index 96% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/typedefs.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx index 217fcdb250b..2d55e859696 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/typedefs.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx @@ -19,18 +19,18 @@ import TabItem from '@theme/TabItem'; :::note WasmLib Types -You can find the complete list of [WasmLib Data Types](../../reference/data-types/types.mdx) in the reference section. +You can find the complete list of [WasmLib Data Types](../../reference/wasm-lib-data-types.mdx) in the reference section. ::: -The WasmLib allows of [container types](../../explanations/proxies.mdx#container-proxies), but it +The WasmLib allows of [container types](../../schema/proxies.mdx#container-proxies), but it is not possible to specify these types directly because the type name syntax only allows you to specify a single container type. There is a simple solution to this problem. You can add a `typedefs` section to the schema definition file, where you can define a single type name for a container type. That way you can easily create containers that contain such container types. The -[Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the in-between proxy types necessary +[Schema Tool](usage.mdx) will automatically generate the in-between proxy types necessary to make this work. To keep it at the `betting` smart contract from [the previous section](structs.mdx), @@ -52,7 +52,7 @@ state: -The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will generate the following code in `typedefs.xx` for the +The [Schema Tool](usage.mdx) will generate the following code in `typedefs.xx` for the `BettingRound` type: diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/usage.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/usage.mdx similarity index 96% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/usage.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/usage.mdx index ccde1e45d93..4114e328ccc 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/usage.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/usage.mdx @@ -289,18 +289,6 @@ eliminating the need to run the schema tool manually after each modification. The tool regenerates code only if it detects alterations since its last operation. To override this and force regeneration, include the `-force` flag in the command line parameter. -## Video Tutorial - - - ### Creating Smart Contracts using AssemblyScript diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md deleted file mode 100644 index e445e0db13a..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md +++ /dev/null @@ -1,365 +0,0 @@ ---- -description: 'The `accounts` contract keeps the ledger of on-chain accounts.' -image: /img/logo/WASP_logo_dark.png -tags: - - core contracts - - accounts - - deposit - - withdraw - - assets - - balance - - reference ---- - -# The `accounts` Contract - -The `accounts` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts -chain. - -This contract keeps a consistent ledger of on-chain accounts in its state, -i.e. [the L2 ledger](../../explanations/how-accounts-work.md). - ---- - -## Entry Points - -The `accounts` contract provides functions to deposit and withdraw tokens, information about the assets deposited on the -chain, and the functionality to create and use foundries. - -### `deposit()` - -A no-op that has the side effect of crediting any transferred tokens to the sender's account. - -:::note Gas Fees - -As with every call, the gas fee is debited from the L2 account right after executing the request. - -::: - -### `withdraw()` - -Moves tokens from the caller's on-chain account to the caller's L1 address. The number of -tokens to be withdrawn must be specified via the allowance of the request. - -:::note Contract Account - -Because contracts does not have a corresponding L1 address it does not make sense to -have them call this function. It will fail with an error. - -::: - -:::note Storage Deposit - -A call to withdraw means that a L1 output will be created. Because of this, the withdrawn -amount must be able to cover the L1 storage deposit. Otherwise, it will fail. - -::: - -### `transferAllowanceTo(a AgentID)` - -Transfers the specified allowance from the sender's L2 account to the given L2 account on -the chain. - -:::note - -When a transfer is made into an EVM account, an EVM tx will be created on the EVM side from the zero address (0x0000...) to the target account. -Information about what is being transferred will be encoded in the transaction's data using the following format: - -``` - + -``` - -The encoding used for this data can be found on [TIP-51](https://github.com/jorgemmsilva/tips/blob/b46d7bc36a0f7d4c2a1ad32ba25ec2abb4835cb3/tips/TIP-0051/tip-0051.md) - -::: - -#### Parameters - -- `a` (`AgentID`): The target L2 account. - -### `transferAccountToChain(g GasReserve)` - -Transfers the specified allowance from the sender SC's L2 account on -the target chain to the sender SC's L2 account on the origin chain. - -#### Parameters - -- `g` (`uint64`): Optional gas amount to reserve in the allowance for - the internal call to transferAllowanceTo(). Default 100 (MinGasFee). - -:::note Important Detailed Information - -[Read carefully before using this function.](xfer.md) - -::: - -### `foundryCreateNew(t TokenScheme) s SerialNumber` - -Creates a new foundry with the specified token scheme, and assigns the foundry to the sender. - -You can call this end point from the CLI using `wasp-cli chain create-foundry -h` - -#### Parameters - -- `t` ([`iotago::TokenScheme`](https://github.com/iotaledger/iota.go/blob/develop/token_scheme.go)): The token scheme - for the new foundry. - -The storage deposit for the new foundry must be provided via allowance (only the minimum required will be used). - -#### Returns - -- `s` (`uint32`): The serial number of the newly created foundry - -### `foundryModifySupply(s SerialNumber, d SupplyDeltaAbs, y DestroyTokens)` - -Mints or destroys tokens for the given foundry, which must be controlled by the caller. - -#### Parameters - -- `s` (`uint32`): The serial number of the foundry. -- `d` (positive `big.Int`): Amount to mint or destroy. -- `y` (optional `bool` - default: `false`): Whether to destroy tokens (`true`) or not (`false`). - -When minting new tokens, the storage deposit for the new output must be provided via an allowance. - -When destroying tokens, the tokens to be destroyed must be provided via an allowance. - -### `foundryDestroy(s SerialNumber)` - -Destroys a given foundry output on L1, reimbursing the storage deposit to the caller. The foundry must be owned by the -caller. - -:::warning - -This operation cannot be reverted. - -::: - -#### Parameters - -- `s` (`uint32`): The serial number of the foundry. - -### `mintNFT(I ImmutableData, a AgentID, C CollectionID, w WithdrawOnMint)` - -Mints an NFT with ImmutableData `I` that will be owned by the AgentID `a`. -It's possible to mint as part of a collection `C` (the caller must be the owner of the collection NFT to mint new NFTs as part of said collection). -The mint can be done directly to any L1 address (it is not necessary for the target to have an account on the chain) - -#### Parameters - -- `I` (`[]byte`): ImmutableData for the NFT. -- `a` (`AgentID`): AgentID that will be the owner of the NFT. -- `C` (optional `NFTID` - default empty): collectionID (NFTID) for the NFT. -- `w` (optional `bool` - default `false`): whether to withdrawal the NFT in the minting step (can only be `true` when the targetAgentID is a L1 address). - -#### Returns - -- `D` (`MintID`): the internal ID of the NFT at the time of minting that can be used by users/contracts to obtain the resulting NFTID on the next block - ---- - -## Views - -### `balance(a AgentID)` - -Returns the fungible tokens owned by the given Agent ID on the chain. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID. - -#### Returns - -A map of [`TokenID`](#tokenid) => `big.Int`. An empty token ID (a string of zero length) represents the L1 base token. - -### `balanceBaseToken(a AgentID)` - -Returns the amount of base tokens owned by any AgentID `a` on the chain. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID. - -#### Returns - -- `B` (`uint64`): The amount of base tokens in the account. - -### `balanceNativeToken(a AgentID, N TokenID)` - -Returns the amount of native tokens with Token ID `N` owned by any AgentID `a` on the chain. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID. -- `N` ([`TokenID`](#tokenid)): The Token ID. - -#### Returns - -- `B` (`big.Int`): The amount of native tokens in the account. - -### `totalAssets()` - -Returns the sum of all fungible tokens controlled by the chain. - -#### Returns - -A map of [`TokenID`](#tokenid) => `big.Int`. An empty token ID (a string of zero length) represents the L1 base token. - -### `accounts()` - -Returns a list of all agent IDs that own assets on the chain. - -#### Returns - -A map of `AgentiD` => `0x01`. - -### `getNativeTokenIDRegistry()` - -Returns a list of all native tokenIDs that are owned by the chain. - -#### Returns - -A map of [`TokenID`](#tokenid) => `0x01` - -### `foundryOutput(s FoundrySerialNumber)` - -#### Parameters - -- `s` ([`FoundrySerialNumber`](#foundryserialnumber)): The Foundry serial number. - -#### Returns - -- `b`: [`iotago::FoundryOutput`](https://github.com/iotaledger/iota.go/blob/develop/output_foundry.go) - -### `accountNFTs(a AgentID)` - -Returns the NFT IDs for all NFTs owned by the given account. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID - -#### Returns - -- `i` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) - of [`iotago::NFTID`](https://github.com/iotaledger/iota.go/blob/develop/output_nft.go)): - The NFT IDs owned by the account - -### `accountNFTAmount(a AgentID)` - -Returns the number of NFTs owned by the given account. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID - -#### Returns - -- `A` (`uint32`) Amount of NFTs owned by the account - -### `accountNFTsInCollection(a AgentID)` - -Returns the NFT IDs for all NFTs in the given collection that are owned by the given account. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID -- `C` (`NFTID`): The NFT ID of the collection - -#### Returns - -- `i` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) - of [`iotago::NFTID`](https://github.com/iotaledger/iota.go/blob/develop/output_nft.go)): - The NFT IDs in the collection owned by the account - -### `accountNFTAmountInCollection(a AgentID)` - -Returns the number of NFTs in the given collection that are owned by the given account. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID -- `C` (`NFTID`): The NFT ID of the collection - -#### Returns - -- `A` (`uint32`) Amount of NFTs in the collection owned by the account - -### `accountFoundries(a AgentID)` - -Returns all foundries owned by the given account. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID - -#### Returns - -A map of [`FoundrySerialNumber`](#foundryserialnumber) => `0x01` - -### `nftData(z NFTID)` - -Returns the data for a given NFT with ID `z` that is on the chain. - -#### Returns - -- `e`: [`NFTData`](#nftdata) - -### `NFTIDbyMintID(D MintID)` - -Returns the NFTID `z` for a given MintID `D`. - -#### Parameters - -- `D` (`MintID`): MintID producted at the time the NFT was minted - -#### Returns - -- `z` (`NFTID`): The ID of the NFT - -### `getAccountNonce(a AgentID)` - -Returns the current account nonce for a give AgentID `a`. -The account nonce is used to issue off-ledger requests. - -#### Parameters - -- `a` (`AgentID`): The account Agent ID. - -#### Returns - -- `n` (`uint64`): The account nonce. - -## Schemas - -### `FoundrySerialNumber` - -``` -FoundrySerialNumber = uint32 -``` - -### `TokenID` - -``` -TokenID = [38]byte -``` - -### `NFTID` - -``` -NFTID = [32]byte -``` - -### `MintID` - -``` -MintID = [6]byte -``` - -### `NFTData` - -`NFTData` is encoded as the concatenation of: - -- The issuer ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)). -- The NFT metadata: the length (`uint16`) followed by the data bytes. -- The NFT owner (`AgentID`). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md deleted file mode 100644 index 67e516e2a0a..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -description: The `blobs` contract maintains a registry of _blobs_ (a collection of arbitrary binary data) referenced from smart contracts via their hashes. -image: /img/logo/WASP_logo_dark.png -tags: - - core contracts - - bloc - - binary data - - store - - get - - entry points - - views - - reference ---- - -# The `blob` Contract - -The `blob` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. - -The objective of the `blob` contract is to maintain an on-chain registry of _blobs_. -A blob is a collection of named chunks of binary data. - -``` -: -: -... -: -``` - -Both names and chunks are arbitrarily long byte slices. - -Blobs can be used to store arbitrary data like, for example, a collection of Wasm binaries needed to deploy a smart contract. - -Each blob in the registry is referenced by its hash. The hash is deterministically calculated from the concatenation of all pieces: - -``` -blobHash = hash( fieldName1 || binaryChunk1 || fieldName2 || binaryChunk2 || ... || fieldNameN || binaryChunkN) -``` - -Usually, field names are short strings, but their interpretation is use-case specific. - -Two predefined field names are interpreted by the VM while deploying smart contracts from binary: - -- _fieldname_ = `"v"` is interpreted as the _VM type_. -- _fieldname_ = `"p"` is interpreted as the _smart contract program binary_. - -If the field `"v"` is equal to the string `"wasmtime"`, the binary chunk of `"p"` is interpreted as WebAssembly binary, executable by the Wasmtime interpreter. - -The blob describing a smart contract may contain extra fields (ignored by the VM), for example: - -``` -"v" : VM type -"p" : smart contract program binary -"d" : data schema for data exchange between smart contract and outside sources and consumers -"s" : program sources in .zip format -``` - ---- - -## Entry Points - -### `storeBlob()` - -Stores a new blob in the registry. - -#### Parameters - -The key/value pairs of the received parameters are interpreted as the field/chunk pairs of the blob. - -#### Returns - -- `hash` (`[32]byte`): The hash of the stored blob. - ---- - -## Views - -### `getBlobInfo(hash BlobHash)` - -Returns the size of each chunk of the blob. - -#### Parameters - -- `hash` (`[32]byte`): The hash of the blob. - -#### Returns - -``` -: (uint32) -... -: (uint32) -``` - -### `getBlobField(hash BlobHash, field BlobField)` - -Returns the chunk associated with the given blob field name. - -#### Parameters - -- `hash` (`[32]byte`): The hash of the blob. -- `field` (`[]byte`): The field name. - -#### Returns - -- `bytes` (`[]byte`): The chunk associated with the given field name. - -### `listBlobs()` - -Returns a list of pairs `blob hash`: `total size of chunks` (`uint32`) for all blobs in the registry. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md deleted file mode 100644 index e4e5dbb2244..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: 'The errors contract keeps a map of error codes to error message templates. These error codes are used in -request receipts.' -image: /img/logo/WASP_logo_dark.png -tags: - -- smart contracts -- core -- root -- initialization -- entry points -- fees -- ownership -- views -- reference ---- - -# The `errors` Contract - -The `errors` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts -chain. - -The `errors` contract keeps a map of error codes to error message templates. -This allows contracts to store lengthy error strings only once and then reuse them by just providing the error code (and -optional extra values) when producing an error, thus saving storage and gas. - ---- - -## Entry Points - -### `registerError(m ErrorMessageFormat) c ErrorCode` - -Registers an error message template. - -#### Parameters - -- `m` (`string`): The error message template, which supports standard [go verbs](https://pkg.go.dev/fmt#hdr-Printing) - for variable printing. - -#### Returns - -- `c` (`ErrorCode`): The error code of the registered template - ---- - -## Views - -### `getErrorMessageFormat(c ErrorCode) m ErrorMessageFormat` - -Returns the message template stored for a given error code. - -#### Parameters - -- `c` (`ErrorCode`): The error code of the registered template. - -#### Returns - -- `m` (`string`): The error message template. - ---- - -## Schemas - -### `ErrorCode` - -`ErrorCode` is encoded as the concatenation of: - -- The contract hname(`hname`). -- The error ID, calculated as the hash of the error template(`uint16`). - -### `UnresolvedVMError` - -`UnresolvedVMError` is encoded as the concatenation of: - -- The error code ([`ErrorCode`](#errorcode)). -- CRC32 checksum of the formatted string (`uint32`). -- The JSON-encoded list of parameters for the template (`string` prefixed with `uint16` size). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md deleted file mode 100644 index 73cab959f4c..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -description: 'The evm core contract provides the necessary infrastructure to accept Ethereum transactions and execute -EVM code.' -image: /img/logo/WASP_logo_dark.png -tags: - -- smart contracts -- core -- root -- initialization -- entry points -- fees -- ownership -- views -- reference ---- - -# The `evm` Contract - -The `evm` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. - -The `evm` core contract provides the necessary infrastructure to accept Ethereum transactions and execute EVM code. -It also includes the implementation of the [ISC Magic contract](/wasp-evm/how-tos/magic-contract/magic). - -:::note - -For more information about how ISC supports EVM contracts, refer to the [EVM](/wasp-evm/introduction/) section. - -::: - ---- - -## Entry Points - -Most entry points of the `evm` core contract are meant to be accessed through the JSON-RPC service provided -automatically by the Wasp node so that the end users can use standard EVM tools like [MetaMask](https://metamask.io/). -We only list the entry points not exposed through the JSON-RPC interface in this document. - -### `init()` - -Called automatically when the ISC is deployed. - -Some parameters of the `evm` contract can be specified by passing them to the -[`root` contract `init` entry point](root.md#init): - -- `evmg` (optional [`GenesisAlloc`](#genesisalloc)): The genesis allocation. The balance of all accounts must be 0. -- `evmbk` (optional `int32` - default: keep all): Amount of EVM blocks to keep in the state. -- `evmchid` (optional `uint16` - default: 1074): EVM chain iD - - :::caution - - Re-using an existing Chain ID is not recommended and can be a security risk. For serious usage, register a unique - Chain ID on [Chainlist](https://chainlist.org/) and use that instead of the default. **It is not possible to change - the EVM chain ID after deployment.** - - ::: - -- `evmw` (optional [`GasRatio`](#gasratio) - default: `1:1`): The ISC to EVM gas ratio. - -### `registerERC20NativeToken` - -Registers an ERC20 contract to act as a proxy for the native tokens, at address -`0x107402xxxxxxxx00000000000000000000000000`, where `xxxxxxxx` is the -little-endian encoding of the foundry serial number. - -Only the foundry owner can call this endpoint. - -#### Parameters - -- `fs` (`uint32`): The foundry serial number -- `n` (`string`): The token name -- `t` (`string`): The ticker symbol -- `d` (`uint8`): The token decimals - -You can call this endpoint with the `wasp-cli register-erc20-native-token` command. See -`wasp-cli chain register-erc20-native-token -h` for instructions on how to use the command. - -### `registerERC20NativeTokenOnRemoteChain` - -Registers an ERC20 contract to act as a proxy for the native tokens **on another -chain**. - -The foundry must be controlled by this chain. Only the foundry owner can call -this endpoint. - -This endpoint is intended to be used in case the foundry is controlled by chain -A, and the owner of the foundry wishes to register the ERC20 contract on chain -B. In that case, the owner must call this endpoint on chain A with `target = -chain B`. The request to chain B is then sent as an on-ledger request. -After a few minutes, call -[`getERC20ExternalNativeTokensAddress`](#geterc20externalnativetokensaddress) -on chain B to find out the address of the ERC20 contract. - -#### Parameters - -- `fs` (`uint32`): The foundry serial number -- `n` (`string`): The token name -- `t` (`string`): The ticker symbol -- `d` (`uint8`): The token decimals -- `A` (`uint8`): The target chain address, where the ERC20 contract will be - registered. - -You can call this endpoint with the `wasp-cli register-erc20-native-token-on-remote-chain` command. See -`wasp-cli chain register-erc20-native-token-on-remote-chain -h` for instructions on how to use the command. - -### `registerERC20ExternalNativeToken` - -Registers an ERC20 contract to act as a proxy for the native tokens. - -Only an alias address can call this endpoint. - -If the foundry is controlled by another ISC chain, the foundry owner can call -[`registerERC20NativeTokenOnRemoteChain`](#registererc20nativetokenonchain) -on that chain, which will automatically call this endpoint on the chain set as -target. - -#### Parameters - -- `fs` (`uint32`): The foundry serial number -- `n` (`string`): The token name -- `t` (`string`): The ticker symbol -- `d` (`uint8`): The token decimals -- `T` (`TokenScheme`): The native token scheme - -### `registerERC721NFTCollection` - -Registers an ERC721 contract to act as a proxy for an NFT collection, at address -`0x107404xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`, where `xxx...` is the first 17 -bytes of the collection ID. - -The call will fail if the address is taken by another collection with the same prefix. - -#### Parameters - -- `C` (`NTFID`): The collection ID - ---- - -## Views - -### `getERC20ExternalNativeTokensAddress` - -Returns the address of an ERC20 contract registered with -[`registerERC20NativeTokenOnRemoteChain`](#registererc20nativetokenonchain). - -Only the foundry owner can call this endpoint. - -#### Parameters - -- `N` (`NativeTokenID`): The native token ID - ---- - -## Schemas - -### `GenesisAlloc` - -`GenesisAlloc` is encoded as the concatenation of: - -- Amount of accounts `n` (`uint32`). -- `n` times: - - Ethereum address (`[]byte` prefixed with `uint32` size). - - Account code (`[]byte` prefixed with `uint32` size). - - Amount of storage key/value pairs `m`(`uint32`). - - `m` times: - - Key (`[]byte` prefixed with `uint32` size). - - Value(`[]byte` prefixed with `uint32` size). - - Account balance (must be 0)(`[]byte` prefixed with `uint32` size). - - Account nonce (`uint64`). - - Account private key (may be used for tests)(`uint64`). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md deleted file mode 100644 index ab8e092379b..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md +++ /dev/null @@ -1,355 +0,0 @@ ---- -description: 'The `governance` contract defines the set of identities that constitute the state controller, access nodes, -who is the chain owner, and the fees for request execution.' -image: /img/logo/WASP_logo_dark.png -tags: - -- core contracts -- governance -- state controller -- identities -- chain owner -- rotate -- remove -- claim -- add -- chain info -- fee info -- reference ---- - -# The `governance` Contract - -The `governance` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts -chain. - -The `governance` contract provides the following functionalities: - -- It defines the identity set that constitutes the state controller (the entity that owns the state output via the chain - Alias Address). It is possible to add/remove addresses from the state controller (thus rotating the committee of - validators). -- It defines the chain owner (the L1 entity that owns the chain - initially whoever deployed it). The chain owner can - collect special fees and customize some chain-specific parameters. -- It defines the entities allowed to have an access node. -- It defines the fee policy for the chain (gas price, what token is used to pay for gas, and the validator fee share). - ---- - -## Fee Policy - -The Fee Policy looks like the following: - -```go -{ - GasPerToken Ratio32 // how many gas units are paid for each token - EVMGasRatio Ratio32 // the ratio at which EVM gas is converted to ISC gas - ValidatorFeeShare uint8 // percentage of the fees that are credited to the validators (0 - 100) -} -``` - ---- - -## Entry Points - -### `rotateStateController(S StateControllerAddress)` - -Called when the committee is about to be rotated to the new address `S`. - -If it succeeds, the next state transition will become a governance transition, thus updating the state controller in the -chain's Alias Output. If it fails, nothing happens. - -It can only be invoked by the chain owner. - -#### Parameters - -- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address of the next - state controller. Must be an - [allowed](#addallowedstatecontrolleraddresss-statecontrolleraddress) state controller address. - -### `addAllowedStateControllerAddress(S StateControllerAddress)` - -Adds the address `S` to the list of identities that constitute the state controller. - -It can only be invoked by the chain owner. - -#### Parameters - -- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address to add to the - set of allowed state controllers. - -### `removeAllowedStateControllerAddress(S StateControllerAddress)` - -Removes the address `S` from the list of identities that constitute the state controller. - -It can only be invoked by the chain owner. - -#### Parameters - -- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address to remove from - the set of allowed state controllers. - -### `delegateChainOwnership(o AgentID)` - -Sets the Agent ID `o` as the new owner for the chain. This change will only be effective -once [`claimChainOwnership`](#claimchainownership) is called by `o`. - -It can only be invoked by the chain owner. - -#### Parameters - -- `o` (`AgentID`): The Agent ID of the next chain owner. - -### `claimChainOwnership()` - -Claims the ownership of the chain if the caller matches the identity set -in [`delegateChainOwnership`](#delegatechainownershipo-agentid). - -### `setFeePolicy(g FeePolicy)` - -Sets the fee policy for the chain. - -#### Parameters - -- `g`: ([`FeePolicy`](#feepolicy)). - -It can only be invoked by the chain owner. - -### `setGasLimits(l GasLimits)` - -Sets the gas limits for the chain. - -#### Parameters - -- `l`: ([`GasLimits`](#gaslimits)). - -It can only be invoked by the chain owner. - -### `setEVMGasRatio(e Ratio32)` - -Sets the EVM gas ratio for the chain. - -#### Parameters - -- `e` ([`Ratio32`](#ratio32)): The EVM gas ratio. - -It can only be invoked by the chain owner. - -### `addCandidateNode(ip PubKey, ic Certificate, ia API, i ForCommittee)` - -Adds a node to the list of candidates. - -#### Parameters - -- `ip` (`[]byte`): The public key of the node to be added. -- `ic` (`[]byte`): The certificate is a signed binary containing both the node public key and their L1 address. -- `ia` (`string`): The API base URL for the node. -- `i` (optional `bool` - default: `false`): Whether the candidate node is being added to be part of the committee or - just an access node. - -It can only be invoked by the access node owner (verified via the Certificate field). - -### `revokeAccessNode(ip PubKey, ic Certificate, ia API, i ForCommittee)` - -Removes a node from the list of candidates. - -#### Parameters - -- `ip` (`[]byte`): The public key of the node to be removed. -- `ic` (`[]byte`): The certificate of the node to be removed. - -It can only be invoked by the access node owner (verified via the Certificate field). - -### `changeAccessNodes(n actions)` - -Iterates through the given map of actions and applies them. - -#### Parameters - -- `n` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go) of `public key` => `byte`): - The list of actions to perform. Each byte value can be one of the following: - - `0`: Remove the access node from the access nodes list. - - `1`: Accept a candidate node and add it to the list of access nodes. - - `2`: Drop an access node from the access node and candidate lists. - -It can only be invoked by the chain owner. - -### `startMaintenance()` - -Starts the chain maintenance mode, meaning no further requests will be processed except -calls to the governance contract. - -It can only be invoked by the chain owner. - -### `stopMaintenance()` - -Stops the maintenance mode. - -It can only be invoked by the chain owner. - -### `setCustomMetadata(x bytes)` - -Changes optional extra metadata that is appended to the L1 AliasOutput. - -#### Parameters - -- `x` (`bytes`): the optional metadata - -### `setPayoutAgentID` - -`setPayoutAgentID` sets the payout AgentID. The default AgentID is the chain owner. Transaction fee will be taken to ensure the common account has minimum storage deposit which is in base token. The rest of transaction fee will be transferred to payout AgentID. - -#### Parameters - -- `s` (`AgentID`): the payout AgentID - -### `setMinCommonAccountBalance` - -`setMinCommonAccountBalance` sets the minimum balanced to be held in the common account. - -#### Parameters - -- `ms` (`AgentID`): the minimum common account balance - ---- - -## Views - -### `getAllowedStateControllerAddresses()` - -Returns the list of allowed state controllers. - -#### Returns - -- `a` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) - of [`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The list of allowed state - controllers. - -### `getChainOwner()` - -Returns the AgentID of the chain owner. - -#### Returns - -- `o` (`AgentID`): The chain owner. - -### `getChainInfo()` - -Returns information about the chain. - -#### Returns - -- `c` (`ChainID`): The chain ID -- `o` (`AgentID`): The chain owner -- `g` ([`FeePolicy`](#feepolicy)): The gas fee policy -- `l` ([`GasLimits`](#gaslimits)): The gas limits -- `x` (`bytes`): The custom metadata - -### `getFeePolicy()` - -Returns the gas fee policy. - -#### Returns - -- `g` ([`FeePolicy`](#feepolicy)): The gas fee policy. - -### `getEVMGasRatio` - -Returns the ISC : EVM gas ratio. - -#### Returns - -- `e` ([`Ratio32`](#ratio32)): The ISC : EVM gas ratio. - -### `getGasLimits()` - -Returns the gas limits. - -#### Returns - -- `l` ([`GasLimits`](#gaslimits)): The gas limits. - -### `getChainNodes()` - -Returns the current access nodes and candidates. - -#### Returns - -- `ac` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go) - of public key => `0x01`): The access nodes. -- `an` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go) - of public key => [`AccessNodeInfo`](#accessnodeinfo)): The candidate nodes. - -### `getMaintenanceStatus()` - -Returns whether the chain is undergoing maintenance. - -#### Returns - -- `m` (`bool`): `true` if the chain is in maintenance mode - -### `getCustomMetadata()` - -Returns the extra metadata that is added to the chain AliasOutput. - -#### Returns - -- `x` (`bytes`): the optional metadata - -### `getPayoutAgentID` - -`getPayoutAgentID` gets the payout AgentID. - -Returns the payout AgentID of the chain. - -#### Returns - -- `s` (`AgentID`): the payout AgentID. - -### `getMinCommonAccountBalance` - -`getMinCommonAccountBalance` returns the minimum balanced to be held in the common account. - -#### Returns - -- `ms` (`uint64`): the minimum storage deposit. - -## Schemas - -### `Ratio32` - -A ratio between two values `x` and `y`, expressed as two `int32` numbers `a:b`, where `y = x * b/a`. - -`Ratio32` is encoded as the concatenation of the two `uint32` values `a` & `b`. - -### `FeePolicy` - -`FeePolicy` is encoded as the concatenation of: - -- The [`TokenID`](accounts.md#tokenid) of the token used to charge for gas. (`iotago.NativeTokenID`) - - If this value is `nil`, the gas fee token is the base token. -- Gas per token ([`Ratio32`](#ratio32)): expressed as an `a:b` (`gas/token`) ratio, meaning how many gas units each token pays for. -- Validator fee share. Must be between 0 and 100, meaning the percentage of the gas fees distributed to the - validators. (`uint8`) -- The ISC:EVM gas ratio ([`Ratio32`](#ratio32)): such that `ISC gas = EVM gas * a/b`. - -### `GasLimits` - -`GasLimits` is encoded as the concatenation of: - -- The maximum gas per block (`uint64`). A request that exceeds this limit is - skipped and processed in the next block. -- The minimum gas per request (`uint64`). If a request consumes less than this - value, it is charged for this instead. -- The maximum gas per request (`uint64`). If a request exceeds this limit, it - is rejected as failed. -- The maximum gas per external view call (`uint64). This is the gas budget - assigned to external view calls. - -### `AccessNodeInfo` - -`AccessNodeInfo` is encoded as the concatenation of: - -- The validator address. (`[]byte` prefixed by `uint16` size) -- The certificate. (`[]byte` prefixed by `uint16` size) -- Whether the access node is part of the committee of validators. (`bool`) -- The API base URL. (`string` prefixed by `uint16` size) diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md deleted file mode 100644 index e3d70cd2419..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -description: There currently are 6 core smart contracts that are always deployed on each chain, root, _default, accounts, blob, blocklog, and governance. -image: /img/banner/banner_wasp_core_contracts_overview.png -tags: - - smart contracts - - core - - initialization - - request handling - - on-chain ledger - - accounts - - data - - receipts - - reference ---- - -# Core Contracts - -![Wasp Node Core Contracts Overview](/img/banner/banner_wasp_core_contracts_overview.png) - -There are currently 7 core smart contracts that are always deployed on each -chain. These are responsible for the vital functions of the chain and -provide infrastructure for all other smart contracts: - -- [`root`](./root.md): Responsible for the initialization of the chain, maintains registry of deployed contracts. - -- [`accounts`](./accounts.md): Manages the on-chain ledger of accounts. - -- [`blob`](./blob.md): Responsible for the registry of binary objects of arbitrary size. - -- [`blocklog`](./blocklog.md): Keeps track of the blocks and receipts of requests that were processed by the chain. - -- [`governance`](./governance.md): Handles the administrative functions of the chain. For example: rotation of the committee of validators of the chain, fees and other chain-specific configurations. - -- [`errors`](./errors.md): Keeps a map of error codes to error messages templates. These error codes are used in request receipts. - -- [`evm`](./evm.md): Provides the necessary infrastructure to accept Ethereum - transactions and execute EVM code. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/root.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/root.md deleted file mode 100644 index 439e438befb..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/root.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -description: 'The root contract is the first smart contract deployed on the chain. It functions as a smart contract -factory for the chain.' -image: /img/logo/WASP_logo_dark.png -tags: - -- smart contracts -- core -- root -- initialization -- entry points -- fees -- ownership -- views -- reference ---- - -# The `root` Contract - -The `root` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts -chain. - -The `root` contract is responsible for the initialization of the chain. -It is the first smart contract deployed on the chain and, upon receiving the `init` request, bootstraps the state of the -chain. -Deploying all of the other core contracts is a part of the state initialization. - -The `root` contract also functions as a smart contract factory for the chain: upon request, it deploys other smart -contracts and maintains an on-chain registry of smart contracts in its state. -The contract registry keeps a list of contract records containing their respective name, hname, description, and -creator. - ---- - -## Entry Points - -### `init()` - -The constructor. Automatically called immediately after confirmation of the origin transaction and never called again. -When executed, this function: - -- Initializes base values of the chain according to parameters. -- Sets the caller as the _chain owner_. -- Deploys all the core contracts. - -### `deployContract(ph ProgramHash, nm Name, ds Description)` - -Deploys a non-EVM smart contract on the chain if the caller has deployment permission. - -#### Parameters - -- `ph` (`[32]byte`): The hash of the binary _blob_ (that has been previously stored in the [`blob` contract](blob.md)). -- `nm` (`string`): The name of the contract to be deployed, used to calculate the - contract's _hname_. The hname must be unique among all contract hnames in the chain. -- `ds` (`string`): Description of the contract to be deployed. - -Any other parameters that are passed to the deployContract function will be passed on to -the `init` function of the smart contract being deployed. Note that this means that the -init parameter names cannot be the above ones, as they will have been filtered out. - -### `grantDeployPermission(dp AgentID)` - -The chain owner grants deploy permission to the agent ID `dp`. - -#### Parameters - -`dp`(AgentID): The agent ID. - -### `revokeDeployPermission(dp AgentID)` - -The chain owner revokes the deploy permission of the agent ID `dp`. - -#### Parameters - -`dp`(AgentID): The agent ID. - -### `requireDeployPermissions(de DeployPermissionsEnabled)` - -#### Parameters - -- `de` (`bool`): Whether permissions should be required to deploy a contract on the chain. - -By default, permissions are enabled (addresses need to be granted the right to deploy), but the chain owner can override -this setting to allow anyone to deploy contracts on the chain. - ---- - -## Views - -### `findContract(hn Hname)` - -Returns the record for a given smart contract with Hname `hn` (if it exists). - -#### Parameters - -`hn`: The smart contract’s Hname - -#### Returns - -- `cf` (`bool`): Whether or not the contract exists. -- `dt` ([`ContractRecord`](#contractrecord)): The requested contract record (if it exists). - -### `getContractRecords()` - -Returns the list of all smart contracts deployed on the chain and related records. - -#### Returns - -A map of `Hname` => [`ContractRecord`](#contractrecord) - ---- - -## Schemas - -### `ContractRecord` - -A `ContractRecord` is encoded as the concatenation of: - -- Program hash (`[32]byte`). -- Contract description (`string`). -- Contract name (`string`). diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md deleted file mode 100644 index 208316b58c8..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -description: 'The `transferAccountToChain` contract needs special consideration.' -image: /img/logo/WASP_logo_dark.png -tags: - - core contracts - - accounts - - deposit - - withdraw - - assets - - balance - - reference ---- - -# `accounts.transferAccountToChain` - -The `transferAccountToChain` function of the `accounts` contract is one that needs -careful consideration before use. Make sure you understand precisely how to use it to -prevent - ---- - -## Entry Point - -### `transferAccountToChain(g GasReserve)` - -Transfers the specified allowance from the sender SC's L2 account on -the target chain to the sender SC's L2 account on the origin chain. - -Caller must be a contract, and we will transfer the allowance from its L2 account -on the target chain to its L2 account on the origin chain. This requires that -this function takes the allowance into custody and in turn sends the assets as -allowance to the origin chain, where that chain's accounts.TransferAllowanceTo() -function then transfers it into the caller's L2 account on that chain. - -#### Parameters - -- `g` (`uint64`): Optional gas amount to reserve in the allowance for - the internal call to transferAllowanceTo(). Default 100 (MinGasFee). - But better to provide it so that it matches the fee structure. - -### IMPORTANT CONSIDERATIONS - -1. The caller contract needs to provide sufficient base tokens in its - allowance, to cover the gas fee GAS1 for this request. - Note that this amount depends on the fee structure of the target chain, - which can be different from the fee structure of the caller's own chain. - -2. The caller contract also needs to provide sufficient base tokens in - its allowance, to cover the gas fee GAS2 for the resulting request to - accounts.TransferAllowanceTo() on the origin chain. The caller needs to - also specify this GAS2 amount through the GasReserve parameter. - -3. The caller contract also needs to provide a storage deposit SD with - this request, holding enough base tokens _independent_ of the GAS1 and - GAS2 amounts. - Since this storage deposit is dictated by L1 we can use this amount as - storage deposit for the resulting accounts.TransferAllowanceTo() request, - where it will then be returned to the caller as part of the transfer. - -4. This means that the caller contract needs to provide at least - GAS1 + GAS2 + SD base tokens as assets to this request, and provide an - allowance to the request that is exactly GAS2 + SD + transfer amount. - Failure to meet these conditions may result in a failed request and - worst case the assets sent to accounts.TransferAllowanceTo() could be - irretrievably locked up in an account on the origin chain that belongs - to the accounts core contract of the target chain. - -5. The caller contract needs to set the gas budget for this request to - GAS1 to guard against unanticipated changes in the fee structure that - raise the gas price, otherwise the request could accidentally cannibalize - GAS2 or even SD, with potential failure and locked up assets as a result. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/testnet.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/testnet.md deleted file mode 100644 index d7ab81d74ba..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/testnet.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: A public testnet for developers to try out smart contracts -image: /img/logo/WASP_logo_dark.png -tags: - - Smart Contracts - - TestNet ---- - -# Testnet - -The testnet is deployed for the community to use for testing and interacting with smart contracts. - -:::caution unscheduled network resets -While we are in active development we might update and reset this chain at any time without prior notice; Keep this in mind while testing. -::: - -## Introduction - -This testnet is deployed on the Shimmer Beta Network (testnet). Multiple committee nodes do the work for -the chain and multiple access nodes are exposed via the endpoints listed below. We do throttle the endpoints to prevent -overloading the testnet because we are looking for functionality testing more than stress testing. - -## Endpoints - -You can access the testnet via the following endpoints: - -- https://json-rpc.evm.testnet.shimmer.network/ - - The URL to interact with the Ethereum Virtual Machine on our testnet -- https://evm-faucet.testnet.shimmer.network/ - - The faucet for the Shimmer Beta network -- https://explorer.evm.testnet.shimmer.network/ - - EVM explorer to view transactions and contracts - -## Interact with EVM - -We have deployed an experimental EVM chain that you can interact with. To begin, add a custom network to Metamask with -the following configuration: - -| Key | Value | -| -------- | -------------------------------------------- | -| RPC URL | https://json-rpc.evm.testnet.shimmer.network | -| Chain ID | 1073 | - -:::note - -The other values (network name and currency symbol) can be whatever value you like. - -::: - -We have a faucet for you to use directly with your EVM address which can be found on https://toolkit.sc.testnet.shimmer.network/ -We also have a withdrawal interface to get any native assets deposited to a EVM chain back into your L1 address on the same link. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/sidebars.js b/docs/build/wasp-wasm/v1.0.0-rc.6/sidebars.js deleted file mode 100644 index 5fa60186648..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/sidebars.js +++ /dev/null @@ -1,283 +0,0 @@ -/** - * 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 = { - // By default, Docusaurus generates a sidebar from the docs folder structure - //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], - - // But you can create a sidebar manually - wasmSidebar: [ - { - type: 'doc', - label: 'Wasm VM for ISC', - id: 'introduction', - }, - { - type: 'category', - label: 'Explanations', - items: [ - { - type: 'doc', - label: 'How Accounts Work', - id: 'explanations/how-accounts-work', - }, - { - type: 'doc', - label: 'Call Context', - id: 'explanations/context', - }, - { - type: 'doc', - label: 'Data Access Proxies', - id: 'explanations/proxies', - }, - ], - }, - { - type: 'category', - label: 'How To', - items: [ - { - type: 'category', - label: 'Use the Schema Tool', - items: [ - { - type: 'doc', - label: 'Introduction', - id: 'how-tos/schema-tool/introduction', - }, - { - type: 'doc', - label: 'Create a Schema', - id: 'how-tos/schema-tool/usage', - }, - { - type: 'doc', - label: 'Define the State', - id: 'how-tos/schema-tool/state', - }, - { - type: 'doc', - label: 'Use Structured Data Types', - id: 'how-tos/schema-tool/structs', - }, - { - type: 'doc', - label: 'Generate Type Definitions', - id: 'how-tos/schema-tool/typedefs', - }, - { - type: 'doc', - label: 'Trigger Events', - id: 'how-tos/schema-tool/events', - }, - { - type: 'doc', - label: 'Define Functions', - id: 'how-tos/schema-tool/funcs', - }, - { - type: 'doc', - label: 'Limit Access', - id: 'how-tos/schema-tool/access', - }, - { - type: 'doc', - label: 'Define Function Parameters', - id: 'how-tos/schema-tool/params', - }, - { - type: 'doc', - label: 'Define Function Results', - id: 'how-tos/schema-tool/results', - }, - { - type: 'doc', - label: 'Use Thunk Functions', - id: 'how-tos/schema-tool/thunks', - }, - { - type: 'doc', - label: 'Use View-Only Functions', - id: 'how-tos/schema-tool/views', - }, - { - type: 'doc', - label: 'Initialize a Smart Contract', - id: 'how-tos/schema-tool/init', - }, - { - type: 'doc', - label: 'Transfer Tokens', - id: 'how-tos/schema-tool/transfers', - }, - { - type: 'doc', - label: 'Add Function Descriptors', - id: 'how-tos/schema-tool/funcdesc', - }, - { - type: 'doc', - label: 'Call Functions', - id: 'how-tos/schema-tool/call', - }, - { - type: 'doc', - label: 'Post Asynchronous Requests', - id: 'how-tos/schema-tool/post', - }, - ], - }, - { - type: 'doc', - label: 'Deposit To a Chain', - id: 'how-tos/deposit-to-a-chain', - }, - { - type: 'doc', - label: 'Withdraw From a Chain', - id: 'how-tos/withdraw-from-a-chain', - }, - { - type: 'doc', - label: 'View Account Balances', - id: 'how-tos/view-account-balances', - }, - { - type: 'category', - label: 'Test Smart Contracts with Solo', - items: [ - { - type: 'doc', - label: 'What is Solo?', - id: 'how-tos/solo/what-is-solo', - }, - { - type: 'doc', - label: 'First Example', - id: 'how-tos/solo/first-example', - }, - { - type: 'doc', - label: 'The L1 Ledger', - id: 'how-tos/solo/the-l1-ledger', - }, - { - type: 'doc', - label: 'Deploy a Smart Contract', - id: 'how-tos/solo/deploying-sc', - }, - { - type: 'doc', - label: 'Invoke a Smart Contract', - id: 'how-tos/solo/invoking-sc', - }, - { - type: 'doc', - label: 'Call a View', - id: 'how-tos/solo/view-sc', - }, - { - type: 'doc', - label: 'Error Handling', - id: 'how-tos/solo/error-handling', - }, - { - type: 'doc', - label: 'Accounts', - id: 'how-tos/solo/the-l2-ledger', - }, - { - type: 'doc', - label: 'Test Smart Contracts', - id: 'how-tos/solo/test', - }, - { - type: 'doc', - label: 'Example Tests', - id: 'how-tos/solo/examples', - }, - { - type: 'doc', - label: 'Colored Tokens and Time Locks', - id: 'how-tos/solo/timelock', - }, - ], - }, - ], - }, - - { - type: 'category', - label: 'Reference', - items: [ - { - type: 'category', - label: 'Core Contracts', - items: [ - { - type: 'doc', - label: 'Overview', - id: 'reference/core-contracts/overview', - }, - { - type: 'doc', - label: 'root', - id: 'reference/core-contracts/root', - }, - { - type: 'doc', - label: 'accounts', - id: 'reference/core-contracts/accounts', - }, - { - type: 'doc', - label: 'blob', - id: 'reference/core-contracts/blob', - }, - { - type: 'doc', - label: 'blocklog', - id: 'reference/core-contracts/blocklog', - }, - { - type: 'doc', - label: 'governance', - id: 'reference/core-contracts/governance', - }, - { - type: 'doc', - label: 'errors', - id: 'reference/core-contracts/errors', - }, - { - type: 'doc', - label: 'evm', - id: 'reference/core-contracts/evm', - }, - ], - }, - - { - type: 'category', - label: 'Data Types', - items: [ - { - type: 'doc', - label: 'WasmLib Data Types', - id: 'reference/data-types/types', - }, - ], - }, - ], - }, - ], -}; diff --git a/docs/learn/sidebars.ts b/docs/learn/sidebars.ts index 398eb0bc609..00ac96280d9 100644 --- a/docs/learn/sidebars.ts +++ b/docs/learn/sidebars.ts @@ -80,43 +80,33 @@ module.exports = { }, { type: 'doc', - label: 'ISC Architecture', - id: 'smart-contracts/isc-architecture', + label: 'Protocol Overview', + id: 'smart-contracts/protocol-overview', }, { type: 'doc', - label: 'Anatomy of a Smart Contract', - id: 'smart-contracts/smart-contract-anatomy', + label: 'Smart Contract Execution', + id: 'smart-contracts/smart-contract-execution', }, { type: 'doc', - label: 'Sandbox Interface', - id: 'smart-contracts/sandbox', + label: 'Account, Addresses & Fees', + id: 'smart-contracts/accounts-addresses-and-fees', }, { type: 'doc', - label: 'Calling a Smart Contract', - id: 'smart-contracts/invocation', + label: 'Chain Owners, Validators, & Access Nodes', + id: 'smart-contracts/chain-owners-validators-and-access-nodes', }, { type: 'doc', - label: 'State, Transitions and State Anchoring', - id: 'smart-contracts/states', - }, - { - type: 'doc', - label: 'State manager', - id: 'smart-contracts/state_manager', - }, - { - type: 'doc', - label: 'Validators and Access Nodes', - id: 'smart-contracts/validators', + label: 'Consensus', + id: 'smart-contracts/consensus', }, { type: 'doc', - label: 'Consensus', - id: 'smart-contracts/consensus', + label: 'State Management & Anchoring', + id: 'smart-contracts/state-management-and-anchoring', }, ], }, diff --git a/docs/learn/smart-contracts/accounts-addresses-and-fees.md b/docs/learn/smart-contracts/accounts-addresses-and-fees.md new file mode 100644 index 00000000000..08db5ffe903 --- /dev/null +++ b/docs/learn/smart-contracts/accounts-addresses-and-fees.md @@ -0,0 +1,54 @@ +--- +description: An overview of account types, gas costs, and fees in IOTA Smart Contracts for efficient transaction management. +image: /img/logo/WASP_logo_dark.png +tags: + - IOTA Smart Contracts + - Accounts and Addresses + - Gas and Fees + - Blockchain + - Digital Assets +--- + +# Accounts, Addresses, and Fees + +## TL;DR; + +- [Types of Accounts](#types-of-accounts): IOTA Smart Contracts feature Layer 1 and Layer 2 accounts, each serving + different roles and facilitating asset transfers across the blockchain. +- [Gas](#gas): Running requests in IOTA Smart Contracts incurs a 'gas' cost, with users setting a `GasBudget` to manage + their spending. +- [Gas Budget](#gas-budget): The `GasBudget` allows users to define a spending limit for their requests, aligning with + the chain’s fee policy. +- [Allowance](#allowance): The `Allowance` system controls the fund usage in smart contracts, ensuring only authorized + transactions are processed. + +## Types of Accounts + +In the world of IOTA Smart Contracts, accounts play a pivotal role. These accounts exist on two levels: Layer 1 (L1) and +Layer 2 (L2). L1 addresses control assets on the IOTA ledger, and each smart contract chain has a unique L1 address, +acting as a custodian for L1 assets. On the L2 ledger, accounts can be owned by various entities, each identified by a +unique Agent ID. An L2 account can belong to a standard L1 address, a specific smart contract, or even an Ethereum +address, enabling trustless asset transfers between different entities on the same or different chains. + +## Gas + +In the IOTA Smart Contract ecosystem, running a request in a chain incurs a cost known as 'gas'. Each operation within a +smart contract, like arithmetic calculations or data storage, has an associated gas cost. + +### Gas Budget + +Users define a `GasBudget` for their requests, which represents the maximum cost they are willing to pay. This fee is +charged based on the chain’s fee policy and is deducted from the user's on-chain account. + +### Allowance + +Additionally, the concept of `Allowance` is crucial as it defines the funds a smart contract can use on behalf of the +caller. This mechanism ensures that only an authorized amount of funds can be utilized in transactions. + +:::tip Dive Deeper + +You can gain a deeper understanding +of [accounts](/isc/explanations/how-accounts-work), [gas](/isc/explanations/invocation#gas) +and [allowance](/isc/explanations/invocation#allowance) in the [IOTA Smart Contracts](/isc/introduction) documentation. + +::: \ No newline at end of file diff --git a/docs/learn/smart-contracts/chain-owners-validators-and-access-nodes.md b/docs/learn/smart-contracts/chain-owners-validators-and-access-nodes.md new file mode 100644 index 00000000000..681249ca0b4 --- /dev/null +++ b/docs/learn/smart-contracts/chain-owners-validators-and-access-nodes.md @@ -0,0 +1,60 @@ +--- +description: Explore the roles of chain owners, validator nodes, and access nodes in the governance and operation of IOTA Smart Contracts. +image: /img/logo/WASP_logo_dark.png +tags: + - IOTA Smart Contracts + - Chain Owners + - Validator Nodes + - Access Nodes + - Blockchain Governance +--- + +# Chain Owners, Validators, and Access Nodes + +## TL;DR; + +- [Chain Owners](#chain-owners): As the primary governors of a chain, chain owners control validator committees and + dictate the chain's governance model. +- [Validator Nodes](#validator-nodes): Validator nodes are crucial for block production and achieving consensus on state + updates, with their composition managed by chain owners. +- [Access Nodes](#access-nodes): Access nodes, having only read access, are key for querying the chain's state and + managing external interactions with the blockchain. + +## Chain Owners + +Chain owners are the primary governing entities of a chain. They hold significant control over the chain, +including the power to manage the committee of validators. They can rotate [validators](#validator-nodes) to ensure the +chain's integrity and efficient operation. Chain owners establish and maintain the governance model of the chain, which +dictates how validators are selected and rewarded. + +## Validator Nodes + +Validator nodes are the workhorses of a blockchain, possessing write access and thus responsible for producing blocks. +These nodes form a committee that collaboratively runs smart contracts and reaches [consensus](consensus.md) on state +updates. Each validator plays their part in executing code, verifying the results, and committing these updates to the +chain. + +This process involves adding new blocks to the chain and updating the state hash in the Layer 1 (L1) +ledger. [Chain owners](#chain-owners) can change the composition of this committee , allowing for flexibility and +adaptability in the network's management. + +Often, validator nodes operate within a private subnet for security, with a designated group of access nodes serving as +the +interface with the external world. The management of both validator and access nodes is coordinated through +the [`governance` core contract](/isc/reference/core-contracts/governance/). + +## Access Nodes + +In contrast to [validator nodes](#validator-nodes), access nodes only have read access to the blockchain. They play a +crucial role in responding to queries about the chain's state and forwarding requests to the committee of validators. +These nodes provide external access to smart contracts, enabling queries +([view calls](smart-contract-execution.md#view-entry-points)) and the sending of +[off-ledger requests](smart-contract-execution.md#off-ledger-requests). + +:::tip Dive Deeper + +You can gain a deeper understanding +of [validators](/isc/explanations/validators#validators) and [access nodes](/isc/explanations/validators#access-nodes) +in the [IOTA Smart Contracts](/isc/introduction) documentation. + +::: \ No newline at end of file diff --git a/docs/learn/smart-contracts/consensus.md b/docs/learn/smart-contracts/consensus.md index 539e7c15adb..533d436e3b3 100644 --- a/docs/learn/smart-contracts/consensus.md +++ b/docs/learn/smart-contracts/consensus.md @@ -1,5 +1,5 @@ --- -description: IOTA Smart Contracts consensus is how Layer 2 validators agree to change the chain state in the same way. +description: An insightful overview of the consensus process in IOTA Smart Contracts, detailing the steps involved in updating the chain. image: /img/logo/WASP_logo_dark.png tags: - smart contracts @@ -8,46 +8,60 @@ tags: - validators - validator nodes - explanation + - state anchor --- # Consensus -To update the chain, its committee must reach a _consensus_, meaning that more than two thirds of its validators have to -agree to change the state in the exact same way. -This prevents a single malicious node from wreaking havoc over the chain, but there are also more mundane reasons for -individual nodes to act up. +## TL;DR; -Smart contracts are deterministic. All honest nodes will produce the same output — but only if they have received the -same input. Each validator node has its point of access to the Tangle, so it may look different to different nodes, as -new transactions take time to propagate through the network. Validator nodes will receive smart contract requests with -random delays in a random order, and, finally, all computers run on their own always slightly skewed clocks. +- [Introduction](#introduction): IOTA's Smart Contract protocol requires consensus among validators, with more than + two-thirds agreement needed for state changes. +- [1. Formulate the Batch Proposals](#1-formulate-the-batch-proposals): Validator nodes begin the consensus process with + batch proposals, requiring mutual agreement to ensure uniform inputs and results. +- [2. Agree On the Batch](#2-agree-on-the-batch): A finalized batch is created by filtering and ordering requests from + all proposals, safeguarding against manipulation. +- [3. Establish the State Anchor](#3-establish-the-state-anchor): Validators independently execute smart contract + requests to create a new block, followed by crafting a state anchor for Layer 1 transaction validation. -## Batch Proposals +## Introduction -As the first step, each node provides its vision, a _batch proposal_. The proposal contains a local timestamp, a list of -unprocessed requests, and the node's partial signature of the commitment to the current state. +In IOTA's Smart Contract protocol, updating the chain requires consensus +among [validator](chain-owners-validators-and-access-nodes.md) nodes. This means more than two-thirds of validators must +agree on any state change. This requirement is crucial for maintaining the chain's integrity and prevents any single +node from causing disruption. -Then the nodes must agree on which batch proposals they want to work on. In short, nodes A, B, and C have to confirm -that they plan to work on proposals from A, B, and C, and from no one else. As long as there are more than two thirds of -honest nodes, they will be able to find an _asynchronous common subset_ of the batch proposals. From that point, nodes -have the same input and will produce the same result independently. +Since smart contracts are deterministic, all honest nodes will yield identical results, provided they receive the same +input. However, variations in access points to the Tangle and the inherent randomness in receiving contract requests +can lead to different perspectives among nodes. -## The Batch +## 1. Formulate the Batch Proposals -The next step is to convert the raw list of batch proposals into an actual batch. All requests from all proposals are -counted and filtered to produce the same list of requests in the same order. -The partial signatures of all nodes are combined into a full signature that is then fed to a pseudo-random function that -sorts the smart contract requests. -Validator nodes can neither affect nor predict the final order of requests in the batch. (This protects ISC +The consensus process starts with each validator node presenting a batch proposal. This proposal includes a timestamp, a +list of pending requests, and the node's partial signature of its commitment to the current state. Nodes must +then mutually agree on a set of batch proposals to process. This agreement process ensures that a common subset of +proposals is selected, allowing nodes to work with identical inputs and, consequently, produce matching results. + +## 2. Agree On the Batch + +Transforming the selected batch proposals into a finalized batch involves counting and filtering requests from all +proposals. This method ensures uniformity in the order of requests. The combined partial signatures of all validators +create a full signature, which, through a pseudo-random function, determines the final sequence of requests. This step +is essential to guard against manipulation and predictability (shielding the system from [MEV attacks](https://ethereum.org/en/developers/docs/mev/)). -## State Anchor +## 3. Establish the State Anchor + +Once the input is agreed upon, each validator independently executes the smart contract requests, leading to the +creation of a new block. Subsequently, each node constructs a state anchor - a Layer 1 transaction attesting to the +commitment to this new state. The state anchor, bearing a timestamp derived from all batch proposals, is signed by all +validators. This unified signature guarantees that any validator can publish the transaction to Layer 1. Although state +anchors can be published after every update, they are typically released every ten seconds to minimize the load on the +Tangle. + +:::tip Dive Deeper -After agreeing on the input, each node executes every smart contract request in order, independently producing the same -new block. Each node then crafts a state anchor, a Layer 1 transaction that proves the commitment to this new chain -state. The timestamp for this transaction is derived from the timestamps of all batch proposals. +You can gain a deeper understanding of [consensus](/isc/explanations/consensus/) in +the [IOTA Smart Contracts](/isc/introduction) documentation. -All nodes then sign the state anchor with their partial keys and exchange these signatures. This way, every node obtains -the same valid combined signature and the same valid anchor transaction, which means that any node can publish this -transaction to Layer 1. In theory, nodes could publish these state anchors every time they update the state; in -practice, they do it only every approximately ten seconds to reduce the load on the Tangle. +::: \ No newline at end of file diff --git a/docs/learn/smart-contracts/introduction.md b/docs/learn/smart-contracts/introduction.md index b7b194d8749..b0c0085864b 100644 --- a/docs/learn/smart-contracts/introduction.md +++ b/docs/learn/smart-contracts/introduction.md @@ -4,11 +4,11 @@ all executing and validating the same code.' image: /img/banner/banner_wasp_core_concepts_smart_contracts.png tags: -- smart contracts -- blockchain -- parallel -- scaling -- explanation + - smart contracts + - blockchain + - parallel + - scaling + - explanation --- @@ -22,6 +22,36 @@ Smart contracts are software applications that run on a distributed network with validating the same code. This ensures the application behaves as expected and that there is no tampering in the program's execution. +### Smart Contract Applications Across Industries + +#### Voting Systems + +Smart contracts can revolutionize [voting systems](https://wiki.iota.org/learn/governance/governance-tech/) by offering +secure, transparent platforms for conducting elections. They ensure the integrity of the voting process, making it +tamper-proof, creating confidence in electoral systems. + +#### Decentralized Finance (DeFi) + +You can use smart contracts to automate complex financial processes like lending, borrowing, and asset trading, +eliminating the need for intermediaries, directly translating into reduced transaction costs and increased transaction +speeds. + +#### Supply Chain Management + +Smart contracts in supply chains provide real-time tracking and authentication of products from manufacturing to +delivery. They ensure transparency and compliance, enhancing trust between suppliers, retailers, and consumers. + +#### Real Estate Transactions + +In real estate, smart contracts streamline property sales by automating title transfers and payments, reducing paperwork +and expediting transactions. This digital approach simplifies the buying and selling process, making it more efficient +and secure. + +#### Intellectual Property and Royalties + +For artists and creators, smart contracts enable direct royalty payments, bypassing traditional intermediaries. This +system ensures fair compensation and transparent distribution of earnings in the music and entertainment industry. + ### Applications You Can Trust As you can be certain that the executed code is always the same (and will not change), this results in @@ -30,8 +60,7 @@ smart contract rules define what the contract can and can not do, making it a de decision-maker. You can use smart contracts for all kinds of purposes. A recurring reason to use a smart contract is to automate -specific -actions without needing a centralized entity to enforce this specific action. A good example is a smart contract +specific actions without needing a centralized entity to enforce this specific action. A good example is a smart contract that can exchange a certain amount of IOTA tokens for land ownership. The smart contract will accept both the IOTA tokens and the land ownership, and will predictably exchange them between both parties without the risk of one of the parties not delivering on their promise. **With a smart contract, code is law**. diff --git a/docs/learn/smart-contracts/isc-architecture.md b/docs/learn/smart-contracts/isc-architecture.md deleted file mode 100644 index 3b573e4f6bd..00000000000 --- a/docs/learn/smart-contracts/isc-architecture.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -description: An overview of the IOTA Smart Contracts architecture. -image: /img/multichain.png -tags: - - smart contracts - - architecture - - Layer 2 - - L2 - - Layer 1 - - L1 - - explanation ---- - -# ISC Architecture - -IOTA Smart Contracts work as a _layer 2_ (L2 for short) extension of the [_IOTA Multi-Asset -Ledger_](../protocols/stardust/core-concepts/multi-asset-ledger.md) (Layer 1, or L1 for short, also sometimes -called the UTXO Ledger). - -In IOTA Smart Contracts, each L2 chain has its own state and smart contracts that cause this state to change. -As validator nodes execute the smart contracts, they tally these state changes and write them into the chain. -Each time they update the state, they collectively agree on a new state and commit to it by publishing its hash to L1. - -Each Layer 2 chain is functionally similar to a traditional blockchain. -However, ISC chains can communicate with Layer 1 and each other, making ISC a more sophisticated protocol. - -![IOTA Smart Contacts multichain architecture](/img/multichain.png 'Click to see the full-size image.') - -_IOTA Smart Contacts multichain architecture._ - -You can find the comprehensive overview of architectural design decisions of IOTA Smart Contracts in the -[ISC white paper](https://files.iota.org/papers/ISC_WP_Nov_10_2021.pdf). diff --git a/docs/learn/smart-contracts/protocol-overview.md b/docs/learn/smart-contracts/protocol-overview.md new file mode 100644 index 00000000000..2d147683416 --- /dev/null +++ b/docs/learn/smart-contracts/protocol-overview.md @@ -0,0 +1,68 @@ +--- +description: An overview of the ISC Protocol, detailing the function and interaction of smart contracts, virtual machines, validators, state, and blockchains in IOTA. +image: /img/logo/WASP_logo_dark.png +tags: + - ISC Protocol + - IOTA Smart Contracts + - Virtual Machines + - Validators + - Blockchain Technology +--- + +# ISC Protocol Overview + +## TL;DR; + +- [Smart Contracts](#smart-contracts): Digital programs on a blockchain, written in various programming languages, + compiled into bytecode and executed by virtual machines. +- [Virtual Machines](#virtual-machines): Essential engines that run smart contracts, process inputs, and enforce rules, + with IOTA supporting EVM and WASM VM. +- [Validators](#validators): Key network components operating virtual machines, managing blockchain state and history, + and facilitating smart contract execution. +- [State](#state): The dynamic data interacted with and altered by smart contracts, forming the blockchain's historical + record. +- [Blockchains](#blockchains): Structures of linked blocks containing state updates, representing the chain’s history + and enabling parallel smart contract execution. + +## Smart Contracts + +Smart contracts are like digital programs on a blockchain, consisting of functions that either view or update the +blockchain's state based on given inputs. They are versatile, written in languages like Solidity, Rust, or Go, and are +compiled into bytecode. This bytecode is then executed by a [virtual machine](#virtual-machines), acting as the +blockchain's engine to process these contracts. + +## Virtual Machines + +Virtual machines, operated by [Validators](#validators), are the execution engines of smart contracts that understand smart contract bytecode and are able compute state changes. They take the +current [state](#state) of the [blockchain](#blockchains) and the inputs from users, execute the smart contract's +bytecode, and produce a new state. These machines also set rules and restrictions for smart contracts, ensuring secure +and orderly operation. The IOTA architecture currently supports two types of virtual machines: + +* The production-ready EVM (Ethereum Virtual Machine) +* The **experimental** WASM VM (WebAssembly Virtual Machine). + +## Validators + +Validators are critical components in a blockchain network. They operate the virtual machines and are responsible for +storing the [state](accounts-addresses-and-fees.md) and history of the blockchain. Validators process requests to run +smart contracts, +achieve consensus on state updates, and create a blockchain that represents the history of said state updates. + +## State + +The state in a [blockchain](#blockchains) is a key-value store that smart contracts interact with and modify. It's a result of smart contract execution, committed in blocks, forming a blockchain representing the history of state updates leading to the current state. + +## Blockchains + +Blockchains in IOTA are structures composed of blocks linked cryptographically, containing [state](#state) updates. They +chronicle the history of all updates leading to the current state. Chain owners own these blockchains which are produced +by validators. These blockchains are anchored in the IOTA ledger, allowing for parallel anchoring of chains and enabling +simultaneous execution of smart contracts across different chains. + +:::tip Dive Deeper + +You can gain a deeper understanding +of [validators](/isc/explanations/validators#validators) and [access nodes](/isc/explanations/validators#access-nodes) +in the [IOTA Smart Contracts](/isc/introduction) documentation. + +::: \ No newline at end of file diff --git a/docs/learn/smart-contracts/smart-contract-execution.md b/docs/learn/smart-contracts/smart-contract-execution.md new file mode 100644 index 00000000000..0ffc5024645 --- /dev/null +++ b/docs/learn/smart-contracts/smart-contract-execution.md @@ -0,0 +1,79 @@ +--- +description: An in-depth exploration of smart contract execution in blockchain technology, detailing their structure, invocation, and associated fees. +image: /img/logo/WASP_logo_dark.png +keywords: +- Smart Contracts +- Blockchain Technology +- Validators +- User Requests +- Gas Fees +--- + +# Smart Contract Execution + +## TL;DR; + +- [Introduction](#introduction): Smart contracts are programs run by [validators](chain-owners-validators-and-access-nodes.md#validator-nodes) upon requests. +- [Structure of a Smart Contract](#structure-of-a-smart-contract): Comprising functions within a decentralized framework, smart contracts have a unique state and accounts, managed by validator node consensus. +- [View Entry Points](#view-entry-points): Read-only operations in smart contracts that do not modify data or incur execution fees. +- [Full Entry Points](#full-entry-points): Functions that can alter a contract's state and typically require execution fees. +- [Invoking a Smart Contract](#invoking-a-smart-contract): Activation of smart contracts through requests, which can be off-ledger or on-ledger, with associated gas fees for computational resources. + +## Introduction + +Smart contracts are essentially programs run by a network of nodes upon requests. Network nodes, also known as +[Validators](chain-owners-validators-and-access-nodes.md) activate these contracts in response to specific [user requests](#invoking-a-smart-contract). + +## Structure of a Smart Contract + +At it's core a smart contract is a collection of functions, much like a traditional computer program. However, they operate +within the blockchain’s decentralized framework, meaning that a network of [validator nodes](chain-owners-validators-and-access-nodes.md) run the exact +same code and come to a [consensus](consensus.md) on the next [state](accounts-addresses-and-fees.md) update. + +Every smart contract has its unique state, which is essentially a collection of data stored as key-value pairs. This +state is only modifiable by the contract's functions, ensuring secure and controlled interactions. Additionally, smart +contracts possess their own accounts within the blockchain, representing their token balances. This structure allows +them to interact with and manage digital assets autonomously. + +### View Entry Points + +View entry points, or functions, are read-only operations that do not alter the contract's data; therefore, they do not incur +any execution fees. + +### Full Entry Points + +Full entry points, or functions, can modify the contract's state and typically require fees to execute. +These fees compensate for the computational resources used in processing the functions. + +## Invoking a Smart Contract + +To activate or 'invoke' a smart contract, users, or other contracts, send requests to the chain. These requests are +calls to the contract’s functions and must be cryptographically signed to ensure security and authenticity. +The type of request determines how it is processed: + +### Off-Ledger Requests + +Off-ledger requests are directly sent to the blockchain's validator nodes, bypassing the main ledger. This type of +request is faster as it avoids the additional processing time of the main ledger but is typically used when the +necessary assets are already within the blockchain’s ecosystem. + +### On-Ledger Requests + +On-ledger requests, on the other hand, pass through the blockchain's main ledger. While slower due to the ledger’s +processing, these requests are essential for transactions that involve transferring assets across different chains or +accounts. The blockchain’s ledger, like the Tangle in IOTA's case, acts as a mediator in these transactions, ensuring +validity and security. + +### Fees and Gas + +Running a request on a blockchain involves computational resources, for which users must compensate. This compensation, +known as 'gas', varies depending on the complexity and size of the request. Users specify a `GasBudget` + + +:::tip Dive Deeper + +You can gain a deeper understanding +of [ISC Architecture](/isc/introduction#isc-architecture) and [smart contract invocation](/isc/explanations/invocation/) +in the [IOTA Smart Contracts](/isc/introduction) documentation. + +::: \ No newline at end of file diff --git a/docs/learn/smart-contracts/state-management-and-anchoring.md b/docs/learn/smart-contracts/state-management-and-anchoring.md new file mode 100644 index 00000000000..86c2d13d232 --- /dev/null +++ b/docs/learn/smart-contracts/state-management-and-anchoring.md @@ -0,0 +1,59 @@ +--- +description: An overview of state management and anchoring in IOTA Smart Contracts, detailing how blockchain state and digital assets are handled and secured. +image: /img/logo/WASP_logo_dark.png +tags: + - IOTA Smart Contracts + - State Management + - Blockchain Technology + - Digital Assets + - Anchoring Process +--- + +# State Management and Anchoring + +## TL;DR; + +- [Introduction](#introduction): In IOTA Smart Contracts, 'state' represents the chain's current status, including data + and digital assets, updated via blockchain blocks. +- [Digital Assets](#digital-assets): Digital assets in IOTA are managed by Layer 1 addresses, with each smart contract + chain having a unique address to act as a custodian. +- [Data](#data): The data state comprises key/value pairs managed outside the UTXO ledger by validator nodes, ensuring + data consistency and traceability. +- [Anchoring](#anchoring): The anchoring process embeds the data state hash into the L1 ledger, creating a tamper-proof + record and ensuring a globally consistent state. + +## Introduction + +In IOTA Smart Contracts, the 'state' represents the current status of the chain, including its data and digital assets. +This state is updated through blocks that form an immutable blockchain. Each block contains changes or mutations, +leading to a new state. + +## Digital Assets + +Digital assets in IOTA are controlled by addresses on the Layer 1 (L1) IOTA UTXO ledger. Each smart contract chain has a +unique L1 address acting as a custodian for these assets, which include base tokens, native tokens, and NFTs. These +assets are consolidated within the chain's account, and their movements are tracked as part of the chain's state +changes. + +## Data + +The data state of an IOTA chain comprises key/value pairs maintained outside the UTXO ledger in a distributed database +managed by validator nodes. This database contains the 'solid state', while the 'virtual state' is an in-memory +collection during smart contract execution. The data state is defined by its hash, timestamp, and index, ensuring +consistency and traceability of changes. + +## Anchoring + +Anchoring is the process of embedding the hash of the data state into a state UTXO on the L1 ledger, providing a +tamper-proof record. This mechanism ensures that there is global consensus on the chain’s state, which is both immutable +and consistent. The state transition in the chain occurs via a transaction that updates both the chain's assets and the +state hash, represented as a sequence of UTXOs on the L1 ledger. + +:::tip Dive Deeper + +You can gain a deeper understanding +of [on-chain digital assets](/isc/explanations/states/#digital-assets-on-the-chain), and +the [data state](/isc/explanations/states/#the-data-state) in the [IOTA Smart Contracts](/isc/introduction) +documentation. + +::: \ No newline at end of file diff --git a/docs/maintain/getting-started/welcome.md b/docs/maintain/getting-started/welcome.md index b5e2718a22a..eca234017a2 100644 --- a/docs/maintain/getting-started/welcome.md +++ b/docs/maintain/getting-started/welcome.md @@ -21,7 +21,7 @@ messages and data in real time. ### WASP - IOTA Smart Contracts -[WASP](/wasp/running-a-node) is an INX plugin you can install and use to run your smart contract chain. -You can use the documentation to get your node up and running, and [set up](/wasp-cli/how-tos/setting-up-a-chain/) and -[manage](/wasp-cli/how-tos/chain-management) a chain, or check out the available -[configuration options](/wasp/configuration). +[WASP](/wasp/how-tos/running-a-node) is an INX plugin you can install and use to run your smart contract chain. +You can use the documentation to get your node up and running, and [set up](/wasp/how-tos/setting-up-a-chain/) and +[manage](/wasp/how-tos/chain-management) a chain, or check out the available +[configuration options](/wasp/reference/configuration). 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 273b52b2884..b5b9eb77645 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 @@ -122,7 +122,7 @@ You can configure your node to either use HTTP or HTTPS. For publicly exposed no :::info -Activating a Wasp node isn't enough to fully participate in a smart contract chain. You don't need a standalone Wasp node if you're using our ShimmerEVM chain. For setting up your own chain, see our guide for the required steps: [Set Up a Chain](/wasp-cli/how-tos/setting-up-a-chain/) +Activating a Wasp node isn't enough to fully participate in a smart contract chain. You don't need a standalone Wasp node if you're using our ShimmerEVM chain. For setting up your own chain, see our guide for the required steps: [Set Up a Chain](/wasp/how-tos/setting-up-a-chain/) ::: diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/chain-management.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md similarity index 96% rename from docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/chain-management.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md index 9c1f0e2421f..b6273d1dd93 100644 --- a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/chain-management.md +++ b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md @@ -20,7 +20,7 @@ You can view the chain state using the dashboard (`/wasp/dashboard` when us ## Manage Chain Configuration and Validators You can manage the chain configuration and committee of validators by interacting with -the [Governance contract](/wasp-wasm/reference/core-contracts/governance/). +the [Governance contract](/isc/reference/core-contracts/governance). The “Chain Owner” is the only one who can perform administrative tasks. diff --git a/docs/maintain/wasp/v1.0.0-rc.6/docs/running-a-node.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/running-a-node.md similarity index 100% rename from docs/maintain/wasp/v1.0.0-rc.6/docs/running-a-node.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/running-a-node.md diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md similarity index 96% rename from docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md index 3ca1c580a71..4afeae67648 100644 --- a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md +++ b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md @@ -83,7 +83,7 @@ From now on, all chain commands will target this chain. The `--quorum` flag indicates the minimum number of nodes required to form a _consensus_. The recommended formula to obtain this number is `floor(N*2/3)+1` where `N` is the number of nodes in your committee. -The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog) core contract. +The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](/isc/reference/core-contracts/blocklog) core contract. After deployment, the chain must be activated by the node operators of all peers. @@ -95,7 +95,7 @@ wasp-cli chain activate --chain= ## Test If It Works You can check that the chain was deployed correctly in the Wasp node dashboard (`/wasp/dashboard` when using `node-docker-setup`). -Note that the chain was deployed with some [core contracts](/wasp-wasm/reference/core-contracts/overview). +Note that the chain was deployed with some [core contracts](/isc/reference/core-contracts/overview). You should also have an EVM-JSONRPC server opened on: diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/wasp-cli.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/wasp-cli.md similarity index 100% rename from docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/wasp-cli.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/wasp-cli.md diff --git a/docs/maintain/wasp/v1.0.0-rc.6/docs/configuration.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/reference/configuration.md similarity index 100% rename from docs/maintain/wasp/v1.0.0-rc.6/docs/configuration.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/reference/configuration.md diff --git a/docs/maintain/wasp/v1.0.0-rc.6/docs/metrics.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/reference/metrics.md similarity index 100% rename from docs/maintain/wasp/v1.0.0-rc.6/docs/metrics.md rename to docs/maintain/wasp/v1.0.0-rc.6/docs/reference/metrics.md diff --git a/docs/maintain/wasp/v1.0.0-rc.6/sidebars.js b/docs/maintain/wasp/v1.0.0-rc.6/sidebars.js index 2a7b08b09e7..2613c40e80b 100644 --- a/docs/maintain/wasp/v1.0.0-rc.6/sidebars.js +++ b/docs/maintain/wasp/v1.0.0-rc.6/sidebars.js @@ -14,18 +14,47 @@ module.exports = { //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], // But you can create a sidebar manually - tutorialSidebar: [ + waspSidebar: [ { - type: 'doc', - id: 'running-a-node', + type: 'category', + label: 'How To', + collapsed: false, + items: [ + { + type: 'doc', + id: 'how-tos/running-a-node', + label: 'Run a Node', + }, + { + id: 'how-tos/wasp-cli', + label: 'Configure wasp-cli', + type: 'doc', + }, + { + id: 'how-tos/setting-up-a-chain', + label: 'Set Up a Chain', + type: 'doc', + }, + { + id: 'how-tos/chain-management', + label: 'Manage a Chain', + type: 'doc', + }, + ], }, { - type: 'doc', - id: 'configuration', - }, - { - type: 'doc', - id: 'metrics', + type: 'category', + label: 'Reference', + items: [ + { + type: 'doc', + id: 'reference/configuration', + }, + { + type: 'doc', + id: 'reference/metrics', + }, + ], }, ], }; diff --git a/src/components/HomeLayout/AppLibrariesSection.tsx b/src/components/HomeLayout/AppLibrariesSection.tsx index 8184ac5e19d..c2b03f7880a 100644 --- a/src/components/HomeLayout/AppLibrariesSection.tsx +++ b/src/components/HomeLayout/AppLibrariesSection.tsx @@ -118,7 +118,7 @@ const LibrariesSection: FC = () => (

Learn about ISC diff --git a/src/components/HomeLayout/index.tsx b/src/components/HomeLayout/index.tsx index a904a9494bc..93d79f53f17 100644 --- a/src/components/HomeLayout/index.tsx +++ b/src/components/HomeLayout/index.tsx @@ -183,7 +183,7 @@ export default function HomeLayout() { smart contract chain using the IOTA Smart Contracts protocol.

Run a smart contract node diff --git a/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png b/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png new file mode 100644 index 00000000000..b28fbcc2e71 Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png differ diff --git a/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png b/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png new file mode 100644 index 00000000000..951f4005e76 Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png differ diff --git a/static/img/evm/how-tos/ERC20/metamask-import-tokens.png b/static/img/evm/how-tos/ERC20/metamask-import-tokens.png new file mode 100644 index 00000000000..65cc8c9774d Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-import-tokens.png differ diff --git a/static/img/evm/how-tos/ERC721/confirm-in-metamask.png b/static/img/evm/how-tos/ERC721/confirm-in-metamask.png new file mode 100644 index 00000000000..7aad835f29e Binary files /dev/null and b/static/img/evm/how-tos/ERC721/confirm-in-metamask.png differ diff --git a/static/img/evm/how-tos/ERC721/safe-mint.png b/static/img/evm/how-tos/ERC721/safe-mint.png new file mode 100644 index 00000000000..791d5c84d2a Binary files /dev/null and b/static/img/evm/how-tos/ERC721/safe-mint.png differ diff --git a/static/img/evm/how-tos/ERC721/set-initial-owner.png b/static/img/evm/how-tos/ERC721/set-initial-owner.png new file mode 100644 index 00000000000..592e19313cc Binary files /dev/null and b/static/img/evm/how-tos/ERC721/set-initial-owner.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/bloom-click-on-send.png b/static/img/evm/how-tos/get-funds/bloom/bloom-click-on-send.png new file mode 100644 index 00000000000..864667657d3 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/bloom-click-on-send.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/bloom-review-and-confirm.png b/static/img/evm/how-tos/get-funds/bloom/bloom-review-and-confirm.png new file mode 100644 index 00000000000..8923e3ed326 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/bloom-review-and-confirm.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/bloom-select-evm-account-1.png b/static/img/evm/how-tos/get-funds/bloom/bloom-select-evm-account-1.png new file mode 100644 index 00000000000..4938d9a7eed Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/bloom-select-evm-account-1.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/bloom-select-the-desired-amount.png b/static/img/evm/how-tos/get-funds/bloom/bloom-select-the-desired-amount.png new file mode 100644 index 00000000000..1d150b3153c Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/bloom-select-the-desired-amount.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/enter-the-amount.png b/static/img/evm/how-tos/get-funds/bloom/enter-the-amount.png new file mode 100644 index 00000000000..e8bce3628e1 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/enter-the-amount.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/enter-the-recipient-address.png b/static/img/evm/how-tos/get-funds/bloom/enter-the-recipient-address.png new file mode 100644 index 00000000000..8e52db75ffd Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/enter-the-recipient-address.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/review-and-confirm-the-transaction.png b/static/img/evm/how-tos/get-funds/bloom/review-and-confirm-the-transaction.png new file mode 100644 index 00000000000..40e020cfe60 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/review-and-confirm-the-transaction.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/select-send.png b/static/img/evm/how-tos/get-funds/bloom/select-send.png new file mode 100644 index 00000000000..3fc42fcdce5 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/select-send.png differ diff --git a/static/img/evm/how-tos/get-funds/bloom/select-the-smr-token.png b/static/img/evm/how-tos/get-funds/bloom/select-the-smr-token.png new file mode 100644 index 00000000000..46a1d2ed2fe Binary files /dev/null and b/static/img/evm/how-tos/get-funds/bloom/select-the-smr-token.png differ diff --git a/static/img/evm/how-tos/get-funds/copy-your-address.png b/static/img/evm/how-tos/get-funds/copy-your-address.png new file mode 100644 index 00000000000..00238e8d01c Binary files /dev/null and b/static/img/evm/how-tos/get-funds/copy-your-address.png differ diff --git a/static/img/evm/how-tos/get-funds/firefly/enter-your-desired-amount-and-metamask-address.png b/static/img/evm/how-tos/get-funds/firefly/enter-your-desired-amount-and-metamask-address.png new file mode 100644 index 00000000000..fc41573393d Binary files /dev/null and b/static/img/evm/how-tos/get-funds/firefly/enter-your-desired-amount-and-metamask-address.png differ diff --git a/static/img/evm/how-tos/get-funds/firefly/hit-send.png b/static/img/evm/how-tos/get-funds/firefly/hit-send.png new file mode 100644 index 00000000000..45599074ccc Binary files /dev/null and b/static/img/evm/how-tos/get-funds/firefly/hit-send.png differ diff --git a/static/img/evm/how-tos/get-funds/firefly/select-send-assets.png b/static/img/evm/how-tos/get-funds/firefly/select-send-assets.png new file mode 100644 index 00000000000..22327dbb652 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/firefly/select-send-assets.png differ diff --git a/static/img/evm/how-tos/get-funds/firefly/select-shimmer-evm.png b/static/img/evm/how-tos/get-funds/firefly/select-shimmer-evm.png new file mode 100644 index 00000000000..f1a3b2dcfd0 Binary files /dev/null and b/static/img/evm/how-tos/get-funds/firefly/select-shimmer-evm.png differ diff --git a/static/img/evm/ozw-721.png b/static/img/evm/ozw-721.png deleted file mode 100644 index fc875e06c63..00000000000 Binary files a/static/img/evm/ozw-721.png and /dev/null differ diff --git a/static/img/evm/remix-721-deploy.png b/static/img/evm/remix-721-deploy.png deleted file mode 100644 index fd877ac1659..00000000000 Binary files a/static/img/evm/remix-721-deploy.png and /dev/null differ diff --git a/static/img/evm/remix-721.png b/static/img/evm/remix-721.png deleted file mode 100644 index 56a1a453441..00000000000 Binary files a/static/img/evm/remix-721.png and /dev/null differ diff --git a/static/img/evm/remix-injected-provider-metamask.png b/static/img/evm/remix-injected-provider-metamask.png new file mode 100644 index 00000000000..425d9a9dcc4 Binary files /dev/null and b/static/img/evm/remix-injected-provider-metamask.png differ diff --git a/static/img/evm/remix-injected-provider-set.png b/static/img/evm/remix-injected-provider-set.png new file mode 100644 index 00000000000..9dddccb2fb4 Binary files /dev/null and b/static/img/evm/remix-injected-provider-set.png differ diff --git a/tutorials/docusaurus.config.js b/tutorials/docusaurus.config.js index 95cf438aad0..8579dc6c807 100644 --- a/tutorials/docusaurus.config.js +++ b/tutorials/docusaurus.config.js @@ -16,7 +16,7 @@ module.exports = { title: 'Run a Wasp Node', description: 'In this tutorial you will learn how to run a wasp node.', preview: '/IOTA-Smart-Contract-Tutorials-A.jpg', - route: '/wasp/running-a-node', + route: '/wasp/how-tos/running-a-node', tags: ['text', 'video'], }, ], @@ -26,7 +26,7 @@ module.exports = { title: 'Run a Wasp Chain', description: 'In this tutorial you will learn how to run a wasp chain.', preview: '/IOTA-Smart-Contract-Tutorials-B.jpg', - route: '/wasp-cli/how-tos/setting-up-a-chain', + route: '/wasp/how-tos/setting-up-a-chain', tags: ['text', 'video'], }, ], @@ -37,7 +37,7 @@ module.exports = { description: 'In this tutorial you will learn how to deploy a wasm smart contract.', preview: '/IOTA-Smart-Contract-Tutorials-C.jpg', - route: '/wasp-cli/how-tos/setting-up-a-chain#deploying-a-wasm-contract', + route: '/wasp/how-tos/setting-up-a-chain#deploying-a-wasm-contract', tags: ['text', 'video'], }, ], @@ -48,7 +48,7 @@ module.exports = { description: 'In this tutorial you will learn how to deploy a solidity smart contract on EVM using remix and metamask.', preview: '/IOTA-Smart-Contract-Tutorials-E.jpg', - route: '/wasp-evm/getting-started/compatible-tools#remix', + route: '/isc/getting-started/tools#remix', tags: ['text', 'video'], }, ], @@ -59,7 +59,7 @@ module.exports = { description: 'In this tutorial you will learn how to use schema tool to generate smart contract template code on rust and golang', preview: '/IOTA-Smart-Contract-Tutorials-G.png', - route: '/wasp-wasm/how-tos/schema-tool/usage', + route: '/isc/schema/how-tos/usage', tags: ['text', 'video'], }, ], diff --git a/tutorials/pages/shimmerevm-dapp-voting.md b/tutorials/pages/shimmerevm-dapp-voting.md index d55207ddd5d..88a3e027241 100644 --- a/tutorials/pages/shimmerevm-dapp-voting.md +++ b/tutorials/pages/shimmerevm-dapp-voting.md @@ -283,7 +283,7 @@ Please make a note of the ABI while you're compiling it. You will need it later. Most of the front end is design work which is not the focus of this tutorial, so let's jump to the js part. You can use [this project](https://github.com/anistark/smart-contracts-demo/tree/main/voting) if you're looking for a ready design to get started. Feel free to make changes to the design to suit your needs. -We will also use [Metamask](/wasp-evm/getting-started/compatible-tools) in this section, so please ensure you have installed and logged in to Metamask. +We will also use [Metamask](/isc/getting-started/tools) in this section, so please ensure you have installed and logged in to Metamask. The first thing you need to do is check that Metamask is accessible from your dApp: ```javascript! diff --git a/versionedConfig.js b/versionedConfig.js index 8c7dc46cfea..8c91a6b3ae3 100644 --- a/versionedConfig.js +++ b/versionedConfig.js @@ -20,35 +20,9 @@ exports.buildPluginsConfig = [ ], }, { - id: 'wasp-evm', - label: 'EVM', - description: 'Create EVM smart contracts.', - icon: 'SmartContracts', - subsection: 'build-layer-2', - versions: [ - { - label: 'v1.0.0-rc.6', - badges: ['Shimmer'], - }, - ], - }, - { - id: 'wasp-cli', - label: 'Wasp CLI', - description: 'Create custom smart contract chains.', - icon: 'SmartContracts', - subsection: 'build-layer-2', - versions: [ - { - label: 'v1.0.0-rc.6', - badges: ['Shimmer'], - }, - ], - }, - { - id: 'wasp-wasm', - label: 'WASM (Experimental)', - description: 'Create WASM smart contracts.', + id: 'isc', + label: 'Smart Contracts', + description: 'Create Smart Contracts.', icon: 'SmartContracts', subsection: 'build-layer-2', versions: [