Technical Guide | How Do Digital Contracts Decentralize Ownership?

Author: Giacomo Zucco

Translator: Tiandao Reward

Source of this article: blockchain_camp

In this article, we will explore the concept of currency based on the idea of ​​using digital puzzles as a way to reproduce scarcity, and based on supply control mechanisms to give digital currencies a certain degree of hardness. Proof of ownership through signatures and scripts and a technology called CoinJoin.

• Data analysis: how to maintain the emerging market structure of digital currencies under the market waterfall
• Ethereum 2.0 first design specification review results released: reasonable structure, strong security measures, only fine-tuning required
• QKL123 market analysis | Bid Bitcoin? Understand these signals (0325)

Proof of ownership: signature

For the second time, our funding plan has focused our attention on human topics and "who" issues.

You set the conditions for issuing new sats, but what about transferring them? Who has the right to change the data in the shared balance sheet and transfer ownership?

If there is a central agency responsible for reassigning sat, follow the instructions of the current owner (for example, you can log in to the system using the classic username and password method, just like your previous e-gold experiment), a fragile single point of failure Reappear : Why move from physical gold to PoW-based "digital scarcity"?

On the other hand, if every user has equal rights to redistribute ownership, your system will not work at all : everyone will be encouraged to continue assigning others' sat to themselves. You need some kind of consistent authority definition protocol that everyone can check independently.

The solution is an encryption technology called digital signature . It works like this: First, Alice chooses a random number, called a private key, and she keeps this number absolutely secret. She then passed the number to the mathematical function through a special mathematical function that was easy to apply in one direction, but almost impossible to reverse. The result was another number called the public key, which Alice did not keep secret at all. Instead, she made sure that Bob knew it. In the end, she passed the private key and message through a second function, which was difficult to reverse, which resulted in a large number called a signature. Bob can apply the third and last mathematical function to the message, signature, and Alice's public key for positive or negative verification. If the result is positive, he can be sure that Alice authorized the message (authentication), she will not be able to refuse the authorization later (non-repudiation) and the message has not been altered (integrity) during transmission.

In a way, it is similar to a handwritten signature (hence the name) , and everyone can easily check some public samples, but it is difficult to copy without the owner of the "right hand". Or wax seal, everyone is easy to check according to official seal, etc., but without the correct wax pattern, it is difficult to copy.

Therefore, you can change the agreement so that part of the proof of work can be reused independently with a digital signature. The first model you implement is simple: each user independently generates a private key and creates a public account, labeled with the corresponding public key. When users want to transfer ownership, they create a message that includes their account, receiving account, and the number of sat they want to transfer. They then digitally sign and broadcast the message, and everyone can verify it.

It is interesting that many well-known (but possibly pseudonymous) developers can use similar schemes to sign different versions of the software so that they are free to change, improve, repair, update, review and view the software, and Any end user of the system. The signatures can be independently verified using a minimized and fragmented network of trust before running their respective preferred versions, without the need for a single authorization to centrally distribute the software. This process enables true code decentralization.

Scripts and smart contracts

However, you do not want to limit the conditions that each peer must check to just the validity of the digital signature before accepting any changes in the shared balance sheet.

You decide that each message can also include a script : a description that states that the receiving account (or multiple accounts) must meet again before it can be spent again. For example, the sender may need a combination of several keys (linked or separated) or a specific wait time to consume. Starting from these very simple (and easy to audit) basic types, complex smart contracts can be built that effectively program funds even without a central participant.

Durability (and scalability) issues

Unlike an encrypted messaging system (if Alice sends some messages to Bob, only Bob can read them), your solution is not really optimized for durability (if Alice sends Bob to sat, it must be displayed outside of Bob Her news, at least for those who will get the same sat in the future).

Money is circulating. The payee cannot trust any transfer, and even if the signature is correct, it cannot verify that the transferred sat has actually been transferred to that particular payer, and so on, from upstream to the original PoW-based issuance. As long as sat has sufficient liquidity, active peers can understand a large number of past transactions, and can use forensic analysis technology to statistically correlate quantity, time, metadata and accounts, thereby making many users anonymous and eliminating their denial Sex.

This is problematic: as discussed in Part 2, durability is a fundamental quality for money, both from an economic and sociological perspective.

Smart contracts exacerbate this problem because specific overhead conditions may be used to identify specific software implementations or specific organizational policies.

This lack of durability is more serious than affecting your previous e-gold experiments. At that time, you stored most of the transaction metadata on a central server, but at least only yourself, not anyone (including many Mallory agents), who could access it! In addition, you can implement some particularly advanced encryption strategies to make yourself at least partially invisible to what actually happens between users.

There is also a small scale issue related to this design: the digital signature is very large. In order to verify everything, the transmission chain that the payee needs to receive includes many signatures, which may increase the cost of verification. Also, account changes are difficult to verify in parallel.

A new paradigm: "CoinJoin"

To alleviate such problems, you decided to change the basic entity of the model from a bank-like account to unused transaction output (UTXO).

Unlike the instructions to transfer sat from one account to another, each message now contains a list of old UTXOs. These old UTXOs are from past transactions and are consumed as ingredients. There is also a list of new UTXOs as The product "generates" and prepares for future transactions.

Bob must provide a new, one-time public key for each payment he wishes to receive, rather than issuing a single, static public key as a general account reference (such as a bank IBAN or email address). When Alice paid him, she signed a message that unlocked some sats of the previously created UTXO and re-locked them to some new UTXO.

Just like with cash, spendable bills don't always match payment requests, so changes often need to be made. For example, if Alice wants to pay Bob 1,000 satellites, but she only controls a few UTXOs that lock 700 satellites, she will sign two UTXOs that consume 700 satellites (total 1,400 satellites unlocked) and generate Two new UTXO transactions: one associated with Bob's key, locked for payment (1,000 sat), and the other associated with Alice's key, locked for change (400 sat).

Assuming people don't reuse keys for different payments, the design itself adds darkness. But this is even more the case when your users start to realize that UTXOs consumed and generated by a single transaction do not necessarily come from two entities.

Alice can create a message, use the old UTXOs she controls and generate new UTXOs (associated with Bob), then she can pass the message to Carol, Carol can simply add the old UTXOs she wants to consume and she wants to create New UTXOs (associated with Daniel). In the end, both Alice and Carol signed and broadcast the synthetic message (both paid to Bob and Daniel).

This particular use of the UTXO model is called "CoinJoin". (Trigger warning: In the actual history of Bitcoin, this usage is not the basis for Satoshi Nakamoto's design of the UTXO model itself, but rather a potential problem in the design of other developers after UTXO was released many years ago. It breaks the statistical linkability between outputs while retaining the so-called atomicity: transactions are either completely valid or invalid, so Alice and Carol don't have to trust each other. (If one of them tries to change a partially signed message before adding their own signature, the existing signature will be invalid.)

Your system may change, and in fact it may further improve the situation: a different digital signature scheme can replace the digital signature scheme you are using now, it is a linear signature. This means: after obtaining two private keys (nothing except two numbers), signing the same message for each message, and then adding the resulting signature (that is, two very large numbers) together, the result Exactly the sum of the two public keys with the corresponding correct signatures associated with the two initial private keys.

This sounds complicated, but the meaning is simple: When CoinJoining, Alice and Carol can add their respective signatures and then only broadcast the sum, and everyone can verify against their public key sum. As we said, since the signature is the heaviest part of the transaction, the possibility of broadcasting only one rather than multiple broadcasts will save a lot of resources. External observers will eventually suspect that every transaction is CoinJoin, as many users may pursue efficiency gains. This assumption will break most forensic heuristics.

Even without further improvements, the UTXO model has improved scalability in some way: unlike state changes in the account model, it enables validation to be batched and parallelized efficiently.

So far, you have learned:

• You can use digital signatures for decentralization;
• You can use a scripting system to convert transactions into programmable smart contracts;
• A more complex paradigm called CoinJoin can further increase darkness and scale.

But since your users can issue sat and transfer them in a completely decentralized way, how can they ensure that they follow a single chronology, thereby avoiding double spending attacks or trying to modify the inflation schedule?

This is a question for everyone, I hope this article is useful to you, welcome to discuss with us in the comment area.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!