UTXO Tokens and the Back-to-Genesis Problem

TLDR; There exists a subset of architectural implementations for tokens that are simply not possible to do with BitcoinSV. In general, if you are the Issuer of a token on the BitcoinSV network, you will be expected to own the responsibility of validating and authenticating the movement of those tokens. Token validation/authentication can’t be delegated to the mining network.

Secondary Issuance

When a new token is issued on an existing blockchain, i.e. a token that is not the native token of the underlying blockchain, we will consider this as a Secondary Issuance.

This blog post is primarily concerned with Secondary Issuances on the BitcoinSV blockchain, and will explore the implications and limitations of performing such an issuance.

Models of Managing State

Within modern blockchains there are primarily two architectural models for managing blockchain state; the UTXO-based model and the Account-based model

UTXO-based model

Within the UTXO-based model of managing blockchain state, you will notice that transition 1 and transition 2 can occur independently of each other. This results in the ability of the blockchain network to reach massive computational scale through parallelising the computations for transition 1 and transition 2. This comes with a trade-off however. That trade-off is that there is no central, on-chain global state that might be used to relate any of the atomic entities. If you have a group of related entities, all of which have to undergo independent state transitions, the only place to feasibly maintain a materialized-view of the current “global state”, is inside an off-chain database.

The only global state for which there exists a materialized-view is the “mempool” which keeps track of the blockchain-native tokens (satoshis in the BitcoinSV case)

Account-based model

Within an account-based model, blockchain state is maintained in a global associative database. I.e there exists not just global state, but a central point of entry into manipulating that global state. This has the advantage of having the materialized-view of the current “global state” directly on-chain. The trade-off this model makes is that computation is limited to the sequential application to state changes. I.e. transition 1 and transition 2 must happen in sequence, and there must exist a transactional boundary around each of the transitions to avoid race conditions.

The current way in which Account-based blockchains like Ethereum are attempting to overcome the limits of parallelising computation, is to have parallel blockchains which can all “roll-up” their state into a central Ethereum “account” associated with that “Layer 2 side-chain”.

Back-to-Genesis

For a deeper technical review of the “back-to-genesis” problem you can have a read at this sCrypt blog post.

The crux of the issue is that when one performs a Secondary Issuance on most UTXO-based blockchains (including BitcoinSV ) , there really are only two ways of dealing with the issue of double-spend protection:

1. Maintain a server in the cloud that acts as a token authenticator
2. Maintain a complete database of all past token history within the client’s wallet.

The back-to-genesis problem is therefore that, in the absence of being able to delegate the authentication of Secondary Issuances to the mining network, the token Issuer (or someone else other than the miners), must maintain a full history of all the token movements for this Secondary Issuance.

Within the current blockchain industry, where the mantras of “permissionlessness” and “decentralisation” are held with something akin to religious zeal, this is seen by many to be an unacceptable “centralisation” of token management.

The author prefers to reason about this architectural concern in terms of technical trade-offs w.r.t. specific business objectives.

How are tokens made ?

Tokens are always brought into existence by an Issuer. Tokens are then “distributed” through some mechanism. The process of distributing block rewards typically performs an automatic issuance of new tokens within blockchains.

The important thing to note is that for every blockchain, the process of validating or authenticating a token always falls to the issuer of that token. The issuer for the blockchain’s “native token” is a Mining Node in Proof-of-Work blockchains.

In a proof-of-work blockchain (Bitcoin, Ethereum etc. ) the “satoshis” or “ether” is issued by the miners as a block reward. Furthermore, when two third-parties want to move these tokens laterally between themselves (peer-to-peer), the only way to prevent a double-spend from occuring is to have the ISSUER of the token authenticate or validate the token movement.

We can further refine our view of the actions that occur during the lifetime of a token:

• Issuance - Genesis event. creates a new token
• Distribution(sometimes same as Issuance) - Tokens are sent to a third-party by the issuer. The token is now in circulation.
• Exchange - Peer-to-peer token movement between participants. Token circulation.

Models of Token movement

Immediate redemption

1. tokens are issued to a recipient
2. The only subsequent token movement would be a redemption event.

E.g. a non-transferrable ticket stub, or a non-transferrable discount voucher.

Lateral with redemption

1. tokens are issued to a recipient
2. tokens circulate laterally
3. tokens are validated at each lateral transfer event
4. tokens are redeemed with an issuer

E.g. a transferrable ticket stub. This is also known as a “bearer-token”.

Lateral without redemption (perpetual circulation)

tokens circulate perpetually

1. tokens are issued to a recipient
2. tokens circulate laterally
3. tokens are validated at each lateral transfer

E.g. a money issuance or non-redeemable art NFT. Typically exchanges or market-places will exist to allow for trading these tokens for other tokens of equivalent value.

Moving forward with UTXOs

Recall that the Issuer of the token can either take responsibility for the validation and authentication of a token, or that responsibility can be delegated to someone else.

Typically in an Ethereum-style blockchain, it is possible to Issue new tokens, and to delegate the responsibility of authenticating the tokens to the network of Miners.

For BitcoinSV, there currently exists no way to delegate the authentication of non-satoshi tokens to the mining network. The implication of this is that the only way to provide a token recipient with double-spend protection is for the token’s Issuer to provide the infrastructure that participates in token authentication.

When looking at the preceding section, it should be apparent that for use-cases of (Immediate Redemption) & (Lateral Move + Redemption), the issuer would typically be a business entity, and therefore one would reasonably expect that the business would not want to delegate token validation to a third-party; primarily for reasons of legal liability, but also to assert control over the redemption process.

For the (Lateral Move - Without Redemption) use-case it is an open debate over whether it’s preferable to have “delegated/distributed validation” vs “centralised validation”.

In conclusion

When the tokens you issued need to move laterally in perpetual circulation, you must have your own cloud-based infrastructure to support the validation of these tokens. In general, if you are the owner of a Secondary Token Issuance on the BitcoinSV network, you will be expected to own the responsibility of validating and authenticating the movement of those tokens.

Resources

Several solutions for UTXO-management, which can assist in building a complete token-validation solution has been developed within the BitcoinSV ecosystem.

Project Name	URL
MatterPool TXQ	https://github.com/MatterPool/TXQ
LibItx TXBox	https://github.com/libitx/txbox
Bux	https://getbux.io