ec clarifications and updates

data-structures.md

@@ -39,9 +39,9 @@ type BlockHeader struct {
 	## Tickets is a chain (possibly singleton) of tickets ending with a winning ticket submitted with this block.
 	tickets [Ticket]
 
-	## ElectionProof is a signature over the final ticket that proves this miner
-	## is the leader at this round
-	electionProof Signature
+	## ElectionProof is generated from a past ticket and proves this miner
+	## is a leader at this round
+	electionProof ElectionProof
 
 	## Parents is an array of distinct CIDs of parents on which this block was based.
 	## Typically one, but can be several in the case where there were multiple winning ticket-
@@ -81,6 +81,38 @@ type BlockHeader struct {
 } representation tuple
 ```
 
+## Ticket
+
+A ticket is a shared random value stapled to a particular block in the chain. Every miner must produce a new ticket each time they run a leader election attempt. In that sense, every new block produced will have one or more associated tickets (in the case the block took multiple leader election attempts to produce).
+
+```go
+type Ticket struct {
+	// TODO HS
+  // This signature is generated by the miner's keypair run on a past ticket in the ticket chain
+  VRFResult Signature
+
+  // The VRFProof proves that the VRFResult was appropriately generated from a past ticket by the miner generating this ticket.
+  VRFProof BigInteger
+
+  // The VDFResult is derived from the VRFResult of the ticket
+  // It is the value that will be used to generate future tickets or ElectionProofs
+  VDFResult BigInteger
+
+  // The VDF proves a delay between tickets generated
+  VDFProof BigInteger
+} representation tuple
+```
+
+## ElectionProof
+
+An election proof is generated from a past ticket (chosen based on public network parameters) by a miner during the leader election process. Its output value determines whether the miner is elected leader and may produce a block. Its inclusion in the block allows other network participants to verify that the block was mined by a valid leader.
+
+```go
+type ElectionProof struct {
+  // TODO HS
+}
+```
+
 ## Message
 
 ```sh

definitions.md

@@ -65,6 +65,10 @@ See [Filecoin Proofs](proofs.md)
 
 *** *A deal in a Filecoin market is made when a bid and ask are matched, corresponding to an agreement on a service and price between a miner and client.
 
+#### Election Proof
+
+An `ElectionProof` is derived from a past `ticket` and is included in every block header. The `ElectionProof` proves that the miner was eligible to mine a block in that `round`.
+
 #### Erasure coding
 
 Erasure coding is a strategy through which messages can be lengthened so as to be made recoverable in spite of errors.
@@ -73,7 +77,7 @@ See [Wikipedia](https://en.wikipedia.org/wiki/Erasure_code)
 
 #### Epoch
 
-An epoch refers to the period over which a given random seed is used in Expected Consensus. In the current Filecoin implementation, each round is an epoch.
+An `epoch` is the period in which a new block is generated. There may be multiple `rounds` in an epoch.
 
 #### Fault
 
@@ -101,6 +105,12 @@ The Generation Attack Threshold is equal to the Polling Time + some Grace Period
 
 #### GHOST
 
+[GHOST](https://eprint.iacr.org/2013/881.pdf) is an acronym for `Greedy Heaviest Observable SubTree`, a class of blockchain structures in which multiple blocks can validly be included in the chain at any given height or round. GHOSTy protocols produce blockDAGs rather than blockchains and use a weighting function for fork selection, rather than simply picking the longest chain.
+
+#### Height
+
+`Height` refers to the number of `TipSets` that have passed between this `TipSet` and the genesis block (which starts at block height 0). If a `TipSet` contains multiple blocks, each block in the TipSet will have the same `height`.
+
 #### Leader
 
 A leader, in the context of Filecoin consensus, is a node that is chosen to propose the next block in the blockchain.
@@ -151,7 +161,11 @@ A piece is a portion of a file that gets fitted into a sector.
 
 Security Parameter. Polling time is the time between two online PoReps in a PoSt proof.
 
-#### Power table
+#### Power Fraction
+
+A miner's `Power Fraction` is the ratio of their committed storage over Filecoin's committed storage. It is used in leader election.
+
+####  Power table
 
 The power table is an abstraction provided by the Filecoin storage market that lists the `power` of every miner in the system.
 
@@ -203,7 +217,9 @@ Repair refers to the processes and protocols by which the Filecoin network ensur
 
 #### Round
 
-A round refers to the period over which a new leader election occurs and a block is generated if a leader is found. Typically this means a new block will be mined at every round, though some rounds may see 0 or multiple blocks generated.
+A round refers to the period over which a new leader election occurs and a block is generated if a leader is found. Typically this means a new block will be mined at every round, though.
+
+A `round` is the period in which a miner runs leader election to attempt to generate a new block. It may succeed, or zero or multiple blocks may be generated instead in that round. Every `round`, one `ticket` is produced. Thus, the duration of a round is currently bounded by the duration of the Verifiable Delay Function (VDF) that is run to generate a `ticket`. Because one `ticket` is produced per `round`, the number of `tickets` is the same as the number of `rounds` that have passed.
 
 #### SEAL/UNSEAL
 
@@ -233,21 +249,24 @@ In the context of:
 
 #### Ticket
 
-Some unpredictable element generated by the system for two uses:
-
-- as a random challenge to PoSTs.
-- to elect a leader in Expected Consensus.
-
-See more on [Expected Consensus](expected-consensus.md) and [PoSTs](proofs.md).
+A `ticket` is used as a source of randomness in EC leader election. Every block depends on an `ElectionProof` derived from a `ticket`. At least one new `ticket` is produced with every new block. Ticket creation is described [here](./expected-consensus.md#Ticket-generation).
 
 #### TipSet
 
-A collection of blocks mined by different miners, each an elected leader of a given epoch. All tip sets have the same parent-set and epoch number (height). TODO add picture.
+ A `TipSet` is a set of blocks that have the same parent set and same number of `tickets`, which implies they will have been mined at the same `height`. A `TipSet` can contain multiple blocks if more than one miner successfully mines a block in the same `round` as another miner.
 
 #### Verifiable
 
 Something that is verifiable can be checked for correctness by a third party.
 
+#### VDF
+
+A verifiable function that guarantees a time delay given some hardware assumptions and a small set of requirements. These requirements are efficient proof verification, random output, and strong sequentiality. Verifiable delay functions are formally defined by [\[BBBF]](https://eprint.iacr.org/2018/601).
+
+```text
+{proof, value} <—- VDF(public parameters, seed)
+```
+
 #### VM
 
 Virtual Machine. The Filecoin VM refers to the system by which changes are applied to the Filecoin system's state. The VM takes messages as input, and outputs state.
@@ -256,6 +275,18 @@ Virtual Machine. The Filecoin VM refers to the system by which changes are appli
 
 Held by an actor as part of a payment channel to complete settlement when the counterparty defaults.
 
+#### VRF
+
+A verifiable random function that receives {Secret Key (SK), seed} and outputs {proof of correctness, output value}. VRFs must yield a proof of correctness and a unique & efficiently verifiable output.
+
+```text
+{proof, value} <-- VRF(SK, seed)
+```
+
+#### Weight
+
+Every mined block has a computed `weight`. Together, the `weights` of all the blocks in a branch of the chain determines the cumulative `weight` of that branch. Filecoin's Expected Consensus is a GHOSTy or heaviest-chain protocol, where chain selection is done on the basis of an explicit weighting function. Filecoin’s `weight` function currently seeks to incentivize collaboration amongst miners as well as the addition of storage to the network. The specific weighting function is defined in [Chain Weighting](expected-consensus.md#chain-weighting).
+
 #### zkSNARK
 
 Zero Knowledge Succinct ARguments of Knowledge. A way of producing a small 'proof' that convinces a 'verifier' that some computation was done correctly.