Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    bzho3179
    @bzho3179
    Hello, everyone. My name is Frank. I am so interested in this project and have been paying my attention on this project for a while. I am eager to make some contribution to this project, but do not know where to start from and what should I do. Could you please give me some suggestions or allocate some tasks for me to work with? Thank you very much.
    Age Manning
    @AgeManning
    Hi Frank. Thanks for reaching out. Typically we recommend looking for good_first_issue's in our issue list to get started. However I'm aware that we are lacking a few of those recently (mainly because we have been busy building large sections of lighthouse). Is there a specific area you are interested in? Eth 2 spec / Networking / Optimizations / Algorithms ? How experienced are you with rust? Given answers to these, I'm sure I could direct you to a task
    bzho3179
    @bzho3179
    @AgeManning Thank you for your reply very much. Based on the four categories given by you, I am good at the Algorithms the most, followed by networking and optimizations. Although I have learned some knowledge regarding to the Ethereum, I know a little about Eth 2 spec. I am able to write some basic Rust code now, but I can understand many Rust codes with the help of documentation. I am a quick learner, I think. Even if I might not know too much about the tasks, I could learn the required knowledge in a short time and apply them in the tasks.
    Paul Hauner
    @paulhauner
    Hey @bzho3179, great to hear you're interested!
    Perhaps you could start on some block processing tests! This one is a good one: sigp/lighthouse#358
    If you have any questions, please reach out! We're in Sydney, Australia and are generally online during business hours (give or take a few hours :) )
    bzho3179
    @bzho3179
    @paulhauner Thanks for your reply. I will try to work on the processing tests. I am at Sydney as well and currently study at USYD.
    Paul Hauner
    @paulhauner
    Oh cool, a local!
    bzho3179
    @bzho3179
    No, I am not a local. I am from China, doing a master degree for IT security. This is my second year studying at Sydney.
    James Zaki
    @jzaki
    What is the generic "train-and-hotel problem" referred to here? -> https://ethresear.ch/t/cross-shard-contract-yanking/1450
    Surprisingly hard to google
    Paul Hauner
    @paulhauner

    Oh, it's an example of an atomic transaction :)

    So consider you want to go on a trip. You need both a train and hotel -- either are useless on their own, you need both. The problem is that the hotel booking contract is on shard A and the train booking contract is on shard B. You need to be able to atomically book both items, failing for both if one fails.

    James Zaki
    @jzaki
    Ah, too easy. Cheers.
    Paul Hauner
    @paulhauner
    No worries!
    James Zaki
    @jzaki
    Another one: LMD GHOST, what does LMD stand for?
    (GHOST = Greediest Heaviest Observed Sub-Tree)
    Referred to in "Fork choice" here -> https://notes.ethereum.org/s/BJEZWNoyE
    James Zaki
    @jzaki
    Disregard, found here: “latest message driven GHOST” -> https://vitalik.ca/general/2018/12/05/cbc_casper.html
    Paul Hauner
    @paulhauner
    cool! if you're coming tonight I can draw it up for you :)
    James Zaki
    @jzaki
    For sure, see you tonight
    James Zaki
    @jzaki
    @michaelsproul What is this black-magic...
    pub fn run_test<T>(doc: &Doc) -> Vec<CaseResult> where Cases<T>: EfTest + YamlDecode, {
    James Zaki
    @jzaki
    I'm seeing Cases<T> being given the traits of EfTests and YamlDecode. But T remains undefined until
    let test_cases: Cases<T> = Cases::yaml_decode(&doc.cases_yaml).unwrap();
    where it is set to YamlDecode in cases.rs?
    Michael Sproul
    @michaelsproul

    hey @jzaki :) Cases<T> is a wrapper around a Vec<T> where T implements the EfTest and YamlDecode traits. The types that T can be instantiated to each have a file in tests/ef_tests/src/cases, and each implement EfTest and YamlDecode. Wherever run_test is called, the compiler can't infer the type T automatically, so we provide it manually like: run_test::<OperationsExit<MinimalEthSpec>>, which says: "I think OperationsExit<MinimalEthSpec> is a valid choice of T that implements EfTest and YamlDecode, so I want you to use its YamlDecode implementation to decode the test cases, and then run them with the EfTest implementation for OperationsExit"

    Hope that makes sense!

    James Zaki
    @jzaki
    Thanks @michaelsproul
    Watching a Sharding video (posted Sep2018), and there is a slide saying that validators from the pool are randomly assigned one of 4 roles: Beacon proposer, shard proposer, shard attester, notary
    https://youtu.be/J6xO7DH20Js?t=277
    Is that still valid?
    Also trying to put beacon nodes in context - ethereum/eth2.0-specs#157
    Paul Hauner
    @paulhauner
    Not sure about notary.. definitely not in phase 0
    Beacon node/validator client is kind of like if you pulled the miner our of geth/parity
    Geth/parity would be the "beacon node" and the miner would be the "validator client"
    the reason it's separated is:
    1. It deals with signing messages -- from a systems design perspective, it's generally nice for private keys to be held in small, separate components.
    2. It provides a degree of failure safety -- if the validator is a separate component it can try and detect if a beacon node is faulty and swap to another one.
    James Zaki
    @jzaki
    That very last point about swapping to another beacon node. What are the beacon assumptions for phase 0?
    Would it be possible to have a say 20-30minute whiteboards session this week to nut a few things out? It'll speed up the noob on-ramp article I'm writing :)
    Paul Hauner
    @paulhauner
    sure! does thursday or friday work for you? we can book a room at wework if you like
    James Zaki
    @jzaki
    That'd be awesome, Thursday. What time? Morning?
    Will DM email just send an invite whenever works for you
    James Zaki
    @jzaki

    "The VC (Validator Client) is capable of managing multiple validators in the same process tree." - https://github.com/sigp/lighthouse/tree/master/validator_client

    From the Eth2.0 Specs point of view, does "validator"/"validator node" refer to the same thing?

    Age Manning
    @AgeManning
    Oh, that is an artifact from an older implementation.
    A validator client is the software that essentially does the signing for various validator duties (i.e proposing blocks and attesting). A validator in the spec, refers to a single BLS keypair that is staking on the beacon chain. The validator client is capable of managing arbitrary many such keypairs. So you could be 10 validators (have 10 keypairs) and the validator client will connect to a beacon node, ask when each validator is supposed to attest or propose a block, then perform the signing for each validator.
    In an earlier version of the validator client, we had a validator binary for each validator... that has since been surpassed with logic that performs actions only when necessary given the validator keypairs it knows about
    James Zaki
    @jzaki
    Awesome cheers @AgeManning
    Where's the best place to read about the configuration of multiple beacon nodes maintaining the beacon state? (if indeed that question is correct).
    Age Manning
    @AgeManning
    yeah not sure I understand. Similar to Eth1. Multiple geth nodes maintain the same eth state. Multiple beacon nodes should agree on the same beacon state
    James Zaki
    @jzaki
    Cool, thought so. And that's outside the Phase 0 spec?
    Age Manning
    @AgeManning
    If you are talking about load-balance beacon nodes for a validator client, we haven't gone down that path yet
    James Zaki
    @jzaki
    So the idea is to get to a point of one beacon client (one beacon node) running, and one or more validator clients connecting to it?
    Just wanting to iron out this terminology for the intro doc.
    Age Manning
    @AgeManning
    A consensus mechanism it what allows multiple nodes to agree on the same state. Ethereum 1 uses PoW. We are using PoS. The justification and finalization is an adaption of the casper paper: https://arxiv.org/abs/1710.09437
    James Zaki
    @jzaki
    Yep, I think I'm clear with that with regard to blocks, ie from beacon state and down (validators etc). I guess I'm missing something around beacon node(s)?
    Age Manning
    @AgeManning
    The beacon chain employs a PoS consensus, where validators vote on blocks. Nodes agree on most votes via LMD GHOST.
    Yep, so if one node knows about block/slot 10 (which contains the beacon state) and another node knows about a different block/slot 10... they need to decide on which one is correct (i.e who has the correct state). They choose the one that has the most votes, basically.. then both nodes will agree on the same block/state
    Age Manning
    @AgeManning

    Yeah, so the idea would be, that a validator client can connect to one or more beacon nodes.... the reason you may want to do this is because, the validator client knows about a few keypairs.. lets say 5.... Of those 5, the validator client asks the beacon node: "hey mate.. when do these validators need to propose blocks or attestations".. the beacon node will be like "in 10, 12 , 15, 18, and 20 seconds".... then at those time intervals, the validator client will ask the beacon node... "can you give me a block to sign"... beacon node is like "yep, here"... validator client, for the validator in question, signs the block and gives it back.

    Now, as a validator client, you have money at stake. If the beacon node gives you the wrong block, or the beacon node is wrong about which times you are supposed to do things, you will lose money. So if you have a beacon node that is intentionally or unintentionally misbehaving, you will lose money.

    For this reason, it's potentially a good idea to have a second beacon node running (or an online service that runs another beacon node for you) so that if one goes down, or misbehaves, you can use the other to continue voting and not lose money

    James Zaki
    @jzaki
    Thanks, I'm all good with the part from a single beacon node down, it's just the idea of one or more beacon nodes sharing state (ie validator lists, balances etc). I think I'm missing something obvious there.