-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misc. questions from assertion flows #30
Comments
Yes, they're distinct. Since P2P IDs are paired with IP addresses, any node on the network knows the real world identity (or pretty close) of any P2P ID. Node IDs are associated with a coinbase account via the ATX. If the two identities were the same, or easily associated, there would be zero privacy for miners. It could also help attackers perform targeted attacks against specific miners, ranging from a simple DDoS to a full-on eclipse attack. While simply separating the IDs is not enough (network analysis can still be used to associate the two), it's an easy first step in the right direction. Dandelion and similar privacy features can be added on later.
They're implicit. The existence of a valid block in the mesh implies that the appropriate share of the layer reward and fees has been added to that miner's coinbase account, as declared in the matching ATX. It's each node's responsibility to calculate the rewards and apply them to the global state.
There's no maturation period. The reward (incl. fees) from a block can be spent as soon as any other transaction included in that block can be spent--once the hare completes for the relevant layer.
Possibly. If everyone's honest, then everyone's blocks would vote the same (or close enough to the same) so that the lack of hare would make little difference. Having the hare makes balancing attacks (see if a block has close to half of the votes for it and vote so that it stays that way), which can prevent the network from reaching consensus, harder to pull off. @barakshani can probably shed more light on this.
What's an inactive miner? Not every miner participates in the hare at every round. Other miners just listen for hare messages and validate everything. The term "hare committee" makes it sound like there's a closed set of miners that participate in the hare protocol until it completes, but that's misleading. Each miner could be eligible to participate in any round of the hare, different rounds have a different set of participants. Hare processes that take more rounds to complete also involve more miners and since it's impossible to predict how many rounds will be needed, everyone has to be ready to participate at a moment's notice.
If a node receives a syntactically invalid block, like you describe, it discards it and doesn't gossip it to neighbors. In the future we plan to also disconnect and blacklist any peer that passed a syntactically invalid message to us. If the block is syntactically invalid and signed by the miner, we may want to blacklist the miner, as well, but that's trickier. If we want to do that, we'd need to publish some kind of proof of the wrongdoing on-mesh, so that there's consensus about that, and it's not clear that it's worth it.
If everyone's honest and everyone sees the whole network, the number of block eligibilities in an epoch is fixed, up to a rounding error, with one exception: if there are more miners than the number of blocks in an epoch - each miner will be eligible for one block and there will be more total blocks than planned. After each miner calculates how many blocks they are eligible for in an epoch, they draw, with replacement, that many layers from the epoch, and those are the layers in which they are eligible for blocks. Because it's with replacement, a miner could be eligible for multiple blocks per layer. Because each eligibility has the same probability to fall in each layer, the number of blocks per layer is distributed binomially. All of this is in the honest case, since attackers could produce more blocks than they are supposed to (they'd receive a smaller share of the rewards per block in that case--pending implementation). It also ignores the benevolent case where miners could publish an ATX and then not publish the blocks they're eligible for, e.g. because they're offline. @barakshani please correct me if I'm wrong about anything here. |
Thanks @noamnelke. One followup question:
I understand the case where a block references a non-existent ATX, or an invalid ATX, and is thus a syntactically invalid block. What if the block references a valid ATX, but the block was produced in the right epoch but the wrong layer (i.e., a layer that the miner wasn't eligible to produce a block in)? How can you determine that the block is syntactically invalid? |
(Moved the list of questions up to the top to maintain one canonical list) Some more recent questions - @noamnelke @barakshani would appreciate your help with these. Thanks! |
The way eligibility for a block is proven is by signing a message which includes a counter value. The value must be less than the number of blocks the miner is eligible for in the epoch and each value can only be used once. The layer is derived from the signature. |
Keep in mind that a layer is defined to be "a set of blocks". Hence, time-wise you cannot publish a block in the "wrong layer". If it's not the "right" time, then the block would be considered early/late, but it is still syntactically valid. What Noam refers to is more into the layer definition: a block explicitly specifies which layer it belongs to, and this is part of the eligibility proof, hence can be verified (note: it could also be implicitly derived from the proof). |
Consensus
|
Other |
So there's no punishment to prevent an attacker from producing more blocks than they're supposed to, say, lots more? What prevents someone from doing this? I understand that they won't receive any extra reward for doing so - is that the only thing? |
We plan to implement bounds for the number of seen active miners. This means that a spammer (a type of attacker) is limited in how many spam blocks they can create, given their investment. So a small space-time investment will allow some spam, but nothing crazy. Limited damage, combined with no rewards, should discourage spammers from choosing this route. |
The "limited damage" part is important to prevent severe griefing attacks :) |
Consensus
What would happen if we had a Hare but no Tortoise?Without the Hare, would pbase lag further behind? I.e., does the Hare help pbase "keep up"?How do inactive miners achieve Hare consensus with the active Hare committee participants? Do they just passively watch gossiped Hare protocol messages?How close do we expect pbase to stay to the current top layer? Is there some threshold that we expect it to stay within - let's say, assuming normal assumptions hold and there is no attack. Another way of phrasing the question: is there an N such that, if the difference between pbase and the current top layer exceeded N, we'd worry, or say there's an issue/some assumption had failed? Is there some formula we can use to calculate how large we expect N to be at any given time?The Hare expects all of the blocks for a given layer to propagate throughout the network before the Hare kicks off, after thehare-wakeup-delta
parameter, right? Doesn't this mean that it punishes blocks that arrive just a little bit late - i.e., blocks that could've arrived later if there were no Hare and were only a Tortoise?How, exactly, is the leader chosen in Hare round 2? Does each active participant in this round include the output of a VRF in their proposal? What does the Hareexpected_leaders
flag do?When exactly, and how, does each node know its participation status (active/passive) in each Hare round, for each Hare execution cycle, in each layer?Does Hare round two actually broadcast an "accept" message at the end of round two (as documented here)? This doesn't seem to line up with the ADDNR18 paper (and it may be my mistake).What happens if there's a problem in the Hare pre-round, e.g., there's no (or insufficient) overlap in the pre-round views? Would Hare terminate with an empty set?from Write a wiki page explaining Spacemesh consensus in context #27 (comment): Tortoise doesn't involve message-passing among nodes, does it? So what does it mean to say that Hare is more efficient in terms of communication complexity?from Write a wiki page explaining Spacemesh consensus in context #27 (comment): Without Hare, is the network more vulnerable to attacks? If so, how? How would this play out in practice?Blocks point to previous blocks, via the view and the Hare votes. Which layer should the block point to blocks in? Is there a limit? The white paper says “recent layer”, what does that mean?Another way of asking the question: a miner would be incentivized to be “safe” by voting for older blocks, i.e., blocks before pbase - what incentivizes them to vote for more recent blocks? Don’t we want them to vote for the most recent ones they’ve seen? Due to latency won’t there be blocks that show up late and some miners consider contextually invalid? So I want to point at blocks where I’m certain there’s no chance someone would think it’s invalidVoting: Does a block have to vote for other blocks? What if it doesn’t? (And if not, why would I bother?) Why does a block need to include a view/“Visible Mesh”?Is there a limit to how many blocks a block can vote for? Is there a minimum? IOW, what exactly does the protocol say about voting?Is PoST used for anything other than generating an ATX/blocks? E.g., do you need an ATX (for this epoch) to be eligible for Hare?Other
Is the node ID keypair distinct from an ephemeral P2P identity keypair that's regenerated when a node restarts? Do nodes have no knowledge of the node ID public key of their neighbors?FeesWhat happens if a miner creates and gossips an invalid block? (I.e., the miner is not eligible to produce a block in the current epoch, or layer)The number of blocks per layer is an average, right? (I.e., total blocks per epoch divided by number of layers per epoch gives us average blocks per layer in that epoch.) What's the probability distribution of the number of blocks per layer? Is it thus hypothetically possible that a given layer could have very few, or even zero blocks?Does the miner submission/input/request to a PoET server include/is specific/tied to to a specific epoch? Or could the PoET proof be used for any epoch?Would gossip protocol gossip e.g. an ATX before it had seen the PoST proof that it references? Is it possible that a node receives an ATX without having seen the PoST proof it references? What happens then?Does an ATX have contextual validity?Why does the block contain both the minerId and a Signature? Why can’t we just extract the minerId from the Signature?And why doesn’t the whitepaper include the Signature under block?What “happens” to a contextually invalid block? Does it just disappear?Do blocks include transactions or just pointers to them? Just txid, right?What was the exact bug that caused the testnet fork? How do we know it won’t happen again?Do you ask one peer or multiple/all peers for a block, tx, atx, etc. as part of sync?The syncer will nevergetLayerFromNeighbors
for an older layer, right? Only the top/current layer? And everything else happens recursivelyWhy are hare-wakeup-delta and sync-validation-delta different? Why do we set/tweak the first for the testnet but not the second?Related: #27
Re: #29
CC @ilans
The text was updated successfully, but these errors were encountered: