Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:42
    mkalinin commented #1595
  • 01:02
    protolambda review_requested #1584
  • 01:02
    protolambda unlabeled #1584
  • 01:01
    protolambda ready_for_review #1584
  • 01:00
    djrtwo commented #1595
  • 00:57
    protolambda synchronize #1584
  • 00:57

    protolambda on pkg-the-pyspec

    Package eth2spec for tooling an… (compare)

  • 00:44
    protolambda synchronize #1584
  • 00:44

    protolambda on pkg-the-pyspec

    Package eth2spec for tooling an… (compare)

  • 00:42
    protolambda edited #1584
  • 00:38
    gnattishness opened #1596
  • 00:38
    protolambda synchronize #1584
  • 00:38

    protolambda on pkg-the-pyspec

    Package eth2spec for tooling an… (compare)

  • 00:32
    protolambda synchronize #1584
  • 00:32

    protolambda on pkg-the-pyspec

    Package eth2spec for tooling an… (compare)

  • 00:14
    AgeManning commented #1595
  • 00:13
    djrtwo edited #1595
  • 00:01

    protolambda on dev

    Remerkleable - merkle tree base… Merge pull request #1552 from e… (compare)

  • 00:01
    protolambda closed #1552
  • Jan 24 23:52
    djrtwo edited #1595
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<herman> Thank you proto
trnhgquan
@trnhgquan
Hi all, i am new to ETH2.0, i have a question that how to create ETH2.0 accounts in javascripts? (for both Staker and Validator). I need to create Deposit Agreements, any recommendations?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<proto> @trnhgquan try the lodestar discord, they are working on an eth2 client and tooling in javascript: https://discord.gg/Quv3nJX
trnhgquan
@trnhgquan
thanks @Eth-Gitter-Bridge
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> eth2 call this thursday --
ethereum/eth2.0-pm#123
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<jgm> Sanity check on slashing penalties. From my reading of the spec, and assuming that all validators have an effective balance of 32 Ether, if a validator is slashed then it receives a penalty equal to ~3% (1 Ether) plus an additional penalty which goes from 0 to 100% of its remaining Ether as the number of other validators also slashed within the same 4K epoch window (2K either side of when the validator was slashed) goes from 0 to 33% of total validators. Is this correct?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<djrtwo> That is correct.

Essentially, at least a slap on the wrist, and then scaling with 3x the % of the network that has recently committed a fault such that if 1/3 do something slashable recently (enough to commit a network fault), slashed validators are maximally punished

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<jgm> So at the moment punishment is a triple whammy: lose some Ether, lose the ability to gain rewards, lose access to your funds for (quite) a while. Given that the idea is to avoid the 33% mark how about bending that curve a little to reduce the punishment when slashing occurs at a non-network-threatening level?
<jgm> So still the same effect if the network is really in danger, but less if there is some muck-up in the network (e.g. code bug) that causes an issue but doesn't threaten the network
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Andrew> Hi are we expecting another audit for the deposit contract or is this formal verification it?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<djrtwo> I see the appeal here, but am concerned about making validator failures seem inconsequential such that validators won't take the proper guards and leave themselves more at risk. Also concerned about reasonably punishing validators if committees are corrupted. This is more of a concern come Phase 1 (and thus @vbuterin's recent PR), but still not settled.

I'm chewing on it some more and soliciting more feedback

<djrtwo> > Hi are we expecting another audit for the deposit contract or is this formal verification it?
This is the primary audit/verification. The contract and FV work is now for public review. I'll be explicitly requesting review from some teams/individuals and will make a call out for it in my next blog post
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> networking call a week from today!
Please add items to the agenda. We'll focus on the practical issues we face today in testnets and if time beyond that discuss more far out items
ethereum/eth2.0-pm#124
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<jgm> > I see the appeal here, but am concerned about making validator failures seem inconsequential...

I wouldn't want slashing penalties to be inconsequential, but given that they already lose 1 Ether and are forcibly ejected from the validating pool (with a very long exit time) that seems like quite a chunk of punishment as-is for situations that aren't network-threatening. And if something similar comes in for committees I think this would become more important, given the much smaller size of a committee Vs. the entire validator pool.

My mind wanders to future failures of software, or hacks of large staking services, that results in 15% of total validators slashed. If they lose 50% of their balance it's going to be a much harder for the next person to decide to deposit, whereas if they lose 10% of balance value I think it would be less of a drag on adoption. Given that such an attack wouldn't be network-threatening (in phase 0, anyway) it can be hard to sell the harshness of the punishment.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<jgm> Pretty surprised that #1506 was closed. I don't see how it isn't a major security hole given it can hijack any deposit.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<djrtwo> This is only a security concern when using a custodial service for a full deposit (units of 32 ETH for a single user) in which the user retains control of the withdrawal credentials. The solution in the PR led to weird front-running exploits and didn't really provide an adequate solution.

The communications protocol I outlined here is a valid and safe way to achieve the goals of the user/custodian without modifying the deposit contract and without exposing the signing key on the wire

https://github.com/ethereum/eth2.0-specs/pull/1506#issuecomment-564086671

<jgm> > The solution in the PR led to weird front-running exploits and didn't really provide an adequate solution.

That was stated but never explained.

<jgm> And the reality is that the workaround is only of use for the parties that understand the issue. Anyone that doesn't understand the issue is vulnerable to malicious actors masquerading as staking services.

<djrtwo> I broadcast a deposit, attacker broadcasts another deposit with my data (with min 1 eth) and changes the withdrawal credentials to their own, my tx now fails.

Likely this annoyance is not worth 1ETH to an attacker, but confusion at early stages of depositing might be sufficiently discouraging for participation in general. Note that this attack is available on all deposits, not just custodial services

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> > And the reality is that the workaround is only of use for the parties that understand the issue. Anyone that doesn't understand the issue is vulnerable to malicious actors masquerading as staking services.
Phishing attacks of any sort are a major issue and the best we can do in most cases is education. I know that the day we launch teh deposit contract, there will be 10 fake addresses circulating around. An unvetted service can trick a user in any number of ways

<jgm> So you don't agree with this statement then?

If the deposit contract is given a deposit with specific withdrawal credentials it should result in either the deposited amount being withdrawable by those credentials or the deposit being rejected.

<jgm> Because that seems to me like a reasonable expectation to have for the contract.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<djrtwo> I do not think that that must be a strict requirement for the system to be secure.

The basic deposit contract ensures that a user staking for themselves will be able to safely make their deposit and specify their params. The protocol outlined in the link I shared allows for more flexibility in doing the same in custodial solutions.

Both scenarios allow for a secure setting of all params of the validator. Once these are set (including withdrawal credentials), the user is safe from any subsequent attempt to modify them as a deposit with wrong credentials would simply increase the validators balance.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<jgm> > I do not think that that must be a strict requirement for the system to be secure.

I think you would struggle to convince someone who loses their stake after signing a deposit with their withdrawal credentials in it that the system is secure, I really do. Let's hope it doesn't come to pass.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<proto> Not your signing key, not your beacon eth. There, education is that simple. The front-running issue is specific to staking services having a signing key prematurely. A user can protect themselves, without relying on Eth1 deposit contract magic, if they follow the protocol outlined by Danny in the issue. And even better, the user has time to reconsider the trust in the staking service, and not give them their part of the signing key. And it is a start for multi-party use, if you want to take it further.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<djrtwo> --------------------------

eth2 call in 11.5 hours
agenda: ethereum/eth2.0-pm#123
stream: https://www.youtube.com/watch?v=kt59-FEeWTI
youtube chatbox: https://www.youtube.com/live_chat?v=kt59-FEeWTI&is_popout=1

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<herman> What is the zoom link for the call?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> call in 24 minutes:
zoom: https://ethereumfoundation.zoom.us/j/820456146
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> call now!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<benjaminion> And from me: https://hackmd.io/@benjaminion/Bk9BW7PZI
Workshop the day after Stanford Blockchain Conference Feb. 22nd
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
Hi all, I'm wondering whether there's more definition available for the 'bonding' mechanism to share ENRs which are then added to the Discovery node table in order to be trusted for FINDNODES queries. afaict clients are statically bootstrapping ENRs into their node table.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Jannik> > shahankhatch

Hi all, I'm wondering whether there's more definition available for the 'bonding' mechanism to share ENRs which are then added to the Discovery node table in order to be trusted for FINDNODES queries. afaict clients are statically bootstrapping ENRs into their node table.
@telegram bridge The bonding mechanism is described in these two documents:

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch (in reply to @Jannik)
<telegram bridge> I've already gone through those docs; they don't describe the bonding mechanism of how ENRs are shared. There's some mention of Kademlia but it's not part of the spec.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jannik> ENRs are requested with FINDNODE messages and sent with NODES messages. FINDNODE messages are sent as part of the lookup process which the second document I linked to describes.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
A FINDNODE query can only be issued after a session is established. If I'm a single peer with another node's ENR, and that node doesn't have my ENR in their node table, they won't respond. Similarly, after issuing a FINDNODE query which returns ENRs, the ENR is known only to one party, however the specification requires that the target peer have the ENR of the source node. So there's a data race condition without a separate ENR sharing mechanism, which is what Kademlia has been proposed for.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
In particular, the phrase "Node A must have a node record for node B and know B's node ID to communicate with it." is the ambiguous part of the spec on the wire page.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jannik> Node B doesn't need to know node A's ENR. They'll just respond to the endpoint where they got A's message from.
<Jannik> In their response, they're supposed to include "the highest known ENR sequence number of node A's record.", but they can just use 0 if they don't have any
<Jannik> that's what trinity does at least and what I think makes the most sense, that's probably something the spec should clarify
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
I think node B responding anyways makes sense, such as with a seqnum of 0. It seems though that node A's ENR is never transmitted to B during the handshake.
<telegram bridge> shahankhatch
Thanks for pointing me to Trinity's approach. A closer look there shows the following constraint check on presence of a peer in the node table, if I am reading that correctly? https://github.com/ethereum/trinity/blob/7224a5a8da41e77d36c03f7e5f5e6a7b6771fa5f/p2p/discovery.py#L692
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jannik> A sends their ENR to B as part of the WHOAREYOU packet
<Jannik> the code you're looking at is for discovery v4 (used for eth1). v5 is here: https://github.com/ethereum/trinity/tree/7224a5a8da41e77d36c03f7e5f5e6a7b6771fa5f/p2p/discv5
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
Thanks, Jannik. That's very helpful. Much appreciate it.