Read this article in German.
Today, we want to talk about a cost-reducing oracle approach that has to be considered magical in terms of its efficiency. We will not go into the technical details, but the motivation for this approach is to combine a collection of independent signatures into a single signature. Verifying this single signature then serves as proof that a sufficient number of signatories agree on the signed message. This allows oracle replies to remain cost-constant, regardless of the number of validating oracle nodes. Before we start with the matter at hand, let us first take a look at a brief behind the scenes since our last project update.
In the past couple of months, we have taken several big steps towards a brighter future for Pantos. Apart from deepening our research and strengthening our corporate and research partnerships (see our CDL-BOT expansion for more), we started developing a Proof of Concept (PoC) to focus more on the practical aspects and experience.
In our latest project update, we took a closer look at global staking and protocol schematics to enable a cross-chain Pantos network. In today’s project update (from a technical point of view), we mostly want to talk about oracle solutions, which is one particular aspect of the Pantos protocol as envisioned in our previous update. The envisioned Pantos network will feature Pantos nodes to execute on-chain protocol logic and Pantos oracles to ensure information transfer from one blockchain to another. By distinguishing between Pantos nodes and Pantos oracles, it is possible to task the Pantos nodes with maintenance tasks that do not endanger the integrity of the network, even in the event that most nodes become malicious. By defaulting to trusted authorities for the Pantos oracles in the initial phase, this distinction further allows a faster rollout and step-by-step system upgrades.
Oracle schematics
An oracle, in our terms, is a query tool. In a simple form, any Pantos client can query the oracle on Blockchain A to determine whether a specific transaction is included on Blockchain B. In the past, we have had closer looks at voting mechanisms and relay solutions (Whitepaper 5). Relay solutions in practice seem to not work out in the long term so far, as most prominently demonstrated by BTC relay. According to our observations, this is mostly due to the ongoing cost factor, even during idle times. To better cope with the need for less-frequent validation periods, we need an on-demand consensus protocol. This boils down to a more node-centered solution. Purely on-chain voting mechanisms (and similarly, the collection and bulk submission of signatures) do not scale with the number of participating nodes. The bigger the network grows, the more expensive its everyday operations become. Before we continue talking about the magic that allows scalable oracle transactions to take place, let us first point out one peculiarity of all the practical protocols we have seen so far.
If we speak about scalability and costs in this blog post (unless indicated otherwise), we always think about on-chain operations and gas costs incurred by these on-chain operations. While on-chain operations from a computational point of view might be trivial, it is the publicity and decentralised validation that is costly for blockchain smart contracts.
The cost factor in blockchain terms does not scale easily. We want transactions to be public, and this public verification comes with a price. Decentralised blockchains allow only very limited throughput. In simple terms, think of the issue of spam in email protocols, but imagine everyone reading the same message folder. As a countermeasure, using fee structures (gas costs) tied to message size limits, spamming does not become impossible, but does become very expensive. These throughput limits will not disappear that easily. For that reason, the blockchain protocols that claim to be more sustainable and allow querying off-chain information make use of dispute mechanisms. Dispute mechanisms require a form of staking currency as collateral and/or an admission ticket. In our case of blockchain interoperability and thus the protocol spanning several blockchains, we have two possibilities. Either we make use of native blockchain currencies for staking, or we use an asset that is available on every blockchain of interest.
Straightforward oracle implementations, particularly relay solutions, tend to favour native blockchain currencies. From a technical point of view, the purpose of the stake is to ensure that disputing parties can be paid for raising an objection. Using non-native blockchain currencies then seems rather unnatural, as it could require the blockchain to track exchange rate information to ensure that any objections raised are being paid for. The need to track exchange rates of non-native blockchain currencies can be solved by flexible fee structures, where exchange rates are updated implicitly through adjusted prices. Such fee structures still increase the game-theory complexity, which can be considered an unnecessary overhead in the case of relay solutions.
Straightforward oracle implementations start with the use case of connecting two different blockchains. If more and more blockchains join the interoperability network, one of the benefits of staking with cross-chain currencies (such as PAN) and global stakes can be sketched as follows: Malevolent actors can always discredit the interoperability network by taking over the sufficient quantity of oracle nodes to force false information to be provided. This is possible regardless of how expensive it becomes. However, in the case of native blockchain currencies, this form of attack is relatively risk-free (for the attacker) since stakes, when provided in native blockchain currencies, do not change in value. In the event of an attack, a cross-chain currency, and in particular, one that mainly serves as gas for running the interoperability network, will be devalued simultaneously with the network by the market. The value of PAN is tied to the trustworthiness of the Pantos network, making investments in PAN stakes a costly thing if the purpose is to discredit the network.
A straightforward implementation of non-native currency staking protocols would build on independent staking contracts on each participating blockchain. This can pose a problem since it can lead to fragmentation, lowering the costs for malicious attacks. To tackle this problem, we currently plan to facilitate global staking as an expensive multi-blockchain operation. Global operations are required to happen on all participating blockchains at the same time. Global states then refer to parameters that are synchronised in this way. A token (and any other on-chain parameter) can be moved into a global state and can then be used as a global stake, synchronised everywhere simultaneously. Global staking thus makes sure that the stakes do not become concentrated on the most-used blockchains only.
Oracle Magic
“Any sufficiently advanced technology is indistinguishable from magic.” — Arthur C. Clarke
As outlined above, oracle solutions do not scale that easily. We have to consider a collection of oracle nodes and we have to assume that consensus between these oracle nodes is required for an oracle query to be answered correctly. To reach this consensus, the oracles could debate on-chain, requiring (possibly) several transactions of several oracle nodes. Alternatively, we could have a designated oracle node for any period of time to collect signatures of other oracle nodes and to submit this collection in bulk. For the Ethereum blockchain and ECDSA signatures, this second approach is already significantly cheaper, as such signatures are hardwired into the Ethereum protocol and are thus somewhat affordable. Nonetheless, if more nodes contribute to this consensus protocol, the on-chain validation becomes more expensive by the same factor.
Mathematics and cryptography in particular do provide wonderful solutions for practical problems. For this blog post, we opt to skip the more advanced technical details and to rather discuss the properties and benefits of one particular method to solve this scalability problem. For the interested reader looking for keywords to search for more literature, we are discussing Boneh-Lynn-Shacham (BLS) threshold signature schemes and Distributed Key Generation (DKG) protocols.
Cryptography in this case comes with asymmetric functionality. We usually have a private/public key pair, where messages encrypted with one of them can be decrypted with the other. In some instances, the difference between public and private keys is merely a difference of knowledge. Decrypting an encoded message with a public key proves that someone with access to the matching private key is responsible for encoding this message. Ownership in this context means that someone has access to a private key, and such access should be treated with the utmost confidentiality. Input and output from encryption/decryption are of asymptotically equal size. With the help of hash functions, private/public key pairs can finally be used to provide fixed size signatures from arbitrary data sets where ownership still means the same thing.
Hash functions and private/public key pairs can already be considered basic magic. For BLS threshold signature schemes, we take it a step further. Using such protocols, we can create a distributed private key, where a set of nodes each owns their own distinct private key share and none of them own the distributed private key. The distributed private key however, matches a single public key. Hence, by combining the results of the nodes using their private key shares to encode the same message, we receive an encoded message that can be decoded simply with the public key. The same procedure works for signatures. Plus, even better, a “threshold” in this context means that the BLS variant we are looking at allows threshold signatures. A fixed number of any different private key shares allows signing a message as if it was signed by the distributed private key. This allows a scenario with, for example, 101 verified oracles, where for a valid signature to be confirmed, it is sufficient for the matching answers of any 51 different of these oracles to be combined.
For BLS threshold signature schemes, each time the set of oracle nodes changes, the distributed private key, the private key shares and the public key change as well. Straightforward implementations require a trusted authority to supervise the creation of these keys. This trusted authority would then know the distributed private key and could create a valid signature without querying any of the oracle nodes. This is where DKG protocols come into play. DKG protocols remove the need for all-knowing supervision. While BLS threshold signature schemes should already be considered magic, the DKG protocol is the part of this approach that allows this instance of magic to be of practical value for our needs.
A working implementation of this magical approach can be found here: https://github.com/pantos-io/ioporacle. This Proof of Concept operates on a private Ethereum test network and makes use of IOTA as a broadcast channel for part of the necessary off-chain oracle communication. This approach has average-constant on-chain verification costs, regardless of the number of participating oracle nodes. Already, for more than three oracle nodes, naive on-chain voting is more expensive than using our approach. ECDSA signature bulk submission is more expensive for 15 or more nodes. Our approach still allows the same on-chain cost for answering queries, even for 1,000 oracle nodes or more.
It is worth noting that costs in the form of off-chain communication and computation are not constant. To create a properly signed message, an entity needs to collect signed messages from a sufficient quantity of other nodes. To create a new private/public key pair, all the nodes need to send customised messages to all other nodes. These costs can still be regarded as low in comparison to the on-chain costs, but we should keep in mind that even with constant on-chain costs, limits to the number of verified oracle nodes do make sense.
Closure and outlook
Summing up, today we discussed threshold signature schemes, allowing blockchain oracles to have constant gas costs for on-chain replies, regardless of the number of verified oracle nodes. In our exemplary implementation, we answer queries regarding transaction inclusion verification. It should be pointed out that further cost reductions can be achieved by batching solutions, either using block headers or milestones originating from the source blockchain.
In case you missed it, and know someone who might be interested, we are currently looking for additional Pantos developers to lift Pantos to another level (Front-End Developer, Blockchain Developer). Also, TU Wien and TU Hamburg are looking for PhD candidates to continue CDL-BOT’s research aspirations (CDL-BOT news page).
As stated above, we are currently working on a more practical PoC to allow the continuous testing of a preliminary Pantos network. For the next project update, we plan to take a sneak peek into this PoC. To be more specific, we will talk about what to expect in more detail and how interested readers will be able to test this PoC. After an internal alpha testing phase, we will gradually make features available for public beta testing on the testnets of Ethereum and the Binance Smart Chain. First, beta testing will be available to developers and tech-savvy power users. Later on, after releasing more user-friendly clients with graphical user interfaces, regular users will also be able to test the preliminary Pantos network.
