Skip to content
This repository has been archived by the owner on Feb 1, 2019. It is now read-only.

Notary #31

Merged
merged 47 commits into from
Apr 17, 2018
Merged

Notary #31

merged 47 commits into from
Apr 17, 2018

Conversation

ChosunOne
Copy link
Collaborator

I feel that the notary branch is ready to be integrated into the develop branch. Major improvements include the following:

  • SMC Listener integration into the main binary
  • Thread refactor
  • Skeletal Notary integration
  • Full unit test coverage of implemented features

There are still a lot of questions I have about functions related to the notary, such as how a notary selects a proposal to vote on and what information is needed in the vote message, but it is at the point where merging this will allow more parallel development of the rest of the project.

Josiah Evans and others added 30 commits April 9, 2018 18:00
…ed trees, and have a proper test for storing collations in the notary.
# Conflicts:
#	README.md
#	src/lib.rs
#	src/notary.rs
#	src/smc_listener.rs
…nts"

* Rearranged order of imported files, and struct attributes for consistency
* Add `#[derive(Debug)]` to enums to allow use with `println!` with `{:?}`
* Add meaningful message to `panic!` calls
* Fix indentation of `notary.run();`
* Change variable names used in collation/header.rs tests to be more readable and consistent with implementation
* Add `id` attribute to `Notary` and `Proposer` structs for identification when debugging the client, such as knowing what notary id we are storing a collation into
* Add `println!` for debugging received messages and current thread in SMC listener
* Add `generate_notary()` function to remove code duplication in notary tests
* Update SMC registration function to be notary or proposer specific, and to return primative boolean value with meaningful success or error logs
* Change `get_selected_notaries()` function to accept `shard_id` argument of `ethereum_types::U256` instead of `usize` for consistency withe the rest of the code
* Add `register_proposer_address()` since there will be both a notary registry and a proposer registry in the SMC Contract according to the Phase 1 Sharding spec
* Change notary test function names to be more explicit
}

// A crude way of converting the ethereum_types::U256 to a u8 byte array to be hashed. Suggestions to improve this are desired.
fn u256_to_bytes32(u256: ethereum_types::U256) -> [u8; 32] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

@ChosunOne ChosunOne Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

u32 is only 32 bits (4 bytes), while a u256 is 256 bits (32 bytes), the function turns the u256 into a raw 32-byte array, which is 256 bits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, my mistake.

src/lib.rs Outdated
}
match notary_thread.handle.unwrap().join() {
Ok(x) => { println!("Successful notary thread join {:?}", x); () },
Err(e) => { panic!("Failed notary thread join {:?}", e); }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could probably avoid duplication in these above two functions by having one that passes proposer or notary as a string to these outputs as well as log them.

src/notary.rs Outdated
/// manager_listener: mpsc::Receiver<client_thread::Command>
///
/// The smc_listener allows the Notary to receive messages from the SMC Listener, and the manager_listener allows the thread to receive commands from outside the thread.
pub fn new(smc_listener: mpsc::Receiver<message::Message>, manager_listener: mpsc::Receiver<client_thread::Command>) -> Notary {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's break these lines up as they are too long.

src/notary.rs Outdated
fn store_proposal(&self, collation: collation::collation::Collation) {}
fn store_proposal(&mut self, proposal: collation::Collation) {
self.proposal_vectors.entry(self.shard_id).or_insert(vec![]);
let vector = self.proposal_vectors.get_mut(&self.shard_id).unwrap();
Copy link
Member

@jamesray1 jamesray1 Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should avoid using unwrap and handle the error, although of course the Collation.body is undefined (not in a common spec), so that can be done once we have it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only error case I can think of is when the shard id isn't in the hashmap, which is addressed in the preceding line by putting an empty vector if the shard_id doesn't have an entry.

src/notary.rs Outdated
use collation::body;

fn generate_genesis_collation() -> collation::Collation {
let g_shard_id = ethereum_types::U256::from_dec_str("0").unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to vary according to the actual shard ID, which could be 1 to 99.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make this function a little more flexible

notary.store_collation(genesis_collation);
notary.store_collation(first_collation);

// Check that the operations succeded
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

succeeded

fn it_registers() {
let (tx, rx) = mpsc::channel();
let smc = SMCListener::new(tx);
let addr_bytes: [u8; 20] = [0x22, 0xFF, 0x31, 0x10, 0xA2, 0x82, 0xc1, 0x19, 0x77, 0x36, 0xb3, 0xfC, 0xe3, 0x4a, 0xD4, 0xFc, 0x5e, 0xEe, 0x75, 0xc8];
Copy link
Member

@jamesray1 jamesray1 Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, let's break these long lines.

@@ -1,103 +0,0 @@
extern crate diamond_drops;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we should have integration tests in /tests/ and unit tests in /src/.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, the tests there were actually just unit tests of the parse_cli_args function.

Copy link
Member

@jamesray1 jamesray1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reduce line lengths to 100 characters max.

src/cli/args.rs Outdated
@@ -6,7 +6,7 @@ enum ConfigType {
Nil
}

pub fn parse_args(args: Vec<String>) -> Result<config::Config, &'static str> {
pub fn parse_cli_args(args: Vec<String>) -> Result<config::Config, &'static str> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add docstrings for all public functions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah will do

@jamesray1 jamesray1 merged commit fae4b10 into develop Apr 17, 2018
@jamesray1 jamesray1 deleted the notary branch April 17, 2018 01:55
@jamesray1 jamesray1 restored the notary branch April 17, 2018 09:25
@jamesray1 jamesray1 deleted the notary branch April 17, 2018 09:49
AyushyaChitransh pushed a commit to AyushyaChitransh/diamond_drops that referenced this pull request May 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants