Pantos Project Update: Sixth TAST Technical White Paper

In the first TAST Technical White Papers, we completed basic research on the requirements for cross-blockchain token transfers. We also published a fifth White Paper and the DeXTT prototype, the first TAST research prototype. With it, we presented a full-fledged solution on how cross-blockchain token transfers could look like in practice.

Now we took a step back. The goal was to answer a fundamental question: How can transactions across blockchains be verified in a trustless way without a third-party involved? The answer to this research question is presented in the sixth TAST Technical White Paper.

Key facts of White Paper VI:

• The ability to verify transactions across blockchains in a decentralized way is a requirement for cross-blockchain applications, such as the cross-blockchain token envisioned by Pantos.
• Cross-blockchain transaction verifications can be realized by the on-chain execution of so-called Simplified Payment Verifications (SPVs) and by employing an incentive structure that encourages participation and discourages malicious behaviour in the system.
• A first prototype implementing these concepts is available as open-source software on GitHub.
• Download the sixth TAST Technical White Paper on TU Wien’s TAST homepage or directly here.
• Download fact sheet PDFs in English, German and French.

Recapping Pantos’ Vision

Pantos aims to create a platform for blockchain interoperability. As a first step, we aim to develop a cross-blockchain token. Ideally, such a token allows its users two things:

• to hold different denominations of the same token on different blockchains at the same time,
• and to freely transfer tokens between blockchains in a completely trustless manner.

Fig. 1: Cross-blockchain token transfer

A cross-blockchain transfer of tokens from blockchain A to blockchain B requires tokens to be destroyed (or “burnt”) on blockchain A before being created (or “mint”) on blockchain B.

Hence, when transferring tokens from blockchain A to blockchain B, blockchain B needs to be able to verify that a “burn” transaction has been executed on blockchain A (i.e., a transaction burning the same amount of tokens on blockchain A) before (re-)creating the same amount of tokens on blockchain B.

Fig. 2: Client interactions in a cross-blockchain transfer

Cross-Blockchain Transaction Verifications

We can leverage the concept of SPVs to enable the cross-blockchain verification of arbitrary transactions in a trustless manner.

If the destination blockchain can execute SPVs “on-chain”, it can prove that a certain transaction is part of the source blockchain without requiring trust in a third party.

Submitting Block Headers

To facilitate the on-chain execution of SPVs, relayers continuously have to submit new block headers of the source blockchain to the destination chain.

Fig. 3: Relayer continuously submitting block headers of the source chain (A) to the destination chain (B)

Received block headers undergo a light validation on the destination chain, where certain metadata like the block hash, the block number, parent, difficulty, and timestamp are checked.

If the light validation is successful, the block header is stored on the destination chain. This way, relevant information from the source blockchain is replicated on the destination chain.

Fig. 4: New block headers arrive at the destination chain

Important: A full Proof of Work (PoW) validation is not carried out for newly submitted block headers since validating the PoW for every block header would be too expensive.

Disputing Block Headers

For each newly submitted block header, the destination chain assigns a lock period. During this lock period, no transaction verifications are possible on these block headers.

Within the lock period, clients can dispute submitted block headers they think are illegal. In case a block header is disputed, the full PoW validation is carried out.

Fig. 5: An illegal block is disputed, causing the entire fork to be deleted

If the PoW validation fails, the corresponding block header and all its successors are marked so that transaction verifications on these block headers will not be possible. This way, submitted invalid blocks are filtered out.

Verifying Transactions

Fig. 6: Client requesting a cross-blockchain transaction verification

To verify the existence of a transaction of the source chain on the destination chain, a client asks the destination chain: “Is transaction x of block b included in the source chain and confirmed by at least n succeeding blocks?”

The destination chain then performs the following checks:

1. Check that block b is known.
2. Check that block b is part of the longest PoW chain of the source blockchain.
3. Check that block b is succeeded by at least n blocks.
4. Check that block b and the n successors have passed the lock period.
5. Finally, check that transaction x is part of block b by validating a Merkle proof of membership which was generated and submitted together with the request by the client.

Incentive Structure

The described approach relies on clients submitting new block headers as well as disputing illegal block headers. Submitting and disputing block headers cost gas.

→ Clients need an incentive to submit or dispute block headers.

Clients requesting the verification of transactions pay a small fee. Whenever a verification is carried out, the client that submitted the corresponding block header receives the fee.

This way, clients are incentivized to submit block headers.

Clients that submit block headers have to provide a stake. When a block is disputed and subsequently deemed illegal, the client that submitted the block headers loses its stake.

The client that disputed the block header receives the stake as a reward.

This way clients are incentivized to dispute illegal blocks. At the same time, clients are discouraged to submit illegal blocks.

Conclusion

The described concepts enable the cross-blockchain verification of transactions. While a first prototype implementing these concepts is available on Github, work on the prototype continues to pave the way for truly cross-blockchain applications, such as the cross-blockchain token envisioned by Pantos. For more detailed information, check out the whitepaper.

About Pantos

As the first multi-blockchain token system, Pantos aims to bring blockchain projects closer together, improve communication between developers, researchers and users, and set innovative standards for cross-chain token transfers.

The goal is to serve as a lighthouse project in an increasingly fragmented blockchain space. With multiple blockchains serving all kinds of different purposes, Pantos is seeking to allow these projects to talk to one another in a standardized way. This will speed up innovation by creating a link between blockchains which then can scale together.

To get the latest news on the progress of the Pantos project you can follow our official channels:

• GitHub: github.com/pantos-io
• Facebook: facebook.com/PantosIO
• Twitter: twitter.com/PantosIO
• Reddit: reddit.com/r/Pantos
• Telegram: https://t.me/PantosIO_EN (official English group)
• Telegram: https://t.me/PantosIO_DE (official German group)
• Telegram: https://t.me/PantosIO_announcements (announcements only)
• LinkedIn: linkedin.com/company/Pantos_IO