BM's latest article: How to overcome artificial restrictions with untrusted smart contracts

Author: BM (Daniel Larimer)

Original: Medium

Source: Planet Daily

Translator: Nian Yinsi Tang

• Analysis of the market on October 18: Will the curse that will fall for a long time be played again?
• Password Punk and Super Sovereignty: written on the eve of the 134 stable currency project
• Interpretation of the US Economic Research Institute "Who should issue CBDC" report: ignoring the consequences of wholesale digital legal currency

Original title: "Star Frontline | BM Detailed Untrusted Contract How to Overcome Artificial Limits"

On October 17th, BM (Daniel Larimer) published an article on Medium, giving his opinion on “How to overcome artificial constraints with untrusted smart contracts”. The full text is as follows:

Smart contracts increase economic efficiency by making it easy to bundle and send rights and obligations in a way that is untrustworthy. This has far-reaching implications for those who attempt to restrict the transfer of rights in contracts in the form of fees, time locks, purchase ballots, indivisibility or some other form of restriction. Anyone who designs a smart contract that relies on artificial constraints to implement some kind of game theory should read this article first.

Imagine if you want to create a token smart contract that will charge 2% to each person when they make a token transfer. This is actually a limit that cannot be enforced. Anyone can create a new contract to accept your token deposit (pay 2% of the fee), then reissue a new negotiable token and charge a lower fee or no fee. Others can withdraw tokens from the new contract after completing an unlimited number of transfers and paying the last 2%. Most people will accept and trade tokens without fees because the contract can be designed to be immutable and untrusted. This example is intended to explain how smart contracts can increase market efficiency and bypass artificial restrictions such as high fees.

Now suppose you want to create a new token that tries to lock in the value of a long-term contract, and your token will be mortgaged for different lock-up periods. Implementing a time lock is as simple as charging a 2% fee for a transfer; however, it can be easily bypassed by using other smart contracts.

In the case of a time lock, you can create a new account and lock the token into the smart contract, then distribute a new tradable token. The value of the token is similar to a zero-risk bond that can be paid at a certain date in the future. Assuming that the underlying asset is valuable and there is a need to trade zero-risk bonds, there is no way to prevent the underlying value of the bond from being sold or placed in another smart contract.

The EOS RAM market is also an artificially restricted asset that only allows users to buy and sell RAM at a fee. RAM can be effectively transferred by buying or selling simultaneously in a single transaction and generating an actual transfer fee of 1%. If someone just wants to trade the economic value of RAM, not the utility of RAM, then you can build a simple contract to issue tokens that anchor RAM, and these tokens can be transferred for free. This may even create a secondary RAM market with no transaction fees.

But the utility of the underlying assets cannot be easily bypassed. Token RAM is different from actual RAM because you can't actually use token RAM for any storage without first converting it to actual RAM and paying a 1% transfer fee (by synchronizing purchase/sale) . The same is true for stoled tokens: you can trade the economic value of a mortgage token, but you can't easily emulate any additional utility, such as voting rights or CPU time (depending on the utility of the token).

For example, suppose a mortgage token provides voting utility. A contract that represents a group mortgage and then reissues the token must be "sponsored as a group." Assuming that each mortgage balance can only be voted for by one person, the entire team will need to organize a meta-vote to determine the voting plan. This will reduce the effectiveness of a small number of team members as they will be forced to vote with the majority.

If the mortgage token system allows each mortgage to assign its votes to multiple options, then a “liquid-stake token” can simply emulate the meta-voting and the vast majority of the underlying mortgage tokens Will be passed to the “mobile mortgage token”.

Even limiting each mortgage can only vote one vote is not a real limit. For a “liquid mortgage token” contract, it is very simple to manage any number of mortgages and vote for each mortgage based on the meta-voting of the “current mortgage token” holder.

Although it is not necessary to say anything, I still have to say that before implementing these solutions, we should carefully consider them from the legal, regulatory and tax perspectives.

Prevent smart contract management

One way to prevent attempts to bypass the expected limit is to prevent accounts from being managed by smart contracts. This can be done by requiring that all interactions with the restricted contract be signed by the actual private key and requiring only one operation per transaction. The purpose of this is to reintroduce the "trust" element by asking someone to hold and use the private key.

Suppose we use a 2% transfer fee token to lock in all operations from other smart contracts. This trust model will be changed to a centralized transaction where tools like Tether are reissued. This has the potential to fundamentally change the legal nature of this arrangement and hinder the implementation of the alternative.

While this approach may prevent attempts to bypass these limitations, using secure multiparty computing, hardware security devices, or minimal trust is sufficient to achieve the goal of bypassing artificial limits. This will also reduce the security and overall flexibility of your contract of use in many smart contract platforms.

Embrace contract freedom

Another option to combat the market's need for financial freedom is to accept it first. Instead of trying to charge a 2% fee, it is better to use zero fees to reduce competition. Rather than trying to block RAM transfers, it's better to make it transferable. Rather than trying to force a person to hold a mortgage token, it is better to make these mortgages substitutable and tradable. Charges are only feasible if the friction generated by the workaround is greater than the cost of the cost, or if there is some utility that is not easy or impossible to replicate (such as market liquidity).

On many EOSIO-based public blockchains, its system tokens are designed to provide utility that represents a prorated allocation of available CPU time. This underlying utility cannot be provided by the token of the underlying CPU, just as the RAM cannot be used by the token RAM holder until the token of the underlying CPU or RAM resource is redeemed in advance.

Assuming that there is a market that wants to lock in people's long-term interest in CPU value, it will allow people to mortgage the current CPU in exchange for more CPU time in the future. In fact, you can lend your CPU as a long-term contract and get interest in the form of CPU time.

Now let's assume that someone has a large sum of money locked into a one-year CPU mortgage contract, but because of the liquidity crunch, cash is needed right now. In theory, they should be able to sell their CPU mortgages to others, and the value they receive from the sale will be the net present value of the CPU delivered within a year of the given expected interest rate. Long-term value or a change in the one-year mortgage CPU rate will make the long-term value of the CPU higher than the current CPU.

Making the mortgage position liquid does not diminish the value of adjusting the voting incentive mechanism. If the actions taken by the holders holding the long-term mortgage will have a negative impact on the expected value of the future CPU, then each person holding a one-year mortgage will immediately be exposed to the market reaction to the loss of their capital. On the other hand, if their current vote decides to increase future expectations (ie, adoption) of CPU demand, they may profit immediately.

Investors holding mortgages do not have to wait a year to earn or suffer losses, and they immediately realize the expected long-term consequences of current operations. The liquidity of these mortgages in turn reduces the average rate of return on mortgage payments, while also increasing the cost of attack based on long-term mortgage-based voting systems, thereby allowing more people to mortgage.

If a voting system requires tokens to be mortgaged for 10 years without an untrusted liquidity option, then the participation rate will be low. In this way, people choose to buy a small amount of "sacrifice" tokens and mortgage for 10 years, and then the cost of attacking the network will be reduced. However, the cost of using the same method to attack a liquidity mortgage solution is much higher. Again, legal, regulatory, and tax issues may affect how this approach can be implemented in practice.

to sum up

Smart contracts should embrace freedom and avoid artificial restrictions that can be easily bypassed. It is not impossible to charge some fees, but it must be done when the charges are more convenient than other workarounds. While increasing the participation of voters, the mortgage position is liquid, thus retaining the incentives for voters to think long-term. Real-time market feedback on the long-term consequences of current governance decisions may be more convincing than allowing voters to wait until the future to achieve their own gains and losses. This takes advantage of the wisdom of the public to punish some of the voters – they mistakenly believe that it is better to take actions that would suffer losses to enhance long-term value than to regret when they are irreparable in the future.

Disclaimer: Everything in this article is my opinion, not the opinion of my employer or anyone associated with it. Do not assume that anything in this article will be implemented or adopted by any blockchain. Anyone considering implementing the proposed solution should consult with a consultant to resolve any legal, regulatory or tax consequences.

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