Merge pull request #2092 from dfinity/style-guide-apply

Applying style guide guidelines

blog/news-and-updates/team-spotlight-node.mdx

@@ -39,9 +39,9 @@ Hello everyone! It's time for another issue of team spotlight. For this edition,
 
 *The node team maintains the replicaOSes (SetupOS, HostOS, GuestOS). These OSes run on replica nodes. The Boundary Node team maintains the BoundaryOSes (Boundary-GuestOS, Boundary-Api-GuestOS). These OSes run on boundary nodes.*
 
-**Node providers are an extremely important component of the IC. How does the Node team support Node Providers?**
+**Node providers are an extremely important component of the IC. How does the Node team support node providers?**
 
-*The node team supports Node Providers during the onboarding procedure (the IC-OS installation), but one of our team priorities is to make the Node Provider onboarding procedure as simple and decentralized as possible so that the Node Team and DFINITY are not a necessary part of the onboarding process.*
+*The node team supports node providers during the onboarding procedure (the IC-OS installation), but one of our team priorities is to make the Node Provider onboarding procedure as simple and decentralized as possible so that the Node Team and DFINITY are not a necessary part of the onboarding process.*
 
 **With so many responsibilities, and such an important team initiative, I can imagine that there are several challenges that the team faces. What would you say is the biggest challenge the team has faced so far?**
 
@@ -67,9 +67,9 @@ Hello everyone! It's time for another issue of team spotlight. For this edition,
 
 **Have there been any improvements made as a direct result of node provider feedback?**
 
-*Absolutely. The Node team is constantly receiving feedback from Node Providers about the onboarding procedure, and we use this feedback to improve our processes and documentation. All Node Providers are encouraged to join the Node Provider matrix channel to share any feedback or suggestions with DFINITY and the community: https://wiki.internetcomputer.org/wiki/Node_Provider_Matrix_channel*
+*Absolutely. The Node team is constantly receiving feedback from node providers about the onboarding procedure, and we use this feedback to improve our processes and documentation. All node providers are encouraged to join the Node Provider matrix channel to share any feedback or suggestions with DFINITY and the community: https://wiki.internetcomputer.org/wiki/Node_Provider_Matrix_channel*
 
-**That's incredible to hear that Node Providers frequently help provide meaningful feedback.**
+**That's incredible to hear that node providers frequently help provide meaningful feedback.**
 
 **Switching focus, what is the primary project that the Node team is working on or focused on currently?**
 

docs/developer-docs/backend/motoko/simple-cycles.md

@@ -126,7 +126,7 @@ Register, build, and deploy your dapp by running the following command in your p
 dfx deploy --argument '(360000000000)' cycles_hello_backend
 ```
 
-This example sets the `capacity` for the canister to 360,000,000,000 cycles. The `dfx deploy` command output then displays information about the operations it performs, including the identity associated with the wallet canister created for this local project and the wallet canister identifier.
+This example sets the `capacity` for the canister to 360_000_000_000 cycles. The `dfx deploy` command output then displays information about the operations it performs, including the identity associated with the wallet canister created for this local project and the wallet canister identifier.
 
 For example:
 

docs/developer-docs/backend/resource-limits.md

@@ -28,11 +28,11 @@ This section defines the current main constraints regarding resource usage on th
 
 The IC may reject WebAssembly modules for reasons such that:
 
-- They declare more than 50,000 functions.
-- They declare more than 1,000 globals.
+- They declare more than 50_000 functions.
+- They declare more than 1_000 globals.
 - They declare more than 16 exported custom sections (the custom section names with prefix icp:).
-- The number of all exported functions called `canister_update <name>` or `canister_query <name>` exceeds 1,000.
-- The sum of `<name>` lengths in all exported functions called `canister_update <name>` or `canister_query <name>` exceeds 20,000.
+- The number of all exported functions called `canister_update <name>` or `canister_query <name>` exceeds 1_000.
+- The sum of `<name>` lengths in all exported functions called `canister_update <name>` or `canister_query <name>` exceeds 20_000.
 - The total size of the exported custom sections exceeds 1MiB.
 
 More information regarding these restrictions can be found in the [Internet Computer interface specification](https://internetcomputer.org/docs/current/references/ic-interface-spec/#system-api-module).

docs/developer-docs/gas-cost.md

@@ -36,7 +36,7 @@ A thorough example how the cost of running a canister on a 13-node app subnet is
 | GB Storage Per Second                | For storing a GB of data per second                                                                              | Canister with storage | 127K / 13                             | 127K                                  | 127K / 13 * 34                     |
  |                                      |                                                                                                                  |                                       |                                       |                                    |
  | _HTTPS outcalls_                     |                                                                                                                  |                                       |                                       |                                    |
- | HTTPS outcall (per call)                | For sending an HTTPS outcall to a server outside the IC, per message (`http_request`)                            | Sending canister | 3,060,000                             | 49,140,000                                  | 171,360,000                                        | 27,200                     |
+ | HTTPS outcall (per call)                | For sending an HTTPS outcall to a server outside the IC, per message (`http_request`)                            | Sending canister | 3_060_000                             | 49_140_000                                  | 171_360_000                                        | 27,200                     |
 | HTTPS outcall request message size (per byte)|	For sending an HTTPS outcall to a server outside the IC, per request byte (http_request) | Sending canister |	400	| 5,200	| 13,600 |
 | HTTPS outcall response message size (per byte) |	For sending an HTTPS outcall to a server outside the IC, per reserved response byte (http_request)|	Sending canister | 800	| 10,400	| 27,200 |
 
@@ -48,7 +48,7 @@ Pricing for the **Chain-Key Signing API** is available in the [Chain-Key Signing
 * System API calls are just like normal function calls from the WebAssembly stand point. The number of instructions each call takes depends on the work done.
 :::
 
-The pricing for HTTPS outcalls is calculated in a slightly different way as the prices for other resources: The feature has a quadratic component in its implementation, which is reflected through the formula `(3,000,000 + 60,000 * n) * n` for the base fee and `400 * n` each request byte and `800 * n` for each response byte. Those formulas have been used in the table to obtain the concrete values for subnets of sizes 13 and 34.
+The pricing for HTTPS outcalls is calculated in a slightly different way as the prices for other resources: The feature has a quadratic component in its implementation, which is reflected through the formula `(3_000_000 + 60_000 * n) * n` for the base fee and `400 * n` each request byte and `800 * n` for each response byte. Those formulas have been used in the table to obtain the concrete values for subnets of sizes 13 and 34.
 
 The USD cost for transactions below is based on the above cycle costs. 1 XDR is equal to 1 Trillion cycles. As of November 23, 2022, the exchange rate for 1 XDR = $1.308860, which is used on this page. The exchange rate for USD/XDR may vary and it will impact the conversion rate. You can view XDR exchange rates [here](https://www.imf.org/external/np/fin/data/rms_sdrv.aspx).
 

docs/developer-docs/integrations/bitcoin/bitcoin-how-it-works.md

@@ -94,21 +94,21 @@ The cost per API call in USD uses the USD/XDR exchange rate of November 23, 2022
 
 | Transaction                          | Description                                                                                                    | Price (Cycles) | Price (USD) | Minimum cycles to send with call |
 |--------------------------------------|----------------------------------------------------------------------------------------------------------------|-----------------------------|-----------------------------|------------------|
-| Bitcoin UTXO set for an address      | For retrieving the UTXO set for a Bitcoin address (`bitcoin_get_utxos`)                                        | 20,000,000 + 0.4 cycles per Wasm instruction | $0.00002617720 + Wasm instruction cost | 4,000,000,000 |
-| Bitcoin fee percentiles              | For obtaining the fee percentiles of the most recent transactions (`bitcoin_get_current_fee_percentiles`)       | 4,000,000                 | $0.00000523544                    | 40,000,000 |
-| Bitcoin balance for an address       | For retrieving the balance of a given Bitcoin address (`bitcoin_get_balance`)                                  | 4,000,000                 | $0.00000523544                    | 40,000,000 |
-| Bitcoin transaction submission       | For submitting a Bitcoin transaction to the Bitcoin network, per transaction (`bitcoin_send_transaction`)      | 2,000,000,000             | $0.00261772000                    | n.a.       |
-| Bitcoin transaction payload          | For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (`bitcoin_send_transaction`)  | 8,000,000                 | $0.00001047088                    | n.a.       |
+| Bitcoin UTXO set for an address      | For retrieving the UTXO set for a Bitcoin address (`bitcoin_get_utxos`)                                        | 20_000_000 + 0.4 cycles per Wasm instruction | $0.00002617720 + Wasm instruction cost | 4_000_000_000 |
+| Bitcoin fee percentiles              | For obtaining the fee percentiles of the most recent transactions (`bitcoin_get_current_fee_percentiles`)       | 4_000_000                 | $0.00000523544                    | 40_000_000 |
+| Bitcoin balance for an address       | For retrieving the balance of a given Bitcoin address (`bitcoin_get_balance`)                                  | 4_000_000                 | $0.00000523544                    | 40_000_000 |
+| Bitcoin transaction submission       | For submitting a Bitcoin transaction to the Bitcoin network, per transaction (`bitcoin_send_transaction`)      | 2_000_000_000             | $0.00261772000                    | n.a.       |
+| Bitcoin transaction payload          | For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (`bitcoin_send_transaction`)  | 8_000_000                 | $0.00001047088                    | n.a.       |
 
 ### Bitcoin Mainnet
 
 | Transaction                          | Description                                                                                                    | Price (Cycles) | Price (USD) | Minimum cycles to send with call |
 |--------------------------------------|----------------------------------------------------------------------------------------------------------------|-----------------------------|-----------------------------|------------------|
-| Bitcoin UTXO set for an address      | For retrieving the UTXO set for a Bitcoin address (`bitcoin_get_utxos`)                                        | 50,000,000 + 1 cycle per Wasm instruction | $0.00006544300 + Wasm instruction cost | 10,000,000,000 |
-| Bitcoin fee percentiles              | For obtaining the fee percentiles of the most recent transactions (`bitcoin_get_current_fee_percentiles`)       | 10,000,000                 | $0.00001308860 | 100,000,000 |
-| Bitcoin balance for an address       | For retrieving the balance of a given Bitcoin address (`bitcoin_get_balance`)                                  | 10,000,000                 | $0.00001308860                    | 100,000,000 |
-| Bitcoin transaction submission       | For submitting a Bitcoin transaction to the Bitcoin network, per transaction (`bitcoin_send_transaction`)      | 5,000,000,000             | $0.00654430000                    | n.a.       |
-| Bitcoin transaction payload          | For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (`bitcoin_send_transaction`)  | 20,000,000                 | $0.00002617720                    | n.a.       |
+| Bitcoin UTXO set for an address      | For retrieving the UTXO set for a Bitcoin address (`bitcoin_get_utxos`)                                        | 50_000_000 + 1 cycle per Wasm instruction | $0.00006544300 + Wasm instruction cost | 10_000_000_000 |
+| Bitcoin fee percentiles              | For obtaining the fee percentiles of the most recent transactions (`bitcoin_get_current_fee_percentiles`)       | 10_000_000                 | $0.00001308860 | 100_000_000 |
+| Bitcoin balance for an address       | For retrieving the balance of a given Bitcoin address (`bitcoin_get_balance`)                                  | 10_000_000                 | $0.00001308860                    | 100_000_000 |
+| Bitcoin transaction submission       | For submitting a Bitcoin transaction to the Bitcoin network, per transaction (`bitcoin_send_transaction`)      | 5_000_000_000             | $0.00654430000                    | n.a.       |
+| Bitcoin transaction payload          | For submitting a Bitcoin transaction to the Bitcoin network, per byte of payload (`bitcoin_send_transaction`)  | 20_000_000                 | $0.00002617720                    | n.a.       |
 
 :::note
 Note that the `bitcoin_get_utxos` call is charged through a baseline fee that amortizes part of the Bitcoin block processing and the cycles cost of the actually-used Wasm instructions. This is the fairest way of charging because a flat fee would be less fair for requests returning a small number of UTXOs, while a fee scaling with the number of UTXOs is hard to define in a clean way. A few informal test measurement have yielded Wasm execution fees anywhere in the range from less than 200K to more than 1,000K cycles per returned UTXO and in addition 30M-50M cycles for processing of the unstable blocks. This wide variance per UTXO was the reason to not use a charging approach based on the number of UTXOs returned, but it should give you a rough indication of what to expect to pay in terms of fees. For queries with a small number of UTXOs, you can expect around 100M cycles as fee to be deducted from the provided cycles on the call for a majority of calls.

docs/developer-docs/integrations/bitcoin/ckbtc.md

@@ -33,7 +33,7 @@ The ckBTC ledger adheres to the ICRC-1 token standard. Technical details can be
 ## ckBTC minter
 The ckBTC minter is a canister that is controlled by the NNS and running on the [pzp6e](https://dashboard.internetcomputer.org/subnet/pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae) subnet. In the configuration of the ckBTC minter canister, the following configurations are set:
 
-- `retrieve_btc_min_amount`: This is the minimum ckBTC amount that can be burned and, correspondingly, the minimum BTC amount that can be withdrawn. The parameter is set to 0.001 BTC, or 100,000 Satoshi.
+- `retrieve_btc_min_amount`: This is the minimum ckBTC amount that can be burned and, correspondingly, the minimum BTC amount that can be withdrawn. The parameter is set to 0.001 BTC, or 100_000 Satoshi.
 - `max_time_in_queue_nanos`: Any BTC retrieval request should be kept in a queue for at most this time. Caching requests rather than handling them right away has the advantage that multiple requests can be served in a single transaction, saving Bitcoin miner fees. The parameter is set to 10 minutes, which corresponds to the expected time between Bitcoin blocks.
 - `min_confirmations`: The number of confirmations required for the ckBTC minter to accept a Bitcoin transaction. In particular, the ckBTC minter does not mint ckBTC before a transaction transferring BTC to a Bitcoin address managed by the ckBTC minter reaches this number of transactions. The parameter was initially set to 72 but has been reduced to 12 in the meantime.
 - `kyt_fee`: The fee that must be paid for KYT checks. It is currently set to 2000 satoshi.

docs/developer-docs/integrations/bitcoin/local-development.md

@@ -190,7 +190,7 @@ Or, via the command line:
 
     dfx canister call basic_bitcoin get_balance '("<your-canister-btc-address>")'
 
-If everything worked well, you should see a balance of 5,000,000,000 Satoshi, which is 50 BTC.
+If everything worked well, you should see a balance of 5_000_000_000 Satoshi, which is 50 BTC.
 This is the reward you received for mining one block.
 
 :::info

docs/developer-docs/integrations/https-outcalls/https-outcalls-how-to-use.md

@@ -28,7 +28,7 @@ The following parameters should be supplied for in the request:
 
 -   `url`: the requested URL. The URL must be valid according to https://www.ietf.org/rfc/rfc3986.txt[RFC-3986] and its length must not exceed `8192`. The URL may specify a custom port number.
 
--   `max_response_bytes`: optional; specifies the maximal size of the response in bytes. If provided, the value must not exceed `2MB` (`2,000,000B`). The call will be charged based on this parameter. If not provided, the maximum of `2MB` will be used.
+-   `max_response_bytes`: optional; specifies the maximal size of the response in bytes. If provided, the value must not exceed `2MB` (`2_000_000B`). The call will be charged based on this parameter. If not provided, the maximum of `2MB` will be used.
 
 -   `method`: currently, only `GET`, `HEAD`, and `POST` are supported.
 

docs/developer-docs/integrations/https-outcalls/index.md

@@ -15,15 +15,15 @@ Canister HTTP requests allow for a plethora of use cases and have numerous advan
 * **Closer to the standard programming paradigm**: the paradigm of a smart contract directly making HTTP requests to external servers is much closer to the "normal" programming paradigm engineers are used to when compared to using oracles. Thus, the fact that one programs for a blockchain can be further abstracted away.
 
 #### Why is interfacing with the external world so important for a blockchain?
-* Most real-world dApp use cases need some form of data exchange with off-chain entities.
-* Most of the world's data is currently held in traditional (Web 2.0) services and many dApps build on this data and therefore need access to it.
+* Most real-world dapp use cases need some form of data exchange with off-chain entities.
+* Most of the world's data is currently held in traditional (Web 2.0) services and many dapps build on this data and therefore need access to it.
 * In order to be able to reach **blockchain singularity**, smart contracts need to be able to interact with Web 2.0 services. In our journey towards blockchain singularity, an ever increasing amount of data will be pulled into the blockchain world of Web 3.0 and interactions will increasingly take place between different smart contracts without involving Web 2.0 servers.
 
 
 ## Use cases
 There are many use cases for canister HTTPS outcalls, see the following list for some prominent examples.
-* One of the most important use cases is reading data from external HTTP APIs, e.g., pricing data used in DEXs or weather data used in decentralized insurance dApps.
-* IoT dApps need to obtain sensor data from traditional servers with which the sensors interact. In the future, we may even envision direct interactions of sensors with the IC blockchain.
+* One of the most important use cases is reading data from external HTTP APIs, e.g., pricing data used in DEXs or weather data used in decentralized insurance dapps.
+* IoT dapps need to obtain sensor data from traditional servers with which the sensors interact. In the future, we may even envision direct interactions of sensors with the IC blockchain.
 * Chat services sending push notifications about incoming messages to users.
 
 We expect the majority of HTTP calls to be `GET` calls for reading Web 2.0 data, but `POST` clearly also plays an important role for the interaction with external systems in order to be able to write data to Web 2.0 servers.