From 136ca6e9c8ef9a60a1b87bd8cf3f0b94487d1617 Mon Sep 17 00:00:00 2001 From: Lucas Tortora Date: Tue, 23 Jan 2024 10:45:45 -0300 Subject: [PATCH] re-merge EVM and WASM --- docs/build/getting-started/sidebars.ts | 4 +- docs/build/getting-started/welcome.md | 2 +- .../docs/_admonitions/_about-accounts.md | 5 + .../explanations/accounts-and-addresses.md | 99 ----- .../docs/explanations/consensus.md | 53 +++ .../v1.0.0-rc.6/docs/explanations/context.mdx | 0 .../docs/explanations/core-contracts.md | 14 +- .../docs/explanations/how-accounts-work.md | 15 +- .../docs/explanations/invocation.md | 111 ++++++ .../docs/explanations/isc-architecture.md | 32 ++ .../v1.0.0-rc.6/docs/explanations/proxies.mdx | 10 +- .../v1.0.0-rc.6/docs/explanations/sandbox.md | 45 +++ .../explanations/smart-contract-anatomy.md | 80 ++++ .../docs/explanations/smart-contracts.md | 54 +++ .../docs/explanations/state_manager.md | 209 ++++++++++ .../v1.0.0-rc.6/docs/explanations/states.md | 122 ++++++ .../docs/explanations/validators.md | 49 +++ .../docs/getting-started/compatibility.md | 10 +- .../docs/getting-started/languages-and-vms.md | 47 ++- .../getting-started/networks-and-chains.md | 136 ------- .../getting-started/networks-and-chains.mdx | 54 +++ .../docs/getting-started/quick-start.mdx} | 4 +- .../v1.0.0-rc.6/docs/getting-started/tools.md | 2 +- .../v1.0.0-rc.6/docs/how-tos/EVM}/ERC20.md | 4 +- .../v1.0.0-rc.6/docs/how-tos/EVM}/ERC721.md | 2 +- .../how-tos/EVM}/create-a-basic-contract.md | 0 .../v1.0.0-rc.6/docs/how-tos/EVM}/using.md | 2 +- .../manage-chains}/chain-management.md | 2 +- .../manage-chains}/setting-up-a-chain.md | 4 +- .../docs/how-tos/manage-chains}/wasp-cli.md | 0 .../docs/how-tos/solo/deploying-sc.md | 2 +- .../docs/how-tos/solo/error-handling.md | 2 +- .../docs/how-tos/solo/examples.mdx | 12 +- .../docs/how-tos/solo/first-example.md | 6 +- .../docs/how-tos/solo/invoking-sc.md | 0 .../v1.0.0-rc.6/docs/how-tos/solo/test.mdx | 16 +- .../docs/how-tos/solo/the-l1-ledger.md | 0 .../docs/how-tos/solo/the-l2-ledger.md | 6 +- .../docs/how-tos/solo/timelock.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/solo/view-sc.md | 2 +- .../docs/how-tos/solo/what-is-solo.md | 2 - .../deposit-to-a-chain.mdx | 5 +- .../how-tos/use-the-magic-contract}/magic.md | 23 ++ .../send-tokens-to-l1.mdx} | 3 + .../view-account-balances.mdx | 4 +- .../withdraw-from-a-chain.mdx | 4 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/access.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/call.mdx | 0 .../v1.0.0-rc.6/docs/how-tos/wasm}/events.mdx | 0 .../docs/how-tos/wasm}/funcdesc.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/funcs.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/init.mdx | 0 .../docs/how-tos/wasm}/introduction.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/params.mdx | 4 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/post.mdx | 0 .../docs/how-tos/wasm}/results.mdx | 4 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/spec.mdx | 0 .../v1.0.0-rc.6/docs/how-tos/wasm}/state.mdx | 2 +- .../docs/how-tos/wasm}/structs.mdx | 6 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/thunks.mdx | 6 +- .../docs/how-tos/wasm}/transfers.mdx | 0 .../docs/how-tos/wasm}/typedefs.mdx | 6 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/usage.mdx | 0 .../v1.0.0-rc.6/docs/how-tos/wasm}/views.mdx | 2 +- .../v1.0.0-rc.6/docs/how-tos/wasm}/yaml.mdx | 0 .../isc/v1.0.0-rc.6/docs/introduction.md | 113 ++---- .../docs/reference/core-contracts/accounts.md | 0 .../docs/reference/core-contracts/blob.md | 0 .../docs/reference/core-contracts/blocklog.md | 2 +- .../docs/reference/core-contracts/errors.md | 0 .../docs/reference/core-contracts/evm.md | 4 +- .../reference/core-contracts/governance.md | 0 .../docs/reference/core-contracts/overview.md | 0 .../docs/reference/core-contracts/root.md | 0 .../docs/reference/core-contracts/xfer.md | 0 .../docs/reference/json-rpc-spec.md | 0 .../docs/reference/magic-contract.md | 26 ++ .../docs/reference/wasm-lib-data-types.mdx} | 14 +- docs/build/isc/v1.0.0-rc.6/sidebars.js | 352 ++++++++++++++++- docs/build/wasp-cli/v1.0.0-rc.6/sidebars.js | 41 -- .../docs/getting-started/compatibility.md | 101 ----- .../docs/getting-started/compatible-tools.md | 136 ------- .../how-tos/magic-contract/call-a-function.md | 22 -- .../magic-contract/call-a-native-contract.md | 25 -- .../docs/how-tos/view-account-balances.mdx | 170 -------- .../wasp-evm/v1.0.0-rc.6/docs/introduction.md | 51 --- .../docs/reference/core-contracts/blocklog.md | 202 ---------- .../docs/reference/core-contracts/evm.md | 170 -------- docs/build/wasp-evm/v1.0.0-rc.6/sidebars.js | 177 --------- .../docs/explanations/how-accounts-work.md | 99 ----- .../docs/how-tos/deposit-to-a-chain.mdx | 78 ---- .../docs/how-tos/withdraw-from-a-chain.mdx | 60 --- .../v1.0.0-rc.6/docs/introduction.mdx | 71 ---- .../docs/reference/core-contracts/accounts.md | 365 ------------------ .../docs/reference/core-contracts/blob.md | 108 ------ .../docs/reference/core-contracts/errors.md | 77 ---- .../reference/core-contracts/governance.md | 355 ----------------- .../docs/reference/core-contracts/overview.md | 37 -- .../docs/reference/core-contracts/root.md | 121 ------ .../docs/reference/core-contracts/xfer.md | 71 ---- .../wasp-wasm/v1.0.0-rc.6/docs/testnet.md | 51 --- docs/build/wasp-wasm/v1.0.0-rc.6/sidebars.js | 283 -------------- docs/learn/smart-contracts/invocation.md | 2 +- docs/learn/smart-contracts/sandbox.md | 4 +- .../smart-contracts/smart-contract-anatomy.md | 8 +- docs/learn/smart-contracts/validators.md | 2 +- docs/maintain/getting-started/welcome.md | 4 +- .../HomeLayout/AppLibrariesSection.tsx | 2 +- tutorials/docusaurus.config.js | 9 +- tutorials/pages/shimmerevm-dapp-voting.md | 2 +- versionedConfig.js | 78 ++-- 111 files changed, 1441 insertions(+), 3350 deletions(-) create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_about-accounts.md delete mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/accounts-and-addresses.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/consensus.md rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/explanations/context.mdx (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/explanations/how-accounts-work.md (87%) create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/isc-architecture.md rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/explanations/proxies.mdx (86%) create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md delete mode 100644 docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.md create mode 100644 docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.mdx rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/getting-started/quickstart.mdx => isc/v1.0.0-rc.6/docs/getting-started/quick-start.mdx} (94%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/EVM}/ERC20.md (94%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/EVM}/ERC721.md (98%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/EVM}/create-a-basic-contract.md (100%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/EVM}/using.md (94%) rename docs/build/{wasp-cli/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/manage-chains}/chain-management.md (96%) rename docs/build/{wasp-cli/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/manage-chains}/setting-up-a-chain.md (96%) rename docs/build/{wasp-cli/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/manage-chains}/wasp-cli.md (100%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md (96%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md (93%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx (94%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/first-example.md (94%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/invoking-sc.md (100%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/test.mdx (87%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/the-l1-ledger.md (100%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md (95%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx (98%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md (96%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md (96%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract}/deposit-to-a-chain.mdx (89%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract => isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract}/magic.md (69%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/send-tokens-to-l1.md => isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/send-tokens-to-l1.mdx} (92%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract}/view-account-balances.mdx (97%) rename docs/build/{wasp-evm/v1.0.0-rc.6/docs/how-tos => isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract}/withdraw-from-a-chain.mdx (93%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/access.mdx (92%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/call.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/events.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/funcdesc.mdx (98%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/funcs.mdx (98%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/init.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/introduction.mdx (99%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/params.mdx (93%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/post.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/results.mdx (92%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/spec.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/state.mdx (99%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/structs.mdx (97%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/thunks.mdx (97%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/transfers.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/typedefs.mdx (97%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/usage.mdx (100%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/views.mdx (98%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool => isc/v1.0.0-rc.6/docs/how-tos/wasm}/yaml.mdx (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/blob.md (100%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md (98%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/errors.md (100%) rename docs/build/{wasp-wasm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/evm.md (97%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/governance.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/overview.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/root.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/json-rpc-spec.md (100%) rename docs/build/{wasp-evm => isc}/v1.0.0-rc.6/docs/reference/magic-contract.md (71%) rename docs/build/{wasp-wasm/v1.0.0-rc.6/docs/reference/data-types/types.mdx => isc/v1.0.0-rc.6/docs/reference/wasm-lib-data-types.mdx} (88%) delete mode 100644 docs/build/wasp-cli/v1.0.0-rc.6/sidebars.js delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-function.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-native-contract.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/introduction.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md delete mode 100644 docs/build/wasp-evm/v1.0.0-rc.6/sidebars.js delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/introduction.mdx delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/accounts.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/blob.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/errors.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/overview.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/root.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/xfer.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/docs/testnet.md delete mode 100644 docs/build/wasp-wasm/v1.0.0-rc.6/sidebars.js diff --git a/docs/build/getting-started/sidebars.ts b/docs/build/getting-started/sidebars.ts index 2035ffb786e..d120794cce1 100644 --- a/docs/build/getting-started/sidebars.ts +++ b/docs/build/getting-started/sidebars.ts @@ -23,12 +23,12 @@ module.exports = { { type: 'link', label: 'WASP CLI', - href: '/wasp-cli/how-tos/wasp-cli', + href: '/isc/how-tos/manage-chains/wasp-cli', }, { label: 'Schema Tool', type: 'link', - href: '/wasp-wasm/how-tos/schema-tool/introduction', + href: '/isc/how-tos/wasm/introduction', }, { label: 'Explorer', diff --git a/docs/build/getting-started/welcome.md b/docs/build/getting-started/welcome.md index f3c69cc36e1..2d8987c4feb 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/_about-accounts.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_about-accounts.md new file mode 100644 index 00000000000..14e70319d1a --- /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](/isc/explanations/how-accounts-work). + +::: \ No newline at end of file diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/accounts-and-addresses.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/accounts-and-addresses.md deleted file mode 100644 index 2d8888f99b3..00000000000 --- a/docs/build/isc/v1.0.0-rc.6/docs/explanations/accounts-and-addresses.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -description: 'IOTA Smart Contracts chains keeps a ledger of on-chain account balances. On-chain accounts are identified -by an AgentID.' -image: /img/tutorial/accounts.png -keywords: - -- smart contracts -- on-chain account -- ownership -- accounts Contract -- explanation - ---- - -# How Accounts Work - -On the L1 Ledger, like with any _DLT_, we have **trustless** and **atomic** transfers of assets between addresses on the -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 -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_. - -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. - -## Types of Accounts - -### L1 Address - -Any L1 address can be the owner of a L2 account. -The Agent ID of an L1 address is just the address, - -e.g. `iota1pr7vescn4nqc9lpvv37unzryqc43vw5wuf2zx8tlq2wud0369hjjugg54mf`. - -Tokens in an address account can only be moved through a request signed by the private key of the L1 address. - -### 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). -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 -example: `cebf5908@tgl1pzehtgythywhnhnz26s2vtpe2wy4y64pfcwkp9qvzhpwghzxhwkps2tk0nd`. - -Note that this allows trustless transfers of assets between smart contracts on the same or different chains. - -Tokens in a smart contract account can only be moved by that smart contract. - -### The Common Account - -The chain owns a unique L2 account, called the _common account_. -The common account is controlled by the chain owner (defined in the chain root contract) and is used to store funds -collected by fees or sent to the chain L1 address. - -The Agent ID of the common account is `@
`. - -### Ethereum Address - -An L2 account can also be owned by an Ethereum address. See [EVM](../introduction.md) for more information. -The Agent ID of an Ethereum address is just the address prefixed with `0x`, -e.g. `0xd36722adec3edcb29c8e7b5a47f352d701393462`. - -Tokens in an Ethereum account can only be moved by sending an Ethereum transaction signed by the same address. - -## The Accounts Contract - -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) - -## Example - -The following diagram illustrates an example situation. -The 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) - -Two chains are deployed, with IDs `chainA` and `chainB`. -`chainA` has two smart contracts on it (with hnames `3037` and `2225`), and `chainB` has one smart contract (`7003`). - -There is also an address on the L1 Ledger: `iota1a2b3c4d`. -This address controls 1337 base tokens and 42 `Red` native tokens on the L1 Ledger. - -The same address also controls 42 base tokens on `chainA` and 8 `Green` native tokens on `chainB`. - -So, the owner of the private key behind the address controls three different accounts: the L1 account and one L2 account -on each chain. - -Smart contract `7003@chainB` has five base tokens on its native chain and controls eleven base tokens on chain A. 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..78192da0a89 --- /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 +keywords: + - 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 index 57b046eca50..d05e7dd1d4e 100644 --- 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 @@ -21,17 +21,17 @@ 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. +- [`root`](/isc/reference/core-contracts/root): Responsible for the initialization of the chain, maintains registry of deployed contracts. -- [`accounts`](./accounts.md): Manages the on-chain ledger of accounts. +- [`accounts`](/isc/reference/core-contracts/accounts): Manages the on-chain ledger of accounts. -- [`blob`](./blob.md): Responsible for the registry of binary objects of arbitrary size. +- [`blob`](/isc/reference/core-contracts/blob): 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. +- [`blocklog`](/isc/reference/core-contracts/blocklog): 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. +- [`governance`](/isc/reference/core-contracts/governance): 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. +- [`errors`](/isc/reference/core-contracts/errors): 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 +- [`evm`](/isc/reference/core-contracts/evm): 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 87% 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 2d8888f99b3..ebdc22d52c8 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 keywords: @@ -11,7 +11,6 @@ keywords: - 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. @@ -74,9 +77,9 @@ 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/use-the-magic-contract/view-account-balances.mdx) +- [Deposit funds to the chain](../how-tos/use-the-magic-contract/deposit-to-a-chain.mdx) +- [Withdraw funds from the chain](../how-tos/use-the-magic-contract/withdraw-from-a-chain.mdx) ## Example diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md new file mode 100644 index 00000000000..b18c132635b --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md @@ -0,0 +1,111 @@ +--- +description: 'Smart contracts can be invoked through their entry points, from outside via a request, or from inside via a +call.' +image: /img/logo/WASP_logo_dark.png +keywords: + +- smart contracts +- requests +- on-ledger +- off-ledger +- calls +- invocation +- explanation + +--- + +# Calling a Smart Contract + +## Entry Points + +Like any other computer program, a smart contract will lie dormant until someone or something instructs it to activate. +In the case of smart contracts, the most common way to activate them is to call one of +their [entry points](./smart-contract-anatomy.md#entry-points). It is the same as calling a program's function. It will +take a set of instructions of the smart contract and execute it over the current chain's state. _View entry points_ can +only read the state, while _full entry points_ can read and write to it. + +To invoke a smart contract from outside the chain, the _sender_ (some entity that needs to be identified by a +private/public key pair) has to wrap the call to the entry point into a _request_. +The request has to be cryptographically signed and submitted to the [consensus](./consensus.md) procedure to let the +chain's committee evaluate it and engrave the outcome of its execution into a new state update. + +Upon receiving a request, the committee will execute the wrapped call fully or reject the request with all its potential +changes, never modifying the state halfway. This means that every single request is an atomic operation. + +### Synchronous Composability + +After being invoked by a request, the smart contract code is allowed to invoke entry points of other smart contracts on +the same chain. This means it can _call_ other smart contracts. + +Smart contract calls are deterministic and synchronous, meaning they always produce the same result and execute all +instructions immediately after another. +If a smart contract calls another smart contract, the resulting set of instructions is also deterministic and +synchronous. This means that for a request, it makes no difference if a smart contract's entry point contains the whole +set of instructions or if it is composed by multiple calls to different smart contracts of the chain. + +Being able to combine smart contracts in this way is called _synchronous composability_. + +--- + +## Requests + +A request contains a call to a smart contract and a signature of the sender. The sender also owns the assets and funds +processed within the request. +Unlike calls between smart contracts, requests are not executed immediately. +Instead, they must wait until the chain's _validator_ nodes include them in a request batch. +This means that requests have a delay and are executed in an unpredictable order. + +### Asynchronous Composability + +Requests are not sent by humans exclusively. Smart contracts can also create requests. +For example, a user can send a request to a smart contract that, in turn, sends a request to a decentralized third-party +exchange which would will the user's funds from one currency to another and send them back through another request. + +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. + +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](../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. + +--- + +## Allowance + +Any funds sent to the chain via on-ledger requests are credited to the sender's account. + +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. + +The Allowance property looks like the following: + +```go +{ + BaseTokens: uint64 + NativeTokens: [{TokenID, uint256}, ...] + NFTs: [NFTID, ...] +} +``` diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/isc-architecture.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/isc-architecture.md new file mode 100644 index 00000000000..e11ef1149d8 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/isc-architecture.md @@ -0,0 +1,32 @@ +--- +description: An overview of the IOTA Smart Contracts architecture. +image: /img/multichain.png +keywords: + - 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_](/learn/protocols/stardust/core-concepts/multi-asset-ledger) (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/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/proxies.mdx b/docs/build/isc/v1.0.0-rc.6/docs/explanations/proxies.mdx similarity index 86% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/proxies.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/explanations/proxies.mdx index f8b01261e92..fb60aa453d7 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/proxies.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/proxies.mdx @@ -32,12 +32,12 @@ At the core, data is secured in maps on the ISC host with byte strings serving a The WasmLib recognizes three predefined maps: -- **[State Map](../how-tos/schema-tool/state.mdx):** A repository for all state storage values. -- **[Params Map](../how-tos/schema-tool/params.mdx):** Holds the parameter values of the current function call. -- **[Results Map](../how-tos/schema-tool/results.mdx):** Returns the result values of the function call. +- **[State Map](../how-tos/wasm/state.mdx):** A repository for all state storage values. +- **[Params Map](../how-tos/wasm/params.mdx):** Holds the parameter values of the current function call. +- **[Results Map](../how-tos/wasm/results.mdx):** Returns the result values of the function call. Through these maps, a complex, -JSON-like data structure can be created with the aid of the [Schema Tool](../how-tos/schema-tool/usage.mdx), +JSON-like data structure can be created with the aid of the [Schema Tool](../how-tos/wasm/usage.mdx), although, fundamentally, this structure is rooted in simple key-value access on the underlying map. ## Proxy Varieties @@ -49,7 +49,7 @@ Proxies are segmented into various categories to facilitate different functional Representing a single instance of a predetermined data type, value proxies are basic entities facilitating type conversion of the byte string representing the stored value. -The [Schema Tool](../how-tos/schema-tool/usage.mdx) ensures type-safe code generation, always selecting the suitable proxy type. +The [Schema Tool](../how-tos/wasm/usage.mdx) ensures type-safe code generation, always selecting the suitable proxy type. ### Container Proxies diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md new file mode 100644 index 00000000000..2ec97c45552 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md @@ -0,0 +1,45 @@ +--- +description: 'Smart Contracts can only interact with the world by using the Sandbox interface which provides limited and +deterministic access to the state through a key/value storage abstraction.' +image: /img/sandbox.png +keywords: + +- smart contracts +- sandbox +- interface +- storage abstraction +- explanation + +--- + +# Sandbox Interface + +A smart contract's access to the world has to be restricted. Imagine a smart contract that would directly tap into a +weather forecast website: as the weather changes, the result of the contract's execution will also change. This smart +contract is not deterministic, meaning that you cannot reproduce the result yourself to verify it because the result for +each execution could be different. + +The access to the chain's state has to be curated, too. The chain owner and developers of individual smart contracts are +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 +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](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](../how-tos/wasm/events.mdx) dispatch. +- Entropy that emulates randomness in an unpredictable yet deterministic way. +- Logging. Used for debugging in a test environment. + +The Sandbox API available in "view calls" is slightly more limited than the one available in normal "execution calls". +For example, besides the state access being read-only for a view, they cannot issue requests, emit events, etc. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md new file mode 100644 index 00000000000..744969510a0 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contract-anatomy.md @@ -0,0 +1,80 @@ +--- +description: Each smart contract instance has a program with a collection of entry points and a state. +image: /img/tutorial/SC-structure.png +keywords: + - smart contracts + - structure + - state + - entry points + - Wasm + - explanation +--- + +# Anatomy of a Smart Contract + +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](../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`](../reference/core-contracts/root.md) core contract +is `0xcebf5908`. This +value uniquely identifies this contract in every chain. + +## State + +The smart contract state is the data owned by the smart contract and stored on the chain. +The state is a collection of key/value pairs. +Each key and value are byte arrays of arbitrary size (there are practical limits set by the underlying database, of +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 account represents the balances of base tokens, native tokens, and NFTs controlled by the smart +contract. + +The smart contract program can access its state and account through an interface layer called the _Sandbox_. +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](https://wiki.iota.org/build/wasp-wasm/how-accounts-work/) for more information on sending and receiving +tokens. + +## Entry Points + +Each smart contract has a program with a collection of _entry points_. +An entry point is a function through which you can invoke the program. + +There are two types of entry points: + +- _Full entry points_ (or simply _entry points_): These functions can modify + (mutate) the smart contract's state. +- _View entry points_ (or _views_): These are read-only functions. They are only used + to retrieve the information from the smart contract state. They cannot + modify the state, i.e., they are read-only calls. + +## 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`](../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. + +## Error Handling + +Smart contract calls can fail: for example, if they are interrupted for any reason (e.g., an exception) or if it +produces an error (missing parameter or other inconsistency). +Any gas spent will be charged to the sender, and the error message or value is stored in the receipt. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md new file mode 100644 index 00000000000..db258bb1d9a --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/smart-contracts.md @@ -0,0 +1,54 @@ +--- +description: 'Smart contracts are applications you can trust that run on a distributed network with multiple validators +all executing and validating the same code.' +image: /img/banner/banner_wasp_core_concepts_smart_contracts.png +keywords: + +- smart contracts +- blockchain +- parallel +- scaling +- explanation + +--- + +# Smart Contracts + +![Wasp Node Smart Contracts](/img/banner/banner_wasp_core_concepts_smart_contracts.png) + +## What Are Smart Contracts? + +Smart contracts are software applications that run on a distributed network with multiple validators executing and +validating the same code. This ensures the application behaves as expected and that there is no tampering in the +program's execution. + +### Applications You Can Trust + +As you can be certain that the executed code is always the same (and will not change), this results in +applications you can trust. This allows you to use smart contracts for applications with a trust issue. The +smart contract rules define what the contract can and can not do, making it a decentralized and predictable +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 +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**. + +### Scalable Smart Contracts + +Anyone willing to pay the fees for deploying a smart contract on a public blockchain can deploy one. Once your smart +contract has been deployed to the chain, you no longer have the option to change it, and you can be sure that your +smart contract application will be there as long as that blockchain exists. Smart contracts can communicate with one +another, and you can invoke programmed public functions on a smart contract to trigger actions on a smart contract, or +address the state of a smart contract. + +Because smart contracts do not run on a single computer but on many validators, a network of validators can only +process so many smart contracts at once, even if the software has been written optimally. This means smart contracts are +expensive to execute, and do not scale well on a single blockchain, often resulting in congested networks and costly +fees for executing functions on smart contracts. **By allowing many blockchains executing smart contracts to run in +parallel** and communicate with one another, **IOTA Smart Contracts solves this scalability problem.** + +At the same time, ISC provides advanced means of communication between its chains and preserves the ability to create +complex, composed smart contracts. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md new file mode 100644 index 00000000000..b3265edd14d --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/state_manager.md @@ -0,0 +1,209 @@ +--- +description: State manager is Wasp component, which is responsible for keeping the store up to date. +image: /img/logo/WASP_logo_dark.png +keywords: + - state manager + - pruning + - snapshot + - write ahead log + - WAL +--- + +# State Manager + +State manager aims at keeping the state of the node up to date by retrieving missing data and ensuring that it is +consistently stored in the DB. It services requests by other Wasp components (consensus, _mempool_), which mainly +consist of ensuring that the required state is available in the node: that it may be retrieved from the permanent +store of the node (the database; DB). An obvious way to obtain the latest state is to obtain all of the blocks, +that resulted in making that state. So to obtain state index `n`, state manager first must commit block index `0` +(origin block), then block index `1`, then block index `2` etc. up to block index `n` precisely in that order. +There are two ways for state manager to obtain blocks (other than origin block): + +1. Receive them directly from this node's consensus when the new state[^1] is decided. State manager has no influence + to this process. +2. Receive them from neighbouring nodes upon request, provided the block is available there. + +Independently of the way the block is received, it is stored in state manager's cache (for quicker access) and WAL +(to ensure availability). Therefore it may happen that the block can be retrieved from there. + +[^1] A block is a difference between two consecutive states. To make state index `n`, block index `n` must be obtained +and committed on top of state index `n-1`. Although state manager manipulates blocks, in this description sometimes +"state" and "block" will be used interchangeably as "obtaining block" or "committing block" is essentially the same as +"obtaining state" or "committing state" respectively, having in mind that previous state is already obtained or committed. Block +and state has some other common properties, e.g. block index `n`, which applied to state index `n-1` produces state index `n`, +contains the same commitment as state index `n`. + +## Snapshot + +Once in a while there might be a need to add a new node to the network. This node has no knowledge of chain's history +and it still needs to have the newest state of the chain (to catch up the chain). If the chain has been running for a while, +it might have gone through many sate transitions and downloading that many blocks may take a long period of time. To avoid that, +some nodes in the network can be configured to dump a complete state of the chain at some time into a file periodically +(see `snapshots.period` parameter). This file is called a snapshot. Loading a snapshot to DB produces the same state as downloading +and committing all the blocks that produced that state. However as those blocks aren't downloaded, they are not available in the DB, +except a block with the same state index as snapshot. + +The snapshot format is as follows: + +1. number `4` in 4 byte unsigned integer little endian format representing the length of state index, +2. state index in 4 byte unsigned integer little endian format, +3. number `40` in 4 byte unsigned integer little endian format representing the length of state commitment: `20` bytes for trie root and + `20` bytes for hash of a block, which was last committed to make this state (block with the same index as state), +4. trie root in `20` bytes, +5. the mentioned block's hash in `20` bytes, +6. number `0` in 1 byte unsigned integer format representing snapshot version, +7. bytes representing mentioned block, +8. bytes representing trie of the state. + +The node that makes a snapshot can serve it over http and new nodes can use this to speed up the catch up. Serving the snapshots +over http is beyond the scope of Wasp and should be done in addition. Wasp is only responsible for making snapshots in local +(configurable by `snapshots.localPath` parameter) folder and obtaining them on start when needed from the same local folder or from +configured (by `snapshots.networkPaths` parameter) URLs. A folder, referenced in the `snapshots.networkPaths` parameter must contain +`INDEX` file with new line separated list of snapshot file names. + +If a chain starts with an empty database (usually if the database hasn't been created yet or was deleted), the node checks if +it can load a snapshot: it scans the local folder and all the network addresses for available snapshot files. In the local folder, it reads +all the files with names that satisfy the search pattern `*-*.snap`. In each network location, Wasp reads all the files listed in `INDEX` +file of that location. Wasp reads a state index and a commitment from the contents of these files. File names are not used to obtain +this information, and full snapshot files are not (down)loaded yet. The node chooses +the one with the largest state index and loads it to the store among all available snapshot files. If several files have the same largest state index, +the node loads them one by one, starting from the local ones until one snapshot is loaded correctly. If loading fails for all candidates, +the node will start with an empty database. + +You can use the `snapshots.snapshotsToLoad` parameter to load a specific snapshot. In that case, the node searches for snapshots with +the block hash provided in the parameter. Once again, if loading all found files fails, the node starts with an empty database. + +After a snapshot is loaded, earlier blocks (ones with a smaller state index than the snapshot) cannot be retrieved and committed to the DB +(this is discussed in [Obtaining blocks section](#obtaining-blocks)). This constraint can cause problems (especially in reorg) +if the loaded snapshot is too recent. To avoid that, making snapshots is delayed by `snapshots.delay` states. E.g., if `snapshots.period` +is `100` and `snapshots.delay` is `20`, then snapshot index `100` will be produced. When block index `120` is committed, snapshot index +`200` will be produced, when snapshot index `220` is committed, etc... For the data to be available after this delay, `snapshot.delay` +value must be considerably smaller than `stateManager.pruningMinStatesToKeep`. + +## Obtaining blocks + +Requests to the state manager contain the state commitment and the state manager must ensure, that block (state) with this +commitment is present in the DB. It is possible that to satisfy the request state manager needs to retrieve +several blocks. However this cannot be done in one step as only the commitment of the requested block is known. For this +reason state (block) contains a commitment of the previous block. Previous block must be committed prior to committing the +requested block. And this logic can be extended up to the block, which is already present in the DB, or until the origin +state is reached. + +E.g., let's say, that the last state in the DB is state index `10` and request to have state index `12` is received. +State manager does this in following steps: + +1. Block index `12` is obtained, and commitment of block index `11` is known. +2. As the commitment of block (state) index `11` is known, the block may be requested and obtained. After obtaining block + index `11` commitment of block index `10` is known. +3. Using block index `10` commitment the DB is checked to make sure that it is already present. +4. As block index `10` is already committed, block index `11` is committed. This makes state `11` present in the DB. +5. As state `11` is already committed, block index `12` is committed. This makes state `12` present in the DB and completes + the request. + +To obtain blocks, state manager sends requests to 5 other randomly chosen nodes. If the block is not received (either messages +got lost or these nodes do not have the requested block), 5 other randomly chosen nodes are queried. This process is repeated +until the block is received (usually from other node but may also be from this node's consensus) or the request is no longer +valid. + +If difference between state indexes of requested state and available in the DB state is large, this chain can get very long. +In order to limit its length, if requested block index is a) smaller than state index of snapshot, which was loaded on node +start, or b) smaller than largest state index among the pruned blocks (see [Pruning](#pruning)), the node panics. If this panicking +continues, the administrator may decide to delete the DB and start the node from (possibly configured) snapshot. + +## Block cache + +Block cache is in memory block storage. It keeps a limited amount (configured by `stateManager.blockCacheMaxSize`) of blocks +for limited amount of time (configured by `stateManager.blockCacheBlocksInCacheDuration`) to make the retrieval +quicker. E.g., in the last step of example of the previous section block index `12` must be committed. It is obtained in +the step 1, but as several steps of the algorithm are spread over time with requests to other nodes in between, and +several requests to obtain the same block may be present, it is not feasible to store it in request. However it would +be wasteful to fetch it twice on the same request. So the block is stored in cache in step 1 of the algorithm and +retrieved from cache later in the last step. + +The block is kept in the cache no longer that predetermined amount of time (configured by `stateManager.blockCacheBlocksInCacheDuration`). +If upon writing to cache blocks in cache limit is exceeded, block, which is in cache the longest, is removed from cache. + +## Block write ahead log (WAL) + +Upon receiving a block, its contents is dumped into a file and stored in a file system. The set of such files is WAL. + +The primary motivation behind creating it was in order not to deadlock the chain. Upon deciding on next state committee +nodes send the newest block to state manager and at the same time one of the nodes send the newest transaction to L1. +In an unfavourable chain of events it might happen that state managers of the committee nodes are not fast enough to commit +the block to the DB (see algorithm in [Obtaining blocks section](#obtaining-blocks)), before the node crashes. This leaves +the nodes in the old state as none of the nodes had time to commit the block. However the L1 reports the new state as +the latest although none of the nodes can be transferred to it. The solution is to put the block into WAL as soon as +possible so it won't be lost. + +Currently upon receiving the new confirmed block from node's consensus, state manager is sure that its predecessor is in the DB, +because consensus sends other requests before sending the new block, so WAL isn't that crucial any more. However, it is useful +in several occasions: + +1. Storing preliminary block, which is sent by consensus of other nodes. +2. When the node is catching up many states and block cache limit is too small to store all the blocks, WAL is used to avoid + fetching the same block twice. +3. In case of adding new node to the network to avoid catch up taking a lot of time when snapshots are not available, + the new node can be configured (`wal.loadToStore=true`) to load the DB with blocks from WAL on startup. WAL can be copied + from some other node. This is also true for any catch up over many states. + +## Pruning + +In order to limit the DB size, old states are deleted (pruned) from it on a regular basis. The amount of states to keep is +configured by two parameters: one in the configuration of the node (`stateManager.pruningMinStatesToKeep`) and one in the governance contract +(`BlockKeepAmount`). The resulting limit of previous states to keep is the larger of the two. Every time a block is committed +to the DB, states which are over the limit are pruned. However, to avoid freezing State manager for too long, no more than +`stateManager.pruningMaxStatesToDelete` blocks are pruned in a single run. The algorithm ensures that oldest states are pruned +first to avoid gaps between available states on the event of some failure. + +Pruning may be disabled completely via node configuration to make an archive node: node that contains all the state ever +obtained by the chain. Note, that such node will require a lot of resources to maintain: mainly disk storage. + +## Parameters + +### State manager + +The following parameters may be provided in section `stateManager`: + +- `blockCacheMaxSize`: the limit of the blocks in block cache. Default is 1k. +- `blockCacheBlocksInCacheDuration`: the limit of the time block stays in block cache. Default is 1 hour. +- `blockCacheBlockCleaningPeriod`: how often state manager should find and delete blocks, that stayed in block cache + for too long. Default is every minute. +- `stateManagerGetBlockRetry`: how often requests to retrieve the needed blocks from other nodes should be repeated. + Default is every 3 seconds. +- `stateManagerRequestCleaningPeriod`: how often state manager should find and delete requests, that are no longer valid. + Default is every second. +- `stateManagerTimerTickPeriod`: how often state manager should check if some maintenance (cleaning requests or block cache, + resending requests for blocks) is needed. Default is every second. There is no point in making this value larger than + any of `blockCacheBlockCleaningPeriod`, `stateManagerGetBlockRetry` or `stateManagerRequestCleaningPeriod`. +- `pruningMinStatesToKeep` : minimum number of old states to keep in the DB. Note that if `BlockKeepAmount` in + governance contract is larger than this value, then more old states will be kept. + Default is 10k. 0 (and below) disables pruning. +- `pruningMaxStatesToDelete`: maximum number of states to prune in one run. This is needed in order not to grab + state manager's time for pruning for too long. Default is 1k. + +### Snapshots + +The following parameters may be provided in section `snapshots`: + +- `snapshotsToLoad`: the comma sepparated list of `:` pairs, where chain `` must be started using snapshot with block hash ``. + The list can also contain `` entry. This hash will be used for other chains, which are not configured separately. There is + no point in having several `` or `:` entries with the same `` as only the last such entry is taken into + account. Note that if the chain is configured to start from some snapshot and the snapshot is not available (or another error occurs + during snapshot loading), the chain will start with an empty DB. The default is an empty list, which means that the newest available snapshot + will be loaded for every chain. +- `period`: how often state snapshots should be made: 1000 meaning "every 1000th state", 0 meaning "making snapshots is disabled". + Snapshots are disabled by default. +- `delay`: how many states to delay making the snapshot; it must be considerably smaller than `stateManager.pruningMinStatesToKeep`. + The default is 20. +- `localPath`: the path to the snapshots folder in this node's disk. Default is `waspdb/snap`. +- `networkPaths`: the comma-separated list of URLs that serve snapshots. The URLs may have the HTTP (e.g., `http://server.org/path/`) or the HTTPS + (e.g., `https://server.org/path/`) scheme for remote locations or a file path (e.g., `file://path/to/folder`) scheme for local snapshot locations. + The scheme is compulsory in the URL. The list is empty by default. + +### WAL + +The following parameters may be provided in section `wal`: + +- `loadToStore`: load blocks from WAL to the store on node start-up. This function is off (`false`) by default. +- `enabled`: whether the WAL is enabled. It is enabled by default. +- `path`: the path to the WAL folder. Default is `waspdb/wal`. diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md new file mode 100644 index 00000000000..c507af37dfa --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/states.md @@ -0,0 +1,122 @@ +--- +description: 'The state of the chain consists of balances of native IOTA digital assets and a collection of key/value +pairs which represents use case-specific data stored in the chain by its smart contracts outside the UTXO ledger.' +image: /img/chain0.png +keywords: + +- state +- transitions +- balances +- digital assets +- UTXO +- transitions +- explanation +--- + +# State, Transitions, and State Anchoring + +## State of the Chain + +The state of the chain consists of: + +- A ledger of accounts owning IOTA _digital assets_ (base tokens, native tokens, and NFTs). The chain acts as a custodian + for those funds on behalf of each account's owner. +- A collection of arbitrary key/value pairs (the _data state_) that contains use case-specific data stored by the smart + contracts in the chain. + +The chain's state is an append-only (immutable) _data structure_ maintained by the distributed consensus of its +validators. + +## Digital Assets on the Chain + +Each native L1 account in the IOTA UTXO ledger is represented by an address and controlled by an entity holding the +corresponding private/public key pair. +In the UTXO ledger, an account is a collection of UTXOs belonging to the address. + +Each ISC L2 chain has a L1 account, called the _chain account_, holding all tokens entrusted to the chain in a single +UTXO, the _state output_. +It is similar to how a bank holds all deposits in its vault. This way, the chain (the entity controlling the state +output) becomes a custodian for the assets owned by its clients, similar to how the bank’s client owns the money +deposited in the bank. + +The consolidated assets held in the chain are the _total assets on-chain_, which are contained in the state output of +the chain. + +The chain account is controlled by a _chain address_, also known as _chain ID_. +It is a special kind of L1 address, an _alias address_, which abstracts the controlling entity (the state controller +address) from the identity of the chain: the controlling entity of the chain may change, while the chain ID stays the +same. + +## The Data State + +The data state of the chain consists of a collection of key/value pairs. +Each key and each value are arbitrary byte arrays. + +In its persistent form, the data state is stored in a key/value database outside the UTXO ledger and maintained by the +validator nodes of the chain. +The state stored in the database is called the _solid state_. + +While a smart contract request is being executed, the _virtual state_ is an in-memory collection of key/value pairs that +can become solid upon being committed to the database. +An essential property of the virtual state is the possibility of having several virtual states in parallel as +candidates, with a possibility for one of them to be solidified. + +The data state has a state hash, a timestamp, and a state index. +The state hash is usually a Merkle root, but it can be any hashing function of all data in the data state. + +The data state hash and on-chain assets are contained in a single atomic unit on the L1 ledger: the state UTXO. +Each state mutation (state transition) of the chain is an atomic event that changes the on-chain assets and the data +state, consuming the previous state UTXO and producing a new one. + +## Anchoring the State + +The data state is stored outside the ledger, on the distributed database maintained by _validator_ nodes. +_Anchoring the state_ means placing the hash of the data state into the state UTXO and adding it to the L1 UTXO ledger. +The UTXO ledger guarantees that there is _exactly one_ such output for each chain on the ledger at every moment. +We call this output the _state output_ (or state anchor) and the containing transaction the _state transaction_ (or +anchor transaction) of the chain. +The state output is controlled (i.e., can be unlocked/consumed) by the entity running the chain. + +With the anchoring mechanism, the UTXO ledger provides the following guarantees to the IOTA Smart Contracts chain: + +- There is a global consensus on the state of the chain +- The state is immutable and tamper-proof +- The state is consistent (see below) + +The state output contains: + +- The identity of the chain (its L1 alias address) +- The hash of the data state +- The state index, which is incremented with each new state output + +## State Transitions + +The data state is updated by mutations of its key/value pairs. +Each mutation either sets a value for a key or deletes a key (and the associated value). +Any update to the data state can be reduced to a partially ordered sequence of mutations. + +A _block_ is a collection of mutations to the data state that is applied in a state transition: + +```go +next data state = apply(current data state, block) +``` + +The state transition in the chain occurs atomically in a L1 transaction that consumes the previous state UTXO and +produces the next one. The transaction includes the movement of the chain's assets and the update of the state hash, + +At any moment in time, the data state of the chain is a result of applying the historical sequence of blocks, starting +from the empty data state. + +![State transitions](/img/chain0.png) + +On the L1 UTXO ledger, the state's history is represented as a sequence (chain) of UTXOs, each holding the chain’s +assets in a particular state and the anchoring hash of the data state. +Note that not all the state's transition history may be available: due to practical reasons, older transactions may be +pruned in a snapshot process. +The only thing guaranteed is that the tip of the chain of UTXOs is always available (which includes the latest data +state hash). + +The ISC virtual machine (VM) computes the blocks and state outputs that anchor the state, which ensures that the state +transitions are calculated deterministically and consistently. + +![Chain](/img/chain1.png) diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md new file mode 100644 index 00000000000..cc0738a1c19 --- /dev/null +++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md @@ -0,0 +1,49 @@ +--- +description: Each chain is run by a network of validator nodes which run a consensus on the chain state update. +image: /img/logo/WASP_logo_dark.png +keywords: + - validators + - validator nodes + - access nodes + - consensus + - state update + - explanation +--- + +# Validators + +Each chain is run by that chain's _committee of validators_. This committee owns a key that is split between all of its +validators. Each key share is useless on its own, but a collective signature gives validators complete control over the +chain. + +The committee of validators is responsible for executing the smart contracts in the chain and thus calculating a _state +update_. +All validators execute exactly the same code and reach a consensus on the state update. +Once the next state is computed and validated, it is committed to each validator's database, a new _block_ is added to +the chain (containing the state mutations), and the _state hash_ is saved in the L1 ledger. + +Depending on the governance model, chain owners can rotate the committee of validators. +By rotating the committee of validators, validators can be deleted, added, or replaced. + +ISC does not define how to select validators to form a committee: it could be a solitary choice of the chain's owner, or +it could be a public competition between candidates. +ISC does not define how validators are rewarded either. + +## Access Nodes + +It is possible to have some nodes act as _access nodes_ to the chain without being part of the committee of +validators. +All nodes in the subnet (validators and non-validators) are connected through statically assigned trust +relationships and each node is also connected to the IOTA L1 node to receive updates on the chain’s L1 +account. + +Any node can optionally provide access to smart contracts for external callers, allowing them to: + +- Query the state of the chain (i.e., _view calls_) +- Send off-ledger requests directly to the node (instead of sending an on-ledger request as a L1 transaction) + +It is common for validator nodes to be part of a private subnet and have only a group of access nodes exposed to the +outside world, protecting the committee from external attacks. + +The management of validator and access nodes is done through +the [`governance` core contract](../reference/core-contracts/governance.md). diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md index e70ea5e060f..ab3d75a40f0 100644 --- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/compatibility.md @@ -31,7 +31,9 @@ Ethereum tools think they are interfacing with an actual Ethereum node, but some :::warning -There is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). Because of this, when sending native tokens in the EVM, which are expressed in wei (ether = 1018wei), the last 12 decimal places will be ignored. +There is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). +Because of this, when sending native tokens in the EVM, which are expressed in wei (ether = 1018wei), +the last 12 decimal places will be ignored. Example: 1,999,999,999,999,999,999 wei = 1.999,999 SMR/MIOTA @@ -43,7 +45,7 @@ Here are some of the most important properties and limitations of EVM support in The Wasp node provides a JSON-RPC service, the standard protocol used by Ethereum tools. Upon receiving a signed Ethereum transaction via JSON-RPC, the transaction is wrapped into an ISC -[off-ledger request](/learn/smart-contracts/invocation#off-ledger-requests). The sender of the request +[off-ledger request](../explanations/invocation.md#off-ledger-requests). The sender of the request is the Ethereum address that signed the original transaction (e.g., the Metamask account). ### Contract ID Source @@ -58,7 +60,7 @@ EVM contracts are not listed in the chain's [contract registry](../reference/cor ### On-ledger Requests EVM contracts cannot be called via regular ISC requests; they can only be called through the JSON-RPC service. -As a consequence, EVM contracts cannot receive [on-ledger requests](/learn/smart-contracts/invocation#on-ledger-requests). +As a consequence, EVM contracts cannot receive [on-ledger requests](../explanations/invocation.md#on-ledger-requests). ### Block Structure and Storage @@ -91,7 +93,7 @@ by default `eth_getBalance` will return the L2 base token balance of the given E ### The Magic Contract -A [dedicated Ethereum contract](../how-tos/magic-contract/magic.md) exists to manage ISC tokens and generally avail ISC +A [dedicated Ethereum contract](../how-tos/use-the-magic-contract/magic.md) exists to manage ISC tokens and generally avail 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 index e15dd71ca27..b5c0452c047 100644 --- 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 @@ -1,7 +1,5 @@ # Supported Virtual Machines & Languages -## EVM/Solidity Based Smart Contracts - :::caution Smart Contracts are currently only compatible with the [Stardust protocol](/learn/protocols/stardust/introduction) and @@ -10,10 +8,12 @@ therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) ::: -The current release of IOTA Smart Contracts has support for [EVM](https://ethereum.org/en/developers/docs/evm/)/[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart -contracts, as well as [Wasm]() smart contracts, providing limited 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. +The current release of IOTA Smart Contracts has support for [EVM/Solidity](#evmsolidity-based-smart-contracts) smart +contracts, as well as [Wasm](#wasm-vm-for-isc) smart contracts, providing limited 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/Solidity Based Smart Contracts ### What is EVM/Solidity? @@ -31,24 +31,37 @@ changes to function on IOTA Smart Contracts. ### How IOTA Smart Contracts Work With EVM Every deployed IOTA Smart Contracts chain automatically includes a core contract -called [`evm`](./reference/core-contracts/evm.md). This core contract is responsible for running EVM code and +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. -## VM for ISC +:::warning EVM Compatibility + +The ISC EVM layer is also designed to be as compatible as possible with existing Ethereum +[tools](tools.md) and functionalities. However, please make sure you have checked out the current +[properties and limitations](compatibility.md). + +For example, there is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). + +::: + + +## Wasm VM for ISC + +:::warning Experimental -:::warning The Wasm _VM_ is in experimental state, showcasing ISC's "VM plugin" architecture. -Experiment but avoid using it for production applications; opt for [EVM](/wasp-evm/introduction). +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. + code execution on ISC. ![Wasp node ISC Host](/img/wasm_vm/IscHost.png) @@ -65,12 +78,12 @@ functionality and smart contract state storage access. 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 +- 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 diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.md deleted file mode 100644 index e0107ff2358..00000000000 --- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/networks-and-chains.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -description: 'Existing EVM tooling is compatible and can be used directly with an IOTA Smart Contracts chain running EVM. -You can configure hardhat, metamask, remix, Ether.js and Web3.js among others.' -image: /img/logo/WASP_logo_dark.png -keywords: - -- smart contracts -- chain -- EVM -- Solidity -- tooling -- wasp-cli -- hardhat -- metamask -- JSON-RPC -- reference - ---- - -# Compatible Tools - -EVM on IOTA Smart Contracts has been integrated in a way that the existing EVM tooling is compatible and can be used -directly with an IOTA Smart Contracts chain running EVM as long as you take a couple of things into account. - -## 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. - -:::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 -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). - -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): - -- Network Name: `Public Testnet` -- New RPC URL: `https://json-rpc.evm.testnet.shimmer.network/` -- Chain ID: `1073` -- Currency Symbol: `SMR` -- Block Explorer URL: `https://explorer.evm.testnet.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. - -If you wish to use additional EVM chains with Metamask, you can add more Custom RPC networks, as long as they have a -unique `Chain ID` and `RPC Url`. Once you have done this, you can start using MetaMask to manage your EVM wallet or -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. - -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`. - -[![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 - - - -## Hardhat - -[Hardhat](https://hardhat.org/) is a command line toolbox that allows you to deploy, test, verify, and interact with -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], - }, -} -``` - -:::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. - -::: - -### Video Tutorial - - - -## Ethers.js/Web3.js - -If you input the correct configuration parameters for the JSON-RPC endpoint to talk -to, [Ethers.js](https://docs.ethers.io/) and [Web3.js](https://web3js.readthedocs.io/) are also compatible with EVM -chains on IOTA Smart Contracts. Alternatively, you can let both interact through MetaMask instead so that it uses the -network configured in MetaMask. For more information on this, read their documentation. - -## Other Tooling - -Most tools available will be compatible if you enter the correct `Chain ID` and `RPC Url`. 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..c6775033a13 --- /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. +keywords: + - 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 | + +## Testnet EVM + + + +[The Testnet EVM](https://explorer.evm.testnet.shimmer.network/) (also called ShimmerEVM Beta) runs as a layer 2 on top +of the [Public Testnet](/build/networks-endpoints/#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 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 94% 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 0695351b7cf..7bfeb03e4ab 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 @@ -29,7 +29,7 @@ Click this button: -Please read [this MetaMask guide](./compatible-tools.md#metamask) for a detailed guidance. +Please read [the MetaMask section in the tools guide](tools.md#metamask) for a detailed guidance. ## Get Testnet SMR Tokens @@ -59,7 +59,7 @@ Visit the [Public Testnet Block Explorer](https://explorer.evm.testnet.shimmer.n - [Wasp GitHub repository](https://github.com/iotaledger/wasp) (smart contracts node implementation) - [Standalone Wasp dashboard](https://dashboard.evm.testnet.shimmer.network/) - [GitHub issues page for Wasp](https://github.com/iotaledger/wasp/issues) -- [Wiki article on configuring wasp-cli](/wasp-cli/how-tos/wasp-cli/) +- [Wiki article on configuring wasp-cli](../how-tos/manage-chains/wasp-cli.md) - [EVM toolkit](https://toolkit.evm.testnet.shimmer.network/) - [ERC20 simulated token faucet](https://erc20-faucet.evm.testnet.shimmer.network/) - [Firefly Shimmer](https://firefly.iota.org) diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.md index e0107ff2358..96851d18d95 100644 --- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.md @@ -41,7 +41,7 @@ chain ID after deployment.** ## Wasp-cli -The Wasp CLI has some basic functionalities to manage an EVM chain. Given the [compatibility](./compatibility.md) with +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 diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC20.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md similarity index 94% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC20.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md index 58b215a3286..b163457efd6 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC20.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md @@ -18,7 +18,7 @@ keywords: - [Remix IDE](https://remix.ethereum.org/). - [A Metamask Wallet](https://metamask.io/). -- [Connect your MetaMask with the public Testnet](../getting-started/compatible-tools.md#metamask). +- [Connect your MetaMask with the public Testnet](../../getting-started/tools.md#metamask). ### Required Prior Knowledge @@ -39,7 +39,7 @@ You can use the [Remix IDE](https://remix.ethereum.org/) to deploy any regular S Set the environment to `Injected Web3` and connect Remix with your MetaMask wallet. If you haven’t already, please follow the instructions -on [how to connect your MetaMask with the public Testnet.](../getting-started/compatible-tools.md#metamask). +on [how to connect your MetaMask with the public Testnet.](../../getting-started/tools.md#metamask). ## 1. Create a Smart Contract diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC721.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC721.md similarity index 98% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC721.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC721.md index ef0b5e7f044..2f80f00104b 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/ERC721.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC721.md @@ -25,7 +25,7 @@ NFTs. - [Remix IDE](https://remix.ethereum.org/). - [A Metamask Wallet](https://metamask.io/). -- [Connect your MetaMask with the public Testnet](../getting-started/compatible-tools.md#metamask). +- [Connect your MetaMask with the public Testnet](../../getting-started/tools.md#metamask). ### Required Prior Knowledge diff --git a/docs/build/wasp-evm/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/EVM/create-a-basic-contract.md similarity index 100% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/create-a-basic-contract.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/create-a-basic-contract.md diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/using.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/using.md similarity index 94% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/using.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/using.md index f7e526072a4..3ad88bbbdf1 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/using.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/using.md @@ -19,7 +19,7 @@ keywords: ## 1. Deploy an IOTA Smart Contracts Chain -When [deploying an IOTA Smart Contracts chain](/wasp-cli/how-tos/setting-up-a-chain/), EVM support is automatically +When [deploying an IOTA Smart Contracts chain](../manage-chains/setting-up-a-chain.md), EVM support is automatically added with the default configuration. The `wasp-cli chain deploy` command accepts the following EVM-specific option: - `--evm-chainid `: EVM chain ID (default: 1074). diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/chain-management.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/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/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/chain-management.md index 30f64ce9197..09ab155d7e9 100644 --- a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/chain-management.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/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](../../reference/core-contracts/governance.md). The “Chain Owner” is the only one who can perform administrative tasks. diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/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/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/setting-up-a-chain.md index 23640a2318d..ca91704e3f1 100644 --- a/docs/build/wasp-cli/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/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`](../../reference/core-contracts/blocklog.md) 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](../../reference/core-contracts/overview.md). 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/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/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/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/wasp-cli.md diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md similarity index 96% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md index 8d909e527fb..593c2b7efd6 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/deploying-sc.md @@ -18,7 +18,7 @@ keywords: :::note WASM VM -For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](../../introduction.mdx). +For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](../../getting-started/languages-and-vms.md#wasm-vm-for-isc). ::: diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md similarity index 93% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md index 6b02ae59faf..f3e881e45b6 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/error-handling.md @@ -44,7 +44,7 @@ Note that this test still ends with the state `#4`, although the last request to ``` This shows that a chain block is always generated, regardless of whether the smart contract call succeeds or not. The -result of the request is stored in the chain's [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog) in the form of +result of the request is stored in the chain's [`blocklog`](../../reference/core-contracts/blocklog.md) in the form of a receipt. In fact, the received Go error `err` in the test above is just generated from the request receipt. If a panic occurs during a smart contract call, it is recovered by the VM context, and the request is marked as failed. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx similarity index 94% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx index 89b6202268f..cbeac98a759 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx @@ -19,8 +19,8 @@ import TabItem from '@theme/TabItem'; # Example Tests -In the previous sections we showed how you can [`call()`](../schema-tool/call.mdx) or -[`post()`](../schema-tool/post.mdx) smart contract function requests. We also created a few wrapper +In the previous sections we showed how you can [`call()`](../wasm/call.mdx) or +[`post()`](../wasm/post.mdx) smart contract function requests. We also created a few wrapper functions to simplify calling these functions even further. Now we will look at how to use the SoloContext to create full-blown tests for the `dividend` example smart contract. @@ -231,11 +231,11 @@ any remaining tokens are not transferred, but remain in the sender's account. Finally, we call `divide` again with 2M+234 tokens and again verify the asset balances afterwards. -Next we will show how to test [Views](../schema-tool/views.mdx) and/or [Funcs](../schema-tool/funcs.mdx) that return -a result. Note that even though Funcs are usually invoked through a [`post()`](../schema-tool/post.mdx) +Next we will show how to test [Views](../wasm/views.mdx) and/or [Funcs](../wasm/funcs.mdx) that return +a result. Note that even though Funcs are usually invoked through a [`post()`](../wasm/post.mdx) request, in which case any return values are inaccessible, they still can be invoked -through a [call()](../schema-tool/call.mdx) from within another Func, in which these return values can -be used normally. Since solo executes [`post()`](../schema-tool/post.mdx) requests synchronously, it is +through a [call()](../wasm/call.mdx) from within another Func, in which these return values can +be used normally. Since solo executes [`post()`](../wasm/post.mdx) requests synchronously, it is possible to have a Func return a result and test for certain result values. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/first-example.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/first-example.md similarity index 94% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/first-example.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/first-example.md index 512963622a2..975735d0216 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/first-example.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/first-example.md @@ -13,8 +13,8 @@ keywords: # First Example The following is an example of a _Solo_ test. It deploys a new chain and invokes some view calls in the -[`root`](/wasp-wasm/reference/core-contracts/root) and [`governance`](/wasp-wasm/reference/core-contracts/governance) -[core contracts](/wasp-wasm/reference/core-contracts/overview). +[`root`](../../reference/core-contracts/root.md) and [`governance`](../../reference/core-contracts/governance.md) +[core contracts](../../reference/core-contracts/overview.md). ```go import ( @@ -81,7 +81,7 @@ The output of the test will be something like this: ::: -The [core contracts](/wasp-wasm/reference/core-contracts/overview) listed in the log are automatically deployed on each +The [core contracts](../../reference/core-contracts/overview.md) listed in the log are automatically deployed on each new chain. The log also shows their _contract IDs_. The output fragment in the log `state transition --> #1` means that the state of the chain has changed from block index diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/invoking-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/invoking-sc.md similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/invoking-sc.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/invoking-sc.md diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/test.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx similarity index 87% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/test.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx index d529627b4d9..8c493da483d 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/test.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx @@ -26,7 +26,7 @@ combination with Solo to deploy chains and smart contracts and simulate transact Solo directly interacts with the ISC code, and therfore uses all the ISC-specific data types directly. Our Wasm smart contracts cannot access these types directly, because they run in a separate, sandboxed environment. Therefore, WasmLib implements its -[own versions](../../reference/data-types/types.mdx) of these data types, and the _VM_ layer acts as a data type +[own versions](../../reference/wasm-lib-data-types.mdx) of these data types, and the _VM_ layer acts as a data type translator between both systems. The impact of this type transformation used to be that to be able to write tests in the @@ -35,7 +35,7 @@ conversion functions, and exactly how to properly pass such data in and out of s contract function calls. This burdened the user with an unnecessary increased learning curve and countless unnecessary type conversions. -With the introduction of the [Schema Tool](../schema-tool/usage.mdx), we were able to remove this +With the introduction of the [Schema Tool](../wasm/usage.mdx), we were able to remove this impedance mismatch and allow the users to test smart contract functionality in terms of the WasmLib data types and functions that they are already familiar with. To that end, we introduced `SoloContext`, a new [Call Context](../../explanations/context.mdx) that specifically works with @@ -45,7 +45,7 @@ available when necessary. The only concession we still have to make is to the language used. Because Solo only works in the Go language environment, we have to use the Go language version of the interface -code that the [Schema Tool](../schema-tool/usage.mdx) generates when testing our smart contracts. Because +code that the [Schema Tool](../wasm/usage.mdx) generates when testing our smart contracts. Because WasmLib programming for Go, Rust, and TypeScript are practically identical, we feel that this is not unsurmountable. The WasmLib interfaces only differ slightly if language idiosyncrasies force differences in syntax or naming conventions. This hurdle used to be a @@ -108,15 +108,15 @@ func dividendGetFactor(ctx *wasmsolo.SoloContext, member *wasmsolo.SoloAgent) ui As you can see, we pass the `SoloContext` and the parameters to the wrapper functions, -then use the `SoloContext` to create a [Function Descriptor](../schema-tool/funcdesc.mdx) for the wrapped -function, pass any parameters through the its [Params](../schema-tool/params.mdx) proxy, and then either -[`post()`](../schema-tool/post.mdx) the function request or [`call()`](../schema-tool/call.mdx) the function. Any -results returned are extracted through the descriptor's [Results](../schema-tool/results.mdx) proxy, and +then use the `SoloContext` to create a [Function Descriptor](../wasm/funcdesc.mdx) for the wrapped +function, pass any parameters through the its [Params](../wasm/params.mdx) proxy, and then either +[`post()`](../wasm/post.mdx) the function request or [`call()`](../wasm/call.mdx) the function. Any +results returned are extracted through the descriptor's [Results](../wasm/results.mdx) proxy, and returned by the wrapper function. There is hardly any difference in the way the function interface is used within Wasm code or within Solo test code. The [Call Context](../../explanations/context.mdx) knows how to properly -[`call()`](../schema-tool/call.mdx) or [`post()`](../schema-tool/post.mdx) the function call through the function +[`call()`](../wasm/call.mdx) or [`post()`](../wasm/post.mdx) the function call through the function descriptor. This makes for seamless testing of smart contracts. In the [next section](examples.mdx) we will go deeper into how the helper member functions diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/the-l1-ledger.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/the-l1-ledger.md similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/the-l1-ledger.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/the-l1-ledger.md diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md similarity index 95% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md index 358439bf95a..0686cb2011b 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/the-l2-ledger.md @@ -100,10 +100,10 @@ func TestTutorialAccounts(t *testing.T) { The example above creates a chain and a wallet with `utxodb.FundsFromFaucetAmount` base tokens on L1. Then, it sends 1 million tokens to the corresponding on-chain account by posting a -[`deposit`](/wasp-wasm/reference/core-contracts/accounts#deposit) request to the -[`accounts` core contract](/wasp-wasm/reference/core-contracts/accounts) on the chain. +[`deposit`](../../reference/core-contracts/accounts.md#deposit) request to the +[`accounts` core contract](../../reference/core-contracts/accounts.md) on the chain. -Finally, it sends a [`withdraw`](/wasp-wasm/reference/core-contracts/accounts#withdraw) request to the `accounts` core +Finally, it sends a [`withdraw`](../../reference/core-contracts/accounts.md#withdraw) request to the `accounts` core contract to get the tokens back to L1. Both requests are affected by the gas fees and the storage deposit. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx similarity index 98% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx index 4fb028f5711..bfe0422c2b9 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx @@ -124,7 +124,7 @@ this will happen in a separate goroutine in the background, so we explicitly wai request counters to catch up with the one request that is pending. The `WaitForPendingRequests()` method can also be used whenever a smart contract function -is known to [`post()`](../schema-tool/post.mdx) a request to itself. Such requests are not immediately +is known to [`post()`](../wasm/post.mdx) a request to itself. Such requests are not immediately executed, but added to the backlog, so you need to wait for these pending requests to actually be processed. The advantage of having to explicitly wait for those requests is that you can inspect the in-between state, which means that you can test even a function diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md similarity index 96% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md index 8147df7f92f..c30df68b2d9 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/view-sc.md @@ -33,7 +33,7 @@ view entry point will result in an exception, returning all attached tokens to t Views are used to retrieve information about the smart contract's state, for example, to display on a website. Certain Solo methods such as `chain.GetInfo`, `chain.GetGasFeePolicy`, and `chain.L2Assets` call views of -the [core smart contracts](/wasp-wasm/reference/core-contracts/overview) behind the scenes to retrieve the information +the [core smart contracts](../../reference/core-contracts/overview.md) behind the scenes to retrieve the information about the chain or a specific smart contract. ## Decoding Results Returned by _PostRequestSync_ and _CallView_ diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md similarity index 96% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md index 006bf22ff6f..75c64a8b4a1 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/what-is-solo.md @@ -64,8 +64,6 @@ You will need a smart contract to test along with Solo. You can find example implementations of Wasm smart contracts, including source code and tests, in the Wasp repository’s [contracts/wasm folder](https://github.com/iotaledger/wasp/tree/develop/contracts/wasm). -For information on creating Wasm smart contracts, refer to the [Wasm VM chapter](../../introduction.mdx). - The following sections will present some Solo usage examples. You can find the example code in the [Wasp repository](https://github.com/iotaledger/wasp/tree/develop/documentation/tutorial-examples). diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/deposit-to-a-chain.mdx similarity index 89% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/deposit-to-a-chain.mdx index e88da4ca3ea..53fd6e2eb3a 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/deposit-to-a-chain.mdx @@ -10,18 +10,21 @@ keywords: - Solo - how to --- +import AboutAccounts from '../../_admonitions/_about-accounts.md'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; # How to Deposit to a Chain + + Any assets attached to an on-ledger request are automatically deposited to the sender's L2 account before executing the request. So, to deposit tokens, you only need to send _any_ on-ledger request with the tokens attached. A commonly needed operation is to only deposit some funds and do nothing else. -The `deposit` entry point of the [`accounts` core contract](../reference/core-contracts/accounts.md) is a no-op function that serves +The `deposit` entry point of the [`accounts` core contract](../../reference/core-contracts/accounts.md) is a no-op function that serves this purpose. :::note Gas Fees diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/magic.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/magic.md similarity index 69% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/magic.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/magic.md index a5ed6917a7e..3cbad431428 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/magic.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/magic.md @@ -42,3 +42,26 @@ 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](/learn/smart-contracts/sandbox) `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/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/send-tokens-to-l1.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/send-tokens-to-l1.mdx similarity index 92% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/send-tokens-to-l1.md rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/send-tokens-to-l1.mdx index d88e5fc6b2c..5c6a04523c8 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/send-tokens-to-l1.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/send-tokens-to-l1.mdx @@ -12,6 +12,7 @@ keywords: - JSON - RPC --- +import AboutAccounts from '../../_admonitions/_about-accounts.md'; # Send Assets and Tokens to L1 @@ -21,6 +22,8 @@ Currently, you can only send back a token to L1 if it was originally sent to L2 ::: + + You can decide how much storage deposit to add by defining it in baseTokens: ```solidity diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/view-account-balances.mdx similarity index 97% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/view-account-balances.mdx index 09771af0901..861e7b31cd6 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/view-account-balances.mdx @@ -10,12 +10,14 @@ keywords: - Solo - how to --- - +import AboutAccounts from '../../_admonitions/_about-accounts.md'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; # View Account Balances + + The Accounts contract provides the following views: ## `balance` diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/withdraw-from-a-chain.mdx similarity index 93% rename from docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/withdraw-from-a-chain.mdx index c348e414ebe..375992f1193 100644 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/withdraw-from-a-chain.mdx @@ -10,12 +10,14 @@ keywords: - Solo - how to --- - +import AboutAccounts from '../../_admonitions/_about-accounts.md'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; # How to Withdraw From a Chain + + The `withdraw` endpoint sends L2 funds owned by the caller to their L1 address. 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/how-tos/wasm/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/how-tos/wasm/access.mdx index c084cad4762..f4c5b4e48d1 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/funcdesc.mdx similarity index 98% 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/how-tos/wasm/funcdesc.mdx index 01e8804e532..de314113a98 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/how-tos/wasm/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. 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/how-tos/wasm/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/how-tos/wasm/funcs.mdx index 8617de41678..d743eb00f6a 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/init.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/introduction.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/introduction.mdx similarity index 99% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/introduction.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/introduction.mdx index bc0e60ca51c..061cb7a101e 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/introduction.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/introduction.mdx @@ -1,4 +1,4 @@ -# Introduction +# The Schema Tool Smart contracts need robustness, combining both flexibility and stringent regulation to prevent mistakes and foster efficiency. Using the Schema Tool ensures consistency, and simplifies smart contract development. 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/how-tos/wasm/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/how-tos/wasm/params.mdx index 3dc604d6f28..4924374d900 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/results.mdx index ea44285bad6..680c224130e 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/state.mdx similarity index 99% 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/how-tos/wasm/state.mdx index d02b9a30ec0..b346ef312f7 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/how-tos/wasm/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 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/how-tos/wasm/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/how-tos/wasm/structs.mdx index 14473408926..d1e7a7d68b2 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/thunks.mdx index 09467423d4c..ac4b969e854 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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/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/how-tos/wasm/typedefs.mdx similarity index 97% 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/how-tos/wasm/typedefs.mdx index c7e2a331839..e04ca5c8952 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/how-tos/wasm/typedefs.mdx @@ -19,7 +19,7 @@ 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. ::: @@ -30,7 +30,7 @@ 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/how-tos/wasm/usage.mdx similarity index 100% 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/how-tos/wasm/usage.mdx diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/views.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/views.mdx similarity index 98% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/views.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/views.mdx index 355c5c05cb0..5f0eae8f33a 100644 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/views.mdx +++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/views.mdx @@ -129,5 +129,5 @@ export function viewGetFactor( The return values are passed to the caller through the predefined [Results](results.mdx) map associated with the [Call Context](../../explanations/context.mdx). Again, this works the same as for Funcs, although Funcs do not necessarily return values to the caller. The -[Schema Tool](../schema-tool/usage.mdx) will generate a function-specific [Results](results.mdx) +[Schema Tool](usage.mdx) will generate a function-specific [Results](results.mdx) structure with type-safe proxies to the result fields in this map. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/yaml.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/yaml.mdx similarity index 100% rename from docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/schema-tool/yaml.mdx rename to docs/build/isc/v1.0.0-rc.6/docs/how-tos/wasm/yaml.mdx 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 index 4870a12e749..ace5bf5e401 100644 --- a/docs/build/isc/v1.0.0-rc.6/docs/introduction.md +++ b/docs/build/isc/v1.0.0-rc.6/docs/introduction.md @@ -11,25 +11,8 @@ keywords: - explanation --- -# Introduction - -Smart contracts are deterministic applications that run on distributed network with multiple -[validators](/learn/smart-contracts/validators) 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, -they usually have a limited throughput as a validator can only process a limited amount smart contracts at once. -This can lead to relatively high fees 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. - -At the same time, ISC provides advanced means of communication between its chains and preserves the ability to create -complex, composed smart contracts. - -## EVM/Solidity Based Smart Contracts +# Introduction :::caution @@ -39,78 +22,62 @@ therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) ::: -The current release of IOTA Smart Contracts has support for [EVM](https://ethereum.org/en/developers/docs/evm/)/[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart -contracts, as well as [Wasm]() smart contracts, providing limited 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. - -### 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 implementations. +Smart contracts are deterministic applications that run on 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. -[Solidity](https://soliditylang.org/) is the programming language of choice with EVM, which was created for this -specific purpose. +## Scalable Smart Contracts -The main benefit of using EVM/Solidity right now is its sheer amount of resources from years of development and 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 probably need no (or very minimal) -changes to function on IOTA Smart Contracts. +Due to the distributed nature of smart contracts, i.e. they run on a network of validators instead of a single computer, +they usually have a limited throughput as a validator can only process a limited amount smart contracts at once. +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. -### How IOTA Smart Contracts Work With EVM +At the same time, ISC provides advanced means of communication between its chains and preserves the ability to create +complex, composed smart contracts. -Every deployed IOTA Smart Contracts 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. +## ISC Architecture -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. +IOTA Smart Contracts (ISC) function as a Layer 2 extension to the IOTA Multi-Asset Ledger. 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](explanations/isc-architecture.md). -## VM for ISC +![IOTA Smart Contacts multichain architecture](/img/multichain.png 'Click to see the full-size image.') -:::warning -The Wasm _VM_ is in experimental state, showcasing ISC's "VM plugin" architecture. +_IOTA Smart Contacts multichain architecture._ -Experiment but avoid using it for production applications; opt for [EVM](/wasp-evm/introduction). -::: +[Explore the comprehensive overview of IOTA Smart Contracts in the ISC white paper](https://files.iota.org/papers/ISC_WP_Nov_10_2021.pdf). -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. +## Supported VMs -![Wasp node ISC Host](/img/wasm_vm/IscHost.png) +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). -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. +## Sandbox Interface -![Wasm VM](/img/wasm_vm/WasmVM.png) +Smart contracts access data via the deterministic [Sandbox interface](explanations/sandbox.md), ensuring +security and predictability. This interface restricts contracts to their own state and provides various utilities like cryptographic functions and +event dispatching. -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. +![Sandbox](/img/sandbox.png) -### Supported Functionalities +## Calling a Smart Contract -The ISC sandbox environment offers: +### Entry Points and Requests -- 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 +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. -### Supported Languages +### Gas -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: +Running a request consumes 'gas', that is the cost of executing an on-chain request. You can specify a `GasBudget` +for each request, with costs charged to your on-chain account. -| Language | Wasm code generator | -|------------|----------------------------------------------------| -| Go | [TinyGo](https://tinygo.org/) | -| Rust | [wasm-pack](https://rustwasm.github.io/wasm-pack/) | -| TypeScript | [AssemblyScript](https://www.assemblyscript.org/) | +## On-Ledger vs Off-Ledger Requests -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 +Requests can be on-ledger, that is, processed through +the Tangle, or off-ledger, directly sent to validators for faster processing. 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 af6f4a9552e..5a03d322272 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](../../how-tos/manage-chains/setting-up-a-chain.md). --- 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-wasm/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-wasm/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 9c9cb0ea038..62257c97ae9 100644 --- a/docs/build/wasp-wasm/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 @@ keywords: 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). +It also includes the implementation of the [ISC Magic contract](../../how-tos/use-the-magic-contract/magic.md). :::note -For more information about how ISC supports EVM contracts, refer to the [EVM](/wasp-evm/introduction/) 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 71% 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..bd7d8643988 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 @@ -32,3 +32,29 @@ There are some usage examples in 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 88% 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 d64affa3a15..4d162caff71 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](../how-tos/wasm/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. @@ -57,7 +57,7 @@ More detailed explanations about their specific uses can be found in the ## 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](../explanations/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 @@ -72,7 +72,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** | @@ -99,8 +99,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](../how-tos/wasm/usage.mdx) will automatically generate the proper (im)mutable 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](../how-tos/wasm/state.mdx) map through immutable proxies. The same goes for the +[Params](../how-tos/wasm/params.mdx) map that was passed into a Func or View, and for the +[Results](../how-tos/wasm/results.mdx) map that was returned from a call to a Func or View. diff --git a/docs/build/isc/v1.0.0-rc.6/sidebars.js b/docs/build/isc/v1.0.0-rc.6/sidebars.js index ea8e6dd6dd0..4e7b49e3126 100644 --- a/docs/build/isc/v1.0.0-rc.6/sidebars.js +++ b/docs/build/isc/v1.0.0-rc.6/sidebars.js @@ -14,7 +14,7 @@ module.exports = { //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], // But you can create a sidebar manually - evmSidebar: [ + EVMSidebar: [ { type: 'doc', label: 'Introduction', @@ -29,6 +29,8 @@ module.exports = { label: 'Languages & VMs', id: 'getting-started/languages-and-vms', }, + 'getting-started/quick-start', + 'getting-started/compatibility', { type: 'doc', label: 'Networks & Chains', @@ -47,18 +49,356 @@ module.exports = { items: [ { type: 'doc', - label: 'How Accounts Work', - id: 'explanations/accounts-and-addresses', + label: 'ISC Functionality', + id: 'explanations/isc-functionality', + }, + { + type: 'doc', + label: 'ISC Architecture', + id: 'explanations/isc-architecture', + }, + { + type: 'doc', + label: 'Anatomy of a Smart Contract', + id: 'explanations/smart-contract-anatomy', + }, + { + type: 'doc', + label: 'Sandbox Interface', + id: 'explanations/sandbox', + }, + { + type: 'doc', + label: 'Calling a Smart Contract', + id: 'explanations/invocation', + }, + { + type: 'doc', + label: 'State, Transitions and State Anchoring', + id: 'explanations/states', + }, + { + type: 'doc', + label: 'State manager', + id: 'explanations/state_manager', }, { type: 'doc', + label: 'Validators and Access Nodes', + id: 'explanations/validators', + }, + { + type: 'doc', + label: 'Consensus', + id: 'explanations/consensus', + }, + { + type: 'doc', + label: 'How Accounts Work', + id: 'explanations/how-accounts-work', + }, + { + type: 'link', + label: 'Core Contracts', + href: '/isc/reference/core-contracts/overview', + }, + ], + }, + + { + type: 'category', + label: 'How To', + collapsed: false, + items: [ + { + type: 'category', + label: 'EVM', + collapsed: false, + items: [ + { + type: 'doc', + label: 'Use EVM in ISC', + id: 'how-tos/EVM/using', + }, + { + type: 'doc', + label: 'Create a Basic Solidity Contract', + id: 'how-tos/EVM/create-a-basic-contract', + }, + { + type: 'doc', + label: 'Create Custom Tokens - ERC20', + id: 'how-tos/EVM/ERC20', + }, + { + type: 'doc', + label: 'Create NFTs - ERC721', + id: 'how-tos/EVM/ERC721', + }, + ], + }, + { + type: 'category', + label: 'Use the Magic Contract', + items: [ + { + type: 'doc', + label: 'Use the Magic Contract', + id: 'how-tos/use-the-magic-contract/magic', + }, + { + type: 'doc', + label: 'Send Tokens to L1', + id: 'how-tos/use-the-magic-contract/send-tokens-to-l1', + }, + { + type: 'doc', + label: 'Deposit To a Chain', + id: 'how-tos/use-the-magic-contract/deposit-to-a-chain', + }, + { + type: 'doc', + label: 'Withdraw From a Chain', + id: 'how-tos/use-the-magic-contract/withdraw-from-a-chain', + }, + { + type: 'doc', + label: 'View Account Balances', + id: 'how-tos/use-the-magic-contract/view-account-balances', + }, + ], + }, + { + type: 'category', + label: 'Manage ISC Chains', + items: [ + { + id: 'how-tos/manage-chains/wasp-cli', + label: 'Configure wasp-cli', + type: 'doc', + }, + { + id: 'how-tos/manage-chains/setting-up-a-chain', + label: 'Set Up a Chain', + type: 'doc', + }, + { + id: 'how-tos/manage-chains/chain-management', + label: 'Manage a Chain', + type: 'doc', + }, + ], + }, + { + 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: 'Wasm VM (experimental)', + items: [ + { + type: 'doc', + label: 'The Schema Tool', + id: 'how-tos/wasm/introduction', + }, + { + type: 'doc', + label: 'Create a Schema', + id: 'how-tos/wasm/usage', + }, + { + type: 'doc', + label: 'Define the State', + id: 'how-tos/wasm/state', + }, + { + type: 'doc', + label: 'Use Structured Data Types', + id: 'how-tos/wasm/structs', + }, + { + type: 'doc', + label: 'Generate Type Definitions', + id: 'how-tos/wasm/typedefs', + }, + { + type: 'doc', + label: 'Trigger Events', + id: 'how-tos/wasm/events', + }, + { + type: 'doc', + label: 'Define Functions', + id: 'how-tos/wasm/funcs', + }, + { + type: 'doc', + label: 'Limit Access', + id: 'how-tos/wasm/access', + }, + { + type: 'doc', + label: 'Define Function Parameters', + id: 'how-tos/wasm/params', + }, + { + type: 'doc', + label: 'Define Function Results', + id: 'how-tos/wasm/results', + }, + { + type: 'doc', + label: 'Use Thunk Functions', + id: 'how-tos/wasm/thunks', + }, + { + type: 'doc', + label: 'Use View-Only Functions', + id: 'how-tos/wasm/views', + }, + { + type: 'doc', + label: 'Initialize a Smart Contract', + id: 'how-tos/wasm/init', + }, + { + type: 'doc', + label: 'Transfer Tokens', + id: 'how-tos/wasm/transfers', + }, + { + type: 'doc', + label: 'Add Function Descriptors', + id: 'how-tos/wasm/funcdesc', + }, + { + type: 'doc', + label: 'Call Functions', + id: 'how-tos/wasm/call', + }, + { + type: 'doc', + label: 'Post Asynchronous Requests', + id: 'how-tos/wasm/post', + }, + ], + }, + ], + }, + { + type: 'category', + label: 'Reference', + items: [ + 'reference/json-rpc-spec', + 'reference/magic-contract', + { + type: 'category', label: 'Core Contracts', - id: 'explanations/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: 'doc', - label: 'ISC Functionality', - id: 'explanations/isc-functionality', + label: 'WasmLib Data Types', + id: 'reference/wasm-lib-data-types', }, ], }, diff --git a/docs/build/wasp-cli/v1.0.0-rc.6/sidebars.js b/docs/build/wasp-cli/v1.0.0-rc.6/sidebars.js deleted file mode 100644 index f7c2d3c88e5..00000000000 --- a/docs/build/wasp-cli/v1.0.0-rc.6/sidebars.js +++ /dev/null @@ -1,41 +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 - tutorialSidebar: [ - { - type: 'category', - label: 'How To', - collapsed: false, - items: [ - { - type: 'doc', - label: 'Configure wasp-cli', - id: 'how-tos/wasp-cli', - }, - { - type: 'doc', - label: 'Set Up a Chain', - id: 'how-tos/setting-up-a-chain', - }, - { - type: 'doc', - label: 'Manage a Chain', - id: 'how-tos/chain-management', - }, - ], - }, - ], -}; diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md deleted file mode 100644 index e70ea5e060f..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatibility.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Compatibility between the ISC EVM layer and existing Ethereum smart contracts and tooling. -image: /img/logo/WASP_logo_dark.png -keywords: - - smart contracts - - EVM - - Ethereum - - Solidity - - limitations - - compatibility - - fees - - reference ---- - -# EVM Compatibility in IOTA Smart Contracts - -The [`evm`](../reference/core-contracts/evm.md) [core contract](../reference/core-contracts/overview.md) -provides EVM support in IOTA Smart Contracts. It stores the EVM state (account balances, state, code, -etc.) and provides a way to execute EVM code to manipulate the state. - -The EVM core contract runs on top of the ISC layer, which provides the rest of the machinery needed to run smart -contracts, such as signed requests, blocks, state, proofs, etc. - -However, the ISC EVM layer is also designed to be as compatible as possible with existing Ethereum tools -like [MetaMask](https://metamask.io/), which assume that the EVM code runs on an Ethereum blockchain composed of -Ethereum blocks containing Ethereum transactions. Since ISC works in a fundamentally different way, -providing 100% compatibility is not possible. We do our best to emulate the behavior of an Ethereum node, so the -Ethereum tools think they are interfacing with an actual Ethereum node, but some differences in behavior are inevitable. - -## Properties and Limitations - -:::warning - -There is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). Because of this, when sending native tokens in the EVM, which are expressed in wei (ether = 1018wei), the last 12 decimal places will be ignored. - -Example: 1,999,999,999,999,999,999 wei = 1.999,999 SMR/MIOTA - -::: - -Here are some of the most important properties and limitations of EVM support in IOTA Smart Contracts: - -### Wrapped Calls to the JSON-RPC - -The Wasp node provides a JSON-RPC service, the standard protocol used by Ethereum tools. Upon receiving a signed -Ethereum transaction via JSON-RPC, the transaction is wrapped into an ISC -[off-ledger request](/learn/smart-contracts/invocation#off-ledger-requests). The sender of the request -is the Ethereum address that signed the original transaction (e.g., the Metamask account). - -### Contract ID Source - -While ISC contracts are identified by an [hname](/learn/smart-contracts/smart-contract-anatomy), EVM contracts are -identified by their Ethereum address. - -### WASM Root Contract List - -EVM contracts are not listed in the chain's [contract registry](../reference/core-contracts/root.md). - -### On-ledger Requests - -EVM contracts cannot be called via regular ISC requests; they can only be called through the JSON-RPC service. -As a consequence, EVM contracts cannot receive [on-ledger requests](/learn/smart-contracts/invocation#on-ledger-requests). - -### Block Structure and Storage - -Unlike Ethereum's blockchain that houses the state in a Merkle tree, the EVM state resides in a raw form to prevent the -duplication of efforts undertaken by the ISC layer. - -Any Ethereum transactions present in an ISC block are executed by -the [`evm`](../reference/core-contracts/evm.md) [core contract](../reference/core-contracts/overview.md), -updating the EVM state accordingly. An emulated Ethereum block is also created and stored to provide compatibility -with EVM tools. As the emulated block is not part of a real Ethereum blockchain, some attributes of the blocks will -contain dummy values (e.g. `stateRoot`, `nonce`, etc.). - -Each stored block contains the executed Ethereum transactions and corresponding Ethereum receipts. If storage is -limited, you can configure EVM so that only the latest N blocks are stored. - -### No Enforced Block Time - -There is no guaranteed _block time_. A new EVM "block" will be created only when an ISC block is created, and ISC does -not enforce an average block time. This means that block times are variable; a new block will be created as soon as needed. The average block time in the [Public Testnet](/build/networks-endpoints#public-testnet) is 8.4 seconds. - -### L2 Token Ownership - -In the IOTA Smart Contract chain, both IOTA and Ethereum addresses are a valid `AgentID`, facilitating the ownership of L2 -tokens. - -### Retrieving the Ethereum Balance - -The Ethereum balance of an account is tied to its L2 ISC balance in the token used to pay for gas. For example, -by default `eth_getBalance` will return the L2 base token balance of the given Ethereum account. - -### The Magic Contract - -A [dedicated Ethereum contract](../how-tos/magic-contract/magic.md) exists to manage ISC tokens and generally avail ISC -functionalities, introducing commands like `isc.send(...)` for token transfers. - -### Gas Fees - -The used EVM gas is converted to ISC gas before being charged to the sender. The conversion ratio is configurable. The -token used to pay for gas is the L1's base token. The gas fee is debited from -the sender's L2 account and must be deposited beforehand. diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md deleted file mode 100644 index e0107ff2358..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/getting-started/compatible-tools.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -description: 'Existing EVM tooling is compatible and can be used directly with an IOTA Smart Contracts chain running EVM. -You can configure hardhat, metamask, remix, Ether.js and Web3.js among others.' -image: /img/logo/WASP_logo_dark.png -keywords: - -- smart contracts -- chain -- EVM -- Solidity -- tooling -- wasp-cli -- hardhat -- metamask -- JSON-RPC -- reference - ---- - -# Compatible Tools - -EVM on IOTA Smart Contracts has been integrated in a way that the existing EVM tooling is compatible and can be used -directly with an IOTA Smart Contracts chain running EVM as long as you take a couple of things into account. - -## 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. - -:::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 -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). - -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): - -- Network Name: `Public Testnet` -- New RPC URL: `https://json-rpc.evm.testnet.shimmer.network/` -- Chain ID: `1073` -- Currency Symbol: `SMR` -- Block Explorer URL: `https://explorer.evm.testnet.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. - -If you wish to use additional EVM chains with Metamask, you can add more Custom RPC networks, as long as they have a -unique `Chain ID` and `RPC Url`. Once you have done this, you can start using MetaMask to manage your EVM wallet or -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. - -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`. - -[![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 - - - -## Hardhat - -[Hardhat](https://hardhat.org/) is a command line toolbox that allows you to deploy, test, verify, and interact with -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], - }, -} -``` - -:::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. - -::: - -### Video Tutorial - - - -## Ethers.js/Web3.js - -If you input the correct configuration parameters for the JSON-RPC endpoint to talk -to, [Ethers.js](https://docs.ethers.io/) and [Web3.js](https://web3js.readthedocs.io/) are also compatible with EVM -chains on IOTA Smart Contracts. Alternatively, you can let both interact through MetaMask instead so that it uses the -network configured in MetaMask. For more information on this, read their documentation. - -## Other Tooling - -Most tools available will be compatible if you enter the correct `Chain ID` and `RPC Url`. diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-function.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-function.md deleted file mode 100644 index 25d1c74cf69..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-function.md +++ /dev/null @@ -1,22 +0,0 @@ -# Call a Function - -In the example above, `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](/learn/smart-contracts/sandbox) `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/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-native-contract.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-native-contract.md deleted file mode 100644 index a6330f3ad27..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/magic-contract/call-a-native-contract.md +++ /dev/null @@ -1,25 +0,0 @@ -# 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-evm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx b/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx deleted file mode 100644 index 09771af0901..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/how-tos/view-account-balances.mdx +++ /dev/null @@ -1,170 +0,0 @@ ---- -description: The Accounts contract provides the balance, totalAssets and accounts views. -image: /img/logo/WASP_logo_dark.png -keywords: - - smart contracts - - view - - account - - balances - - Rust - - Solo - - how to ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# View Account Balances - -The Accounts contract provides the following views: - -## `balance` - -Get the account balance of a specific account. - -### Parameters - -- `ParamAgentID`: account's AgentID. - -### Returns - -A map of `token ID -> amount` (the base token is identified by an empty token ID). - -### Examples - - - - -```go -balances := chain.L2Assets(agentID) -``` - - - - -```go -b := coreaccounts.ScFuncs.Balance(ctx) -b.Params.AgentID().SetValue(agentID) -b.Func.Call() -require.NoError(t, ctx.Err) -balances := b.Results.Balances() -``` - - - - -```rust -let b = coreaccounts::ScFuncs::balance(ctx); -b.params.agent_id().set_value(&agentID); -b.func.call(); -let balances = b.results.balances(); -``` - - - - -```go -b := coreaccounts.ScFuncs.Balance(ctx) -b.Params.AgentID().SetValue(agentID) -b.Func.Call() -balances := b.Results.Balances() -``` - - - - ---- - -## `totalAssets` - -Get the total funds controlled by the chain. - -### Returns - -- A map of [token_color] -> [amount] . - - - - -```go -balances := chain.L2TotalAssets() -``` - - - - -```go -b := coreaccounts.ScFuncs.TotalAssets(ctx) -b.Func.Call() -require.NoError(t, ctx.Err) -balances := b.Results.Balances() -``` - - - - -```rust -let b = coreaccounts::ScFuncs::total_assets(ctx); -b.func.call(); -let balances = b.results.balances(); -``` - - - - -```go -b := coreaccounts.ScFuncs.TotalAssets(ctx) -b.Func.Call() -balances := b.Results.Balances() -``` - - - - ---- - -## `accounts` - -Get a list of all accounts that exist on the chain. - -### Returns - -A list of accounts (Agent IDs). - - - - -```go -accounts := chain.L2Accounts() -``` - - - - -```go -a := coreaccounts.ScFuncs.Accounts(ctx) -a.Func.Call() -require.NoError(t, ctx.Err) -accounts := a.Results.AllAccounts() -``` - - - - -```rust -let a = coreaccounts::ScFuncs::accounts(ctx); -a.func.call(); -let accounts = a.results.all_accounts(); -``` - - - - -```go -a := coreaccounts.ScFuncs.Accounts(ctx) -a.Func.Call() -accounts := a.Results.AllAccounts() -``` - - - diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/introduction.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/introduction.md deleted file mode 100644 index 2bf139a2de8..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/introduction.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -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 -keywords: - -- EVM -- Solidity -- smart contracts -- Ethereum -- explanation - ---- - -# EVM/Solidity Based Smart Contracts - -:::caution - -Smart Contracts are currently only compatible with the [Stardust protocol](/learn/protocols/stardust/introduction) and -therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) and -[Public Testnet networks](/build/networks-endpoints/#public-testnet). - -::: - -The current release of IOTA Smart Contracts has support for [EVM](https://ethereum.org/en/developers/docs/evm/)/[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart -contracts, as well as [Wasm](/wasp-wasm/introduction/) smart contracts, providing limited 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. - -### 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 implementations. - -[Solidity](https://soliditylang.org/) is the programming language of choice with EVM, which was created for this -specific purpose. - -The main benefit of using EVM/Solidity right now is its sheer amount of resources from years of development andf -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 probably need no (or very minimal) -changes to function on IOTA Smart Contracts. - -### How IOTA Smart Contracts Work With EVM - -Every deployed IOTA Smart Contracts 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. diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md deleted file mode 100644 index af6f4a9552e..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/blocklog.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -description: The `blocklog` contract keeps track of the blocks of requests processed by the chain. -image: /img/logo/WASP_logo_dark.png -keywords: - - core contracts - - blocklog - - views - - information - - request status - - receipts - - events - - reference ---- - -# The `blocklog` Contract - -The `blocklog` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. - -The `blocklog` contract keeps track of the blocks of requests processed by the chain, providing views to get request -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/). - ---- - -## Entry Points - -### `retryUnprocessable(u requestID)` - -Tries to retry a given request that was marked as "unprocessable". - -:::note -"Unprocessable" requests are on-ledger requests that do not include enough base tokens to cover the deposit fees (example if an user tries to deposit many native tokens in a single output but only includes the minimum possible amount of base tokens). Such requests will be collected into an "unprocessable list" and users are able to deposit more funds onto their on-chain account and retry them afterwards. -::: - -#### Parameters - -- `u` ([`isc::RequestID`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)): The requestID to be retried. (sender of the retry request must match the sender of the "unprocessable" request) - ---- - -## Views - -### `getBlockInfo(n uint32)` - -Returns information about the block with index `n`. - -#### Parameters - -- `n`: (optional `uint32`) The block index. Default: the latest block. - -#### Returns - -- `n` (`uint32`):The block index. -- `i` ([`BlockInfo`](#blockinfo)):The information about the block. - -### `getRequestIDsForBlock(n uint32)` - -Returns a list with all request IDs in the block with block index `n`. - -#### Parameters - -- `n` (optional `uint32`):The block index. The default value is the latest block. - -#### Returns - -- `n` (`uint32`):The block index. -- `u`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) - of [`RequestID`](#requestid)) - -### `getRequestReceipt(u RequestID)` - -Returns the receipt for the request with the given ID. - -#### Parameters - -- `u` ([`RequestID`](#requestid)):The request ID. - -#### Returns - -- `n` (`uint32`):The block index. -- `r` (`uint16`):The request index within the block. -- `d` ([`RequestReceipt`](#requestreceipt)):The request receipt. - -### `getRequestReceiptsForBlock(n uint32)` - -Returns all the receipts in the block with index `n`. - -#### Parameters - -- `n` (optional `uint32`):The block index. Defaults to the latest block. - -#### Returns - -- `n` (`uint32`):The block index. -- `d`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) - of [`RequestReceipt`](#requestreceipt)) - -### `isRequestProcessed(u RequestID)` - -Returns whether the request with ID `u` has been processed. - -#### Parameters - -- `u` ([`RequestID`](#requestid)):The request ID. - -#### Returns - -- `p` (`bool`):Whether the request was processed or not. - -### `getEventsForRequest(u RequestID)` - -Returns the list of events triggered during the execution of the request with ID `u`. - -### Parameters - -- `u` ([`RequestID`](#requestid)):The request ID. - -#### Returns - -- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`). - -### `getEventsForBlock(n blockIndex)` - -Returns the list of events triggered during the execution of all requests in the block with index `n`. - -#### Parameters - -- `n` (optional `uint32`):The block index. Defaults to the latest block. - -#### Returns - -- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`). - -### `getEventsForContract(h Hname)` - -Returns a list of events triggered by the smart contract with hname `h`. - -#### Parameters - -- `h` (`hname`):The smart contract’s hname. -- `f` (optional `uint32` - default: `0`):"From" block index. -- `t` (optional `uint32` - default: `MaxUint32`):"To" block index. - -#### Returns - -- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`) - -### `hasUnprocessable(u requestID)` - -Asserts whether or not a given requestID (`u`) is present in the "unprocessable list" - -#### Parameters - -- `u` ([`isc::RequestID`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)): The requestID to be checked - -#### Returns - -- `x` ([`bool`]) Whether or not the request exists in the "unprocessable list" - ---- - -## Schemas - -### `RequestID` - -A `RequestID` is encoded as the concatenation of: - -- Transaction ID (`[32]byte`). -- Transaction output index (`uint16`). - -### `BlockInfo` - -`BlockInfo` is encoded as the concatenation of: - -- The block timestamp (`uint64` UNIX nanoseconds). -- Amount of requests in the block (`uint16`). -- Amount of successful requests (`uint16`). -- Amount of off-ledger requests (`uint16`). -- Anchor transaction ID ([`iotago::TransactionID`](https://github.com/iotaledger/iota.go/blob/develop/transaction.go)). -- Anchor transaction sub-essence hash (`[32]byte`). -- Previous L1 commitment (except for block index 0). - - Trie root (`[20]byte`). - - Block hash (`[20]byte`). -- Total base tokens in L2 accounts (`uint64`). -- Total storage deposit (`uint64`). -- Gas burned (`uint64`). -- Gas fee charged (`uint64`). - -### `RequestReceipt` - -`RequestReceipt` is encoded as the concatenation of: - -- Gas budget (`uint64`). -- Gas burned (`uint64`). -- Gas fee charged (`uint64`). -- The request ([`isc::Request`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)). -- Whether the request produced an error (`bool`). -- If the request produced an error, the - [`UnresolvedVMError`](./errors.md#unresolvedvmerror). diff --git a/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md b/docs/build/wasp-evm/v1.0.0-rc.6/docs/reference/core-contracts/evm.md deleted file mode 100644 index a64b943658d..00000000000 --- a/docs/build/wasp-evm/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 -keywords: - -- 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](../../how-tos/magic-contract/magic.md). - -:::note - -For more information about how ISC supports EVM contracts, refer to the [EVM](../../introduction.md) 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-evm/v1.0.0-rc.6/sidebars.js b/docs/build/wasp-evm/v1.0.0-rc.6/sidebars.js deleted file mode 100644 index c47ea7f167c..00000000000 --- a/docs/build/wasp-evm/v1.0.0-rc.6/sidebars.js +++ /dev/null @@ -1,177 +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 - evmSidebar: [ - { - type: 'doc', - label: 'Introduction', - id: 'introduction', - }, - { - type: 'category', - label: 'Getting Started', - items: [ - { - type: 'doc', - label: 'Quickstart', - id: 'getting-started/quickstart', - }, - { - type: 'doc', - label: 'Compatible Tools', - id: 'getting-started/compatible-tools', - }, - { - type: 'doc', - label: 'Compatibility & Limitations', - id: 'getting-started/compatibility', - }, - ], - }, - { - type: 'category', - label: 'Explanations', - items: [ - { - type: 'doc', - label: 'How Accounts Work', - id: 'explanations/how-accounts-work', - }, - ], - }, - { - type: 'category', - label: 'How To', - items: [ - { - type: 'doc', - label: 'Use EVM in ISC', - id: 'how-tos/using', - }, - { - type: 'doc', - label: 'Create a Basic Contract', - id: 'how-tos/create-a-basic-contract', - }, - { - type: 'doc', - label: 'Create Custom Tokens', - id: 'how-tos/ERC20', - }, - { - type: 'doc', - label: 'Create NFTs', - id: 'how-tos/ERC721', - }, - { - type: 'category', - label: 'Use the Magic Contract', - items: [ - { - type: 'doc', - label: 'Introduction', - id: 'how-tos/magic-contract/magic', - }, - { - type: 'doc', - label: 'Call a Function', - id: 'how-tos/magic-contract/call-a-function', - }, - { - type: 'doc', - label: 'Call a Native Contract', - id: 'how-tos/magic-contract/call-a-native-contract', - }, - { - type: 'doc', - label: 'Send Tokens to L1', - id: 'how-tos/magic-contract/send-tokens-to-l1', - }, - { - 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: 'Reference', - items: [ - 'reference/json-rpc-spec', - 'reference/magic-contract', - { - 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', - }, - ], - }, - ], - }, - ], -}; diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md deleted file mode 100644 index cf485279079..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/explanations/how-accounts-work.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -description: 'IOTA Smart Contracts chains keeps a ledger of on-chain account balances. On-chain accounts are identified -by an AgentID.' -image: /img/tutorial/accounts.png -keywords: - -- smart contracts -- on-chain account -- ownership -- accounts Contract -- explanation - ---- - -# How Accounts Work - -On the L1 Ledger, like with any _DLT_, we have **trustless** and **atomic** transfers of assets between addresses on the -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 -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_. - -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. - -## Types of Accounts - -### L1 Address - -Any L1 address can be the owner of a L2 account. -The Agent ID of an L1 address is just the address, - -e.g. `iota1pr7vescn4nqc9lpvv37unzryqc43vw5wuf2zx8tlq2wud0369hjjugg54mf`. - -Tokens in an address account can only be moved through a request signed by the private key of the L1 address. - -### 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). -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 -example: `cebf5908@tgl1pzehtgythywhnhnz26s2vtpe2wy4y64pfcwkp9qvzhpwghzxhwkps2tk0nd`. - -Note that this allows trustless transfers of assets between smart contracts on the same or different chains. - -Tokens in a smart contract account can only be moved by that smart contract. - -### The Common Account - -The chain owns a unique L2 account, called the _common account_. -The common account is controlled by the chain owner (defined in the chain root contract) and is used to store funds -collected by fees or sent to the chain L1 address. - -The Agent ID of the common account is `@
`. - -### Ethereum Address - -An L2 account can also be owned by an Ethereum address. See [EVM](/wasp-evm/introduction/) for more information. -The Agent ID of an Ethereum address is just the address prefixed with `0x`, -e.g. `0xd36722adec3edcb29c8e7b5a47f352d701393462`. - -Tokens in an Ethereum account can only be moved by sending an Ethereum transaction signed by the same address. - -## The Accounts Contract - -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) - -## Example - -The following diagram illustrates an example situation. -The 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) - -Two chains are deployed, with IDs `chainA` and `chainB`. -`chainA` has two smart contracts on it (with hnames `3037` and `2225`), and `chainB` has one smart contract (`7003`). - -There is also an address on the L1 Ledger: `iota1a2b3c4d`. -This address controls 1337 base tokens and 42 `Red` native tokens on the L1 Ledger. - -The same address also controls 42 base tokens on `chainA` and 8 `Green` native tokens on `chainB`. - -So, the owner of the private key behind the address controls three different accounts: the L1 account and one L2 account -on each chain. - -Smart contract `7003@chainB` has five base tokens on its native chain and controls eleven base tokens on chain A. diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx deleted file mode 100644 index e88da4ca3ea..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/deposit-to-a-chain.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -description: The `deposit` entry point credits the transferred tokens into your on-chain account. -image: /img/logo/WASP_logo_dark.png -keywords: - - smart contracts - - deposit - - transfer - - chain - - Rust - - Solo - - how to ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# How to Deposit to a Chain - -Any assets attached to an on-ledger request are automatically deposited to the sender's L2 account before executing the -request. -So, to deposit tokens, you only need to send _any_ on-ledger request with the tokens attached. - -A commonly needed operation is to only deposit some funds and do nothing else. -The `deposit` entry point of the [`accounts` core contract](../reference/core-contracts/accounts.md) is a no-op function that serves -this purpose. - -:::note Gas Fees - -All requests are charged a gas fee, so the L2 account may receive fewer tokens than the amount sent. - -::: - -:::info Storage Deposits - -The IOTA L1 transaction needs a minimum amount of tokens attached for -storage deposit. It will fail if the amount transferred is less than this minimum amount. - -::: - - - - -```go -// deposits N base tokens from wallet into chain -err := chain.DepositBaseTokensToL2(N, wallet) -require.NoError(t, err) -``` - - - - -```go -// deposits N base tokens from wallet into chain -d := coreaccounts.ScFuncs.Deposit(ctx.Sign(wallet)) -d.Func.TransferBaseTokes(N).Post() -require.NoError(t, ctx.Err) -``` - - - - -```rust -// deposits N iotas from wallet into chain -let d = coreaccounts::ScFuncs::deposit(ctx.sign(wallet)); -d.func.transfer_base_tokens(N).post(); -``` - - - - -```go -// deposits N iotas from wallet into chain -d := coreaccounts.ScFuncs.Deposit(ctx.Sign(wallet)) -d.Func.TransferBaseTokens(N).Post() -``` - - - diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx deleted file mode 100644 index c348e414ebe..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/how-tos/withdraw-from-a-chain.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -description: The `withdraw` endpoint sends L2 funds owned by the caller to their L1 address. -image: /img/logo/WASP_logo_dark.png -keywords: - - smart contracts - - withdraw - - transfer - - chain - - Rust - - Solo - - how to ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# How to Withdraw From a Chain - -The `withdraw` endpoint sends L2 funds owned by the caller to their L1 address. - - - - -```go -// withdraw from chain to wallet -req := solo.NewCallParams(accounts.Contract.Name, accounts.FuncWithdraw.Name) -_, err := chain.PostRequestSync(req.WithMaxAffordableGasBudget(), wallet) -require.NoError(t, err) -``` - - - - -```go -// withdraw from chain to wallet -w := coreaccounts.ScFuncs.Withdraw(ctx.Sign(wallet)) -w.Func.Post() -require.NoError(t, ctx.Err) -``` - - - - -```rust -// withdraw from chain to wallet -let w = coreaccounts::ScFuncs::withdraw(ctx.sign(wallet)); -w.func.post(); -``` - - - - -```go -// withdraw from chain to wallet -w := coreaccounts.ScFuncs.Withdraw(ctx.sign(wallet)) -w.Func.Post() -``` - - - diff --git a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/introduction.mdx b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/introduction.mdx deleted file mode 100644 index e1f4b0f8f64..00000000000 --- a/docs/build/wasp-wasm/v1.0.0-rc.6/docs/introduction.mdx +++ /dev/null @@ -1,71 +0,0 @@ ---- -description: "Get to know IOTA Smart Contracts' flexible programming with Wasm VM, supporting a secure and dynamic smart contract development environment." -keywords: - - IOTA Smart Contracts - - Wasm VM - - Smart contract development - - WasmLib - - Supported languages -image: /img/wasm_vm/IscHost.png ---- - -# Introduction to the Wasm VM for ISC - -:::warning -The Wasm _VM_ is in experimental state, showcasing ISC's "VM plugin" architecture. - -Experiment but avoid using it for production applications; opt for [EVM](/wasp-evm/introduction). -::: - -:::caution - -Smart Contracts are currently only compatible with the [Stardust protocol](/learn/protocols/stardust/introduction) and -therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) and -[Public Testnet networks](/build/networks-endpoints/#public-testnet). - -::: - -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) - -We offer a VM example utilizing [WebAssembly (Wasm)](https://webassembly.org/) 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. - -## Video Tutorial - - 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 8adc3dc1d5d..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 -keywords: - - 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 2c3e84e3bfa..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 -keywords: - - 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 d3d3db383a8..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 -keywords: - -- 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/governance.md b/docs/build/wasp-wasm/v1.0.0-rc.6/docs/reference/core-contracts/governance.md deleted file mode 100644 index f38555a6af9..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 -keywords: - -- 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 57b046eca50..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 -keywords: - - 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 9ff834a509f..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 -keywords: - -- 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 9f4cde0dd3c..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 -keywords: - - 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 3e2d26ca502..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 -keywords: - - 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/smart-contracts/invocation.md b/docs/learn/smart-contracts/invocation.md index d0040378057..20570963605 100644 --- a/docs/learn/smart-contracts/invocation.md +++ b/docs/learn/smart-contracts/invocation.md @@ -87,7 +87,7 @@ etc.) has an associated gas cost. 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](/isc/reference/core-contracts/governance#fee-policy). The funds to cover the gas used will be charged directly from the user's on-chain account. diff --git a/docs/learn/smart-contracts/sandbox.md b/docs/learn/smart-contracts/sandbox.md index d0c70b8e2d7..a81175a7be9 100644 --- a/docs/learn/smart-contracts/sandbox.md +++ b/docs/learn/smart-contracts/sandbox.md @@ -30,14 +30,14 @@ their internal state as a list of key/value pairs. 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](/isc/explanations/how-accounts-work) 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](/isc/how-tos/wasm/events) 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/learn/smart-contracts/smart-contract-anatomy.md index 1aaa6b03be0..c285bc10a14 100644 --- a/docs/learn/smart-contracts/smart-contract-anatomy.md +++ b/docs/learn/smart-contracts/smart-contract-anatomy.md @@ -16,7 +16,7 @@ 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](/isc/getting-started/languages-and-vms#wasm-vm-for-isc) and [EVM/Solidity](/isc/getting-started/languages-and-vms#evmsolidity-based-smart-contracts) smart contracts coexisting on the same chain. The logical structure of IOTA Smart Contracts is independent of the _VM_ type: @@ -27,7 +27,7 @@ The logical structure of IOTA Smart Contracts is independent of the _VM_ type: 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 +For example, the hname of the [`root`](/isc/reference/core-contracts/root/) core contract is `0xcebf5908`. This value uniquely identifies this contract in every chain. @@ -49,7 +49,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](https://wiki.iota.org/build/wasp-wasm/how-accounts-work/) for more information on sending and receiving +See [Accounts](/isc/explanations/how-accounts-work/) for more information on sending and receiving tokens. ## Entry Points @@ -68,7 +68,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`](/isc/reference/core-contracts/blocklog/) 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/validators.md b/docs/learn/smart-contracts/validators.md index 07e1ea7633c..c598a5f471c 100644 --- a/docs/learn/smart-contracts/validators.md +++ b/docs/learn/smart-contracts/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](/isc/reference/core-contracts/governance/). diff --git a/docs/maintain/getting-started/welcome.md b/docs/maintain/getting-started/welcome.md index b5e2718a22a..6c71bc0b53f 100644 --- a/docs/maintain/getting-started/welcome.md +++ b/docs/maintain/getting-started/welcome.md @@ -22,6 +22,6 @@ 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 +You can use the documentation to get your node up and running, and [set up](/isc/how-tos/manage-chains/setting-up-a-chain/) and +[manage](/isc/how-tos/manage-chains/chain-management) a chain, or check out the available [configuration options](/wasp/configuration). diff --git a/src/components/HomeLayout/AppLibrariesSection.tsx b/src/components/HomeLayout/AppLibrariesSection.tsx index 5030f8457e0..ce430f88ce6 100644 --- a/src/components/HomeLayout/AppLibrariesSection.tsx +++ b/src/components/HomeLayout/AppLibrariesSection.tsx @@ -132,7 +132,7 @@ const LibrariesSection: FC = () => (

Learn about ISC diff --git a/tutorials/docusaurus.config.js b/tutorials/docusaurus.config.js index 1198616502a..88f2e010577 100644 --- a/tutorials/docusaurus.config.js +++ b/tutorials/docusaurus.config.js @@ -37,7 +37,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: '/isc/how-tos/manage-chains/setting-up-a-chain', tags: ['text', 'video'], }, ], @@ -48,7 +48,8 @@ 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: + '/isc/how-tos/manage-chains/setting-up-a-chain#deploying-a-wasm-contract', tags: ['text', 'video'], }, ], @@ -59,7 +60,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'], }, ], @@ -70,7 +71,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/how-tos/wasm/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 7e908af33cf..995bbf32465 100644 --- a/versionedConfig.js +++ b/versionedConfig.js @@ -34,45 +34,45 @@ 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.', - icon: 'SmartContracts', - subsection: 'build-layer-2', - versions: [ - { - label: 'v1.0.0-rc.6', - badges: ['Shimmer'], - }, - ], - }, + // { + // 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.', + // icon: 'SmartContracts', + // subsection: 'build-layer-2', + // versions: [ + // { + // label: 'v1.0.0-rc.6', + // badges: ['Shimmer'], + // }, + // ], + // }, { id: 'identity-rs', routeBasePath: 'identity.rs',