# Entropy things

* This doc is mainly to have an internal living breathing spec. Rough spec, idk lets just get some shit on paper

## Staking System

* As talked about there are 2 - 3 options
* This is important to get right early as upgrade stratagies from one to the next are mad painful

#### option 1

* Two seperate staking systems

##### pros
* This is my optimal choice from and engineering perspective, seperate concerns allows a green field while designing our system
* Modular

##### cons
* From a product perspective this may be bad, two seperate staking systems who people will chose and may be less staked for this reason

#### option 2

* Extending the staking system of validators

##### pros

* can piggy back of parity's code here
* joint staking pool so I can stake once and participate in two actions

##### cons
* may have choices and issues that we can not get around, also playing with some seriously heavy code that we may not be fully read in on yet
* forking would require keeping an eye on substrate PRs and making sure no critical changes are made and if they are manually updating them which sucks

##### option 3

* This option requires more research and may not even be feasible without forking the staking stuff
* Sharing just the stakes by locking them and seperating both staking logics
* If it is not forked and we really test and think through it this maybe the best of both worlds......or to be honest the worst of both worlds if it doesn't fit right

##### pros

* Can stake once and use for both but the logics are modularized

##### cons

* still not a greenfield and is the easiest option to have big compatability bugs

#### option 4 (not a staking system, should not be here)

* David's staking idea was not a staking system per sé, but a possible solution to the issue that token-holders might predominantly choose to only stake with signers, not with validators.
* This issue could be handled by letting validator-stakes boost (increase) signer stakes. A similar feature is used by curve.fi
* Of course, this could also be handled by simply having separate and variable staking rewards for signers and validators.

## Signing design

* This is meant to be the design of the whole system, there are def parts I am missing/have not thought of feel free to add comment or jam on this

#### option 1

* Onchain signing exectution and staking
* this is what I like personally, more fun tbh easier and fun.

* Alice is user
* Bob is node

* Bob stakes and enters the entropy network
* Alice generates a key shard and distrubutes it to a selection of validators
** Remark: in DistributedKeyGeneration, all parties generate their own key shares/shards and send public information, which is derived from that key share, to other parties. Those 'derivatives' are used together with the shares in the signature generation.
* This part is hazy to me for crypto reasoning and MvP reasoning
* Regardless this passing for now can be an RPC call the node exposes....or maybe we make them each have a small http server
* You can build a custom RPC endpoint pretty easily with substrate https://substrate.dev/recipes/custom-rpc.html
* An extrinsic would need to be put on chain for alice to say hey, these are the nodes I need to recreate my key?

* A lot of questions in the last point but we can now assume alice knows the nodes she needs either that being stored on chain or client side
* Alice then can set any reqierments she wants onchain
* IP address
* amount
* time
* etc

* alice does the crypto stuff locally and requests the signing from the nodes and a hash of the signature can be stored onchain for X amount of time
* Pruning the chain here would be a nice touch, maybe alice can store X amount, or txs are stored for X amount of blocks
* They need to be stored so we can slash if need be

* Storing the hash of the tx onchain cues the offchain worker to do stuff
* The signer needs to get the proper shards, the signer can be the current block producer, may just piggy back off that, could be fun, here is an example of that I did with Kian https://github.com/paritytech/statemint/blob/master/pallets/collator-selection/src/lib.rs#L388
** Remarks:
* we decided on a 2-of-2 threshold signature scheme for now, so there are only 2 shards, both of which are needed for signature generation.
* As Alice holds 1 shard, the other shard would have to be stored on-chain (at least retrievable by all signers).
* Signer can use an offchain worker to rebuild the shards off chain, the shards should be stored in their local storage or maybe a temp DB, we need to think this one through more this one is difficult
* Assume they securly have the shards, they sign it with the offchain worker and now the signature is prepped, we double check the hash of the tx is onchain and then we can send it back to alice
* Alice can then send or kill the tx
* from an UX-perspective, it would be nice if the transaction was immediately sent by the entropy-network (one less step for Alice). This is probably not MVP, but how much work would this be?

##### Slashing

* If alice can prove a tx from her account that and the hash of that tx is not on chain, the sender can be slashed to make up for her funds?
* Alice should get those funds
* I want to prune those hashes so we need a timeframe and we need a way of knowing when the time the tx was sent

* A node should get slashsed if it censors tx
* Just a thought but if a signature is requested and it is like nah prob a no no

##### pros

* The chain is there and can take care of a lot of things for us
* censhorship resistent as a person can send a tx or send to our relayer and if the signer node fails to execute it can be slashed

##### cons

* Blockchain baggage
* Speed

#### option 2

* Offchain signing, onchain staking and onchain accountability

* All of the crypto signing items happen offchain
* I am not sure how everyone comes to consensys on who the signing node should be
* the chain is used for staking and slashing
* Questions
* How to prove a tx was suppose to happen
* How to generate the proofs

##### pros

* since no consensys is needed on chain we do not need to wait a block can be faster

##### cons

* more fragile
* censorable
* less secure
* A lot more custom built