many gas has been transferred to this address on TestNet. The gas belongs to those who can take them.

This mission has been released for 24 hours and known by many blockchain experts, but nobody took it. So it deserves the title of mission impossible.

This article is to talk you out of developing verification contracts and into learning application contract development first.

The learning curve of neo.org documentation is not steep but precipitous.

I did a sampling research, and found that someone has finished the learning of verification contract by following this documentation.

So I decided to climb this steep mountain with full confidence in my learning competence in the hope of teaching you how tolearn verification contract after I learned it well. Now I am back and jumped from the precipice.

These two money is from the reward mission account.

Was the token transfer successful? Partially. I couldn’t be more disheartened when I tried to withdraw the money with NEOGUI.

Only when its first parameter is 0214 and when Runtime.Trigger==Verification, it returns true.

For an verification contract, the transaction is only true when it returns true.

It’s easy to think about it. But where do we input this 0214? We need to talk about the whole transaction and

Verificationcontract.

Verification contract and transaction

Verification contract is executed at transaction verification stage. If verification contract doesn’t return true, then this transaction verification fails, it

Can’t be written into the block and can’t be queried.

Verification contract is different from application in essence. Application contract is definitely implemented in the block after it is verified and written into the block.

NEO transaction has input and output. It’s a UTXO model. Transaction input is a list,

each of which is a reference to a UTXO. The output of the transaction is to make a new UTXO.

Transaction input and output is money. Destroy input and make output. If you are still confused about UTXO, please don’t look down. Go back and

Figure out what UTXO is.

A transaction includes the following information:

1. Input list

2. Output list

3. If it’s an application transaction trade, there is also application contract script. And there are others for

Other transactions. All of these constitute unsigned contracts.

Have you found that it has nothing to do with verification contract?

Do you still remember signature? You need your private key to sign the transaction when you send tokens to others?

Actually this is a special case of verification contract.

1. How many witnesses are needed depends on how many input address(payer) in a transaction.

2. To sign a transaction means to add the witnesses of the transaction initiator.

3. NEO is a complete smart contract system. Each witness is two scripts, one is called verification script, the other execution script.

The above three points are puzzling. Don’t rush, there are something more puzzling.

a detailed explanation of signature

1. Each account address of NEO is a script, which is a two-instruction smart contract. The pseudo-code is:

Push publickey

Syscall Checkwitness

The hash value of the script is the user's address, usually the user's address is expressed in the form of strings which is converted from the hash value through base58. The string form is exactly equivalent to the hash value. It can be seen, NEO's address is the hash value of smart contracts. The reverse is also true, the hash value of each smart contract of NEO is an address.

So I can send tokens to a smart contract and withdraw tokens from a smart contract, because my address is actually a smart contract address.

2. The verification script of witnesses is the smart contract this address corresponds to. It can’t be modified and can’t be verified if hash is different.

3. Witness's execution script is a smart contract that is used to provide parameters like a validation script

Let’s go back and have a look what happened when I send some tokens from

My address?

1. There has to be utxo from my address in the input when transferring tokens to others.

2. build transactions.

3. to add witnesses, the verification script is my script.

4. Set the execution script of witness, which is a one-instruction smart contract, its pseudo-code is

Push signdata

5. Send rawdata that contains transaction data and witness data.

6. Verify transactions, execute script push signdata, end. Verification script pushes its own pubkey and checksig. The two parameters of this function is signdata and pubkey. Check it, if it’s successful, transaction is true;

If not successful, the transaction is false.

Is signature much more complex than you imagined？

take the rewards away

After figuring out the relationship between witness and transaction, we can withdraw money from the reward contract.

Let’s build a transfer transaction.

Input n and find utxo from reward contract address as input.

Output1: to your own address

Output2 is optional: get change for the rewards address.

Witness: verification script=rewards contract.

Execution script=parameter

Because the parameter is a string and an array.

Reverse push.

the pseudo-code is

Push0 // add 0

Pack // To build an array with the above 0 means it’s a blank array.

Push bytes(”0214“.as bytes())//push ”0214“

The binary is：00c10430323134

The information has been told you, then you just piece a custom contract together.

NEOGUI has its tools, right? Use F12 to get it out. Go test it. It will be definitely fun. You can understand what is precipitous learning curve is.

And even you’ve done them all right, you can’t take the rewards.

I felt puzzled here for a long time and delved into NEO’s underlaying layers line by line.

There is a restriction. Instruction is only allowed to be pushed in the execution script or the execution of script fails. And

Verification contract fails, the transaction is false.

The pseudo-code of the execution script is:

Push0 //加入0 add 0

Pack // To build an array with the above 0 means a blank array.

Push bytes(”0214“.as bytes())//push ”0214“

the binary：00c10430323134

There is one pack. If it’s beyond allowed range, the transaction must fail.

Then we know that there’s no way to use array type of parameters.

The good thing is the second parameter of the reward contract is useless, you can push whatever you like.

We change the execution script to:

Push0 //add 0

Push bytes(”0214“.as bytes())//push ”0214“

the binary：000430323134

Ok, if you are patient, go play NEOGUI and F12.

not deployed?

If you have read some documents of NEO smart contract. You may find this contract is not deployed.

Smart contracts don’t need to be deployed. You can directly call it. No problem.

Then on what conditions does a smart contract need to be deployed? If this smart contract is to be called by appcall, it has to be deployed on the chain and pay expensive fees. Application

Contract is basically this type. In order to achieve convenient repeated invoke, there is also internal storage. Considering all of these, starting from application contract is much easier than starting