Zcashd deprecation forum list discussion

[oxarbitrage]

There is a list posted by Hanh in the Zcash forum about features that are needed for deprecating zcashd:

https://forum.zcashcommunity.com/t/zcashd-deprecation-roadmap/47515/2

I made a table with the list to see what is supported in Zebra at the moment and what not.

Request	Supported	Comments
- regnet with custom activation heights	✔️	Zebra has this as part of the last work in Regtests and Custom Testnets. (https://zebra.zfnd.org/user/regtest.html)
- generate	❌	Assuming this is to generate a new address, this is wallet functionality we don’t have.
- list accounts - get new account - get address for account	❌	All wallet related methods we don’t have.
- get utxos	✔️	We have getaddressutxos (https://zcash-rpc.github.io/getaddressutxos.html)
- get balance - import address - shield coinbase - z send many	❌	Wallet functionality needed.
- get block count - get block hash - get block	✔️	We have support for this 3 already.
- invalidate block - reconsider block	❌	I am not sure about this 2 , they are not zcashd rpc methods.
- get transaction (with tx input address.& amount, insightexplorer=1)	✅	We have call support, not sure about the mentioned arguments.
- get raw transaction - get raw mempool - send raw transaction	✔️	Zebra has all these.

Most of the calls could be possible if Zebra gets integrated with the memory wallet backend in librustzcash, something we are considering as an option to go over the deprecation: https://github.com/oxarbitrage/zebra-grpc-scan-spec/blob/main/client_integration.md

[arya2]

invalidateblock and reconsiderblock are defined here in zcashd: https://github.com/zcash/zcash/blob/fe6faf49e67379e1393d84595e5c52993abd855e/src/rpc/blockchain.cpp#L1573-L1648

[mpguerra]

Do we need to create new issues in zebra to implement these two methods in zebra?

[arya2]

Yeah, @hhanh00's project uses them to test forks and chain reorganizations (see this comment).

They would've been useful for testing the current implementation for TrustedChainSync with forks and chain reorganizations, and may still be useful for testing it more comprehensively, or testing any changes or additions to it (like if the indexer needs to keep a synced copy of Zebra's mempool state). They may also be useful for testing the zcashd replacement wallet.

It should be fine for those methods to only support invalidating/reconsidering non-finalized blocks in Zebra, at least for now since it would be far more complicated to support them for finalized blocks as well, and it's currently not possible for Zebra to have forks or chain reorganizations below the finalized tip while running.

Update: Opened a new tracking issue here.

[hhanh00]

generate is for mining a new block. In regtest where the difficulty is kept to the minimal, this is very fast.

The explorer arguments are config flags that add extra indexes and allow the get transaction call to return information about the inputs, such as address & amount. Without them, you would only get the txout because it is what the tx contains.

[oxarbitrage]

I think this is pretty much all done in the Zebra side and there are other resources that cover it (https://docs.google.com/spreadsheets/d/1UJxH1cowexGqadU32Uei5Qak6jGhXjb18-T_QBPmDAA/edit?gid=0#gid=0, #8435, https://github.com/ZcashFoundation/zebra/milestone/41, etc).