Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove address_to_object_id_hack part 2 #29

Merged
merged 20 commits into from
Dec 8, 2021

Conversation

patrickkuo
Copy link
Contributor

@patrickkuo patrickkuo commented Dec 6, 2021

This PR further refactor the code to remove usage of address_to_object_id_hack, also

  • removed balance from ClientState
  • added Vec<ObjectID> to ClientState
  • replaced get_object_id() with ObjectID::random()

Todos (in future PRs):

  • remove/ modify unit test to test object transfer instead of balance
  • remove all reference to balance
  • Unit test for encode and decoding of ObjectID (ObjectID now inherited Move's AccountAddress)

@patrickkuo patrickkuo force-pushed the pat/object_id_hack_refactoring_pt2 branch from 5106867 to 6e404cc Compare December 7, 2021 11:11
@patrickkuo patrickkuo changed the base branch from pat/object_id_hack_refactoring to main December 7, 2021 11:12
* removed unused amount args
* renamed init_state_with_account to init_state_with_object
This reverts commit 2034fec6b8d69908510ce7e2ed184accfb21910e.
* added objects to client state
* added object arg field to init_state_with_account function
* removed unused amount args
* renamed init_state_with_account to init_state_with_object
* removed unused amount args
* renamed init_state_with_account to init_state_with_object
This reverts commit 2034fec6b8d69908510ce7e2ed184accfb21910e.
@patrickkuo patrickkuo force-pushed the pat/object_id_hack_refactoring_pt2 branch from 6e404cc to 6977063 Compare December 8, 2021 10:35
@patrickkuo patrickkuo marked this pull request as ready for review December 8, 2021 14:25
@patrickkuo patrickkuo self-assigned this Dec 8, 2021
@@ -124,22 +124,22 @@ impl ClientServerBenchmark {
let mut account_keys = Vec::new();
Copy link
Contributor

Choose a reason for hiding this comment

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

With this change, account_keys probably should be renamed to something like acount_objects as it contains both account and object id.

@@ -57,7 +54,7 @@ pub struct ClientState<AuthorityClient> {
received_certificates: BTreeMap<(FastPayAddress, SequenceNumber), CertifiedOrder>,
/// The known spendable balance (including a possible initial funding, excluding unknown sent
Copy link
Contributor

Choose a reason for hiding this comment

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

Update comment.

)
}

/// Make one transfer order per account, up to `max_orders` transfers.
fn make_benchmark_transfer_orders(
accounts_config: &mut AccountsConfig,
max_orders: usize,
) -> (Vec<Order>, Vec<(FastPayAddress, Bytes)>) {
) -> (Vec<Order>, Vec<(FastPayAddress, ObjectID, Bytes)>) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think you need both FastPayAddress and ObjectID. FastPayAddress should be no longer needed as we just need ObjectID for sharding. Similarly for other make_benchmark_ methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the address is used later on as the recipient's address, we use ObjectID for sharing but we still need Address for the sender and recipient during transfer.

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm I don't see it though. Can you point me to the code that uses the address from the serialized_orders?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ohhh you are right, address is not needed here, I was confused with the address_keys in bench.rs, thanks!

@@ -213,7 +213,7 @@ impl InitialStateConfig {
failure::bail!("expecting two columns separated with ':'")
}
let address = decode_address(elements[0])?;
let balance = elements[1].parse()?;
let balance = ObjectID::from_hex_literal(elements[1])?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't be called balance

@@ -276,10 +278,9 @@ where
/// Find the highest balance that is backed by a quorum of authorities.
/// NOTE: This is only reliable in the synchronous model, with a sufficient timeout value.
#[cfg(test)]
async fn get_strong_majority_balance(&mut self) -> Balance {
async fn get_strong_majority_balance(&mut self, object_id: ObjectID) -> Balance {
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the semantics of this function under the object model? My understanding is that previously it tries to get the lower bound of the balances. But with objects what does it mean?

Copy link
Contributor Author

@patrickkuo patrickkuo Dec 8, 2021

Choose a reason for hiding this comment

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

it doesn't mean much, we have set the balance to 0 in all of our test, it's remnant of fastpay, have created an issue to refactor all of these.

Copy link
Contributor

@lxfind lxfind left a comment

Choose a reason for hiding this comment

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

LGTM

@patrickkuo patrickkuo merged commit 65247d7 into main Dec 8, 2021
@patrickkuo patrickkuo deleted the pat/object_id_hack_refactoring_pt2 branch December 8, 2021 23:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants