Updates to storage proposal with more storage contract details (#3373)

book/src/ledger-replication-to-implement.md

@@ -2,6 +2,12 @@
 
 Replication behavior yet to be implemented.
 
+### Storage epoch
+
+The storage epoch should be the number of slots which results in around 100GB-1TB of
+ledger to be generated for replicators to store. Replicators will start storing ledger
+when a given fork has a high probability of not being rolled back.
+
 ### Validator behavior
 
 3. Every NUM\_KEY\_ROTATION\_TICKS it also validates samples received from
@@ -37,3 +43,100 @@ transacation proves the validator incorrectly validated a fake storage proof.
 The replicator is rewarded and the validator's staking balance is slashed or
 frozen.
 
+### Storage proof contract logic
+
+Each replicator and validator will have their own storage account. The validator's
+account would be separate from their gossip id similiar to their vote account.
+These should be implemented as two programs one which handles the validator as the keysigner
+and one for the replicator. In that way when the programs reference other accounts, they
+can check the program id to ensure it is a validator or replicator account they are
+referencing.
+
+#### SubmitMiningProof
+```rust,ignore
+SubmitMiningProof {
+    slot: u64,
+    sha_state: Hash,
+    signature: Signature,
+};
+keys = [replicator_keypair]
+```
+Replicators create these after mining their stored ledger data for a certain hash value.
+The slot is the end slot of the segment of ledger they are storing, the sha\_state
+the result of the replicator using the hash function to sample their encrypted ledger segment.
+The signature is the signature that was created when they signed a PoH value for the
+current storage epoch. The list of proofs from the current storage epoch should be saved
+in the account state, and then transfered to a list of proofs for the previous epoch when
+the epoch passes. In a given storage epoch a given replicator should only submit proofs
+for one segment.
+
+The program should have a list of slots which are valid storage mining slots.
+This list should be maintained by keeping track of slots which are rooted slots in which a significant
+portion of the network has voted on with a high lockout value, maybe 32-votes old. Every SLOTS\_PER\_SEGMENT
+number of slots would be added to this set. The program should check that the slot is in this set. The set can
+be maintained by receiving a AdvertiseStorageRecentBlockHash and checking with its bank/locktower state.
+
+The program should do a signature verify check on the signature, public key from the transaction submitter and the message of
+the previous storage epoch PoH value.
+
+#### ProofValidation
+```rust,ignore
+ProofValidation {
+   proof_mask: Vec<ProofStatus>,
+}
+keys = [validator_keypair, replicator_keypair(s) (unsigned)]
+```
+A validator will submit this transaction to indicate that a set of proofs for a given
+segment are valid/not-valid or skipped where the validator did not look at it. The
+keypairs for the replicators that it looked at should be referenced in the keys so the program
+logic can go to those accounts and see that the proofs are generated in the previous epoch. The
+sampling of the storage proofs should be verified ensuring that the correct proofs are skipped by
+the validator according to the logic outlined in the validator behavior of sampling.
+
+The included replicator keys will indicate the the storage samples which are being referenced; the
+length of the proof\_mask should be verified against the set of storage proofs in the referenced
+replicator account(s), and should match with the number of proofs submitted in the previous storage
+epoch in the state of said replicator account.
+
+#### ClaimStorageReward
+```rust,ignore
+ClaimStorageReward {
+}
+keys = [validator_keypair or replicator_keypair, validator/replicator_keypairs (unsigned)]
+```
+Replicators and validators will use this transaction to get paid tokens from a program state
+where SubmitStorageProof, ProofValidation and ChallengeProofValidations are in a state where
+proofs have been submitted and validated and there are no ChallengeProofValidations referencing
+those proofs. For a validator, it should reference the replicator keypairs to which it has validated
+proofs in the relevant epoch. And for a replicator it should reference validator keypairs for which it
+has validated and wants to be rewarded.
+
+#### ChallengeProofValidation
+```rust,ignore
+ChallengeProofValidation {
+    proof_index: u64,
+    hash_seed_value: Vec<u8>,
+}
+keys = [replicator_keypair, validator_keypair]
+```
+
+This transaction is for catching lazy validators who are not doing the work to validate proofs.
+A replicator will submit this transaction when it sees a validator has approved a fake SubmitMiningProof
+transaction. Since the replicator is a light client not looking at the full chain, it will have to ask
+a validator or some set of validators for this information maybe via RPC call to obtain all ProofValidations for
+a certain segment in the previous storage epoch. The program will look in the validator account
+state see that a ProofValidation is submitted in the previous storage epoch and hash the hash\_seed\_value and
+see that the hash matches the SubmitMiningProof transaction and that the validator marked it as valid. If so,
+then it will save the challenge to the list of challenges that it has in its state.
+
+#### AdvertiseStorageRecentBlockhash
+```rust,ignore
+AdvertiseStorageRecentBlockhash {
+    hash: Hash,
+    slot: u64,
+}
+```
+
+Validators and replicators will submit this to indicate that a new storage epoch has passed and that the
+storage proofs which are current proofs should now be for the previous epoch. Other transactions should
+check to see that the epoch that they are referencing is accurate according to current chain state.

book/src/ledger-replication.md

@@ -31,7 +31,7 @@ core. The total space required for verification is `1_ledger_segment +
 Validators for PoRep are the same validators that are verifying transactions.
 They have some stake that they have put up as collateral that ensures that
 their work is honest. If you can prove that a validator verified a fake PoRep,
-then the validators stake can be slashed.
+then the validator will not receive a reward for that storage epoch.
 
 Replicators are specialized *light clients*. They download a part of the ledger
 and store it, and provide PoReps of storing the ledger. For each verified PoRep
@@ -53,7 +53,7 @@ changes to determine what rate it can validate storage proofs.
 
 ### Constants
 
-1. NUM\_STORAGE\_ENTRIES: Number of entries in a segment of ledger data. The
+1. SLOTS\_PER\_SEGMENT: Number of slots in a segment of ledger data. The
 unit of storage for a replicator.
 2. NUM\_KEY\_ROTATION\_TICKS: Number of ticks to save a PoH value and cause a
 key generation for the section of ledger just generated and the rotation of
@@ -77,7 +77,7 @@ height.
 3. Validator generates a storage proof confirmation transaction.
 4. The storage proof confirmation transaction is integrated into the ledger.
 6. Validator responds to RPC interfaces for what the last storage epoch PoH
-value is and its entry\_height.
+value is and its slot.
 
 ### Replicator behavior
 
@@ -95,10 +95,10 @@ is:
     - (d) replicator can subscribe to an abbreviated transaction stream to
       generate the information itself
 2. A replicator obtains the PoH hash corresponding to the last key rotation
-along with its entry\_height.
+along with its slot.
 3. The replicator signs the PoH hash with its keypair. That signature is the
 seed used to pick the segment to replicate and also the encryption key. The
-replicator mods the signature with the entry\_height to get which segment to
+replicator mods the signature with the slot to get which segment to
 replicate.
 4. The replicator retrives the ledger by asking peer validators and
 replicators. See 6.5.
@@ -118,9 +118,9 @@ current leader and it is put onto the ledger.
 ### Finding who has a given block of ledger
 
 1. Validators monitor the transaction stream for storage mining proofs, and
-keep a mapping of ledger segments by entry\_height to public keys. When it sees
+keep a mapping of ledger segments by slot to public keys. When it sees
 a storage mining proof it updates this mapping and provides an RPC interface
-which takes an entry\_height and hands back a list of public keys.  The client
+which takes a slot and hands back a list of public keys.  The client
 then looks up in their cluster\_info table to see which network address that
 corresponds to and sends a repair request to retrieve the necessary blocks of
 ledger.