Convert all spelling to Google English

CODE_OF_CONDUCT.adoc

@@ -24,7 +24,7 @@ Examples of unacceptable behavior by participants include:
 
 === Facilitation, Not Strongarming
 
-We recognise that this software is merely a tool for users to create and maintain their blockchain of preference. We see that blockchains are naturally community platforms with users being the ultimate decision makers. We assert that good software will maximise user agency by facilitate user-expression on the network. As such:
+We recognize that this software is merely a tool for users to create and maintain their blockchain of preference. We see that blockchains are naturally community platforms with users being the ultimate decision makers. We assert that good software will maximize user agency by facilitate user-expression on the network. As such:
 
 * This project will strive to give users as much choice as is both reasonable and possible over what protocol they adhere to; but
 * use of the project's technical forums, commenting systems, pull requests and issue trackers as a means to express individual protocol preferences is forbidden.

CONTRIBUTING.adoc

@@ -33,10 +33,10 @@ Merging pull requests once CI is successful:
 
 When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
 
-. Buggy behaviour.
+. Buggy behavior.
 . Undue maintenance burden.
 . Breaking with house coding style.
-. Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
+. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).
 . Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
 . Uselessness (i.e. it does not strictly add a feature or fix a known issue).
 
@@ -47,7 +47,7 @@ When reviewing a pull request, the end-goal is to suggest useful changes to the
 
 == Helping out
 
-We use https://github.com/paritytech/substrate/labels[labels] to manage PRs and issues and communicate state of a PR. Please familiarize yourself with them. Furthermore we are organising issues in https://github.com/paritytech/substrate/milestones[milestones]. Best way to get started is to a pick a ticket from the current milestone tagged https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ2-easy[`easy`] or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ3-medium[`medium`] and get going or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AX1-mentor[`mentor`] and get in contact with the mentor offering their support on that larger task.
+We use https://github.com/paritytech/substrate/labels[labels] to manage PRs and issues and communicate state of a PR. Please familiarize yourself with them. Furthermore we are organizing issues in https://github.com/paritytech/substrate/milestones[milestones]. Best way to get started is to a pick a ticket from the current milestone tagged https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ2-easy[`easy`] or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ3-medium[`medium`] and get going or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AX1-mentor[`mentor`] and get in contact with the mentor offering their support on that larger task.
 
 == Releases
 

README.adoc

@@ -10,9 +10,9 @@ Substrate is a next-generation framework for blockchain innovation.
 
 == Description
 
-At its heart, Substrate is a combination of three technologies: https://webassembly.org/[WebAssembly], https://libp2p.io/[Libp2p] and GRANDPA Consensus. About GRANDPA, see this https://hackmd.io/Jd0byWX0RiqFiXUVC78Bdw?view#GRANDPA[definition], https://medium.com/polkadot-network/grandpa-block-finality-in-polkadot-an-introduction-part-1-d08a24a021b5[introduction] and https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf[formal specification]. It is both a library for building new blockchains and a "skeleton key" of a blockchain client, able to synchronise to any Substrate-based chain.
+At its heart, Substrate is a combination of three technologies: https://webassembly.org/[WebAssembly], https://libp2p.io/[Libp2p] and GRANDPA Consensus. About GRANDPA, see this https://hackmd.io/Jd0byWX0RiqFiXUVC78Bdw?view#GRANDPA[definition], https://medium.com/polkadot-network/grandpa-block-finality-in-polkadot-an-introduction-part-1-d08a24a021b5[introduction] and https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf[formal specification]. It is both a library for building new blockchains and a "skeleton key" of a blockchain client, able to synchronize to any Substrate-based chain.
 
-Substrate chains have three distinct features that make them "next-generation": a dynamic, self-defining state-transition function; light-client functionality from day one; and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and procedures for replacing any aspect of itself or of the blockchain's state ("governance"). Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".
+Substrate chains have three distinct features that make them "next-generation": a dynamic, self-defining state-transition function; light-client functionality from day one; and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and procedures for replacing any aspect of itself or of the blockchain's state ("governance"). Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organizm".
 
 See also https://www.parity.io/what-is-substrate/.
 
@@ -39,7 +39,7 @@ Block := Header + Extrinsics + Justifications
 
 === Extrinsics
 
-Extrinsics in Substrate are pieces of information from "the outside world" that are contained in the blocks of the chain. You might think "ahh, that means *transactions*": in fact, no. Extrinsics fall into two broad categories of which only one is *transactions*. The other is known as *inherents*. The difference between these two is that transactions are signed and gossipped on the network and can be deemed useful *per se*. This fits the mould of what you would call transactions in Bitcoin or Ethereum.
+Extrinsics in Substrate are pieces of information from "the outside world" that are contained in the blocks of the chain. You might think "ahh, that means *transactions*": in fact, no. Extrinsics fall into two broad categories of which only one is *transactions*. The other is known as *inherents*. The difference between these two is that transactions are signed and gossipped on the network and can be deemed useful *per se*. This fits the mold of what you would call transactions in Bitcoin or Ethereum.
 
 Inherents, meanwhile, are not passed on the network and are not signed. They represent data which describes the environment but which cannot call upon anything to prove it such as a signature. Rather they are assumed to be "true" simply because a sufficiently large number of validators have agreed on them being reasonable.
 
@@ -71,8 +71,8 @@ impl_runtime_apis! {
 			Executive::execute_block(block)
 		}
 
-		fn initialise_block(header: <Block as BlockT>::Header) {
-			Executive::initialise_block(&header)
+		fn initialize_block(header: <Block as BlockT>::Header) {
+			Executive::initialize_block(&header)
 		}
 	}
 	// ---snip---
@@ -86,9 +86,9 @@ The Substrate Runtime Module Library includes functionality for timestamps and s
 
 === Block-authoring Logic
 
-In Substrate, there is a major distinction between blockchain *syncing* and block *authoring* ("authoring" is a more general term for what is called "mining" in Bitcoin). The first case might be referred to as a "full node" (or "light node" - Substrate supports both): authoring necessarily requires a synced node and, therefore, all authoring clients must necessarily be able to synchronise. However, the reverse is not true. The primary functionality that authoring nodes have which is not in "sync nodes" is threefold: transaction queue logic, inherent transaction knowledge and BFT consensus logic. BFT consensus logic is provided as a core element of Substrate and can be ignored since it is only exposed in the SDK under the `authorities()` API entry.
+In Substrate, there is a major distinction between blockchain *syncing* and block *authoring* ("authoring" is a more general term for what is called "mining" in Bitcoin). The first case might be referred to as a "full node" (or "light node" - Substrate supports both): authoring necessarily requires a synced node and, therefore, all authoring clients must necessarily be able to synchronize. However, the reverse is not true. The primary functionality that authoring nodes have which is not in "sync nodes" is threefold: transaction queue logic, inherent transaction knowledge and BFT consensus logic. BFT consensus logic is provided as a core element of Substrate and can be ignored since it is only exposed in the SDK under the `authorities()` API entry.
 
-Transaction queue logic in Substrate is designed to be as generic as possible, allowing a runtime to express which transactions are fit for inclusion in a block through the `initialize_block` and `apply_extrinsic` calls. However, more subtle aspects like prioritisation and replacement policy must currently be expressed "hard coded" as part of the blockchain's authoring code. That said, Substrate's reference implementation for a transaction queue should be sufficient for an initial chain implementation.
+Transaction queue logic in Substrate is designed to be as generic as possible, allowing a runtime to express which transactions are fit for inclusion in a block through the `initialize_block` and `apply_extrinsic` calls. However, more subtle aspects like prioritization and replacement policy must currently be expressed "hard coded" as part of the blockchain's authoring code. That said, Substrate's reference implementation for a transaction queue should be sufficient for an initial chain implementation.
 
 Inherent extrinsic knowledge is again somewhat generic, and the actual construction of the extrinsics is, by convention, delegated to the "soft code" in the runtime. If ever there needs to be additional extrinsic information in the chain, then both the block authoring logic will need to be altered to provide it into the runtime and the runtime's `inherent_extrinsics` call will need to use this extra information in order to construct any additional extrinsic transactions for inclusion in the block.
 
@@ -167,7 +167,7 @@ It won't do much until you start producing blocks though, so to do that you'll n
 substrate --chain ~/mychain.json --validator --key ...
 ----
 
-You can distribute `mychain.json` so that everyone can synchronise and (depending on your authorities list) validate on your chain.
+You can distribute `mychain.json` so that everyone can synchronize and (depending on your authorities list) validate on your chain.
 
 
 == Building

core/basic-authorship/src/basic_authorship.rs

@@ -177,7 +177,7 @@ impl<Block, C, A> consensus_common::Proposer<<C as AuthoringApi>::Block> for Pro
 	fn propose(&self, inherent_data: InherentData, max_duration: time::Duration)
 		-> Result<<C as AuthoringApi>::Block, error::Error>
 	{
-		// leave some time for evaluation and block finalisation (33%)
+		// leave some time for evaluation and block finalization (33%)
 		let deadline = (self.now)() + max_duration - max_duration / 3;
 		self.propose_with(inherent_data, deadline)
 	}
@@ -197,7 +197,7 @@ impl<Block, C, A> Proposer<Block, C, A>	where
 
 		/// If the block is full we will attempt to push at most
 		/// this number of transactions before quitting for real.
-		/// It allows us to increase block utilisation.
+		/// It allows us to increase block utilization.
 		const MAX_SKIPPED_TRANSACTIONS: usize = 8;
 
 		let block = self.client.build_block(

core/client/src/block_builder/api.rs

@@ -28,7 +28,7 @@ decl_runtime_apis! {
 		/// Apply the given extrinsics.
 		fn apply_extrinsic(extrinsic: <Block as BlockT>::Extrinsic) -> ApplyResult;
 		/// Finish the current block.
-		fn finalise_block() -> <Block as BlockT>::Header;
+		fn finalize_block() -> <Block as BlockT>::Header;
 		/// Generate inherent extrinsics. The inherent data will vary from chain to chain.
 		fn inherent_extrinsics(inherent: InherentData) -> Vec<<Block as BlockT>::Extrinsic>;
 		/// Check that the inherents are valid. The inherent data will vary from chain to chain.

core/client/src/block_builder/block_builder.rs

@@ -64,7 +64,7 @@ where
 			Default::default()
 		);
 		let api = api.runtime_api();
-		api.initialise_block_with_context(block_id, ExecutionContext::BlockConstruction, &header)?;
+		api.initialize_block_with_context(block_id, ExecutionContext::BlockConstruction, &header)?;
 		Ok(BlockBuilder {
 			header,
 			extrinsics: Vec::new(),
@@ -97,7 +97,7 @@ where
 
 	/// Consume the builder to return a valid `Block` containing all pushed extrinsics.
 	pub fn bake(mut self) -> error::Result<Block> {
-		self.header = self.api.finalise_block_with_context(&self.block_id, ExecutionContext::BlockConstruction)?;
+		self.header = self.api.finalize_block_with_context(&self.block_id, ExecutionContext::BlockConstruction)?;
 
 		debug_assert_eq!(
 			self.header.extrinsics_root().clone(),

core/client/src/call_executor.rs

@@ -73,7 +73,7 @@ where
 		method: &str,
 		call_data: &[u8],
 		changes: &mut OverlayedChanges,
-		initialised_block: &mut Option<BlockId<B>>,
+		initialized_block: &mut Option<BlockId<B>>,
 		prepare_environment_block: PB,
 		execution_manager: ExecutionManager<EM>,
 		native_call: Option<NC>,
@@ -213,29 +213,29 @@ where
 		method: &str,
 		call_data: &[u8],
 		changes: &mut OverlayedChanges,
-		initialised_block: &mut Option<BlockId<Block>>,
+		initialized_block: &mut Option<BlockId<Block>>,
 		prepare_environment_block: PB,
 		execution_manager: ExecutionManager<EM>,
 		native_call: Option<NC>,
 		mut side_effects_handler: Option<&mut O>,
 	) -> Result<NativeOrEncoded<R>, error::Error> where ExecutionManager<EM>: Clone {
 		let state = self.backend.state_at(*at)?;
-		if method != "Core_initialise_block" && initialised_block.map(|id| id != *at).unwrap_or(true) {
+		if method != "Core_initialize_block" && initialized_block.map(|id| id != *at).unwrap_or(true) {
 			let header = prepare_environment_block()?;
 			state_machine::new(
 				&state,
 				self.backend.changes_trie_storage(),
 				side_effects_handler.as_mut().map(|x| &mut **x),
 				changes,
 				&self.executor,
-				"Core_initialise_block",
+				"Core_initialize_block",
 				&header.encode(),
 			).execute_using_consensus_failure_handler::<_, R, fn() -> _>(
 				execution_manager.clone(),
 				false,
 				None,
 			)?;
-			*initialised_block = Some(*at);
+			*initialized_block = Some(*at);
 		}
 
 		let result = state_machine::new(
@@ -252,9 +252,9 @@ where
 			native_call,
 		).map(|(result, _, _)| result)?;
 
-		// If the method is `initialise_block` we need to set the `initialised_block`
-		if method == "Core_initialise_block" {
-			*initialised_block = Some(*at);
+		// If the method is `initialize_block` we need to set the `initialized_block`
+		if method == "Core_initialize_block" {
+			*initialized_block = Some(*at);
 		}
 
 		self.backend.destroy_state(state)?;

core/client/src/client.rs

@@ -285,7 +285,7 @@ impl<B, E, Block, RA> Client<B, E, Block, RA> where
 			backend.begin_state_operation(&mut op, BlockId::Hash(Default::default()))?;
 			let state_root = op.reset_storage(genesis_storage, children_genesis_storage)?;
 			let genesis_block = genesis::construct_genesis_block::<Block>(state_root.into());
-			info!("Initialising Genesis block/state (state: {}, header-hash: {})", genesis_block.header().state_root(), genesis_block.header().hash());
+			info!("Initializing Genesis block/state (state: {}, header-hash: {})", genesis_block.header().state_root(), genesis_block.header().hash());
 			op.set_block_data(
 				genesis_block.deconstruct().0,
 				Some(vec![]),
@@ -1351,7 +1351,7 @@ impl<B, E, Block, RA> CallRuntimeAt<Block> for Client<B, E, Block, RA> where
 		function: &'static str,
 		args: Vec<u8>,
 		changes: &mut OverlayedChanges,
-		initialised_block: &mut Option<BlockId<Block>>,
+		initialized_block: &mut Option<BlockId<Block>>,
 		native_call: Option<NC>,
 		context: ExecutionContext,
 	) -> error::Result<NativeOrEncoded<R>> {
@@ -1373,7 +1373,7 @@ impl<B, E, Block, RA> CallRuntimeAt<Block> for Client<B, E, Block, RA> where
 			function,
 			&args,
 			changes,
-			initialised_block,
+			initialized_block,
 			|| self.prepare_environment_block(at),
 			manager,
 			native_call,
@@ -1630,7 +1630,7 @@ pub(crate) mod tests {
 	}
 
 	#[test]
-	fn client_initialises_from_genesis_ok() {
+	fn client_initializes_from_genesis_ok() {
 		let client = test_client::new();
 
 		assert_eq!(

core/client/src/genesis.rs

@@ -93,7 +93,7 @@ mod tests {
 			state_machine::NeverOffchainExt::new(),
 			&mut overlay,
 			&executor(),
-			"Core_initialise_block",
+			"Core_initialize_block",
 			&header.encode(),
 		).execute(
 			ExecutionStrategy::NativeElseWasm,
@@ -119,7 +119,7 @@ mod tests {
 			state_machine::NeverOffchainExt::new(),
 			&mut overlay,
 			&executor(),
-			"BlockBuilder_finalise_block",
+			"BlockBuilder_finalize_block",
 			&[],
 		).execute(
 			ExecutionStrategy::NativeElseWasm,

core/client/src/light/call_executor.rs

@@ -118,14 +118,14 @@ where
 		method: &str,
 		call_data: &[u8],
 		changes: &mut OverlayedChanges,
-		initialised_block: &mut Option<BlockId<Block>>,
+		initialized_block: &mut Option<BlockId<Block>>,
 		_prepare_environment_block: PB,
 		execution_manager: ExecutionManager<EM>,
 		_native_call: Option<NC>,
 		side_effects_handler: Option<&mut O>,
 	) -> ClientResult<NativeOrEncoded<R>> where ExecutionManager<EM>: Clone {
 		// it is only possible to execute contextual call if changes are empty
-		if !changes.is_empty() || initialised_block.is_some() {
+		if !changes.is_empty() || initialized_block.is_some() {
 			return Err(ClientErrorKind::NotAvailableOnLightClient.into());
 		}
 
@@ -245,7 +245,7 @@ impl<Block, B, Remote, Local> CallExecutor<Block, Blake2Hasher> for
 		method: &str,
 		call_data: &[u8],
 		changes: &mut OverlayedChanges,
-		initialised_block: &mut Option<BlockId<Block>>,
+		initialized_block: &mut Option<BlockId<Block>>,
 		prepare_environment_block: PB,
 		_manager: ExecutionManager<EM>,
 		native_call: Option<NC>,
@@ -270,7 +270,7 @@ impl<Block, B, Remote, Local> CallExecutor<Block, Blake2Hasher> for
 				method,
 				call_data,
 				changes,
-				initialised_block,
+				initialized_block,
 				prepare_environment_block,
 				ExecutionManager::NativeWhenPossible,
 				native_call,
@@ -291,7 +291,7 @@ impl<Block, B, Remote, Local> CallExecutor<Block, Blake2Hasher> for
 				method,
 				call_data,
 				changes,
-				initialised_block,
+				initialized_block,
 				prepare_environment_block,
 				ExecutionManager::NativeWhenPossible,
 				native_call,
@@ -388,7 +388,7 @@ pub fn prove_execution<Block, S, E>(
 	let (_, init_proof) = executor.prove_at_trie_state(
 		&trie_state,
 		&mut changes,
-		"Core_initialise_block",
+		"Core_initialize_block",
 		&header.encode(),
 	)?;
 
@@ -435,7 +435,7 @@ pub fn check_execution_proof<Header, E, H>(
 		&trie_backend,
 		&mut changes,
 		executor,
-		"Core_initialise_block",
+		"Core_initialize_block",
 		&next_block.encode(),
 	)?;
 
@@ -516,12 +516,12 @@ mod tests {
 		assert_eq!(remote, local);
 
 		// check method that requires environment
-		let (_, block) = execute(&remote_client, 0, "BlockBuilder_finalise_block");
+		let (_, block) = execute(&remote_client, 0, "BlockBuilder_finalize_block");
 		let local_block: Header = Decode::decode(&mut &block[..]).unwrap();
 		assert_eq!(local_block.number, 1);
 
 		// check method that requires environment
-		let (_, block) = execute(&remote_client, 2, "BlockBuilder_finalise_block");
+		let (_, block) = execute(&remote_client, 2, "BlockBuilder_finalize_block");
 		let local_block: Header = Decode::decode(&mut &block[..]).unwrap();
 		assert_eq!(local_block.number, 3);
 	}