Collators are not full nodes. They are somewhat like miners in Ethereum 1.0. Full nodes remain unrewarded with sharding.
The entry ticket for a proposer on a single shard is PROPOSER_DEPOSIT + MIN_PROPOSER_BALANCE which is currently 1.1 ETH.
Too many collators would not reduce throughput (it would allow for collators to secure more shards, i.e. more throughput). What do you mean increase latency? The main reason for having a high deposit is overhead in to main chain from the SMC.
We will use blockhashes in phase 1 as described in get_eligible_collator. This is imperfect (because of grinding opportunities by miners) but good enough for now. You can find some code for the old spec here.
It’s just a simple keccak hash on the concatenation of the inputs. Both get_eligible_collator and compute_header_hash are helper functions added for clarity of exposition. They can be made private.
Well spotted
I fixed it to proposer_registry[proposer_address].balances[shard_id].
Well spotted, fixed ![]()
If we need a new SMC then the NETWORK_ID (part of the shard ID) will be updated. I have added SMC_ADDRESS to the list of parameters.
I’m not a native English speaker either but I think you may be right. I’ve followed your suggestion.