Kind of a Roadmap, Twice.
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.
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.
I understand that by ’24, most people who are in the cryptocurrency/blockchain scene are very much used to the on-chain smart contract way of thinking and what I am proposing may sound strange and unusual. Some may ask why not simply implement on-chain contracts on Peercoin. My answer to that is that Peercoin was designed to be a coin, not a smart contract platform. Smart contracts belong on platforms specifically designed to run them. To run smart contracts and dapps, the architecture of the system must be adapted to serve such a task. In my opinion, complex smart contracts do not belong on a coin. I am saying complex here because Peercoin does have a scripting system and limited capability for smart contracts — most famously used for multi-signature addresses, atomic swaps and the lightning network.
There is a market for smart contract platforms, and evidently demand too, but again, this does not belong on a coin. It belongs on specialized platforms. With the technologies proposed in this post, moving information to and from any number of platforms becomes rather easy — without forcing design decisions that conflict with the coin.
To summarize, by moving the execution of smart contracts off-chain, the following favorable traits are achieved:
- Increased Privacy; to the outside world, the entire contract seems like a regular taproot transaction.
- Lower Fees; due to drastically reduced script size and cheap signature validation.
- Scalability; as most computationally intensive work is done elsewhere and only settled on the main chain.
The ability to operate contracts with a minimal on-chain footprint while ensuring integrity and confidentiality is a pivotal development in the quest for a more accessible and efficient blockchain ecosystem.
Now, let’s imagine what kind of services can be built.
Binary Options
With the presented technologies, implementing binary option platforms is the easily accessible, low-hanging fruit. It’s probably also the easiest case to imagine for most readers, so I am starting with it. Due to the nature of DLCs and how they work, everything has to be expressed as true or false, so binary options are a natural fit.
Binary options are a type of financial derivative where individuals can place all-or-nothing bets on the outcome of specific events or changes in asset prices. The essence of these options lies in a simple “yes or no” proposition, which is why they are called “binary.”
If a trader’s prediction is correct, and the option expires in their favor (in the money), they receive a payout. Conversely, if the prediction is incorrect, and the option does not end as anticipated (out of the money), the trader incurs a loss.
Let me illustrate further with two simple examples.
Example 1: Nvidia Stock Binary Options.
Stock binary options, with both sides trying to outsmart each other based on what they think will happen with Nvidia’s stock.
In every binary option scenario, we have two parties, two roles. The maker and taker.
The Maker: In the world of binary options, the maker is the party that creates the binary option contract. They decide the conditions of the option, like which stock it’s about, whether the bet is on the price going up or down, and the time frame (like by the end of the day, or the end of the quarter). The maker is offering a challenge and is essentially saying, “I bet you a tenner that Nvidia’s stock will (not) reach a certain price by a certain time.”
The Taker: In this scenario, you’re the taker if you decide to take on the bet. By accepting the bet, you agree to the terms set by the maker.
Perhaps it is confusing to define the roles abstractly like this, but imagine every Alice being able to be a maker and every Bob can take the bet. Any peer could come around and post a bet, and any other peer could come around and take that bet offer.
How it all Plays Out:
- Setting the Stage: The maker sets up the option by deciding on the terms (Nvidia stock, price direction, timeframe, and bet amount). Maker posts a bet offer which claims that the price of Nvidia stock will trade under $1000 by Jan. 1st 2025.
- Accepting the Challenge: The taker, intrigued by the maker’s bet, decides to take the challenge. If the taker agrees with the maker’s offer, they’re essentially betting against the maker. In other words, in order for the taker to win, the maker must lose.
- Waiting for the Outcome: Both parties wait until the future event to see what happens with Nvidia’s stock price.
- Winning or Losing:
- If the stock’s price is over $1000 on Jan. 1st, 2025, the taker wins the bet and collects both his deposit and the deposit of the taker.
- If the stock’s price is under $1000, the taker loses the money they bet and the maker can withdraw the full sum.
In this scenario, the maker is taking on a bit of risk by offering the bet, but they might also be using their knowledge or intuition about the stock to try to win money from the taker. The taker, on the other hand, is directly accepting the challenge, using their own knowledge or gut feeling to try to win.
See in the next example exactly how these binary options would be settled and what the role of the oracle is.
Example 2: Betting on the Outcome of an Event, the USA Presidential Elections
The Maker: This party sets up a new bet related to the upcoming presidential election in the USA. They propose a bet saying, “I bet that Donald Trump will defeat Joe Biden in the upcoming presidential election.” The maker decides on the terms of the bet, such as how much money is at stake.
The Taker: Another party who decides to engage with the maker’s bet. The taker bets against the maker, i.e. betting that Biden will win the election. It always comes down to boolean true/false.
The Oracle: This is a crucial character in our setup. The oracle is an independent party that doesn’t bet but plays an essential role. They are responsible for determining the outcome of the event and declaring the result of the bet based on that outcome.
How it all Plays Out:
- The Bet is Made: The maker puts forward the bet on the election outcome. They might say, “I bet Ᵽ100 that Trump will win the election.”
- The Bet is Accepted: The taker reviews the bet and decides to take it. By definition, the taker disagrees with the maker, and they’re betting their money on Biden winning.
- The Election Happens: People vote, and the votes are counted, and official results are published.
- The Oracle Steps In: Once the election results are official, the oracle announces the outcome to the players. This ensures that there’s no dispute about who won or lost the bet. The oracle says, “The result is in, and [Trump/Biden] has won the election.”
- The Outcome of the Bet: If Biden wins, the taker wins the money.
In this scenario, the oracle plays a crucial role in maintaining the integrity of the bet. By having an independent party declare the result, both the maker and the taker can trust that the outcome is fair and that the bet will be resolved honestly. This setup mirrors real-life mechanisms where third parties often mediate outcomes in betting and financial contracts.
I am trying to shorten this blog post, so I will just mention that sports betting can be done in the very same way, given that there is an oracle swarm that specializes in this. Alice makes the bet that the Doggers will win against the Blazers by 5 points or more. Bob accepts the bet as a counterparty and everything continues just like in the example above.
Bridges of all Kind
Bridges to sidechains, bridges to foreign chains, all kind of bridges.
Cross-chain Bridges
A cross-chain bridge enables the transfer of token assets, smart contract instructions or data between blockchains.
Most of the cross-chain bridges out there are simple multi-signature setups. A number of trustees band together to form an address from which spending is only possible if a certain number of signers provide a valid signature. The most common multi-signature setup is 2-of-3, which means that there is a total of three signers, and a minimum of two is required to produce a valid spending condition.
Wrapped Bitcoin, the tokenization of Bitcoin on Ethereum, is a contract with 13 signers. On the other side of the blockchain scene, most, if not all, Ethereum “layer twos” are still on “training wheels” secured with similar multisig contracts on Ethereum L1. For example, the Ethereum ↔ Polygon bridge used to be a 5/8 multisig, and maybe it still is. Besides the obvious security risks of having so few signers, there is also the privacy risk, since the addresses of all parties in a multisig contract are easily visible. I am also fairly certain that such setups carry high regulatory risk, given the amount of money they handle, as they would be classified as VASPs in OECD member states and should be registered as such. This is precisely why users have to go through KYC procedures if they want their wBTC unwrapped or BTC wrapped. Why don’t these rules apply to Ethereum layer two networks, I don’t know?
By utilizing threshold signature and signature aggregation, such multisigs can be scaled up to dozens or even hundreds of signers. Moreover, due to the nature of Schnorr threshold signatures, the identity of participants remains obscured. From the outside, it looks like a single address and a single signer. Hiding the signers makes the system far more robust, as nobody can be singled out, threatened, blackmailed or prosecuted.
Let’s imagine a hypothetical wrapping protocol that would be using a threshold signature schema such as FROST or ROAST.
Bridging from a UTXO-based blockchain to a smart contract platform, where DeFi usually happens, is actually quite tricky since the two systems work very different. Due to this, reliance on some sort of custodian address for deposits is required. The custodian is usually a multisig address in these kinds of setups. But let’s try to imagine something different. In this scenario, the counterparty for custodianship of the UTXOs is an entire network of signers.
- To deposit, you ask the network for the new deposit address. It is always a fresh address and is generated on demand by the network of signers by some sort of distributed key generation.
- Upon the confirmation of the deposit, the network gives you a signature, which you use to mint new wrapped tokens on the foreign chain by interacting with the wrapped coin contract.
- To withdraw, you submit a request to withdraw and present a proof of burn on the foreign blockchain. You also submit your desired withdrawal address.
- The network deducts a fee and proceeds to assemble the transaction by randomly selecting UTXOs it controls. It then signs and transmits the transaction.
The user treats this network of signers as a black box, which does its job without exposing its internal processes. However, these internal processes can be quite complicated. Internally, the network can be coordinated by a blockchain, it can have punishment mechanisms for dishonest signers, mechanisms to replace unresponsive signers, reputation tracking and much more.
If a bridging service like this can demonstrate that its internal consensus is a consequence of a peer-to-peer protocol with clear and pre-defined rules — I believe such a network would not be considered a VASP, in the same way a block producer on Peercoin network is not a VASP, and could provide its services without AML/KYC procedures on its customers.
Bridging to Sidechain(s)
In another example of bridging to somewhere, the destination chain can be a sidechain, a layer two. Using the same, or similar, bridging service, users can send their peercoins to a specialized sidechain that offers EVM compatibility or any other popular Turing-complete virtual machine. Such a blockchain can be both private or public, it can have a native token, but it can also natively use wrapped peercoins. It can be secured by PoS, dPoS, PoA or anything else. There can be a myriad of such chains, too, each with a different set of features and catering to a different audience. If you want to have a private sidechain where you and your friends play poker, it probably makes sense to simply use an existing professional service like this bridge to get your peercoins over to the sidechain.
There is another way to bridge to sidechains, without using a custodian bridge service. It can be done directly using DLCs.
- The user moves their coins into a DLC contract on the Peercoin chain, a contract where the counterparty is a specialized service providing exactly this sort of bridging.
- Both the user and the service select a suitable oracle (network of oracles) which will deliver proof of burn on the sidechain.
- Since the coins are effectively locked now, the proof of lock can be issued to the user (a signature), and the user can mint the same amount of wrapped coins on the other side.
- The user can use the wrapped version of peercoin for any service offered by this sidechain.
- When a user wants to withdraw from the sidechain and move back to Peercoin, they destroy (burn) the wrapped coin.
- The oracle continuously monitors the sidechain for burn events. Once the event has occurred, the oracle releases the private key (discrete log) for their public key, allowing the signature to become valid and — unlocking the DLC.
Let me try to imagine a less degenerate scenario that is not related to cryptocurrency, or gambling.
Insurance
In this scenario, UK-based Company “C” trades with a regime at risk of being sanctioned by Western countries due to human rights violations. The business is lucrative, but the risks are high. To protect against potential losses from such sanctions, the Company enters into a Discrete Log Contract (DLC) with an insurance company. This contract will pay out to Company C if a network of oracles confirms that the regime has been sanctioned.
The oracles, chosen for their reliability and access to geopolitical data, independently verify and report on the sanction event. If the predetermined conditions are met — specifically, if the oracles confirm that sanctions have been imposed, the company is eligible for payout. This process mitigates the risk of political sanctions affecting Company C’s business activities, providing a secure, private, and efficient insurance mechanism without the need for traditional financial institutions.
The use of multiple oracles reduces the risk of manipulation, ensuring the contract’s integrity. If the regime is not sanctioned by the time the contract expires, Company C does not receive a payout, and the insurance premium stays with the insurance company.
All these technologies like threshold signatures and massive multisigs, distributed oracles and smart contracts that work off-chain won’t really become meaningful unless they’re easy for everyone to use. For these technologies to truly make a difference, they need to be made user-friendly. This means hiding all the complicated tech stuff under the hood and presenting it in a simple and clear interface to users. Only by making these technologies approachable and straightforward can we hope to see them become a part of everyday life. And that’s precisely what we’re working on by integrating all these new technologies into the Peercoin Flutter wallet.
It’s all about making sure that these advancements are for people, not just for tech experts.
Human meaningful and human centric.
