# Distributed transaction signing
*by Alexander Lednev, October 2024
Email: [e-mail]
Telegram: @iceseer*

## Abstract
The solution provides the ability to securely verify and approve or reject a transaction before it is executed. At its core, it uses the idea of securing the signature of each transaction, rather than the private key. Thus, there is no need to access the private key and transaction can be signed offline. The design of the system and protocol minimizes the attack surface and makes hacking attempts extremely costly by reducing the reward, as the outcome of a successful attack would be a signature for a single transaction. Additionally, a recipient address substitution attack is made impossible, as the signature is already formed at the verification stage, and any address substitution would invalidate it. This solution is not tied to specific systems and can provide an additional layer of security for any systems that use verification of certain data, such as signatures, enabling easy scalability and integration of new external systems.

## Distributed transaction execution services (DTES)
The DTES system consists of 5 types of services and applications, each performing its own role and being responsible for its outcome.


### Initiator
The task of this module is to provide complete input data and the profile identifier for processing (**EP**) of these data. EP is a set of configurations and instructions on how the data should be received, processed, and executed.

### Gate
This module contains the EP settings and performs the initial preparation of the input data received from the *initiator*. For example, it prepares the binary data of a transaction that will be executed on the blockchain, but does not sign it. Depending on the specific EP, the data may be sent to the signing module (in the case of the *pre-sign* mode) or directly to the distribution module (in the case of *post-sign* mode). The connection between the *gate* and the *signing* module, as well as between the *gate* and the *distribution* module, is secured.

### Signer
The module responsible for signing. This module is abstract in the general sense. It is external to DTES, and its placement is assumed to be with the system user. The task of the module is to provide a signature with a specified key for the input data. The implementation of the module depends on the user's security requirements and may include, for example, different methods of key storage (HSM, Vault), as well as an additional layer of distributed key storage.

### Approvers
Participants in the network whose task is to confirm the correctness of the transaction they wish to execute and to make a decision on each transaction individually: approve or reject. All approvers are divided into $primary$ and $secondary$. The role of each approver is fixed in the EP.
- **Primary Approver.** For the transaction to be executed, positive votes from all primary approvers are **required**. Rejecting the transaction or the absence of a vote from such an approver prevents its execution.
- **Secondary Approver.** For the transaction to be executed, positive votes from secondary approvers are required, in a quantity no less than *quorum* ($k$).

### Distributed Transaction Executor(DTE)
The task of this module is to transform the data and distribute it among the approvers according to the profile settings in such a way that:
1. The absence of at least one vote from the $primaries$ makes data recovery impossible and provides no information about the data.
2. The presence of votes from $secondaries < k$ makes data recovery impossible and provides no information about the data.
3. The presence of all $primary$ votes and $secondary votes >= k$ allows full recovery of the original data.

To solve this task, **Shamir's Secret Sharing** is used.

## Basics

### Shamir's secret sharing

Shamir's Secret Sharing is an algorithm used to split a secret into several parts, such that only a specific minimum number of parts are needed to reconstruct the secret. This method was proposed by Israeli cryptographer Adi Shamir in 1979 and is one of the foundational techniques in secret sharing.

The core idea of Shamir's scheme is based on polynomials. Let's break down how this works step by step.

#### 1. Problem Formulation

Suppose we have a secret $S$ that we want to split into $n$ parts. In order to reconstruct the secret, a minimum of $k$ parts (out of the $n$) are required. These parts are called *shares*.

#### 2. The Basic Idea

The secret $S$ is represented as a value in some mathematical structure, such as a finite field $GF(p)$, where $p$ is a prime number, and all computations are performed modulo $p$. Then, the secret is hidden within a polynomial, and its values are computed at various points, forming the shares.

#### 3. Creating the Polynomial

1. We choose the degree of the polynomial to be $k-1$, where $k$ is the minimum number of shares required to reconstruct the secret.
2. The constant (or free term) of this polynomial will be the secret $S$.
3. We then construct the polynomial $f(x)$ of degree $k-1$, which will be:
$$
f(x) = S + a_1 x + a_2 x^2 + \dots + a_{k-1} x^{k-1}
$$
where $a_1, a_2, \dots, a_{k-1}$ are random coefficients chosen from the field $GF(p)$. These coefficients should remain unknown to prevent anyone, except those who possess enough shares, from reconstructing the secret.

#### 4. Generating the Shares

Each share is a point on the graph of this polynomial. To generate a share, we substitute values $x$ (where $x$ are unique identifiers for each share) into the polynomial. That is, the shares are:
$$
(x_1, f(x_1)), (x_2, f(x_2)), \dots, (x_n, f(x_n))
$$
where $x_1, x_2, \dots, x_n$ are distinct values of $x$, chosen beforehand (they should not repeat). These shares are then distributed to the participants.

#### 5. Reconstructing the Secret

To reconstruct the secret, at least $k$ shares are required. To reconstruct the polynomial, we use **Lagrange interpolation**. Lagrange interpolation allows us to reconstruct the polynomial from any $k$ points (where we know both the $x$-coordinates and $f(x)$-coordinates) and, in particular, recover the secret by finding the constant term $f(0) = S$.

#### 6. Lagrange Interpolation

The interpolation process using Lagrange polynomials can be written as:
$$
f(x) = \sum_{i=1}^{k} f(x_i) \cdot L_i(x)
$$
where $L_i(x)$ are the **Lagrange basis polynomials**, defined as:
$$
L_i(x) = \prod_{\substack{1 \leq j \leq k \\ j \neq i}} \frac{x - x_j}{x_i - x_j}
$$
To recover the secret, we simply evaluate $f(0)$, which will be the secret $S$:
$$
f(0) = \sum_{i=1}^{k} f(x_i) \cdot L_i(0)
$$

#### 7. Security

The key feature of Shamir's scheme is its security. Without having at least $k$ shares, it is impossible to reconstruct the secret. For example, if an adversary only has $k-1$ shares, they cannot gain any information about the secret, because there are infinitely many polynomials that can pass through these $k-1$ points, and only by adding the $k$-th share can the secret be uniquely determined.

### SR25519 signature

**SR25519** is a modern cryptographic signature algorithm based on elliptic curves that provides both security and efficiency, making it particularly well-suited for use in blockchain protocols. It was designed to improve upon other existing algorithms (such as Ed25519) by incorporating optimizations that enhance performance and security in certain contexts. SR25519 is widely used in blockchain platforms like **Polkadot** and other systems that rely on the **Substrate** framework.

#### 1. Key Characteristics and Features of SR25519

1. **Elliptic Curve Based**:
- **SR25519** uses the **Curve25519** elliptic curve, which is a widely used curve in cryptography for creating fast and secure cryptographic algorithms.
- **Curve25519** was chosen for its resistance to vulnerabilities common in other elliptic curves (e.g., the **secp256k1** curve used in Bitcoin).

2. **Signature Algorithm**:
- SR25519 utilizes the **Schnorr signature** scheme, which is known for its security, efficiency, and mathematical properties.
- While **Ed25519** (another popular elliptic curve-based algorithm) uses **EdDSA (Edwards-curve Digital Signature Algorithm)**, SR25519 uses **Schnorr** signatures, which offer stronger security guarantees in certain scenarios, especially for blockchain use.

3. **Zero-Knowledge Proof (ZKP) Protocol**:
- The **Schnorr signature** scheme, upon which SR25519 is based, is a **zero-knowledge proof protocol**, meaning that the signer can prove their ability to sign a message without revealing the private key itself.
- This is particularly useful for ensuring privacy and security because it allows one to verify the authenticity of a signature without exposing sensitive key data.

4. **Performance Optimized**:
- SR25519 is optimized for **high-performance cryptographic operations**, particularly suited for environments like blockchain platforms where quick transaction validation and signature generation are critical.
- The algorithm is specifically designed for the **Polkadot** ecosystem and other blockchain systems built with the **Substrate framework**, where both speed and security are important.

5. **Quantum Resistance**:
- Unlike some older signature schemes like **RSA** or **ECDSA**, which are vulnerable to attacks from quantum computers, **Schnorr-based** algorithms (such as SR25519) are considered more resistant to quantum computing threats, though they are not entirely quantum-resistant.

6. **Reliability**:
- **SR25519** was designed with a focus on **security** and **reliability**. It has undergone extensive cryptographic analysis, ensuring it is resistant to various attacks, including those targeting the underlying elliptic curve or signature generation.

7. **Keys and Signatures**:
- **Private Key**: The private key is a 32-byte random number used to sign messages.
- **Public Key**: The public key is derived from the private key and is also 32 bytes in size.
- **Signature**: The signature is 64 bytes long and is generated using the private key and the message being signed.

8. **Blockchain Use**:
- **SR25519** is primarily used in **Polkadot**, **Kusama**, and other blockchain systems that leverage the **Substrate framework** for creating decentralized applications.
- In these systems, SR25519 is used to sign and verify transactions, messages, and other data within the blockchain network.

#### 2. Schnorr Signature Scheme

The Schnorr signature scheme is based on using **elliptic curves** or **groups with well-studied mathematical properties**. At its core, the scheme relies on the **discrete logarithm problem**, which is a difficult problem in cryptography.

##### Key Steps in the Schnorr Signature Scheme

1. **Key Generation**:
- The secret key $x$ is chosen randomly from the set of integers less than the order of the group $q$.
- The public key $y$ is computed as $y = g^x \mod p$, where $g$ is a generator of the group, $p$ is a prime number, and $x$ is the secret key.

2. **Signing Process**:
To sign a message $m$, the following steps are performed:

- Generate a random number $k$, chosen randomly.
- Compute the value $r = g^k \mod p$, where $g$ is the generator of the group.
- Compute the hash $e = H(r \parallel m)$, where $H$ is a cryptographic hash function, and $r \parallel m$ is the concatenation of $r$ and the message $m$.
- The signature consists of the pair $(r, s)$, where:
$$
s = k - x \cdot e \mod (p-1)
$$
Here, $r$ and $s$ are the signature values.

3. **Signature Verification**:
To verify the signature $(r, s)$ for the message $m$, the following steps are performed:

- Compute the hash $e = H(r \parallel m)$.
- Check the condition:
$$
g^s \cdot y^e \stackrel{?}{=} r
$$
If the condition holds, the signature is valid; otherwise, it is forged.

4. **Aggregation of Signatures**:
To combine $n$ signatures, we aggregate all the values $r_i$ and $s_i$ as follows:
- $R_{\text{agg}} = \prod_{i=1}^{n} r_i \mod p$ — aggregation of all intermediate values $r_i$,
- $S_{\text{agg}} = \sum_{i=1}^{n} s_i \mod (p - 1)$ — aggregation of all responses $s_i$.

As a result, the aggregated signature consists of two values:
- $R_{\text{agg}}$,
- $S_{\text{agg}}$.

5. **Verification of Aggregated Signature**:
To verify the aggregated signature, we check the condition using the combined values $R_{\text{agg}}$ and $S_{\text{agg}}$:
$$
g^{S_{\text{agg}}} \cdot y^{T_{\text{agg}}} \stackrel{?}{=} T_{\text{agg}} \cdot g^{H(m)} \mod p,
$$
where $y$ is the public key of each signer, and $H(m)$ is the hash of the signed message.

If the condition holds, the aggregated signature is valid.

### Elliptic Curve Diffie-Hellman (ECDH)

**ECDH** is a cryptographic key exchange protocol that uses the mathematical properties of **elliptic curves** to securely establish a shared secret between two parties over an insecure channel. It is an extension of the classic **Diffie-Hellman key exchange**, but instead of using modular exponentiation, it operates over elliptic curves, making it more efficient and secure.

#### 1. Choosing Elliptic Curve Parameters
- Both parties must agree on the elliptic curve **$E$**, the finite field **$p$** over which the curve is defined, and a **base point** $G$, which is a publicly known generator of a subgroup of the elliptic curve.
- The curve parameters must be **secure** and conform to cryptographic standards (e.g., **NIST P-256, Curve25519**).

#### 2. Key Generation
Each party generates a pair of cryptographic keys:

- **Private Key**: A random integer $x_A$ chosen from $[1, n-1]$, where $n$ is the order of the base point $G$.
- **Public Key**: A point on the elliptic curve, computed as:
$$
P_A = x_A \cdot G
$$
Here, $\cdot$ represents **scalar multiplication** on the elliptic curve.

Similarly, the other party generates:
- **Private Key**: $x_B$
- **Public Key**: $P_B = x_B \cdot G$

#### 3. Public Key Exchange
Each party sends its public key over the insecure channel:
- Party $A$ sends $P_A$ to Party $B$.
- Party $B$ sends $P_B$ to Party $A$.

#### 4. Shared Secret Computation
After receiving the public key of the other party, each participant computes the shared secret:

- **Party $A$ computes**:
$$
S_A = x_A \cdot P_B
$$
- **Party $B$ computes**:
$$
S_B = x_B \cdot P_A
$$

Since scalar multiplication is associative, both computations yield the same shared secret:

$$
S_A = x_A \cdot (x_B \cdot G) = (x_A \cdot x_B) \cdot G
$$

$$
S_B = x_B \cdot (x_A \cdot G) = (x_B \cdot x_A) \cdot G
$$

Thus, both parties derive the same **shared secret**, which is a point on the elliptic curve.

#### 5. Key Derivation
The shared secret $S$ is typically **not** used directly as an encryption key. Instead, a **key derivation function (KDF)** (e.g., **HKDF, SHA-256**) is applied to derive a symmetric key suitable for encryption (e.g., **AES**).

### BLAKE2 Cryptographic Hash Function

**BLAKE2** is a cryptographic hash function designed to be faster than MD5 and SHA-2 while maintaining a high level of security. It was developed as an improvement to the original **BLAKE** function, which was a finalist in the **SHA-3 competition**. BLAKE2 offers high-speed hashing and cryptographic security, making it a suitable choice for various applications.

BLAKE2 has two main variants:
- **BLAKE2b** (optimized for 64-bit platforms)
- **BLAKE2s** (optimized for 32-bit platforms)

##### **Mathematics Behind BLAKE2**

The BLAKE2 function is built on concepts from the **Merkle-Damgård** construction and uses a **Feistel network** structure, where multiple rounds of transformation are applied to the input data to create a final hash.

##### **Key Structure of BLAKE2**

1. **Initialization**:
BLAKE2 uses an initialization vector (IV), which is a fixed set of values that define the initial state of the hash function.

- For **BLAKE2b**: There are 8 initialization words (64-bit each).
- For **BLAKE2s**: There are 12 initialization words (32-bit each).

These values are predefined constants, chosen to provide strong cryptographic security.

2. **Message Block Processing**:
The input message is broken into fixed-length blocks (512 bits for BLAKE2b and 256 bits for BLAKE2s). If the message length is not a multiple of the block size, padding is applied.

3. **Round Transformations**:
Each block is processed through several rounds of transformations. These rounds use a **Feistel network** structure, where input data is manipulated using a series of bitwise operations, additions, and shifts. One key operation in the round is the **G function**, which takes four words and applies a combination of XOR, addition modulo, and bit-shifting operations.

4. **The Core Operation: The G Function**:
The G function is the core transformation applied in each round of the hash function. It processes four 64-bit or 32-bit words, denoted as $a$, $b$, $c$, and $d$, performing the following operations:

- **Addition**:
$$
a = (a + b + m_i) \mod 2^{64}
$$
where $m_i$ is a message word.

- **XOR**:
$$
d = d \oplus a
$$

- **Rotation** (bit shifts):
$$
d = (d \gg r) \mod 2^{64}
$$
where $r$ is a fixed rotation parameter.

- The transformations are applied to the words $a$, $b$, $c$, and $d$ in multiple rounds, ensuring the mixing of the data and producing a strong cryptographic effect.

5. **State Update**:
After each round, the internal state is updated, and the output of one round serves as the input for the next. This iterative process continues until all blocks are processed.

6. **Final Hash Output**:
After all message blocks have been processed, the final state is used to produce the hash output. The length of the hash depends on the variant:

- For **BLAKE2b**, the hash is 512 bits long.
- For **BLAKE2s**, the hash is 256 bits long.

The output of the final state is the cryptographic hash of the message.

##### **Advantages of BLAKE2**

1. **High Speed**:
BLAKE2 is much faster than older hash functions like **SHA-3**, especially on 64-bit systems. This speed makes it ideal for applications that require high throughput.

2. **Security**:
BLAKE2 offers a high level of cryptographic security, comparable to or better than SHA-2. It is resistant to various types of cryptographic attacks, including **collision resistance** and **pre-image resistance**.

3. **Flexibility**:
The algorithm supports variable output lengths (up to 512 bits), making it adaptable to different use cases.

4. **Simplicity**:
The design of BLAKE2 is simple and avoids unnecessary complexity, making it easy to implement and less prone to implementation errors.

5. **Resistant to Attacks**:
BLAKE2 has been designed with resistance to cryptanalytic attacks in mind. Its structure is robust against common attacks such as **birthday attacks** and **collision attacks**.

## DTES protocol
The protocol is designed in such a way that at each stage it includes data verification and the possibility of its execution. It is assumed that the data is transmitted over an open channel, so the encryption of critical data is provided within the protocol itself and does not require the use of TLS.

To explain the protocol, we introduce additional conditions:
1. The *initiator*, *gate*, *DTES*, and each of the *approvers* has its own pair of **sr25519** keys, which they use to sign outgoing requests.
2. The *signer*, *gate*, and *DTES* maintain a whitelist of **sr25519** public keys from which requests are allowed to be executed. Requests signed with keys not on the list are ignored.
3. *signer* and *DTES* each have ephimeral keypair for ECDH protocol.

Each approver has its own key pair
$$
(\text{PK}_{A_i}, \text{SK}_{A_i})
$$
where $\text{PK}_{A_i}$ is the public key of approver $A_i$,
and $\text{SK}_{A_i}$ is the private key of approver $A_i$.

All key pairs of approvers form the set of approvers' keys.

$$
\text{PK}_{A} = \bigcup_{i} \text{PK}_{A_i}
$$
$$
\text{SK}_{A} = \bigcup_{i} \text{SK}_{A_i}
$$
such that $\text{PK}_{A_i} \leftrightarrow \text{SK}_{A_i}$.

Let us define the set of keys of *primary* approvers as:

$$
\text{PRI} = \bigcup_{j} \text{PK}_{A_j}
$$

where $j \leq i$ and $\text{PRI} \subseteq \text{PK}_A$.

Similarly, for the set of keys of *secondary* approvers, we define:

$$
\text{SEC} = \bigcup_{j} \text{PK}_{A_j}
$$

where $j \leq i$ and $\text{SEC} \subseteq \text{PK}_A$.

It is important to note that the keys should not overlap:

$$
\text{PRI} \cap \text{SEC} = \varnothing
$$

Next, we introduce the concept of a profile set $E$ consisting of $n$ elements:

$$
\{E_0, E_1, \dots, E_{n-1} | E_i \in E\}
$$

where $E$ is the set of all profiles, and $E_i$ is the $i$-th profile such that:

$$
E_i \to (N, \text{PRI}_i, \text{SEC}_i, Q)
$$

where $N$ is the identifier of the output network, $Q$ is the quorum for *secondary* approvers.

### Initiator
The task of the initiator is to provide the system with the complete input data for executing the transaction, including the **EP** specification. Thus, the initiator creates the message:

$$
T = (\text{from}, \text{to}, \text{amount}, \text{token}, \text{created})
$$

$$
M = (T, E_i)
$$
where $\text{from}$ - sender's address,
$\text{to}$ - recipient's address,
$\text{amount}$ - the number of tokens to be transfered,
$\text{token}$ - the token identifier,
$\text{created}$ - UTC timestamp of transaction creation(ms),
$E_i$ - **EP** identifier.

Signs it **blake2b** hash:
$$h=H(M)$$
$$S_I = sign(SK_I, h)$$

where $\text{sign}$ is the *sr25519* signature function using the initiator's private key $SK_I$ for the message $M$. The resulting message $V_I$ is then transmitted as input data to the gate:

$$
V_I = (M, PK_I, S_I)
$$

### Gate
1. A large number of gates can be connected to the DTE module. Each gate is allowed to process input data from the **initiator** set, which has keys denoted as $\text{PK}_{I_i}$. To prevent a **Double Spend Attack**, the sets of keys that the gates operate with must not intersect with each other:
$$
\forall i, j \in \{1, 2, \dots, n\}, \, i \neq j \Rightarrow \text{PK}_{I_i} \cap \text{PK}_{I_j} = \varnothing
$$
2. Each *Tx* contains a *created* timestamp. Let’s define the transaction’s time-to-live (TTL) as $T_{Tx}$. Then, only transactions that satisfy the condition below can be processed:
$$
|t-\text{created}| < T_{Tx}
$$
where $t$ is the current time.
3. To prevent a **Repeat Attack**, upon receiving $V_I$, the gate should calculate the hash and store it during the transaction's lifetime, and only process unique messages:
$$
h = H(M)
$$
4. Upon receiving $V_I$, the module checks if processing messages from this initiator is allowed:
$$
\{\text{PK}_{I}\} \cap \text{PK}_{I_i} \stackrel{?}{=} \{1\}
$$

If processing is allowed, the signature is verified against the key:
$$
verify(\text{PK}_{I}, S_I, h) \stackrel{?}{=} True
$$

When all the conditions above are met, at this step we are sure that:
- The incoming transaction *Tx* was formed by a legitimate initiator;
- The *Tx* data has not been altered in any way;
- This *Tx* has not been processed by the current gate;
- This *Tx* has not been processed by any other gate;
- The *Tx* was formed within the TTL window.

From all of this, it follows that the transaction is valid and unique within the given DTES network. For further processing, the transaction needs to be signed. To do this, the message is encoded in the network format and sent to the appropriate *signer* based on $N$ in the *EP* profile:
$$
M_G = \text{encode}(N, \text{from}, \text{to}, \text{amount}, \text{token}, \text{created})
$$
$$
V_G = (M_G, E_{PK_D}, PK_G, S_G)
$$
where $E_{PK_D}$ is DTE's *ephemeral public key* for **ECDH** protocol, $PK_G$ - **sr25519** public key and $S_G$ - signature, for the message hash:
$h_{M_G}=H(M_G||E_{PK_D})$ - *blake2b* hash from $M_G$ concatenated with DTE ephemeral public DTE.

### Signer
Upon receiving $V_G$, the *signer* checks the source of this data:
1. First, it is checked that the public key is in the list of authorized keys:
$$
\{\text{PK}_{G}\} \cap \text{PK}_{G_i} \stackrel{?}{=} \{1\}
$$
2. If processing is allowed, the message's signature is verified to ensure the message has not been tampered with or altered:
$$
\text{verify}(\text{PK}_{G}, S_G, h_{M_G}) \stackrel{?}{=} \text{True}
$$

The main task of the *signer* is to generate the signature $S_{Tx}$ of the transaction *Tx*, which represents secret data that must be protected from external observers. To do this, $S_{Tx}$ is encoded according to the *ECDH* protocol:
$$
M_S = \text{encrypt}(E_{PK_D}, E_{SK_S}, S_{Tx})
$$
where $E_{SK_S}$ is the *ephemeral secret key* of the **signer**.

The encoded signature is returned to the *gate* in the form of a message:
$$
V_S = (M_S, E_{PK_S})
$$
where $E_{PK_S}$ is the *ephemeral public key* of the **signer**.

### Gate
At this stage, the signature of the response and its verification are not required, as only the *DTE*, whose key was passed in the request, can decrypt the response data. Thus, the *gate* has no access to any secret data, including the transaction signature. During the process of receiving the *ephemeral public key DTE* $E_{PK_D}$, both participants must verify each other's signatures to ensure that only the trusted module will receive the transaction signature $S_{Tx}$. It is assumed that such an exchange has occurred earlier, and the gate already knows the correct $E_{PK_D}$. The gate’s next task is to transmit the complete data for forming the distributed signature on the DTE, along with the transaction's open data:
$$
I = (T, N)
$$
where $T$ is the open data of the transaction and $N$ is the network identifier of the transaction execution.
The data required for the distribution system are taken from the *EP* profile and are as follows:
$$
R = (PRI, SEC, Q)
$$
where $PRI$ and $SEC$ are the sets of public keys of the approvers.
Thus, the message will look as follows:
$$
M_D = (I, R, V_S)
$$

That is, the full message sent to the *DTE* will be:
$$
V_D = (M_D, PK_G, S_{GD})
$$
where $S_{GD} = \text{sign}(SK_G, h_{GD})$ is the signed *blake2b* hash of the outgoing message $h_{GD} = H(M_D) = H(I || R || V_S)$.

### DTE
For convenience, let's assume that any approver is an observer from the set of approvers $A = \{ A_1, A_2, \dots, A_n \}$, possessing a key pair $(PK_{A_i}, SK_{A_i})$, and that it is NOT trustworthy. That is, we assume that data obtained from any approver $A_i$ may be compromised. However, we trust data that is signed by the correct key $SK_{A_i}$ and has passed signature verification, i.e.:
- Any approver $A_i$, upon receiving data from *DTE*, should not be able to obtain any full or partial knowledge of $S_{Tx}$;
- *DTE* must ensure that the open part of the transaction information corresponds to the closed part: $I \leftrightarrow S_{Tx}$.

Upon receiving data from the gate, DTE decrypts $S_{Tx}$, using ECDH:
$$
S_{Tx} = \text{decrypt}(E_{SK_D}, E_{PK_S}, M_S)
$$
where $E_{SK_D}$ - DTE *ephemeral sekret key*, $E_{PK_S}$ - *signer ephemeral public key*, $M_S$ - encrypted data blob.

Then DTE calculates the number of elements into which it needs to divide the input data, which we will call shares. The secret division is performed using the Shamir algorithm. Since the DTE must collect signed shares from all $A_i \in PRI$ approvers and from at least $Q$ approvers in $A_j \in SEC$, it will be considered that the $SEC$ set is necessary to obtain an additional mandatory element. Let:

- $|PRI|$ be the number of elements in the set $PRI$.
- $|SEC|$ be the number of elements in the set $SEC$.

Then, we can write the following:
$$
Q_{PRI} = \begin{cases}
|PRI|, & \text{if } |SEC| = 0 \\
|PRI| + 1, & \text{if } |SEC| \neq 0
\end{cases}
$$
where $Q_{PRI}$ is the minimum number of shares required to restore the secret data.

An additional share is data that is recoverable by the set of approvers $SEC$. That is, after applying the Shamir algorithm to $S_{Tx}$, we get a set of $Q_{PRI}$ shares:

$$
\{B_1, B_2, \dots, B_{PRI}\} = shamir(S_{Tx}, Q_{PRI}, Q_{PRI})
$$

where to restore $S_{Tx}$, $Q_{PRI}$ elements from the set are required:

$$
S_{Tx} = restore(\{B_1, B_2, \dots, B_{PRI}\})
$$

An additional share from the set is recoverable data for the set $SEC$:

$$
B_x = random(\{B_1, B_2, \dots, B_{PRI}\})
$$
where $random(\dots)$ - random function, that takes random item from a set.

$$
\{D_1, D_2, \dots, D_{SEC}\} = shamir(B_x, |SEC|, Q)
$$
where $|SEC|$ is the number of *secondary* approvers, $Q$ - is the *quorum* value neccessarry to restore the data.

By combining these expressions, we get the expression for restoring the original data:

$$
S_{Tx} = restore\left(\sum_{i=1}^{Q_{PRI}-1} B_i + restore\left(\sum_{j=1}^{Q} D_j \right)\right)
$$

Upon creating the sets $\{B_1, B_2, \dots, B_{PRI-1}\}$ and $\{D_1, D_2, \dots, D_{SEC}\}$, for each approver, a block of secret data is formed consisting of a hash of the public data and the corresponding share for that approver. The addition of the hash is necessary to ensure that the approver verifies and signs the data corresponding to $I$:

$$
M_{A_i} = \begin{cases}
(B_i, h_I), & \text{if } PK_{A_i} \in PRI \\
(D_i, h_I), & \text{if } PK_{A_i} \in SEC
\end{cases}
$$

where $PK_{A_i}$ is the public key of the $i$-th approver, and $h_I = H(I)$ is the *blake2b* hash of the public data.

Next, $M_{A_i}$ is encrypted and sent, along with $I$, to the $i$-th approver:

$$
MD_i = \text{encrypt_AES128}(M_{A_i})
$$

$$
V_{A_i} = (I, MD_i)
$$

For the approver, $MD_i$ is indistinguishable from a random byte sequence, and they do not know its contents. The approver verifies the public transaction data $I$ and signs it along with the associated private metadata:

$$
h_{A_i} = H(h_I || MD_i)
$$

$$
S_{A_i} = \text{sign}(SK_{A_i}, h_{A_i})
$$

The approver then sends the response to DTE:

$$
R_{A_i} = (MD_i, S_{A_i})
$$

Since $MD_i$ contains $h_I$ in encrypted form and DTE can retrieve it, DTE only needs to verify the signature $S_{A_i}$ to be sure that $A_i$ has verified and signed the data corresponding to the transaction $Tx$:

$$
\text{verify}(PK_{A_i}, S_{A_i}, h_{A_i})\stackrel{?}{=} True
$$

$$
\text{verify}(PK_{A_i}, S_{A_i}, H(h_I || MD_i))\stackrel{?}{=} True
$$

By collecting a sufficient number of correctly signed $MD_i$, DTE can restore the original signature $S_{Tx}$ and apply the transaction to the blockchain.

## Conclusion

The DTES system is a reliable means for verifying and confirming transactions before they are applied. It has several advantages, key ones include:

1. The solution scales excellently by adding additional data $I$ in the metadata block $MD_i$, which allows the restoration of the signature and transaction data on different DTES systems, splitting the input part responsible for the distribution of shares and the output part responsible for data recovery.
2. DTES does not require knowledge of the wallet’s secret key to perform a transaction, which allows signing *Tx* on third-party solutions (HSM, Vault) or using additional tools for distributed secret key storage.
3. The fact that the verification is done on the already signed transaction minimizes the damage in case of a breach or leak, as the ultimate target for the attack is the signature of a specific transaction, which does not provide any knowledge or access to any transaction before or after the breached one, nor does it give any knowledge about the wallet keys.
4. The fact that the verification is done on the already signed transaction makes the attack of replacing the recipient's address meaningless, as any modification of the original data invalidates the signature $S_{Tx}$.
5. All cryptographic algorithms are proven to be secure and do not provide any knowledge to an attacker who does not possess the complete set of data and the AES128 secret.
6. DTES can be scaled and applied to any blockchain or systems with a verification scheme similar to that of signatures.
7. The modular architecture and flexible configuration allow building a verification system that meets any security requirements.

## Revision 1.1
### Gate
In a case we don't trust gate module because of external location or just to increase the whole system safety, we should keep gate out of the trusted set. So the main idea to transfer DTE Ephemeral ECDH key directly. Signer can keep additional *allowed list* for **ECDH** key providers which allowes to update $E_{PK_D}$. As a result the message from gate to signer will be as follows
$$
V_G = (M_G, PK_G, S_G)
$$
where $PK_G$ - **sr25519** public key and $S_G$ - signature, for the message hash:
$h_{M_G}=H(M_G)$ - *blake2b* hash from $M_G$. The signer response will be the same as it was.