With the Sapling activation approaching, we’re continuing our education on what users and third-party services can expect. We recently announced the Sapling turnstile and what users should anticipate with this feature. In this post, we’re going to look at the Sapling transaction anatomy.
Legacy Shielded Transactions and JoinSplits
Just after the launch of Zcash, we wrote an introduction on the Anatomy of A Zcash Transaction.
The basic spend types will also apply after Sapling activation but there are some nuanced changes to how shielded addresses appear in transactions.
In transactions involving legacy shielded addresses, the zero-knowledge proof operation is referred to as a JoinSplit. A JoinSplit consumes either one or two input values and creates either one or two output values. These input and output values are referred to as notes.
A JoinSplit does not reveal whether one or two notes were actually consumed or created. A transaction requiring the consumption or creation of more than two notes uses multiple JoinSplits.
The transaction above shows a fully-shielded payment requiring multiple JoinSplits. You don’t get much information from this other than the transaction consumed or created many notes.
Sapling Shielded Transactions
Due to the efficiency improvements in Sapling, shielded transactions using the new Sapling addresses look slightly different. They still consume and create notes but do not employ JoinSplit operations.
Instead, the new Sapling operation is composed of spends and outputs. These include detail on the exact number of notes consumed or created in transactions.
To compare, take a look at a testnet Sapling transaction:
Notice that the explorer shows one shielded spend (consumed note) and two shielded outputs (created notes).
It’s likely that this transaction consumed a note to send part of its balance to another address and the remainder as change sent back to the original address. However, they may have sent their entire note balance to two addresses and had no change. We can’t know for sure.
If a sender, Alice, needed to create a payment which sent a single Sapling shielded address the entire balance from her transparent address (perhaps she is completing a Sapling turnstile migration), then the explorer would show zero shielded spends and 1 shielded output.
User Impacts
We do not think the change in transaction anatomy should directly impact how Sapling shielded addresses are used but we do think it’s important for users to be aware, no matter how minor of an effect.
For example, services tracking Zcash blockchain activity such as block explorers will be able to distinguish the type of shielded address used (legacy vs Sapling). They could even add new labels to the interfaces so users can distinguish as well.
Everything else about shielded transactions remains the same including value, address and the memo remaining protected and transaction fees remaining visible.
Stay tuned for our next post on what users should expect with the Sapling activation. If you have any questions about Sapling transaction anatomy, we recommend bringing them to the community chat or forum.
