Restructure Codebase about cbc-casper HOT 16 CLOSED

Rounds in string generators with passing some info along with the execution string (length of round) is a good trade off :)

Notes:

• you added "display" and "save" to json string but did not remove from XProtocol parameters. Why are we pushing these two vars to the json file? My gut is that they stay out and we just add "length_of_round" which is used during certain execution environments.
• "length_of_round" needs to be part of the json file under "execution". I think this makes sense. If it is missing, it can default to 1 message per round.
• "The interval is measured in message creation." should be "The interval is measured in rounds where rounds are specified by 'length of round' measured in messages." Or something like that
• length_of_round and interval combine decently. We do lose some display info depending on the message gen scheme. If messages generated per round is fixed (like rrob or full) then no info is lost, but if validators are using more complex strategies and messages generated per round is variable, then the "length of round" probably becomes an average (or 1), and the complexity of time is lost. That said, defaulting to 1 on complex intervals is probably fine.

from cbc-casper.

@djrtwo updated with explanation of new commands.

from cbc-casper.

How are you currently stepping through time? If there's a well-defined grid step, you could give each validator a validator_delay and at each step check if current_grid_step >= v.validator_delay. If so, poll its next message, etc.

Sample validator delays from some arbitrary distribution (uniform) over the [min,max] you want.

from cbc-casper.

You also (maybe?) could add the estimator.estimate logic into the each XView's class. Since it seems all you're doing in each view is importing that function defined in a separate file.

from cbc-casper.

I think this is a good approach and agree that it will clean up the codebase and testing.
Some initial thoughts. Sorry for the poor organization. Let's hop on a call sometime in the next couple of days.

Bigger design notes/questions:

• I am worried about how execution_string is going to handle time stepping forward. I'm thinking we assume everything happens sequentially (nothing happens at exactly the same time), and that each space delimited "event" in the string counts as one time-step, rather than just each message generation. Thus our weak notion of time goes from "rounds" in the previous implementation to "events" in the protocol redesign.
  • If our weak notion of time is just related to message generation, then I think we are going to run into difficulties simulating or at least reasoning about certain network conditions/validator strategies. For example, assume all validators are waiting to receive a message from validator A before they create a new message. Validator A makes the message and it has a delay of 3. Our notion of time has now stopped because validator-A's message is waiting on three other messages to be generated before it is delivered, and the other validator's are waiting on Validator-A's message before they generate a new message.
  • If we use "events" to step time forward, we might need to model an "empty" event when generating the strings, but not necessarily when printing the strings. The empty events might be useful in creating the gifs (looks like everyone is waiting). As for creating the gifs, I think view_interval should treat every event as an interval step, rather than just the message generation.
• protocol.execute adding strings -- I think it makes sense to be able to take a protocol from some state A, add the string s, and execute from state A via s to B. There are some corner cases to think through, namely - what happens if we haven't executed through the original string passed in via the JSON? Must we first execute the json string and then the additional string or just the additional string? I would think first execute the json string and anything added later is an extension of at least that state. If you do protocol.execute(s) then protocol.execute(t) then you would be left at the state gotten to via json_string + s + t

Minor notes:

• setup --> config in the json file
• specify random seed in the json file to make deterministic for random components like "select_outputs": "random". If not specified, should output the seed that was used or should default to a known seed -- 0.
• At any point, should be able to ask the protocol questions like protocol.global_estimate
• Might want to have a more granular option than just execute. Something like step. So that one could step through the protocol execution and query the protocol along the way. step would move forward one event (space delimited item from the string)
• view_interval might just be interval or step_interval. It could correspond the number of events when a user steps. At the same time, if the user wanted a verbose output, that could be the interval at which the protocol execution (or higher level object) logs data (like global_estimate, etc)
• initial messages -- view has add_initial_messages - does this take an argument of supplied messages which come from querying the protocol's get_initial_message for that particular validator?

from cbc-casper.

@naterush also correct me if I'm wrong but it looks like there is a single protocol view that all validators keep track of. This means that all validators always have the same exact view. Do you have plans to let each validator have a potentially unique view of the chain state?

from cbc-casper.

@drewstone This is already implemented.

Network keeps track of a global_view that we use for gathering data about all messages, but each validator stores their own view in which they can only see messages that they have received and can only make judgements from such.

Sometimes the output/viewgraphs is just showing us info from the global view so we can get a global perspective on the network.

from cbc-casper.

Thanks for the great feedback. I've updated the post above to consider most of these comments.

I think that a lot of the complexity described above was a result of not having rounds (which it turns out - though they seem unnecessary, are fairly necessary). As such, I've changed the above description to have rounds again; the key here is that we only really need them when a) creating the execution string, and b) calculating when to display (if we are displaying something). Reintroducing them seems to solve all the problems, but let me know if you see any other issues.

Also, most of the minor notes seem reasonable to me. I've justified some decisions (like the separate set_initial_messages function) in the original post.

from cbc-casper.

There's one more thing I want to make sure we can handle, but I'm not exactly sure how to do it. Essentially: we need to control how initial messages are propagated.

For example: currently, we send all initial messages to everyone at the start of a binary protocol, but this leads to all messages have the same estimate for the rest of time (b/c everyone has seen everything), which isn't very interesting.

So we need more control over the execution over how these initial messages are propagated. There are a couple solutions here:

1. For some protocols, enforce that the execution strings starts with "M0-A M1-B M2-C..." as a validity condition (an error will be thrown if it doesn't start with this, for say, binary). A, B, C... are the names of the initial messages for each validator. The issue with this is that it the requires special cases in the protocol execution string generator.
2. Automatically name each initial message from the validators, but don't include them in the execution string. Note that this still requires special cases in the execution string generator string still (we have to send those initial messages still), but we lose the clarity of actually being able to see this in the execution string.
3. Do what we are doing currently, and send all initial messages to all validators before running the execution string. I personally don't like this solution b/c it leads to protocols like binary, list, and order all having super boring executions where everyone has the same estimate the whole time.

Personally, I think 1 is the cleanest solution. Any other thoughts/suggestions are greatly appreciated.

from cbc-casper.

So I figured out a way to actually handle the special case in a general manner, without doing much extra work.

Essentially: the first time a validator 0 sends a message to validator 1, they send it in a justified manner (by including all the other blocks they sent as well).

from cbc-casper.

As for your fix on the sending of initial messages..

Are you proposing that when Val-0 (whose initial message was A) sends its first message (B) to Val-1, that both A and B are attempted to be propagated to Val-1?
Are you proposing that:

• we bundle these and have them delivered at once
• or just that both are attempted to be sent (on potentially different delay schedules)

from cbc-casper.

@djrtwo I am suggesting the first. Essentially, we insist that the first time Val-0 sends to Val-1 (say they are sending message B), we use SJ1-B rather than S1-B.

from cbc-casper.

I think that sending in the length of the round is a nice solution - as well as leaving display and save out. I'll update the spec with this now.

Agree on defaulting to one - especially in the case of more complex strategies.

from cbc-casper.

One final change: I'm proposing some changes to the testing language so it's more extensible for any possible future protocol executions we might want.

There are two base commands: M, S, where M is making a new message and S is sending an existing message. Furthermore, there is the secondary command SJ, which note, can be decomposed to the just S commands.

M-0-A means Val-0 make a new message called A.
S-1-A means send Val-1 message A.
SJ-1-A means send Val-1 message A, as well as all messages in A's justification.

Other validity conditions:

• if a message is sent, it but have first been created.

Furthermore, we also add the following . The base make command is M-0-A (for example), but we also have M-0-A-(), where () can contain any arbitrary information about the new message.

For example, we could have M-0-A-(J-{B,C,D}), where this command essentially says create a message called A that just has the messages B, C, and D in its justification.

The regex for matching these commands is: ([A-Za-z]*)([-]*)([0-9]*)([-]*)([A-Za-z0-9]*)([-]*)([(){A-Za-z0-9,}]*)

from cbc-casper.

from cbc-casper.

Merged!

from cbc-casper.