Sapling and Shielded Transactions on Tezos
Beginner to In-Depth Understanding of Private Transactions and Sapling
Public blockchains are public and transparent by default. For a system that needs to support large amounts of value, transparency is important. Blockchains should be open source and fully public because of the large financial stake that token holders have in the success and stability of the network. With the vast majority of public blockchains, you can see exactly which transactions take place, between which parties, for how much and when. But, solutions exist to make some transactions private. For understandable reasons, many people want to make their transactions anonymous or non-traceable. Since Tezos is the self-upgrading blockchain, why not add this anonymity feature to Tezos? This is exactly what was implemented in February of 2020 in the Edo upgrade. Popular blockchains that do this as a fundamental tenet are Monero and Zcash. With the introduction of Sapling, it can be added into various applications on Tezos such as a transaction type on wallets or DeFi applications for anonymity. It is implemented by extending the Michelson functionality to include Sapling, a protocol developed by the ZCash team.
Sapling allows anonymity when transacting with fungible tokens (i.e. tokens like wBTC, XTZ, or MVK but not NFTs). Sapling requires a set of additional keys, similar to the public and private keys of your Tezos blockchain wallet. There is the viewing key and sending key. The viewing key is similar to the public key, where it allows you to see private transactions sent in and out. The spending key is needed to send funds in and out of the wallet anonymously. The viewing key can be used to generate sapling addresses. Other users can send anonymous transactions to these sapling addresses, and the funds are accessed through the spending key. There is an unlimited amount of sapling addresses that can be generated if the user wants a different address for each transaction. Technically, there are 51³¹ possibilities, but who’s counting ;). Someone may use this feature so two people who send money to the same wallet wouldn’t know it. To clarify, there is one spending key and one viewing key, but the viewing key can generate infinite addresses to send money to. These addresses are called sapling addresses. If you need to give your shielded transactions to a regulatory body, you can share with them the viewing key.
Within a public ledger such as Tezos, there can exist transactions that are hidden or shielded. This is known as a shielded pool. Shielding, as the name suggests, means a hidden transaction not publicly readable by anyone besides the sender and receiver. Users need to shield tokens by entering them into the shielded pool and when they exit the shielded pool, unshielding the tokens. Since this shielded pool of transactions lives on a public ledger, any entrance or exit of the shielded pool is recorded on-chain. It is recorded that a certain amount of XTZ has been shielded or unshielded by a certain wallet. The Sapling-protected transactions are crafted in half a second and take about 10 milliseconds to verify. This speed is important for any technology, but specifically blockchain. The shielded pool is like Tor, where you can see which wallets transfer funds in and out, but not what is happening inside the pool. It’s critical to note that this system only works when there are numerous transactions occurring and a large volume of shielded tokens. Otherwise, it could be figured out where users sent tokens. I created a rough diagram below of how the shielded pool interacts with the blockchain.
As mentioned above, this Sapling integration was achieved by adding new functionality to Michelson. The function is called sapling_verify_update with new types called sapling_state and sapling_transaction. The sapling_verify_update function does the following. First, it takes in the sapling_statewhich is the current state of the shielded transaction pool and the transaction currently being submitted to the pool as the type, sapling_transaction. The function then returns the updated state of the pool that includes your transaction and a balance. The balance is the difference between created or destroyed shielded tokens between the current and previous shielded pool states. So, for example, if there was a balanceof 127, then that means 127 XTZ tokens were shielded between states. If the balance is -20, then 20 tokens were unshielded between states. If you are just sending shielded tokens between wallets, then the balance would be 0 because there was no quantity change in the pool. Hypothetically, thousands of users will be executing transactions with the shielded pool in the same block, so the balance isn’t directly correlated with your transaction specifically but the total of all the transactions between the previous and current state. Once those funds are shielded, they can be transferred within the pool completely anonymously through encryption with the keys as spoken about previously. What is not shielded is when the funds leave or enter the shielded pool.
How does a shielded transaction practically work?
Let’s say I want to send 100 XTZ to my friend Alice, but her annoying ex-boyfriend is always looking at her Tezos wallet. First, I will generate a new sapling address. I will then convert the 100 XTZ to shielded tokens with a smart contract that adds my tokens to the smart contract's shielded pool. That transaction will credit my sapling wallet with the shielded 100 XTZ and remove 100 XTZ from my transparent address. From there, I can send my shielded tokens to Alice’s sapling wallet, which she will need to generate also. If Alice chooses to, she can then send the shielded tokens to other users with her spending key or convert the tokens to unshielded XTZ. But, this unshielding will be public, and maybe she doesn’t want to make it public yet.
If it is just Alice and I using this smart contract, it would be obvious that I’m the one who sent the tokens to Alice, but when hundreds of thousands of people are using it, it will be incredibly difficult if not impossible to track the exact payment.
Practical examples for private transactions are for companies to not know or track your spending habits or, for competing nations to not know the behavior of the citizens. There are really a plethora of examples of why financial transactions should be private. For Tezos (and all blockchains) to gain mass adoption and more use-cases, Sapling is a crucial feature. Privacy should be inherent in every transaction and if this privacy functionality is fully adopted as best practice, it will create just one more reason that Tezos is the most upgradeable and adaptable blockchain.
Thank you so much for learning about Sapling with us! Feel free to message me with any questions on Twitter at @adshinder. Follow Tezos Israel on Twitter @tezosisrael to keep up with what we’re building and how we are advancing the Tezos ecosystem!
Helpful/Additional Sources:
