Skip to content

Solid State Transfers #97

@igormcoelho

Description

@igormcoelho

I propose a NEP that will help us give much more control over token operations, specially on Neo 3 (although already applicable for Neo2, even existing NEP-5 tokens could do that without changing contracts). This proposal is simple: allow better balance tracing over storage-based assets, like NEP-5.
On UTXO, it's all connected, the past transactions, past balances, and current balance, giving great auditability capabilities.
On storage-based assets, such as NEP-5, we only execute some transfer operation on the chain, and our balance is automatically updated, but no record is kept for how much existed before (and after).

This NEP requires that assets prove that they exist, before actual transfer.

Example for NEP-5:
transfer myaddress youraddress 100

How much did I have before? zero? 1000? We don't know, unless we process the whole chain at that point (or restore the point with some state trie). This proposal is simple, yet powerful:

Transfer operation NEP-5 (using solid state records):
value = balanceOf myaddress
assert(value == 250) # ok, now I'm sure what my funds were before transfer
transfer myaddress youraddress 100
value2 = balanceOf youraddress
assert(value2 == 600) # ok, now I'm sure what your funds were after transfer

If this transaction passes on chain, we have a evidence for two things: I had 250; and I have transferred 100 to you; and now you have 600.

More elaborate versions of this could require saving previous and after balances, for both addresses, but personally I think that a single "before" register is enough to guarantee quite a few nice properties. For NFT implementations, the count before and after of transferred asset (if countable), or hash state (if hashable); so this is not just intended for NEP-5, but for all onchain assets (not mandatory standard, of course, use it if you like).

Justification:
Neo Blockchain is quite special, in the sense that it doesn't add a solid state reference to block header itself, giving fundamental bugfixing capabilities to the network (that already could have prevented hundreds of hard forks on it). There are many proposals for state tracking on Neo3, in many different formats, however, I believe this proposal here adds much guarantees and auditability to NEP-5 tokens, with or without state tracking. And this is something users (or user wallets) can do for themselves, it's easy and gives strong certainty of instantaneous states on the chain, just by looking at operations themselves.

Drawbacks:
This may not be wanted on situations where several transactions compete to enter a block, in very high throughput operations on same address (like exchanges), as this NEP also fundamentally breaks the possibility of "double-spending" of any kind of token, in any situation. Yet, for common daily transfers it looks quite nice. User wallets could use it to send assets to an exchange, and withdraw operations on that same exchange not necessarily using this (that's why only prev balance is desired, not destination).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions