Fork and Merge
(POC 100+, V1° 1000+)
Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub are the technical details about how we can achieve shielded transaction aggregation. The unanswered question is how we represent these aggregation of transactions in the Zcashd/Zebrad as a feature/APIs. I argue fork and merge is one good option. It also has a few side benefits:
- Can be a representation of debt
- Allows for an optional type of locking mechanism to prevent double spend
- Describes some commision/fee options the aggregator can employ
- Allows for atomic transactions
- Can be relatively easy incorporated into wallets (wallet can query forks for info using same APIs used today)
A fork is simple a Zcash node that has decided to stop updating its state with Zcash blocks from the main chain but still accepts transactions. This fork/node could be centralised and controlled by an individual/organisation. Or this fork/node could lower its difficulty to allow continued mining from participants and represent a roll-up side chain that users/wallets can use instead of main for cheaper transactions. This also allows for any profits of the roll-up to be distributed to node participants/miners.
To be clear we would not be competing with the scaling work. The scope of this idea would be a Fork and Merge POC that could either be integrated into Zcash in its own right or proposed as an API we release shielded transaction aggregation with.
Note: The presentation of this idea wasn’t great in the original thread and more a live open thought process I was having. If ZCG or anyone are seriously interested I’d be happy to answer any questions or attempt a better description/requirements.
° V1 would require a hard fork. Requires adding a new fork ID parameter to enable asset locking to a particular fork.