provide more details about Proof struct

README.md

@@ -1,7 +1,7 @@
 # SSV Distributed Key Generation Spec
 
 ## Introduction
-This repository contains spec of distributed key generation (DKG) used in SSV. Based on verifiable secret sharing, DKG allows a set of *n* operators to generate a  **BLS** key share for each operator, such that a BLS private key can only be used when threshold *t* out of *n* operators agree. 
+This repository contains spec of distributed key generation (DKG) used in SSV. Based on verifiable secret sharing, DKG allows a set of *n* operators to generate a  **BLS** key share for each operator, such that a BLS private key can only be used when threshold $t$ out of $n$ operators agree. $t$ is defined by the number of faults admissible: $t = n - f$, where $n = 3 * f + 1$.
 
 ---
 
@@ -12,7 +12,7 @@ Operations are initiated by an initiator, and executed by operators. An initiato
 When a init message is sent to the operators, all operators participate and run a DKG ceremony to create key shares. A DKG ceremony asks each operator to verifiably share locally generated secrets with other operators, and combine secret shares from all operators to derive its own BLS key share. After the ceremony, each operator generates a **Result** with a **SignedProof** (see below) for verification. Proofs are referred to when an initiator asks for re-sign or reshare. 
 
 ### Re-sign
-In the case where the nonces of a DKG ceremony is not correct, to prevent replay attack, the initiator sends re-sign messages for operators to create new signatures with correct nonces without generating new key shares. 
+In the case where the nonces of a DKG ceremony is not correct, to prevent replay attack, the initiator sends re-sign messages for operators to create new signatures with correct nonces without generating a new validator key. 
 
 ### Reshare
 When the set of operators changed (including change of size and change of operators), a reshare is initiated to generate new key shares among the new operators. This process requires participation from *t* old operators and all new operators. 
@@ -57,10 +57,10 @@ type Proof struct {
 	Owner [20]byte `ssz-size:"20"`
 }
 ```
-*ValidatorPubKey*, *EncryptedShare*, and *Owner* are to identify information of the validator and the operator in SSV network, the *SharePubKey* is computed by the operator after the DKG ceremony using the obtained secret share as the private key.
+As a 4-operator example, after the ceremony, each operator $i$ obtains a secret share $s_i$. The aggregated secret key $S$ can be recovered from any 3 out of the 4 secret shares $s_1, s_2, s_3, s_4$. In this example, *ValidatorPubKey* is the public key of the aggregated secret $S$. *EncryptedShare* is the encrypted secret share of the operator, e.g. encrypted $s_1$ for operator 1. *SharePubKey* is the corresponding public key of the operator's secret share $s_i$. 
 
 **Proof**s are published by the initiator after the DKG ceremony. All **Proof** from a ceremony together validates the completion of this ceremony. they can make sure:
-- Partial signatures of operators are publically verifiable using the *SharePubKey* in the **proof**. If an operator created invalid partial signatures, the network is able to identify and potentially take further action.
+- Partial signatures of operators are publically verifiable using the *SharePubKey* in the **proof** with BLS signature verification (given the message, *SharePubKey*, and the signature, returns whether the signature is valid or not). If an operator created invalid partial signatures, the network is able to identify and potentially take further action.
 - An operator knows its peers have completed the protocol locally and has a secret share ready to use. It prevents the case where some operators failed to derive their secret shares while others are unaware.
 - The initiator refers to a completed valid DKG ceremony when initiating **Re-sign** and **Reshare**. Operators are able to identify and verify the corresponding ceremony when receiving requests from the initiator.