# BN <-> Agggregator v0.11.1 - 1 Pager Design Author: Terence Tsao ## Objective In this page, we aim to achieve an end to end design between BN RPC server and VC RPC client so that BN can properly subscribes to attestation subnet such that: * BN serving attester can find persistent peers on the subnet in question to publish attestation * BN serving aggregator can join the subnet ## Required readings for background https://github.com/ethereum/eth2.0-specs/pull/1615 https://github.com/ethereum/eth2.0-specs/pull/1685 ## Limitations in today's design ![](https://i.imgur.com/xZJ12xP.png) **Red X 1**: Beacon node has no way knowing which attester is also an aggregator and whether it has to serve an aggregator at all. Instead beacon node just subscribes to every the committee ID subnet of every attester. This defaults back to the current testnet limitation, listening on every subnet is very expensive! **Red X 2**: Waiting 1/3 of slot on the beacon node makes little sense. Waitng 1/3 slot should happen on the attester before sending the GetAttestationData request **Red X 3**: Beacon node aggregates *all* unaggregated attestations in the pool at intervals (3 times per slot), this a wasteful operation given a beacon node may not be serving aggregators. Beacon node should aggregate unaggregated attestations of the precise committee ID subnet on demand ## Proposed design to address limitaitons ![](https://i.imgur.com/ovC48eO.png) ~~**Yellow Star 1**: Update RPC duties response to include duties for next epoch~~ We don't have to modify the current RPC duties response. Instead, validator client can just send two duty requsts. One for current epoch and one for next epoch. **Yellow Star 2**: Add new RPC message `SubscribeSubnet` to notify which committee ID subnet to subscribe **Yellow Star 3**: Move wait 1/3 of slot to validator client attester **Yellow Star 4**: Have Aggregate attestations on demand and take out aggregation intervals routine in operation pool ❗**Note**❗ The proposed design assume that backend should not be load balanced with round robin or any other ephemeral connection LB strategy. A beacon node should consider the fact that the validator can connect to the BN later and BNshould do whatever it can to connect to the subnet in a timely manner.
Last changed by  
 
terence tsao
307

Read more

Onyx Testnet Pre Gensis Q/A

⏳ Genesis time related questions: Q: Is there any estimate time for the genesis of Oynx? A: Not yet, the deposit contract needs to hit the threshold of 16384 deposits then wait for 48 hours until genesis. ✉️ Deposit related questions: Q: If there is anyway to get back the GoETH I deposit in the topaz testnet with the shardwithdrawalkey ? A: There is no way to get back that GoETH. Deposits into eth2 phase 0 are one-way Q: https://prylabs.net/participate still sends ETH to old contract. A: Try clearing your browser cache

6/10/2020
Prysm Phase1 Design Summary

Author: Terence Tsao (terence@prysmaticlabs.com) :wave: Background In the current Ethereum road map, Ethereum2.0 (ETH2.0)'s phase 1 implements sharding of data. As the phase 1 spec continues to mature, evolve and improved by the researchers and the community members. There's great value and synergy to begin implement a phase 1 proof of concept client that aims to serve many great purposes. Prysm from Prysmatic Labs is the phase 0 beacon chain implementation in Golang. The project consists of implemenations of beacon node and validator client. Both implementations are aiming to be production ready as beacon chain goes mainnet starting day 0. As we are heading towards the mainnet production readiness phase for phase 0, it naturally makes sense to begin and explore experimental phase 1 functionality using Prysm. :goal_net: Outlined Goals Implement shard chains that get built along side beacon chain in run time, shard chains should be crosslinking with the beacon chain Implement benchmarks on what is feasible and what is not feasible with design decisions outlined in the spec

5/12/2020
Read more from terence tsao
Published on HackMD