Kind of a Roadmap, Twice. Pt. 1
Rising regulatory pressure and new technologies are reshaping decentralized services. The Peercoin Foundation is investing heavily in tools for builders to create scalable, private, and censorship-resistant decentralized applications.
Back in December of '22, I published a blog post titled "Future of Smart Contracts" where I laid out my thesis on why there is a strong need to rethink smart contracts, and the way we deploy and use them.
Rising regulatory pressure and new technologies will change the way we build and use decentralized services.
Due to the meteoric rise in popularity of general-purpose smart contracts, platforms have been forced to increase throughput by reducing the number of block producers and centralizing the formation of consensus to fewer and fewer nodes. By doing so, they are facing the necessity to comply with rules and regulations set by government agencies. In other words, the popular smart contract platforms are no longer offshore. They have been shored and are becoming regulated. To retain the desirable traits of blockchain systems like privacy, censorship resistance and achieve scalability, I must conclude that it is best to proceed with off-chain solutions.
Initial research on this topic was conducted for the purpose of said blog post, and shortly afterward I presented a concrete plan to the Peercoin Foundation, explaining my vision and asking for funding to pursue the idea. The blog post, and the general idea, were soon used to solicit a large donation that was received by the Foundation. Randy and I went out and found someone who liked the idea so much that they decided to support us with no strings attached. This $350k donation was received in early 2023 specifically to pursue this project and we are eternally grateful for this opportunity.
This project demonstrates that the Peercoin Foundation is committed to the research and development of innovative and smart solutions that increase the utility of the Peercoin blockchain, while keeping in mind the traits that have made Peercoin appealing in the first place, traits such as easily accessible participation in consensus, cheap and easy validation of the blockchain state and absolute dedication to decentralization.
I will start with explaining the end goal, then come back to the specifics of how it is being implemented, and finally, some examples of what can be done with it.
I believe the future of dapps is off the chain, with on-chain settlement, for reasons of scalability, sustainability and privacy, but mostly for privacy and sustainability.
Long term, I want the Peercoin Flutter wallet to become the center of all the <off chain functionalities>. It shall be made so it can create and interact with discreet log contracts (DLCs), and handle threshold signatures, two necessary technologies for making all of this work. Secondly, the app is being developed in such a way that it can become a node that can communicate with other Peercoin Flutter nodes.
This Peercoin Flutter app is made from scratch, fully in-house. At the heart of the app is the coinlib library. We have implemented the finest and most feature-complete *coin library in the entire dart/flutter ecosystem. It does all things cryptography and all things *coin, and soon it will do the off-chain things as well. Coinlib is also slowly being adopted by a number of third party wallets, signaling it is a compelling product.
To allow Peercoin Flutter the ability to communicate with other nodes and become a tool through which all the new dapps become easily accessible, we plan to implement an overlay p2p network. This network can be used to allow peers to organize and participate in various consensus-forming groups. More on that later in this post. For now, just imagine one of the following: being able to publish an atomic swap order to this network, where someone else can easily find it and become your counterparty, all in true p2p fashion. Or you and your friends could form a minting pool, as described in my previous blog post. You could also form swarms of oracles and witness real-world events, or witness the transactions that cross a bridge to a sidechain, or coins on their way to be wrapped on Ethereum - all of this becomes possible and easily accessible.
The technology stack I imagine is aiming to bring peers back to peer-to-peer consensus, and make the technology human centric and human meaningful. To make it human centric, you need to have it on the go, on mobile and accessible at the touch of your fingers. That is why Peercoin Flutter is implemented in, well, Flutter - a cross-platform framework by Google. It natively works on all mobile and desktop platforms, and on the web. It can also be made into a browser extension, akin to Metamask, opening the doors to web3 integrations and familiar in-browser workflow.
Our next task is implementing support for threshold signatures within Peercoin Flutter. Threshold signatures in the app would be used to form massive multisigs and distributed oracles. To achieve that, we implemented Frosty, which extends coinlib so it can handle FROST threshold signatures over the secp256k1 curve. Two days ago, Frosty completed its first on-chain tests, and that is why this blog post is going public.
This transaction spends two Taproot outputs. The first one is a key-path spend of an output requiring a 2-of-3 FROST signature. The second one is a script-path spend of an output that specified a script requiring another 2-of-3 FROST signature. The signatures and keys are indistinguishable from an ordinary key. There is no way for an outsider to see that a 2-of-3 FROST key was used from the transaction alone.
Frosty library shall be open sourced under the BSD-3 license.
The third step is implementing an extension for coinlib that will handle discreet log contracts (DLCs). Support for DLCs is crucial, since this is where everything comes together. We will delve more into why later in this blog post.
Discreet Log Contracts (DLCs) are a type of smart contract that can run on a very limited scripting system, like the one used by Peercoin. Unlike the usual procedures found on Ethereum, for example, a Discreet Log Contract and most of its activity is not published on the blockchain.
After support for DLCs has been implemented, the first real tests of oracle swarms and binary options can be executed. The first useful apps can also be implemented at this point.
What is yet to be done is the following, not necessarily in this exact order:
- Make the Peercoin Flutter wallet natively support threshold signatures and distributed key generation.
- Implement DLCs primitives support into Peercoin Flutter.
- Implement the ROAST signature schema, which extends the FROST signature schema. We want ROAST as it has a number of favorable properties and is more suited for decentralized application use.
- Implement a user-friendly way to load and sign transaction templates into the Peercoin Flutter wallet.
- Implement an overlay p2p network that would allow Peercoin Flutter the ability to communicate with other nodes on this network and become a tool through which all the new dapps become easily accessible for regular humans.
But How?
Now that we have established what and why, let's go over how. If you are not really into technicals, you can skip to the second part of the blog post, where concrete examples of what can be done with these technologies will be presented.
Above, I mentioned threshold signatures, discreet log contracts, oracles, oracle swarms and many other cryptic words. I will now try to explain what they mean and why are they relevant. These are the building blocks.
Threshold Signatures
This is the core concept, as threshold signatures present an economically viable method to reach consensus within collectives - without using a blockchain. This approach enables a group to generate a single signature that represents an agreement, and reflects internal state - thereby simplifying the process of consensus verification and making it cost-effective, especially in scenarios involving large numbers of participants. Specifically, I am talking about FROST, which is a threshold signature aggregation protocol that allows for consensus among many signers to be expressed as a single signature. FROST is an entirely off-chain protocol. If it helps, you can imagine it as an off-chain multisig. The threshold consensus is formed through mathematics and communication rounds between participants.
A schema like this allows to express a succinct summary of a consensus between, potentially, hundreds of parties as a single signature. In our case, the consensus between all these parties is fully off-chain, completely private and infinitely scalable. There are entire blockchain networks out there which are basically large multisig setups, and they form consensus through rounds of communication between the multisig participants. They work on-chain, though, while what I propose works off-chain. Imagine a 150-strong swarm of nodes working as one oracle. All 150 signers independently verify some event and deliver the information to resolve some contract, for example, a pooled bet on who will win the 2024 presidential elections in the USA.
We plan to use the ROAST scheme to coordinate signing of FROST threshold signatures. This is known as Robust Asynchronous Schnorr Threshold Signatures, which provides a reliable way to construct FROST signatures among many participants, even when some participants act dishonestly.
Discreet Log Contracts
Discreet Log Contracts (DLCs) are a novel idea on how to do contracts without relying on scripting or virtual machines. With DLCs, all the important details of the contract and its execution happen privately, away from the public eye and without using the blockchain directly for anything other than starting and finishing the contract. This means the details of the contract and the money involved are kept secret from everyone except the parties involved. There's also a safety net included that ensures everyone gets their fair share even if something goes wrong, like someone not fulfilling their part of the deal or if the external information source, called an oracle, doesn't provide the needed information on time. Basically, only two steps in the whole process are visible on the blockchain, and they look like regular transactions, keeping the contract details private and secure.
DLCs fit perfectly with the technology stack I am imagining, making it a smart and effective way to agree on something digitally without needing extra layers of complexity.
Oracles
In the context of blockchains, Oracles in a blockchain network serve as bridges linking the on- and off-chain worlds. Oracles process the external events and deliver them in a way that can be used on a blockchain. External events can be anything from a football game’s results to the value of a stock, so that data can be fed into smart contracts.
In this context, an oracle is an entity delivering information about real-world events for DLCs. Before the event occurrence, the oracle advertises a public key that can be used to construct a DLC. The DLC participants prepare a transaction with a signature that is modified using the oracle's public key. Once the event has occurred, an oracle releases the private key for this public key, allowing the signature to become valid, thus unlocking the DLC and allowing the settlement of the contract.
The oracle's role is to fairly announce the outcome of some event without having the power to access the money in the contract.
An important feature of DLCs is that oracle signatures can be used without an explicit request from the contract participants.
Oracle Swarms
This is the fun part, and it is novel, as we are proposing a distributed oracle protocol.
Keys used in DLCs can be split across a group of oracles in the same way that is done for FROST signatures. This means that an oracle does not have to be a single party, a single point of trust. The oracle can be a group of 8 or 32 people. It can also be a 120 node-strong p2p network, with internal consensus, governance and even a token. The oracle can also be a separate blockchain network (like a sidechain) that specializes in services like this. What I am saying is that threshold keys make this absolutely flexible.
Let's imagine you are a part of an oracle swarm, which is in the business of delivering proofs about political events in the United States of America, and you are covering the upcoming Trump vs. Biden election show. You would open your mobile app and click A or B (Trump / Biden), tap fingerprint to sign the message and click send. If enough oracle swarm participants agree on the outcome of an event, they can construct and publish the information that proves they, as a collective, agree to this. This is peer to peer consensus in its true sense, and I am stressing out that "peer" here is human.
Technology like this, if integrated properly into user-facing applications, such as a mobile wallet, will make the blockchain technology human meaningful and human centric.
In part 2 of this blog post, I will lay out several concrete examples of what can be done using this technology.
Further Reading
https://adiabat.github.io/dlc.pdf
Craig Warmke