Abolition of global assets

[erikzhang]

In NEO 2.x, we have two different ways to create assets, the first is to create a global asset based on UTXO, and the other is to create a NEP-5 token that is stored in a contract. For a long time, the biggest challenge in the development of smart contracts on NEO is to handle global assets in contracts.

Why don't we put the global assets into the smart contract in NEO 3.0? As a result, the development of smart contracts will become very easy.

For system assets (neo and gas), we can use the functionality of native contracts to turn them into NEP-5 tokens.

[igormcoelho]

Fully supported! Perhaps that is even feasible for Neo 2.X Erik. We can create a special NEP-5 contract for NEO and GAS, and hardcode it to be accepted as system fee and network fee. Using the GetNotifications scheme, it is possible to guarantee that a payment was performed in the same invocation transaction, and if not, the contract can THROW, which will rollback all operations in same invocation tx, right?

[erikzhang]

...and if not, the contract can THROW, which will rollback all operations in same invocation tx, right?

Correct.

[igormcoelho]

We created a draft proposal on how Merkle Patricia trees could be useful to create safer storage and to provide a door out of UTXO model: neo-project/proposals#74
Everyone in community is invited to join us as a co-author :)

[jsolman]

One advantage of the UTXO assets is that the verification fails on double spends naturally. NEP5 tokens don't generally have to bring the contract on for verification, so it doesn't have a chance to fail double spends ahead of time, and leaves garbage in the chain where the NEP5 transfer actually fails.

If it were possible to have any call to a particular method have a verification that gets called to block the transaction from entering the MemPool that could solve the problem, but the problem with that is you can't tell before the contract executes whether it will call another contract that will invoke such a method that should trigger the verification up front.

I would like to think about it more and discuss it further.

[jsolman]

I have an idea that could work for making NEO and GAS smart contract based assets and still cause verification failures to prevent double spends. We could create a new asset standard with adjustments such that to send funds it is required to bring the asset contract on as a witness. Attributes can be used to specify the sender, receiver, and amount. Then the balance of the sender can be checked against the amount during verification and fail if there is not enough balance.

[jsolman]

We can transition NEO and GAS to contract based assets on NEO 2.x in a one way fashion.

Definition / Requirements

• The new contract based assets will allow receiving traditional system assets NEO and GAS and convert them.
• Contract based NEO generates contract based GAS.
• A timeline of x months can be determined after which point UTXO based NEO and GAS will not be allowed to be sent to any address other than the contract based asset addresses to convert to contract assets.
• Any needed tools or plugins to help exchanges need can be built (one such tool is to validate balances are accurate)

Benefits

• Contract developers then have time to work on updates to their contract for NEO 2.x and come up with their own transition plan as long as it happens before the cutoff point.
• Transition to a new chain for NEO 3.0 can occur more smoothly since contracts will have already been updated to support NEO and GAS as contract based assets.

Negatives

• Failing during verification for not enough balance becomes less reliable, and transfer may fail more during application execution (we can at least fail for the case of not enough funds during verification, but for double spends, it will have to fail during execution); Please comment if you have ideas that could help improve this

[igormcoelho]

As discussed with core members, it looks like that a transition of Neo/Gas using Native Contracts is reasonable, for two points:
(1) The hash identifier will be preserved on Neo 3.0 network (see naming rule on: #303)
(2) Gas generation/claim can be easily done with native logic

One possibility is to do a one-way Neo UTXO -> Neo Native, as we discussed @jsolman, without possibility to go back, that could cause issues (different prices?), but at the same time prepare the ground for the transition to Neo 3.0, including all tools/wallets, which is very important.
Perhaps, until the complete abolishment of Neo/Gas UTXO, users could be able to go back (Neo Native -> Neo UTXO), so no one is harmed during a long transition (for early adopters), and when Neo 3.0 is ready to go, a short schedule of few months is put, to allow converting from one network to the other (perhaps, as a practical application of NeoX?).

Regarding your comment on negative aspects @jsolman:

Failing during verification for not enough balance becomes less reliable, and transfer may fail more during application execution

I don't get it, and I don't see any negative aspect. Can you clarify? No double spends will be possible, as usual, and all issues must fail on verification (any reason to not fail?).

[ThomasLobker]

I don't get it, and I don't see any negative aspect. Can you clarify? No double spends will be possible, as usual, and all issues must fail on verification (any reason to not fail?).

@igormcoelho I think a double spend without UTXO could be possible if the user is trying to send tokens, the transaction doesn't go through at first, then after some time he tries again with a new transaction and now it goes through. Now his second transaction doesn't disqualify his first (missing) transaction, so if it would still be broadcasted then it would be still be a valid transaction and you would lose your tokens. This can happen if your node for the first transaction was going offline temporarily, but recovers later and will still broadcast the transaction.

Wallets can mostly work around this issue, but that's still not 100% reliable.

If NEO would become a non-UTXO NEP-5 compatible token, then we would need an extension or something to disqualify any out of order transactions. For example: we could keep track of the transaction hash for each successful transfer of each address, then require the wallets to send the last hash along with the new transfer. This way transfers can still be chained in the right order.

[igormcoelho]

@ThomasLobker you are correct, we perhaps need to attach a sequence number on the InvocationTx message. A higher seq number always has priority over lower.
Another way is to attach a timeout script, which is easy to do, and wallets should wait that time before proceeding with a new transaction. Timeout is quite easy to do, and I'm just waiting to finish testing on dBFT 2.0 to proceed on that: CityOfZion/neon-wallet#1417

[steven1227]

UTXO model can track each coin's trace but NEP-5 can not. I believe in some perspective, UTXO can promote financial transparency.

[igormcoelho]

@steven1227 as long as a trusted storage system exists, NEP-5 will be as safe as UTXO, and much more efficient. As @erikzhang always emphasizes, UTXO could still exist on Neo 3.0, so perhaps it's time for us to design a NEP-X for that (UTXO tokens): neo-project/proposals#88

[shargon]

Could be closed @erikzhang ?