There will a be bunch misc significant differences (some of which I listed as candidates in the phase 2 roadmap, including asynchronous cross-contract calls only, account abstraction, eWASM, archive accumulators, storage rent). I expect these differences to add up to a totally different EVM implementation, although a lot of the differences may abstracted away in the higher level programming languages.
That should be collator pool, thanks! Fixed 
This may be silly, but, should/could this be the signature of a proposer at a given address in a proposal? Or is that overkill? I wonder because proposer address is spelled out in more detail and it made me think that this term could be more complete. But this may be unnecessary.
Is the last proposal_commitment_slashing duplicate?
I think it is a very good start! Now the devil will be in the details 
Cryptoeconomic proofs will be a nontrivial part since the current version Truebit protocol is only weakly secure !
Also imho protecting aganst frontrunning attacks will be a big issue across all components of the system.
Please help with what I’m missing here, but I don’t understand Phase 1. What good are collations without state transitions? What are you collating? Why would anyone submit a Blob if that blob isn’t going to actually do anything?
I’m not sure I understand. Do you mean that the proposer address could be part of the proposal body as opposed to the proposal header?
Fxed
Phase 1 has no TrueBit protocol. Do you mean the phase 3 execution game with executors? If so, why is weakly secure?
We’re reducing consensus to its core: data availability. Execution (transactions, state, state transitions, validity, state roots, …) is a simpler deterministic execution game (not a consensus game). The default execution engine (the sharded EVM) will be added in phase 2, and will provide “meaning” to blobs that pay gas fees to use the EVM.
Alternative execution engines are possible, and this is facilitated by the natural evolution of consensus abstraction. Taking a historical perspective:
I think I worded myself wrong … It may be super strongly secure What I meant is we need a document that analyzes possibilities of front running attacks throughout the system.
If some agent is paid for some work, there is always a possibility for someone else steal the submission and get paid. Since there is lots of money potentially involved, in my opinion every single potential vulnerability needs to be analyzed.
IMHO Ethereum needs to stand out and be different by tightly addressing security. There are many projects on the market that imho will crash and fail by not addressing security seriously enough.
For the execution game with executors
“Here is one simple proposal. Allow anyone with ETH in any shard to deposit their ETH (with a 4 month lockup period), and at certain points (eg. once every Casper epoch) give depositors the ability to make claims about the state at some given height. These claims can be published into the blockchain. The claims would be of the form [height, shard, state_root, signature]. From the point of view of a node executing the state, a correct claim is given some reward proportional to the deposit (eg. corresponding to an interest rate of 5%), and a false claim means the claimer is penalized.”
Is this vulnerable to front running? Judging from the description it could be, since I could do no work, and simply intercept and resubmit someone else’s claim …
This is a particular example, though. A more general question though is should we have a separate document listing all potential vulnerabilities/weaknesses of the protocols and their impact from low to high.
Yes, but if you front-run by copying another executor then you’re exposing yourself to a griefing attack from that executor voluntarily burning some portion of their deposit to burn yours. Though I do agree that these kinds of issues absolutely need to be fully considered.
I need to figure out how to implement this in Rust, where a struct accepts an address as an argument. Cross-posting this at https://gitter.im/Drops-of-Diamond/Lobby?at=5ab485e45f188ccc15e8c909, Rust-specific discussion can be had there.
AIUI this is saying that address is an int128 type, but in current implementations it is a binary data of length 160 bits.
I’ll just define this like so for now:
struct CollatorPool {
collator_pool_len: int128,
// size of the collator pool
collator_pool: [Address; collator_pool_len],
// array of active collator addresses
empty_slots_stack_depth: int128,
empty_slots_stack: [int128; empty_slots_stack_depth],
// stack of empty collator slot indices
empty_slots_stack_top: int128, // top index of the stack
}
What is the depth of empty_slots_stack? Is it 1024 words = 1024 *32 bytes like the current stack depth?
Or should empty_slots_stack: int128[int128] actually be written in Rust like empty_slots_stack: HashMap<H128, H128>?
Why make this an arbitrary byte array? Is that for abstraction reasons for custom signature schemes like Lamport signatures, ECDSA, etc.? This is actually meant to be a fixed byte array but the syntax is wrong, see my comment below.
The int128 is the collator’s id in the array, not the address itself.
OK, thanks for clarifying. In that case I’ll need to figure out how to write collator_pool: address[int128] in Rust. I’ll ask around.
I think Alternatively this could be a hash map, which seems to be the most plausible. I’ve used collator_pool: address[int128] is meant to be used like CollatorPool.collator_pool[int128], returning the address of the collator, i.e. you find the address (as a custom type) of a collator by accessing it’s ID in the collator_pool. But clarification would be good as it’s not very clear. Alternatively it may mean or be intended to be used like CollatorPool.collator_pool[address}, which will return the collator’s IDas an int128 if the collator exists, or produce an error otherwise. In any case it’s not very clear, and others on Stack Overflow couldn’t tell either.collator_pool: HashMap<address, H128>. (I’ll release the full code soon, but H128 is a type from the crate ethereum_types.)
OK thanks, so address is the value type and H128 is the key type so swapping them around we have collator_pool: HashMap<H128, Address>. @JustinDrake it would be helpful if you could clarify in the spec that this is a map in Vyper, which corresponds to an associative array.
It would be good to get a spec for the sharding p2p network. I guess that’s an R&D project.
I think I still need an answer to this, but I guess we have to wait until phase 2 when the EVM is defined?
Why does the empty slots stack need to have any limits at all?