merging with develop changes

chain-signatures/README.md → API.md

@@ -54,9 +54,5 @@ pub fn experimantal_signature_deposit(&self) -> u128
 For more details check `User contract API` impl block in the [chain-signatures/contracts/src/lib.rs](./chain-signatures/contracts/src/lib.rs) file.
 
 # Environments
-Currently, we have 3 environments:
 1. Mainnet: `v1.signer`
-2. Testnet: `v1.sigenr-prod.testnet`
-3. Dev (unstable): `v1.signer-dev.testnet`
-
-Contracts can be changed from v1 to v2, etc. Older contracts should continue functioning.
+2. Testnet: `v1.sigenr-prod.testnet`

ARCHITECTURE.md

@@ -1,15 +1,5 @@
 # Architecture
 
-This doc outlines the architecture for NEAR's Multi-Party Computation (MPC) related services which powers FastAuth and Chain Signatures.
-
-## FastAuth (aka mpc-recovery)
-
-FastAuth allows a user to store their login details for their NEAR wallet in a set amount of MPC nodes. Each node contains a share of the user's credentials. Note, this will likely change in the future as we resdesign the system to utilize chain signatures instead of having to purely rely on a standalone MPC service for NEAR accounts.
-
-## Chain Signatures
-
-Chain signature is an MPC service that facilitates the ability to sign arbitrary payloads by calling into a smart contract and eventually getting back a signature. This signature can be used for various purposes such as deriving new public keys associated to foreign chains.
-
 There are several components that make up chain-signatures. This includes but is not limited to the following:
 
 - NEAR Smart Contract

README.md

@@ -1,19 +1,11 @@
-# NEAR MPC
-
-This repo hosts all the code for MPC related services on NEAR, which includes but is not limited to FastAuth and Chain Signatures.
-
-
 ## Chain Signatures
 
-An MPC service that generates signatures based on a payload. These are a set of N nodes operating as a sort of L2 (maybe L0) where users (developers or clients) can talk to a smart contract on NEAR to generate a signature. This signature can then be used for multiple purposes such as managing an account located on a foreign chain (BTC, ETH, ...)
-
-Most of this code is located in `chain-signatures/` folder and for more information on how most of this work or its design, refer to [ARCHITECTURE.md](ARCHITECTURE.md).
-
-## FastAuth (aka MPC recovery)
-
-An MPC service that allows users to create NEAR accounts based on an identity provider. The secret key belonging to these accounts are stored partially on an MPC node, where the full key is never recreated. For more info on, look at the [mpc-recovery/README.md](mpc-recovery/README.md)
+Chain signatures is an MPC service that facilitates the ability to sign arbitrary payloads by calling into a smart contract and eventually getting back a signature. This signature can be used for various purposes such as deriving new public keys associated to foreign chains (Ethereum, Bitcoin, etc.).
 
-## Notes
+### More inforamtion:
+- [API](API.md)
+- [Roadmap](ROADMAP.md)
+- [Architecure](ARCHITECTURE.md)
+- [Scaling and Security](SCALING_AND_SECURITY.md)
 
-- Not to be confused, but FastAuth and Chain Signatures are separate services. This can change in the future but they remain separate for now.
-- FastAuth also has an equivalent [UI repo](https://github.com/near/fast-auth-signer) which is used in [near.org](near.org)
+If you are looking for FastAuth project, please check the [mpc-recovery](/mpc-recovery) folder.

ROADMAP.md

@@ -0,0 +1,17 @@
+## Roadmap
+### Q4 2024
+- Scale system to 10 nodes (12 on testnet)
+- Chain Signatures on Ethereum testnet
+- Publish Triple Security Proof
+- Publish ECDSA Signature Security Proof
+
+### Q1 2025
+- Chain Signatures on Ethereum mainnet
+- Tooling for NEAR <-> Ethereum smart contract interactions
+- EDDSA signatures support
+- Scaling of signature production
+- Formalize state and message passing w proofs
+
+### Q2 2025
+- Deploy Chain Signatures on 6+ networks on Testnet
+- Release a tooling that allows a NEAR smart contract to call smart contracts on these networks

SCALING_AND_SECURITY.md

@@ -0,0 +1,5 @@
+## Scaling capabilities
+Currently chain signatures operates using one signature genertion network and can handle up to 8 concurent requests. Average response time is 15 seconds. We are planning to improve both metrics and scale the system to multiple networks wich will allow to handle more requests and reduce response time.
+
+## Security properties
+Chain signatures is usign cait-sith threshold ECDSA protocol. Currently our network consist of 8 nodes with treshold 5. This means that at least 5 nodes must collaborate in order to create a valid signature.

chain-signatures/node/src/cli.rs

@@ -8,6 +8,7 @@ use local_ip_address::local_ip;
 use near_account_id::AccountId;
 use near_crypto::{InMemorySigner, SecretKey};
 use std::sync::Arc;
+use std::time::Duration;
 use tokio::sync::{mpsc, RwLock};
 use tracing_stackdriver::layer as stackdriver_layer;
 use tracing_subscriber::{layer::SubscriberExt, EnvFilter, Registry};
@@ -135,6 +136,7 @@ fn is_running_on_gcp() -> bool {
     let resp = reqwest::blocking::Client::new()
         .get("http://metadata.google.internal/computeMetadata/v1/instance/id")
         .header("Metadata-Flavor", "Google")
+        .timeout(Duration::from_secs(1))
         .send();
 
     match resp {

chain-signatures/node/src/http_client.rs

@@ -46,6 +46,7 @@ async fn send_encrypted<U: IntoUrl>(
             .post(url.clone())
             .header("content-type", "application/json")
             .json(&message)
+            .timeout(Duration::from_secs(2))
             .send()
             .await
             .map_err(SendError::ReqwestClientError)?;

chain-signatures/node/src/mesh/connection.rs

@@ -49,7 +49,13 @@ impl Pool {
                 continue;
             };
 
-            let Ok(resp) = self.http.get(url.clone()).send().await else {
+            let Ok(resp) = self
+                .http
+                .get(url.clone())
+                .timeout(Duration::from_secs(1))
+                .send()
+                .await
+            else {
                 tracing::warn!(
                     "Pool.ping resp err participant {:?} url {}",
                     participant,
@@ -93,7 +99,13 @@ impl Pool {
                 continue;
             };
 
-            let Ok(resp) = self.http.get(url).send().await else {
+            let Ok(resp) = self
+                .http
+                .get(url)
+                .timeout(Duration::from_secs(1))
+                .send()
+                .await
+            else {
                 continue;
             };
 

chain-signatures/node/src/metrics.rs

@@ -448,6 +448,15 @@ pub(crate) static SIGNATURE_PUBLISH_RESPONSE_ERRORS: Lazy<CounterVec> = Lazy::ne
     .unwrap()
 });
 
+pub(crate) static PROTOCOL_ITER_CNT: Lazy<CounterVec> = Lazy::new(|| {
+    try_create_counter_vec(
+        "multichain_protocol_iter_count",
+        "Count of multichain protocol iter",
+        &["node_account_id"],
+    )
+    .unwrap()
+});
+
 pub fn try_create_int_gauge_vec(name: &str, help: &str, labels: &[&str]) -> Result<IntGaugeVec> {
     check_metric_multichain_prefix(name)?;
     let opts = Opts::new(name, help);

mpc-recovery/README.md

@@ -1,4 +1,7 @@
-# MPC Account Recovery (WIP)
+## FastAuth (aka mpc-recovery)
+
+FastAuth allows a user to store their login details for their NEAR wallet in a set amount of MPC nodes. Each node contains a share of the user's credentials. Note, this will likely change in the future as we resdesign the system to utilize chain signatures instead of having to purely rely on a standalone MPC service for NEAR accounts.
+
 The aim of this project is to offer NEAR users the opportunity to create and restore their accounts by utilizing OIDC protocol. By linking their NEAR account to `near.org` or other authentication provider, they can then add a new Full Access key, which will be managed by the trusted network of servers. Should they lose all the keys they possess, they can reauthorize themselves, create a new key, and add it into their NEAR account using a transaction that will be signed by MPC servers through their recovery key. All the transaction cost will be covered by a relayer server and metatransactions.
 
 ## How the MPC system will work