Client RFC: add BlazeSync and cap-std
This commit is contained in:
parent
c9e93a75f7
commit
f15aa52751
|
@ -201,6 +201,8 @@ Support for sending tx's via _non-privileged_ RPC endpoints, or via Stolon:
|
|||
- zebra-cli talks to the subcomponent running in zebrad
|
||||
- (can use servo/bincode to communicate with zebrad)
|
||||
- via the privileged (and possibly the unprivileged) RPC endpoints
|
||||
- can use [cap-std](https://blog.sunfishcode.online/introducing-cap-std/)
|
||||
to restrict filesystem and network access for zebra-client
|
||||
|
||||
## Task isolation in Tokio
|
||||
- TODO: fill in
|
||||
|
@ -296,6 +298,9 @@ Supporting a wallet assumes risk. Effort required to implement wallet functiona
|
|||
# Future possibilities
|
||||
[future-possibilities]: #future-possibilities
|
||||
|
||||
- [BlazeSync algorithm](https://forum.zcashcommunity.com/t/zecwallets-blazesync-sync-entire-chain-in-60s/39447)
|
||||
for fast syncing, like Zecwallet
|
||||
|
||||
- mandatory sweeps for legacy keys
|
||||
- blazingly fast wallet startup, to match `zebrad`'s blazingly fast sync
|
||||
- generate unified address from a new seed phrase (or one provided by the user)
|
||||
|
@ -313,6 +318,8 @@ Supporting a wallet assumes risk. Effort required to implement wallet functiona
|
|||
- split `Client` component into subprocess
|
||||
- this helps somewhat but the benefit is reduced by our prexisting memory safety, thanks to Rust
|
||||
- not meaningful without other isolation (need to restrict `zebrad` from accessing viewing keys on disk, etc)
|
||||
- could use [cap-std](https://blog.sunfishcode.online/introducing-cap-std/)
|
||||
to restrict filesystem and network access for zebra-client
|
||||
- instead of process isolation, maybe you actually want the Light Client
|
||||
Protocol, or something similar?
|
||||
|
||||
|
|
Loading…
Reference in New Issue