Have you ever come across a scenario in which the company needs to configure an internal service and expose a public network interface for debugging. At the same time, in order to ensure security, token verification is set for this interface. Only members of the group know the token. Obviously, there is a security risk here, and members of the team may disclose the token. In order to be traceable, it is decided to assign different tokens to each member of the team. However, there is always one operation and maintenance personnel who can get all the tokens, so you decide to use asymmetric encryption. Each member of the team generates a key pair locally, submits the public key to a white list, and saves the private key. Each time the interface is called, the private key is used to sign the request content, and then the server verifies the signature and the public key in the white list. To this point, we have implemented the binding of token and identity. However, there is still a problem: is there a top authority that can add the public key to the whitelist, delete it later, and delete the history? In order to prevent this kind of thing from happening, we can use email or IM to inform all members of the group every time we modify the white list. In this way, even if the records on the server are deleted, the group members still keep the local records. The problem comes again. If you don’t know the reason, a group member shows an email with a modification record in the white list, and other members don’t have this email, how can you judge the authenticity of this record? Suppose we are sure that the service provider sending the e-mail is reliable, and the service provider will only send the e-mail when it receives the message that the white list has been modified, then the e-mail should be real. But what if someone fakes a message that “the white list has been modified” and sends it to an email service provider? We found that loopholes may appear in every link,
PKI system (public key infrastructure) can not avoid the problem of how to prevent records from being deleted, and how to verify the authenticity of the data recovered in different places. As long as there are traces to follow, we can find the truth. The problem is that it is possible for hackers or insiders to delete or forge records. In order to ensure that records are not deleted, companies must use third-party services, and it is better to use the services of large companies, because large companies generally have higher security. This does not mean that risks can be completely avoided, such as the deletion of gitlab code, the deletion of business order data and so on. Fortunately, we now have a better solution, blockchain. You may not have heard of blockchain, but you must have heard of bitcoin. As a peer-to-peer e-cash system, bitcoin has been generating new transaction records since its birth. These transaction records can be traced back to 11 years ago, and the approximate time of each transaction can be verified by hash algorithm. In addition, in a single transaction of bitcoin, up to 4GB of data (OP) can be attached_ PUSHDATA4)。 You can understand bitcoin as a very reliable cloud service company. You can do crud in the way of incremental update on bitcoin, and the records of each operation are almost impossible to be deleted (they will be distributed to nodes all over the world). Even if they are deleted, as long as the original transaction and merklerot of the transaction are kept locally, The authenticity of the transaction can be verified, and the previous operation record cannot be forged after a period of time. As for privacy, it’s also a good solution. You can encrypt the data and then publish it. You can use bitcoin as a hard disk. How to interpret the data is defined by the business logic in the code.
Some people may say that this does not solve the problem of illegal data being written to the blockchain, and the user needs to verify the legitimacy of the data contained in the transaction through the local business logic, which requires a lot of calculation. For example, in the scenario mentioned above, each member of the team submits his own public key, signs his own operation with his own private key, and then sends it to the interface, in this case, to the blockchain. In this step, the attacker can send a large number of illegal messages to consume our computation (we need to verify the signature for each message). Although the attacker needs to pay the cost of bitcoin transaction fees, with the bitcoin transaction fees getting lower and lower, and if our verification logic is more complex, it is possible to offset this cost.
The simplest way to use the data is to verify the validity of the data by the data consumers
This method of verifying the validity of data by data consumers is also known as “offline verification” or layer 2 network. Usdt, a stable currency widely used in exchanges, is issued in this way. To verify whether a usdt transfer is legal or not, a special node program needs to be run. This node program will trace back from the first transaction issued by usdt to determine the balance of each address at each time, so as to filter out those “counterfeit money”. So, is there a better solution to prevent illegal data from being published on the blockchain from the beginning? Of course, there is such a scheme. We call it layer 1. Bitcoin has a built-in script virtual machine. Every transaction needs to be run by this virtual machine to get a true or false result. If the result is false, the transaction will not be packaged into a block. In other words, it will not appear on the blockchain. The script language itself is Turing complete, it can implement any verification logic. Script executors are mining nodes. Bitcoin miners are often mentioned in the news. Part of their work is to execute the script in the received transaction. When there are more and more complex scripts in bitcoin network, the speed of script execution will affect the income of miners. At this time, miners will gradually increase their investment in this area, such as using FPGA or even ASIC and other proprietary hardware to execute bitcoin scripts. In this way, the cost of executing a script will be significantly reduced, making the form of attack we mentioned above unprofitable.
Complex application form: implement verification logic in transaction script.
At present, there are high-level languages that can be compiled into bitcoin scripts,scrypt. Its syntax is not very different from the common high-level languages. You can get started soon and install a plug-in in the vscode editor to use it.
Next, I will use layer 2 and layer 1 to develop an application with friendly operation interface, which realizes the token permission transfer requirements mentioned at the beginning of the article. Pay attention to the author, so as to receive the push at the first time.
In this paper, “bitcoin” refers to the bitcoin data link containing the block “000000000002f5268d72f9c79f29bef494e350e58f624bcf28700a1846”.