Warp 2 Technical Demo
This demonstrates the performance of Warp Sync 2 using the compact blockchain
retrieved from LightWalletd and post-processed into a WS 2 compatible form.
The data is up to date to height 2166554. It skips transactions that have more
than 50 inputs/outputs/actions. Most of them are caused by the spam attack
on the Zcash blockchain starting Jul 2022.
Build from sources
To build the binary you need
Checkout the repository and run
git clone https://github.com/hhanh00/warp2.git
cargo b -r
This should produce a binary
Use a release
Github also builds release binaries for Windows and Linux.
You also need the blockchain data file. It is 2.2 GB file available for
Place it in project directory.
where FVK is the sapling full viewing key. It begins with
Video Clip - Using it with the ZecPages viewing key
With a AMD 3900X and a SSD drive, the ZecPages account is scanned in ~30 s.
How does it work?
Warp 2 skips over the transactions that have 50 or more inputs/outputs/actions. There
are very few normal usage for these types of transactions, thus they are indicative of SPAM.
Warp 1 is able to skip trial decryption of these transactions but still had to update
the note witnesses with the spam outputs/actions.
Warp 2 eliminates that work by using precomputed bridges. In fact, it can skip over the entire
block when the user has not received any funds in it. As a result, Warp 2 makes significantly
less elliptical curve calculations than any other existing synchronization mechanism.
warp2 didn’t worked here
$ ./target/release/warp2 zxviews1q0duytgcqqqqpqre26wkl45gvwwwd706xw608hucmvfalr759ejwf7qshjf5r9aa7323zulvz6plhttp5mltqcgs9t039cx2d09mgq05ts63n8u35hyv6h9nc9ctqqtue2u7cer2mqegunuulq2luhq3ywjcz35yyljewa4mgkgjzyfwh6fr6jd0dzd44ghk0nxdv2hnv4j5nxfwv24rwdmgllhe0p8568sgqt9ckt02v2kxf5ahtql6s0ltjpkckw8gtymxtxuu9gcr0swvz
Error: No such file or directory (os error 2)
viewing key is of zecpages.
I believe warp2 was compiled successfully, I ran without the viewing key, and warp2 seems to be running
thread 'main' panicked at 'Need the FVK as an argument', src/main.rs:13:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Did you download the data file?
that’s why you should always read the docs
I skipped that part, sorry.
I’ll try again, thanks.
Internet Speed: 350 Mbps
PC: AMD Ryzen 3 3200G (cpu MHz: 3600.000)
(PC specs ain’t the best)
Game changing syncing speed. Congrats!
Dumb question, syncing a secret-extended-key or a mnemonic phrase / seed (assuming it have only 1 address) would take the same amount of time or it has to do more computations?
Same amount of time. The secret part is unnecessary for synchronization, therefore the demo app doesn’t ask for it.
The internet speed is not a factor since the data file is local. SSD helps a lot though.
Did you try with your own fvk?
This is awesome. You are a Jedi master @hanh so thankful for your work…
@zancas will you be able to add this to Zingo wallet eventually or is it only for ywallet?
Some people have asked why the blockchain file is downloaded before and whether it is representative of a real wallet. After all, wallets do not have to download the blockchain every time. That’s a good question that I’d like to address.
The data file for the blockchain is 2.2 GB, which is much smaller than the complete blockchain file (~250 GB). The compact blockchain data from lightwalletd ECC edition is larger than 6GB. The demo downloads the file so that the performance of Warp Sync 2 is not impacted by the network speed and every run takes the same time. It shows that unless you have very fast internet, the sync is limited by your internet connection rather than your CPU.
Obviously, if you don’t sync from the beginning, WS 2 is still gonna work the same way. But for a demo, it is better to show on the largest amount of data.
Finally, as technical note there is no implementation of lightwalletd that works with WS 2. WS 2 needs extensions to the lightwallet protocol (just like DAG-Sync but for different data).
We’re actively working in this area.
We’re aware that caching portions of the commitment tree in the client will provide speed-ups in the current choke-point in the pipeline (networking).
I predict Zingo’s commitment tree cache will almost certainly be upgraded shortly.
I think Zingoists will take a look at warp2 and see how it relates to other solutions we’re discussing.