OK, I’m happy to start working on one now, in Vyper. If anyone wants to work on it with me, feel free to say so on https://gitter.im/Drops-of-Diamond/Development. This contract will need rewriting to match with the above spec.
Generally, I think it would make sense to have implementations not only in Vyper but also in Solidity. Just to have two independent implementations that we can test against each other. Not sure though if this is the right time for that, or if we should rather wait until the spec has matured a bit.
I guess that a problem with that is if you actually deployed both implementations, I think you would need separate contracts for each implementation on the main net.
That’s true, but for testing we don’t need to deploy anything. We can test locally.
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).
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.
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).
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.
That’s a bug in the infographic! Just corrected it, thank you!