feat: rs-sdk: rust software development kit for Dash Platform #1208
Conversation
| // Now, lookup quorum details | ||
| let chain_id = mtd.chain_id.clone(); | ||
| let quorum_type = proof.quorum_type; | ||
| let pubkey_bytes = provider.get_quorum_public_key(quorum_type, quorum_hash.to_vec())?; |
There was a problem hiding this comment.
we should also pass the core height to verify that the quorum is still active at that height.
| // #[cfg(feature = "mockall")] | ||
|
|
||
| /// Create an object based on proof received from DAPI | ||
| pub trait FromProof<Req, Resp> { |
There was a problem hiding this comment.
These parameters made as generics imply that there are possibility to have more than one implementation of the trait for a type, but is it our case? If not, it's better to have them as associated types
There was a problem hiding this comment.
In platform.proto, we have at least two services that return Identity:
rpc getIdentity (GetIdentityRequest) returns (GetIdentityResponse);
rpc getIdentityByPublicKeyHashes (GetIdentityByPublicKeyHashesRequest) returns (GetIdentityByPublicKeyHashesResponse);
So the answer is that we can have more than one.
There was a problem hiding this comment.
as I see in this snippet they both return their own response types
There was a problem hiding this comment.
I mean yes, you're right there will be more than one FromProof implementation for Identity, but for each of implementation a pair of Req:Resp is fixed, so only one of them is a generic parameter
edit: I may sound confusing, here is tldr: make Resp an associated type instead of trait's generic parameter, so FromProof<Req> will have an exactly one type Resp
There was a problem hiding this comment.
Agreed with fominok (I think)
| /// It defines a single method `get_quorum_public_key` which retrieves the public key of a given quorum. | ||
| #[uniffi::export(callback_interface)] | ||
| #[cfg_attr(feature = "mock", mockall::automock)] | ||
| pub trait QuorumInfoProvider: Send + Sync { |
There was a problem hiding this comment.
We have trait and callback interface just to get a quorum public key that might be just passed as a parameter, how sure we are that this trait will grow? If so, do we really need to invert how dependencies are taken instead of having each method to have their own requirements listed as arguments?
I just don't get this whole dynamic story with vague provider instead of statically known calls with their own dependencies (or put parameters inside request objects).
There was a problem hiding this comment.
The idea behind design of this API is a kind of "proxy"/"middleware" that gets request and response, and returns object retrieved from the proof inside the response. So, I expect the user (eg. third-party developer) to not understand - and not even try to read - the response. The intention here is to just translate received response from gRPC transport layer to DPP business objects, with as small amount of understanding of the underlying logic as possible.
Unfortunately, there is a missing piece needed to achieve that - public key. So I followed an approach similar to - for example - rust tls's x.509 certificate resolver.
Some other considerations:
- the user does not know quorum hash upfront - so he cannot provide quorum public key without inspecting response,
- public key can be either stored inside user's app, or looked up on an as-needed basis.
If we agree on going with callback design, we use a trait to implement it, as described in uniffi docs.
| fn get_quorum_public_key( | ||
| &self, | ||
| quorum_type: u32, | ||
| quorum_hash: Vec<u8>, |
There was a problem hiding this comment.
quorum hash should be [u8;32]
| &self, | ||
| quorum_type: u32, | ||
| quorum_hash: Vec<u8>, | ||
| ) -> Result<Vec<u8>, Error>; |
Co-authored-by: strophy <[email protected]>
Co-authored-by: lklimek <[email protected]>
… rs-sdk-versioning
…drive-light-client
…drive-light-client
…drive-light-client
…drive-light-client
…drive-light-client
Co-authored-by: Lukasz Klimek <[email protected]>
…drive-light-client
lklimek
changed the title
|
Closed by mistake, recreated as #1475 |
Issue being fixed or feature implemented
This PR implements multiple elements needed to build Rust SDK for Dash Platform.
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only