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"