-
Notifications
You must be signed in to change notification settings - Fork 0
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
Base CLI parsing #17
Base CLI parsing #17
Conversation
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.
lgtm
89955b1
to
ade64d1
Compare
Solved issue with failing Nix tests: ade64d1 💪. Now it works: |
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 would like to see code that leverages the type system and is more more declarative. That leaves us with code that is easier to follow and extend. Moreover, the compiler supports us to catch missing/ unhandled commands.
PR and description updated - ready for re-review 👀. |
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.
Great, I think we are almost there. One last remark. I've put the main.rs
into build to create a separation between library and binary. If you could put all the modules except main.rs
into a src
directory that would be perfect.
LGTM |
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.
LGTM
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.
LGTM
@@ -0,0 +1,26 @@ | |||
use crate::common::args::{AmountArg, PrivateKeyPathArg}; | |||
use crate::crypto::error::CryptoError; | |||
use crate::crypto::signer::CasperSigner; |
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 did we make a custom signer?
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 want to isolate Casper code, to make it easily replaceable in the future. I imagine we might have Signer
trait and blockchain specific implementations for it.
pub struct CasperPublicKey(pub casper_types::PublicKey); | ||
|
||
impl CasperPublicKey { | ||
pub fn from_bytes(bytes: &[u8]) -> Result<Self, CryptoError> { |
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.
Don’t make this part of the inherent implementation, just impl the FromBytes trait if you want to do this
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.
FromBytes
is a trait existing in casper_types
, and my intention was to make Kairos as much independent as possible.
It can be constructed directly via public field.
Better separation with executable at `./bin/main.rs`.
More precise errors for caller, with the cost of manual casting into `CryptoError` in handlers.
5556046
to
455872d
Compare
Changes rebased with the latest |
3775a71
Per @xcthulhu request, I added additional tests for parsing public keys from CSPR.live. All four approvals were automatically dismissed though 😨. @asladeofgreen PTAL 🙏 |
Now it is possible to differentiate serialization and deserialization error.
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.
lgtm
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 have caveats, notably with reinventing wheels in respect of the cryptography, however I do understand the wish to reduce dependency upon casper libs as much as possible. Wouldn't a dedicated low-level kairos-crypto crate be of use here ?
So am approving for now but imho would like to revisit some of this code as the solution evolves.
@asladeofgreen Yes, cryptography will be moved out of CLI package into |
CLI interface
Implemented interface with three key transaction commands (Deposit, Transfer, Withdraw) and integrated Casper's cryptography functionalities.
Fixes #14.
Deposit:
$ ./kairos-cli deposit \ --amount 123 \ --private-key ~/wallet/secret_key.pem
Transfer:
$ ./kairos-cli transfer \ --recipient 01a26419... \ --amount 123 \ --private-key ~/wallet/secret_key.pem
Withdraw:
$ ./kairos-cli withdraw \ --amount 123 \ --private-key ~/wallet/secret_key.pem
Outputs
u64
- no need to handle u512 at this pointCasperSigner
(created fromCasperPrivateKey
)CasperPublicKey
Notably, signer allows generating signature of arbitrary byte data. It will be used to sign transactions sent to Kairos server.
Error handling
123a
:foobar
, when making transfer:Tests
Both 3 happy paths and error cases are tested in
cli_tests.rs
.