Merge pull request #679 from fijter/develop

Documentation manual merge conflict resolution
iotaledger · Dec 10, 2021 · 7cf4eed · 7cf4eed
2 parents 5e58a0a + cf64e24
commit 7cf4eed
Show file tree

Hide file tree

Showing 65 changed files with 205 additions and 194 deletions.
diff --git 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
@@ -1,6 +1,5 @@
 ---
 keywords:
-- ISCP
 - Smart Contracts
 - Chain
 - Management

diff --git a/documentation/docs/guide/chains_and_nodes/docker_standalone.md b/documentation/docs/guide/chains_and_nodes/docker_standalone.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/guide/chains_and_nodes/publisher.md b/documentation/docs/guide/chains_and_nodes/publisher.md
@@ -0,0 +1,33 @@
+---
+keywords:
+- Publisher 
+- Nanomsg
+- Messages
+description: Publishing important events via a Nanomsg message stream. Subscribing to a stream with a client. Message format description.
+image: /img/logo/WASP_logo_dark.png
+---
+
+# Wasp Publisher
+
+Each Wasp node publishes important events via a [Nanomsg](https://nanomsg.org/) message stream
+(just like ZMQ is used in IRI. Possibly in the future ZMQ and MQTT publishers will be supported too).
+
+Any Nanomsg client can subscribe to the message stream. In Go you can use the
+`packages/subscribe` package provided in Wasp for this.
+
+The Publisher port can be configured in `config.json` with the `nanomsg.port`
+setting.
+
+Message format is simply a string consisting of a space separated list of tokens; and the first token
+is the message type. Below is a list of all message types published by Wasp. (You can search for
+`publisher.Publish` in the code to see the exact places where each message is published.)
+
+|Message|Format|
+|:--- |:--- |
+|Chain record has been saved in the registry | `chainrec <chain ID> <color>` |
+|Chain committee has been activated|`active_committee <chain ID>`|
+|Chain committee dismissed|`dismissed_committee <chain ID>`|
+|A new SC request reached the node|`request_in <chain ID> <request tx ID> <request block index>`|
+|SC request has been processed (i.e. corresponding state update was confirmed)|`request_out <chain ID> <request tx ID> <request block index> <state index> <seq number in the block> <block size>`|
+|State transition (new state has been committed to DB)| `state <chain ID> <state index> <block size> <state tx ID> <state hash> <timestamp>`|
+|Event generated by a SC|`vmmsg <chain ID> <contract hname> ...`|
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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,15 +20,15 @@ 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.
 
 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -1,6 +1,5 @@
 ---
 keywords:
-- ISCP
 - Smart Contracts
 - Architecture
 - Ethereum
@@ -14,9 +13,9 @@ With IOTA Smart Contracts, anyone can start their own chain and define the valid
 
 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 IOTA Smart Contracts 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](../../../static/img/multichain.png)
+![IOTA Smart Contracts multichain architecture](/img/multichain.png)
 
 The comprehensive overview of architectural design decisions of IOTA Smart Contracts can be found in the 
 [whitepaper](https://files.iota.org/papers/ISC_WP_Nov_10_2021.pdf).
diff --git 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
@@ -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
@@ -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
@@ -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/...ation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md b/...ation/docs/guide/core_concepts/smartcontract-interaction/off-ledger-requests.md
@@ -1,6 +1,6 @@
 ---
 keywords:
-- ISCP
+- Smart Contracts
 - requests
 - off-ledger
 - node