diff --git a/README.md b/README.md index 2211c45..fa2af3d 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,7 @@ This command starts a local development server and opens up a browser window. Mo npm build ``` -This command generates static content into the `build` directory and can be served using any static contents hosting service. +This command generates static content into the `build` directory and can be served using any static content hosting service. ### Clear .docusaurus directory @@ -47,4 +47,4 @@ npm clear © 2025 Wire Network. All rights reserved. - diff --git a/docs/api-reference/system-contracts/index.md b/docs/api-reference/system-contracts/index.md index ba18d3c..33360f0 100644 --- a/docs/api-reference/system-contracts/index.md +++ b/docs/api-reference/system-contracts/index.md @@ -10,7 +10,7 @@ The Wire blockchain platform is unique in that the features and characteristics ## Concepts -### System contracts, system accounts, priviledged accounts +### System contracts, system accounts, privileged accounts At the genesis of a Wire-based blockchain, there is only one account present: `sysio`, which is the **main system account**. There are other system accounts, which are created by `sysio`, and control specific actions of the system contracts mentioned earlier. @@ -18,7 +18,7 @@ Privileged accounts are accounts which can execute a transaction while skipping Not all system accounts contain a system contract, but each system account has important roles in the blockchain functionality, as follows: -|Account|Priviledged|Has contract|Description| +|Account|Privileged|Has contract|Description| |---|---|---|---| |sysio|Yes|It contains the `sysio.system` contract|The main system account on a Wire based blockchain.| |sysio.msig|Yes|It contains the `sysio.msig` contract|Allows the signing of a multi-sig transaction proposal for later execution if all required parties sign the proposal before the expiration time.| @@ -50,7 +50,7 @@ As CPU and RAM, NET is also a very important resource in Wire-based blockchains. - About System Contracts - [Concepts](#concepts) - - [System contracts, system accounts, priviledged accounts](#system-contracts-system-accounts-priviledged-accounts) + - [System contracts, system accounts, privileged accounts](#system-contracts-system-accounts-privileged-accounts) - [RAM](#ram) - [CPU](#cpu) - [NET](#net) @@ -85,14 +85,14 @@ Below are listed the actions which are declared in the `sysio.bios` contract, ma |updateauth|Updates the permission for an account.| |deleteauth|Delete permission for an account.| |linkauth|Assigns a specific action from a contract to a permission you have created.| -|unlinkauth|Assigns a specific action from a contract to a permission you have created.| +|unlinkauth|Removes the assignment of a specific action from a contract to a permission you have created.| |canceldelay|Allows for cancellation of a deferred transaction.| |onerror|Called every time an error occurs while a transaction was processed.| |setcode|Allows for update of the contract code of an account.| ### `sysio.system` contract -The `sysio.system` contract is another smart contract that Block.one provides an implementation for as a sample system contract. It is a version of `sysio.bios` only this time it is not minimalist, it contains more elaborated structures, classes, methods, and actions needed for a Wire based blockchain core functionality: +The `sysio.system` contract is another smart contract that Block.one provides an implementation for as a sample system contract. It is a version of `sysio.bios` only this time it is not minimalist, it contains more elaborate structures, classes, methods, and actions needed for the core functionality of a Wire-based blockchain: The actions implemented and publicly exposed by the `sysio.system` system contract are presented in the table below. Just like the `sysio.bios` sample contract there are a few actions which are not implemented at the contract level (`newaccount`, `updateauth`, `deleteauth`, `linkauth`, `unlinkauth`, `canceldelay`, `onerror`, `setabi`, `setcode`), they are just declared in the contract so they will show in the contract's ABI and users will be able to push those actions to the chain via the account holding the 'sysio.system' contract, but the implementation is at the Wire Sysio core level. They are referred to as **native actions.** @@ -102,7 +102,7 @@ The actions implemented and publicly exposed by the `sysio.system` system contra |updateauth|Updates the permission for an account.| |deleteauth|Delete permission for an account.| |linkauth|Assigns a specific action from a contract to a permission you have created.| -|unlinkauth|Assigns a specific action from a contract to a permission you have created.| +|unlinkauth|Removes the assignment of a specific action from a contract to a permission you have created.| |canceldelay|Allows for cancellation of a deferred transaction.| |onerror|Called every time an error occurs while a transaction was processed.| |setabi|Allows for updates of the contract ABI of an account.| diff --git a/docs/api-reference/tooling/cdt/features/binary-extension.md b/docs/api-reference/tooling/cdt/features/binary-extension.md index a145efc..9a6bfa9 100644 --- a/docs/api-reference/tooling/cdt/features/binary-extension.md +++ b/docs/api-reference/tooling/cdt/features/binary-extension.md @@ -10,11 +10,11 @@ tags: You can find the implementation of `sysio::binary_extension` [here](https://github.com/Wire-Network/wire-cdt/blob/master/libraries/sysiolib/core/sysio/binary_extension.hpp). -Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in an `sysio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration. +Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in a `sysio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration. -By wrapping the new field in an `sysio::binary_extension`, you are enabling your contract to be _backwards compatible_ for future use. Note that this new field/parameter **MUST** be appended at the end of a data structure (this is due to implementation details in `sysio::multi_index`, which relies on the `boost::multi_index` type), or at the end of the parameter list in an action declaration. +By wrapping the new field in a `sysio::binary_extension`, you are enabling your contract to be _backwards compatible_ for future use. Note that this new field/parameter **MUST** be appended at the end of a data structure (this is due to implementation details in `sysio::multi_index`, which relies on the `boost::multi_index` type), or at the end of the parameter list in an action declaration. -If you don't wrap the new field in an `sysio::binary_extension`, the `sysio::multi_index` table will be reformatted in such a way that disallows reads to the former datum; or in an action's case, the function will be uncallable. +If you don't wrap the new field in a `sysio::binary_extension`, the `sysio::multi_index` table will be reformatted in such a way that disallows reads to the former datum; or in an action's case, the function will be uncallable. *** @@ -423,7 +423,7 @@ warning: transaction executed locally, but may not be confirmed by the network y *** -Now, let's upgrade the smart contract by adding a new field to the table and a new parameter to an action while **NOT** wrapping the new field/parameter in an `sysio::binary_extension` type and see what happens: +Now, let's upgrade the smart contract by adding a new field to the table and a new parameter to an action while **NOT** wrapping the new field/parameter in a `sysio::binary_extension` type and see what happens: **binary_extension_contract.hpp** @@ -558,7 +558,7 @@ Whoops! We aren't able to write to our table the original way with the upgraded *** -Ok, let's back up and wrap the new field and the new action parameter in an `sysio::binary_extension` type: +Ok, let's back up and wrap the new field and the new action parameter in a `sysio::binary_extension` type: **binary_extension_contract.hpp** @@ -653,7 +653,7 @@ struct [[sysio::table]] structure { } ``` -Note the `$` after the types now; this indicates that this type is an `sysio::binary_extension` type field. +Note the `$` after the types now; this indicates that this type is a `sysio::binary_extension` type field. ```diff { @@ -725,4 +725,4 @@ Just keep these simple rules in mind when upgrading a smart contract. If you are adding a new field to a struct currently in use by a `sysio::multi_index` be **SURE** to: - add the field at the end of the struct. -- wrap the type using an `sysio::binary_extension` type. +- wrap the type using a `sysio::binary_extension` type. diff --git a/docs/api-reference/tooling/cdt/features/crypto-extensions.mdx b/docs/api-reference/tooling/cdt/features/crypto-extensions.mdx index d022956..353e1d1 100644 --- a/docs/api-reference/tooling/cdt/features/crypto-extensions.mdx +++ b/docs/api-reference/tooling/cdt/features/crypto-extensions.mdx @@ -75,7 +75,7 @@ C++ types were added to represent `G1` and `G2` points (read and write) and view ec_point(std::vector& p); /** - * Return serialzed point containing only x and y + * Return serialized point containing only x and y */ std::vector serialized() const; }; @@ -125,7 +125,7 @@ C++ types were added to represent `G1` and `G2` points (read and write) and view ec_point_view(const ec_point& p); /** - * Return serialzed point containing only x and y + * Return serialized point containing only x and y */ std::vector serialized() const; }; diff --git a/docs/api-reference/tooling/cdt/features/native-tester-compilation.md b/docs/api-reference/tooling/cdt/features/native-tester-compilation.md index 2e41406..c27d967 100644 --- a/docs/api-reference/tooling/cdt/features/native-tester-compilation.md +++ b/docs/api-reference/tooling/cdt/features/native-tester-compilation.md @@ -42,7 +42,7 @@ using namespace sysio; using namespace sysio::native; SYSIO_TEST_BEGIN(hello_test) - // These can be redefined by the user to suit there needs per unit test + // These can be redefined by the user to suit their needs per unit test // the idea is that in a future release there will be a base library that // initializes these to "useable" default implementations and probably // helpers to more easily define read_action_data and action_data_size intrinsics @@ -107,7 +107,7 @@ Every `intrinsic` that is defined for sysio (prints, require_auth, etc.) is re-d ## CDT Native Tester API -- CHECK_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed but allow the rest of the tests to run. +- CHECK_ASSERT(...) : This macro will check whether a particular assert has occurred and flag the tests as failed but allow the rest of the tests to run. - This is called either by - `CHECK_ASSERT("", [](){ whatever_function(); })` - `CHECK_ASSERT([](std::string msg){ user defined comparison function }, [](){ whatever_function(); })` @@ -115,8 +115,8 @@ Every `intrinsic` that is defined for sysio (prints, require_auth, etc.) is re-d - This is called either by - `CHECK_PRINT("", [](){ whatever_function(); })` - `CHECK_PRINT([](std::string print_buffer){ user defined comparison function }, [](){ whatever_function(); })` -- CHECK_EQUAL(X, Y) : This macro will check whether two inputs equal eachother and fail the test but allow the rest of the test to continue. -- REQUIRE_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed and halt the test on failure. +- CHECK_EQUAL(X, Y) : This macro will check whether two inputs equal each other and fail the test but allow the rest of the test to continue. +- REQUIRE_ASSERT(...) : This macro will check whether a particular assert has occurred and flag the tests as failed and halt the test on failure. - This is called either by - `REQUIRE_ASSERT("", [](){ whatever_function(); })` - `REQUIRE_ASSERT([](std::string msg){ user defined comparison function }, [](){ whatever_function(); })` @@ -124,7 +124,7 @@ Every `intrinsic` that is defined for sysio (prints, require_auth, etc.) is re-d - This is called either by - `REQUIRE_PRINT("", [](){ whatever_function(); })` - `REQUIRE_PRINT([](std::string print_buffer){ user defined comparison function }, [](){ whatever_function(); })` -- REQUIRE_EQUAL(X, Y) : This macro will check whether two inputs `X` and `Y` equal eachother and fail the test and halt the test on failure. +- REQUIRE_EQUAL(X, Y) : This macro will check whether two inputs `X` and `Y` equal each other and fail the test and halt the test on failure. - SYSIO_TEST_BEGIN(X) : This macro defines the beginning of a unit test and assigns `X` as the symbolic name of that test. - SYSIO_TEST_END : This macro defines the end of a unit test. - SYSIO_TEST(X) : This is used to run a particular named unit test `X` in the main function. diff --git a/docs/api-reference/tooling/clio/command-reference/get/deprecated/accounts.md b/docs/api-reference/tooling/clio/command-reference/get/deprecated/accounts.md index 930945a..934da5f 100755 --- a/docs/api-reference/tooling/clio/command-reference/get/deprecated/accounts.md +++ b/docs/api-reference/tooling/clio/command-reference/get/deprecated/accounts.md @@ -9,7 +9,7 @@ tags: :::warning [Deprecation Notice] -| **Important**: The command `clio get accounts ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. +**Important**: The command `clio get accounts ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. ::: ## Description diff --git a/docs/api-reference/tooling/clio/command-reference/get/deprecated/servants.md b/docs/api-reference/tooling/clio/command-reference/get/deprecated/servants.md index e28d2ec..a44a2bb 100755 --- a/docs/api-reference/tooling/clio/command-reference/get/deprecated/servants.md +++ b/docs/api-reference/tooling/clio/command-reference/get/deprecated/servants.md @@ -8,7 +8,7 @@ tags: --- :::warning Deprecation Notice -| **Important**: The command `clio get servants ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. +**Important**: The command `clio get servants ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. ::: ## Description diff --git a/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction.md b/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction.md index 5167aea..dfe3c93 100755 --- a/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction.md +++ b/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction.md @@ -8,7 +8,7 @@ tags: --- :::warning Deprecation Notice -| **Important**: The command `clio get transaction ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. +**Important**: The command `clio get transaction ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. ::: ## Description diff --git a/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction_id.md b/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction_id.md index a99c376..1274a98 100755 --- a/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction_id.md +++ b/docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction_id.md @@ -8,7 +8,7 @@ tags: --- :::warning Deprecation Notice -| **Important**: The command `clio get transaction_id ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. +**Important**: The command `clio get transaction_id ` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`. ::: ## Description diff --git a/docs/api-reference/tooling/clio/command-reference/get/table.md b/docs/api-reference/tooling/clio/command-reference/get/table.md index 08994f4..6bf9d2d 100755 --- a/docs/api-reference/tooling/clio/command-reference/get/table.md +++ b/docs/api-reference/tooling/clio/command-reference/get/table.md @@ -27,7 +27,7 @@ clio get table [[-l | --limit] ] # The maximum number of rows to return [[-k | --key] ] # (Deprecated) The name of the key to index by as defined by the abi, defaults to primary key [[-L | --lower] ] # JSON representation of lower bound value of key, defaults to first - [[-U | --upper] ] # JSON representation of upper bound value value of key, defaults to last + [[-U | --upper] ] # JSON representation of upper bound value of key, defaults to last [--index ] # Index number, `1`: primary (first), `2`: secondary index (in order defined by multi_index), `3`: third index, etc. Number or name of index can be specified, e.g. `secondary` or `2` [--key-type ] # The key type of `--index`; primary only supports `i64`. All others support `i64`, `i128`, `i256`, `float64`, `float128`, `ripemd160`, `sha256`. Special type `name` indicates an account name [--encode-type ] # The encoding type of `--key_type`; `dec` for decimal encoding of (`i[64|128|256]`, `float[64|128]`); `hex` for hexadecimal encoding of (`i256`, `ripemd160`, `sha256`) diff --git a/docs/api-reference/tooling/clio/command-reference/net/connect.md b/docs/api-reference/tooling/clio/command-reference/net/connect.md index d731b25..fc9f803 100755 --- a/docs/api-reference/tooling/clio/command-reference/net/connect.md +++ b/docs/api-reference/tooling/clio/command-reference/net/connect.md @@ -31,7 +31,7 @@ Make sure you meet the following requirements: * Install the currently supported version of `clio`. :::note -| The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded. diff --git a/docs/api-reference/tooling/clio/command-reference/net/disconnect.md b/docs/api-reference/tooling/clio/command-reference/net/disconnect.md index 52eb3bb..8d86304 100755 --- a/docs/api-reference/tooling/clio/command-reference/net/disconnect.md +++ b/docs/api-reference/tooling/clio/command-reference/net/disconnect.md @@ -31,7 +31,7 @@ clio net disconnect * Install the currently supported version of `clio`. :::note - | The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. + The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded. diff --git a/docs/api-reference/tooling/clio/command-reference/net/peers.md b/docs/api-reference/tooling/clio/command-reference/net/peers.md index 13e5bb2..0885051 100755 --- a/docs/api-reference/tooling/clio/command-reference/net/peers.md +++ b/docs/api-reference/tooling/clio/command-reference/net/peers.md @@ -29,7 +29,7 @@ clio net peers * Install the currently supported version of `clio`. :::note - | The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. + The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded. diff --git a/docs/api-reference/tooling/clio/command-reference/net/status.md b/docs/api-reference/tooling/clio/command-reference/net/status.md index f8ab9bd..8db30f0 100755 --- a/docs/api-reference/tooling/clio/command-reference/net/status.md +++ b/docs/api-reference/tooling/clio/command-reference/net/status.md @@ -31,7 +31,7 @@ clio net status * Install the currently supported version of `clio`. :::note -| The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded. diff --git a/docs/api-reference/tooling/clio/command-reference/set/set-action-permission.md b/docs/api-reference/tooling/clio/command-reference/set/set-action-permission.md index b55634c..832074b 100755 --- a/docs/api-reference/tooling/clio/command-reference/set/set-action-permission.md +++ b/docs/api-reference/tooling/clio/command-reference/set/set-action-permission.md @@ -54,7 +54,7 @@ clio set action permission * Install the currently supported version of `clio`. :::note -| The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a local Wire node. diff --git a/docs/api-reference/tooling/kiod/index.md b/docs/api-reference/tooling/kiod/index.md index ba419d0..26495b4 100644 --- a/docs/api-reference/tooling/kiod/index.md +++ b/docs/api-reference/tooling/kiod/index.md @@ -17,7 +17,7 @@ tags: ## Usage :::tip[Recommended Usage] -| For most users, the easiest way to use `kiod` is to have `clio` launch it automatically. Wallet files will be created in the default directory (`~/sysio-wallet`). +For most users, the easiest way to use `kiod` is to have `clio` launch it automatically. Wallet files will be created in the default directory (`~/sysio-wallet`). ::: ### Basic operation @@ -25,7 +25,7 @@ tags: When a wallet is unlocked with the corresponding password, `clio` can request `kiod` to sign a transaction with the appropriate private keys. :::info[Audience] -| `kiod` is intended to be used by Wire developers only. +`kiod` is intended to be used by Wire developers only. ::: ### Launching kiod manually @@ -39,7 +39,7 @@ kiod By default, `kiod` creates the folder `~/sysio-wallet` and populates it with a basic `config.ini` file. The location of the config file can be specified on the command line using the `--config-dir` argument. The configuration file contains the HTTP server endpoint for incoming HTTP connections and other parameters for cross-origin resource sharing. :::info[Wallet Location] -| The location of the wallet data folder can be specified on the command line with the `--data-dir` option. +The location of the wallet data folder can be specified on the command line with the `--data-dir` option. ::: ### Auto-locking diff --git a/docs/api-reference/tooling/kiod/plugins/index.md b/docs/api-reference/tooling/kiod/plugins/index.md index d122279..bd3ac76 100644 --- a/docs/api-reference/tooling/kiod/plugins/index.md +++ b/docs/api-reference/tooling/kiod/plugins/index.md @@ -13,5 +13,5 @@ Plugins extend the core functionality implemented in `kiod`. For information on * [`wallet_plugin`](wallet-plugin.md) :::info -| Plugins add incremental functionality to `kiod`. Unlike runtime plugins, `kiod` plugins are built at compile-time. +Plugins add incremental functionality to `kiod`. Unlike runtime plugins, `kiod` plugins are built at compile-time. ::: diff --git a/docs/api-reference/tooling/kiod/plugins/wallet-api-plugin.md b/docs/api-reference/tooling/kiod/plugins/wallet-api-plugin.md index a072553..71a37ae 100644 --- a/docs/api-reference/tooling/kiod/plugins/wallet-api-plugin.md +++ b/docs/api-reference/tooling/kiod/plugins/wallet-api-plugin.md @@ -11,7 +11,7 @@ tags: The `wallet_api_plugin` exposes functionality from the [`wallet_plugin`](wallet-plugin.md) to the RPC API interface managed by the [`http_plugin`](../../nodeop/plugins/http-plugin.md). :::warning[Caution] -| This plugin exposes wallets. Therefore, running this plugin on a publicly accessible node is not recommended. As of 1.2.0, the `wallet_api_plugin` is only available through `kiod`. It is no longer supported by `nodeop`. +This plugin exposes wallets. Therefore, running this plugin on a publicly accessible node is not recommended. As of 1.2.0, the `wallet_api_plugin` is only available through `kiod`. It is no longer supported by `nodeop`. ::: ## Usage diff --git a/docs/api-reference/tooling/kiod/plugins/wallet-plugin.md b/docs/api-reference/tooling/kiod/plugins/wallet-plugin.md index ef35ddc..5eb298b 100644 --- a/docs/api-reference/tooling/kiod/plugins/wallet-plugin.md +++ b/docs/api-reference/tooling/kiod/plugins/wallet-plugin.md @@ -8,7 +8,7 @@ tags: The `wallet_plugin` adds access to wallet functionality from a node. :::danger[Danger] -| This plugin is not designed to be loaded as a plugin on a publicly accessible node without further security measures. This is particularly true when loading the `wallet_api_plugin`, which should not be loaded on a publicly accessible node under any circumstances. +This plugin is not designed to be loaded as a plugin on a publicly accessible node without further security measures. This is particularly true when loading the `wallet_api_plugin`, which should not be loaded on a publicly accessible node under any circumstances. ::: ## Usage diff --git a/docs/api-reference/tooling/kiod/usage.md b/docs/api-reference/tooling/kiod/usage.md index 8634fe4..fa51bf4 100644 --- a/docs/api-reference/tooling/kiod/usage.md +++ b/docs/api-reference/tooling/kiod/usage.md @@ -9,7 +9,7 @@ tags: --- :::tip[Recommended Usage] -| For most users, the easiest way to use `kiod` is to have `clio` launch it automatically. Wallet files will be created in the default directory (`~/sysio-wallet`). +For most users, the easiest way to use `kiod` is to have `clio` launch it automatically. Wallet files will be created in the default directory (`~/sysio-wallet`). ::: ## Launching kiod manually @@ -23,7 +23,7 @@ kiod By default, `kiod` creates the folder `~/sysio-wallet` and populates it with a basic `config.ini` file. The location of the config file can be specified on the command line using the `--config-dir` argument. The configuration file contains the HTTP server endpoint for incoming HTTP connections and other parameters for cross-origin resource sharing. :::info[Wallet Location] -| The location of the wallet data folder can be specified on the command line with the `--data-dir` option. +The location of the wallet data folder can be specified on the command line with the `--data-dir` option. ::: ## Auto-locking diff --git a/docs/api-reference/tooling/kiod/wallet-specification.md b/docs/api-reference/tooling/kiod/wallet-specification.md index ecbcd01..2b0fe73 100644 --- a/docs/api-reference/tooling/kiod/wallet-specification.md +++ b/docs/api-reference/tooling/kiod/wallet-specification.md @@ -7,7 +7,7 @@ tags: ## Wallet Import Format (WIF) -Wallet Import Format is an encoding for a private EDSA key. Wire uses the same version, checksum, and encoding scheme as the Bitcoin WIF addresses and should be compatible with existing libraries [1]. Check [Bitcoin WIF](https://en.bitcoin.it/wiki/Wallet_import_format) for more information. +Wallet Import Format is an encoding for a private ECDSA key. Wire uses the same version, checksum, and encoding scheme as the Bitcoin WIF addresses and should be compatible with existing libraries [1]. Check [Bitcoin WIF](https://en.bitcoin.it/wiki/Wallet_import_format) for more information. **Example of a WIF Private Key:** diff --git a/docs/api-reference/tooling/nodeop/native-logging.md b/docs/api-reference/tooling/nodeop/native-logging.md index 693f984..4407d65 100644 --- a/docs/api-reference/tooling/nodeop/native-logging.md +++ b/docs/api-reference/tooling/nodeop/native-logging.md @@ -151,7 +151,7 @@ The configuration options are: ``` :::info -| The default logging level for all loggers, if no `logging.json` is provided is `info`. Each logger can be configured independently in the `logging.json` file. +The default logging level for all loggers, if no `logging.json` is provided is `info`. Each logger can be configured independently in the `logging.json` file. ::: ## Example `logging.json` diff --git a/docs/api-reference/tooling/nodeop/plugins/chain-plugin.md b/docs/api-reference/tooling/nodeop/plugins/chain-plugin.md index 5574372..8f4caee 100644 --- a/docs/api-reference/tooling/nodeop/plugins/chain-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/chain-plugin.md @@ -9,7 +9,7 @@ tags: ## Description -The `chain_plugin` is a core plugin required to process and aggregate chain data on an Wire node. +The `chain_plugin` is a core plugin required to process and aggregate chain data on a Wire node. ## Usage diff --git a/docs/api-reference/tooling/nodeop/plugins/history-api-plugin.md b/docs/api-reference/tooling/nodeop/plugins/history-api-plugin.md index f84930b..931ae45 100644 --- a/docs/api-reference/tooling/nodeop/plugins/history-api-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/history-api-plugin.md @@ -5,7 +5,7 @@ tags: --- :::warning -| The `history_plugin` that the `history_api_plugin` depends upon is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](state-history-plugin.md) or the [`trace_api_plugin`](trace-api-plugin.md) instead. +The `history_plugin` that the `history_api_plugin` depends upon is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](state-history-plugin.md) or the [`trace_api_plugin`](trace-api-plugin.md) instead. ::: ## Description diff --git a/docs/api-reference/tooling/nodeop/plugins/history-plugin.md b/docs/api-reference/tooling/nodeop/plugins/history-plugin.md index 32888b9..7d20f85 100644 --- a/docs/api-reference/tooling/nodeop/plugins/history-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/history-plugin.md @@ -5,7 +5,7 @@ tags: --- :::warning -| The `history_plugin` is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](state-history-plugin.md) or the [`trace_api_plugin`](trace-api-plugin.md) instead. +The `history_plugin` is deprecated and will no longer be maintained. Please use the [`state_history_plugin`](state-history-plugin.md) or the [`trace_api_plugin`](trace-api-plugin.md) instead. ::: ## Description @@ -34,13 +34,13 @@ Config Options for sysio::history_plugin: -f [ --filter-on ] arg Track actions which match receiver:action:actor. Actor may be blank to include all. Action and Actor - both blank allows all from Recieiver. + both blank allows all from Receiver. Receiver may not be blank. -F [ --filter-out ] arg Do not track actions which match receiver:action:actor. Action and Actor - both blank excludes all from Reciever. + both blank excludes all from Receiver. Actor blank excludes all from - reciever:action. Receiver may not be + receiver:action. Receiver may not be blank. ``` diff --git a/docs/api-reference/tooling/nodeop/plugins/index.md b/docs/api-reference/tooling/nodeop/plugins/index.md index 94dbfab..0a8b622 100644 --- a/docs/api-reference/tooling/nodeop/plugins/index.md +++ b/docs/api-reference/tooling/nodeop/plugins/index.md @@ -7,7 +7,7 @@ tags: ## Overview -Plugins extend the core functionality implemented in `nodeop`. Some plugins are mandatory, such as `chain_plugin`, `net_plugin`, and `producer_plugin`, which reflect the modular design of `nodeop`. The other plugins are optional as they provide nice to have features, but non-essential for the nodes operation. +Plugins extend the core functionality implemented in `nodeop`. Some plugins are mandatory, such as `chain_plugin`, `net_plugin`, and `producer_plugin`, which reflect the modular design of `nodeop`. The other plugins are optional as they provide nice to have features, but non-essential for the node's operation. For information on specific plugins, just select from the list below: @@ -25,6 +25,6 @@ For information on specific plugins, just select from the list below: * [`trace_api_plugin`](trace-api-plugin.md) ::: note -| Plugins add incremental functionality to `nodeop`. Unlike runtime plugins, `nodeop` plugins are built at compile-time. +Plugins add incremental functionality to `nodeop`. Unlike runtime plugins, `nodeop` plugins are built at compile-time. ::: diff --git a/docs/api-reference/tooling/nodeop/plugins/net-api-plugin.md b/docs/api-reference/tooling/nodeop/plugins/net-api-plugin.md index 6332778..6af556c 100644 --- a/docs/api-reference/tooling/nodeop/plugins/net-api-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/net-api-plugin.md @@ -20,7 +20,7 @@ The `net_api_plugin` provides four RPC API endpoints: See [Net API Reference Documentation](/docs/api-reference/net-api). :::danger -| This plugin exposes endpoints that allow management of p2p connections. Running this plugin on a publicly accessible node is **NOT** recommended as it can be exploited. +This plugin exposes endpoints that allow management of p2p connections. Running this plugin on a publicly accessible node is **NOT** recommended as it can be exploited. ::: ## Usage diff --git a/docs/api-reference/tooling/nodeop/plugins/producer-api-plugin.md b/docs/api-reference/tooling/nodeop/plugins/producer-api-plugin.md index a3e50d1..f4ad2bf 100644 --- a/docs/api-reference/tooling/nodeop/plugins/producer-api-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/producer-api-plugin.md @@ -11,7 +11,7 @@ tags: The `producer_api_plugin` exposes a number of endpoints for the [`producer_plugin`](producer-plugin.md) to the RPC API interface managed by the [`http_plugin`](http-plugin.md). :::danger -| This plugin exposes endpoints that allow management of p2p connections. Running this plugin on a publicly accessible node is **NOT** recommended as it can be exploited. +This plugin exposes endpoints that allow management of p2p connections. Running this plugin on a publicly accessible node is **NOT** recommended as it can be exploited. ::: See [Producer API Reference Documentation](/docs/api-reference/producer-api). diff --git a/docs/api-reference/tooling/nodeop/plugins/producer-plugin.md b/docs/api-reference/tooling/nodeop/plugins/producer-plugin.md index 50a2013..14084c6 100644 --- a/docs/api-reference/tooling/nodeop/plugins/producer-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/producer-plugin.md @@ -11,7 +11,7 @@ tags: The `producer_plugin` loads functionality required for a node to produce blocks. :::info -| Additional configuration is required to produce blocks. Please read [Configuring Block Producing Node](../usage/node-setups/producing-node.md). +Additional configuration is required to produce blocks. Please read [Configuring Block Producing Node](../usage/node-setups/producing-node.md). ::: ## Usage diff --git a/docs/api-reference/tooling/nodeop/plugins/trace-api-plugin.md b/docs/api-reference/tooling/nodeop/plugins/trace-api-plugin.md index 00a0039..9e91f6b 100644 --- a/docs/api-reference/tooling/nodeop/plugins/trace-api-plugin.md +++ b/docs/api-reference/tooling/nodeop/plugins/trace-api-plugin.md @@ -163,7 +163,7 @@ Compressed trace log files have the `.clog` file extension (see [Compression of The data is compressed into raw zlib form with full-flush *seek points* placed at regular intervals. A decompressor can start from any of these *seek points* without reading previous data and it can also traverse a seek point without issue if it appears within the data. :::info[Size reduction of trace logs] -| Data compression can reduce the space growth of trace logs twentyfold! For instance, with 512 seek points and using the test dataset on the Wire network, data compression reduces the growth of the trace directory from ~50 GiB/day to ~2.5 GiB/day for full data. Due to the high redundancy of the trace log contents, the compression is still comparable to `gzip -9`. The decompressed data is also made immediately available via the [Trace RPC API](/docs/api-reference/trace-api/) without any service degradation. +Data compression can reduce the space growth of trace logs twentyfold! For instance, with 512 seek points and using the test dataset on the Wire network, data compression reduces the growth of the trace directory from ~50 GiB/day to ~2.5 GiB/day for full data. Due to the high redundancy of the trace log contents, the compression is still comparable to `gzip -9`. The decompressed data is also made immediately available via the [Trace RPC API](/docs/api-reference/trace-api/) without any service degradation. ::: #### Role of seek points @@ -195,7 +195,7 @@ The `trace_api_plugin` also supports an option to optimize disk space by applyin If the argument `N` is 0 or greater, the plugin automatically sets a background thread to compress the irreversible sections of the trace log files. The previous N irreversible blocks past the current LIB block are left uncompressed. :::info[Trace API utility] -| The trace log files can also be compressed manually with the [trace_api_util](../../utilities/trace-api-util.md) utility. +The trace log files can also be compressed manually with the [trace_api_util](../../utilities/trace-api-util.md) utility. ::: If resource usage cannot be effectively managed via the `trace-minimum-irreversible-history-blocks` and `trace-minimum-uncompressed-irreversible-history-blocks` options, then there might be a need for periodic manual maintenance. In that case, the user may opt to manage resources through an external system or recurrent process. @@ -205,5 +205,5 @@ If resource usage cannot be effectively managed via the `trace-minimum-irreversi The `trace-dir` option defines the directory on the filesystem where the trace log files are stored by the `trace_api_plugin`. These files are stable once the LIB block has progressed past a given slice and then can be deleted at any time to reclaim filesystem space. The deployed system contract will tolerate any out-of-process management system that removes some or all of these files in this directory regardless of what data they represent, or whether there is a running `nodeop` instance accessing them or not. Data which would nominally be available, but is no longer so due to manual maintenance, will result in a HTTP 404 response from the appropriate API endpoint(s). :::info[For node operators] -| Node operators can take full control over the lifetime of the historical data available in their nodes via the `trace-api-plugin` and the `trace-minimum-irreversible-history-blocks` and `trace-minimum-uncompressed-irreversible-history-blocks` options in conjunction with any external filesystem resource manager. +Node operators can take full control over the lifetime of the historical data available in their nodes via the `trace-api-plugin` and the `trace-minimum-irreversible-history-blocks` and `trace-minimum-uncompressed-irreversible-history-blocks` options in conjunction with any external filesystem resource manager. ::: diff --git a/docs/api-reference/tooling/nodeop/storage-and-read-modes.md b/docs/api-reference/tooling/nodeop/storage-and-read-modes.md index 70ee4d3..9b86521 100644 --- a/docs/api-reference/tooling/nodeop/storage-and-read-modes.md +++ b/docs/api-reference/tooling/nodeop/storage-and-read-modes.md @@ -56,7 +56,7 @@ When `nodeop` is configured to be in irreversible read mode, it will still track ### Speculative Mode (Deprecated) -Speculative mode is low latency but fragile, there is no guarantee that the transactions reflected in the state will be included in the chain OR that they will reflected in the same order the state implies. +Speculative mode is low latency but fragile, there is no guarantee that the transactions reflected in the state will be included in the chain OR that they will be reflected in the same order the state implies. This mode features the lowest latency, but is the least consistent. diff --git a/docs/api-reference/wire-cdt/best-practices/abi/abi-code-generator-attributes-explained.md b/docs/api-reference/wire-cdt/best-practices/abi/abi-code-generator-attributes-explained.md index c285348..d43cbd3 100644 --- a/docs/api-reference/wire-cdt/best-practices/abi/abi-code-generator-attributes-explained.md +++ b/docs/api-reference/wire-cdt/best-practices/abi/abi-code-generator-attributes-explained.md @@ -64,7 +64,7 @@ class [[sysio::contract("ANY_NAME_YOU_LIKE")]] test_contract : public sysio::con }; ``` -The code above will mark this `class` as being a Wire contract, this allows for namespacing of contracts, i.e. you can include headers like `sysio::token` and not have `sysio::token`'s actions/tables wind up in you ABI or generated dispatcher. +The code above will mark this `class` as being a Wire contract, this allows for namespacing of contracts, i.e. you can include headers like `sysio::token` and not have `sysio::token`'s actions/tables wind up in your ABI or generated dispatcher. ## [[sysio::on_notify("VALID_SYSIO_ACCOUNT_NAME::VALID_SYSIO_ACTION_NAME")]] diff --git a/docs/api-reference/wire-cdt/best-practices/abi/understanding-abi-files.md b/docs/api-reference/wire-cdt/best-practices/abi/understanding-abi-files.md index f35f92a..af3d147 100644 --- a/docs/api-reference/wire-cdt/best-practices/abi/understanding-abi-files.md +++ b/docs/api-reference/wire-cdt/best-practices/abi/understanding-abi-files.md @@ -5,14 +5,14 @@ tags: --- ## Introduction -ABI files can be generated using the `cdt-cpp` utility provided by CDT. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary. +ABI files can be generated using the `cdt-cpp` utility provided by CDT. However, there are several situations that may cause ABI generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary. ## What is an ABI The Application Binary Interface (ABI) is a JSON-based description on how to convert user actions between their JSON and Binary representations. The ABI also describes how to convert the database state to/from JSON. Once you have described your contract via an ABI then developers and users will be able to interact with your contract seamlessly via JSON. ::: warning -| ABI can be bypassed when executing transactions. Messages and actions passed to a contract do not have to conform to the ABI. The ABI is a guide, not a gatekeeper. +ABI can be bypassed when executing transactions. Messages and actions passed to a contract do not have to conform to the ABI. The ABI is a guide, not a gatekeeper. ::: ## Create an ABI File @@ -37,7 +37,7 @@ Start with an empty ABI, for exemplification we will work based on the `sysio.to An ABI enables any client or interface to interpret and even generate a GUI for your contract. For this to work consistently, describe the custom types that are used as a parameter in any public action or struct that needs to be described in the ABI. ::: info -| Wire implements a number of custom built-ins. +Wire implements a number of custom built-ins. ::: ```json @@ -87,7 +87,7 @@ A struct's object definition in JSON looks like the following: } ``` -In the `sysio.token` contract, there's a number of structs that require definition. Please note, not all of the structs are explicitly defined, some correspond to an actions' parameters. Here's a list of structs that require an ABI description for the `sysio.token` contract: +In the `sysio.token` contract, there are a number of structs that require definition. Please note, not all of the structs are explicitly defined, some correspond to an action's parameters. Here's a list of structs that require an ABI description for the `sysio.token` contract: ## Implicit Structs @@ -303,7 +303,7 @@ Describe the tables. Here's a table's JSON object definition: The sysio.token contract instantiates two tables, [accounts](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L134) and [stat](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L135). -The `accounts` table is an i64 index, based on the [`account` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L120-L124), has a [`uint64` as it's primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L123) +The `accounts` table is an i64 index, based on the [`account` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L120-L124), has a [`uint64` as its primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L123) Here's how the accounts table would be described in the ABI @@ -317,7 +317,7 @@ Here's how the accounts table would be described in the ABI } ``` -The `stat` table is an i64 index, based on the [`currency_stats` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L126-L132), has a [`uint64` as it's primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L131) +The `stat` table is an i64 index, based on the [`currency_stats` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L126-L132), has a [`uint64` as its primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L131) Here's how the stat table would be described in the ABI diff --git a/docs/api-reference/wire-cdt/best-practices/data-design-and-migration.md b/docs/api-reference/wire-cdt/best-practices/data-design-and-migration.md index 97f643e..71f5b35 100644 --- a/docs/api-reference/wire-cdt/best-practices/data-design-and-migration.md +++ b/docs/api-reference/wire-cdt/best-practices/data-design-and-migration.md @@ -52,6 +52,6 @@ If you prefer less code complexity and can accept downtime for your application: 2. Deploy a new contract using only the new version of the table, at which point, your migration and downtime is complete. ::: warning -| Both of the above migration methods require some pre-planning (like the ability to put your contract into a maintenance mode for user feedback) +Both of the above migration methods require some pre-planning (like the ability to put your contract into a maintenance mode for user feedback) ::: diff --git a/docs/api-reference/wire-cdt/best-practices/debugging-a-smart-contract.md b/docs/api-reference/wire-cdt/best-practices/debugging-a-smart-contract.md index 0d9d64e..6a9a233 100644 --- a/docs/api-reference/wire-cdt/best-practices/debugging-a-smart-contract.md +++ b/docs/api-reference/wire-cdt/best-practices/debugging-a-smart-contract.md @@ -4,11 +4,11 @@ tags: - debugging --- -In order to be able to debug your smart contract, you will need to setup a local `nodeop` node. This local `nodeop` node can be run as separate private testnet or as an extension of a public testnet. This local node also needs to be run with the contracts-console option on, either `--contracts-console` via the command line or `contracts-console = true` via the `config.ini` file and/or by setting up logging on your running node and checking the output logs. +In order to be able to debug your smart contract, you will need to set up a local `nodeop` node. This local `nodeop` node can be run as a separate private testnet or as an extension of a public testnet. This local node also needs to be run with the contracts-console option on, either `--contracts-console` via the command line or `contracts-console = true` via the `config.ini` file and/or by setting up logging on your running node and checking the output logs. See below for details on logging. -When you are creating your smart contract for the first time, it is recommended to test and debug your smart contract on a private testnet first, since you have full control of the whole blockchain and can easily add suitable logging. This enables you to have unlimited amount of eos needed and you can just reset the state of the blockchain whenever you want. When it is ready for production, debugging on the public testnet (or official testnet) can be done by connecting your local nodeop to the public testnet (or official testnet) so you can see the log of the testnet in your local nodeop. +When you are creating your smart contract for the first time, it is recommended to test and debug your smart contract on a private testnet first, since you have full control of the whole blockchain and can easily add suitable logging. This enables you to have an unlimited amount of tokens needed and you can just reset the state of the blockchain whenever you want. When it is ready for production, debugging on the public testnet (or official testnet) can be done by connecting your local nodeop to the public testnet (or official testnet) so you can see the log of the testnet in your local nodeop. The concept is the same, so for the following guide, debugging on the private testnet will be covered. @@ -16,11 +16,11 @@ If you haven't set up your own local `nodeop`, follow the [Setup guide](https:// # Method -The main method used to debug smart contract is **Caveman Debugging**. Printing is utilized to inspect the value of a variable and check the flow of the contract. Printing in smart contracts can be done through the Print API. The C++ API is a wrapper for C API and is the recommended API. +The main method used to debug a smart contract is **Caveman Debugging**. Printing is utilized to inspect the value of a variable and check the flow of the contract. Printing in smart contracts can be done through the Print API. The C++ API is a wrapper for C API and is the recommended API. # Print -Print C API supports the following data type that you can print: +Print C API supports the following data types that you can print: - prints - a null terminated char array (string) - prints_l - any char array (string) with given size diff --git a/docs/api-reference/wire-cdt/best-practices/securing-your-contract.md b/docs/api-reference/wire-cdt/best-practices/securing-your-contract.md index a082911..dde0603 100644 --- a/docs/api-reference/wire-cdt/best-practices/securing-your-contract.md +++ b/docs/api-reference/wire-cdt/best-practices/securing-your-contract.md @@ -13,7 +13,7 @@ The following are basic recommendations which can be the foundation for securing ### 1. Authorization Checks -The following methods are available in the Wire Sysio core software and they can be used to implemented authorization checks in your smart contracts: +The following methods are available in the Wire Sysio core software and they can be used to implement authorization checks in your smart contracts: - `has_auth` - `require_auth` diff --git a/docs/api-reference/wire-cdt/troubleshooting.md b/docs/api-reference/wire-cdt/troubleshooting.md index dd80481..2230906 100644 --- a/docs/api-reference/wire-cdt/troubleshooting.md +++ b/docs/api-reference/wire-cdt/troubleshooting.md @@ -145,7 +145,7 @@ __Possible solution__: The key point here is the `expected order` and what you t } ``` -The code above has one `print` statement before the `singleton_set.send` and another one after the `singleton_set.send`. If you wrote some more `print` statements in the code that implements the `singleton_set.send` action and expect to see them before the second `print` statement then it is a wrong assumption. The inline actions are broadcasted to the network and they are executed at a different time, asynchronous of the current execution thread of the current `multi_index_example::mod` action, therefor it is impossible to predict when the `print` statements from inline action code will be outputted. +The code above has one `print` statement before the `singleton_set.send` and another one after the `singleton_set.send`. If you wrote some more `print` statements in the code that implements the `singleton_set.send` action and expect to see them before the second `print` statement then it is a wrong assumption. The inline actions are broadcasted to the network and they are executed at a different time, asynchronously from the current execution thread of the current `multi_index_example::mod` action, therefore it is impossible to predict when the `print` statements from inline action code will be outputted. ## Assertion failure while creating an account after sysio.system was installed diff --git a/docs/api-reference/wire-cdt/tutorials/abi-variants.md b/docs/api-reference/wire-cdt/tutorials/abi-variants.md index a1486ce..1ab809e 100644 --- a/docs/api-reference/wire-cdt/tutorials/abi-variants.md +++ b/docs/api-reference/wire-cdt/tutorials/abi-variants.md @@ -160,5 +160,5 @@ class [[sysio::contract]] multi_index_example : public contract { ``` :::warning -| Be aware, it is not recommend to use `sysio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated! +Be aware, it is not recommend to use `sysio::binary_extension` inside variant definition, this can lead to data corruption unless one is very careful in understanding how these two templates work and how the ABI gets generated! ::: diff --git a/docs/api-reference/wire-cdt/tutorials/create-an-abi-file.md b/docs/api-reference/wire-cdt/tutorials/create-an-abi-file.md index b142bcc..92944da 100644 --- a/docs/api-reference/wire-cdt/tutorials/create-an-abi-file.md +++ b/docs/api-reference/wire-cdt/tutorials/create-an-abi-file.md @@ -7,13 +7,13 @@ tags: ## Overview -This tutorial provides instructions to how to hand-write an ABI file. This should normally not be necessary since `cdt-cpp` can automatically generate an ABI file from your source code if it is properly annotated. +This tutorial provides instructions on how to hand-write an ABI file. This should normally not be necessary since `cdt-cpp` can automatically generate an ABI file from your source code if it is properly annotated. ## Introduction The Application Binary Interface (ABI) is a JSON-based description to convert user actions between their JSON and Binary representations. The ABI also describes how to convert the database state to/from JSON. Once you have described your contract via an ABI then developers and users will be able to interact with your contract seamlessly via JSON. -This tutorial will use the [sysio.token](https://github.com/Wire-Network/wire-system-contracts/tree/master/contracts/sysio.token) contract as an example. *sysio.token contract does not cover every possible permutation of an ABI definition. +This tutorial will use the [sysio.token](https://github.com/Wire-Network/wire-system-contracts/tree/master/contracts/sysio.token) contract as an example. *sysio.token contract does not cover every possible permutation of an ABI definition.* To make things easy, we will start with an empty ABI. @@ -33,7 +33,7 @@ To make things easy, we will start with an empty ABI. ## Types -An ABI enables any client or interface to interpret and even generate an GUI for you contract. For this to work in a consistent manner, we'll need to describe the custom types that are used as a parameter in any public action or struct that we would like to describe in the ABI. +An ABI enables any client or interface to interpret and even generate a GUI for your contract. For this to work in a consistent manner, we'll need to describe the custom types that are used as a parameter in any public action or struct that we would like to describe in the ABI. :::info |Built-in Types @@ -72,7 +72,7 @@ Our ABI now looks like this: ## Structs -We now need to describe the structs of the token contract. By looking at `sysio.token.hpp`, we can quickly determine which structs are utilized by public actions. This is particularly important for when we describe our actions in the the ABI file in the next step. +We now need to describe the structs of the token contract. By looking at `sysio.token.hpp`, we can quickly determine which structs are utilized by public actions. This is particularly important for when we describe our actions in the ABI file in the next step. A struct's object definition in JSON looks like the following: @@ -91,7 +91,7 @@ A struct's object definition in JSON looks like the following: } ``` -Looking through the `sysio.token` contract, we see a number of structs that require definition. Please note, not all of the structs are explicitly defined, some correspond to an actions' parameters. Here's a list of structs that require an ABI description for the `sysio.token` contract: +Looking through the `sysio.token` contract, we see a number of structs that require definition. Please note, not all of the structs are explicitly defined, some correspond to an action's parameters. Here's a list of structs that require an ABI description for the `sysio.token` contract: ## Implicit Structs @@ -258,7 +258,7 @@ An action's JSON object definition looks like the following: } ``` -Next, we'll describe the actions of the `sysio.token` contract by aggregating all the public functions describe in the `sysio.token` contract's [header file](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L24-L36). We'll then describe each action's *type* to their previously described struct. In most situations, the function name and the struct name will be equal, but are not required to be equal. +Next, we'll describe the actions of the `sysio.token` contract by aggregating all the public functions described in the `sysio.token` contract's [header file](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L24-L36). We'll then map each action's *type* to its previously described struct. In most situations, the function name and the struct name will be equal, but are not required to be equal. Below is a list of actions that link to their source code with example JSON provided for how each action would be described. @@ -330,7 +330,7 @@ Finally, we need to describe our tables. Here's a table's JSON object definition The sysio.token contract instantiates two tables, [accounts](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L57) and [stat](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L58). -The accounts table is an i64 index, based on the [`account` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L43-L47), has a [`uint64` as it's primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L46) and it's key been arbitrarily named "currency". +The accounts table is an i64 index, based on the [`account` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L43-L47), has a [`uint64` as its primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L46) and its key has been arbitrarily named "currency". Here's how the accounts table would be described in the ABI @@ -344,7 +344,7 @@ Here's how the accounts table would be described in the ABI } ``` -The stat table is an i64 index, based on the [`currenct_stats` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L49-L55), has a [`uint64` as it's primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L54) and it's key been arbitrarily named "currency" +The stat table is an i64 index, based on the [`currency_stats` struct](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L49-L55), has a [`uint64` as its primary key](https://github.com/Wire-Network/wire-system-contracts/blob/master/contracts/sysio.token/include/sysio.token/sysio.token.hpp#L54) and its key has been arbitrarily named "currency" Here's how the stat table would be described in the ABI @@ -362,7 +362,7 @@ You'll notice the above tables have the same "key name." Naming your keys simila ## Putting it all Together -Finally, once all the pieces are strewn together, we have ourselves a ABI file that accurately describes the `sysio.token` contract. +Finally, once all the pieces are strewn together, we have ourselves an ABI file that accurately describes the `sysio.token` contract. ```json { @@ -579,4 +579,4 @@ Every time you change a struct, add a table, add an action or add parameters to ### Table returns no rows -Check that your table is accurately described in the `<>` file. For example, If you use `clio` to add a table on a contract with a malformed `<>` definition and then get rows from that table, you will recieve an empty result. `clio` will not produce an error when adding a row nor reading a row when a contract has failed to properly describe its tables in its `<>` File. +Check that your table is accurately described in the `<>` file. For example, If you use `clio` to add a table on a contract with a malformed `<>` definition and then get rows from that table, you will receive an empty result. `clio` will not produce an error when adding a row nor reading a row when a contract has failed to properly describe its tables in its `<>` file. diff --git a/docs/getting-started/create-development-accounts.md b/docs/getting-started/create-development-accounts.md index 7b6540c..d18cbc0 100644 --- a/docs/getting-started/create-development-accounts.md +++ b/docs/getting-started/create-development-accounts.md @@ -23,13 +23,13 @@ The install process has already set up the wallet for the *root* user. To intera ## Overview -This article gives a brief summary of the concept of account and provides instructions on how to create a new account. +This article gives a brief summary of the concept of an account and provides instructions on how to create a new account. ## Account An **account** on the blockchain is the identity of a participant on the blockchain — whether a single user, a group, or a smart-contract actor — and it carries the authorizations that control what that participant can do. This flexible permission framework lets ownership be assigned to one key, multiple keys, or even other accounts. Because every action or transaction must be signed by an account, a valid account is required to send, receive, or invoke smart-contract actions with other accounts on-chain. -In this practical tutorial series, we utilize two user accounts, `bob` and `alice`, along with the default `sysio` account for configuration purposes. Additional accounts are also created for various contracts in the future articles. +In this practical tutorial series, we utilize two user accounts, `bob` and `alice`, along with the default `sysio` account for configuration purposes. Additional accounts are also created for various contracts in future articles. ## Creating an account @@ -51,7 +51,7 @@ Here is the output of the first command, confirming that the transaction has bee ![creating-account](/img/clio-create-account.png) -If you encounter errors ensure you are correctly loading environment variables and that your wallet is unlocked. +If you encounter errors, ensure you are correctly loading environment variables and that your wallet is unlocked. - inspect value of `$PUBLIC_KEY` by `echo $PUBLIC_KEY` @@ -82,9 +82,9 @@ For a clear understanding of how Wire accounts and their associated public keys ## Troubleshooting -### `[clio: Failed to connect to nodeop at ](http://127.0.0.1:8888/); is nodeop running?` +### `clio: Failed to connect to nodeop at http://127.0.0.1:8888/; is nodeop running?` -Doublecheck if `nodeop` is running; and use `/opt/wire-network/blockproducer/stop.sh` and `/opt/wire-network/blockproducer/start.sh` to restart the node. +Double-check if `nodeop` is running; and use `/opt/wire-network/blockproducer/stop.sh` and `/opt/wire-network/blockproducer/start.sh` to restart the node. ```bash pidof nodeop diff --git a/docs/getting-started/getting-started-intro.md b/docs/getting-started/getting-started-intro.md index 0e7362e..7a2125a 100644 --- a/docs/getting-started/getting-started-intro.md +++ b/docs/getting-started/getting-started-intro.md @@ -12,7 +12,7 @@ tags: # Getting Started :::info -The diagram below serves as a comprehensive roadmap, detailing the *sequential steps required to effectively utilize the documentation provided*. For optimal understanding and efficiency, it’s important to follow the order of the steps, beggining with this article, contunuing with setting up your local environment and progressing through the smart development contracts section. +The diagram below serves as a comprehensive roadmap, detailing the *sequential steps required to effectively utilize the documentation provided*. For optimal understanding and efficiency, it’s important to follow the order of the steps, beginning with this article, continuing with setting up your local environment and progressing through the smart contract development section. ::: @@ -28,7 +28,7 @@ The Wire platform is supported on the following environments: ## System Info -The subsequent tutorials([hello world contract](../smart-contract-development/hello-world-contract-short.md), [company contract](../smart-contract-development/company-contract.md)) are up to date with the following Wire components. +The subsequent tutorials ([hello world contract](../smart-contract-development/hello-world-contract-short.md), [company contract](../smart-contract-development/company-contract.md)) are up to date with the following Wire components. | Component | Version | | ------------------ | ------- | @@ -37,13 +37,13 @@ The subsequent tutorials([hello world contract](../smart-contract-development/he ## Development Experience -Wire based blockchains execute user-generated applications and code using WebAssembly (WASM). WASM is an emerging web standard with widespread support from Google, Microsoft, Apple, and industry leading companies. +Wire based blockchains execute user-generated applications and code using WebAssembly (WASM). WASM is an emerging web standard with widespread support from Google, Microsoft, Apple, and industry-leading companies. At the moment the most mature toolchain for building applications that compile to WASM is clang/llvm with their C/C++ compiler. ### Command Line Knowledge -There are a variety of tools provided along with Wire core and CDT packages which requires you to have a basic command line knowledge in order to interact with them. +There are a variety of tools provided along with Wire core and CDT packages which require you to have a basic command line knowledge in order to interact with them. ### Development Tools diff --git a/docs/getting-started/install-dependencies.md b/docs/getting-started/install-dependencies.md index 546d4d2..a3562de 100644 --- a/docs/getting-started/install-dependencies.md +++ b/docs/getting-started/install-dependencies.md @@ -42,7 +42,7 @@ sudo wire-cli install -g ``` :::info -It is important to note that we are *intentially* using wire-cli to launch a full-scale Wire blockchain environment. This is a multi-node setup(**blockproducer**, **bp-relay**, and **chain-api**) with deployed system contracts, resource management, including contract policies, all very similar to a testnet configuration setup. +It is important to note that we are *intentionally* using wire-cli to launch a full-scale Wire blockchain environment. This is a multi-node setup (**blockproducer**, **bp-relay**, and **chain-api**) with deployed system contracts, resource management, including contract policies, all very similar to a testnet configuration setup. ::: ##### Verify installation @@ -81,7 +81,7 @@ Expected Output -> cdt-cpp version 4.1.1 ``` :::info -Wire CDT is located at `/usr/opt` with symlinks to each of its executable in `/usr/bin`. You can list the contents using `ls -la usr/opt/cdt//bin`. +Wire CDT is located at `/usr/opt` with symlinks to each of its executables in `/usr/bin`. You can list the contents using `ls -la usr/opt/cdt//bin`. :::   @@ -117,7 +117,7 @@ info [timestamp] nodeop controller.cpp:2375 log_applied ] Pr info [timestamp] nodeop controller.cpp:2375 log_applied ] Produced block a505dcb166388262... #4248 @ 2026-03-16T15:56:46.500 signed by sysio [trxs: 0, lib: 4246, net: 0, cpu: 100 us, elapsed: 81 us, producing time: 462054 us] ``` -Verify the `[timestamp]` is a recent one and that you aren't looking at a stale logs. +Verify the `[timestamp]` is a recent one and that you aren't looking at stale logs. To exit logs: Ctrl + C diff --git a/docs/getting-started/manage-local-wallet-with-clio.md b/docs/getting-started/manage-local-wallet-with-clio.md index d116366..b24aeab 100644 --- a/docs/getting-started/manage-local-wallet-with-clio.md +++ b/docs/getting-started/manage-local-wallet-with-clio.md @@ -51,7 +51,7 @@ Wallets: ## Unlock a Wallet -The `kiod` wallet(s) have been opened, but is still locked. +The `kiod` wallet(s) have been opened, but are still locked. ```bash clio wallet unlock @@ -88,7 +88,7 @@ The asterisk (\*) next to the name means that the wallet is currently *unlocked* ## Create and Import keys into your wallet​ -To generate a key pair directly within the wallet, you could use `clio wallet create_key` command. +To generate a key pair directly within the wallet, you could use the `clio wallet create_key` command. ```bash clio wallet create_key @@ -126,7 +126,7 @@ clio wallet keys_by_name --password "$(cat /opt/wire-network/secrets/wallet_pas :::warning[IMPORTANT] -**Save the public key somewhere safe as you would need it in the upcoming tutorials.** +**Save the public key somewhere safe as you will need it in the upcoming tutorials.** You could set it as environment variable: @@ -138,7 +138,7 @@ You could set it as environment variable: ## Import the Development Key​ -Every new Wire chain has a default system user called `sysio`. This account is used to setup the chain by deploying system contracts that handle essential functions related to resource management, governance and consensus of the chain. +Every new Wire chain has a default system user called `sysio`. This account is used to set up the chain by deploying system contracts that handle essential functions related to resource management, governance and consensus of the chain. Every new Wire chain also comes with a *development key*, and this key is always the same one. diff --git a/docs/guides/clio-options.md b/docs/guides/clio-options.md index e9c0a31..13320ea 100644 --- a/docs/guides/clio-options.md +++ b/docs/guides/clio-options.md @@ -51,7 +51,7 @@ clio --url : COMMAND ``` :::info[Default address:port] -| If no optional arguments are used (i.e. no `--url`), `clio` attempts to connect to a local `nodeop` running at localhost or `127.0.0.1` and default port `8888`. Use the `nodeop` command line arguments or [config.ini](/docs/api-reference/tooling/nodeop/usage/nodeop-configuration.md) file to specify a different address. +If no optional arguments are used (i.e. no `--url`), `clio` attempts to connect to a local `nodeop` running at localhost or `127.0.0.1` and default port `8888`. Use the `nodeop` command line arguments or [config.ini](/docs/api-reference/tooling/nodeop/usage/nodeop-configuration.md) file to specify a different address. ::: --- @@ -65,7 +65,7 @@ clio --wallet-url http://:8900 COMMAND ``` :::info[Default address:port] -| If no optional arguments are used (i.e. no `--wallet-url`), `clio` attempts to connect to a local `nodeop` or `kiod` running at localhost or `127.0.0.1` and default port `8900`. Use the `kiod` command line arguments or [config.ini](/docs/api-reference/tooling/kiod/usage.md#launching-kiod-manually) file to specify a different address. +If no optional arguments are used (i.e. no `--wallet-url`), `clio` attempts to connect to a local `nodeop` or `kiod` running at localhost or `127.0.0.1` and default port `8900`. Use the `kiod` command line arguments or [config.ini](/docs/api-reference/tooling/kiod/usage.md#launching-kiod-manually) file to specify a different address. ::: ## Reference diff --git a/docs/guides/hello-world-video-testnet.mdx b/docs/guides/hello-world-video-testnet.mdx index 6165852..3a78d8c 100644 --- a/docs/guides/hello-world-video-testnet.mdx +++ b/docs/guides/hello-world-video-testnet.mdx @@ -72,7 +72,7 @@ sudo clio wallet import --private-key ### 5. Compile the Contract -Compile it using the `./build.sh`. This script uses the Wire Contract Development Toolkit (CDT) the `hello-world` contract into WebAssembly (WASM) format. The script will create a compilation folder `hello/` with the WASM and ABI files. +Compile it using the `./build.sh`. This script uses the Wire Contract Development Toolkit (CDT) to compile the `hello-world` contract into WebAssembly (WASM) format. The script will create a compilation folder `hello/` with the WASM and ABI files. ```bash ./build.sh @@ -83,11 +83,11 @@ Upon successful compilation, you will see a `hello/` folder with `hello.abi` and ```sh title="hello-world-contract/" -| .... + .... ├── hello │ ├── hello.abi │ └── hello.wasm -| ... + ... ``` ### 6. Deploy the Contract @@ -125,7 +125,7 @@ The Hello World contract includes a single action called `hi()`, which logs a gr - In the [Wire Hub](https://hub.wire.network), open the *Contract* Tab for your contract’s account. - You’ll see *Actions* listed (in this case, just `hi`) and parameters field. -- To invoke the action, enter a username(e.g. `bob`) and click Submit. +- To invoke the action, enter a username (e.g. `bob`) and click Submit. - The Hub displays a receipt upon success, and you can view the console log output: ```txt diff --git a/docs/guides/how-to-create-a-wallet.md b/docs/guides/how-to-create-a-wallet.md index 89edc8f..407b40e 100644 --- a/docs/guides/how-to-create-a-wallet.md +++ b/docs/guides/how-to-create-a-wallet.md @@ -18,7 +18,7 @@ Make sure you meet the following requirements: * Install the currently supported version of `clio`. :::info -| The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * Understand what an [account](/docs/introduction/glossary.md#account) is and its role in the blockchain. diff --git a/docs/guides/how-to-create-an-account.md b/docs/guides/how-to-create-an-account.md index ac97d14..15905e7 100644 --- a/docs/guides/how-to-create-an-account.md +++ b/docs/guides/how-to-create-an-account.md @@ -16,7 +16,7 @@ In a Wire Blockchain, creating a new account is a privilege reserved for existin * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: * [Accounts and Permissions](/docs/smart-contract-development/accounts-permissions.md). @@ -48,11 +48,11 @@ clio create account [creator account name] [new account name] [OwnerKey] [Active | `ActiveKey` | The public key for the active permission (optional but recommended) | :::tip[Recommend] -| `ActiveKey` is optional but recommended. If omitted, the `OwnerKey` will be used for both permissions. +`ActiveKey` is optional but recommended. If omitted, the `OwnerKey` will be used for both permissions. ::: :::info[Note] -| To create a new account in the Wire blockchain, an existing account, also referred to as a creator account, is required to authorize the creation of a new account. For a newly created Wire blockchain, the default system account used to create a new account is `sysio`. +To create a new account in the Wire blockchain, an existing account, also referred to as a creator account, is required to authorize the creation of a new account. For a newly created Wire blockchain, the default system account used to create a new account is `sysio`. ::: ### Example diff --git a/docs/guides/how-to-create-key-pairs.md b/docs/guides/how-to-create-key-pairs.md index 0d57bd5..3a4ff91 100644 --- a/docs/guides/how-to-create-key-pairs.md +++ b/docs/guides/how-to-create-key-pairs.md @@ -14,7 +14,7 @@ tags: * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] diff --git a/docs/guides/how-to-deploy-a-smart-contract.md b/docs/guides/how-to-deploy-a-smart-contract.md index fa0b3b0..9a5e4ab 100644 --- a/docs/guides/how-to-deploy-a-smart-contract.md +++ b/docs/guides/how-to-deploy-a-smart-contract.md @@ -18,7 +18,7 @@ This guide provides instructions to deploy a smart contract. * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] @@ -42,7 +42,7 @@ clio set contract [wasm-file] [abi-file] Replace the `contract_folder` with the path that points to your contract folder. :::info[Default contract name] -| By default, `clio` treats the last folder specified in `contract_folder` as the contract name. Therefore, it expects `.wasm` and `.abi` files with that contract name as filename. This can be overridden with the optional `wasm-file` and `abi-file` parameters. +By default, `clio` treats the last folder specified in `contract_folder` as the contract name. Therefore, it expects `.wasm` and `.abi` files with that contract name as filename. This can be overridden with the optional `wasm-file` and `abi-file` parameters. ::: ## Reference diff --git a/docs/guides/how-to-get-account-information.md b/docs/guides/how-to-get-account-information.md index 9905bab..b45dc07 100644 --- a/docs/guides/how-to-get-account-information.md +++ b/docs/guides/how-to-get-account-information.md @@ -18,7 +18,7 @@ This guide explains how to retrieve account information using the `clio get acco * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: :::warning[REMINDER] @@ -65,5 +65,5 @@ SYS balances: ``` :::info[Account Fields] -| Depending on the network you are connected, you might see different fields associated with an account. +Depending on the network you are connected to, you might see different fields associated with an account. ::: diff --git a/docs/guides/how-to-get-block-information.md b/docs/guides/how-to-get-block-information.md index 480bbfb..295d764 100644 --- a/docs/guides/how-to-get-block-information.md +++ b/docs/guides/how-to-get-block-information.md @@ -14,7 +14,7 @@ tags: * Install the currently supported version of `clio`. :::info[Note] -| The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: diff --git a/docs/guides/how-to-get-tables-information.md b/docs/guides/how-to-get-tables-information.md index e62770a..3daad76 100644 --- a/docs/guides/how-to-get-tables-information.md +++ b/docs/guides/how-to-get-tables-information.md @@ -18,7 +18,7 @@ This guide explains how to query data from a smart contract's multi-index table * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] diff --git a/docs/guides/how-to-import-a-key.md b/docs/guides/how-to-import-a-key.md index 33f9a28..1e5b587 100644 --- a/docs/guides/how-to-import-a-key.md +++ b/docs/guides/how-to-import-a-key.md @@ -14,7 +14,7 @@ tags: * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] diff --git a/docs/guides/how-to-list-all-key-pairs.md b/docs/guides/how-to-list-all-key-pairs.md index 1594156..9e9db3f 100644 --- a/docs/guides/how-to-list-all-key-pairs.md +++ b/docs/guides/how-to-list-all-key-pairs.md @@ -14,7 +14,7 @@ tags: * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] @@ -74,7 +74,7 @@ clio wallet private_keys ``` :::danger -| You should **NEVER** reveal your private keys in a production environment! +You should **NEVER** reveal your private keys in a production environment! ::: ### 4. List keys by name diff --git a/docs/guides/how-to-set-custom-permission.md b/docs/guides/how-to-set-custom-permission.md index ebc970b..0b9264b 100644 --- a/docs/guides/how-to-set-custom-permission.md +++ b/docs/guides/how-to-set-custom-permission.md @@ -18,7 +18,7 @@ As shown in the tutorial below, you can assign a custom permission — such as ` * Install the currently supported version of `clio.` :::note -| The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: diff --git a/docs/guides/how-to-submit-a-transaction.md b/docs/guides/how-to-submit-a-transaction.md index 161899e..370fdac 100644 --- a/docs/guides/how-to-submit-a-transaction.md +++ b/docs/guides/how-to-submit-a-transaction.md @@ -15,7 +15,7 @@ It covers two methods: pushing an action directly or submitting a JSON transacti ## Prerequisites -* Install the currently supported version of `clio`. which is distributed as part of the [Wire software suite](https://github.com/Wire-Network/wire-sysio/blob/master/README.md). To install `clio`, visit the [Install Dependencies](/docs/getting-started/install-dependencies.md) section. +* Install the currently supported version of `clio`, which is distributed as part of the [Wire software suite](https://github.com/Wire-Network/wire-sysio/blob/master/README.md). To install `clio`, visit the [Install Dependencies](/docs/getting-started/install-dependencies.md) section. * Understand [action](/docs/introduction/glossary.md#action) and [transaction](/docs/introduction/glossary.md#transaction). @@ -138,7 +138,7 @@ echo '{ * Alternatively, you can also create a JSON snippet that uses clear text JSON for `data` field. :::warning -| Be aware that if a clear text `data` field is used, `clio` needs to fetch the smart contract's ABI using `nodeop` API. This operation has an **overall performance overhead for both `clio` and `nodeop`.** On the other hand, if hex data is used in the `data` field then the ABI fetching is not executed and thus the total time to send and execute the transaction is faster. +Be aware that if a clear text `data` field is used, `clio` needs to fetch the smart contract's ABI using `nodeop` API. This operation has an **overall performance overhead for both `clio` and `nodeop`.** On the other hand, if hex data is used in the `data` field then the ABI fetching is not executed and thus the total time to send and execute the transaction is faster. ::: ```json diff --git a/docs/guides/how-to-unlink-permission.md b/docs/guides/how-to-unlink-permission.md index 692279e..9bca89c 100644 --- a/docs/guides/how-to-unlink-permission.md +++ b/docs/guides/how-to-unlink-permission.md @@ -16,7 +16,7 @@ This guide explains how to remove a custom permission link from a smart contract * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] diff --git a/docs/guides/how-to-update-account-keys.md b/docs/guides/how-to-update-account-keys.md index 9a952c9..31f9f37 100644 --- a/docs/guides/how-to-update-account-keys.md +++ b/docs/guides/how-to-update-account-keys.md @@ -21,7 +21,7 @@ Always ensure you have a secure backup of your current keys before updating them * Install the currently supported version of `clio.` :::info[Note] -| The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a local Wire node. diff --git a/docs/guides/multi-index/how-to-delete-data-from-a-multi-index-table.md b/docs/guides/multi-index/how-to-delete-data-from-a-multi-index-table.md index e4b9229..35ff136 100644 --- a/docs/guides/multi-index/how-to-delete-data-from-a-multi-index-table.md +++ b/docs/guides/multi-index/how-to-delete-data-from-a-multi-index-table.md @@ -33,7 +33,7 @@ Use the multi-index `find(...)` method to locate the user object you want to del ### 2. Delete the User(if found) -Check to see if the user exists and use `erase(...)` method to delete the row from table. Otherwise print an informational message and return. +Check to see if the user exists and use the `erase(...)` method to delete the row from table. Otherwise print an informational message and return. ```cpp title="contract.cpp" [[sysio::action]] void multi_index_example::del(name user) { diff --git a/docs/guides/nodeop/how-to-create-snapshot-with-full-history.md b/docs/guides/nodeop/how-to-create-snapshot-with-full-history.md index b900368..4cfb26c 100644 --- a/docs/guides/nodeop/how-to-create-snapshot-with-full-history.md +++ b/docs/guides/nodeop/how-to-create-snapshot-with-full-history.md @@ -26,7 +26,7 @@ curl http://127.0.0.1:8887/v1/producer/create_snapshot | json_pp * Wait for `nodeop` to process several more blocks after the snapshot completed. This ensures that the state-history files include **at least one block** beyond the snapshot, and that the `blocks.log` file contains the next block after it becomes irreversible. :::info -| If the block included in the snapshot is forked out, then the snapshot will be invalid. +If the block included in the snapshot is forked out, then the snapshot will be invalid. ::: 1. Stop `nodeop` by running: `/opt/wire-network/blockproducer/stop.sh`. diff --git a/docs/guides/nodeop/how-to-fast-start-without-old-history.md b/docs/guides/nodeop/how-to-fast-start-without-old-history.md index 0315cc7..6482a65 100644 --- a/docs/guides/nodeop/how-to-fast-start-without-old-history.md +++ b/docs/guides/nodeop/how-to-fast-start-without-old-history.md @@ -19,7 +19,7 @@ This process will permanently delete all historical blockchain data from your lo - Install the currently supported version of `clio`. :::info -| The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool and `kiod` are bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: - Learn about [Using Nodeop](/docs/api-reference/tooling/nodeop/usage/index.md). @@ -59,7 +59,7 @@ Do not stop `nodeop` until it has received *at least 1 block* from the network, If `nodeop` fails to receive blocks from the network, then try the above using `net_api_plugin`. Use [`clio net disconnect`](/docs/api-reference/tooling/clio/command-reference/net/disconnect.md) and [`clio net connect`](/docs/api-reference/tooling/clio/command-reference/net/connect.md) to reconnect nodes which timed out. -You must have the `net_api_plugin` enabled on your `nodeop` instance. That plugin is **not** enabled `/opt/wire-network/blockproducer/config/config.ini` by default, so you will need to stop your node and edit the `config.ini` file to enable it: +You must have the `net_api_plugin` enabled on your `nodeop` instance. That plugin is **not** enabled in `/opt/wire-network/blockproducer/config/config.ini` by default, so you will need to stop your node and edit the `config.ini` file to enable it: ```ini # ....previous plugins ... @@ -67,5 +67,5 @@ plugin = sysio::net_api_plugin ``` :::warning[Caution when using `net_api_plugin`] -| Use use a firewall to block access to your `http-server-address` despite port 8887 not being exposed to the public by default. The `net_api_plugin` is not intended for public use and should only be used in a secure environment. +Use a firewall to block access to your `http-server-address` despite port 8887 not being exposed to the public by default. The `net_api_plugin` is not intended for public use and should only be used in a secure environment. ::: diff --git a/docs/guides/nodeop/how-to-generate-a-snapshot.md b/docs/guides/nodeop/how-to-generate-a-snapshot.md index 8105ee8..97c71fd 100644 --- a/docs/guides/nodeop/how-to-generate-a-snapshot.md +++ b/docs/guides/nodeop/how-to-generate-a-snapshot.md @@ -12,7 +12,7 @@ tags: You can create a snapshot by using the [`create_snapshot` API endpoint](https://docs.wire.network/docs/api-reference/producer-api#operation/create_snapshot) supported by the `producer_api_plugin`. This will create a snapshot file in the `data/snapshots` directory. Snapshot files are written to disk with the name pattern `*snapshot-\.bin*`. :::info[Snapshots Location] -| By default, snapshots are written to the `/opt/wire-network/blockproducer/data/snapshots` directory. +By default, snapshots are written to the `/opt/wire-network/blockproducer/data/snapshots` directory. ::: ## Prerequisites diff --git a/docs/guides/nodeop/how-to-replay-from-a-snapshot.md b/docs/guides/nodeop/how-to-replay-from-a-snapshot.md index 05431bb..2c74065 100644 --- a/docs/guides/nodeop/how-to-replay-from-a-snapshot.md +++ b/docs/guides/nodeop/how-to-replay-from-a-snapshot.md @@ -13,7 +13,7 @@ Location | Name | Action data/snapshots | `.bin` | place the snapshot file you want to replay here | data/ | * | remove | -You can use `snapshots-dir = "snapshots"` in the configuration file or using the `--snapshots-dir` command line option, to specify the where to find the the snapshot to replay, use `--snapshot` to specify the name of the snapshot to replay. +You can use `snapshots-dir = "snapshots"` in the configuration file or using the `--snapshots-dir` command line option, to specify where to find the snapshot to replay, use `--snapshot` to specify the name of the snapshot to replay. ```sh nodeop --snapshot yoursnapshot.name \ diff --git a/docs/guides/restrict-access-to-an-action-by-user.md b/docs/guides/restrict-access-to-an-action-by-user.md index 0451777..169ae7f 100644 --- a/docs/guides/restrict-access-to-an-action-by-user.md +++ b/docs/guides/restrict-access-to-an-action-by-user.md @@ -17,7 +17,7 @@ This guide provides instructions on how to perform authorization checks in a sma * Install the currently supported version of `clio` :::info -| The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. +The `clio` tool is bundled with the Wire software. [Installing Wire Core](/docs/getting-started/install-dependencies.md) will also install the clio tool. ::: :::warning[REMINDER] diff --git a/docs/guides/sysio-code-tutorial.md b/docs/guides/sysio-code-tutorial.md index 939ee46..ff2ddd6 100644 --- a/docs/guides/sysio-code-tutorial.md +++ b/docs/guides/sysio-code-tutorial.md @@ -21,7 +21,7 @@ The `sysio.code` permission is a special authority flag that enables a smart con * Install the currently supported version of `clio`. :::note -| The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. +The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools. ::: * You have access to a local Wire node. diff --git a/docs/guides/working-with-different-action-return-types.md b/docs/guides/working-with-different-action-return-types.md index b34a95e..ec512ea 100644 --- a/docs/guides/working-with-different-action-return-types.md +++ b/docs/guides/working-with-different-action-return-types.md @@ -71,7 +71,7 @@ Before deploying, ensure you have an open wallet and account to deploy the contr :::note -In Wire ecosystem, deploying a smart contract requires an account; an account can own one smart contract instance and a smart contract instance must be deployed to an account. Each account functions as a distinct namespace for the contract, which means that the contract’s code and its state are encapsulated within that account. +In the Wire ecosystem, deploying a smart contract requires an account; an account can own one smart contract instance and a smart contract instance must be deployed to an account. Each account functions as a distinct namespace for the contract, which means that the contract’s code and its state are encapsulated within that account. ::: diff --git a/docs/introduction/glossary.md b/docs/introduction/glossary.md index 5b2e9f7..42eb6f2 100644 --- a/docs/introduction/glossary.md +++ b/docs/introduction/glossary.md @@ -14,7 +14,7 @@ An account is a unique identifier and a requirement to interact with a Wire bloc ## Account Name -An account name is a human-readable identifier that is stored on the blockchain. Account names must be between 1 and 12 characters in length. The characters can include a-z, 1-5, and optional dots (.) except the last character. +An account name is a human-readable identifier that is stored on the blockchain. Account names must be between 1 and 12 characters in length. The characters can include a-z, 1-5, and optional dots (.) except the last character. @@ -22,7 +22,7 @@ An account name is a human-readable identifier that is stored on the blockchain. ## Action -Functionality exposed by a smart contract that is exercised by passing the correct parameters via an approved transaction to Wire network. +Functionality exposed by a smart contract that is exercised by passing the correct parameters via an approved transaction to the Wire network. --- @@ -74,7 +74,7 @@ The list of block producers who currently have the possibility of being selected ## Block-Producing Node -A full node running `nodeop` that is actively producing blocks. A producing node, if voted out, will become a producing node on "standby". Standby operators are synced with the nextwork but they will only start producing blocks and earn rewards if they are selected to be part of the 21 Node Operators. +A full node running `nodeop` that is actively producing blocks. A producing node, if voted out, will become a producing node on "standby". Standby operators are synced with the network but they will only start producing blocks and earn rewards if they are selected to be part of the 21 Node Operators. ## Blockchain Application @@ -82,7 +82,7 @@ A blockchain application is a software application that has integrated a blockch ## Byzantine Fault Tolerance -In the context of distributed systems, Asyncronous Byzantine Fault Tolerance (aBFT) is the ability of a distributed computer network to function as desired and correctly reach a sufficient consensus despite malicious components (nodes) of the system failing or propagating incorrect information to other peers. In a Wire based blockchain aBFT is achieved using a combination of Appointed Proof of Stake, the last irreversible block, and the fact that a producer cannot sign two blocks with the same block number. +In the context of distributed systems, Asynchronous Byzantine Fault Tolerance (aBFT) is the ability of a distributed computer network to function as desired and correctly reach a sufficient consensus despite malicious components (nodes) of the system failing or propagating incorrect information to other peers. In a Wire based blockchain aBFT is achieved using a combination of Appointed Proof of Stake, the last irreversible block, and the fact that a producer cannot sign two blocks with the same block number. ## CPU @@ -94,7 +94,7 @@ The chain state (or "database" as it is often called) is a memory mapped file, w ## clio -clio is a command line tool that interfaces with the REST api exposed by nodeop, in other words clio is the command line tool through which you can interface with a Wire based blockchain; clio contains documentation for all of its commands. For a list of all commands known to clio, simply run it without no arguments +clio is a command line tool that interfaces with the REST API exposed by nodeop, in other words clio is the command line tool through which you can interface with a Wire based blockchain; clio contains documentation for all of its commands. For a list of all commands known to clio, simply run it with no arguments. ## Confirmed Transaction @@ -117,12 +117,12 @@ In addition to the native permissions, owner and active, an account can possess Deferred actions are actions sent to a peer action that are scheduled to run, at best, at a later time, at a block producer's discretion. There is no guarantee that a deferred action will be executed. From the perspective of the originating action, i.e., the action that creates the deferred action, it can only determine whether the create request was submitted successfully or whether it failed (if it fails, it will fail immediately). Deferred actions carry the authority of the contract that sends them. A deferred action can also be cancelled by another action or a transaction. :::warning -| Deferred transactions are deprecated and replaced by inline actions in wire-sysio v.5.1.0 +Deferred transactions are deprecated and replaced by inline actions in wire-sysio v.5.1.0 ::: -## Appointed Proof of Stake(APoS) +## Appointed Proof of Stake (APoS) -Wire Network's consensus algorithm that builds upon a Delegated Proof of Stake, which was originally developed by Daniel Larimer. APoS addresses DPoS consensus challenges by separating roles and responsibilities of Node Owners from Node Operators, +Wire Network's consensus algorithm that builds upon a Delegated Proof of Stake, which was originally developed by Daniel Larimer. APoS addresses DPoS consensus challenges by separating roles and responsibilities of Node Owners from Node Operators. ## Deserialization @@ -138,7 +138,7 @@ Every smart contract must provide an apply action handler. The apply action hand ## Dispatcher Hooks -In addition to actions and notification handlers, two "hooks" are available. The pre_dispatch hook will fire when the dispatcher is run and allow the smart contract to do some pre-validation and exit early if need be by returning false. If the function returns true then the dispatcher continues to dispatch the actions or notification handlers. The post_dispatch hook will only fire when the dispatcher has failed to match any notification handlers, this allows the user to do some meaningful last ditch validation. +In addition to actions and notification handlers, two "hooks" are available. The pre_dispatch hook will fire when the dispatcher is run and allows the smart contract to do some pre-validation and exit early if need be by returning false. If the function returns true then the dispatcher continues to dispatch the actions or notification handlers. The post_dispatch hook will only fire when the dispatcher has failed to match any notification handlers, this allows the user to do some meaningful last ditch validation. ## Distributed Ledger Technology @@ -168,7 +168,7 @@ The genesis node is the first node in the blockchain network. The genesis node i ## Governance -Blockchain governance is a lot like other kinds of governance, except that it's underpinned by smart contracts and transparent voting on the blockchain. Governance, the mechanism by which collective decisions are made, of a Wire based blockchain is achieved through 21 active Node Operators which are appointed by token holders. The 21 active Node Operators continuously create the blockchain via block creation, secure the blocks by validating them, and reach consensus on the state of the blockchain as a whole. Consensus is reached when 2/3+ active node operators agree on validity of a block , therefore on all transactions contained in it and their order. +Blockchain governance is a lot like other kinds of governance, except that it's underpinned by smart contracts and transparent voting on the blockchain. Governance, the mechanism by which collective decisions are made, of a Wire based blockchain is achieved through 21 active Node Operators which are appointed by token holders. The 21 active Node Operators continuously create the blockchain via block creation, secure the blocks by validating them, and reach consensus on the state of the blockchain as a whole. Consensus is reached when 2/3+ of the active node operators agree on the validity of a block, therefore on all transactions contained in it and their order. **Related** [Irreversible Block](#irreversible-block) @@ -203,11 +203,11 @@ A Merkle tree is a tree in which every leaf node is labelled with the hash of a ## Multi-Index -Wire wraps the [boost multi-index C++](https://www.boost.org/doc/libs/1_75_0/libs/multi_index/doc/index.html) library to provide in memory data persistence. A subset of the functionality provided by the boost multi- index is provided in the Wire multi-index. +Wire wraps the [boost multi-index C++](https://www.boost.org/doc/libs/1_75_0/libs/multi_index/doc/index.html) library to provide in memory data persistence. A subset of the functionality provided by the boost multi-index is provided in the Wire multi-index. ## Multi Index Table -Multi Index Tables, are a way to cache state and/or data in RAM for fast access. Multi index tables support create, read, update, and delete (CRUD) operations, something which the blockchain doesn't (it only supports create and read). Multi index tables are stored in Wire RAM and each smart contract using a multi index table reserves a partition of the RAM cache. Access to each partition is controlled using the table name, code, and scope, and can have up to 16 indexes or indices defined. +Multi Index Tables are a way to cache state and/or data in RAM for fast access. Multi index tables support create, read, update, and delete (CRUD) operations, something which the blockchain doesn't (it only supports create and read). Multi index tables are stored in Wire RAM and each smart contract using a multi index table reserves a partition of the RAM cache. Access to each partition is controlled using the table name, code, and scope, and can have up to 16 indexes or indices defined. *Synonyms* Multiple Index Tables @@ -215,13 +215,13 @@ Multi Index Tables, are a way to cache state and/or data in RAM for fast access. ## Multisig -Multisig is a short term for multiple signatures. It’s used to describe the case in which one requires more than one account's permission to execute a transaction. Wire provides the system account sysio.msig, which can be used to push onto the blockchain the multisig proposals and their corresponding account's permission required to approve the proposal. Multisig, when used properly, increases the security of an account, the security of a smart contract, and it's also the method by which producers are able to affect changes within a Wire blockchain. +Multisig is a short term for multiple signatures. It’s used to describe the case in which one requires more than one account's permission to execute a transaction. Wire provides the system account sysio.msig, which can be used to push onto the blockchain the multisig proposals and their corresponding account's permission required to approve the proposal. Multisig, when used properly, increases the security of an account, the security of a smart contract, and is also the method by which producers are able to effect changes within a Wire blockchain. *Synonyms* msig multiple signatures ## NET -NET is required to store transactions on a Wire based blockchain. The amount of NET an account has is measured in bytes, representing the amount of transaction storage an account has at its disposal when creating a new transaction. NET is recalculated after each block is produced, based on the system tokens staked for NET bandwidth by the account. The amount allocated to an account is proportional with the total system tokens staked for NET by all accounts. Do not confuse NET with RAM, although it is also storage space, NET measures the size of the transactions and not contract state. +NET is required to store transactions on a Wire based blockchain. The amount of NET an account has is measured in bytes, representing the amount of transaction storage an account has at its disposal when creating a new transaction. NET is recalculated after each block is produced, based on the system tokens staked for NET bandwidth by the account. The amount allocated to an account is proportional to the total system tokens staked for NET by all accounts. Do not confuse NET with RAM, although it is also storage space, NET measures the size of the transactions and not contract state. ## Nodeop @@ -229,7 +229,7 @@ NET is required to store transactions on a Wire based blockchain. The amount of ## Node Operator -A Node Operator is an identifiable entity composed of one or more individuals that express interest in participating in running a Wire network. By participating it is meant these entities will provide a full node, gather transactions, verify their validity, add them into blocks, and propose and confirm these blocks. A Node Operator is generally required to have experience with system administration and security as it is expected that their full-node have constant availability. +A Node Operator is an identifiable entity composed of one or more individuals that express interest in participating in running a Wire network. By participating it is meant these entities will provide a full node, gather transactions, verify their validity, add them into blocks, and propose and confirm these blocks. A Node Operator is generally required to have experience with system administration and security as it is expected that their full node has constant availability. **Synonyms** Block Producer, BP **Related** [Block Producer](#block-producer) @@ -246,7 +246,7 @@ An oracle, in the context of blockchains and smart contracts, is an agent that f ## Packed Transaction -In order to transfer transaction content between nodes faster and to save storage space when storing transaction content in and Wire based blockchain database, the transactions are 'translated' from json into a packed form which is smaller in size. To get the packed version of a transaction one can use the clio convert command. +In order to transfer transaction content between nodes faster and to save storage space when storing transaction content in a Wire-based blockchain database, the transactions are 'translated' from json into a packed form which is smaller in size. To get the packed version of a transaction one can use the clio convert command. ## Peer-to-peer @@ -270,7 +270,7 @@ The sum of permission weights necessary for a signature to be considered valid. ## Permission Weight -A permission weight is a value given to an account for authorization purposes. This is typically used in the context of a mutli-sig to give one or more accounts more control over a multi-sig than others. +A permission weight is a value given to an account for authorization purposes. This is typically used in the context of a multi-sig to give one or more accounts more control over a multi-sig than others. *Synonyms* Authorization @@ -284,7 +284,7 @@ nodeop plugins are software components that implement features that complement t ## Private Key -A private key is a secret key used to sign transactions. In Wire, a private key's authority is determined by it's mapping to a Wire account name. +A private key is a secret key used to sign transactions. In Wire, a private key's authority is determined by its mapping to a Wire account name. ## Private Network @@ -316,13 +316,13 @@ RAM is required to store account information such as keys, balances, and contrac The REX (Resource Exchange) is a CPU and Network resource rental market in which holders of the core token of a blockchain can buy and sell slices of the REX pool in the form of REX tokens. Blockchain users can then rent CPU and Network resources from the REX pool. -## ROA(Resource Owners Association) +## ROA (Resource Owners Association) A REX extension. ## TaPoS (Transaction as Proof of Stake) -TaPoS is a mechanish that requires every transaction to include part of the hash of a recent block header. This hash serves two purposes: +TaPoS is a mechanism that requires every transaction to include part of the hash of a recent block header. This hash serves two purposes: - prevents a replay of a transaction on forks that do not include the referenced block; - signals the network that a particular user and their stake are on a specific fork. @@ -337,7 +337,7 @@ The mechanism/process for exchanging data between chains. It is responsible for ## Read Mode -An Wire based blockchain allows contract developers to persist state across actions, and consequently transaction, boundaries. For example the sample sysio.token contract keeps balances for all users in the database. Each instance of nodeop keeps the database in memory, so contracts can read and write data quickly. However, at any given time there can be multiple correct ways, called modes, to query that data. +A Wire-based blockchain allows contract developers to persist state across actions, and consequently transaction boundaries. For example the sample sysio.token contract keeps balances for all users in the database. Each instance of nodeop keeps the database in memory, so contracts can read and write data quickly. However, at any given time there can be multiple correct ways, called modes, to query that data. ## Retired Action @@ -379,7 +379,7 @@ Staking is the act of locking tokens for resources on a Wire network. This inclu ## Standard Account Name -Standard account names can only contain the characters .abcdefghijklmnopqrstuvwxyz12345. a-z (lowercase), 1-5 and. (period), must start with a letter and must be 12 characters in length. +Standard account names can only contain the characters .abcdefghijklmnopqrstuvwxyz12345. a-z (lowercase), 1-5 and . (period), must start with a letter and must be 12 characters in length. ## Standby Pool @@ -407,7 +407,7 @@ A test network or testnet is an instantiation of the Wire platform that is inten A complete all-or-nothing change to the Blockchain. A combination of one or more actions. Usually the execution result of a Smart Contract. -## Transaction Reciept +## Transaction Receipt On completion of a transaction, a transaction receipt is generated. This receipt takes the form of a hash. Receiving a transaction hash does *not* mean that the transaction has been confirmed, it simply means that the node accepted it without error, which also means that there is a high probability other producers will accept it. @@ -429,7 +429,7 @@ Wallets are clients that store keys that may or may not be associated with the p ## Wallet Import Format -An encoding for a private EDSA key. Wire uses the same version, checksum, and encoding scheme as the Bitcoin WIF addresses and should be compatible with existing libraries. +An encoding for a private ECDSA key. Wire uses the same version, checksum, and encoding scheme as the Bitcoin WIF addresses and should be compatible with existing libraries. Example of a WIF Private Key: `5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU` @@ -439,5 +439,5 @@ Example of a WIF Private Key: `5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuat The Wire based blockchains execute user-generated applications and code using WebAssembly. WASM is an emerging web standard with widespread support of Google, Microsoft, Apple, and others. At the moment the most mature toolchain for building applications that compile to WASM is clang/llvm with their C/C++ compiler. For best compatibility, it is recommended that you use the Wire toolchain to generate WASM. -**Synonyms** Web-Assembly Machine +**Synonyms** WebAssembly **Abbreviation** : Wasm diff --git a/docs/introduction/network-information.md b/docs/introduction/network-information.md index f43e77a..e164f0d 100644 --- a/docs/introduction/network-information.md +++ b/docs/introduction/network-information.md @@ -19,5 +19,5 @@ description: Wire Network endpoints and connection information | Network Name | Wire Testnet | | RPC URL | [https://testnet-00.wire.foundation/](https://testnet-00.wire.foundation/) | | Hyperion | [https://testnet-hyperion.wire.foundation/](https://testnet-hyperion.wire.foundation/) | -| Hyperion Swagger UI Index | [https://testnet-hyperion.wire.foundation/v2/docs/static/index.html](https://testnet-hyperion.wire.foundation/v2/docs/static/index.html) +| Hyperion Swagger UI Index | [https://testnet-hyperion.wire.foundation/v2/docs/static/index.html](https://testnet-hyperion.wire.foundation/v2/docs/static/index.html) | | Explorer | [https://hub.wire.network/](https://hub.wire.network) | diff --git a/docs/introduction/overview.md b/docs/introduction/overview.md index 1a6067f..5a2fa0e 100644 --- a/docs/introduction/overview.md +++ b/docs/introduction/overview.md @@ -25,4 +25,4 @@ Wire Network aims to address all of the major problems holding back the blockcha By keeping assets securely locked within their native chains and transacting ownership rights within Wire Network's settlement layer, the UTL eliminates the need for traditional bridges or oracle-based interoperability systems. This approach maintains the security and consensus integrity of the original blockchains while providing rapid transaction speeds and low or zero transaction costs within the network. Users can interact with Wire Network using their existing wallets through the technology enabled by UPAP, simplifying the onboarding process and enhancing user experience. -Moreover, Wire Network's novel Appointed Proof-of-Stake consensus mechanism enhances decentralization and security by distinctly separating governance, staking, and block production roles. Wire’s hierarchical node structure ensures optimal network performance while minimizing the risk of centralization. By addressing critical issues such as scalability, security, onboarding, and interoperability, Wire Network is poised to facilitate enterprise adoption of blockchain technology and consumer mass adoption, as well as support the future growth of decentralized applications and the emerging Ai-driven economy. +Moreover, Wire Network's novel Appointed Proof-of-Stake consensus mechanism enhances decentralization and security by distinctly separating governance, staking, and block production roles. Wire’s hierarchical node structure ensures optimal network performance while minimizing the risk of centralization. By addressing critical issues such as scalability, security, onboarding, and interoperability, Wire Network is poised to facilitate enterprise adoption of blockchain technology and consumer mass adoption, as well as support the future growth of decentralized applications and the emerging AI-driven economy. diff --git a/docs/introduction/savanna-consensus.md b/docs/introduction/savanna-consensus.md index 538ad08..a69d561 100644 --- a/docs/introduction/savanna-consensus.md +++ b/docs/introduction/savanna-consensus.md @@ -61,7 +61,7 @@ Before Savanna, Antelope used a two-layer mechanism: **Delegated Proof of Stake ### 2.2. The Two-Round Confirmation Problem -In the legacy system, a block reaching true irreversibility required **two full rounds** of supermajority confirmation, not one. In the first round, each Block Producer(BP) piggybacks a `confirm_count` field in its own block header as it produces blocks, registering confirmations for recent blocks it has seen. A BP can only emit a confirmation when it is scheduled to produce — never out-of-band. Once ⌈2/3 × 21⌉ = 15 BPs have each confirmed a block, it advances to **Proposed LIB (PLIB)**. But that is only stage one. In the second round, the PLIB itself must then receive 2/3+1 confirmations before it graduates to the actual **Last Irreversible Block (LIB)**. With 21 BPs each producing 12-block slots, one full round of confirmations requires waiting for roughly 20 producers to cycle through their slots — approximately 240 blocks. Two rounds therefore compounded to a minimum gap of around 325 blocks between the chain head and LIB in good network conditions, and commonly over 360 in practice. At 0.5 seconds per block that works out to roughly 2.5–3 minutes. No amount of hardware or network improvement could break this ceiling — it was baked into the two-stage protocol structure itself. +In the legacy system, a block reaching true irreversibility required **two full rounds** of supermajority confirmation, not one. In the first round, each Block Producer (BP) piggybacks a `confirm_count` field in its own block header as it produces blocks, registering confirmations for recent blocks it has seen. A BP can only emit a confirmation when it is scheduled to produce — never out-of-band. Once ⌈2/3 × 21⌉ = 15 BPs have each confirmed a block, it advances to **Proposed LIB (PLIB)**. But that is only stage one. In the second round, the PLIB itself must then receive 2/3+1 confirmations before it graduates to the actual **Last Irreversible Block (LIB)**. With 21 BPs each producing 12-block slots, one full round of confirmations requires waiting for roughly 20 producers to cycle through their slots — approximately 240 blocks. Two rounds therefore compounded to a minimum gap of around 325 blocks between the chain head and LIB in good network conditions, and commonly over 360 in practice. At 0.5 seconds per block that works out to roughly 2.5–3 minutes. No amount of hardware or network improvement could break this ceiling — it was baked into the two-stage protocol structure itself. > The Bottleneck > diff --git a/docs/introduction/wns-overview.md b/docs/introduction/wns-overview.md index b2e5d47..a1bf66b 100644 --- a/docs/introduction/wns-overview.md +++ b/docs/introduction/wns-overview.md @@ -21,13 +21,13 @@ While these solutions offer different approaches, they often share common drawba Moreover, the heterogeneous nature of blockchain technology presents ongoing compatibility issues with both new and existing networks. Many interoperability solutions are inherently limited by the number of chains they can support, restricting their effectiveness in a rapidly evolving ecosystem. -At its core, Wire Network is designed to overcome these challenges. Wire Name Service (WNS), when combined with the Wire layer-1 settlement layer and the Universal Polymorphic Address Protocol, collectively forms to create a *Universal Transaction Layer* (UTL). +At its core, Wire Network is designed to overcome these challenges. Wire Name Service (WNS), when combined with the Wire layer-1 settlement layer and the Universal Polymorphic Address Protocol, collectively form a *Universal Transaction Layer* (UTL). This article explores the architecture and processes of Wire Network and WNS, detailing how it addresses the inherent challenges of blockchain interoperability and sets a new standard for seamless cross-chain transactions. ## Design -The UTL's design is a hub-and-spoke model (see diagram below). This design enables transactions between different blockchain networks through a universal hub, providing a seamless, secure and cost-efficient way for environment for assets to interact & move between chains. +The UTL's design is a hub-and-spoke model (see diagram below). This design enables transactions between different blockchain networks through a universal hub, providing a seamless, secure, and cost-efficient environment for assets to interact and move between chains. ![wns-design](../../static/img/wns-design.png) @@ -41,7 +41,7 @@ WNS is comprised of native settlement and target chain ('escrow' or 'bucket') co ## Security Principles -The security framework of WNS is robust, relying on multiple checks and balances to prevent malicious activities. Key features are the use of standard cryptographic proofs to verify transactions, implementation of UTXO model to track transaction outputs; as well utilizing a completely independent sub-chain to aid with the transaction verification process. This sub-chain, also knowns as S-chain (stands for *settlement*) includes only the relevant transactions and data needed for the target chain, allowing for fast and efficient processing. +The security framework of WNS is robust, relying on multiple checks and balances to prevent malicious activities. Key features are the use of standard cryptographic proofs to verify transactions, implementation of the UTXO model to track transaction outputs, as well as utilizing a completely independent sub-chain to aid with the transaction verification process. This sub-chain, also known as S-chain (stands for *settlement*), includes only the relevant transactions and data needed for the target chain, allowing for fast and efficient processing. ### UTXO @@ -49,7 +49,7 @@ The UTXO (Unspent Transaction Output) model views each token amount as a distinc **Example:** -Bob wants to send 15 USDC to Alice. To complete the transaction, Bob’s wallet selects UTXOs that equal or exceed the required amount. UTXO #1 (12 USDC) and UTXO #2 (5 USDC) are selected, which together are total of 17 USDC. +Bob wants to send 15 USDC to Alice. To complete the transaction, Bob’s wallet selects UTXOs that equal or exceed the required amount. UTXO #1 (12 USDC) and UTXO #2 (5 USDC) are selected, which together total 17 USDC. ![utxo-example](../../static/img/utxo-example.png) diff --git a/docs/introduction/wns-trx-flow.md b/docs/introduction/wns-trx-flow.md index 685be21..2c52e5c 100644 --- a/docs/introduction/wns-trx-flow.md +++ b/docs/introduction/wns-trx-flow.md @@ -14,8 +14,8 @@ description: Understanding the transaction flow for deposits, swaps, and withdra # WNS Transaction Flow Below is an example of a diagram that visualizes deposit, swap and withdrawal for two hypothetical users - Bob and Alice. -Bob possesses $100 of ETH on Ethereum and Alice has $100 of SOL on Solana, both stored in their respective UPAP-enabled wallets. Upon successful deposits, Bob and Alice have respectively their wrapped tokens WETH and WSOL. +Bob possesses $100 of ETH on Ethereum and Alice has $100 of SOL on Solana, both stored in their respective UPAP-enabled wallets. Upon successful deposits, Bob and Alice respectively have their wrapped tokens WETH and WSOL. If they wish to swap these assets, the WNS system can perform an atomic swap on the Wire blockchain via the swap contract. Either party can initiate this transaction using their UPAP-enabled wallet. For instance, Bob proposes a transaction to exchange his $100 in ETH for Alice's $100 in SOL. Alice then finalizes the transaction in her UPAP-enabled wallet, resulting in the updated ownership being confirmed and reflected in the WNS system. -Bob and Alice then decide to withdraw their assets - Bob would now have $100 of SOL in his Solana wallet, and Alice - $100 of ETH in her ETH. +Bob and Alice then decide to withdraw their assets — Bob would now have $100 of SOL in his Solana wallet, and Alice would have $100 of ETH in her Ethereum wallet. ![wns-trx-flow](../../static/img/wns-2.png) diff --git a/docs/smart-contract-development/accounts-permissions.md b/docs/smart-contract-development/accounts-permissions.md index 8e31c94..def4c50 100644 --- a/docs/smart-contract-development/accounts-permissions.md +++ b/docs/smart-contract-development/accounts-permissions.md @@ -67,7 +67,7 @@ Name | Type | Description `accounts` | array of `permission_level_weight` | list of `account@permission` levels and weights `waits` | array of `wait_weight` | list of time waits and weights -The `key_weight` type contains the actor's public key and associated weight. The `permission_level_weight` type consists of the actor's `account@permission` level and associated weight. The `wait_weight` contains the time wait and associated weight (used to satisfy action authorizations in delayed user transactions. All of these types allow to define lists of authority factors that are used for satisfaction of action authorizations. +The `key_weight` type contains the actor's public key and associated weight. The `permission_level_weight` type consists of the actor's `account@permission` level and associated weight. The `wait_weight` contains the time wait and associated weight (used to satisfy action authorizations in delayed user transactions). All of these types allow you to define lists of authority factors that are used for satisfaction of action authorizations. #### Authority Factors @@ -89,6 +89,6 @@ The authority table for `jack`'s `release-code` named permission is shown in the Since both `katey@active` and `kyle@active` factors have a weight of 2, *either one can satisfy the action authorization*. This means that either `katey` or `kyle` with a permission level of `active` or higher can independently execute any action under `jack`'s `release-code` permission. -Alternatively, it would require two acounts each with weight of 1 to satisfy the action authorization - in this case account with public key `SYS7Hnv4iBfcw2...` and `nick@active`. +Alternatively, it would require two accounts each with a weight of 1 to satisfy the action authorization - in this case account with public key `SYS7Hnv4iBfcw2...` and `nick@active`. ![account-weights-example](../../static/img/weights-example.png) diff --git a/docs/smart-contract-development/company-contract.md b/docs/smart-contract-development/company-contract.md index 5cf3f35..1a09c88 100644 --- a/docs/smart-contract-development/company-contract.md +++ b/docs/smart-contract-development/company-contract.md @@ -15,7 +15,7 @@ description: Step-by-step guide to creating a company contract using Wire CDT ## Overview -This page will guide you to creating and developing a simple contract using Wire CDT and C++ language. While prior knowledge of C++ is not necessary for this tutorial, we encourage you to familiarize yourself with the basics of C++ to enhance your understanding. +This page will guide you through creating and developing a simple contract using Wire CDT and C++ language. While prior knowledge of C++ is not necessary for this tutorial, we encourage you to familiarize yourself with the basics of C++ to enhance your understanding. ## Prerequisites @@ -40,7 +40,7 @@ Open `company-contract` in your preferred text editor to begin coding. ### 2\. Write the Contract Code -In C++, splitting class declarations and definitions into separate header (.hpp) and source (.cpp) files is a common practice that promotes better code organization, readability, and compile time-efficiency. This approach helps segregating interface from implementation; as well hiding the implementation details from other parts of the program and exposing only what is necessary. For the purposes of this and future tutorials, we will stick to that approach. +In C++, splitting class declarations and definitions into separate header (.hpp) and source (.cpp) files is a common practice that promotes better code organization, readability, and compile time-efficiency. This approach helps segregate interface from implementation, as well as hiding the implementation details from other parts of the program and exposing only what is necessary. For the purposes of this and future tutorials, we will stick to that approach. 2.1. Define contract interfaces in `company.hpp` @@ -236,7 +236,7 @@ Before deploying, ensure you have an open wallet and account to deploy the contr :::note -In Wire ecosystem, deploying a smart contract requires an account; an account can own one smart contract instance and a smart contract instance must be deployed to an account. Each account functions as a distinct namespace for the contract, which means that the contract’s code and its state are encapsulated within that account. +In the Wire ecosystem, deploying a smart contract requires an account; an account can own one smart contract instance and a smart contract instance must be deployed to an account. Each account functions as a distinct namespace for the contract, which means that the contract’s code and its state are encapsulated within that account. ::: diff --git a/docs/smart-contract-development/hello-world-contract-short.md b/docs/smart-contract-development/hello-world-contract-short.md index 995025c..4677cc4 100644 --- a/docs/smart-contract-development/hello-world-contract-short.md +++ b/docs/smart-contract-development/hello-world-contract-short.md @@ -31,11 +31,11 @@ Start by cloning the existing GitHub repository containing the Hello World contr git clone https://github.com/Wire-Network/guides.git && cd guides/hello-world-contract ``` -Then open the code into your favorite code editor and inspect the files. +Then open the code in your favorite code editor and inspect the files. ### 2. Compile the Contract -Compile it using the `./build.sh`. This script uses the Wire Contract Development Toolkit (CDT) the Hello World contract into WebAssembly (WASM) format. The script will create a compilation folder `hello/` with the WASM and ABI files. +Compile it using the `./build.sh`. This script uses the Wire Contract Development Toolkit (CDT) to compile the Hello World contract into WebAssembly (WASM) format. The script will create a compilation folder `hello/` with the WASM and ABI files. ```bash ./build.sh @@ -46,16 +46,16 @@ Upon successful compilation, you will see a `hello` folder with `hello.abi` and ```sh title="hello-world-contract/" -| .... + .... ├── hello │ ├── hello.abi │ └── hello.wasm -| ... + ... ``` ### 3. Deploy the Contract -Before deploying, ensure you have an account to deploy the contract to. Create an account if necessary and replace `PUBLIC_KEY` with the development key used in Manage Local Wallet with clio guide (see [Import Keys](../getting-started/manage-local-wallet-with-clio.md#import-the-development-key); key pair is also listed [here](../getting-started/manage-local-wallet-with-clio.md#development-key)). Your wallet must be also unlocked before using it (see [Unlock a wallet](../getting-started/manage-local-wallet-with-clio.md#unlock-a-wallet)). +Before deploying, ensure you have an account to deploy the contract to. Create an account if necessary and replace `PUBLIC_KEY` with the development key used in Manage Local Wallet with clio guide (see [Import Keys](../getting-started/manage-local-wallet-with-clio.md#import-the-development-key); key pair is also listed [here](../getting-started/manage-local-wallet-with-clio.md#development-key)). Your wallet must also be unlocked before using it (see [Unlock a wallet](../getting-started/manage-local-wallet-with-clio.md#unlock-a-wallet)). #### 3.1. Create an account using `clio` diff --git a/docs/smart-contract-development/interacting-with-contracts/smart-contracts-clio.md b/docs/smart-contract-development/interacting-with-contracts/smart-contracts-clio.md index b50459a..261c5e2 100644 --- a/docs/smart-contract-development/interacting-with-contracts/smart-contracts-clio.md +++ b/docs/smart-contract-development/interacting-with-contracts/smart-contracts-clio.md @@ -57,7 +57,7 @@ executed transaction: 6761530f000a2a98bdb002f41c1905e5e3e234031ee54077bcfb47c57b >> Employee added: jack ``` -You could use block explorer to inspect the table and the transactions. +You could use a block explorer to inspect the table and the transactions. ![be-table-check](/img/be-table-check.png) diff --git a/docs/smart-contract-development/smart-contract-basics.md b/docs/smart-contract-development/smart-contract-basics.md index 7ffbdb3..ecb6926 100644 --- a/docs/smart-contract-development/smart-contract-basics.md +++ b/docs/smart-contract-development/smart-contract-basics.md @@ -59,7 +59,7 @@ CONTRACT contractname : public contract { } ``` -The code snippet above are essentially equivalent to: +The code snippet above is essentially equivalent to: ```cpp title="project/include/contractname.hpp" #pragma once @@ -87,7 +87,7 @@ void contractname::dosomething() { ### Header vs. Source Files -In C++, code is typically split into header files (`.hpp` or `.h`) and source files (`.cpp`), especially when projects get large. This helps with code organization and readibility. +In C++, code is typically split into header files (`.hpp` or `.h`) and source files (`.cpp`), especially when projects get large. This helps with code organization and readability. - **Header files** are used to declare functions, classes, structs, and other types. - **Source files** are used for the implementation of functions declared in header files. diff --git a/docs/smart-contract-development/state-data.md b/docs/smart-contract-development/state-data.md index 4a7eb27..5a160d4 100644 --- a/docs/smart-contract-development/state-data.md +++ b/docs/smart-contract-development/state-data.md @@ -42,7 +42,7 @@ Defining a model in Wire smart contracts is similar to defining a C++ struct, bu #### Secondary Key -A secondary index is more flexible than a primary key and it's primaraly used when you intend to associate multiple rows with the same key. It can be any of the following data types: +A secondary index is more flexible than a primary key and it's primarily used when you intend to associate multiple rows with the same key. It can be any of the following data types: - `uint64_t` - `uint128_t` @@ -151,7 +151,7 @@ auto iterator = users.find(1); :::warning[Always Check If the Row Exists] -When you retrieve data from a table using the `find(`) method, you must check whether the row actually exists. If the row is not found, the iterator returned will be equal to `users.end()`, which is a special iterator representing the end of the table. +When you retrieve data from a table using the `find()` method, you must check whether the row actually exists. If the row is not found, the iterator returned will be equal to `users.end()`, which is a special iterator representing the end of the table. ```cpp if (iterator != users.end()) { @@ -358,7 +358,7 @@ configs.set(ConfigModel{ ### Removing data -Once you've instantiated a `singleton`, it's easy to remove it. Just called the `remove` method on the instance itself. +Once you've instantiated a `singleton`, it's easy to remove it. Just call the `remove` method on the instance itself. ```cpp configs.remove(); diff --git a/docs/smart-contract-development/types.md b/docs/smart-contract-development/types.md index c34f0ca..9301e45 100644 --- a/docs/smart-contract-development/types.md +++ b/docs/smart-contract-development/types.md @@ -143,7 +143,7 @@ function recover(checksum256 hash, signature sig) { The `asset` type is used to represent a quantity of a digital asset. It is a 64-bit integer with a symbol, but it's displayed as a string. -It is resistent to overflow and underflow, and has various methods for performing arithmetic operations easily. +It is resistant to overflow and underflow, and has various methods for performing arithmetic operations easily. | Asset Types | Description | | --- | --- | diff --git a/docs/wire-hub/connect-a-wallet.md b/docs/wire-hub/connect-a-wallet.md index 7bc3f86..bba492f 100644 --- a/docs/wire-hub/connect-a-wallet.md +++ b/docs/wire-hub/connect-a-wallet.md @@ -14,7 +14,7 @@ import BrowserWindow from '@site/src/components/BrowserWindow'; Begin by navigating to the [Wire Hub](https://hub.wire.network) website. - =hub page + hub page @@ -28,7 +28,7 @@ Begin by navigating to the [Wire Hub](https://hub.wire.network) website. ### Step 3: Select Your Wallet Provider - hub-connect-metamast-wallet + hub-connect-metamask-wallet diff --git a/docs/wire-hub/connect-to-a-rpc.md b/docs/wire-hub/connect-to-a-rpc.md index dd4d639..5554ad8 100644 --- a/docs/wire-hub/connect-to-a-rpc.md +++ b/docs/wire-hub/connect-to-a-rpc.md @@ -1,12 +1,12 @@ -# Wire Hub:Connect to a Local Network +# Wire Hub: Connect to a Local Network ## Overview -**Wire Hub** is a unified management and monitoring platform, created by Wire Network team, that serves as both a block explorer and a dashboard for Wire Network aministrative's tasks. +**Wire Hub** is a unified management and monitoring platform, created by the Wire Network team, that serves as both a block explorer and a dashboard for Wire Network administrative tasks. A block explorer is an online application that enables individuals to interact with and examine information stored on the blockchain. Such tools provide a straightforward interface for users to view transaction histories, account balances, and additional relevant data on a blockchain. Block explorers catalog and display all transactions on a specific network. -This tool is an invaluable for monitoring a network's transactions and observing the real-time effects of your smart contracts' interactions with the blockchain. +This tool is invaluable for monitoring a network's transactions and observing the real-time effects of your smart contracts' interactions with the blockchain. ## Steps @@ -17,7 +17,7 @@ Begin by navigating to the [Wire Hub](https://hub.wire.network) website. import BrowserWindow from '@site/src/components/BrowserWindow'; - =hub page + hub page diff --git a/docs/wire-hub/create-wire-testnet-account.md b/docs/wire-hub/create-wire-testnet-account.md index 9af4d09..b1a5c20 100644 --- a/docs/wire-hub/create-wire-testnet-account.md +++ b/docs/wire-hub/create-wire-testnet-account.md @@ -1,4 +1,4 @@ -# Wire Hub(Testnet Only):Create an Account +# Wire Hub (Testnet Only): Create an Account ## Prerequisites @@ -14,7 +14,7 @@ import BrowserWindow from '@site/src/components/BrowserWindow'; Begin by navigating to the [Wire Hub](https://hub.wire.network) website. - =hub page + hub page @@ -29,7 +29,7 @@ You will see your account dashboard: ### Step 3: Create an Account -Click *Create Account* button to go ahead with registering a new account tied to your wallet. +Click the *Create Account* button to go ahead with registering a new account tied to your wallet. hub-create-account diff --git a/docs/wire-hub/inspect-transaction.md b/docs/wire-hub/inspect-transaction.md index 889ea6f..596bc78 100644 --- a/docs/wire-hub/inspect-transaction.md +++ b/docs/wire-hub/inspect-transaction.md @@ -9,15 +9,15 @@ Begin by navigating to the [Wire Hub](https://hub.wire.network) website. import BrowserWindow from '@site/src/components/BrowserWindow'; - =hub page + hub page -Ensure you are connected to any network +Ensure you are connected to a network. ### Step 2: Get a Transaction ID -Copy any transaction ID from *All Transactions* list. +Copy any transaction ID from the *All Transactions* list. hub-trx-1 @@ -33,4 +33,4 @@ Paste the transaction ID in the search box and the results will load the transac -[link](https://hub.wire.network/explore/transactions/b91e21c08ab2fcc8b7e7c850ff8dc69419ceab45f4be4bb4f51160982428dc45>) +[link](https://hub.wire.network/explore/transactions/b91e21c08ab2fcc8b7e7c850ff8dc69419ceab45f4be4bb4f51160982428dc45) diff --git a/docs/wire-hub/request-a-policy.md b/docs/wire-hub/request-a-policy.md index 519b6fc..f496907 100644 --- a/docs/wire-hub/request-a-policy.md +++ b/docs/wire-hub/request-a-policy.md @@ -1,8 +1,8 @@ -# Wire Hub(Testnet Only): Request a Developer Contract Policy +# Wire Hub (Testnet Only): Request a Developer Contract Policy ## Overview -On the Wire Testnet, to develop decentralized applications (dApps), you’ll need resources for your smart contracts. These resources are collectively managed by Node Owners via the [`sysio.roa`](/docs/api-reference/system-contracts/contracts/sysio.roa.md) contract. Therefore, *you must request a baseline Developer Contract Policy* for a new contract account. This initial policy, issued by a test Node Owner, it is a necessary step and it provides essential resources to start your smart contract development. +On the Wire Testnet, to develop decentralized applications (dApps), you’ll need resources for your smart contracts. These resources are collectively managed by Node Owners via the [`sysio.roa`](/docs/api-reference/system-contracts/contracts/sysio.roa.md) contract. Therefore, *you must request a baseline Developer Contract Policy* for a new contract account. This initial policy, issued by a test Node Owner, is a necessary step and provides essential resources to start your smart contract development. ## Prerequisites @@ -23,7 +23,7 @@ Begin by navigating to the [Node Owner Dashboard](https://hub.wire.network/explo ### Step 2: Copy Account Contract's Username and Keys -Copy the account contract's username and keys to a safe place, check *I have saved the username and key pair to a safe place* and click **Request New Contract Policy**. +Copy the contract account's username and keys to a safe place, check *I have saved the username and key pair to a safe place* and click **Request New Contract Policy**. hub-policy-copy-details