Updates to storage proposal with more storage contract details (#3373)
This commit is contained in:
parent
f567877d1d
commit
576524f13b
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue