Replace "coin" with "network"

The Processor's coins folder referred to the networks it could process, as did
its Coin trait. This, and other similar cases throughout the codebase, have now
been corrected.

Also corrects dated documentation for a key pair is confirmed under the
validator-sets pallet.

coordinator/src/main.rs

@@ -398,7 +398,7 @@ pub async fn handle_processors<D: Db, Pro: Processors, P: P2p>(
         key_gen::ProcessorMessage::Shares { id, shares } => {
           Some(Transaction::DkgShares(id.attempt, shares, Transaction::empty_signed()))
         }
-        key_gen::ProcessorMessage::GeneratedKeyPair { id, substrate_key, coin_key } => {
+        key_gen::ProcessorMessage::GeneratedKeyPair { id, substrate_key, network_key } => {
           assert_eq!(
             id.set.network, msg.network,
             "processor claimed to be a different network than it was for GeneratedKeyPair",
@@ -411,7 +411,7 @@ pub async fn handle_processors<D: Db, Pro: Processors, P: P2p>(
             id.set.network,
             (
               Public(substrate_key),
-              coin_key
+              network_key
                 .try_into()
                 .expect("external key from processor exceeded max external key length"),
             ),

coordinator/src/substrate/mod.rs

@@ -102,7 +102,7 @@ async fn handle_key_gen<D: Db, Pro: Processors>(
           processor_messages::substrate::CoordinatorMessage::ConfirmKeyPair {
             context: SubstrateContext {
               serai_time: block.time().unwrap(),
-              coin_latest_finalized_block: serai
+              network_latest_finalized_block: serai
                 .get_latest_block_for_network(block.hash(), set.network)
                 .await?
                 // The processor treats this as a magic value which will cause it to find a network
@@ -176,7 +176,7 @@ async fn handle_batch_and_burns<Pro: Processors>(
   assert_eq!(HashSet::<&_>::from_iter(networks_with_event.iter()).len(), networks_with_event.len());
 
   for network in networks_with_event {
-    let coin_latest_finalized_block = if let Some(block) = batch_block.remove(&network) {
+    let network_latest_finalized_block = if let Some(block) = batch_block.remove(&network) {
       block
     } else {
       // If it's had a batch or a burn, it must have had a block acknowledged
@@ -194,7 +194,7 @@ async fn handle_batch_and_burns<Pro: Processors>(
           processor_messages::substrate::CoordinatorMessage::SubstrateBlock {
             context: SubstrateContext {
               serai_time: block.time().unwrap(),
-              coin_latest_finalized_block,
+              network_latest_finalized_block,
             },
             network,
             block: block.number(),

docs/integrations/Instructions.md

@@ -8,7 +8,7 @@ encoded into transactions on connected networks. Serai will parse included
 instructions when it receives coins, executing the included specs.
 
   - Out Instructions detail how to transfer coins, either to a Serai address or
-an address native to the coin in question.
+an address native to the network of the coins in question.
 
 A transaction containing an In Instruction and an Out Instruction (to a native
 address) will receive coins to Serai and send coins from Serai, without

docs/protocol/Constants.md

@@ -15,6 +15,7 @@ protocol.
 | Session         | u32                                          |
 | Validator Set   | (Session, NetworkId)                         |
 | Key             | BoundedVec\<u8, 96>                          |
+| KeyPair         | (SeraiAddress, Key)                          |
 | ExternalAddress | BoundedVec\<u8, 128>                         |
 | Data            | BoundedVec\<u8, 512>                         |
 

docs/protocol/Validator Sets.md

@@ -30,19 +30,16 @@ reject newly added coins which would cross that threshold.
 Multisigs are created by processors, communicating via their Coordinators.
 They're then confirmed on chain via the `validator-sets` pallet. This is done by
 having 100% of participants agree on the resulting group key. While this isn't
-fault tolerant, a malicious actor who forces a `t`-of-`n` multisig to be
-`t`-of-`n-1` reduces the fault tolerance of the multisig which is a greater
-issue. If a node does prevent multisig creation, other validators should issue
-slashes for it/remove it from the Validator Set entirely.
+fault tolerant regarding liveliness, a malicious actor who forces a `t`-of-`n`
+multisig to be `t`-of-`n-1` reduces the fault tolerance of the created multisig
+which is a greater issue. If a node does prevent multisig creation, other
+validators should issue slashes for it/remove it from the Validator Set
+entirely.
 
-Due to the fact multiple key generations may occur to account for
-faulty/malicious nodes, voting on multiple keys for a single coin is allowed,
-with the first key to be confirmed becoming the key for that coin.
-
-Placing it on chain also solves the question of if the multisig was successfully
-created or not. Processors cannot simply ask each other if they succeeded
-without creating an instance of the Byzantine Generals Problem. Placing results
-within a Byzantine Fault Tolerant system resolves this.
+Placing the creation on chain also solves the question of if the multisig was
+successfully created or not. Processors cannot simply ask each other if they
+succeeded without creating an instance of the Byzantine Generals Problem.
+Placing results within a Byzantine Fault Tolerant system resolves this.
 
 ### Multisig Lifetime
 
@@ -61,9 +58,11 @@ no longer eligible to receive coins and they forward all of their coins to the
 new set of keys. It is only then that validators in the previous instance of the
 set, yet not the current instance, may unbond their stake.
 
-### Vote (message)
+### Set Keys (message)
 
-  - `coin` (Coin): Coin whose key is being voted for.
-  - `key`  (Key):  Key being voted on.
+  - `network`   (Network):   Network whose key is being voted for.
+  - `key_pair`  (KeyPair):   Key pair being set for this `Session`.
+  - `signature` (Signature): A MuSig-style signature of all validators,
+confirming this key.
 
 Once a key is voted on by every member, it's adopted as detailed above.

processor/messages/src/lib.rs

@@ -14,7 +14,7 @@ use validator_sets_primitives::{ValidatorSet, KeyPair};
 #[derive(Clone, Copy, PartialEq, Eq, Debug, Zeroize, Serialize, Deserialize)]
 pub struct SubstrateContext {
   pub serai_time: u64,
-  pub coin_latest_finalized_block: BlockHash,
+  pub network_latest_finalized_block: BlockHash,
 }
 
 pub mod key_gen {
@@ -50,7 +50,7 @@ pub mod key_gen {
     // Created shares for the specified key generation protocol.
     Shares { id: KeyGenId, shares: HashMap<Participant, Vec<u8>> },
     // Resulting keys from the specified key generation protocol.
-    GeneratedKeyPair { id: KeyGenId, substrate_key: [u8; 32], coin_key: Vec<u8> },
+    GeneratedKeyPair { id: KeyGenId, substrate_key: [u8; 32], network_key: Vec<u8> },
   }
 }
 
@@ -165,7 +165,7 @@ pub mod substrate {
         CoordinatorMessage::ConfirmKeyPair { context, .. } => context,
         CoordinatorMessage::SubstrateBlock { context, .. } => context,
       };
-      Some(context.coin_latest_finalized_block)
+      Some(context.network_latest_finalized_block)
     }
   }
 
@@ -263,7 +263,7 @@ impl CoordinatorMessage {
       }
       CoordinatorMessage::Sign(msg) => {
         let (sub, id) = match msg {
-          // Unique since SignId includes a hash of the coin, and specific transaction info
+          // Unique since SignId includes a hash of the network, and specific transaction info
           sign::CoordinatorMessage::Preprocesses { id, .. } => (0, bincode::serialize(id).unwrap()),
           sign::CoordinatorMessage::Shares { id, .. } => (1, bincode::serialize(id).unwrap()),
           sign::CoordinatorMessage::Reattempt { id } => (2, bincode::serialize(id).unwrap()),

processor/src/additional_key.rs

@@ -1,14 +1,14 @@
 use ciphersuite::Ciphersuite;
 
-use crate::coins::Coin;
+use crate::networks::Network;
 
 // Generate a static additional key for a given chain in a globally consistent manner
 // Doesn't consider the current group key to increase the simplicity of verifying Serai's status
 // Takes an index, k, to support protocols which use multiple secondary keys
 // Presumably a view key
-pub fn additional_key<C: Coin>(k: u64) -> <C::Curve as Ciphersuite>::F {
-  <C::Curve as Ciphersuite>::hash_to_F(
+pub fn additional_key<N: Network>(k: u64) -> <N::Curve as Ciphersuite>::F {
+  <N::Curve as Ciphersuite>::hash_to_F(
     b"Serai DEX Additional Key",
-    &[C::ID.as_bytes(), &k.to_le_bytes()].concat(),
+    &[N::ID.as_bytes(), &k.to_le_bytes()].concat(),
   )
 }

processor/src/db.rs

@@ -2,11 +2,11 @@ use core::marker::PhantomData;
 
 pub use serai_db::*;
 
-use crate::{Plan, coins::Coin};
+use crate::{Plan, networks::Network};
 
 #[derive(Debug)]
-pub struct MainDb<C: Coin, D: Db>(D, PhantomData<C>);
-impl<C: Coin, D: Db> MainDb<C, D> {
+pub struct MainDb<N: Network, D: Db>(D, PhantomData<N>);
+impl<N: Network, D: Db> MainDb<N, D> {
   pub fn new(db: D) -> Self {
     Self(db, PhantomData)
   }
@@ -31,7 +31,7 @@ impl<C: Coin, D: Db> MainDb<C, D> {
   fn signing_key(key: &[u8]) -> Vec<u8> {
     Self::main_key(b"signing", key)
   }
-  pub fn save_signing(txn: &mut D::Transaction<'_>, key: &[u8], block_number: u64, plan: &Plan<C>) {
+  pub fn save_signing(txn: &mut D::Transaction<'_>, key: &[u8], block_number: u64, plan: &Plan<N>) {
     let id = plan.id();
 
     {
@@ -56,7 +56,7 @@ impl<C: Coin, D: Db> MainDb<C, D> {
     }
   }
 
-  pub fn signing(&self, key: &[u8]) -> Vec<(u64, Plan<C>)> {
+  pub fn signing(&self, key: &[u8]) -> Vec<(u64, Plan<N>)> {
     let signing = self.0.get(Self::signing_key(key)).unwrap_or(vec![]);
     let mut res = vec![];
 
@@ -66,7 +66,7 @@ impl<C: Coin, D: Db> MainDb<C, D> {
       let buf = self.0.get(Self::plan_key(id)).unwrap();
 
       let block_number = u64::from_le_bytes(buf[.. 8].try_into().unwrap());
-      let plan = Plan::<C>::read::<&[u8]>(&mut &buf[16 ..]).unwrap();
+      let plan = Plan::<N>::read::<&[u8]>(&mut &buf[16 ..]).unwrap();
       assert_eq!(id, &plan.id());
       res.push((block_number, plan));
     }