Copy updates

blog/features/tla-models.md

@@ -7,7 +7,7 @@ image: /img/blog/tla-models.webp
 ---
 
 
-Earlier this year, we highlighted the benefits of applying TLA+ to canister smart contracts on the Internet Computer. The TLDR: (1) the potential for immediate monetary loss makes security and correctness critical for smart contracts, (2) formal methods such as TLA+ increase systems’ correctness and security in general, and (3) TLA+ is in particular good at weeding out a very frequent class of bugs, called reentrancy bugs, from canisters.
+Earlier this year, we highlighted the benefits of applying TLA+ to canister smart contracts on the Internet Computer. The TLDR: (1) the potential for immediate monetary loss makes security and correctness critical for smart contracts, (2) formal methods such as TLA+ increase the protocol’s correctness and security in general, and (3) TLA+ is in particular good at weeding out a very frequent class of bugs, called reentrancy bugs, from canisters.
 
 After some cleanup work, we’re excited to announce that we’ve just open sourced all of our TLA+ models. You’ll find models of the following canisters on GitHub:
 

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

@@ -9,7 +9,7 @@ image: /img/blog/dev-update-blog-exe-1.jpg
 
 **Welcome to edition of the developer blog's team spotlight series! For this issue, we met with members from the Execution team to get insight into how the IC's execution environment works and how it fits within the IC technology stack. Let's start with our usual introduction, what is the purpose of the Execution team?**
 
-*The team’s mission can be summarized as “managing the lifecycle and providing efficient execution of canisters”. We provide the system APIs that canisters can use to run on the IC and interact with other canisters as well as scheduling of messages and cycles accounting.*
+*The team’s mission can be summarized as “managing the lifecycle and providing efficient execution of canisters”. We contribute to the system APIs that canisters can use to run on the IC and interact with other canisters as well as scheduling of messages and cycles accounting.*
 
 **What is the composition of the Execution team?**
 
@@ -36,11 +36,11 @@ image: /img/blog/dev-update-blog-exe-1.jpg
 
 **Thank you for that description! I think that is very insightful for developers to understand what's happening behind the scenes. How do developers interact with the execution layer through canisters?**
 
-*Developers interact with the execution environment through two sets of APIs: the first is a synchronous one which we call the system API. This is analogous to system calls on a regular operating system. The second class is the API provided by the management canister which is asynchronous and is very similar to interacting with any other canister on the IC – this API allows canisters to manage other canisters as well as get access to some of the special features of the IC, including tECDSA and HTTP outcalls.*
+*Developers interact with the execution environment through two sets of APIs: the first is a synchronous one, often called the system API. This is analogous to system calls on a regular operating system. The second class is the API provided by the management canister which is asynchronous and is very similar to interacting with any other canister on the IC – this API allows canisters to manage other canisters as well as get access to some of the special features of the IC, including tECDSA and HTTP outcalls.*
 
 **How does the Execution team work with other teams?**
 
-*The Execution team works with several other teams within DFINITY. We work pretty closely with the Runtime team who are in charge of the lower level Wasm execution engine of the IC, the Message Routing team who are responsible for routing of messages to the appropriate subnet for execution and state management as well as the SDK and Languages teams to expose the APIs provided by the execution environment to the developers.*
+*The Execution team works with several other teams within DFINITY. We work pretty closely with the Runtime team who contribute to the lower level Wasm execution engine of the IC, the Message Routing team who are responsible for routing of messages to the appropriate subnet for execution and state management as well as the SDK and Languages teams to expose the APIs provided by the execution environment to the developers.*
 
 **How does the IC execution environment differ from other forms of execution environments?**
 

docs/developer-docs/backend/rust/2-project-organization.md

@@ -162,9 +162,9 @@ This definition specifies that the `greet` function is a `query` method which ta
 
 ### Stable variables vs flexible variables
 
-**Stable variables** are global variables that the system preserves across upgrades. For example, a user database should probably be stable.
+**Stable variables** are global variables that the protocol preserves across upgrades. For example, a user database should probably be stable.
 
-**Flexible variables** are global variables that the system discards on code upgrade. For example, it is reasonable to make a cache flexible if keeping this cache hot is not critical for your product.
+**Flexible variables** are global variables that the protocol discards on code upgrade. For example, it is reasonable to make a cache flexible if keeping this cache hot is not critical for your product.
 
 ### Putting all global variables in one place
 

docs/developer-docs/integrations/sns/introduction/dao-alternatives.md

@@ -5,7 +5,7 @@ sidebar_position: 4
 
 ## Overview
 
-SNSs are system-provided DAOs on the Internet Computer.
+SNSs are protocol-provided DAOs on the Internet Computer.
 There are of course also other alternatives to getting a DAO.
 
 These possibilities allow communities to choose between using DAOs that are provided
@@ -18,11 +18,11 @@ that have full flexibility of how they can evolve.
   available [open source code](https://github.com/dfinity/ic/tree/master/rs/sns).
 They can deploy this code on a normal application subnet and manually upgrade it.
   They can then choose to follow the same SNS versions than
-  system-provided SNSs follow or they can choose to deviate from this path.
+  protocol-provided SNSs follow or they can choose to deviate from this path.
   In this option, the DAO community has to be more active in
-  implementing, testing and approving code versions. In exchange, they have more flexbility.
-One advantage of the system-provided SNSs over this option is that the verification of the code is
-easier as all SNSs on the SNS subnet run the same cansiter versions that are verified by the
+  implementing, testing and approving code versions. In exchange, they have more flexibility.
+One advantage of the protocol-provided SNSs over this option is that the verification of the code is
+easier as all SNSs on the SNS subnet run the same canister versions that are verified by the
   NNS community.
 
 ## Build your own DAO / use other DAO frameworks

docs/developer-docs/integrations/sns/managing/manage-sns-intro.md

@@ -1,7 +1,7 @@
 # Manage an SNS
 
 ## Overview
-SNSs are system-provided DAOs on the IC that are to some extent maintained by the
+SNSs are protocol-provided DAOs on the IC that are to some extent maintained by the
 NNS community, who for example approve new upgrades of SNS canister code.
 This eliminates much of the maintenance burden from the SNS communities.
 However, there are still some maintenance tasks that have to be performed by an

how-it-works/0_general/01_overview-of-the-internet-computer.subpage.md

@@ -43,7 +43,7 @@ Each subnet hosts canister smart contracts, up to a total of hundreds of gigabyt
 A subnet consists of *node machines*, or *nodes*.
 Each node replicates all the canisters, state, and computation of the subnet using blockchain technology.
 This makes a subnet a blockchain-based *replicated state machine*, that is, a virtual machine that holds state in a secure, fault-tolerant, and non-tamperable manner: the computations of the canisters hosted on a subnet will proceed correctly and without stopping, even if some of the nodes on the subnet are faulty (either because they crash, or even worse, are hacked by a malicious party)
-New subnets can be created from nodes added to the IC to scale out the system, analogous to how traditional infrastructures such as public clouds scale out by adding machines.
+New subnets can be created from nodes added to the IC to scale out the protocol, analogous to how traditional infrastructures such as public clouds scale out by adding machines.
 Such a scale-out architecture is rather the exception than the rule in the blockchain space and allows for limitless scaling, i.e., combining the security and resiliency properties of blockchains with the scalability properties enjoyed by the public cloud.
 
 <figure>

roadmap/2_boundary_nodes/deployed/1_icos-nodes.md

@@ -7,4 +7,4 @@ eta: August 2022
 is_community: false
 ---
 
-This feature enables NNS-driven deployment of boundary nodes, establishing a fully-automated installation and configuration process. The operating system, IC OS, currently used for replica nodes, will also be used for boundary nodes. This solution eliminates manual intervention by DFINITY Foundation employees and builds a basis for ongoing decentralization efforts.
+This feature ports the boundary nodes to IC OS, the operating system currently used for replica nodes. Aligning the two images and their build processes, greatly simplifies operations.

src/pages/capabilities/limitless-scaling.tsx

@@ -72,11 +72,8 @@ function FeaturePage() {
             </p>
             <h3>Subnet Architecture</h3>
             <p>
-              The Internet Computer Protocol is running on standardized node
-              hardware in independent data centers around the world. The Network
-              Nervous System governance system, scales the network by combining
-              nodes from different data centers to spin up new subnet
-              blockchains.
+            The Internet Computer blockchain runs on a network of nodes owned and operated by a growing community of independent 
+            node providers distributed across the globe. The node providers are selected and vetted by the NNS neuron owners.
               <br />
               <br />
               The Internet Computer's partitioning into subnet blockchains is

src/pages/sns.tsx

@@ -116,7 +116,7 @@ function SnsPage() {
               variants={transitions.item}
             >
               Developers can now hand over their Web3 service to an SNS. The
-              community can buy governance tokens to take ownership and control
+              community can acquire governance tokens to take ownership and control
               through the SNS DAO and shape the dapp’s future.
             </motion.p>
             <motion.p
@@ -176,8 +176,8 @@ function SnsPage() {
               >
                 The newly-created SNS tokenizes the dapp through an initial
                 decentralization swap: Part of the dapp’s governance tokens
-                (utility tokens) are bought by the community, providing funding
-                the DAO. Part of the dapp’s utility tokens are allocated to the
+                (utility tokens) are swapped by the community for ICP, providing funding
+                for the DAO. Part of the dapp’s utility tokens are allocated to the
                 original developer(s) as a reward for their initial efforts. The
                 rest remains in a treasury the SNS DAO controls, and is used to
                 fund the future development of the dapp.
@@ -265,11 +265,11 @@ function SnsPage() {
                 variants={transitions.item}
               >
                 Decentralizing dapps through SNSs is the third level of
-                decentralization on the Internet Computer. The first level is
-                the ICP blockchain that runs on decentralized node machines
-                distributed throughout the world, operated by independent
-                entities, and hosted in independent data centers. The second
-                level is the Network Nervous System (NNS) that governs the
+                decentralization on the Internet Computer.The first level is the Internet Computer blockchain 
+                runs on a network of nodes owned and operated by a growing community of independent node providers 
+                distributed across the globe. The node providers are selected and vetted by the NNS neuron owners.
+
+                The second level is the Network Nervous System (NNS) that governs the
                 decentralized ICP blockchain. The third level is the SNS-based
                 decentralization of dapps running on the decentrally-governed
                 decentralized platform. Only such decentralization on every