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.
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.
Within modern blockchains there are primarily two architectural models for managing blockchain state; the UTXO-based model and the Account-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)
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”.
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:
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.
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:
E.g. a non-transferrable ticket stub, or a non-transferrable discount voucher.
E.g. a transferrable ticket stub. This is also known as a “bearer-token”.
tokens circulate perpetually
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.
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”.
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.
Several solutions for UTXO-management, which can assist in building a complete token-validation solution has been developed within the BitcoinSV ecosystem.