by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 20 2019 16:01
    gitcoinbot commented #110
  • Jun 20 2019 15:13
    gitcoinbot commented #110
  • Jun 20 2019 15:13
    gitcoinbot commented #110
  • Jun 19 2019 14:58
    mkeen commented #110
  • Jun 19 2019 12:34
    hrishikeshio commented #110
  • Jun 19 2019 01:47
    mkeen commented #110
  • Jun 10 2019 09:19
    kuhnchris commented #110
  • Jun 10 2019 01:12
    mkeen commented #110
  • Mar 28 2019 02:21
    ChihChengLiang closed #176
  • Mar 28 2019 02:21
    ChihChengLiang commented #176
  • Mar 28 2019 02:20

    ChihChengLiang on master

    deprecate repo Merge pull request #177 from Ch… (compare)

  • Mar 28 2019 02:20
    ChihChengLiang closed #177
  • Mar 28 2019 02:19
    ChihChengLiang opened #177
  • Mar 10 2019 08:27
    gitcoinbot commented #152
  • Jan 24 2019 11:20
    hrishikeshio opened #176
  • Jan 24 2019 07:46
    kuhnchris commented #110
  • Jan 24 2019 07:40
    hrishikeshio commented #110
  • Jan 21 2019 22:10
    kuhnchris commented #110
  • Aug 22 2018 21:01
    vs77bb commented #152
  • Aug 22 2018 21:01
    gitcoinbot commented #152
Paul Hauner
@paulhauner
(can move this into sharding thread if you think that's best)
Chih Cheng Liang
@ChihChengLiang
The CASPER_BALANCE approach is convenient for the contract version because it is easier in evm to issue the voting reward with pre-stored ETH. In the beacon chain, the issuance of reward can be just implemented like how the mining reward is issued currently.
Paul Hauner
@paulhauner
Thanks!
I'll update my comment with what you said :)
(if that's ok?)
Chih Cheng Liang
@ChihChengLiang
No problem, feel free to do anything :D
Paul Hauner
@paulhauner
Thanks!
GagziW
@GagziW
Assuming 312.500 active Validators and 1024 Shards ==> Shard Committee Size = 305. How are these 305 Validators in a Shard now allocated to the slots? @Eth-Gitter-Bridge The committees per slot SHARD_COUNT / CYCLE_LENGTH always results in 1024/64 = 16, assuming a fixed amount of shards. 16*MIN_COMMITEE_SIZE >> 305 Validators though. So how are the 305 Validators allocated to the 64 slots within the shard?
Help is highly appreciated :)
Mikhail Kalinin
@mkalinin
@GagziW checkout a diagram in this section https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ?view#Helper-functions. It's a good representation of how validators committees are defined. First, active validator's set is shuffled, then it divided into slots, in your case there are 4,882 validators per slot. Then calculating number of validators per shard: 4,882 / 1024 = 4. And it ends up with breaking down validators set to a set of slot-shard committees, each one of size 4.
btw, it's better using https://gitter.im/ethereum/sharding channel for such questions
terence tsao
@terenc3t
Hey guys, during dynasty transition. Shouldn’t we also setdynasty_start to block.slot_number?
This is all the steps, but I think we are missing dynasty_start
Set crystallized_state.dynasty += 1
Let next_start_shard = (shard_and_committee_for_slots[-1][-1].shard_id + 1) % SHARD_COUNT
Set shard_and_committee_for_slots[CYCLE_LENGTH:] = get_new_shuffling(block.parent_hash, validators, crystallized_state.dynasty, next_start_shard)
Danny Ryan
@djrtwo
Yeah, I think it is going to be set dynasty_start = crystallized_state.last_state_recalc
Need to add initial values for dynasty start and some other vars as well
terence tsao
@terenc3t
Cool. I’m now implemeting dynasty transition for pryzm. Let me know if there’s other vars we should init when you get a chance : )
Danny Ryan
@djrtwo
Nice! I mainly implemented today. Have just those two fixes now. Adding some testing tmw
Mamy Ratsimbazafy
@mratsim

I’ve ported the fork choice rule to Nim: https://ethresear.ch/t/beacon-chain-casper-ffg-rpj-mini-spec/2760/13 and https://github.com/status-im/nim-beacon-chain/tree/master/beacon_chain/fork_choice_rule.

This is typed (including different hash types for block hashes and signature hashes).

It’s not v2.1 ready though and completely stand alone from the rest of the beacon chain.

isan_rivkin
@Isan-Rivkin
Hi, Casper FFG Question: How is Casper resistent to Long-Range Attacks ? I know usually PoS uses "checkpoints" every few blocks. This is a very centralized solution. Is Ethereum going to do this differently ?
Alex Stokes
@ralexstokes
@Isan-Rivkin the general idea is that Casper clients will sync the chain at least once every so often. This frequency, the withdrawal period, can be tuned so that it minimizes the feasibility of a long-range attack while not demanding too much of clients. It is a pretty big change in security model from a purely proof-of-work consensus. https://ethereum.stackexchange.com/questions/15659/what-is-weak-subjectivity and the linked blog post https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
isan_rivkin
@Isan-Rivkin
@ralexstokes Thanks!
Benjamin Cordes
@benjyz
isn't Pow/PoS switch completely different in this regard? Nxt was pure PoS. in such a system much depends on the initial allocation. I think the big disadvantage of a switch is that it messes with the initial conditions ("weak immutability" if you will). i.e. at some point when things scale there is no mandate to make a decision to switch.
Grady Laksmono
@glaksmono
So, when are you guys going to launch this?
Jacques Wagener
@jacqueswww
when it's ready.
:P
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> btw is anyone from lighthouse and nimbus in here?
Jacek Sieka
@arnetheduck
@vbuterin ping
Danny Ryan
@djrtwo
lighthouse is asleep in australia
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> 👌 👌
<vbuterin> just want to make sure we're including everyone
<vbuterin> 😊
Jacek Sieka
@arnetheduck
thought lighthouses are needed when it's dark ;)
Paul Hauner
@paulhauner
All the ships have GPS now, turns out we’re not really needed. That’s why we pivoted from illumination to entropy and validator management.
Danny Ryan
@djrtwo
🤣
wanderingbort
@wanderingbort
Hello! Is this the best channel to ask casper protocol questions? Or is it focussed on the testnet/contract?
Danny Ryan
@djrtwo
This is a good place
wanderingbort
@wanderingbort
So, I think I'm missing a key part of the base protocol, I'm going to throw up a case (probably look dumb) and learn i the process :)

Give this block tree:

 Root
    /\
   /  \
 C'1  C"1
  |    |
 C'2  C"2
  |    |
 C'3  C"3
  |    |
 C'4  C"4

and these super majority votes:
Root -> C'1
Root -> C"2
C'1 -> C'3
C"2 -> C"4

Haven't we finalized checkpoints C'1 and C"2 on disparate forks without violating any of the slashing conditions?

Danny Ryan
@djrtwo
Neither C’1 nor C’’2 is finalized. You have to have a supermajority link to a direct child to finalize the parent. Root -> C’1 finalizes root. That is it for finality here
wanderingbort
@wanderingbort
Ah, so finalized requires a supermajority vote where h(t) - h(s) == 1?
Danny Ryan
@djrtwo
yes — from the casper paper "A checkpoint c is called finalized if it is justified and there is a supermajority link c → c′ where c′ is a direct child of c."
wanderingbort
@wanderingbort
yes, thats what I'm reading. I admit it is there. As that becomes a very important quality of the rest of the paper, if I may suggest, giving that link a proper name and defining it more explicitly may help avoid people like me in the future looking dumb :)
Danny Ryan
@djrtwo

You’re right. This is a common source of confusion and could be made clearer in the paper. Even pointing out that it is a common source of confusion and should be noted!

and you don’t “look dumb”. there’s a lot going on in the paper and you clearly a groking it. Glad you came here to ask

wanderingbort
@wanderingbort
Ok, so given the slashing conditions. Lets say all validators reveal their votes simultaneously. If finality must proceed by exactly 1, a reveal of 50/50 split of votes for Root -> C'1 and Root -> C"2 put the protocol in a state where no finality can proceed without an altruistic slash. Which means that proper game theory is to wait to establish a higher justified checkpoint as guidance. However, as voting for a justified checkpoint at any height puts you at risk of not being able to vote for the finality of that height (lest you violate the h(t1) == h(t2) slashing condition) you also cannot really vote in the blind there. It seems like being the first to reveal is far riskier than being the last to reveal and I am trying to figure out the mitigation for that so that game theory doesn't lead stake to stop casting votes out of fear or being put into a position where they must resign or be slashed.
the leap-frogging votes was what I thought was the path out of that pickle. But it was obviously not (and had other problems)
wanderingbort
@wanderingbort
actually, now I'm really confused. Even a vote for a link whose h(t) - h(s) > 1 means you have to slash yourself to vote for the link that can be used for finality because that would be a different link with h(t) - h(s) == 1 but h(t) is the same between these votes which is a slash. I must be off the right path so, I'm going to hunker down, light a campfire and wait for help haha
Oh, crap. Ok. its that finality is not necessarily built on finality. Finality can skip several blocks as it is built on justified links with a specific form of link after it.
I think I'm square now.