From b22d92847cdb424f398a7e5d94b6fd57d609d3a3 Mon Sep 17 00:00:00 2001 From: charlesthompson3 Date: Fri, 3 Dec 2021 11:06:15 +0100 Subject: [PATCH] Updated ISCP to IOTA Smart Contracts --- documentation/docs/contribute.md | 3 +-- .../chains_and_nodes/chain-management.md | 1 - .../docs/guide/chains_and_nodes/publisher.md | 1 - .../guide/chains_and_nodes/running-a-node.md | 1 - .../chains_and_nodes/setting-up-a-chain.md | 5 ++-- .../docs/guide/chains_and_nodes/testnet.md | 1 - .../docs/guide/chains_and_nodes/wasp-cli.md | 1 - .../accounts/how-accounts-work.md | 17 ++++++------ .../accounts/how-to-deposit-to-a-chain.mdx | 2 +- .../accounts/how-to-withdraw-from-a-chain.mdx | 2 +- .../accounts/the-common-account.mdx | 2 +- .../accounts/view-account-balances.mdx | 2 +- .../docs/guide/core_concepts/consensus.md | 7 +++-- .../core_concepts/core_contracts/accounts.md | 2 +- .../core_concepts/core_contracts/blob.md | 2 +- .../core_concepts/core_contracts/blocklog.md | 2 +- .../core_concepts/core_contracts/default.md | 4 +-- .../core_contracts/governance.md | 2 +- .../core_concepts/core_contracts/overview.md | 2 +- .../core_concepts/core_contracts/root.md | 2 +- .../guide/core_concepts/iscp-architecture.md | 11 ++++---- .../docs/guide/core_concepts/iscp.md | 11 ++++---- .../docs/guide/core_concepts/sandbox.md | 3 +-- .../core_concepts/smart-contract-anatomy.md | 3 +-- .../guide/core_concepts/smart-contracts.md | 3 +-- .../off-ledger-requests.md | 2 +- .../on-ledger-requests.md | 8 +++--- .../docs/guide/core_concepts/states.md | 3 +-- .../docs/guide/core_concepts/validators.md | 1 - documentation/docs/guide/evm/create-chain.md | 12 ++++----- .../docs/guide/evm/examples/ERC20.md | 3 +-- .../docs/guide/evm/examples/introduction.md | 3 +-- documentation/docs/guide/evm/introduction.md | 11 ++++---- documentation/docs/guide/evm/limitations.md | 12 ++++----- documentation/docs/guide/evm/tooling.md | 14 +++++----- .../guide/example_projects/fair_roulette.md | 3 +-- documentation/docs/guide/schema/call.mdx | 4 +-- documentation/docs/guide/schema/init.mdx | 2 +- documentation/docs/guide/schema/test.mdx | 10 +++---- documentation/docs/guide/schema/transfers.mdx | 6 ++--- documentation/docs/guide/schema/views.mdx | 8 +++--- documentation/docs/guide/solo/balances.md | 4 +-- documentation/docs/guide/solo/invoking-sc.md | 4 +-- .../docs/guide/solo/reimbursed-funds.md | 2 +- .../docs/guide/solo/sending-funds-sc.md | 2 +- documentation/docs/guide/wasm_vm/context.mdx | 2 +- documentation/docs/guide/wasm_vm/intro.mdx | 26 +++++++++---------- documentation/docs/guide/wasm_vm/proxies.mdx | 16 ++++++------ documentation/docs/guide/wasm_vm/types.mdx | 21 +++++++-------- documentation/docs/misc/accounts.md | 6 ++--- documentation/docs/misc/coretypes.md | 10 +++---- documentation/docs/misc/docker.md | 1 - documentation/docs/misc/utxo.md | 2 +- documentation/docs/overview.md | 9 +++---- documentation/docs/rfc/prevent-mev.md | 6 ++--- documentation/docs/rfc/replay-off-ledger.md | 8 +++--- documentation/docs/tutorial/01.md | 12 ++++----- documentation/docs/tutorial/03.md | 6 ++--- documentation/docs/tutorial/05.md | 2 +- documentation/docs/tutorial/06.md | 4 +-- documentation/docs/tutorial/08.md | 4 +-- documentation/docs/tutorial/10.md | 2 +- documentation/docs/tutorial/12.md | 14 +++++----- documentation/docs/tutorial/readme.md | 8 +++--- documentation/docs/welcome.md | 8 +++--- 65 files changed, 175 insertions(+), 198 deletions(-) diff --git a/documentation/docs/contribute.md b/documentation/docs/contribute.md index 223b69b475..de1bc72b62 100644 --- a/documentation/docs/contribute.md +++ b/documentation/docs/contribute.md @@ -1,13 +1,12 @@ --- keywords: -- ISCP - Smart Contracts - Contribute - Pull Request - Linting - Go-lang - golangci-lint -description: How to contribute to ISCP. Creating a PR, setting up golangci-lint. +description: How to contribute to IOTA Smart Contracts. Creating a PR, setting up golangci-lint. image: /img/logo/WASP_logo_dark.png --- diff --git a/documentation/docs/guide/chains_and_nodes/chain-management.md b/documentation/docs/guide/chains_and_nodes/chain-management.md index cbcee7134e..287d12976c 100644 --- a/documentation/docs/guide/chains_and_nodes/chain-management.md +++ b/documentation/docs/guide/chains_and_nodes/chain-management.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - Chain - Management diff --git a/documentation/docs/guide/chains_and_nodes/publisher.md b/documentation/docs/guide/chains_and_nodes/publisher.md index 527b3edb50..e63290f97b 100644 --- a/documentation/docs/guide/chains_and_nodes/publisher.md +++ b/documentation/docs/guide/chains_and_nodes/publisher.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Publisher - Nanomsg - Messages diff --git a/documentation/docs/guide/chains_and_nodes/running-a-node.md b/documentation/docs/guide/chains_and_nodes/running-a-node.md index f8e8922df9..e15d5ccfd7 100644 --- a/documentation/docs/guide/chains_and_nodes/running-a-node.md +++ b/documentation/docs/guide/chains_and_nodes/running-a-node.md @@ -2,7 +2,6 @@ description: How to run a node. Requirements, configuration parameters, dashboard configuration and tests. image: /img/logo/WASP_logo_dark.png keywords: -- ISCP - Smart Contracts - Running a node - Go-lang diff --git a/documentation/docs/guide/chains_and_nodes/setting-up-a-chain.md b/documentation/docs/guide/chains_and_nodes/setting-up-a-chain.md index cb0f07f2d6..b10f009ea2 100644 --- a/documentation/docs/guide/chains_and_nodes/setting-up-a-chain.md +++ b/documentation/docs/guide/chains_and_nodes/setting-up-a-chain.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - Chain - Set up @@ -94,9 +93,9 @@ After you have requested the funds, you can deposit funds to a chain by running: wasp-cli chain deposit IOTA:10000 ``` -### Deploy the ISCP Chain +### Deploy the IOTA Smart Contracts Chain -You can deploy your ISCP chain by running: +You can deploy your IOTA Smart Contracts chain by running: ```shell wasp-cli chain deploy --committee=0,1,2,3 --quorum=3 --chain=mychain --description="My chain" diff --git a/documentation/docs/guide/chains_and_nodes/testnet.md b/documentation/docs/guide/chains_and_nodes/testnet.md index 9f38d6a557..99330bfd81 100644 --- a/documentation/docs/guide/chains_and_nodes/testnet.md +++ b/documentation/docs/guide/chains_and_nodes/testnet.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - TestNet description: A public testnet for developers to try out smart contracts diff --git a/documentation/docs/guide/chains_and_nodes/wasp-cli.md b/documentation/docs/guide/chains_and_nodes/wasp-cli.md index a7bb37814e..d55984c240 100644 --- a/documentation/docs/guide/chains_and_nodes/wasp-cli.md +++ b/documentation/docs/guide/chains_and_nodes/wasp-cli.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Wasp-cli - Configuration - Goshimmer diff --git a/documentation/docs/guide/core_concepts/accounts/how-accounts-work.md b/documentation/docs/guide/core_concepts/accounts/how-accounts-work.md index 7fcf758b74..cd679165ca 100644 --- a/documentation/docs/guide/core_concepts/accounts/how-accounts-work.md +++ b/documentation/docs/guide/core_concepts/accounts/how-accounts-work.md @@ -1,17 +1,16 @@ --- keywords: -- ISCP - Smart Contracts - on-chain account - Ownership - Accounts Contract -description: ISCP chains keeps a ledger of on-chain account balances. ON-chain accounts are identified by an AgentID. +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 --- # How Accounts Work -ISCP provides secure, trustless transfers of digitized assets: +IOTA Smart Contracts provide secure, trustless transfers of digitized assets: - Between smart contracts on the same or different chains - Between smart contracts and L1 addresses on the UTXO Ledger @@ -21,7 +20,7 @@ transfers of assets between addresses on the ledger. The tokens contained in the address can be moved to another address by providing a valid signature using the private key which controls the source address. -In ISCP, the smart contracts which reside on chains are also owners of their +In IOTA Smart Contracts, the smart contracts which reside on chains are also owners of their tokens. Each smart contract can receive tokens that are transferred to it and can send tokens it controls to any other owner, be it another smart contract, or an ordinary L1 address on the UTXO Ledger. @@ -29,7 +28,7 @@ contract, or an ordinary L1 address on the UTXO Ledger. There are 2 types of entities that can control tokens: * L1 addresses on the UTXO Ledger -* Smart contracts on ISCP chains +* Smart contracts on IOTA Smart Contracts chains There are 3 different types of trustless token transfers possible between those entities. Each type involves a different mechanism of transfer: @@ -44,16 +43,16 @@ To make the system homogenous, we introduce the following two concepts: owning entity. * `On-chain account`: Represents the unit of ownership on the chain. -Each ISCP chain keeps a ledger of on-chain account balances +Each IOTA Smart Contracts chain keeps a ledger of on-chain account balances ## Account Ownership ### Smart Contract ID Unlike with blockchain systems like Ethereum, we cannot simply represent the -smart contract by a blockchain address: ISCP can have many blockchains. -Each chain in ISCP is identified by its _chain ID_. A chain can -contain many smart contracts on it. So, in ISCP each contract is identified by +smart contract by a blockchain address: IOTA Smart Contracts can have many blockchains. +Each chain in IOTA Smart Contracts is identified by its _chain ID_. A chain can +contain many smart contracts on it. So, in IOTA Smart Contracts, each contract is identified by an identifier that consists of the chain ID, and the _hname_ of the smart contract. In human-readable form, the smart _contract ID_ looks like this: diff --git a/documentation/docs/guide/core_concepts/accounts/how-to-deposit-to-a-chain.mdx b/documentation/docs/guide/core_concepts/accounts/how-to-deposit-to-a-chain.mdx index d3f7cafb96..ed7b20c0a0 100644 --- a/documentation/docs/guide/core_concepts/accounts/how-to-deposit-to-a-chain.mdx +++ b/documentation/docs/guide/core_concepts/accounts/how-to-deposit-to-a-chain.mdx @@ -1,6 +1,6 @@ --- keywords: -- ISCP +- Smart Contracts - deposit - transfer - chain diff --git a/documentation/docs/guide/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx b/documentation/docs/guide/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx index e7aa7dc93e..15eb9b603f 100644 --- a/documentation/docs/guide/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx +++ b/documentation/docs/guide/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx @@ -1,6 +1,6 @@ --- keywords: -- ISCP +- Smart Contracts - withdraw - transfer - chain diff --git a/documentation/docs/guide/core_concepts/accounts/the-common-account.mdx b/documentation/docs/guide/core_concepts/accounts/the-common-account.mdx index 291a29a279..766e51470d 100644 --- a/documentation/docs/guide/core_concepts/accounts/the-common-account.mdx +++ b/documentation/docs/guide/core_concepts/accounts/the-common-account.mdx @@ -1,6 +1,6 @@ --- keywords: -- ISCP +- Smart Contracts - deposit - transfer - chain diff --git a/documentation/docs/guide/core_concepts/accounts/view-account-balances.mdx b/documentation/docs/guide/core_concepts/accounts/view-account-balances.mdx index 5f6cb7b854..3b2a5b5bfd 100644 --- a/documentation/docs/guide/core_concepts/accounts/view-account-balances.mdx +++ b/documentation/docs/guide/core_concepts/accounts/view-account-balances.mdx @@ -1,6 +1,6 @@ --- keywords: - - ISCP + - Smart Contracts - view - account - balances diff --git a/documentation/docs/guide/core_concepts/consensus.md b/documentation/docs/guide/core_concepts/consensus.md index 503daa105a..8e37edfaa2 100644 --- a/documentation/docs/guide/core_concepts/consensus.md +++ b/documentation/docs/guide/core_concepts/consensus.md @@ -1,9 +1,8 @@ --- keywords: -- ISCP - Smart Contracts - Consensus -description: ISCP Consensus +description: IOTA Smart Contracts Consensus image: /img/logo/WASP_logo_dark.png --- # Consensus @@ -36,13 +35,13 @@ The anchor transaction contains chain state transition, the AliasOutput and toke **It is only possible to produce valid signatures of inputs of the anchor transaction by the quorum** of nodes. In this case, a confirmed anchor transaction becomes a cryptographical **proof of consensus** in the committee. -To archive this, ISCP uses **BLS threshold signatures in combination with polynomial (Shamir) secret sharing** to identify the address controlling the chain state. In order for the secret keys to be distributed across the chain validators, a DKG (Distributed Key Generation) procedure is executed when starting a chain (using the Rabin-Gennaro algorithm). +To archive this, IOTA Smart Contracts uses **BLS threshold signatures in combination with polynomial (Shamir) secret sharing** to identify the address controlling the chain state. In order for the secret keys to be distributed across the chain validators, a DKG (Distributed Key Generation) procedure is executed when starting a chain (using the Rabin-Gennaro algorithm). ## The Consensus Algorithm The committee is of fixed size, thus we use a Byzantine Fault Tolerant (BFT) Algorithm, which guarantees consistency and byzantine fault tolerance if less than ⅓ of nodes are malicious. -As a basis for the ISCP consensus, the Asynchronous Common Subset (ACS) part of the HoneyBadgerBFT algorithm is used, with the exception of how the proposals are combined. +As a basis for the IOTA Smart Contracts consensus, the Asynchronous Common Subset (ACS) part of the HoneyBadgerBFT algorithm is used, with the exception of how the proposals are combined. The rest of the consensus algorithm is built on top of the ACS. Each node supplies to the ACS its batch proposal which indicates a set of Request IDs, a timestamp, consensus and access mana pledge addresses, fee destination and a partial signature for generating non-forgeable entropy. Upon termination of the ACS, each honest node gets the same set of such proposals and aggregates them into the final batch in a deterministic way. diff --git a/documentation/docs/guide/core_concepts/core_contracts/accounts.md b/documentation/docs/guide/core_concepts/core_contracts/accounts.md index 3e19ad0dba..bc9ed78aa4 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/accounts.md +++ b/documentation/docs/guide/core_concepts/core_contracts/accounts.md @@ -11,7 +11,7 @@ keywords: --- # The `accounts` Contract -The `accounts` contract is one of the [core contracts](overview.md) on each ISCP +The `accounts` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The `accounts` contract keeps a consistent ledger of on-chain accounts in its state for the agents that control them. There are two types of agents who can do it: L1 addresses and smart contracts. diff --git a/documentation/docs/guide/core_concepts/core_contracts/blob.md b/documentation/docs/guide/core_concepts/core_contracts/blob.md index 0e39f49169..feec4eaac9 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/blob.md +++ b/documentation/docs/guide/core_concepts/core_contracts/blob.md @@ -12,7 +12,7 @@ keywords: --- # The `blob` Contract -The `blob` contract is one of the [core contracts](overview.md) on each ISCP chain. +The `blob` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The function of the `blob` contract is to maintain an on-chain registry of _blobs_, a collections of arbitrary binary data. Smart contracts reference _blobs_ via their hashes. diff --git a/documentation/docs/guide/core_concepts/core_contracts/blocklog.md b/documentation/docs/guide/core_concepts/core_contracts/blocklog.md index 1f20912ba7..e2f9d5b13b 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/blocklog.md +++ b/documentation/docs/guide/core_concepts/core_contracts/blocklog.md @@ -12,7 +12,7 @@ keywords: --- # The `blocklog` Contract -The `blocklog` contract is one of the [core contracts](overview.md) on each ISCP chain. +The `blocklog` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The function of the `blocklog` contract is to keep track of the blocks of requests that were processed by the chain. diff --git a/documentation/docs/guide/core_concepts/core_contracts/default.md b/documentation/docs/guide/core_concepts/core_contracts/default.md index 87a87b6c3e..bfd86fa9ef 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/default.md +++ b/documentation/docs/guide/core_concepts/core_contracts/default.md @@ -2,14 +2,14 @@ description: The function of the `_default` contract is to provide a fall-back target for any request that cannot be handled by the chain, or contract, it was addressed to image: /img/logo/WASP_logo_dark.png keywords: -- ISCP +- Smart Contracts - core contracts - default - fall-back --- # The `_default` Contract -The `_default` contract is one of the [core contracts](overview.md) on each ISCP +The `_default` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The function of the `_default` contract is to provide a fall-back target for any diff --git a/documentation/docs/guide/core_concepts/core_contracts/governance.md b/documentation/docs/guide/core_concepts/core_contracts/governance.md index 09e75a56d1..e48b42601a 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/governance.md +++ b/documentation/docs/guide/core_concepts/core_contracts/governance.md @@ -17,7 +17,7 @@ keywords: # The `governance` Contract -The `governance` contract is one of the [core contracts](overview.md) on each ISCP +The `governance` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The `governance` contract provides the following functionalities: diff --git a/documentation/docs/guide/core_concepts/core_contracts/overview.md b/documentation/docs/guide/core_concepts/core_contracts/overview.md index e48bbd5bcf..1749c80516 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/overview.md +++ b/documentation/docs/guide/core_concepts/core_contracts/overview.md @@ -2,7 +2,7 @@ description: There currently are 6 core smart contracts that are always deployed on each chain, root, _default, accounts, blob, blocklog, and governance. image: /img/logo/WASP_logo_dark.png keywords: -- ISCP +- Smart Contracts - core - initialization - request handling diff --git a/documentation/docs/guide/core_concepts/core_contracts/root.md b/documentation/docs/guide/core_concepts/core_contracts/root.md index 7e7321dbfd..e6213f56de 100644 --- a/documentation/docs/guide/core_concepts/core_contracts/root.md +++ b/documentation/docs/guide/core_concepts/core_contracts/root.md @@ -13,7 +13,7 @@ keywords: --- # The `root` Contract -The `root` contract is one of the [core contracts](overview.md) on each ISCP +The `root` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain. The `root` contract provides the following functions: diff --git a/documentation/docs/guide/core_concepts/iscp-architecture.md b/documentation/docs/guide/core_concepts/iscp-architecture.md index 9e45fb2ba6..667701e258 100644 --- a/documentation/docs/guide/core_concepts/iscp-architecture.md +++ b/documentation/docs/guide/core_concepts/iscp-architecture.md @@ -1,22 +1,21 @@ --- keywords: -- ISCP - Smart Contracts - Architecture - Ethereum - Implementation -description: ISCP allows anyone to start their own chain and validators. Link to full technical description of the ISCP architecture +description: IOTA Smart Contracts allow anyone to start their own chain and validators. Link to full technical description of the IOTA Smart Contracts architecture. image: /img/multichain.png --- -# ISCP Architecture +# IOTA Smart Contracts Architecture -With ISCP, anyone can start their own chain and define the validators. +With IOTA Smart Contracts, anyone can start their own chain and define the validators. Each chain has its own state where a state update (going from one block to the next) is hashed and published to the Tangle, which moves the state anchor on Layer 1. -The multi-chain nature of ISCP makes it a more complex implementation of smart contracts, over say Ethereum, as illustrated here: +The multi-chain nature of the IOTA Smart Contracts makes it a more complex implementation of smart contracts, over say Ethereum, as illustrated here: -![ISCP multichain architecture](/img/multichain.png) +![IOTA Smart Contracts multichain architecture](/img/multichain.png) A full and extensive documentation of the IOTA Architecture describing all components in detail can be found in this [technical description](https://github.com/iotaledger/wasp/raw/master/documentation/ISCP%20architecture%20description%20v3.pdf). diff --git a/documentation/docs/guide/core_concepts/iscp.md b/documentation/docs/guide/core_concepts/iscp.md index b74d6a9653..8bac4dbc0d 100644 --- a/documentation/docs/guide/core_concepts/iscp.md +++ b/documentation/docs/guide/core_concepts/iscp.md @@ -1,17 +1,16 @@ --- keywords: -- ISCP - Smart Contracts - scaling - fees - flexibility - Tangle -description: ISCP stands for IOTA Smart Contract Protocol and is IOTA's solution for running smart contracts on top of the IOTA tangle. Wasp is the node software we've built to let you run smart contracts in a committee using a virtual machine of choice. +description: IOTA Smart Contracts are IOTA's solution for running smart contracts on top of the IOTA tangle. Wasp is the node software we've built to let you run smart contracts in a committee using a virtual machine of choice. image: /img/logo/WASP_logo_dark.png --- -# ISCP +# IOTA Smart Contracts -ISCP stands for IOTA Smart Contract Protocol. It is IOTA's solution for running smart contracts on top of the IOTA tangle. With ISCP we bring scalable and flexible smart contracts into the IOTA ecosystem by allowing anyone to spin up a smart contract blockchain and anchor it to the IOTA tangle. +The IOTA Smart Contracts are IOTA's solution for running smart contracts on top of the IOTA tangle. With IOTA Smart Contracts, we bring scalable and flexible smart contracts into the IOTA ecosystem by allowing anyone to spin up a smart contract blockchain and anchor it to the IOTA tangle. Allowing multiple blockchains to anchor to the tangle will solve several problems with smart contracts. @@ -29,9 +28,9 @@ Given that anyone can start a new chain, and set the rules for that chain, a lot You can run multiple types of virtual machines on any chain. We are starting with [Rust/Wasm](https://rustwasm.github.io/docs/book/) based smart contracts, followed by -[Solidity/EVM](https://docs.soliditylang.org/en/v0.8.6/) based smart contracts, but eventually all kinds of virtual machines can be supported in a ISCP chain depending on the demand. +[Solidity/EVM](https://docs.soliditylang.org/en/v0.8.6/) based smart contracts, but eventually all kinds of virtual machines can be supported in IOTA Smart Contracts chain depending on the demand. -ISCP is more complex compared to conventional smart contracts, but this provides freedom and flexibility to allow the usage of smart contracts in a wide range of use cases. +The IOTA Smart Contracts is more complex compared to conventional smart contracts, but this provides freedom and flexibility to allow the usage of smart contracts in a wide range of use cases. ## What is Wasp? diff --git a/documentation/docs/guide/core_concepts/sandbox.md b/documentation/docs/guide/core_concepts/sandbox.md index a279562536..0c3b022c85 100644 --- a/documentation/docs/guide/core_concepts/sandbox.md +++ b/documentation/docs/guide/core_concepts/sandbox.md @@ -2,7 +2,6 @@ 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: -- ISCP - Smart Contracts - Sandbox - interface @@ -17,7 +16,7 @@ The Sandbox provides limited and deterministic access to the state through a key ![Sandbox](/img/sandbox.png) -Besides reading and writing to the contract state, the Sandbox interface allows Smart contracts to access: +Besides reading and writing to the contract state, the Sandbox interface allows smart contracts to access: - the AgentID of the contract - the details of the current function invocation (request or view call) diff --git a/documentation/docs/guide/core_concepts/smart-contract-anatomy.md b/documentation/docs/guide/core_concepts/smart-contract-anatomy.md index 69a699fcfa..2fc0a8d9af 100644 --- a/documentation/docs/guide/core_concepts/smart-contract-anatomy.md +++ b/documentation/docs/guide/core_concepts/smart-contract-anatomy.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - structure - State @@ -14,7 +13,7 @@ image: /img/tutorial/SC-structure.png Smart contracts are programs which are immutably stored in the chain. -The logical structure of an ISCP smart contract is independent of the VM type you +The logical structure of IOTA Smart Contracts is independent of the VM type you use, be it a _Wasm_ smart contract or any other VM type. ![Smart Contract Structure](/img/tutorial/SC-structure.png) diff --git a/documentation/docs/guide/core_concepts/smart-contracts.md b/documentation/docs/guide/core_concepts/smart-contracts.md index f96c27aff1..e9b7015f37 100644 --- a/documentation/docs/guide/core_concepts/smart-contracts.md +++ b/documentation/docs/guide/core_concepts/smart-contracts.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - blockchain - parallel @@ -24,4 +23,4 @@ Smart contracts are used for all kinds of purposes. A recurring reason to use a On a public blockchain, anyone willing to pay the fees for deploying a smart contract 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 assured 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 smart contracts 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 expensive fees for executing functions on smart contracts. **By allowing many blockchains executing smart contracts to run in parallel**, and communicate with one another, the **ISCP will solve this scalability problem.** +Because smart contracts do not run on a single computer, but on many validators, a network of smart contracts 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 expensive 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 will solve this scalability problem.** diff --git a/documentation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md b/documentation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md index 32b2293aef..970490261e 100644 --- a/documentation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md +++ b/documentation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md @@ -1,6 +1,6 @@ --- keywords: -- ISCP +- Smart Contracts - requests - off-ledger - node diff --git a/documentation/docs/guide/core_concepts/smartcontract-interaction/on-ledger-requests.md b/documentation/docs/guide/core_concepts/smartcontract-interaction/on-ledger-requests.md index 1764f1bfe8..59d03edc87 100644 --- a/documentation/docs/guide/core_concepts/smartcontract-interaction/on-ledger-requests.md +++ b/documentation/docs/guide/core_concepts/smartcontract-interaction/on-ledger-requests.md @@ -1,6 +1,6 @@ --- keywords: -- ISCP +- Smart Contracts - requests - on-ledger - tangle @@ -13,13 +13,13 @@ image: /img/tutorial/send_request.png # On-ledger Requests -Requests to the smart contract as transactions on the Tangle are called `on-ledger` requests. As they are simply posted by a transaction to the Tangle, they can be sent to any chain deployed on the Tangle without accessing a Wasp node. The ISCP committee is actively monitoring the Tangle and will be aware of the request. +Requests to the smart contract as transactions on the Tangle are called `on-ledger` requests. As they are simply posted by a transaction to the Tangle, they can be sent to any chain deployed on the Tangle without accessing a Wasp node. The IOTA Smart Contracts committee is actively monitoring the Tangle and will be aware of the request. [![Generic process of posting an on-ledger request to the smart contract](/img/tutorial/send_request.png)](/img/tutorial/send_request.png) ## Fees -Fees charged by the ISCP chain will be taken from this transaction, so be sure to send enough IOTAs to cover the fee, or the request will be rejected. +Fees charged by the IOTA Smart Contracts chain will be taken from this transaction, so be sure to send enough IOTAs to cover the fee, or the request will be rejected. ## Processing Order @@ -29,5 +29,5 @@ Requests are stored in the mempool and selected on a [random batch selection](.. By leveraging the `ExtendedLockedOutput`, it is possible to send requests with time constraints. -- **fallback**: By providing a `deadline` timestamp and a `fallback address` it is possible to post a request which, if not processed by the `deadline`, will not be picked-up by ISCP, and the funds will be spendable by the `fallback address`. +- **fallback**: By providing a `deadline` timestamp and a `fallback address` it is possible to post a request which, if not processed by the `deadline`, will not be picked-up by IOTA Smart Contracts, and the funds will be spendable by the `fallback address`. - **timelock**: By providing a `timelock` timestamp it is possible to post a request which will not be picked up until the `timelock` timestamp is passed. \ No newline at end of file diff --git a/documentation/docs/guide/core_concepts/states.md b/documentation/docs/guide/core_concepts/states.md index 3df21ae675..d5c960052c 100644 --- a/documentation/docs/guide/core_concepts/states.md +++ b/documentation/docs/guide/core_concepts/states.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - state - transitions - Balances @@ -54,7 +53,7 @@ The UTXO ledger guarantees that at every moment there is *exactly one* such outp The state output is controlled (i.e. can be unlocked/consumed) by the entity running the chain. -With the anchoring mechanism the UTXO ledger supports the ISCP chain the following ways: +With the anchoring mechanism the UTXO ledger supports the IOTA Smart Contracts chain the following ways: - Guarantees global consensus on the state of the chain - Makes the state immutable and tamper-proof diff --git a/documentation/docs/guide/core_concepts/validators.md b/documentation/docs/guide/core_concepts/validators.md index eb05184417..4ef0e653b1 100644 --- a/documentation/docs/guide/core_concepts/validators.md +++ b/documentation/docs/guide/core_concepts/validators.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Validators - consensus - state update diff --git a/documentation/docs/guide/evm/create-chain.md b/documentation/docs/guide/evm/create-chain.md index 10a615c38a..f35e3819c7 100644 --- a/documentation/docs/guide/evm/create-chain.md +++ b/documentation/docs/guide/evm/create-chain.md @@ -9,24 +9,24 @@ keywords: - metamask - JSON - RPC -description: Create, fund and deploy a new EVM Chain using ISCP. +description: Create, fund and deploy a new EVM Chain using IOTA Smart Contracts. image: /img/logo/WASP_logo_dark.png --- # Creating an EVM Chain -EVM chains run inside ISCP chains. So in order to start an EVM chain, you will first need to follow the steps to [start an ISCP chain](../chains_and_nodes/setting-up-a-chain.md), or use an existing ISCP chain to start the EVM chain on. +EVM chains run inside IOTA Smart Contracts chains. So in order to start an EVM chain, you will first need to follow the steps to [start an IOTA Smart Contracts chain](../chains_and_nodes/setting-up-a-chain.md), or use an existing IOTA Smart Contracts chain to start the EVM chain on. :::warning -**An ISCP chain can only contain 1 EVM chain contract**. If your ISCP chain already has an EVM chain contract, you should use that chain contract instead of creating a new one. +**An IOTA Smart Contracts chain can only contain 1 EVM chain contract**. If your IOTA Smart Contracts chain already has an EVM chain contract, you should use that chain contract instead of creating a new one. ::: -## 1. Create the ISCP Chain +## 1. Create the IOTA Smart Contracts Chain -If you don't have an ISCP chain, you should create one. To do so, follow the instructions [on setting up a chain](../chains_and_nodes/setting-up-a-chain.md). +If you don't have an IOTA Smart Contracts chain, you should create one. To do so, follow the instructions [on setting up a chain](../chains_and_nodes/setting-up-a-chain.md). -## 2. Fund Your Account on Your ISCP Chain +## 2. Fund Your Account on Your IOTA Smart Contracts Chain In order to deploy the EVM chain contract, you need to have some IOTA locked on your newly created chain to fund that action. To do this, run: diff --git a/documentation/docs/guide/evm/examples/ERC20.md b/documentation/docs/guide/evm/examples/ERC20.md index 322fdfcbef..57084d5630 100644 --- a/documentation/docs/guide/evm/examples/ERC20.md +++ b/documentation/docs/guide/evm/examples/ERC20.md @@ -1,7 +1,6 @@ --- title: ERC20 Example keywords: -- ISCP - IOTA - Smart Contracts - EVM @@ -45,7 +44,7 @@ You can change the token name `ExampleERC20Token` and the token symbol `EET`. ## 2. Compile -Go to the second tab and compile your smart Contract with the "Compile ERC20.sol" button. +Go to the second tab and compile your smart contract with the "Compile ERC20.sol" button. [![Compile ERC20.sol](./images/compile.png)](./images/compile.png) diff --git a/documentation/docs/guide/evm/examples/introduction.md b/documentation/docs/guide/evm/examples/introduction.md index ad18473975..13288578de 100644 --- a/documentation/docs/guide/evm/examples/introduction.md +++ b/documentation/docs/guide/evm/examples/introduction.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - EVM - Solidity @@ -10,7 +9,7 @@ image: /img/logo/WASP_logo_dark.png --- # Solidity Smart Contract Example -Solidity smart contracts on ISCP are compatible with Solidity smart contracts on any other network, so most smart contracts will work directly without any modification. To get a rough indication of how a simple Solidity smart contract looks like, see the example below: +Solidity smart contracts on IOTA Smart Contracts are compatible with Solidity smart contracts on any other network, so most smart contracts will work directly without any modification. To get a rough indication of how a simple Solidity smart contract looks like, see the example below: ```solidity diff --git a/documentation/docs/guide/evm/introduction.md b/documentation/docs/guide/evm/introduction.md index d56eeb3673..bd3f3c92b0 100644 --- a/documentation/docs/guide/evm/introduction.md +++ b/documentation/docs/guide/evm/introduction.md @@ -5,12 +5,12 @@ keywords: - Solidity - Smart Contracts - Ethereum -description: The current release of ISCP also has experimental support for EVM/Solidity,this means that existing smart contracts and tooling from other EVM based chains like Ethereum are fully compatible with EVM chains running on ISCP. +description: The current release of IOTA Smart Contracts also has experimental support for EVM/Solidity,this means that existing smart contracts and tooling from other EVM based chains like Ethereum are fully compatible with EVM chains running on IOTA Smart Contracts. image: /img/logo/WASP_logo_dark.png --- # EVM/Solidity Based Smart Contracts -The current release of ISCP has experimental support for EVM/Solidity smart contracts as well as Wasm based smart contracts. This means that existing smart contracts and tooling from other EVM based chains like Ethereum are fully compatible with EVM chains running on ISCP. This allows us to offer the existing ecosystem around EVM/Solidity a familiar alternative. +The current release of IOTA Smart Contracts has experimental support for EVM/Solidity smart contracts as well as Wasm based smart contracts. This means that existing smart contracts and tooling from other EVM based chains like Ethereum are fully compatible with EVM chains running on IOTA Smart Contracts. This allows us to offer the existing ecosystem around EVM/Solidity a familiar alternative. :::caution @@ -22,10 +22,9 @@ This experimental implementation currently does not have the ability yet to inte [EVM](https://ethereum.org/en/developers/docs/evm/) stands for "Ethereum Virtual Machine", which currently is the tried and proven virtual machine running most smart contract implementations. [Solidity](https://soliditylang.org/) is the programming language of choice with EVM, and has been created for this specific purpose. -The main benefit of using EVM/Solidity right now is the sheer amount of resources available from it from years of development and experimentation on Ethereum. There are many articles, tutorials, examples and tools available for EVM/Solidity, and the ISCP implementation is fully compatible with them. If you have experience developing on other EVM based chains you will feel right at home, and any existing contracts you've written will probably need no (or very minimal) changes to function on ISCP as well. +The main benefit of using EVM/Solidity right now is the sheer amount of resources available from it from years of development and experimentation on Ethereum. There are many articles, tutorials, examples and tools available for EVM/Solidity, and the IOTA Smart Contracts implementation is fully compatible with them. If you have experience developing on other EVM based chains you will feel right at home, and any existing contracts you've written will probably need no (or very minimal) changes to function on IOTA Smart Contracts as well. -### How ISCP Works With EVM +### How IOTA Smart Contracts Work With EVM -With ISCP, an EVM based chain runs inside an ISCP chain as an ISCP smart contract. Because of this, it is possible to run both Wasm based smart contracts and an EVM chain -in a single ISCP chain. We offer an EVM compatible JSON-RPC server as part of the `wasp-cli`, which allows you to connect to these EVM Chains using existing tooling like [MetaMask](https://metamask.io/), [Remix](https://remix.ethereum.org/) or [Hardhat](https://hardhat.org/). Deploying to a new EVM chain is as easy as pointing your tools to the address of your JSON-RPC gateway. +With IOTA Smart Contracts, an EVM based chain runs inside an IOTA Smart Contracts chain as an IOTA Smart Contracts smart contract. Because of this, it is possible to run both Wasm based smart contracts and an EVM chain in a single IOTA Smart Contracts chain. We offer an EVM compatible JSON-RPC server as part of the `wasp-cli`, which allows you to connect to these EVM Chains using existing tooling like [MetaMask](https://metamask.io/), [Remix](https://remix.ethereum.org/) or [Hardhat](https://hardhat.org/). Deploying to a new EVM chain is as easy as pointing your tools to the address of your JSON-RPC gateway. diff --git a/documentation/docs/guide/evm/limitations.md b/documentation/docs/guide/evm/limitations.md index 3e6aa19602..837c20a329 100644 --- a/documentation/docs/guide/evm/limitations.md +++ b/documentation/docs/guide/evm/limitations.md @@ -6,16 +6,16 @@ keywords: - limitations - fees - sand-boxed -description: EVM based smart contract limitations. The current implementation is fully sand-boxed and not aware of IOTA or ISCP. You start an EVM chain with a new supply of EVM specific tokens assigned to a single address... +description: EVM based smart contract limitations. The current implementation is fully sand-boxed and not aware of IOTA or IOTA Smart Contracts. You start an EVM chain with a new supply of EVM specific tokens assigned to a single address. image: /img/logo/WASP_logo_dark.png --- -# EVM Limitations within ISCP +# EVM Limitations within IOTA Smart Contracts -The current experimental EVM support for ISCP allows developers to get a preview of EVM based smart contract solutions on top of IOTA. There are some limitations you should be aware of at the time, which we will be addressing in the months to come: +The current experimental EVM support for IOTA Smart Contracts allows developers to get a preview of EVM based smart contract solutions on top of IOTA. There are some limitations you should be aware of at the time, which we will be addressing in the months to come: -- **The current implementation is fully sand-boxed and not aware of IOTA or ISCP**. It currently can not communicate with non-EVM smart contracts, nor can it interact with assets outside the EVM sandbox yet. +- **The current implementation is fully sand-boxed and not aware of IOTA or IOTA Smart Contracts**. It currently can not communicate with non-EVM smart contracts, nor can it interact with assets outside the EVM sandbox yet. - **You start an EVM chain with a new supply of EVM specific tokens assigned to a single address** (the main token on the chain which is used for gas as well, comparable to ETH on the Ethereum network). These new tokens are in no way connected to IOTA, or any other token, but are specific for that chain for now. -- **Because EVM runs inside an ISCP smart contract, any fees that need to be paid for that ISCP smart contract have to be taken into account** while invoking a function on that contract. To support this right now the JSON-RPC gateway uses the wallet account connected to it. +- **Because EVM runs inside an IOTA Smart Contracts smart contract, any fees that need to be paid for that IOTA Smart Contracts smart contract have to be taken into account** while invoking a function on that contract. To support this right now the JSON-RPC gateway uses the wallet account connected to it. - **You need to manually deposit some IOTA to the chain** you are using to be able to invoke these functions. We are planning to resolve this at a later phase in a more user-friendly way. -Overall these are temporary solutions, the next release of ISCP will see a lot of these improved or resolved. +Overall these are temporary solutions, the next release of the IOTA Smart Contracts will see a lot of these improved or resolved. diff --git a/documentation/docs/guide/evm/tooling.md b/documentation/docs/guide/evm/tooling.md index 7ed19625e9..ee957c8f09 100644 --- a/documentation/docs/guide/evm/tooling.md +++ b/documentation/docs/guide/evm/tooling.md @@ -9,18 +9,18 @@ keywords: - hardhat - metamask - JSON-RPC -description: Existing EVM tooling is compatible and can be used directly with an ISCP chain running EVM. You can configure hardhat, metamask, remix, Ether.js and Web3.js among others. +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 --- # EVM Tooling -EVM on ISCP has been integrated in a way that the existing EVM tooling is compatible, and can be used directly with an ISCP chain running EVM as long as a couple of things are taken into account. +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 a couple of things are taken into account. ## Tooling Considerations 1. Please make sure you use the correct JSON-RPC endpoint URL in your tooling for your chain. If you run locally this will simply be `localhost:8545`. 2. Please make sure you use the right `Chain ID` as configured while starting the JSON-RPC service. If you did not explicitly define this while starting the service, the default Chain ID will be `1074`. - 3. Fees are being handled on the ISCP chain level, not EVM level. Because of this, you can simply use a gas price of 0 on EVM level at this point in time. + 3. Fees are being handled on the IOTA Smart Contracts chain level, not EVM level. Because of this, you can simply use a gas price of 0 on EVM level at this point in time. :::caution @@ -30,7 +30,7 @@ Re-using an existing Chain ID is not recommended and can be a security risk. For ## Wasp-cli -The Wasp CLI has some very basic functionalities to manage an EVM chain. Given the compatibility with existing tooling, only the basics are covered to get started with ISCP and EVM. You can currently either run a JSON-RPC server, or deploy the EVM Chain itself on an ISCP chain. To see the available options and configuration parameters simply run: +The Wasp CLI has some very basic functionalities to manage an EVM chain. Given the compatibility with existing tooling, only the basics are covered to get started with IOTA Smart Contracts and EVM. You can currently either run a JSON-RPC server, or deploy the EVM Chain itself on an IOTA Smart Contracts chain. To see the available options and configuration parameters simply run: ```bash wasp-cli chain evm @@ -54,7 +54,7 @@ If you also want to use the [Remix IDE](https://remix.ethereum.org/) to deploy a ## Hardhat -[Hardhat](https://hardhat.org/) is a commandline toolbox that allows you to deploy, test, verify, and interact with Solidity smart contracts on an EVM chain. EVM chains running on ISCP are compatible with Hardhat; simply make sure you add the correct network parameters to your `hardhat.config.js`, for example: +[Hardhat](https://hardhat.org/) is a commandline 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: { @@ -69,14 +69,14 @@ networks: { :::caution -Currently, there is no validation service available for EVM/Solidity smart contracts on ISCP, which is often offered through block explorer API's. +Currently, there is no validation service available for EVM/Solidity smart contracts on IOTA Smart Contracts, which is often offered through block explorer API's. ::: ## Ethers.js/Web3.js -As long as you input the right 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 ISCP. Alternatively you can let both interact through MetaMask instead so that it uses the network as configured in MetaMask. For more information on this, read their documentation. +As long as you input the right 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 as configured in MetaMask. For more information on this, read their documentation. ## Other Tooling diff --git a/documentation/docs/guide/example_projects/fair_roulette.md b/documentation/docs/guide/example_projects/fair_roulette.md index ebb1362c85..a475b6e17f 100644 --- a/documentation/docs/guide/example_projects/fair_roulette.md +++ b/documentation/docs/guide/example_projects/fair_roulette.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - Rust - poc @@ -29,7 +28,7 @@ A round is running for a certain amount of time. In the example its 60 seconds. If no round is _active_ when a bet gets placed, the round gets initiated immediately. -The random number is generated by the native randomness of the ISCP consensus. +The random number is generated by the native randomness of the IOTA Smart Contracts consensus. It is unpredictable by anybody, including an individual validator node. Therefore the roulette is Fair. diff --git a/documentation/docs/guide/schema/call.mdx b/documentation/docs/guide/schema/call.mdx index 88edf44c71..1862449555 100644 --- a/documentation/docs/guide/schema/call.mdx +++ b/documentation/docs/guide/schema/call.mdx @@ -23,7 +23,7 @@ sandbox environment. Therefore, the only way to share data between smart contrac call each other is through function parameters and return values. Synchronous calls can only be made between contracts that are running on the same contract -chain. The ISCP host knows about all the contracts it is running on a chain, and therefore +chain. The IOTA Smart Contracts host knows about all the contracts it is running on a chain, and therefore is able to dispatch the call to the correct contract function. The function descriptor is used to specify the call parameters (if any) through its `params` proxy, and to invoke the function through its `func` interface. @@ -38,7 +38,7 @@ function to complete. After completion, it may access the returned values (if an the [`results` proxy](results.mdx) of the function descriptor. When calling a function from a View function, it is only possible to call other View -functions. The ScFuncs interface enforces this at compile-time through the ISCP function +functions. The ScFuncs interface enforces this at compile-time through the IOTA Smart Contracts function context that needs to be passed to the function that creates the function descriptor. Here's how a smart contract would tell a `dividend` contract on the same chain to divide diff --git a/documentation/docs/guide/schema/init.mdx b/documentation/docs/guide/schema/init.mdx index ba7e46e1b0..a87ea6601a 100644 --- a/documentation/docs/guide/schema/init.mdx +++ b/documentation/docs/guide/schema/init.mdx @@ -23,7 +23,7 @@ provided through an optional function named `init`. When provided, the `init` function will automatically be called immediately after the first time the contract has been deployed to the VM. Note that this is a one-time -initialization call, meant to be performed by the contract deployment mechanism. ISCP will +initialization call, meant to be performed by the contract deployment mechanism. IOTA Smart Contracts will prevent anyone else from calling this function ever again. So if you need to be able to reconfigure the contract later on, you will need to provide a separate configuration function, and guard it from being accessed by anyone else than properly authorized diff --git a/documentation/docs/guide/schema/test.mdx b/documentation/docs/guide/schema/test.mdx index f99c84b3b9..c1e97e9b9d 100644 --- a/documentation/docs/guide/schema/test.mdx +++ b/documentation/docs/guide/schema/test.mdx @@ -22,22 +22,22 @@ having to start nodes, set up a committee, and send transactions over the Tangle you can use Go's built-in test environment in combination with Solo to deploy chains and smart contracts and simulate transactions. -Solo directly interacts with the ISCP code, and uses all the data types that are -[defined in the ISCP code](https://github.com/iotaledger/wasp/blob/develop/documentation/docs/misc/coretypes.md) +Solo directly interacts with the IOTA Smart Contracts code, and uses all the data types that are +[defined in the IOTA Smart Contracts code](https://github.com/iotaledger/wasp/blob/develop/documentation/docs/misc/coretypes.md) directly. Because they run in a sandboxed environment our Wasm smart contracts cannot access these types directly. Therefore, WasmLib implements its [own versions](../wasm_vm/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 -solo environment the user also needed to know about the ISCP-specific data types and type +solo environment the user also needed to know about the IOTA Smart Contracts-specific data types and type conversion functions, and exactly how to properly pass such data in and out of smart contract function calls. This burdened the user with an unnecessary increased learning curve. With the introduction of the schema tool, 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 a new ISCP +and functions that they are already familiar with. To that end, we introduced a new IOTA Smart Contracts function context that specifically works with the Solo testing environment. We aimed to simplify the testing of smart contracts as much as possible, keeping the full Solo interface hidden as much as possible, but available when necessary. @@ -118,7 +118,7 @@ parameters through the `Params` proxy, and then either post the function request the function. Any results returned are extracted through the `Results` proxy, and returned by the wrapper. -There is hardly difference in the way the function interface is used with the ISCP +There is hardly difference in the way the function interface is used with the IOTA Smart Contracts function context in WasmLib and with the SoloContext. This makes for seamless testing of smart contracts. diff --git a/documentation/docs/guide/schema/transfers.mdx b/documentation/docs/guide/schema/transfers.mdx index 96ec7d47b5..104293d589 100644 --- a/documentation/docs/guide/schema/transfers.mdx +++ b/documentation/docs/guide/schema/transfers.mdx @@ -8,7 +8,7 @@ keywords: - incoming - tokens - incoming -description: There are two methods in the ISCP function context that deal with token balances. The balances() method can be used to determine the current total balance per token color. The incoming() method can be used to determine the amounts of incoming tokens per token color that were sent with the request to call the smart contract function. +description: There are two methods in the IOTA Smart Contracts function context that deal with token balances. The balances() method can be used to determine the current total balance per token color. The incoming() method can be used to determine the amounts of incoming tokens per token color that were sent with the request to call the smart contract function. image: /img/logo/WASP_logo_dark.png --- import Tabs from "@theme/Tabs" @@ -16,7 +16,7 @@ import TabItem from "@theme/TabItem" # Token Transfers -There are two methods in the ISCP function context that deal with token balances. The +There are two methods in the IOTA Smart Contracts function context that deal with token balances. The first one is the `balances()` method, which can be used to determine the current total balance per token color that is governed by the smart contract. The second one is the `incoming()` method, which can be used to determine the amounts of incoming tokens per @@ -29,7 +29,7 @@ smart contract's account. But, if any error occurs which causes the function to these incoming() tokens will be returned to where they came from, and it will be as if they were never sent to the smart contract. -There is also a `transfer_to_address()` method in the ISCP function context that can +There is also a `transfer_to_address()` method in the IOTA Smart Contracts function context that can transfer tokens from the smart contract account to any Tangle address. The tokens to be transferred are provided to the method through a special `ScTransfers` map proxy. We will be using the transfer_to_address() method in the dividend example to disperse the incoming diff --git a/documentation/docs/guide/schema/views.mdx b/documentation/docs/guide/schema/views.mdx index 04b7cad6d0..deaaba986e 100644 --- a/documentation/docs/guide/schema/views.mdx +++ b/documentation/docs/guide/schema/views.mdx @@ -1,10 +1,10 @@ --- keywords: - results -- ISCP function context +- Smart Contracts function context - view function - retrieve state -description: Views are smart contract functions that only allow you to retrieve state information about the smart contract They have a special, limited ISCP function context that does not allow them to change the smart contract state. +description: Views are smart contract functions that only allow you to retrieve state information about the smart contract. They have a special, limited IOTA Smart Contracts function context that does not allow them to change the smart contract state. image: /img/logo/WASP_logo_dark.png --- import Tabs from "@theme/Tabs" @@ -14,7 +14,7 @@ import TabItem from "@theme/TabItem" View-only functions, or Views for short, are smart contract functions that only allow you to _retrieve_ state information about the smart contract. They have a special, limited -ISCP function context that does not allow access to functionality that could result in +IOTA Smart Contracts function context that does not allow access to functionality that could result in changes to the smart contract state. This means that all access to the state storage will be through immutable proxies. It also means that they cannot receive or transfer tokens, because changes to the smart contract account are by definition state changes as well. @@ -117,7 +117,7 @@ export function viewGetFactor(ctx: wasmlib.ScViewContext, f: sc.GetFactorContext Return values are passed to the caller through the predefined `results` map associated -with the ISCP function context. Again, this works the same way as for Funcs, although +with the IOTA Smart Contracts function context. Again, this works the same way as for Funcs, although Funcs do not necessarily return values to the caller. The schema tool will set up a function-specific `results` structure with proxies to the result fields in this map. diff --git a/documentation/docs/guide/solo/balances.md b/documentation/docs/guide/solo/balances.md index a81ae1b74c..0cc87cc134 100644 --- a/documentation/docs/guide/solo/balances.md +++ b/documentation/docs/guide/solo/balances.md @@ -17,7 +17,7 @@ keywords: The example code can be found in the [Wasp repository](https://github.com/iotaledger/wasp/tree/develop/documentation/tutorial-examples). ::: -Each chain in _ISCP_ is a separate ledger, different from the UTXO ledger. +Each chain in the _IOTA Smart Contracts_ is a separate ledger, different from the UTXO ledger. Multiple chains add another dimension on top of the UTXO Ledger. Smart contracts can exchange assets between themselves on the same chain and also between different chains, as well as with addresses on the UTXO Ledger. We will skip explaining the whole picture for the time @@ -32,7 +32,7 @@ Ledger, the private key is represented by the address (the hash of the public key). That address holds balances of colored tokens. Those tokens are _controlled_ by the private key. -In ISCP we extend the concept of _address_ with the concept of `account`. An +In IOTA Smart Contracts, we extend the concept of _address_ with the concept of `account`. An `account` contains colored tokens just like an `address`. The `account` is located on some chain, and it is controlled by the same private key as the associated address. So, an address can control tokens on the UTXO Ledger diff --git a/documentation/docs/guide/solo/invoking-sc.md b/documentation/docs/guide/solo/invoking-sc.md index 9cac3b5144..39b181f0d9 100644 --- a/documentation/docs/guide/solo/invoking-sc.md +++ b/documentation/docs/guide/solo/invoking-sc.md @@ -43,7 +43,7 @@ is going on here. The diagram above depicts the generic process of posting an `on-ledger` request to the smart contract. The same picture is valid for the _Solo_ environment and for any other -requester which sends an `on-ledger` request to the smart contract, for example, the ISCP +requester which sends an `on-ledger` request to the smart contract, for example, the IOTA Smart Contracts wallet or another chain. Posting the request always consists of the steps below. Note that in Solo all 7 @@ -53,7 +53,7 @@ steps are carried out by the single call to `PostRequestSync`. and moves tokens. Each request transaction is a value transaction, it always moves at least one token. Therefore, each request transaction must be signed by the private key of the owner of the tokens: the requester. That securely - identifies each requester in ISCP. In Solo, the transaction is signed by the + identifies each requester in IOTA Smart Contracts. In Solo, the transaction is signed by the private key provided in the second parameter of the `PostRequestSync` call (see below). 2. Posting the request transaction to the Tangle and confirming it. In _Solo_ it diff --git a/documentation/docs/guide/solo/reimbursed-funds.md b/documentation/docs/guide/solo/reimbursed-funds.md index 7c568d8b38..c6fffcacc9 100644 --- a/documentation/docs/guide/solo/reimbursed-funds.md +++ b/documentation/docs/guide/solo/reimbursed-funds.md @@ -59,5 +59,5 @@ The programmer forgets the parameter `paramString` and the program panics: You can see that all sent 42 tokens are returned to the sender's address. -In case of panic in the smart contract for whatever reason, the fallback logic of the ISCP VM: +In case of panic in the smart contract for whatever reason, the fallback logic of the IOTA Smart Contracts VM: returns all tokens (minus fees) to the sender (to the sender's address in the example above). diff --git a/documentation/docs/guide/solo/sending-funds-sc.md b/documentation/docs/guide/solo/sending-funds-sc.md index 6b4549a7ea..f6c5856f64 100644 --- a/documentation/docs/guide/solo/sending-funds-sc.md +++ b/documentation/docs/guide/solo/sending-funds-sc.md @@ -11,7 +11,7 @@ keywords: - withdrawIota - transfer_to_address --- -# Sending Tokens From ISCP to the Tangle +# Sending Tokens From IOTA Smart Contracts to the Tangle The programmer of the `example` smart contract implemented the entry point `withdrawIota`. What it is for? The answer is: if not for this method, any tokens sent to the diff --git a/documentation/docs/guide/wasm_vm/context.mdx b/documentation/docs/guide/wasm_vm/context.mdx index 7f5d52f836..5f8572e03b 100644 --- a/documentation/docs/guide/wasm_vm/context.mdx +++ b/documentation/docs/guide/wasm_vm/context.mdx @@ -20,7 +20,7 @@ is now time to introduce the gateway to the host that allows you to access the functionality that the host sandbox interface provides. We call this gateway the _function call context_ , and it is provided as a predefined parameter to the smart contract function. In fact, you can -distinguish two separate flavors of smart contract functions in the ISCP: +distinguish two separate flavors of smart contract functions in the IOTA Smart Contracts: - **Func**, which allows full mutable access to the smart contract state, and always results in a state update. diff --git a/documentation/docs/guide/wasm_vm/intro.mdx b/documentation/docs/guide/wasm_vm/intro.mdx index 296cb413d6..1177a97023 100644 --- a/documentation/docs/guide/wasm_vm/intro.mdx +++ b/documentation/docs/guide/wasm_vm/intro.mdx @@ -10,23 +10,23 @@ keywords: - Access - store - state -description: The Iota Smart Contracts Protocol (ISCP) provides a very flexible way of programming smart contracts by providing an API to a sandboxed environment that allows you to interact with the ISCP deterministically without any security risks. +description: IOTA Smart Contracts provide a very flexible way of programming smart contracts by providing an API to a sandboxed environment that allows you to interact with IOTA Smart Contracts deterministically without any security risks. image: /img/wasm_vm/IscpHost.png --- -# Introduction to the Wasm VM for ISCP +# Introduction to the Wasm VM for IOTA Smart Contracts -The Iota Smart Contracts Protocol (ISCP) provides a very flexible way of +IOTA Smart Contracts provide a very flexible way of programming smart contracts by providing an API to a sandboxed environment -that allows you to interact with the ISCP deterministically without any security risks. +that allows you to interact with the IOTA Smart Contracts deterministically without any security risks. The API provides a generic way to store, access, and modify the state of the smart contract. The API can be used by any kind of Virtual Machine (VM) to implement a system to -program, load, and run smart contracts on top of the ISCP. The actual VMs can be +program, load, and run smart contracts on top of IOTA Smart Contracts. The actual VMs can be implemented by whoever wants to create them. -[![Wasp node ISCP Host](/img/wasm_vm/IscpHost.png)](/img/wasm_vm/IscpHost.png) +[![Wasp node IOTA Smart Contracts Host](/img/wasm_vm/IscpHost.png)](/img/wasm_vm/IscpHost.png) Of course, we provide an example implementation of such a VM to allow anyone to get -a taste of what it is like to program a smart contract for the ISCP. Our VM implementation +a taste of what it is like to program a smart contract for IOTA Smart Contracts. Our VM implementation uses [WebAssembly](https://webassembly.org/) (Wasm) code as an intermediate compilation target. The implementation of the Wasm VM currently uses the open-source [Wasmtime](https://wasmtime.dev/) runtime environment. The Wasm VM enables dynamic @@ -40,7 +40,7 @@ Because each Wasm code unit runs in its own memory space and cannot access anyth outside that memory by design, Wasm code is ideally suited for secure smart contracts. The Wasm runtime system will only provide access to external functionality that is needed for the smart contracts to be able to do their thing, but nothing more. In our case, we -only provide access to the ISCP host's sandbox API environment. The way we do that is by +only provide access to the IOTA Smart Contracts host's sandbox API environment. The way we do that is by providing a simple library that can be linked to the Wasm code. This library, for obvious reasons, has been named `WasmLib` for now. @@ -48,14 +48,14 @@ obvious reasons, has been named `WasmLib` for now. As you can see we can have any number of smart contracts running in our Wasm VM. Each smart contract is a separately compiled Wasm code unit that contains its own copy of -WasmLib embedded into it. Each WasmLib provides the ISCP sandbox functionality to its +WasmLib embedded into it. Each WasmLib provides the IOTA Smart Contracts sandbox functionality to its corresponding smart contract and knows how to access the underlying smart contract state -storage through the VM runtime system. This makes ISCP sandbox API access seamless to the +storage through the VM runtime system. This makes the IOTA Smart Contracts sandbox API access seamless to the smart contract by hiding the details of bridging the gap between the smart contract's -memory space, and the ISCP host's memory space. It also prevents the smart contract from -accessing and/or modifying the ISCP host's memory space directly. +memory space, and the IOTA Smart Contracts host's memory space. It also prevents the smart contract from +accessing and/or modifying the IOTA Smart Contracts host's memory space directly. -The ISCP sandbox environment enables the following functionality: +The IOTA Smart Contracts sandbox environment enables the following functionality: - Access to smart contract metadata - Access to parameter data for smart contract function calls diff --git a/documentation/docs/guide/wasm_vm/proxies.mdx b/documentation/docs/guide/wasm_vm/proxies.mdx index 3ac69d760f..0f5b8bf9ad 100644 --- a/documentation/docs/guide/wasm_vm/proxies.mdx +++ b/documentation/docs/guide/wasm_vm/proxies.mdx @@ -7,27 +7,27 @@ keywords: - container proxies - array proxies - map proxies -description: As there is no way for the Wasm code to access any memory outside its own memory space, the WasmLib interface provides a number of proxies to make accessing data within the ISCP sandbox as seamless as possible. +description: As there is no way for the Wasm code to access any memory outside its own memory space, the WasmLib interface provides a number of proxies to make accessing data within the IOTA Smart Contracts sandbox as seamless as possible. image: /img/wasm_vm/Proxies.png --- # Data Access Proxies -As we cannot call the ISCP sandbox functions directly, we need a library to access the +As we cannot call the IOTA Smart Contracts sandbox functions directly, we need a library to access the sandbox functionality. There is no way for the Wasm code to access any memory outside -its own memory space. Therefore, any data that is governed by the ISCP sandbox has to be +its own memory space. Therefore, any data that is governed by the IOTA Smart Contracts sandbox has to be copied in and out of that memory space through well-defined protected channels in the Wasm runtime system. To make this whole process as seamless as possible the WasmLib interface uses so-called `proxies`. Proxies are objects that can perform the underlying data transfers between the separate systems. Proxies are like data references in that regard, they refer to the -actual objects or values stored on the ISCP host, and know how to manipulate them. Proxies +actual objects or values stored on the IOTA Smart Contracts host, and know how to manipulate them. Proxies provide a consistent interface to access the smart contract data. ## Value Proxies The most basic proxies are value proxies. They refer to a single value instance stored on -the ISCP host. All values are stored as key/value pairs in container objects on the ISCP +the IOTA Smart Contracts host. All values are stored as key/value pairs in container objects on the IOTA Smart Contracts host. Value proxies refer to their values through an object id and key id combination that uniquely defines the value's location in the container object. @@ -36,7 +36,7 @@ uniquely defines the value's location in the container object. To keep things as simple and understandable as possible these are limited to only two different kinds. Array proxies and map proxies. Because we allow nesting of container objects, these are enough to be able to define quite complex data structures. The -underlying ISCP sandbox provides access to its data in the form of simple key/value stores +underlying IOTA Smart Contracts sandbox provides access to its data in the form of simple key/value stores that can have arbitrary byte data for both key and value. WasmLib provides an abstraction on top of this one-dimensional storage system that supports nesting of maps and arrays, very similar to the way objects in YAML or JSON can be nested. @@ -59,7 +59,7 @@ moment. [![Proxies in WasmLib](/img/wasm_vm/Proxies.png)](/img/wasm_vm/Proxies.png) -In this example we have a single map in ISCP state storage that contains a number of +In this example we have a single map in the IOTA Smart Contracts state storage that contains a number of key/value combinations (Key 1 through Key 4). One of them (Key 4) refers to an array, which in turn contains indexed values stored at indexes 0 through N. Notice how the WasmLib proxies mirror these exactly. There is a container proxy for every @@ -69,7 +69,7 @@ identifies the value it references through the container id of the container it the key id (or index) that correlates to its position in the container. Note that despite the one-to-one correspondence in the example it is not necessary for a -smart contract function to define a proxy for every value or container in ISCP state +smart contract function to define a proxy for every value or container in the IOTA Smart Contracts state storage. In practice a function will only define proxies to data that it actually needs to access. diff --git a/documentation/docs/guide/wasm_vm/types.mdx b/documentation/docs/guide/wasm_vm/types.mdx index 194654fc9d..b566b545af 100644 --- a/documentation/docs/guide/wasm_vm/types.mdx +++ b/documentation/docs/guide/wasm_vm/types.mdx @@ -1,12 +1,11 @@ --- keywords: -- ISCP - data types - WasmLib - array - proxies - map -description: The WasmLib provides direct support for the basic value data types that are found in all programming languages, and WasmLib version of ISCP-specific value data types. +description: The WasmLib provides direct support for the basic value data types that are found in all programming languages, and WasmLib version of IOTA Smart Contracts-specific value data types. image: /img/logo/WASP_logo_dark.png --- # WasmLib Data Types @@ -22,22 +21,22 @@ direct support for the following value data types: - `Bytes` - An arbitrary-length byte array. - `String` - An UTF-8 encoded string value. -## ISCP-specific Value Data Types +## IOTA Smart Contracts-specific Value Data Types - `Address` - A 33-byte Tangle address. -- `AgentID` - A 37-byte ISCP Agent ID. -- `ChainID` - A 33-byte ISCP Chain ID. +- `AgentID` - A 37-byte IOTA Smart Contracts Agent ID. +- `ChainID` - A 33-byte IOTA Smart Contracts Chain ID. - `Color` - A 32-byte token color ID. -- `ContractID` - A 37-byte ISCP smart contract ID. +- `ContractID` - A 37-byte IOTA Smart Contracts smart contract ID. - `Hash` - A 32-byte hash value. - `Hname` - A 4-byte unsigned integer hash value derived from a name string. - `RequestID` - A 34-byte transaction request ID. The first group consists of the basic value data types that are found in all programming -languages, whereas the second group consists of WasmLib versions of ISCP-specific value +languages, whereas the second group consists of WasmLib versions of IOTA Smart Contracts-specific value data types. More detailed explanations about their specific uses can be found in the -[ISCP documentation](https://github.com/iotaledger/wasp/blob/develop/documentation/docs/misc/coretypes.md) -. WasmLib provides its own implementations for each of the ISCP value data types. They can +[IOTA Smart Contracts documentation](https://github.com/iotaledger/wasp/blob/develop/documentation/docs/misc/coretypes.md) +. WasmLib provides its own implementations for each of the IOTA Smart Contracts value data types. They can all be serialized into and deserialized from a byte array. Each value data type can also be used as a key in key/value maps. @@ -52,8 +51,8 @@ in two flavors that reflect this, and makes sure the data can only be used as in rule is that from an immutable container proxy you can only derive immutable container and value proxies. The referenced data can never be changed through immutable proxies. Separating these constraints for types into separate proxy types allows the use of -compile-time type-checking to enforce these constraints. To guard against client code that tries to bypass -them, the ISCP sandbox will also check these constraints at runtime on the host. +compile-time type-checking to enforce these constraints. To guard against client code that tries to bypass +them, the IOTA Smart Contracts sandbox will also check these constraints at runtime on the host. ## Full Matrix of WasmLib Types (excluding array proxies) diff --git a/documentation/docs/misc/accounts.md b/documentation/docs/misc/accounts.md index a1f5cedb53..1fca85154f 100644 --- a/documentation/docs/misc/accounts.md +++ b/documentation/docs/misc/accounts.md @@ -1,14 +1,14 @@ # On-chain accounts -ISCP introduces the concept of _on-chain account_. Each chain maintains a list +IOTA Smart Contracts introduces the concept of _on-chain account_. Each chain maintains a list of pairs: `: `. Each pair is an account with its colored balances. -**Any agent ID on the ISCP network may have an account on any chain**. In +**Any agent ID on the IOTA Smart Contracts network may have an account on any chain**. In other words, any smart contract and any ordinary address on the network can have account on any chain. -ISCP ensures that the tokens owned by the chain address may be moved to another +IOTA Smart Contracts ensures that the tokens owned by the chain address may be moved to another location only by the entity represented by the corresponding agent ID. The system requires cryptographically secure authorization to move funds between on-chain accounts. diff --git a/documentation/docs/misc/coretypes.md b/documentation/docs/misc/coretypes.md index ded898dede..70b6d513c6 100644 --- a/documentation/docs/misc/coretypes.md +++ b/documentation/docs/misc/coretypes.md @@ -1,13 +1,13 @@ # Core types All core types used in the Wasp code are defined in the -[`iscp`](https://github.com/iotaledger/wasp/tree/master/packages/iscp) +[`IOTA Smart Contracts`](https://github.com/iotaledger/wasp/tree/master/packages/iscp) package. ## Chain ID -ISCP allows running multiple blockchains, called _smart contract chains_, _contract chains_ or just +IOTA Smart Contracts allows running multiple blockchains, called _smart contract chains_, _contract chains_ or just _chains_ on the Tangle in parallel. A chain is defined by two properties: @@ -19,7 +19,7 @@ Both address and color uniquely identify a chain. However, the chain address is transient because chains can be moved from address to address. The chain color is an ultimate identifier of the chain for its lifetime. -Each chain is identified on the ISCP by its _chain ID_, represented by the +Each chain is identified on the IOTA Smart Contracts by its _chain ID_, represented by the [`iscp.ChainID`](https://github.com/iotaledger/wasp/blob/master/packages/iscp/chainid/chainid.go) type. In the current implementation `iscp.ChainID` is just a synonym of the chain address. In the future, the chain color will be used as chain ID. @@ -62,7 +62,7 @@ For example: `2AxoLpidnriXtSif5NnXSWdt28fUb6VwVRjULdDoe6pZVw::cebf5908`. In the IOTA Tangle, iotas and colored tokens are owned by an address. Only the entity owning the corresponding private key is able to spend from the address. -In ISCP, iotas and colored tokens can be owned either by an address or by a +In IOTA Smart Contracts, iotas and colored tokens can be owned either by an address or by a smart contract. In the latter case, only the contract represented by the contract ID can spend those tokens, i.e. only the contract program can move them to another location. @@ -74,7 +74,7 @@ to withdraw at any time (more on this [here](./accounts.md)). An _agent ID_ (`iscp.AgentID` type, 37 bytes) represents an owner of tokens in the internal chain ledger. It is a union type that can be either an -IOTA address (when the last 4 bytes are 0x00) or an ISCP contract ID. +IOTA address (when the last 4 bytes are 0x00) or an IOTA Smart Contracts contract ID. User-friendly representations of both types of _agent ID_ are prefixed by `A/` (for addresses) and `C/` (for contracts), like this: diff --git a/documentation/docs/misc/docker.md b/documentation/docs/misc/docker.md index c1304341fe..29186ae906 100644 --- a/documentation/docs/misc/docker.md +++ b/documentation/docs/misc/docker.md @@ -2,7 +2,6 @@ description: How to run a Wasp node in using Docker. Build the image, configure it, run it. image: /img/logo/WASP_logo_dark.png keywords: -- ISCP - Smart Contracts - Running a node - docker diff --git a/documentation/docs/misc/utxo.md b/documentation/docs/misc/utxo.md index fc0e794311..5067e755bd 100644 --- a/documentation/docs/misc/utxo.md +++ b/documentation/docs/misc/utxo.md @@ -61,7 +61,7 @@ validation rules of value transactions are the following: 4. The number of tokens with `ColorIOTA` in the outputs can be smaller or larger than iotas in inputs, provided condition (1) is satisfied. -The ISCP relies heavily on the logic of the tokens in the UTXO Ledger. In later +The IOTA Smart Contracts relies heavily on the logic of the tokens in the UTXO Ledger. In later documentation we will describe exactly how. Meanwhile, to simplify our thinking, we can represent a 2D address balance as its 1-dimensional "projection to the color axis": a collection of sub balances per color, like this: diff --git a/documentation/docs/overview.md b/documentation/docs/overview.md index a372ee48f1..550ca85c55 100644 --- a/documentation/docs/overview.md +++ b/documentation/docs/overview.md @@ -1,6 +1,5 @@ --- keywords: -- ISCP - Smart Contracts - Core Concepts - scaling @@ -8,9 +7,9 @@ keywords: description: IOTA Smart Contract Protocol is IOTA's solution for running smart contracts on top of the IOTA tangle. image: /img/logo/WASP_logo_dark.png --- -# ISCP +# IOTA Smart Contracts -ISCP stands for IOTA Smart Contract Protocol. It is IOTA's solution for running smart contracts on top of the IOTA tangle. With ISCP we bring scalable and flexible smart contracts into the IOTA ecosystem by allowing anyone to spin up a smart contract blockchain and anchor it to the IOTA tangle. +The IOTA Smart Contract Protocol is IOTA's solution for running smart contracts on top of the IOTA tangle. With IOTA Smart Contracts we bring scalable and flexible smart contracts into the IOTA ecosystem by allowing anyone to spin up a smart contract blockchain and anchor it to the IOTA tangle. Allowing multiple blockchains to anchor to the tangle will solve several problems with smart contracts. @@ -28,9 +27,9 @@ Given that anyone can start a new chain, and set the rules for that chain, a lot You can run multiple types of virtual machines on any chain. We are starting with [Rust/Wasm](https://rustwasm.github.io/docs/book/) based smart contracts, followed by -[Solidity/EVM](https://docs.soliditylang.org/en/v0.8.6/) based smart contracts, but eventually all kinds of virtual machines can be supported in a ISCP chain depending on the demand. +[Solidity/EVM](https://docs.soliditylang.org/en/v0.8.6/) based smart contracts, but eventually all kinds of virtual machines can be supported in a IOTA Smart Contract chain depending on the demand. -ISCP is more complex compared to conventional smart contracts, but this provides freedom and flexibility to allow the usage of smart contracts in a wide range of use cases. +IOTA Smart Contracts are more complex compared to conventional smart contracts, but this provides freedom and flexibility to allow the usage of smart contracts in a wide range of use cases. ## What is Wasp? diff --git a/documentation/docs/rfc/prevent-mev.md b/documentation/docs/rfc/prevent-mev.md index 408144dab7..46ebfdc600 100644 --- a/documentation/docs/rfc/prevent-mev.md +++ b/documentation/docs/rfc/prevent-mev.md @@ -1,15 +1,15 @@ -# Prevention of MEV in ISCP +# Prevention of MEV in IOTA Smart Contracts _MEV_ stands for _Miner Extractable Value_. Miner can take advantage of its knowledge, include and order its own transactions into the block to its advantage: front-running, sandwiching, abusing early knowledge of oracle submitted values and similar. It is a common thing e.g. in Ethereum because in Nakamoto PoW consensus miner fully defines the block content. -Generally speaking, in the BFT consensus used by ISCP it is impossible. This is because the VM is run post-consensus. +Generally speaking, in the BFT consensus used by IOTA Smart Contracts it is impossible. This is because the VM is run post-consensus. All validator nodes first agree on inputs to computations (the _batch_), and the rest is deterministic, i.e. cannot be influenced by less than 2/3+1 majority. -From the other side, in ISCP consensus the batch has to be sorted deterministically before running the VM. It opens a theoretical +From the other side, in IOTA Smart Contracts consensus the batch has to be sorted deterministically before running the VM. It opens a theoretical opportunity to take advantage in case the order or requests can be computed in advance. To prevent it, we propose to use the native unpredictable yet deterministic randomness generated during the consensus. diff --git a/documentation/docs/rfc/replay-off-ledger.md b/documentation/docs/rfc/replay-off-ledger.md index 0ffba3f87a..56429ccbaa 100644 --- a/documentation/docs/rfc/replay-off-ledger.md +++ b/documentation/docs/rfc/replay-off-ledger.md @@ -2,7 +2,7 @@ ## Motivation -The _off-ledger requests_ (aka _L2 requests_) are ISCP requests sent to the smart contract directly +The _off-ledger requests_ (aka _L2 requests_) are IOTA Smart Contracts requests sent to the smart contract directly through the Wasp node, a validator node or access node of the chain. In contrast, _on-ledger requests_ (aka _L1 requests_) are sent to the smart contract by wrapping the request into the IOTA value transaction and confirming it on the Tangle. @@ -25,12 +25,12 @@ The above is valid for both _off-ledger_ and _on-ledger_ requests. It means curr against request replay. However, the problem is with potentially huge logs in the state (in the _blocklog_). -The ISCP design is aiming at high TPS (settled requests per second) to be processed by the ISCP chains, mostly by using mechanism of _off-ledger_ requests. +The IOTA Smart Contracts design is aiming at high TPS (settled requests per second) to be processed by the IOTA Smart Contracts chains, mostly by using mechanism of _off-ledger_ requests. Let's assume we have 1000 TPS (requests per second). Each request generates a record 50+ bytes long in the `blocklog`. This gives us 50+ kB/s = 180+ MB/hour = 4.3+ GB/day. This isn't sustainable in the long run. -It means ISCP chain state will have to be equipped with the mechanism of periodical pruning, i.e. deleting non-critical and obsolete information from the state. +It means IOTA Smart Contracts chain state will have to be equipped with the mechanism of periodical pruning, i.e. deleting non-critical and obsolete information from the state. _(In short, the pruning of the state involves extracting witnesses/proofs of existence of the past state and then deleting that part from the state. Witnesses may be stored independently of the chain, while the chain will contain @@ -50,7 +50,7 @@ e.g. timestamp. Once `nonce` is part of the essence of the request and is hashed The approach would allow an early check by calling a view and checking the `blocklog`. It could be used to prevent spamming/DDoS attacks. -The problem, however, is that with the ISCP consensus, we cannot guarantee the requests will be included in the block in +The problem, however, is that with the IOTA Smart Contracts consensus, we cannot guarantee the requests will be included in the block in the order in which they arrived. Actually, the order is intentionally random. For example, if a client sends 5 requests at once, with correct sequence of nonces `1, 2, 3, 4, 5`, the requests may be picked and processed in two separate batches `1,2,5` and `3,4`. diff --git a/documentation/docs/tutorial/01.md b/documentation/docs/tutorial/01.md index 46414c6b75..ef794208ab 100644 --- a/documentation/docs/tutorial/01.md +++ b/documentation/docs/tutorial/01.md @@ -1,10 +1,10 @@ # The Solo package _Solo_ is a Go package to write tests for IOTA smart contracts. It allows the -deployment of ISCP chains and smart contracts. It also provides a toolkit for +deployment of IOTA Smart Contracts chains and smart contracts. It also provides a toolkit for interaction with smart contracts, for manipulation of tokens and ledger accounts in an environment that is almost identical to the distributed multi-chain -environment of the ISCP. +environment of the IOTA Smart Contracts. The Solo package and its GoDoc link [can be found here](https://github.com/iotaledger/wasp/tree/master/packages/solo). The GoDocs provides a reference to all _Solo_ calls which can be used in tests @@ -13,13 +13,13 @@ The GoDocs provides a reference to all _Solo_ calls which can be used in tests Smart contracts are notoriously isolated from the outside world. The effect of the user interaction with a smart contract is normally only observed in its state change. The approach in this tutorial is to explain all main concepts of -ISCP development through loading smart contracts into the _Solo_ tests, invoking +IOTA Smart Contracts development through loading smart contracts into the _Solo_ tests, invoking its functions and examining state changes. -ISCP is currently in active development, so things change and are less than -perfect. In the current stage the ISCP software is experimental. We expect +IOTA Smart Contracts is currently in active development, so things change and are less than +perfect. In the current stage, the IOTA Smart Contracts software is experimental. We expect feedback from the community about hands-on experience. We also expect -contribution to the development of ISCP itself, including Rust/Wasm development +contribution to the development of IOTA Smart Contracts itself, including Rust/Wasm development environment or, possibly, alternative VM implementations. _Solo_ is not a toy environment. It allows developers to develop and test real diff --git a/documentation/docs/tutorial/03.md b/documentation/docs/tutorial/03.md index 392110189d..a85d0b993b 100644 --- a/documentation/docs/tutorial/03.md +++ b/documentation/docs/tutorial/03.md @@ -39,9 +39,9 @@ Rust, and then will use the `wasplib` [library](https://github.com/iotaledger/wa and [wasm-pack](https://rustwasm.github.io/wasm-pack/installer/) to compile it into a WebAssembly (_wasm_) binary. :::note -This tutorial is not a tutorial of the ISCP smart contract development +This tutorial is not a tutorial of the IOTA Smart Contracts smart contract development environment: for that we will provide other tutorials. The only goal of these -examples is an introduction to fundamental principles of ISCP smart contracts. +examples is an introduction to fundamental principles of IOTA Smart Contracts smart contracts. ::: We assume you already have Rust and `wasm-pack` @@ -131,4 +131,4 @@ C:/Users/evaldas/.cargo/bin/wasm-pack.exe build -- --color=always The 17KB file `example_tutorial_bg.wasm` is the binary of the smart contract. We will be using it in further examples. The file contains everything needed to -deploy the smart contract on a chain run on the ISCP network. +deploy the smart contract on a chain run on the IOTA Smart Contracts network. diff --git a/documentation/docs/tutorial/05.md b/documentation/docs/tutorial/05.md index fcbb1541e1..db9962bb5b 100644 --- a/documentation/docs/tutorial/05.md +++ b/documentation/docs/tutorial/05.md @@ -4,7 +4,7 @@ Smart contracts are programs, immutably stored in the chain. In the previous example the binary file with the code of the smart contract _example_tutorial_bg.wasm_ will be immutably stored in the chain state. -The logical structure of an ISCP smart contract is independent of the VM type we +The logical structure of an IOTA Smart Contracts smart contract is independent of the VM type we use, be it a _Wasm_ smart contract or any other VM type. ![Smart Contract Structure](/img/tutorial/SC-structure.png) diff --git a/documentation/docs/tutorial/06.md b/documentation/docs/tutorial/06.md index 7bed5bbd37..9449a0d75b 100644 --- a/documentation/docs/tutorial/06.md +++ b/documentation/docs/tutorial/06.md @@ -38,7 +38,7 @@ is going on here. The diagram above depicts the generic process of posting an `on-ledger` request to the smart contract. The same picture is valid for the _Solo_ environment and for any other -requester which sends an `on-ledger` request to the smart contract, for example the ISCP +requester which sends an `on-ledger` request to the smart contract, for example the IOTA Smart Contracts wallet or another chain. Posting the request always consists of the steps below. Note that in Solo all 7 @@ -48,7 +48,7 @@ steps are carried out by the single call to `PostRequestSync`. and moves tokens. Each request transaction is a value transaction, it always moves at least one token. Therefore, each request transaction must be signed by the private key of the owner of the tokens: the requester. That securely - identifies each requester in ISCP. In Solo the transaction is signed by the + identifies each requester in IOTA Smart Contracts. In Solo the transaction is signed by the private key provided in the second parameter of the `PostRequestSync` call (see below); 2. Posting the request transaction to the Tangle and confirming it. In _Solo_ it diff --git a/documentation/docs/tutorial/08.md b/documentation/docs/tutorial/08.md index d6d272532a..0306b874cc 100644 --- a/documentation/docs/tutorial/08.md +++ b/documentation/docs/tutorial/08.md @@ -1,6 +1,6 @@ # Accounts: deposit and withdraw tokens -Each chain in _ISCP_ is a separate ledger, different from the UTXO ledger. +Each chain in _IOTA Smart Contracts_ is a separate ledger, different from the UTXO ledger. Multiple chains adds another dimension on top of the UTXO Ledger. Smart contracts can exchange assets between themselves on the same chain and also between different chains as well as with addresses on the UTXO Ledger. We will skip explaining the whole picture for time @@ -15,7 +15,7 @@ Ledger the private key is represented by the address (the hash of the public key). That address holds balances of colored tokens. Those tokens are _controlled_ by the private key. -In ISCP we extend the concept of _address_ with the concept of `account`. An +In IOTA Smart Contracts we extend the concept of _address_ with the concept of `account`. An `account` contains colored tokens just like an `address`. The `account` is located on some chain, and it is controlled by the same private key as the associated address. So, an address can control tokens on the UTXO Ledger diff --git a/documentation/docs/tutorial/10.md b/documentation/docs/tutorial/10.md index ee133dd55a..80f661a662 100644 --- a/documentation/docs/tutorial/10.md +++ b/documentation/docs/tutorial/10.md @@ -48,5 +48,5 @@ The programmer forgets the parameter `paramString` and the program panics: We can see that all sent 42 tokens are returned to the sender's address. -In case of panic in the smart contract for whatever reason, the fallback logic of the ISCP VM +In case of panic in the smart contract for whatever reason, the fallback logic of the IOTA Smart Contracts VM returns all tokens (minus fees) to the sender (to the sender's address in the example above). \ No newline at end of file diff --git a/documentation/docs/tutorial/12.md b/documentation/docs/tutorial/12.md index 9b89634d60..dc5aa0d773 100644 --- a/documentation/docs/tutorial/12.md +++ b/documentation/docs/tutorial/12.md @@ -1,6 +1,6 @@ -# ISCP accounts. Controlling token balances +# IOTA Smart Contracts accounts. Controlling token balances. -ISCP provides secure, trustless transfers of digitized assets: +IOTA Smart Contracts provides secure, trustless transfers of digitized assets: - between smart contracts on the same or on different chains - between smart contracts and L1 addresses on the UTXO Ledger. @@ -10,7 +10,7 @@ transfers of assets between addresses on the ledger. The tokens contained in the address can be moved to another address by providing a valid signature by the private key which controls the source address. -In ISCP, the smart contracts which reside on chains are also owners of their +In IOTA Smart Contracts, the smart contracts which reside on chains are also owners of their tokens. Each smart contract can receive tokens that are transferred to it and can send tokens it controls to any other owner, be it another smart contract, or an ordinary L1 address on the UTXO Ledger. @@ -18,7 +18,7 @@ contract, or an ordinary L1 address on the UTXO Ledger. So, there are 2 types of entities which can control tokens: * L1 addresses on the UTXO Ledger -* Smart contracts on ISCP chains +* Smart contracts on IOTA Smart Contracts chains There are 3 different types of trustless token transfers possible between those entities. Each type involves a different mechanism of transfer: @@ -36,9 +36,9 @@ To make the system homogenous, we introduce the following two concepts: ## Smart contract ID Unlike with blockchain systems like Ethereum, we cannot simply represent the -smart contract by a blockchain address: ISCP can have many blockchains, not just -a single one. Each chain in ISCP is identified by its _chain ID_. A chain can -contain many smart contracts on it. So, in ISCP each contract is identified by +smart contract by a blockchain address: IOTA Smart Contracts can have many blockchains, not just +a single one. Each chain in IOTA Smart Contracts is identified by its _chain ID_. A chain can +contain many smart contracts on it. So, in IOTA Smart Contracts each contract is identified by an identifier that consists of the chain ID, and the _hname_ of the smart contract. In human-readable form, the smart _contract ID_ looks like this: diff --git a/documentation/docs/tutorial/readme.md b/documentation/docs/tutorial/readme.md index ee89c0e3f0..29cee9bf44 100644 --- a/documentation/docs/tutorial/readme.md +++ b/documentation/docs/tutorial/readme.md @@ -1,12 +1,12 @@ # Exploring IOTA Smart Contracts -This document is an introductory tutorial of the IOTA Smart Contract Platform -(ISCP) for developers. +This document is an introductory tutorial of the IOTA Smart Contracts Platform +for developers. The level of this document is technical. Its target audience is software -engineers who want to understand the ISCP, and the direction it is taking, in +engineers who want to understand the IOTA Smart Contracts, and the direction it is taking, in order to develop their own dApps and/or contribute to the development of the -ISCP and Wasp nodes. +IOTA Smart Contracts and Wasp nodes. There are two ways of seeing the same thing, a smart contract: as a program of a state machine and as a distributed, fault-tolerant and decentralized system. Both views are correct. diff --git a/documentation/docs/welcome.md b/documentation/docs/welcome.md index 1ecfce3531..66f8470f31 100644 --- a/documentation/docs/welcome.md +++ b/documentation/docs/welcome.md @@ -1,10 +1,10 @@ # Welcome to the Wasp [Wasp](https://github.com/iotaledger/wasp) is a node software developed by the -[IOTA Foundation](http://iota.org) to run the _IOTA Smart Contract Protocol_ -(_ISCP_ in short) on top of the _IOTA Tangle_. Please find here a [high level +[IOTA Foundation](http://iota.org) to run the _IOTA Smart Contracts_ +on top of the _IOTA Tangle_. Please find here a [high level introduction](https://blog.iota.org/an-introduction-to-iota-smart-contracts-16ea6f247936) -into ISCP. +into IOTA Smart Contracts. A _smart contract_ is a distributed software agent that stores its state in the [UTXO ledger](misc/utxo.md), and evolves with each _request_ sent to @@ -18,7 +18,7 @@ program. This ensures that the operation of smart contracts is distributed, fault-tolerant and leaderless. The articles below explain how to run a Wasp node on the Goshimmer network, as -well as concepts and architecture of ISCP and Wasp. +well as concepts and architecture of IOTA Smart Contracts and Wasp. _Disclaimer: Wasp node and articles is a work in progress, and most likely will always be. The software presented in this repository is not ready for use in