nChain solves the “Back to Genesis” problem of token verification on any blockchain

nChain solves the “Back to Genesis” problem of token verification on any blockchain

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

But so far, all token protocols have suffered from a problem called the “traceability problem” or “Back to Genesis” – how do you prove that a token is valid through a series of transactions that can last for years or even centuries? nChain’s research and development team says they have already solved this problem and it works on all blockchains.

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 each new transaction. This creates a “circuit” for each new token rule set that allows each token using those rules to verify itself, all the way back to the time it was issued.

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 Back to Genesis problem using recursive SNARKS.”

What does “Back to Genesis” mean?

For the record, the term “Back to Genesis” does not mean proving something all the way back to a blockchain’s own “genesis block.” It refers to the “genesis transaction” of a new token, the exact time the token was originally issued.

See also  Can Blockchain Change the Supply Chain Outlook?

There are several token protocols in existence today, each with their own methods of verifying a token’s authenticity. However, all of these require trusted third parties outside of Bitcoin (or other blockchains) to provide this proof. While it is possible to include extra data in each 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 consuming processing resources or relying on third parties? The issue has caused much discussion and debate within the Bitcoin and other blockchain user communities.

Recursive ZKPs

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

To succeed, 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 is more ideal for a blockchain to not rely on third parties in case a time comes when it no longer exists (or is temporarily unavailable).

As long as a token transaction has only one input and one output, it can also determine whether a digital token is genuine. nChain’s “ZKP circuit” mathematical proof method establishes a token rule set with the first transaction, which records a unique token identifier. This is then updated (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 this number exceed one, the token is considered “burnt” or no longer valid.

See also  Putin Calls for International Settlements Based on Blockchain and Digital Currencies - Finance Bitcoin News

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) scripting patterns common to common blockchain transactions.

Even better, he wrote, the proofs themselves don’t even need to be registered/stored on-chain, meaning they don’t require data storage space or miner verification. However, the option to record this data on-chain remains if an issuer wants more complete records of the token’s validity.

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

nChain R&D is actively developing the protocol and 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, right up to central bank digital currencies (CBDC).

Vaughan said that if there were any downsides to the proof method, it’s that it “uses cutting-edge technology that has yet to be battle-tested” and requires a small but not insignificant processing time to create each new proof (with each transaction).

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

Xiaohui Liu’s description provides more technical details about sCrypt’s own implementation on BSV, and describes with snarkyj’s code examples how Groth16 recursive verification can be used to generate a small/simple new proof for each transaction. It then shows how this works for a hypothetical NFT.

See also  Top 10 Exciting Blockchain Games at Polygon – Cryptopolitan

The example can 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 can also be applied to directed acyclic graph (DAG) structures instead of transaction chains, Liu said. However, this will be more computationally intensive.

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

See: The presentation of the BSV Global Blockchain Convention, Smart Contracts and Computation on BSV

New to Bitcoin? Check out CoinGeeks Bitcoin for beginners section, the ultimate resource guide for learning more about Bitcoin – as originally envisioned by Satoshi Nakamoto – and blockchain.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *