nChain solves the ‘Back to Genesis’ problem for token verification on any blockchain

Getting your Trinity Audio player ready...

The ability to create unique digital tokens vastly expands a blockchain’s potential use cases. They range from NFTs and consumer loyalty tokens all the way up to property titles/deeds and central bank digital currencies (CBDCs) that could replace the world’s fiat currencies.

However, so far, all token protocols have suffered from a problem called the “traceback problem” or “Back to Genesis”—how do you prove a token is valid through a string of transactions that may last for years or even centuries? nChain’s research and development team say they’ve already solved this problem, and it works on any blockchain.

nChain calls its new protocol “transaction chain proof,” or TCP. It uses “ZKPs” or “zero-knowledge proofs” with a recursive function in the code to renew the proof with every new transaction. This creates a “circuit” for each new token ruleset that enables every token using those rules to verify itself, all the way back to the time it was issued.

Need a great read for your morning coffee?
In this blog, @DrOVaughan, Director of Research at nChain, discusses the first ever #solution to the #backtogenesis problem. https://t.co/pGxdeJ11Yo pic.twitter.com/M6ug6re0Ao

— nChain (@nChainGlobal) August 16, 2022

sCrypt, the contract and token firm led by Xiaohui Liu, has already created an implementation of nChain’s solution for the BSV blockchain, describing it in a blog post titled “Scalable Peer-to-Peer Tokens on Bitcoin” as a way to “solve the Back To Genesis problem using recursive SNARKS.”

What does ‘Back To Genesis’ mean?

For the record, the term “Back to Genesis” doesn’t mean proving anything all the way back to a blockchain’s own “genesis block.” It refers to the “genesis transaction” for a new token, the exact time that token was initially issued.

There are several token protocols that exist today, all with their own methods to verify a token’s authenticity. All of these, however, require trusted third parties external to Bitcoin (or any other blockchain) to provide that proof. While it’s possible to include extra data in every token transaction to self-verify, inspecting every single transaction involving that token becomes unwieldy after a long time, making new token transactions large and expensive to process.

Is it even possible for a digital token to verify itself, back to its source, without bogging down processing resources or relying on third parties? The issue has caused much discussion and debate within Bitcoin and other blockchain user communities.

Recursive ZKPs

nChain Director of Research Owen Vaughan broadly described the “recursive ZKP” method for token proofs, which he developed with Dr. Mehmet Sabir Kiraz and Dr. Enrique Larraia.

I am pleased to share the first solution to the back to genesis problem that does not require a change to the protocol. The solution is blockchain agnostic and backwards compatible with existing token protocols. https://t.co/WkkVIYoNVc

— Owen Vaughan (@DrOVaughan) August 16, 2022

In order to be successful, the method must reliably answer the question, “is this a valid token?” without using any trusted third-party service. Trusted third parties are feasible, and today’s token protocols all use them, but it’s more ideal for a blockchain not to rely on third parties in case a time comes when it no longer exists (or isn’t available temporarily).

As long as a token transaction has only one input and one output, it can also determine if a digital token is genuine. nChain’s “ZKP circuit” mathematical proof method establishes a token ruleset with its initial transaction, which records a unique token identifier. This then updates (using recursion) with each new transaction involving that token. As long as each new transaction has only one input and output, it remains valid. Should that number go above one, the token is considered “burned” or no longer valid.

The size of each proof remains small and constant, no matter how many transactions there are over time. Vaughan said the method is backward-compatible with existing token protocols (on any blockchain) and uses simple pay-to-public-key-hash (P2PKH) script patterns common to ordinary blockchain transactions.

Better still, he wrote, the proofs themselves do not even need to be recorded/stored on-chain, meaning they don’t require data storage space or miner verification. However, the option remains to record this data on-chain if an issuer desires more complete records of token validity.

Using this method, anyone can verify a token’s authenticity and validity by themselves, requiring nothing extra from the token’s initial creator.

nChain R&D is actively developing the protocol and is still testing it, refining and optimizing the final designs for simple tokens like NFTs. However, the team is also looking for solutions for more complex token protocols that require more flexibility, all the way up to central bank digital currencies (CBDCs).

Vaughan said if there were any disadvantages to the proof method, it is that it “uses cutting edge technology that is not yet battle tested” and requires a small but non-negligible processing time to create each new proof (with every transaction).

The size of the proof in every transaction may depend on the ZKP implementation used. There are security and efficiency trade-offs to each, with Vaughan giving the examples of “Groth16” (1.5 kb proof size, but needs a trusted setup for each circuit); and “Halo” (no trusted setup, but a larger 3.5 kb proof size).

Xiaohui Liu‘s description provides more technical detail of sCrypt’s own implementation on BSV, describing with snarkyjs code examples how Groth16 recursive verification can be used to generate a small/simple new proof for each transaction. It then demonstrates how this works for a hypothetical NFT.

The example could also be extended to more complex transactions and tokens, such as fungible tokens or even a regular transaction that needs to be linked to an “ancestor transaction” in the past. It could also be applied to directed acyclic graph (DAG) structures instead of transaction chains, Liu said. However, this would be more computationally intensive.

Kiraz and Vaughan have filed a patent application for Transaction Chain Proof, which is pending. If approved, it would be a licensable method for token self-validation on any blockchain. BSV in particular prioritizes ways to verify data in a simple and elegant fashion, without additional layers or trusted third parties. Whether or not future token issuers use the method, or continue to use separate validation methods, depends on intended use cases, or the length of time, their tokens need to exist.

Watch: The BSV Global Blockchain Convention presentation, Smart Contracts and Computation on BSV

https://www.youtube.com/watch?v=c_zAlkImgTU&feature=youtu.be