Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 19 21:38
    gitcoinbot commented #1303
  • Sep 19 13:05
    mcdee commented #1356
  • Sep 19 12:13
    ericsson49 opened #1409
  • Sep 19 12:11
    ericsson49 opened #1408
  • Sep 19 10:11
    mcdee commented #1183
  • Sep 18 00:03
    gitcoinbot commented #1303
  • Sep 17 17:00
    djrtwo closed #1351
  • Sep 17 17:00
    djrtwo commented #1351
  • Sep 17 15:00

    djrtwo on v08x

    Network specification update Adds chunked responses to the R… Apply Danny's suggestions and 8 more (compare)

  • Sep 17 15:00
    djrtwo closed #1404
  • Sep 17 14:03
    CarlBeek synchronize #1361
  • Sep 17 14:03

    CarlBeek on carl-keys

    Simplify keystores. No longer r… (compare)

  • Sep 17 13:43
    CarlBeek synchronize #1361
  • Sep 17 13:43

    CarlBeek on carl-keys

    Specify Bech32 encoding of PubK… (compare)

  • Sep 17 08:29
    hwwhww labeled #1404
  • Sep 16 19:54

    djrtwo on dev

    Update 1_custody-game.md Fix t… Update 1_custody-game.md Update specs/core/1_custody-gam… and 2 more (compare)

  • Sep 16 19:54
    djrtwo closed #1407
  • Sep 16 19:26
    djrtwo synchronize #1407
  • Sep 16 17:41
    CarlBeek synchronize #1361
  • Sep 16 17:40

    CarlBeek on carl-keys

    Improve readability of SSZ type… make nil-count randomization wo… Update libp2p networking spec and 29 more (compare)

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[discord] <vbuterin> in which case it has to be absolutely 100% always uniqueness, not usually-and-penalty-if-there-isn't
[discord] <JustinDrake> Why?
[discord] <vbuterin> because otherwise the vote formats get way more complicated
[discord] <vbuterin> that said, it does not seem like we're doing binary voting now
[discord] <JustinDrake> Wouldn't votes have to reference a hash anyway in case the main chain reorgs?
[discord] <JustinDrake> And if votes don't go onchain, they can reference proposal hashes because there's less of a gas concern
[discord] <vbuterin> ah, but they could just reference a recent block hash
[discord] <JustinDrake> Couldn't they do something similar. Reference a hash of proposal hashes
[discord] <JustinDrake> And if there's ambiguity, then try the various possibilities
[discord] <vbuterin> so basically, pushing proposals on chain is just a convenient infrastructure for forcing everyone to converge toward the same hash of proposal hashes
[discord] <vbuterin> so there's no worst case exponential blowup of hashes to check
[discord] <vbuterin> I agree it's not striclty necessary; it's justa nice convenience
[discord] <vbuterin> though as I said, I don't think it's necessary in the "one meta-committee per period" approach
[discord] <JustinDrake> Because we're not restricted by gas?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[discord] <vbuterin> because there's only one thing to choose for each shard in any case
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[discord] <JustinDrake> In the meta-committee idea, I'm imagining the committee chooses 100 fully notarised checkpoints, one for each shard. What if some shards have multiple fully notarised checkpoints, or some shards have no fully notarised checkpoints. Doesn't this create an exponential blowup in the possible meta-checkpoints?
[discord] <vbuterin> > What if some shards have multiple fully notarised checkpoints
[discord] <vbuterin> so first of all, that would require 1/3 of a committee slashed
[discord] <vbuterin> second, the meta-committee has to distribute across the ethereum network an object that contains all the headers and the signatures, so users can check the meta-root for themselves
[discord] <vbuterin> so think of the hash that the meta-committe notarized as being like a level-2 header root
[discord] <JustinDrake> How does slashing work? Each shard is running a separate Casper FFG loop?
[discord] <vbuterin> ah no
[discord] <vbuterin> they just vote
[discord] <vbuterin> it's definitely possible for bad proposers to split them half and half, in which case nothing gets finalized for that shard in that period
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[discord] <vbuterin> so minor bad news
[discord] <vbuterin> any kind of RNG based on PoSW basically amounts to a scheme that reveals a number when someone submits any valid solution to a particular predicate
[discord] <vbuterin> (the verification function for the PoSW)
[discord] <vbuterin> hence it's basically equivalent to witness encryption
[discord] <vbuterin> and in fact, you can do it with witness encryption and unboundedly long trusted setup, but I think that's the only way
[discord] <vbuterin> analysis of why I think simple RANDAO is totally fine
James Ray
@jamesray1
I think I'm going to only refer to research when there is no more development to be done without referring to research, or when there might be better approaches to development. Otherwise I spend too much time reading if I try to keep up with sharding research, even if it's just phase 1. For any changes to specifications you can post at
https://gitter.im/Drops-of-Diamond/Development or set up a telegram channel for such announcements.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[discord] <vbuterin> @jamesray I think at this point, just getting the minimal spec done is enough; by that point, the research will have solidified much more
[discord] <vbuterin> ^ massie exploitability reduction to RANDAO
James Ray
@jamesray1
@vbuterin, I agree. I think it's more practical to just develop the stuff that is suitable enough to be developed now (where there's no drastically different and better way to develop such stuff), then when that's done, look to research if needed to develop more stuff.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

[discord] <Hudson Jameson (souptacular)> ATTENTION

Bridge is going down for maintenance. Shouldn't take too long. WiIl ping when it is back up.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Hudson Jameson (souptacular)> ATTENTION

The bridge is back up. I tweaked the username formatting so it wouldn't be so bulky and display "discord" or "gitter" everytime. Thank you!

Tim Siwula
@fluffypomeranian
With regards to local shard state storage, which db performance attributes should have priority? e.g. read or write optimized, latency, concurrency ...
Preston Van Loon
@prestonvanloon
@tcsiwula I would say that database performance should prioritize writes with minimal disk footprint. The real pain point for full clients is syncing. From my understanding, syncing leans write heavy as the client is downloading, verifying, and writing the chain to disk. Once the client has reached the head of the chain, then the DB experience relatively low load compared to the sync
James Ray
@jamesray1
Yes I agree that getting full sync times down and more accessible for low- and medium-end computers is important. As mentioned before, I haven't been able to finish syncing with Parity with warp sync, and I've given up because it slows my computer down when I try to use it, and I have to keep turning it on and off, which doesn't seem to be sustainable if I managed to catch up. I'll make a high level note for context that I/O is the major bottleneck for scaling, so we need to solve that more specifically than general sharding, ideally evening out resource use so that not any one tends to bottleneck more than the other, where the resources are computation, bandwidth, storage, I/O, which all encompasses any computational tasks like proposing transactions (computation if executing them for verifying validity, plus storage and I/O), propagating blocks/collations (bandwidth), and verifying transactions (computation and bandwidth if interactive). It'd be interesting to see quantitative analysis on the amount of reads and writes at different times over the network to get a better idea of what to prioritize. Perhaps reads use up more resources than writes, or maybe they take more time over time if storage builds up, and are also important for loading dapps. While writes tend to bottleneck at particular times e.g. ICOs, although they would also scale on average over time with increasing usage.
Light sync works fine though.
Piper Merriam
@pipermerriam
@prestonvanloon don't take this a gospel but my understanding is that disk io is still the bottleneck after fast sync completes (as block processing is bound by disk io)
James Ray
@jamesray1
RFC: SPECTRE and PHANTOM by Aviv Zohar and Yonatan Sompolinsky. https://medium.com/@avivzohar/the-spectre-protocol-7dbbebb707b5, https://www.coindesk.com/spectre-creators-propose-phantom-blockchain-protocol/. I just read these articles, I haven't had time to read the papers yet. I see parallels between the discussions we have had on DAG design and voting. Thanks @ChosunOne for suggesting to read this.
James Ray
@jamesray1
Eli
@elihanover
Can anyone point me to any discussions on modifying the VMC to allow for varying gas limits for shards? As there can be up to 1 collation per shard per period, why not grant certain shards a higher gas limit and allow their collators to submit collation headers anytime up to a few periods later? If we keep the collators' performance requirements between shards proportional and increase the collator's reward proportional to the gas limit, this shouldn't sacrifice decentralization and would allow for higher gas txns without changing the period length. Thanks.
Philippe Castonguay
@PhABC
@JustinDrake Is there any plan to push the random beacon thing with the RANDAO to be at the L1 protocol level directly? Not only sharding would benefit from this.
By this I mean whether the random values will be accessible by smart contracts once inplemented.