feat: add walletAddress endpoint #39
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #39 +/- ##
==========================================
+ Coverage 77.98% 78.94% +0.96%
==========================================
Files 9 9
Lines 109 114 +5
==========================================
+ Hits 85 90 +5
Misses 24 24 ☔ View full report in Codecov by Sentry. |
xps-gateway/src/lib.rs
Outdated
|
|
||
| pub use crate::rpc::{XpsMethods, XpsServer}; | ||
|
|
||
| pub const SERVER_HOST: &str = "127.0.0.1:0"; | ||
| pub const DEFAULT_WALLET_ADDRESS: &str = "0x0000000000000000000000000000000000000000"; |
There was a problem hiding this comment.
This should generate a new hot wallet, known only to this process.
There was a problem hiding this comment.
Maybe unrelated - how do we make sure these is fund in the wallet in order to send txs?
There was a problem hiding this comment.
Yes, this issue issues/23 describes the mechanism for transparency for the wallet balance. Then anyone can transfer funds to the wallet to maintain the desired level of funding for the process.
There was a problem hiding this comment.
Ok 👍
In that case, do walletAddress and balance RPC need authentication according to the issue requirements?
I don't think they need it since all data are public on blockchain anyways.
There was a problem hiding this comment.
No, you are absolutely correct these methods are safe in the sense that anyone can observe the address without exposing any risk to the internal wallet. It would be fine to implement the first version without any authentication and to update the documentation.
We still need to design the authentication and that may be a form of 'blanket authentication' such as an API key that applies to the whole server via a proxy on aws. You can ignore these considerations for now.
There was a problem hiding this comment.
One proviso attached to the above statement however is that the wallet must be generated from a secure source of cryptographic randomness as stated in the ticket. Also the generation should be essentially constant time, using the services provided in ethers. Otherwise a hacker may be able to deduce information about the private key by observing the public one.
As an interesting aside, recently the rust RSA module was broken in this way because researchers were able to break the key generation by observing the key generation times. It turned out the algorithm they were using for key generation was not safe.
There was a problem hiding this comment.
Gotcha, 100% agree with you and thanks for the info!
|
This PR uses a randomly generated wallet at initialization. I also created a feature request issue #41 here if using a existing wallet is needed. |
closes #28
In the future, we might want to get a private key from the environment variable and create an in-memory wallet instead of generate a new wallet every time.