@jamesray1@efynn@mhchia
If I understand correctly, there are deposit and balance[shard_id] for a proposer and they are two different thing. deposit is used for slashing(if the proposer did misbehave) and balance is used to pay the collator, so each of them will have their own withdraw function(proposer_withdraw_balance for balance withdrawal and release_proposer for deposit withdrawal).
But there are still a few questions left regarding proposer registry/deposit.
Since proposer’s balance on each shard is a mapping, there’s no way to clean up the proposer’s registry entry(because there’s no way to delete a mapping unless you keep track of which shard the proposer added a balance).
IIUC there seems to be no slashing condition applicable to proposer(at least for now?). Both proposal_commitment_slashing and availability slashing are applicable only to collator.
The PROPOSER_LOCKUP_LENGTH would be the same, for both balance and deposit, or just deposit?
Why have both? Why can’t the deposit be used to slash the proposer?
What if a proposer misbehave in different shards, it can be slashed as it was misbehaving in just 1? Since the slashing balance is not bound to the shards.
PROPOSER_LOCKUP_LENGTH is for deposit only and deposit is exactly used to slash the proposer(proposer’s deposit will get slashed if the proposer misbehave).
What are a proposer’s misbehaviors you have in mind? If there is one, it can be added to the slashing conditions.
For 1. proposer registry entry not been cleaned up seems not really harmful to me tho. But regarding mapping deletion without knowing the keys, IIRC it’s currently not supported by either Solidity or Vyper).
The advantage is that you can use a Merkle branch into the collation header structure which then identifies that there is a blob and that blob will definitely be processed. With RLP, you can’t tell if it’s valid without verifying the whole thing.
What I would like to see is formal proofs of security for proposed specifications like this, covering security in fundamental properties, e.g.: “consistency and liveness in an asynchronous network with adversarial delays that are a-priori bounded, within a formal model allowing for adaptive corruption and spawning of new players, assuming that the computational puzzle is modeled as a random oracle.” This paper already proves that Nakamoto consensus blockchains already have these properties, and whatever changes we make should still have these properties. (With Casper, the part about the computational puzzle is not applicable, but the proposal mechanism should still be as random as practical or pseudorandom. Additionally there should be an analysis of security with synchronous cases such as cross-shard synchronous contract calls and internally synchronous zones.) Also do an analysis of the tendency towards centralization vs decentralization would be good, as well as whether there are asymmetries (particularly economic ones) between participants (e.g. like this analysis: Exploring the proposer/collator split), which can lead to a different Nash equilibrium than the intended one. Additionally assess whether there are externalities, which should be internalized for sustainability.
Then again, if you are just going to have a testnet without execution, then these research topics are less important.
The links to this post have broken because the heading has been updated. Please change it back to “Sharding phase 1 spec”. The update at the top of the post is clear enough.