NEO Smart Contract Development(II) an Additional Exploration of Mission Impossible

The application contract is comparatively easy in the NEO smart contract development. Yes, you are right. The application contract is easy.

The trilogy of the application contract: deploy, invoke and see the results. There is a lack of tools for seeing results, but deploying and invoking neogui can still support you for test.

The verification contract is troublesome, because neogui cannot support you to test verification contracts very well.

This is a difficulty. We asked you to try and withdraw money with a verification contract. Anyone can withdraw money with a password. But it’s not easy to withdraw tokens with neogui, right?

Let’s explore this topic further. A more valuable usage scenario.

How to limit the amount of money a user can withdraw from a smart contract?

Don’t worry. If you know nothing here, it’s very normal. I think there are no more than 10 people in China who know NEO’s verification mechanism. A normal NEO learning mechanism should be：

1. Develop a wallet Client first.

2. Then understand the invoking of application contracts. To call the application contract with your own wallet Client and the scriptbuilder that you wrote by yourself.

3. Understand the verification contract. Write some verification contracts and trade with your own wallet Client and test them.

There is little information on NEO official website. Without reading NEO source code, no normal people can learn this just via information on NEO official website.

The significance of limit mechanism on withdrawing money

For example, Nep5’s ICO mechanism, the user invests NEO and gets Nep5 tokens. This is a vending machine mechanism. You give me gas or neo, I give you the game currency. Using UTXO assets to buy NEP5 assets, or whatever.

There is no return mechanism in the ICO template offered by NEO. Because it is more difficult to achieve, it is not easy to limit how much money the user can withdraw from the ICO contract.

This is what it means to be able to achieve the ICO automated return mechanism by limiting how much money you withdraw.

For example, the mechanism of vending machines has many other functions. For example, I save a sum of money for my friend and he can withdraw it when his birthday is up.

For example, two people bet, guessing a random number after five blocks is odd or even , clever you immediately understand if you can limit the UTXO assets users can withdraw from the smart contract, you can use UTXO assets directly to do various indescribable gambling business.

Let’s go further to think about it, In a fully automated exchange, if you use GAS to buy some kind of NEO tokens and sell the GAS when its price goes up and withdraw them. I have not seen otcgo.cn published its source code. I have not studied neox source code . That’s one of the core mechanisms with which users withdraw UTXO assets.

What’s the difficulty here?

It’s very hard. The first response is storage saves a value directly. Save it when you withdraw it. Based on this value, we can achieve any limit logic.

100 gas is here. Withdraw it if you can!

Rest assured you can’t withdraw it.

This contract looks like anyone can withdraw the gas. But Storage.Put triggers something abnormal. Actually no one can withdraw the gas.

Look, the best thing you are thinking about is to limit how much can be withdrawn via Storage, but you can’t do that. When the verification contract is triggered, Storage.Put doesn’t work completely.

Think back to the ICO template, there was no fully automatic refunds, right? To be exact, the reason why users can’t withdraw NEO from the smart contract is this.

So there’s no solution?

There is a famous saying: there are always more solutions than problems.

If you just have an overview of it, you may feel Storage method doesn’t work.

Let’s look at this logic carefully.

1. Money withdrawing limit mechanism is needed. You can’t continue withdrawing money after withdrawing all of them.

2. Storage is needed to control this mechanism.

3. Storage.Put Storage.Put doesn’t work when verification contract is implemented.

It seems the logic chain is broken. But when we remember one feature of UTXO, this broken logic chain can be reconnected. One UTXO can only be used once. Here we go! Can’t we just use it to control how much money users withdraw?

First, there is a need to limit the mechanism for withdrawing money ( each withdrawing user is given a dedicated UTXO from which only he can only withdraw money)

Second, you need to use Stroage to control this mechanism (storage directly saves a map <utxo, targetaddr>, a utxo is limited to only be transferred to a fixed address)

Third, Storage.put doesn’t work when a verification contract is implemented contract (but Storage.get works. ah, bingo)

We adjusted the train of thought a little and reconnect it. We do not need storage to directly control how much money a user can withdraw.

1. You can control one UTXO to transfer tokens to which address with storage, which can be achieved.

2. A UTXO can only be transferred once, which is natural.

With the above two points together, this self-withdrawing of UTXO assets logic makes sense.

To achieve self-withdrawing of UTXO assets with two transactions.

For the first transaction, the smart contract is indispensable for assets. smart contracts transfer tokens to itself to generate a user-specific UTXO, and invoke application contract, record the UTXO specialization.

For the second transaction, withdraw money, transfer tokens to user address with this dedicated UTXO.

Practice

Let’s look at the source code directly.

Here is just to explore this mechanism, we set the first step for the super administrator to pay the user money. You think about it carefully, to achieve a user refund from his own NEP5 address, and this is not much difference. We do not let so much code to interfere with our core mechanism.

the first step

transfer tokens to yourself with this smart contract

As shown in the picture, it’s 1000 gas. Transfer 100 gas to yourself and give out change of 900 gas. The money doesn’t leave the smart contract address. Then the super administrator transfers 30536.6 GAS to the super administrator, which the super administrator doesn’t pay money. Meanwhile, invoke the smart contract. Set the 0st output UTXO of this transaction to transfer tokens to acfW…address only as shown in the picture.

It needs a SC’s witness because a smart contract is used. Just pass two parameters, don’t use Array.

Let’s analyze what we’ve done on the above.

1. A smart contract transfers tokens to itself. The 0st output is a UTXO, 100gas, which means we allow AcfW…address to transfer 100gas away from this smart contract address.

2. The super administrator transfers tokens to himself, which doesn’t produce direct value.

He just let the verification contract come here and append the verification certificate and then transfer tokens as you like.

1. APPcall givemoney(0,Acfw…)

Here is the code. To compile this transaction’s hash and the 0st output of this transaction into a key. Maybe you’ve noticed I’ve written a ConvertN function, because the form of integers’ byte[] is not stable, I need it to be certain, or else, 0000 00 and blank byte[] both means 0, which will be chaotic.

Then you can see I directly storage.put to store the target address. This is the first step.

To make a 100 gas UTXO and record to whom it’s given in the Storage.

the 2nd step

The 2nd step is easy, for this transaction doesn’t need any signature.

For the verification script of this smart contract, just fill out whatever you like.

Then you can withdraw the money.

Let’s analyze it.

I divided this verification contract into three parts

The red part is to judge that this transaction allows only one input and one output, otherwise you can’t withdraw money. Of course, you can use the cycle to handle more complex situations. Remember we are only exploring this mechanism.

The yellow part is to get the target this UTXO allows from storage.

The blue part is to determine whether the output of the transaction aligns with what’s saved in the Storage .

If yes, you can take the money away, UTXO will be destroyed.

If not, the transaction is not true, UTXO is still there.

What we’ve done

To sum up, we propose a mechanism that can be used to withdraw UTXO assets under the restriction of smart contracts on the NEO framework, and write the code to verify it.

This mechanism can be used for:

1. Use NEO’s UTXO assets such as NEO, GAS for ICO return mechanisms.

2. Expand the previous one to automate the sale of certain digital assets and returns.

3. Lottery, betting and other activities using NEO’s UTXO assets.

4.decentralized exchanges.