Pantos Project Update: Cross-Blockchain Consensus

Read this article in German.

Over the past couple of months, the Pantos project has benefitted from a wide range of structural, personal and organisational changes. Most noticeably, we are now communicating with the community through Telegram and other channels more directly. However, we also started tackling this project from aspects we did not consider so much in the past. A big part of this, of course, comes with the advancement of the project in general. We have extended our scope of business collaborations to the traditional banking sector, we are currently looking at applications with smart grid and supply chain solutions and we are cooperating with the Austrian Blockchain Center (ABC) to distill further possible use cases. On the technical side, we are still looking at approaches to make the relay solution more lightweight, as well as searching for non-relay alternatives which perform better during idle times.

We are consistently reiterating our blockchain review, an internal discussion paper to highlight aspects of blockchains and other ledgers that are of interest for the Pantos network. With the hiring of an additional, dedicated Pantos developer, this will lead to a first prototype connecting blockchain networks other than Ethereum.

In the remainder of this blogpost, we will talk about the “how” of enabling cross-blockchain token transfers in a multi-ledger network, including an implementation plan. We will also highlight the details of global staking, which we currently envision as an integral part of our cross-blockchain solution.

Speaking of thinking, coulds, wants, woulds and other possibilities, dear reader, please keep in mind that Pantos still is a research project. If anyone already knew how to best solve cross-blockchain communication, we wouldn’t need to do the research part. Performing this research keeps revealing insights, ideas and novel approaches. However, even though we believe that the presented thoughts are very close to what the Pantos project will eventually look like as a product, this still is a work in progress. In other words, the Pantos network might resemble the represented ideas in great detail, but there is no guarantee we are not going to come up with a very different and even better solution to our needs.

Connecting a Multiverse of Ledgers

As a cross-blockchain communication protocol, Pantos depends on agreed-upon procedures and roles. We distinguish PAN holders as individuals who want to use the Pantos network, Pantos nodes as agents who participate in the protocol as helping hands, and the Pantos oracle as a means to provide knowledge across blockchains. We identify blockchains and similar structures that are of interest for the Pantos technology as ledgers and finally, the Pantos network itself as a collection of ledgers that need to be connected. Each role, PAN holder, Pantos node and Pantos oracle, comes with a signature, which allows signed information to be unambiguously related with the originating signatory.

Thinking of communication between ledgers, we differentiate between knowledge transfer, where information from one ledger can be requested on another ledger and knowledge synchronisation, where information is created on all ledgers at the same time. Smart contract interaction in the Pantos network can be classified as a special case of knowledge transfer, where the transfer happens in both directions and has impacts on the information that is transferred in return. Token transfer again can be considered as a special case of smart contract interaction, where tokens on one ledger are destroyed in exchange for recreating them on a different ledger.

At any given time, one distinct ledger is identified as the broadcast channel. This broadcast channel is needed to openly communicate protocol necessities, but could also be replaced by a custom P2P network, or even by a server managed by a trusted authority. The only thing we require from the broadcast channel is that it allows distribution of information in a transparent manner and that the publication of information is economically affordable on this channel. The integrity of the published information via the broadcast channel is ensured by the signature principle since malformed and malicious information can be tracked to the originator.

We use the term on-chain to refer to information that is stored on one specific ledger as well as smart contract functions that are executed on one specific ledger. Off-chain on the other hand is information that is shared via the broadcast channel. Off-chain communication is required to follow the protocol. Invalid information or communication that is published on the broadcast channel thus, by definition, is not part of the Pantos protocol. Hence, the broadcast channel has no need of providing communication logic and is not required to have smart contract capabilities itself.

Now, consider the case where a PAN holder wants to send PAN originating on one ledger to another PAN holder on another ledger. Let’s call the PAN holders Michael and Susanne, and the ledgers Ethereum and BSC. In this example, we make use of IOTA’s Tangle as the broadcast channel. We will also include a specific Pantos node called Bernhard to serve as a helping hand with the cross-chain transaction.

We assume the possibility of calling functions (and transferring assets) on-chain and cross-chain in the name of a different user. This means that given Michael’s consent in the form of a signed statement, Bernhard is capable of transferring PAN from Michael’s wallet to another wallet, without the necessity of Michael submitting any transactions of his own to the ledger in question directly. In this scenario, Michael does not even need to hold any of the native currency of the ledger (blockchain or other DLT) in question. To enable such a calling function, we will make use of the broadcast channel. Michael can then publish his intent of moving PAN from his Ethereum wallet to Susanne’s BSC wallet, and Bernhard can use this intent to enact the transaction.

Cross-chain interaction happens in packages produced by a PAN holder as an initiator (Michael in our example). Such a package includes a maximum payable fee in PAN, a source ledger where the initiator holds enough PAN to cover the fee, transaction preparations, which allow PAN nodes to enact the requested blockchain interaction without further involvement of the initiator and for each such transaction preparation, a designated ledger, as well as a timeout tailored to this ledger. Each transaction preparation can further include the required collateral (in PAN or in the requested ledger’s native currency) allowing observers to jump in if the PAN node who claimed the request fails to finish it. This collateral should consequently be big enough to cover the necessary reversal operations.

For the cross-chain case where Michael wants to send 100 PAN from Ethereum to Susanne on BSC and is willing to pay 2 PAN to be subtracted from the transferred PAN, Michael packs all the necessary information into a package and publishes this package on the broadcast channel. The transaction preparation in this case consists of a burn transaction on Ethereum, a create transaction on BSC, and a finalize transaction for Ethereum. Bernhard, our Pantos node as a helping hand, then sees this package and claims Michael’s intent by publishing a claim transaction on the source ledger Ethereum, which in this case burns Michael’s token. Bernhard then uses the Pantos oracle on BSC to verify this burning transaction. This is needed in order for Bernhard to be allowed to recreate the PAN that was destroyed on Ethereum on BSC. Afterwards, Bernhard finalises the burn on Ethereum by using the Pantos oracle on Ethereum to verify that the create transaction actually happened. This way, Susanne on BSC ends up with 98 PAN and Bernhard finally receives 2 PAN on Ethereum.

The length of the timeouts, the optimal fee and collateral amounts and how to decide which Pantos node wins the claim of the request are still the topic of vivid future research. A likely candidate for this selection process is a stake-based hash function on the submitted request with the Pantos node identifier as salt. This creates a random fee between zero and the maximal transaction fee as intended by the initiator, but the higher the stake a Pantos node locks away, their chances of a higher fee should increase, and the closer the request comes to timing out, the maximum fee any Pantos node can cash in should also be higher. That way, fee rewards can be fairly distributed among active Pantos nodes and additionally the PAN holders might end up paying less fees than they had planned to.

Global Staking

Collateral refers to a security a Pantos node needs to lock away until the request is finalised in order to ensure that the finalisation eventually happens. This means that such collateral serves the purpose of possibly being slashed. Staking has similar uses and also refers to assets locked away to ensure their integrity. Staking however is more commonly used to create a scarcity and allows winner selection relative to some Pantos node’s staked resources to be based on random selection. Staking also ensures that Pantos nodes fulfill a minimum requirement and prevents spamming attacks.

The Pantos oracle can be implemented in a rather diverse manner. It is possible to have an oracle implementation consisting of relay solutions only, and thus replications of each ledger on every other ledger in the Pantos network. Due to cost efficiency, we are currently also investigating other oracle solutions, mostly based on voting procedures. Where trustworthy Pantos nodes participate as a Pantos oracle, it even seems possible to have optimistic oracles with dispute possibilities. This means that the answer given by a Pantos node can be considered correct after a pre-defined timeout if no other Pantos node started a dispute and triggered a voting contest in the meantime. For the time being, we believe that the Pantos oracle will include different approaches for different ledgers and different throughput times, which is why we simply refer to the need of transaction inclusion verifications with the possibility of general oracle solutions.

Now, given a Pantos network of a couple of blockchains, the naive approach would be to connect each ledger with every other ledger via an oracle solution and each of these connections require Pantos nodes to provide a locked stake on both ledgers. Apparently, a general oracle, or an on-chain oracle interface, can serve a multitude of incoming connections. This way, we only require one locked stake on each ledger of the Pantos network. We have previously introduced the possibility of knowledge synchronisation as utilised in our early Whitepapers for instance. We will now take a look at the implications of this idea for our security needs in the Pantos network.

Let’s assume that PAN and other tokens can be moved freely from one blockchain to another. This gives us two states, a token can be in. In a local state an asset exists on one particular ledger and for the duration of a local transaction, this asset never leaves its ledger. In a transitional state, where an asset is transferred from one ledger to another, for a brief period, the asset exists neither on one nor on the other ledger. The step from there to global staking consists of the question of a global state, where an asset is synchronised over all ledgers in the Pantos network at the same time and resides on all of these ledgers at the same time. Such global states and global operations are naturally more on the expensive side, since the status update needs to be communicated on each ledger separately.

Global states hence are expensive and slow but, for the same reason, they are rather reliable states. Another benefit of the global state is that it allows us to have the stakes incorporated into this global state. This then also means that instead of having distributed locked assets on every ledger, we get a collection of locked assets on all ledgers at the same time, vastly increasing the total value of this stake and with it, its security level.

One of the remaining questions regarding such global stakes is how to deal with misbehaving Pantos nodes. In the case of Pantos nodes simply being helping hands and their actions all being recorded for good or worse on-chain, the local collateral mandatorily provided with each claim suffices to ensure honest behaviour. Oracles however, especially if voting comes into play, cannot be tracked that easily and global operations cannot be solved with local collateral. Hence, to allow Pantos nodes to also provide Pantos oracle services, this will require the option to slash their global stake in the event of misbehaviour.

Another question is how to deal with the no-bad actors dilemma. If Pantos nodes never misbehave, other Pantos nodes might opt to reduce their operational costs by simply not monitoring their peers for misbehaviour anymore, creating a severe security issue for the Pantos network. Common solutions to this problem include the possibility of random violations by Pantos nodes that are secretly tests for their peers. Both the testing node as well as the reacting node should be rewarded and the incentive to track the behaviour of other nodes remains intact. The idea of such rewards can be implemented by adding additional (but rather minimal) maintenance fees to each transaction that are collected in local pools to be used for such tests.

Implementation Timeline

All that is left is to take a look at the future of the Pantos project. This outlook is by no means complete and since we still have many open questions to solve, the actual result might happen in a different way than currently planned.

• At the moment, we are working on connecting two blockchains where only one of them is Ethereum. As always, any prototype will first be published for test networks and only once it proves to work as intended, will it be rolled out to the public networks
• As a first step, we must focus mostly on on-chain smart contracts. This means that Pantos nodes (but more importantly Pantos oracles) will be trusted authorities in the beginning
• Pantos nodes as helping hands, who make use of Pantos oracles to allow PAN holders to move their assets across different blockchains, will be implemented rather early as well. Once this possibility is available, PAN holders will be able to participate in cross-blockchain interaction in exchange for earning fees.
• To allow PAN holders to actively participate in testing the cross-blockchain interaction, we will need a wallet solution, which most likely is going to be a browser-plugin solution
• Once we have a couple of helping hands in the form of Pantos nodes, we will then start working on implementing a third blockchain and rolling out tests to have Pantos nodes provide oracle services of minor impact as well
• Once the network of Pantos nodes becomes sufficiently reliable, we will allow Pantos nodes to actively participate in the Pantos oracle solution, rendering the trusted authority of the earlier implementations as just one among many. For novel blockchain additions to the Pantos network, we might still require an initial phase where only the trusted authority can handle certain oracle questions, but eventually the Pantos nodes will become the Pantos oracle

As already hinted in our social media channels, we have a lightning talk in preparation to explain this project update and answer community questions.

Feel free to join our Telegram channel and roast us with questions that come to your mind when reading this article:

- German Group https://t.me/PantosIO_DE

- English Group https://t.me/PantosIO_EN

As a closing note, we are happy to announce that we have planned a very nice approach for solving the voting scalability problem of oracles for the next blog post. If voting takes place on-chain, this becomes more expensive if there are more nodes who want to participate. With our approach the security level stays the same, but the on-chain costs are constant regardless of the number of participants.