-
Notifications
You must be signed in to change notification settings - Fork 19
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
feat: create a PoC based on actix actors #4
Conversation
let (node_actor, node_handle) = | ||
Actor::spawn(None, actor::NodeActor, (node_id, pk_set.clone(), sk_share)) | ||
.await | ||
.expect("Ping pong actor failed to start up!"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's something from an example :)
} | ||
|
||
#[derive(Debug, Clone, Serialize, Deserialize)] | ||
pub struct SignatureResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear from the name how is it different from the SignResponce. Let's brainstorm on it or add some comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah the names are far from perfect for sure. SignatureResponse
is when you have the full signature ready and can respond to NewRequest
. SignResponse
is when you want to respond with your signature share.
// and (optionally) internal state | ||
type State = NodeActorState; | ||
// Startup initialization args | ||
type Arguments = (NodeId, PublicKeySet, SecretKeyShare); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to declare these types here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is just a part of how ractor works. Arguments
is what you need to pass to initialize the actor. In our case it is node id, public key set and the secret key share associated with this node.
message: Self::Msg, | ||
state: &mut Self::State, | ||
) -> Result<(), ActorProcessingErr> { | ||
let remote_actors = ractor::pg::get_members(&MPC_RECOVERY_GROUP.to_string()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to fetch all the actors in each handle()
execution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want the actor system to be dynamically joinable, then yes. But as I said we could also just get rid of actors entirely and do N
HTTP requests to static addresses instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be dinamically joinable in the future, but I believe it's fixed for now.
Ok, let's keep it this way. I guess there is no harm from this design at the initial stage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
Let's add all other changes in follow up commits.
Fixes #11