That’s true, but for testing we don’t need to deploy anything. We can test locally.
2 Likes
Should there be slashing condition for collator submitting more than one header?
Or it can simply be prevented by adding checks in addHeader function(keeping track of the period the latest header is submitted). At the cost of additional storage slots used and extra gas cost(>5000).
1 Like
We should change the terminology to state-minimized clients rather than stateless clients. We don’t want to offload all of the state into secondary markets, but give people a choice between storage rent on the blockchain and secondary markets.
Good point, seems like a slashing condition would be more efficient.
A collator can be a proposer at the same time,this is unfair to other proposers who no collator supports. In the end, is it possible that the independent proposers will disappear?
I’m not very good at English, I hope I’m clear enough.
In Vyper you need to specify the maxLen as an integer which represents the maximum number of bits of bytes. http://vyper.readthedocs.io/en/latest/types.html#fixed-size-byte-arrays. So what should the maxLen be? In the Yellow Paper the signature is a byte array of size 32.
E.g. proposer_signature bytes <= 8 is a one byte or 8-bit-wide byte array.
Then when you instantiate at the moment it has to be as a string, without prefix formatting, e.g. proposer_signature = "00101011".
If it’s an elliptic curve signature, as it is here, then 96 bytes. For signatures in general, 1024 could be reasonable.
1 Like
Instead of block.number I think this should say collation_header.number. (There is no collation struct in this spec, and number is not a member of collation_header, we have period and height as related members. Periods are every 5 collations. height is defined as “height: The height of a collation in a shard’s collation tree relative to the genesis collation.” AIUI in Casper heights are incremented by checkpoints, which occur every 100 blocks, or collations in this non-EVM context. We could recursively determine the block number by the period, tracing back via the parent hash until we get to a collation that occurs at the start of a period, but this doesn’t seem very efficient. In the current EVM, the Yellow Paper defines block headers as containing a number field. Thus, I think we should add the collation_number as a member to the collation_header struct. (number is a reserved keyword.)
PS, my work on the SMC in Vyper is progressing, it is available here.
No, this is correct. block.number refers to the number of a main chain block. So we have one period per PERIOD_LENGTH main chain blocks. collation.period refers to the period in which the collation gets included in the main chain. collation.period and collation.height are not equivalent as there can be periods in which no collation is submitted, or periods in which collations are submitted, but for a different branch).
1 Like
Ah OK, that’s fine. If we are going to use block.number in phase 1, independently of the EVM, we will need to somehow import block.number.
This and the previous sentences should say “equivalent to”. Why do “The proposer balances need to be emptied before calling this method.”? Can’t they be emptied during it?
@public
@payable
def release_proposer() -> bool:
self.proposer_address = msg.sender
assert self.proposer_registry[self.proposer_address].deregistered != 0
assert floor(block.number / self.period_length) > self.collator_registry\
[msg.sender].deregistered + self.collator_lockup_length
send(self.proposer_address, self.proposer_registry\
[self.proposer_address].balances)
self.proposer_registry[self.proposer_address] = {
deregistered = 0,
balances = 0
}
log.Release_proposer(self.proposer_address, \
self.proposer_registry[self.proposer_address].deregistered,\
self.proposer_registry[self.proposer_address].balances)
return True
Again, the full file is available here although it’s not finished yet.
If we are going to use block.number in phase 1, independently of the EVM, we will need to somehow import block.number.
My understanding is that the sharding manager contract will run on the existing Ethereum chain, so there is no need to do anything extra regarding getting the block number. That would only be a problem once you try to run a sharding manager contract on another shard.
Yes, the SMC will run on the main chain in phase 1. Using Vyper I believe that block.number will fetch the latest block number, but I am yet to run and test the SMC to confirm this . Later onwith phase 6 when we have an SMC in a shard and recursively have shards within shards and so on, then you would need to do a call to the main/mother shard to get the block number.
AIUI there does not need to be a balances key, because when a collator is added to the collator_registry in the register_collator function, they must have a msg.value >= collator_deposit. So by being added to the collator_registry then implicitly, their balance must be >= collator_deposit. Thus, storing the collator_registry.balance seems to be unnecessary. You can see how I’ve implemented this at https://github.com/Drops-of-Diamond/sharding/blob/develop/smc/Sharding_Manager_Contract.v.py.
1 Like
That’s a bug in the infographic! Just corrected it, thank you! 
1 Like
@vbuterin, what about including a Bitcoin-NG style approach in the roadmap (e.g. phase 5 or 6)? Blocks are distinguished validating consensus blocks and non-consensus transaction micro-blocks. Additional features include:
- a poison transaction in each microblock pointing to the header of the first block in the pruned branch as a proof of fraud, accompanied with a maturity window for the reward, within which the poison transaction must be placed on the blockchain; and
- rewards split by ~40% for the miner/proposer of a leader block followed by micro-blocks and 60% to the leader of the next block).
I’m not sure if this can be used with Casper, however.
But maybe with this proposal it is not necessary or it would be more prone to adaptive adversaries.
Does compute_header_hash() also need height: in128 and proposer_signature: bytes[8192] as arguments to match with the collation header struct fields?
I think floor(block.number / PERIOD_LENGTH) + LOOKAHEAD_LENGTH >= period >= floor(block.number / PERIOD_LENGTH), otherwise we can get only collators for the current period, right?
If this function only gets the collator for the current period, you don’t need to check in add_header for:
Since this is guaranteed by the get_eligible_collator