Scripts without scripts: support for smart contracts without smart contracts in Bitcoin
It is known that Bitcoin's blockade capacity is limited. At the same time, smart contracts can be resource intensive. Therefore, although Bitcoin-blockchain always supported the main functions of smart contracts, these two technologies never fit together.
However, a recent study conducted on the initiative of Andrew Poelstra (a mathematician of Blockstream company ) can help fix this. Recently introduced as a key part of his presentation at Scaling Bitcoin Stanford, the Scriptless Scripts offer the potential for the complete transfer of some smart contracts to Bitcoin-blocking, while leaving all Bitcom's network security tools at the disposal of users.
Bitcoin and smart contracts
Smart contracts, first proposed by the digital currency veteran Nick Szabo in the 1990s, are essentially self-executing contracts. In the most typical application, they send money from one party to another when certain conditions are met. For example, if someone is listening to a song, there is an automatic payment from the content recipient to the performer (the copyright owner).
While smart contracts are often associated with the "second generation" of blockbusters, such as the Etherium, Bitcoin also always supported the basic functions of smart contracts. In some ways, any Bitlock-Transaction is technically a smart contract: the funds are usually moved provided that a valid cryptographic signature is provided. Slightly more advanced smart contracts, such as multisig and timelocks, are used for the operation of second-level protocols, such as the Lightning Network.
However, smart contracts based on blockbuster have certain problems. First, as they become more complex, more resources are needed to fulfill them. This is especially problematic because all nodes of the network must execute the contract and not only the parties to the contract (participants in the transaction).
Such execution of the contract throughout the network also means that the terms of the contract will be known not only to the parties to the contract: the entire network will know exactly the essence of the contract. In addition, this will also negatively affect the interchangeability. If a smart contract for some reason is unpopular, the reputation of the funds associated with it - publicly visible on the blockroom - can be spoiled.
As smart contracts become more complex, they will pose a security risk. Alternative code implementations can, for example, interpret the details of contracts a little differently, thus hampering the maintenance of consensus among all nodes of the network. In addition, potential errors in these smart contracts will also be visible in a publicly accessible network, which increases the likelihood of hacker attacks.
But Pelstra, among other things, believes that many of these problems can be solved by moving most of the contracts from the blockbuster [to the periphery]. Instead of using all the nodes on the network to process the entire smart contract, this function should only be performed by the parties involved in the contract.
The point is to ensure the correct execution by the network of the results of the contract: payment must be made only if the required conditions are met.
Schnorr
Initially, Poeelstra began researching "scripts without scripts" (a name that he also invented himself) in the context of the Mimblewimble protocol. This truncated version of Bitcoin offers higher confidentiality and better scalability but does not support the script (code elements built in Bitcoin-Transactions that support the most basic functions of smart contracts).
So, Pelastra figured out how to get useful functionality provided by scripts, without the need for their presence on the block, ie, "scripts without scripts".
The main thing in "scripts without scripts" is that (rather) regular cryptographic signatures can indirectly indicate that it is not part of the transaction that includes the signature itself. In other words, when someone applies a signature to verify a normal Bitcoin-transaction, it is considered that the smart contract, even outside the block, is conscientiously executed.
This is made possible by the signatures of Schnorr signatures. These types of signatures have not yet been implemented in the Bitcoin protocol, however, it is possible that they will be applied already within a year or a little later.
Signatures Shnorra allow you to combine the signatures, that is, several signatures can be mathematically combined into a single signature. And, what is important for this application, this mathematical operation is "linear". Basically, this means that you can perform relatively simple but very expressive mathematical operations with these signatures.
In a very simplified form this works as follows:
Private keys and signatures are, of course, just numbers, and the latter is obtained from the first. Since this is a simplified example, for example, one private key looks like 10, and half of the Schnorr signature obtained from this private key looks like 10,000. And the other private key looks like 15, and the second half of the sign of Shnorr is 15,000. In this simplified example, the signature Shnorra, in the end, will look like 25,000 (or 10,000 + 15,000).
And since both halves of the signature are just numbers, you can perform mathematical operations with them. So, in this simplified example, the difference between these halves is 5000 (or 15000 - 10000).
Although the reality is more complex, Shnorr's linearity allows several types of mathematical "techniques" to be performed.
Smart contract
Now suppose that the user wants to listen to an online song of some artist. The song belongs to the artist, and the song will be available to the user who wants to listen to it online, if (and only if) the server where the song is stored will receive the artist's signature. Since we simplify, let's say, the "signature of the song" looks like 7000. To listen to the song, the user is ready to pay one bitcoin to the performer for this song signature. (Let's say he wants to hear this song so much.)
In this simplified example, the user and the performer can automate the purchase using two procedures. First, they create a pretty normal Bitcoin-transaction, which sends one bit-kick from the user to the performer, if both the user and the performer provide each of their half signatures to Shnorr to create the full signature of Shnorr. (In fact, this step requires extra precautions so that no one loses money, but this is solved relatively simply.)
At the next stage, things get a bit complicated.
The contractor knows how his half of Schnorr's signature looks; since we simplify, suppose it will be 8000. And he also knows how his song signature looks - 7000. Then, the performer can calculate the difference between two values, which is 1000. This value is called "adaptive signature" (adaptor signature). The performer then passes this "adaptive signature" (1000) to the recipient of the content.
This is where the cryptographic magic happens.
By changing the normal signature verification method, the content recipient can actually verify that the "adaptive signature" that he just received (1000) really equals the difference between the half of the artist's signature and his signature of the song - although the content recipient still does not have access to one of these signatures. (And thanks to cryptographic techniques called "zero-knowledge proofs", something like this can be done in a surprisingly wide range of scenarios, not just in signatures, as shown in this example.)
Now, having convinced himself of the receipt of the "adaptive signature" (1000), the content recipient, in turn, can give the artist his half of the signature of Shnorr, because as soon as the performer uses half of the user's signature to create a complete signature and transfers it to the Bitcoin network, the performer automatically will reveal his half of the signature of Shnorr (8000) to the recipient of the content.
Using half the artist's schnorr signature, the content recipient can now subtract the "adaptive signature" (1000). Subtracting the "adaptive signature" from half the signature of the artist's Schnorr (8000 - 1000), the content recipient does recognize the "signature of the song" of the performer (7000). And now he can listen to the song.
In other words, when translating a transaction that brings one bitmaker to the performer, it automatically sells the signature to the content recipient, this is a smart contract.
From the point of view of the block, that is, of the rest of the world, the deal is quite typical. Information about the smart contract, not counting the actual "settlement transaction", is never recorded in the block. No one will ever know that the base contract was executed - no matter what song the user listened to - and the data relating to the contract will never need to be calculated or stored by anyone other than the parties directly involved in the transaction.
