owned this note
owned this note
Published
Linked with GitHub
# ssv sdk goals tech overview
## Goals
- logically separate part handeling secrets from rest
- reasons
- allow for internal part to be audited separately
- allow for the rest of the SDK to be agnostic, also developed in GO, JS or other languages
- questions
- what should be the exact structure of the functions?
- how many should be there?
- ? take inspiration from structuring of validator key tool?
- allow for separation of external and internal part
- what is the best way to do so?
- ? have a `read_config()` run at the beginning of the script?
- reasons
- error handeling
- only necessary inputs must be in config
- easier to reason about fns
- devs see what inputs it usese
- easier for grantees to use only specific functions from the SDK, agnostic to config structure, let them handle inputs in any way
-
## internal part
All the internal part of the SSV sdk can be converted into a library which takes input in the functions and gives necessary output.
### Principles
- minimal code required to get shares + keys from secret.
- should return only publicly sharable encrypted data
- ? return validator_key or just deposit data? // would avoid this as not to pass secrects anywhere
- ? would make it without external dependecies such as RPCs
- for safety this part does not take validator keys as inputs as no secrets are passed in or out, however, some grantees use validator keys directly and not mnemonic in their system, does it make sense to create a specific function for this which takes this as input? probably better than incorporate into existing ones for clarity..
- do we want the be opinionated in this or not?
### Parts
**goal**
- Validator Creation
- Requires:
- Mnemonic
- Index of Validators
- Number of Validators
- Network
- Outputs:
- keystore files for the validators
- KeyShare Creation
- Requires:
- keystore file or mnemonic and index
- Node operator public keys
- Owner Address
- Owner Nonce
- Outputs
- keyshare file for the SSV node operators
- Validator Exits
- Requires
- keystore file or mnemonic and index
- beacon chain api
- Outputs
- exit file with exit message
As mentioned above mnemonic and index is the major part that is needed for all the operations. Though, it can be omitted but a backup should be stored in the case when validator keys goes missing. There are different ways to store them as required by the system
- **memory** : Passing the mnemonic when running the files stores them in memory and when the script stops will delete the memory. This will only give access to the script when it is running.
- **vaults** : There are many kind of vaults and these is one of the safest way to store any confidential information. This gives more granular access to the mnemonic and only the instance running the script can access it. Ex. Hashicorp vault or vaults provided by cloud providers like AWS vault
- **keystore** : Third option can be using the system keystore. Most of the systems have inbuilt keystores which can be used to store sensitive information and can be accessed by scripts with right priviliges
- **enclaves** : This option is also quite famous now-a-days. It involves creating a trusted environment and running your processes there. The enclave just takes the input from the user and outputs results and the files are not accessible.
- **config file** : This is the least secure option to store the mnemonic. The security depends on the system on which config is stored
The decision to use any of the above depends on the team using the library.
- validator mapping // should this be part of external or internal part?
- validator_key => validator_index
- functions
- init function
- creates mnemonic
- print mnenmonic on the screen
- backup
- print mnenmonic on the screen
-
**validator functions**
```python
def get_deposit_data(mnemonic=dot_env, validator_index=0):
...
return deposit_data
def get_exit_cred(mnemonic=dot_env, validator_index=0):
...
return exit_cred
```
- this fn does not follow the pricniples of keeping the secrets inside only, as it outputs validator key... should we include it? can a strong password could be used to make it safe?
```python=
def create_validator(mnemonic=dot_env, validator_index=0)
...
return validator_key, deposit_data
```
**ssv functions**
```python
def get_encrypted_shares(mnemonic=dot_env, validator_index=0, operator_public_keys)
...
return encrypted_shares
```
## external part
everything else needed manage validators + get inputs + format outputs for ssv_network contracts
### parts
- config file
- functions
- ? validator database / operator regitry
**validator functions**
```python
def exit_validator(validator_index=0, bc_rpc):
# only index is inputed,
# secrets are not passed outside internal module
...
return True
def deposit_validator(deposit_data):
...
return True
def get_validator_index(pub_key):
...
return validator_index
```
**ssv functions**
```python
def get_input_registerOperators( validator_index=0, operator_ids, rpc_url):
...
return registerOperator_inputs # to be pluggable straight to the function
def format_output_operatorFee(tx_output, scale=years):
...
return operatorFee_human_readable
def format_output_networkFee(tx_output, scale=years):
...
return networkFee_human_readable
```