Week 1 Update (#78)

* add notes * Update development-updates.md
eth-protocol-fellows · Jun 17, 2024 · 769901b · 769901b
1 parent a0f6477
commit 769901b
Show file tree

Hide file tree

Showing 2 changed files with 46 additions and 2 deletions.
diff --git a/development-updates.md b/development-updates.md
@@ -18,7 +18,7 @@ Phase one is the very beginning of the cohort. The first few weeks are dedicated
 | [Bastin](https://github.com/Inspector-Butters)               | [Update 0](https://hackmd.io/@Bastin/HJ6hOLQHC)                                                                                                  | [Update 1](https://hackmd.io/@Bastin/HyM3AmnrA)                 |        |
 | [BobLiu](https://github.com/Akagi201)                        | [Update 0](https://hackmd.io/@Akagi201/epf-cohort5-week0)                                                                                        |                                                                 |        |
 | [Boma Naps](https://github.com/bomanaps)                     |                                                                                                                                                  | [Update 1](https://hackmd.io/@u1hkHdIvSFKF7TfMsZSBow/SJQorxsrR)   |      |                                                               |        |
-| [Chirag](https://github.com/chirag-parmar)                   | [Update 0](https://hackmd.io/@chirag-parmar/S13p6uVBR)                                                                                           |                                                                 |        |
+| [Chirag](https://github.com/chirag-parmar)                   | [Update 0](https://hackmd.io/@chirag-parmar/S13p6uVBR)                                                                                           | [Update 1](https://hackmd.io/z3I1a1jITpGzXPbqDjYKAA)            |        |
 | [ChloeZhu](https://github.com/Chloezhu010)                   | [Update 0](https://hackmd.io/@chloezhu/HJpABlzBR)                                                                                                |                                                                 |        |
 | [Cloud](https://github.com/0xClouds/)                        | [Update 0](https://hackmd.io/@RkzKp199Qb2WyCcgr-HMNA/rkCLfmpSR)                                                                                  |                                                                 |
 | [Caleb](https://github.com/Tomi-3-0)                         |                                                                                                                                                  | [Update 1](https://hackmd.io/@tc3rGbpwSe6dJwI2nuYQsw/BkoLPPdr0) |        |

diff --git a/notes/ChiragMahaveerParmar.md b/notes/ChiragMahaveerParmar.md
@@ -52,7 +52,51 @@ Things learned:
 Open questions:
 1. Is there no simpler way to construct bilinear maps using elliptic curves? How did we land on using divisors? 
 
-### Beacon chain, weak subjectivity and the merge [June 11]
+### Beacon chain, weak subjectivity and the merge [June 11 - 16]
+
+[beacon chain explainer](https://ethos.dev/beacon-chain) - [the merge](https://www.youtube.com/watch?v=8N10a1EBhBc) - [why pos?](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) - [part2 of eth2book](https://eth2book.info/capella/part2/)
+
+Things Learned:
+1. 32 slots per epoch, each slot is 12s. Nodes need to maintain roughly synchronized clock [clock synchronization](https://ethresear.ch/t/network-adjusted-timestamps/4187)
+2. each slot is meant for one block. block proposer are chosen at random from the pool of validators for each slot of the epoch. all validators are "uniformly" distributed over all the slots of that epoch. they are then grouped into commitees for each slot. 
+    a. each committee should have a minimum number of validators. [minimum committee size](https://medium.com/@chihchengliang/minimum-committee-size-explained-67047111fa20)
+    b. each slot can have multiple committees and it is usually recommended to have multiple committees. why? because if all validators of a slot are assigned to only one single committee it would take longer to aggregate all attestations. But if we have more than one committee per slot then the total number of aggregate attestations for that block increases thereby increasing the block space. it is a trade-off. [committees best explained here](https://eth2book.info/capella/part2/building_blocks/committees/)
+    c. a similar trade-off is made to divide validators over the entire epoch. because if all validators attest on all slots, first, it would take a long time to aggregate all attestations and secondly it would flood the entire network thereby increasing the load.
+    d. since the entire design of commitees is based on trade offs, naturally, there is also an upper limit to the number of committees per slot. And there is also a max validators per committee, although this is expected to not be reached as it would require all the ether in the network and more to be staked.
+    e. minimum number of validators per slot = 128, maximum number of commitees per slot = 64
+    f. there is more to commitees and aggregations, per committee there are also aggregators selected, [more info here](https://eth2book.info/capella/part2/building_blocks/aggregator/)
+3. An attestation is weighted by the validators balance. So is the random selection process for proposing a block, in a sense mo money translates to mo heavier vote.
+4. The randomness of the selection process is also generated in a distributed manner. This is termed as RANDAO. Basically, proposers signature is hashed and added to the previous randao value that exists. this way the reveal value (the signature of the proposer) is verifiably random (the source being the proposers private key used for signing).
+    a. however some accounts do not have a independently generated random number for private key they are derived just like in BIP-32. the exact EIP is [EIP-2333](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2333.md) 
+    b. [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399) discusses other sources of entropy for the random number. the eip itself proposes a method to reuse deprecated block header fields and obsolete EVM instructions for bringing in the randao value into the EVM context for randomness. Note this randomness is public and not private.
+    c. the biasability of randao is in the last slot of the of the epoch. the last proposer can choose to commit or not commit their reveal based on the randao accumulated until the second last slot. if the randao value without their commitment is more favorable for the followinf epochs then they can choose to not commit. this is one bit of influence. Based on their balances if a proposer gets proposal opportunity for the last k slots the it has k bits of influence.
+    d. to provide some time for the validators to get ready a randao value has a minimum lookahead of 2 epochs i.e. randao accumulated at the end of epoch N is decides duties for epoch N + 2.
+    e. a validator with a large proportion of stake or with the ability to mount a wide scale DoS attack agaist block proposers can influence the randao significantly, thereby having the ability to lookahead more than 2 epochs. in turn this can be used to mount a even more efficient attack, join and exit validators strategically for maximum rewads. to stop this the protocol uses defines a maximum lookahead feasible and delays all activations and exits by those many epochs.
+5. Randao accumulation and shuffling has an inherent problem, along with the proposer, everyone else on the network also know that the proposer has been assigned to propose a block. A feature called single shot leader election is being researched on so that only the proposer knows ahead of time and everyone else can verify when the block is actually proposed.
+6. We chose an invertible shuffle function to allow light clients to reverse calculate. To understand this, imagine a shuffling algorithm takes as input an index and outputs a shuffled index. Now I start shuffling a list of 10 elements. let' say the 8th element gets shuffled into the 5th index and the 3rd element gets shuffled into the 6th index. so to know which element lands in the 5th and 6th index i have to run the shuffling function for every element first. If the function is invertible, i can basically provide input 5 and 6 to the inverted function and then know that the 8th and the 3rd element get shuffled here. Since we use shuffling for committee assignment, an invertible shuffling function can reduce the load for light clients to process the entire list of validators rather light clients can just calculate in reverse. There are other details pertaining to the biasability of the shuffling function.
+7. EIP-1011 partial move to PoS in the ethereum blockchain
+8. the name beacon chain was taken from dfinity's randomness beacon. it also published a white paper using BLS signatures for aggregation before justin drake posted the famous "pragmatic signature aggregation with BLS"
+9. The BLS scheme also supports threshold signatures, this enables distributed validator technology.
+10. The BLS scheme is vulnerable to an attack, called the rogue public key attack. i can publish my public key to be my public key minus your public key. after which when i sign a message i can claim that both of us signed over it (but you didn't). The signature would verify as an aggregated signature, because when your public key is added to rogue public key the resulting aggregate would be my original public key.
+11. the merge essentially is merging the existing execution layer (without proof of work) into the new consensus layer or beacon chain. The contracts for PoS were launched on EL, where validators made deposits but they participated in the consensus game on the beacon chain. 
+12. PoS is subject to lesser economic risks compared to PoW. 
+
+
+questions:
+1. what if i deliberately use a less random key and then use it to commit the random reveal? Is signing a pseudo random process? Where does the initial randao value come from?
+2. how is randao seeded initially? Is there a higher chance of bias?
+3. how much effort do we save for light clients by not choosing fisher yates shuffle?
+
+### Side Quests: Deploying a node over a VPS
+
+TODO (everything )
+preimages
+pruning
+beacon backfilling
+execution client initially requires consensus client then it starts syncing and doesn't require it anymore. actualy the other way is true, the beacon chain requires the execution client because the head is optimistic. What is this process?
+if i have finality why do i need to download the entire chain
+state download and chain download are independent processes
+