I will discuss an interesting blockchain protocol — or consensus mechanism — in which blocks are constructed on one blockchain by transferring assets on an entirely separate one. This is used by Stacks, where bitcoin needs to be spent in order to add blocks to the Stacks chain. Benefits include recycling the considerable proof-of-work of Bitcoin to secure additional chains, and can extend its functionality by introducing features such as smart contracts closely linked with Bitcoin.
As described in previous posts, decentralized cryptocurrencies such as Bitcoin require a protocol in order to regulate construction of the blockchain and to ensure immutability. Blocks of transactions are appended, one by one, to the end of the chain. The protocol helps decide who gets to assemble each block and receive the associated reward, as well as ensure immutability so that confirmed blocks remain unchanged in the chain for perpetuity. The focus of this post will be on the consensus mechanism itself, rather than any additional features of the blockchain in question such as support of smart contracts.
Most well-known is the proof-of-work (PoW) protocol used by Bitcoin as well as by many other leading cryptocurrencies. This requires miners to compete by expending computational power in order to gain the chance to create a block. Currently, the main competitor to proof-of-work is proof-of-stake (PoS), which requires validators to lock up units of the underlying chain asset in order to be selected to create blocks. Examples include Cardano and Solana. Both kinds of consensus mechanism function by requiring the prospective block-builders to spend some resource in order to win the chance of building a block, and receiving a block reward paid on-chain. These approaches gain their security from the idea that an attacker would need to gain control of more than half of the global resource in order to be able to control the network, known as a 51% attack.
For proof-of-work, the resource in question is hash rate or computational work, which boils down to using sufficient energy. This is external to the blockchain since the energy exists independently of the blockchain. For proof-of-stake, the resource is the blockchain asset itself or, more precisely, its opportunity cost because it is only required to lock up the asset for a period of time. This is internal to the blockchain. Since the resource used for security itself depends on the security of the network, it can introduce some circularities or difficulties when trying to analyse properties of the blockchain such as immutability and possible attack vectors.
There is a third kind of protocol, which is the focus of this post. Specifically, a blockchain can be secured by requiring validators to spend a resource existing on a separate blockchain. Since this approach gains its security from a ‘base’ blockchain to which it refers, it makes sense to use what is considered the most secure and decentralized chain. Namely, Bitcoin. The idea is quite general, and other chains such as Ethereum could be used be used in exactly the same way. As of writing this article, there is one blockchain using such a consensus mechansim. This is Stacks, which gains its security by validators spending bitcoin in order to build Stacks blocks. As such, I will use this as the canonical example demonstrating the approach. The name ‘proof-of-transfer’ (PoX) is used by the Stacks team. This makes sense, since validators are effectively transferring bitcoin in exchange for native Stacks coins when constructing blocks. The important point, though, is that they are spending a resource on the Bitcoin blockchain in order to build blocks on the Stacks one.
Figure 1 shows the idea graphically. The top row is the Bitcoin blockchain, consisting of a sequence of blocks, each containing a collection of transactions and a header referencing the previous block. Individual commitment transactions can refer to a Stacks block by containing its hash and, in the figure, are shown in green. These both transfer some bitcoin and anchor the Stacks block to a specific location in the Bitcoin blockchain. Since Bitcoin transactions can hold arbitrary data inside of OP_RETURN outputs, these are used to store the Stacks block hash in addition to a reference to the transaction anchoring the previous Stacks block. Referencing the previous block commitment has the major benefit of allowing us to see the entire chain of Stacks block hashes and how they link together, including any branches, just by looking at the Bitcoin blockchain. Of course we still need to have access to the actual Stacks blocks to be able to see their contents. Finally, in figure 1, the Stacks blocks are shown along the bottom row. They are drawn considerably bigger than the Bitcoin blocks, showing one of the benefits of this approach. It enables us to leverage the security implicit in Bitcoin’s proof-of-work without being limited by the 1MB maximum size of Bitcoin blocks.
Since miners of a PoX chain are spending assets on the base (Bitcoin) blockchain via their commitment transactions, they need to be rewarded to provide the incentive to do this. As with all decentralized blockchains, this is achieved by having a native asset on the PoX chain and used to pay the miner a block reward and/or transaction fees. Hence, Stacks has a native asset, called STX.
The PoX protocol used by Stacks is, in many ways, more similar to proof-of-work than to proof-of-stake. This is because the resource (bitcoin) spent by miners is external to the Stacks blockchain, and exists entirely independently of it. Bitcoin existed before Stacks and, if anything ever went wrong with the Stacks chain, Bitcoin would be unaffected. In some other ways, though, PoX has similarities to PoS. Whereas the proof-of-work problem is essentially random, so that we do not know who will be the first to construct the next valid Bitcoin block and have it accepted by the network, with PoX and PoS this randomness is not automatic. Instead, it needs to be introduced explicitly in the protocol by the use of pseudo-random numbers or similar methods.
Occasionally, the Stacks chain is confused with the idea of side chains used to extend functionality or scalability of a main blockchain. Whereas a side chain is characterised by the existence of a two-way peg allowing assets to be moved between it and the main chain, PoX is the underlying protocol controlling the production of blocks and ensuring immutability. A side-chain could potentially use a PoX protocol, just as it could use PoW, PoS, a federated approach, or something else. So, the two concepts are orthogonal.
Benefits of Proof of Transfer
There are various reasons why it can be beneficial for a blockchain such as Stacks to use the proof-of-transfer consensus mechanism. For more information, see the article What kind of blockchain is Stacks?
- It leverages the high level of PoW security of Bitcoin, without requiring its own expensive and energy-intensive mining procedure.
- The protocol works cooperatively with Bitcoin, rather than competing against it. This is in contrast to using PoW, where the global hashrate would be split between the two chains with neither one being able to have 100% of the power. Merged mining is an alternative solution to this issue, but would require cooperation from the Bicoin miners. Using PoX, the mining process for the two chains are entirely separate and do not compete.
- It can be used to extend the functionality of Bitcoin. As each Stacks block is linked to a Bitcoin block, the protocol is set up so that contracts can see the Bitcoin state. Then, we can have smart contracts on the Stacks chain which are triggered by Bitcoin transactions. In some ways, the PoX chain can be seen as an extension of the base chain. Note, however, that this is one-way only. Bitcoin transactions do not see the Stacks chain. This has to be the case, since nodes validating Bitcoin know nothing about Stacks.
- The entry requirements for mining are low. Anyone can be a miner in a PoX system as long as they are able to pay the required amount of bitcoin. This contrasts with PoW, which can require specialized hardware to be purchased and maintained, as well access to sufficiently cheap electricity. It also contrasts with PoS which requires ownership of the native asset, which could be dominated by a small number of large holders.
- Whereas with standard PoW, it is possible for miners to attempt to attack the chain by building a private fork, with PoX used by Stacks, all block hashes are publicly recorded to the Bitcoin blockchain. To do this in private would require also creating a private fork of Bitcoin. So attacking the Stacks chain by a private fork can only work by simultaneously attacking and reorg-ing Bitcoin, which is a very difficult and expensive prospect.
- The PoX protocol used by Stacks gives holders of STX an interesting new way to earn Bitcoin, referred to as stacking. The Bitcoin transferred from the miners by the commitment transactions are paid to STX holders. This is a bit like validators in PoS who earn a return on their stake. The differences here are that stackers earn bitcoin instead of the native chain asset, and they are not required to participate in the validation or mining process.
On the other hand, proof-of-transfer does have some limitations of which we should be aware,
- The security of the blockchain is limited by that of the chain to which it anchored. For example, a reorganization of the Bitcoin blockchain would almost definitely result in a reorg of the Stacks one. So, Stacks cannot be more secure than Bitcoin. Consequently, if it takes 6 confirmations (i.e., blocks) for a Bitcoin transaction to be considered secure and irreversible, then it takes the same time for a Stacks transaction.
- The rate at which blocks are added cannot be greater than the chain to which it is anchored. For example, Bitcoin blocks are added on average every 10 minutes, so Stacks blocks cannot be added faster than this. However, Stacks gets around this limitation by allowing ‘microblocks’ to be created in between the regular ‘anchor’ blocks described above.
- It is possible for forks and reorgs to occur, where the canonical Stacks chain recognised by nodes switches to a competing branch. This can occur even when there is no reorg of the referenced Bitcoin blockchain. Such behaviour is a feature of the ‘Nakamoto consensus’ used by PoW chains whereby the longest chain is recognized as the canonical one. Resilience to such attacks depends on the total resources or, in the case of Stacks, the total amount of Bitcoin spent securing the chain.
Example Blocks
One of the great things when looking at the PoX protocol, is that all block hashes and forks of the chain are recorded on the base chain for everyone to see. So, let’s get a bit more hands-on and have a look at some actual commitment transactions used to anchor Stacks blocks.
I took the four Stacks blocks with heights 29966 through 29969 and checked their commitment transactions on the Bitcoin blockchain. The first output of the commitment transactions are all of type OP_RETURN with an 80 byte data string. This data contains the hash of the Stacks block and a reference to the commitment transaction of the previous block, as discussed above, along with some additional information. Figure 2 shows the results of this investigation. Clicking on the first column entries will take you to the Stacks explorer entry for the relevant block. The second column links to the commitment transaction in a Bitcoin block explorer, where the OP_RETURN data of the first output is displayed as a 160 digit hexadecimal string.
| Stacks | Bitcoin | OP_RETURN data | |||||||
| block | transaction | Hash | Seed | Parent tx | Key tx | m | |||
| 29966 | 700628:28 | ac3…6c9 | f3b…24e | 000ab0d3:0093 700627:147 |
000aacbf:003b 699583:59 |
02 | |||
| 29967 | 700631:352 | baf…0f5 | f6f…a69 | 000ab0d4:001c 700628:28 |
000aa8b2:050c 698546:1292 |
00 | |||
| 29968 | 700632:81 | a49…a2b | cff…9e6 | 000ab0d7:0160 700631:352 |
000aaf91:001c 700305:28 |
01 | |||
| 29969 | 700633:67 | b54…1f1 | d9b…0e9 | 000ab0d8:0051 700632:81 |
000ab054:0012 700500:18 |
02 | |||
To explain what this is showing:
- The first column shows the height of the Stacks block and links to its entry in the Stacks Explorer.
- The second column is the commitment transaction labelled as height:index, where height is the Bitcoin block height and index is its position in the array of transactions for the block. Clicking on this will link to the transaction in the Blockchain.com explorer. Its 80 byte OP_RETURN data is listed in order in the following columns:
- A fixed 3 byte prefactor, which is equal to 58325b for every commitment, so I do not list these in the table.
- The 32 byte hash of the Stacks block.
- A 32 byte seed used in leader selection.
- 6 bytes referring to commitment for the previous Stacks block. This consists of 4 bytes for its block height and 2 for its index within the block. I also include the decimal values, and link to the transaction.
- 6 bytes referring to the key transaction which again, is expressed in terms of the block height and its index. This is a transaction earlier in the blockchain used to register the miner.
- 1 byte for the ‘burn block modulus’, which is a number between 0 and 4. This is the Bitcoin block height (modulo 5) when the commitment was constructed, and will usually be one less than the height of the block that the transaction is in.
Each of the commitment transactions pays an equal amount in the second and third outputs, which is the transfer to the stackers (holders of STX). The recipients are determined by the Stacks chain state, so it is not possible to determine if the commitment is paying the correct addresses by just looking at the Bitcoin blockchain. It can also be seen that the commitment transactions have a single input, using the same Bitcoin address as the the second output of the corresponding key transaction. Hence, when a miner submits a key transaction, they are fixing the address to be used to pay for any future commitments.
For a more detailed description, see SIP-001 and SIP-007 on Github.
Leadership Election
To add a block to a PoX chain, a miner needs to construct a commitment transaction containing its hash and submit for inclusion in a block of the base chain. However, many different miners could do the same, so that a single block of the base chain can contain many commitment transactions. The protocol used by Stacks selects a single one of these, together with its associated Stacks block. Regardless of how many different commitments are contained in a Bitcoin block and how many different branches (or chain tips) of the Stacks blockchain they build off, only one commitment is regarded as valid.
Consider Bitcoin block height 700631, for example. From figure 2 above, we see that it contains a single commitment at transaction number 352, corresponding to Stacks block 29967. If we look through all of the transactions in this Bitcoin block, we actually see six commitments, listed in figure 3 below. This includes the total amount transferred and the fee for each commitment (in Sats). We also note that the commitments do not all build off of the same chain tip (transaction 271 has a different parent from the rest) but, even so, only the one in position 352 is valid.
| Tx | Parent tx | Key tx | Transfer | Fee |
| 135 | 700628:28 | 700452:67 | 580,000 | 26,949 |
| 152 | 700628:28 | 700305:28 | 600,000 | 22,750 |
| 271 | 700630:6 | 700500:18 | 434,444 | 8,473 |
| 308 | 700628:28 | 699587:151 | 511,110 | 7,000 |
| 351 | 700628:28 | 700498:29 | 75,000 | 6,300 |
| 352 | 700628:28 | 698546:1292 | 245,000 | 6,300 |
The miner whose commitment transaction is selected is referred to as the leader, as in PoS protocols. The choice of leader — or leadership election — is made using a verifiable random function (VRF), and requires each miner to include a 32 byte proving key in his key transaction. This function selects the leader in a pseudo-random fashion depending on the following data.
- The Bitcoin block header.
- The Bitcoin public key, block hash, VRF proof, and amount of bitcoin transferred for each commitment transaction.
- A seed generated from the previous winning leader.
For the details of this calculation, see SIP-001. The important properties for our discussion are:
- The result is pseudo-random with each leader candidate having a probability of winning in direct proportion to the quantity of bitcoin they transfer.
- It is practically impossible for anyone to compute the outcome until after the Block is produced containing their commitments.
- It can be computed using only data stored in the Bitcoin blockchain.
The first property is vital, and corresponds to the idea in PoW that the probability of a miner producing the next block is in direct proportion to their hashpower. Suppose that an attacker tries to gain control of the Stacks block production by creating the majority of the blocks themselves. They would need greater than 50% chance of winning each leadership election which requires transferring more than 50% of the total bitcoin across all participants. That is, a 51% attack. Economically, the total Bitcoin transferred should be about the same or slightly less than the total value of STX paid to miners in compensation. This will equal the Stacks block reward plus transaction fees multiplied by the value of STX. So, the security against such attacks will be in proportion to the value of STX.
The second property listed is required since, if they could predict the election outcome, miners could create lots of alternative blocks in private and only submit the commitment for the one that they predict will win. This would severely reduce the amount transferred on-chain, reducing security and possibly even devolving into a de-facto proof of work where the miner who can generate the most commitment transactions has the highest chance of finding a winning one.
The third property means that it is possible to construct the entire chain of Stacks block hashes, including any forks that may exist, by only looking at the Bitcoin blockchain. It also means that the winner of the leadership election is known as soon as the Bitcoin block is produced, and only the winner needs to transmit their Stacks block to the network.
Note that this method of selecting a commitment transaction does not guarantee a valid Stacks block. The election winner could submit an invalid block, or even refuse to submit any block at all. This should not be a problem. If such a situation occurred, then proceeding blocks in the chain would just be built off an earlier, valid, Stacks block. Consequently, the missing or invalid block would not appear in the canonical Stacks chain, and the loser in this situation is the offending miner who paid Bitcoin with his commitment transaction but does not receive the reward on the Stacks blockchain.
Forks
As with other protocols such as proof-of-work, chains using proof-of-transfer can fork. This occurs when more than one block builds off of the same tip, causing the chain to split into two alternative branches. The protocol needs to provide a rule for nodes to determine which of these is the canonical chain. If nodes were to disagree on the canonical branch, or switch from one to the other, then there will be a chain reorg, and transactions in one branch could effectively be lost. This is perfectly fine and is how the blockchain is intended to function, so long as disagreements between nodes or reorganizations only impact a small number of blocks near the tip of the chain. This is why we only consider a transaction to be final when it is confirmed by having sufficiently many blocks on top of it.
One way in which a PoX chain can fork, is if the base chain to which it is anchored forks. This is rather straightforward, and we leave it up to the base chain nodes to determine the canonical branch. For example, with Bitcoin, transactions are usually considered final after they have 6 confirmations, meaning that it is in a block with at least 5 further blocks already added on top. So, for a Stacks block to be considered final, we should at least require that its commitment transaction has 6 confirmations in the Bitcoin blockchain.
There is another way in which a PoX chain can fork. Even without any fork occurring in the base chain, it is possible for more than one block to be built off the same chain tip. This occurs when the leader for a particular base chain block does not build off of the most recent PoX chain block. Such a (hypothetical) situation for Stacks is demonstrated in figure 4 below
We see that the Stacks commitment transaction in the second displayed Bitcoin block builds off of the one in the first as expected. However, the third commitment does not build off of the most recent available anchored Stacks block. Instead, it again builds off of the first one. This creates a fork, and leaders in each of the subsequent Bitcoin blocks choose one or other of these two forks to build on.
This property, where the PoX chain can fork even when the base chain doesn’t, is not easily eliminated. You might think that we could enforce miners to always build off of the most recent PoX block, which would eliminate forks. However, this could be fatal. For example, a leader could submit an invalid block, or could withhold submitting his block for a period of time, or even fail to submit it at all. If we were forced to build off of his block then the PoX chain would come to a halt. We must allow the flexibility for miners to build off of earlier blocks if necessary.
Considering figure 4 again, maybe the second leader was slow in sending his block to the network. So, the third leader could not see his Stacks block and was forced to build off the previous one. If the first leader then, belatedly, submits his block, there are now two valid forks for subsequent leaders to build off. Alternatively, maybe there was a network split where half of the Stacks miners are not able to communicate with the other half. Then, each half starts working on its own branch, forking the Stacks chain.
In the event of a fork, the Stacks protocol needs to select one branch as the canonical one. The solution is simple. The canonical chain is the longest out of all the available valid branches. From looking only at the commitment transactions on the Bitcoin blockchain, it is possible to build the entire tree containing all existing branches. We then need the Stacks blocks themselves to determine which branches are valid, and can select the canonical one. The idea is that in the event of a fork, once one branch becomes longer than the other, this becomes the accepted one. Miners are economically incentivized to build on this branch since, otherwise, they would be paying bitcoin but not receiving any reward in the accepted chain. The effect is to further increase the length advantage of the canonical chain. The longer the canonical branch grows the harder it becomes for any other to catch up, and, before long, all other branches are abandoned. This is called the Nakamoto consensus, since it is the idea introduced by Satoshi Nakamoto with Bitcoin. Once a block has sufficiently many built on top of it, so that any branch splitting from the canonical chain before this point has negligible chance of overtaking it, the block is considered to be final.
Since the Stacks PoX protocol records all branches in the Bitcoin blockchain via commitment transactions, we can look for actual examples of forks that have occurred. In fact, look at the example blocks in figure 2 above. These are consecutive Stacks block heights, but the associated Bitcoin blocks are not consecutive. Bitcoin block heights 700629 and 700630 were skipped. Also, looking at the commitment transactions in Bitcoin block 700631 shown in figure 3, we see that they do not all build off of the same chain tip. What happened here? Figure 5 below shows all valid Stacks blocks anchored to these Bitcoin block heights, and how they are linked.
The number above each Bitcoin block shows its height, and the anchored Stacks block height is displayed underneath. First off, Stack blocks of height 29965 and 29966 are achored to Bitcoin blocks 700627 and 700628 respectively. Next, Bitcoin block 700629 was empty, and contains no transactions at all other than the coinbase. In particular, it does not contain any Stacks commitments. Following this empty block, the leader for Bitcoin block 700630 did not build off of the most recent Stacks block. This created a fork, with two Stacks blocks of height 29966, one in each branch, and anchored to Bitcoin blocks 700628 and 700630 respectively. The leader for Bitcoin block 700631 could have built on either of these branches. In fact, from figure 3 above, we see that there are commitment transactions extending both branches. The winning leader, however, built off the Stacks block 29966 anchored to Bitcoin height 700628, resulting in this becoming part of the canonical chain. The alternative Stacks block 29966 was consequently abandoned, or orphaned.
We can see Stacks block 29966 in the Stacks explorer, anchored at Bitcoin height 700628. The orphaned block 29966 can also be seen in the explorer anchored to Bitcoin block 700630.
Microblocks
One drawback of the PoX protocol as described above is that we can only have one block for each block of the base chain. Using Bitcoin as the base chain, this means that there is on average 10 minutes between each Bitcoin block, during which no new PoX block can be produced. If a user submits a transaction, then it cannot be added to the PoX chain until a new Bitcoin block is added.
Stacks addresses this issue with what are called microblocks. These are blocks which are not anchored to Bitcoin, so require an extension to the protocol. Mixing protocols like this should not be an issue, since the chain is still anchored to Bitcoin, just not at every block.
The way Stacks approaches this is to view these microblocks as being part of the previous anchored block that they build off. They are not treated completely as independent blocks in their own right, and do not get assigned a block height, for example. When the leader creates a block, and sends its hash in a commitment transaction to be included in a Bitcoin block, this cannot include any subsequent transactions which have not even been sent to the mempool yet.Instead, it just contains the transactions that he commits to including. If he wins the election, he can add new microblocks containing additional transactions as they arrive in the mempool.
When the next Bitcoin block comes in, the new leader can choose to build their block off of the most recent microblock, an earlier one, or ignore these microblocks altogether. To encourage leaders to add these microblocks, and for the following leader to build off of the most recent ones, the transaction fees are shared. A portion goes to the leader of the block they are built on, and a portion goes to the next leader who builds on top of these microblocks. See SIP-001 for more details on this.
Proof of Transfer vs Proof of Burn
As discussed above, the underlying idea is to secure one blockchain by requiring miners to spend an asset on an entirely separate chain. Keeping with the example of mining Stacks by spending bitcoin, there are two main ways that this can be done. They both involve anchoring Stacks blocks with commitment transactions on the Bitcoin blockchain, and the procedure is identical in almost all ways other than what these commitment transactions do with the bitcoin.
- Proof of Burn (PoB): The commitment burns (destroys) bitcoin, by sending it to a provably unspendable address.
- Proof of Transfer (PoX): The commitment transfers bitcoin to holders of STX.
In some ways, the first method (PoB) is closest to PoW, where miners consume energy to solve the proof-of-work problem. We are just replacing ‘energy’ with ‘bitcoin’. This ensures that a 51% attack would be expensive to perform, since the attacker would need a lot of bitcoin to burn. PoB is actually the approach originally used by Stacks, described in SIP-001.
In the case of burning bitcoin, we are not really destroying total value, since any lost or burned coins reduces the supply and increases the value of any remaining bitcoin. However, there are some drawbacks. The idea of intentionally destroying bitcoin could be controversial, even if it does increase the value of the remaining coins. Furthermore, it transfers value from Stacks to holders of bitcoin. This manifests itself by the process where miners need to keep buying bitcoin to burn, pushing up its price, and then sell the earned STX depressing its price. As the security of the protocol against 51% attacks depends on the value of STX, this can be regarded as an undesirable property of PoB.
The second method (PoX) avoids having to destroy bitcoin by instead transferring it to holders of STX. This is the method currently employed by Stacks, and described in more detail in SIP-007. Unlike with PoB, this has the effect of keeping the value within the Stacks ecosystem, with the downwards pressure of miners selling STX being offset by the ability of STX holders to earn bitcoin.
There is one potential problem with PoX. Imagine the extreme situation where one person held all the STX, or at least, held all of the STX participating in stacking. Then, he could mine Stacks blocks almost for free, since the transferred bitcoin would just come back to himself. There would only be a small transaction cost incurred. Although this situation is rather extreme, it is still the case that a holder of a significant proportion of STX could mine Stacks more cheaply than otherwise. For this reason, Stacks has the ability to revert to PoB with the approval of a minority of STX holders.
Zero Knowledge 