From a0fb0c6ce41b1978de15b03cb0c49c1215ca7138 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Mon, 30 Oct 2023 13:20:28 -0500 Subject: [PATCH 1/2] applying style guide parameters --- blog/news-and-updates/team-spotlight-node.mdx | 8 ++++---- .../backend/motoko/simple-cycles.md | 2 +- .../developer-docs/backend/resource-limits.md | 8 ++++---- docs/developer-docs/gas-cost.md | 4 ++-- .../bitcoin/bitcoin-how-it-works.md | 20 +++++++++---------- .../integrations/bitcoin/ckbtc.md | 2 +- .../integrations/bitcoin/local-development.md | 2 +- .../https-outcalls-how-to-use.md | 2 +- .../integrations/ledger/collecting-dust.md | 4 ++-- .../t-ecdsa/t-ecdsa-how-it-works.md | 4 ++-- .../setup/cycles/cycles-wallet.md | 2 +- 11 files changed, 29 insertions(+), 29 deletions(-) diff --git a/blog/news-and-updates/team-spotlight-node.mdx b/blog/news-and-updates/team-spotlight-node.mdx index 440566d2b7..221410e390 100644 --- a/blog/news-and-updates/team-spotlight-node.mdx +++ b/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?** diff --git a/docs/developer-docs/backend/motoko/simple-cycles.md b/docs/developer-docs/backend/motoko/simple-cycles.md index 22b0abac93..234902cf48 100644 --- a/docs/developer-docs/backend/motoko/simple-cycles.md +++ b/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: diff --git a/docs/developer-docs/backend/resource-limits.md b/docs/developer-docs/backend/resource-limits.md index dfbd6474cd..fb4208bb64 100644 --- a/docs/developer-docs/backend/resource-limits.md +++ b/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 ` or `canister_query ` exceeds 1,000. -- The sum of `` lengths in all exported functions called `canister_update ` or `canister_query ` exceeds 20,000. +- The number of all exported functions called `canister_update ` or `canister_query ` exceeds 1_000. +- The sum of `` lengths in all exported functions called `canister_update ` or `canister_query ` 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). diff --git a/docs/developer-docs/gas-cost.md b/docs/developer-docs/gas-cost.md index 703a2a3348..2e4e5bde48 100644 --- a/docs/developer-docs/gas-cost.md +++ b/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). diff --git a/docs/developer-docs/integrations/bitcoin/bitcoin-how-it-works.md b/docs/developer-docs/integrations/bitcoin/bitcoin-how-it-works.md index 7430b6a0e8..5becd5e160 100644 --- a/docs/developer-docs/integrations/bitcoin/bitcoin-how-it-works.md +++ b/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. diff --git a/docs/developer-docs/integrations/bitcoin/ckbtc.md b/docs/developer-docs/integrations/bitcoin/ckbtc.md index 180b03fb40..df052d54c1 100644 --- a/docs/developer-docs/integrations/bitcoin/ckbtc.md +++ b/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. diff --git a/docs/developer-docs/integrations/bitcoin/local-development.md b/docs/developer-docs/integrations/bitcoin/local-development.md index 1ba485fc9c..f9f8fbf36e 100644 --- a/docs/developer-docs/integrations/bitcoin/local-development.md +++ b/docs/developer-docs/integrations/bitcoin/local-development.md @@ -190,7 +190,7 @@ Or, via the command line: dfx canister call basic_bitcoin get_balance '("")' -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 diff --git a/docs/developer-docs/integrations/https-outcalls/https-outcalls-how-to-use.md b/docs/developer-docs/integrations/https-outcalls/https-outcalls-how-to-use.md index 8b49cbfbf7..5d88963be5 100644 --- a/docs/developer-docs/integrations/https-outcalls/https-outcalls-how-to-use.md +++ b/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. diff --git a/docs/developer-docs/integrations/ledger/collecting-dust.md b/docs/developer-docs/integrations/ledger/collecting-dust.md index 997013140e..3426d0ae89 100644 --- a/docs/developer-docs/integrations/ledger/collecting-dust.md +++ b/docs/developer-docs/integrations/ledger/collecting-dust.md @@ -15,7 +15,7 @@ The balance of each of these trimmed accounts will also be deleted ## Example -For the SNS ledger, the threshold is currently set a 28 million accounts for the ledger, plus 100,000 for the +For the SNS ledger, the threshold is currently set a 28 million accounts for the ledger, plus 100_000 for the trim quantity. -Therefore, if adding a transaction lead to index more than 28.1 M accounts, the 100,000 accounts with the lowest +Therefore, if adding a transaction lead to index more than 28.1 M accounts, the 100_000 accounts with the lowest balance will be trimmed and their balance burned. diff --git a/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md b/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md index 00de549190..350188cdb5 100644 --- a/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md +++ b/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md @@ -92,13 +92,13 @@ If a canister using this feature is intended to be blackholed, but also for othe | Transaction | Description | Cycles (test key) | USD | |--------------------------------------|----------------------------------------------------------------------------------------------------------------|-----------------------------|-----------------------------| -| Threshold ECDSA signing | For computing one threshold ECDSA signature (`sign_with_ecdsa`) | 10,000,000,000 | $0.0130886 | +| Threshold ECDSA signing | For computing one threshold ECDSA signature (`sign_with_ecdsa`) | 10_000_000_000 | $0.0130886 | ### Fees for the t-ECDSA Production Key | Transaction | Description | Cycles (production key) | USD | |--------------------------------------|----------------------------------------------------------------------------------------------------------------|-----------------------------|-----------------------------| -| Threshold ECDSA signing | For computing one threshold ECDSA signature (`sign_with_ecdsa`) | 26,153,846,153 | $0.0342317 | +| Threshold ECDSA signing | For computing one threshold ECDSA signature (`sign_with_ecdsa`) | 26_153_846_153 | $0.0342317 | ## Environments diff --git a/docs/developer-docs/setup/cycles/cycles-wallet.md b/docs/developer-docs/setup/cycles/cycles-wallet.md index 3b9df22f37..50a789dbb8 100644 --- a/docs/developer-docs/setup/cycles/cycles-wallet.md +++ b/docs/developer-docs/setup/cycles/cycles-wallet.md @@ -327,4 +327,4 @@ The output from the command is in Candid format similar to the following: vec { record { 23_515 = 0; 1_191_829_844 = variant { 4_271_600_268 = record { 23_515 = principal "tsqwz-udeik-5migd-ehrev-pvoqv-szx2g-akh5s-fkyqc-zy6q7-snav6-uqe"; 1_224_700_491 = null; 1_269_754_742 = variant { 4_218_395_836 };} }; 2_781_795_542 = 1_621_456_688_636_513_683;}; record { 23_515 = 1; 1_191_829_844 = variant { 4_271_600_268 = record { 23_515 = principal "ejta3-neil3-qek6c-i7rdw-sxreh-lypfe-v6hjg-6so7x-5ugze-3iohr-2qe"; 1_224_700_491 = null; 1_269_754_742 = variant { 2_494_206_670 };} }; 2_781_795_542 = 1_621_461_468_638_569_551;}; record { 23_515 = 2; 1_191_829_844 = variant { 1_205_528_161 = record { 2_190_693_645 = 11_000_000_000_000; 2_631_180_839 = principal "gvvca-vyaaa-aaaae-aaaga-cai";} }; 2_781_795_542 = 1_621_462_573_993_647_258;}; record { 23_515 = 3; 1_191_829_844 = variant { 1_205_528_161 = record { 2_190_693_645 = 11_000_000_000_000; 2_631_180_839 = principal "gsueu-yaaaa-aaaae-aaagq-cai";} }; 2_781_795_542 = 1_621_462_579_193_578_440;}; record { 23_515 = 4; 1_191_829_844 = variant { 1_955_698_212 = record { 2_190_693_645 = 0; 2_374_371_241 = "install_code"; 2_631_180_839 = principal "aaaaa-aa";} }; 2_781_795_542 = 1_621_462_593_047_590_026;}; record { 23_515 = 5; 1_191_829_844 = variant { 1_955_698_212 = record { 2_190_693_645 = 0; 2_374_371_241 = "install_code"; 2_631_180_839 = principal "aaaaa-aa";} }; 2_781_795_542 = 1_621_462_605_779_157_885;}; record { 23_515 = 6; 1_191_829_844 = variant { 1_955_698_212 = record { 2_190_693_645 = 0; 2_374_371_241 = "authorize"; 2_631_180_839 = principal "gsueu-yaaaa-aaaae-aaagq-cai";} }; 2_781_795_542 = 1_621_462_609_036_146_536;}; record { 23_515 = 7; 1_191_829_844 = variant { 1_955_698_212 = record { 2_190_693_645 = 0; 2_374_371_241 = "greet"; 2_631_180_839 = principal "gvvca-vyaaa-aaaae-aaaga-cai";} }; 2_781_795_542 = 1_621_463_144_066_333_270;}; record { 23_515 = 8; 1_191_829_844 = variant { 4_271_600_268 = record { 23_515 = principal "ejta3-neil3-qek6c-i7rdw-sxreh-lypfe-v6hjg-6so7x-5ugze-3iohr-2qe"; 1_224_700_491 = null; 1_269_754_742 = variant { 2_494_206_670 };} }; 2_781_795_542 = 1_621_463_212_828_477_570;}; record { 23_515 = 9; 1_191_829_844 = variant { 1_955_698_212 = record { 2_190_693_645 = 0; 2_374_371_241 = "wallet_balance"; 2_631_180_839 = principal "gastn-uqaaa-aaaae-aaafq-cai";} }; 2_781_795_542 = 1_621_878_637_071_884_946;}; record { 23_515 = 10; 1_191_829_844 = variant { 4_271_600_268 = record { 23_515 = principal "b5quc-npdph-l6qp4-kur4u-oxljq-7uddl-vfdo6-x2uo5-6y4a6-4pt6v-7qe"; 1_224_700_491 = null; 1_269_754_742 = variant { 4_218_395_836 };} }; 2_781_795_542 = 1_621_879_473_916_547_313;}; record { 23_515 = 11; 1_191_829_844 = variant { 313_999_214 = record { 1_136_829_802 = principal "gastn-uqaaa-aaaae-aaafq-cai"; 3_573_748_184 = 10_000_000_000;} }; 2_781_795_542 = 1_621_977_470_023_492_664;}; record { 23_515 = 12; 1_191_829_844 = variant { 2_171_739_429 = record { 25_979 = principal "gastn-uqaaa-aaaae-aaafq-cai"; 3_573_748_184 = 10_000_000_000; 4_293_698_680 = 0;} }; 2_781_795_542 = 1_621_977_470_858_839_320;};}, ) -In this example, there are twelve event records. The `Role` field (represented by the hash `1_269_754_742`) specifies whether a principal is a controller (represented by the hash `4_218_395_836`) or a custodian (represented by the hash `2_494_206_670`). The events in this example also illustrate an amount field (represented by the hash `3_573_748_184`) with a transfer of 10,000,000,000 cycles. \ No newline at end of file +In this example, there are twelve event records. The `Role` field (represented by the hash `1_269_754_742`) specifies whether a principal is a controller (represented by the hash `4_218_395_836`) or a custodian (represented by the hash `2_494_206_670`). The events in this example also illustrate an amount field (represented by the hash `3_573_748_184`) with a transfer of 10_000_000_000 cycles. \ No newline at end of file From 5ed28ecc7b900bd62a21d33155b1b32b65275b66 Mon Sep 17 00:00:00 2001 From: Jessie Mongeon Date: Mon, 30 Oct 2023 13:28:48 -0500 Subject: [PATCH 2/2] apply dapp capitalization --- .../integrations/https-outcalls/index.md | 8 ++++---- .../integrations/t-ecdsa/t-ecdsa-how-it-works.md | 2 +- .../01_overview-of-the-internet-computer.subpage.md | 12 ++++++------ how-it-works/1_protocol/04_execution.subpage.md | 4 ++-- plugins/data/conversations-mock.js | 2 +- roadmap/1_core-protocol/deployed/03_http-outcalls.md | 2 +- roadmap/5_developer_experience/upcoming/dfx_sns.md | 4 ++-- showcase.json | 12 ++++++------ 8 files changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/developer-docs/integrations/https-outcalls/index.md b/docs/developer-docs/integrations/https-outcalls/index.md index 29afd84b36..a63c0d3c0e 100644 --- a/docs/developer-docs/integrations/https-outcalls/index.md +++ b/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. diff --git a/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md b/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md index 350188cdb5..a2d324ea28 100644 --- a/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md +++ b/docs/developer-docs/integrations/t-ecdsa/t-ecdsa-how-it-works.md @@ -114,6 +114,6 @@ For the technically interested readers we want to note that the SDK uses the exa ### Internet Computer -Any canister on any subnet of the IC can call the threshold ECDSA API exposed by the management canister. The calls are routed via XNet communication to the ECDSA-enabled subnet that holds the key referred to in the API call (only one such signing subnet holding a test key and one signing subnet holding the production key are available currently). Note that this test key is hosted on a subnet with a replication factor of only 13 and may be deleted in the future, thus it should not be used for anything of value, but rather solely for development and testing purposes. The main intended purpose is to facilitate the development and testing of Bitcoin-enabled dApps using Bitcoin testnet. +Any canister on any subnet of the IC can call the threshold ECDSA API exposed by the management canister. The calls are routed via XNet communication to the ECDSA-enabled subnet that holds the key referred to in the API call (only one such signing subnet holding a test key and one signing subnet holding the production key are available currently). Note that this test key is hosted on a subnet with a replication factor of only 13 and may be deleted in the future, thus it should not be used for anything of value, but rather solely for development and testing purposes. The main intended purpose is to facilitate the development and testing of Bitcoin-enabled dapps using Bitcoin testnet. As part of the general availability (GA) release of the feature, a production ECDSA key on the `secp256k1` elliptic curve has been deployed to be used for integration with the Bitcoin Mainnet and other use cases of interest. diff --git a/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md b/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md index 289ae72e60..a617f6ddfe 100644 --- a/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md +++ b/how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md @@ -17,7 +17,7 @@ A smart contract on the IC is called *canister smart contract*, or just *caniste A canister bundles [*WebAssembly (Wasm)*](https://en.wikipedia.org/wiki/WebAssembly) program code and data storage into a single unit. Anyone can deploy a canister on the Internet Computer. Canisters are stored and their code executed in a replicated, fault-tolerant manner on multiple machines, that is, the nodes of a subnet. -Unlike other blockchains, a smart contract on the IC can respect one of several possible *mutability policies*: it can be completely immutable (cannot be changed by anyone), unilaterally mutable (can be changed unilaterally by the dApp developer), or DAO mutable (it can be changed as authorized by a decentralized autonomous organization). +Unlike other blockchains, a smart contract on the IC can respect one of several possible *mutability policies*: it can be completely immutable (cannot be changed by anyone), unilaterally mutable (can be changed unilaterally by the dapp developer), or DAO mutable (it can be changed as authorized by a decentralized autonomous organization). Canisters pay, using *cycles*, for the IC resources they consume. @@ -89,7 +89,7 @@ Both chain-key and chain-evolution technology sets the IC apart from other proje ## Governance -The IC offers governance at multiple levels, the platform level and the dApp level. +The IC offers governance at multiple levels, the platform level and the dapp level. ### Platform governance @@ -99,10 +99,10 @@ The NNS allows holders of the staked ICP to make proposals and vote on those pro ### Dapp governance -dApps on the IC can be governed by an out-of-the-box deployable governance system, the *Service Nervous System (SNS)*, which is similar to the platform's NNS, but tailored to govern dApps. -Everyone controlling a dApp can hand over control over their dApp to a tokenized DAO by parameterizing and deploying an instance of the SNS. -The SNS implements tokenized governance at the dApp level and can be used without the dApp engineers implementing a governance system themselves, which is revolutionary. -Handing over control of a dApp to an instance of the SNS usually includes running a decentralization swap as an early step where funds can be raised through the swap of the dApp's governance tokens. +dapps on the IC can be governed by an out-of-the-box deployable governance system, the *Service Nervous System (SNS)*, which is similar to the platform's NNS, but tailored to govern dapps. +Everyone controlling a dapp can hand over control over their dapp to a tokenized DAO by parameterizing and deploying an instance of the SNS. +The SNS implements tokenized governance at the dapp level and can be used without the dapp engineers implementing a governance system themselves, which is revolutionary. +Handing over control of a dapp to an instance of the SNS usually includes running a decentralization swap as an early step where funds can be raised through the swap of the dapp's governance tokens. ## Go even deeper diff --git a/how-it-works/1_protocol/04_execution.subpage.md b/how-it-works/1_protocol/04_execution.subpage.md index 5a0b773d46..8c2bfdf40b 100644 --- a/how-it-works/1_protocol/04_execution.subpage.md +++ b/how-it-works/1_protocol/04_execution.subpage.md @@ -54,7 +54,7 @@ However, all the nodes of the subnet can concurrently execute different queries Query throughput of a subnet thus increases linearly with an increasing number of nodes in the subnet, while the update call performance decreases with an increasing number of nodes. Queries are similar to read operations on a local or cloud Ethereum node on the Ethereum blockchain. -A dApp should use queries for non-critical operations only. +A dapp should use queries for non-critical operations only. Whenever an information item to be read is critical, e.g., financial data based on which decisions are made, update calls should be used to obtain such information as the response of an update call is certified by the subnet with a BLS threshold signature and verifiable with the subnet's public key. ## Deterministic Time Slicing @@ -80,7 +80,7 @@ The states obtained while executing canisters are certified (i.e. digitally sign Memory pages representing canister state are persisted to SSD by the execution layer, without canister programmers needing to take care of this. Having all memory pages transparently persisted enables _orthogonal persistence_ and frees the smart contract programmers from reading from and writing to storage as on other blockchains or as in traditional IT systems. -This dramatically simplifies smart contract implementation and helps reduce the TCO of a dApp and go to market faster. +This dramatically simplifies smart contract implementation and helps reduce the TCO of a dapp and go to market faster. Programmers can always have the full canister smart contract state on the heap or in stable memory. The difference is that the heap is cleared on updates of the canister code, while stable memory remains stable throughout updates, hence its name. Any state on the heap that is to be preserved through a canister update must be transferred to stable memory by a canister programmer before an update and restored from there after the update. diff --git a/plugins/data/conversations-mock.js b/plugins/data/conversations-mock.js index d3250e8556..2c3c4ec350 100644 --- a/plugins/data/conversations-mock.js +++ b/plugins/data/conversations-mock.js @@ -706,7 +706,7 @@ module.exports = [ speaker: "Dieter Sommer ", speakerTitle: "Senior Technical Program Manager", description: - "

The Ethereum Virtual Machine (EVM) has been the first and is still the world's most-widely-used smart contract execution environment. The EVM features synchronous smart contract call semantics which simplifies certain aspects of smart contract implementation, but greatly impedes scalability. Currently, the EVM is the environment of choice of most DeFi dApps and therefore EVM-compatible chains can benefit from network effects resulting from easily-portable DeFi smart contracts, a large tooling ecosystem and developer community and still the largest user community.\nIn this talk we shed some light onto what it would take to make the Internet Computer EVM compatible. We particularly consider the option of running an EVM as a smart contract on the Internet Computer. The major challenges of bringing the EVM to the Internet Computer result from the impedance mismatch between the asynchronous messaging model of the Internet Computer and the synchronous smart contract call semantics of the EVM. We present limitations of EVM architectures on the Internet Computer and potential solutions to the main challenges. This talk is intended as a starting point of a wider (technical) discussion on how to best bring an EVM to the Internet Computer.

\n", + "

The Ethereum Virtual Machine (EVM) has been the first and is still the world's most-widely-used smart contract execution environment. The EVM features synchronous smart contract call semantics which simplifies certain aspects of smart contract implementation, but greatly impedes scalability. Currently, the EVM is the environment of choice of most DeFi dapps and therefore EVM-compatible chains can benefit from network effects resulting from easily-portable DeFi smart contracts, a large tooling ecosystem and developer community and still the largest user community.\nIn this talk we shed some light onto what it would take to make the Internet Computer EVM compatible. We particularly consider the option of running an EVM as a smart contract on the Internet Computer. The major challenges of bringing the EVM to the Internet Computer result from the impedance mismatch between the asynchronous messaging model of the Internet Computer and the synchronous smart contract call semantics of the EVM. We present limitations of EVM architectures on the Internet Computer and potential solutions to the main challenges. This talk is intended as a starting point of a wider (technical) discussion on how to best bring an EVM to the Internet Computer.

\n", zoomLink: "https://dfinity.zoom.us/webinar/register/WN_TN84N3uhSPiOi5pOZx0FIg", tbdMonth: "2022-12", diff --git a/roadmap/1_core-protocol/deployed/03_http-outcalls.md b/roadmap/1_core-protocol/deployed/03_http-outcalls.md index fa44e60972..52f0b10eee 100644 --- a/roadmap/1_core-protocol/deployed/03_http-outcalls.md +++ b/roadmap/1_core-protocol/deployed/03_http-outcalls.md @@ -10,4 +10,4 @@ is_community: true in_beta: false --- -This feature directly integrates the Web3 with the Web2 worlds by enabling canister smart contracts on the Internet Computer to make HTTP(S) outcalls to Web 2.0 services outside the blockchain in a completely trustless manner. Using this feature, we can realize a substantial part of the functionalities currently offered by blockchain oracle services, just with better security guarantees and at a lower cost. Possible use cases include directly obtaining market data from HTTP servers for DeFi dApps and decentralized insurance services, sending notifications to end users via traditional communications channels, or implementing, by also using the threshold ECDSA feature, an Ethereum integration entirely in canister space. +This feature directly integrates the Web3 with the Web2 worlds by enabling canister smart contracts on the Internet Computer to make HTTP(S) outcalls to Web 2.0 services outside the blockchain in a completely trustless manner. Using this feature, we can realize a substantial part of the functionalities currently offered by blockchain oracle services, just with better security guarantees and at a lower cost. Possible use cases include directly obtaining market data from HTTP servers for DeFi dapps and decentralized insurance services, sending notifications to end users via traditional communications channels, or implementing, by also using the threshold ECDSA feature, an Ethereum integration entirely in canister space. diff --git a/roadmap/5_developer_experience/upcoming/dfx_sns.md b/roadmap/5_developer_experience/upcoming/dfx_sns.md index 5f7ac25340..ad31ea3539 100644 --- a/roadmap/5_developer_experience/upcoming/dfx_sns.md +++ b/roadmap/5_developer_experience/upcoming/dfx_sns.md @@ -6,6 +6,6 @@ links: eta: is_community: false --- -We want to enable more developers to decentralize their dApps through the SNS. DFX will soon have more tools +We want to enable more developers to decentralize their dapps through the SNS. DFX will soon have more tools and capabilities for you to develop your code and test your swap locally, run a simulated swap on mainnet, and -manage your dApp after it has been launched. +manage your dapp after it has been launched. diff --git a/showcase.json b/showcase.json index 8a7d988336..24d78129c3 100644 --- a/showcase.json +++ b/showcase.json @@ -507,7 +507,7 @@ "name": "Orally", "oneLiner": "The fully on-chain oracles for secure and reliable decentralized data feeding and automation across multiple chains.", "tags": ["Tools / Infrastructure", "DeFi", "Ethereum"], - "description": "The fully on-chain oracles for secure and reliable decentralized data feeding and automation across multiple chains. Experience seamless real-world data integration across various blockchains, powering dynamic, secure and efficient dApps. Elevate your blockchain journey with us!", + "description": "The fully on-chain oracles for secure and reliable decentralized data feeding and automation across multiple chains. Experience seamless real-world data integration across various blockchains, powering dynamic, secure and efficient dapps. Elevate your blockchain journey with us!", "usesInternetIdentity": false, "website": "https://orally.network", "github": "https://github.com/orally-network", @@ -542,7 +542,7 @@ { "id": "juno", "name": "Juno", - "oneLiner": "Build Web3 dApps like Web2", + "oneLiner": "Build Web3 dapps like Web2", "website": "https://juno.build", "tags": [ "Tools / Infrastructure" @@ -1765,7 +1765,7 @@ "tags": [ "Tools / Infrastructure" ], - "description": "Build scalable DApps on internet computer with ease. Build, manage and ship dApps with just a few clicks", + "description": "Build scalable DApps on internet computer with ease. Build, manage and ship dapps with just a few clicks", "usesInternetIdentity": false, "display": "Normal", "logo": "/img/showcase/ics_logo.webp", @@ -1796,7 +1796,7 @@ "NFT", "Wallet" ], - "description": "Canister Store is a groundbreaking platform that empowers developers/users in the Internet Computer ecosystem and beyond. With its innovative self-deploy feature, users can effortlessly access and deploy canisters, including pre-built images such as Tokens, NFTs, dApps, and various other tools.", + "description": "Canister Store is a groundbreaking platform that empowers developers/users in the Internet Computer ecosystem and beyond. With its innovative self-deploy feature, users can effortlessly access and deploy canisters, including pre-built images such as Tokens, NFTs, dapps, and various other tools.", "usesInternetIdentity": true, "website": "https://canister.app", "github": "https://github.com/canister-app", @@ -2489,7 +2489,7 @@ "tags": [ "SocialFi" ], - "description": "Welcome to IC Hub! Your dApp for connecting with friends, chatting, joining groups, and managing tokens & NFTs. For developers, register your projects easily without seeking permissions. Empowering you to connect, transact, and build in a user-friendly ecosystem.", + "description": "Welcome to IC Hub! Your dapp for connecting with friends, chatting, joining groups, and managing tokens & NFTs. For developers, register your projects easily without seeking permissions. Empowering you to connect, transact, and build in a user-friendly ecosystem.", "usesInternetIdentity": true, "stats": "50+ Projects", "logo": "/img/showcase/ichub_logo.png", @@ -3001,7 +3001,7 @@ ], "display": "Normal", "id": "doocoins", - "oneLiner": "Kids rewards dApp", + "oneLiner": "Kids rewards dapp", "tags": [ "Wallet", "Games"