On Free Transactions, Discounted Claims and Sybil Attacks

[igormcoelho]

Summary or problem description
A discussion on possibilities to keep "free tx" on Neo3, specially allowing NEO->NEO and NEP5->NEP5 transfers. I want to focus on a proposal for Discounted Claims.

Do you have any solution you want to propose?
Based on today's discussions, specially with @belane, something came to my mind...
We are previously considered to have sponsored contracts #1147 , so as customers can simply transfer their NEP5 without worrying about GAS. The hard/difficult issue with that proposal is that GAS is still on the hands of the contract, and it must allow it on every runtime, issuing operations that could/should not exist during Verification. This proposal is different: it allows direct GAS redirection to users, but they are limited to use that for contract execution.

Users may want to transfer Native NEO, that may require GAS to perform simple transfers. The problem of having free tx (in a similar model than Neo2 with fixed 10 GAS fee) is that spams can happen, and "10 GAS fee" may not mean much... GAS price may vary a lot, and there's also possibilities that operation GAS costs may also change in time. So, the 10 GAS allowance may work one day, and not on the next.
Some blockchains consider giving free operation slots to users. Honestly, I'm not fully aware of how this can happen safely, but the central issue is how do we define "users". Who should be the users being "benefited/incentived" by the free tx proposal?
U1) someone who operates thousands of tx per day?
U2) someone who transfers some times in a day?
U3) someone who transfers once in a while (few days)?

For me, U1 is a heavy user, and as such, it should pay for heavy batch of operations. U2 may not operate heavily, but it already knows how to get some GAS to perform its frequent operations. But U3 is the most tricky one in my perspective: it may be someone that just one its NEO for the first time, but he/she cannot even play with it, transfer it, even to learn! too bad...

I think we can find a way to please these users, specially U3, with a proposal for Discounted Claims. The idea is the following: users that hold NEO get GAS, but this GAS may not be enough (in price) to provide eventual transfers. If GAS operation cost (in relation to claim) goes too low (near zero), all operations (light or heavy) would flood the blockchain, and if it goes too high, claim cannot help users (it would take so long). The proposed idea is that automatic claims of GAS -> NEO accounts stay at a CLAIMED slot until they are consumed (similar to "old" claimable field). When you use the CLAIMED GAS for a single execution, you get a massive discount (say 99%) for its GAS operations (up to some configurable max limit), and the returned GAS (change) is not in CLAIMED slot anymore. The idea is that a user holding a very tiny portion of NEO (say 1 NEO) would be able to transfer it using a tiny amount CLAIMED GAS.
I may be wrong, but I think this is much better than "execution slots" or fixed max gas fee. The reason is that "execution slot" is not clear about how could be the cost of such slot... and just using max gas fee gives opportunities to a generalized spam. I believe that this strategy here forces users to hold NEO for a while, and when they use these discounts, they would compete for the "free tx" part of the block (that would become a "discounted tx" part of block). I think this reinforces the utility of GAS and importance of holding NEO, to backup your operations.
Finally, for NEP5 it's more tricky, as the user cannot have any NEO to claim its GAS... other blockchains simply require users to have the token, but I think we may try to find a more ellaborate solution.
Imagine user gets some tokens, and want to play with them, in simple operation. It may not have any NEO or GAS, but contract itself (NEP5) may hold some NEO on behalf of its users. The idea is that, if enough NEO is hold there, and discounted claims can operate on users behalf, this may incentive people to hold NEO on every contract. To make this operate smoothly, we could have a syscall that registers the "redirection rate" for each "contract user", in a fractional/percentage format or parts/total format.
Example (used on a NEP5 contract):
syscall Native.Neo.SetClaimContractTotalShares 1000 # registered 1000 "shares" of "something"
syscall Native.Neo.SetClaimContractUserShare 30 ScriptHashA # registered 30 "shares" of "something" to ScriptHashA

Obviously, names 'SetClaimContractTotalShares' and 'SetClaimContractUserShare' are not good enough ( I hope they are useful now, to minimally understand 😂 ), but this should give 3% of CLAIMED GAS for user ScriptHashA.

This way, the idea is that claimed GAS for this NEO-holding contract will be automatically distributed by native NEO/GAS system to every "user" (a ScriptHash). This gives execution GAS allowance to users, and we may discuss if we could just give CLAIMED GAS for execution (not give actual "transferrable" GAS). The Real GAS change could go back to main contract, so the only purpose could be to easily give "execution" power to users.

When I mention Sybil Attack, is that as @vncoelho pointed out, some user may just hold NEO in multiple accounts, to have more "discounted GAS"... that's true, it's like simulating being multiple people, but anyway it would need to compete with the discounted part of block, and also to handle security for multiple accounts. The "theoretical minimum NEO value" for this approach is also adjustable in time, so it could be reasonable for 1 NEO, or 10 NEO, or 100 NEO, with varying times from 1 day, 2 days, 1 week... just by changing the "discount factor" on claimed GAS.

I hope this is useful to raise some possibly interesting discussions.

Neo Version

• Neo 3

Where in the software does this update applies to?

• Ledger
• Network Policy
• Other: Native NEO/GAS

[igormcoelho]

@erikzhang @shargon @vncoelho any thoughts?

[igormcoelho]

Very simplified explanation of algorithm:
Step 1) Native NEO computes GAS generation for claims
Step 2) It gives CLAIMED GAS to every elligible NEO account, with proportional value
Step 3*) Now, it verifies which accounts that received GAS and are deployed contracts. If CLAIMED GAS is over some minimum limit L, it starts GAS redistribution process within registered scripthashes of that contract, by specified Shares. We can control Native NEO/GAS system parameter L to avoid too much GAS redistribution (if L = infinity, no redistribution ever occurs; L=0, every GAS will be redistributed).

Note: This proposal can work for ANY contract that holds NEO, so it's not limited to Native or NEP5 transfers, it's just an example.

[shargon]

So, the 10 GAS allowance may work one day, and not on the next.

Totally agree.

The idea is that, if enough NEO is hold there, and discounted claims can operate on users behalf, this may incentive people to hold NEO on every contract.

If we lock the NEO and the GAS if you want free TX, maybe we can avoid the spam.

But his proposal focuses on NEO and GAS tx. We should have free tx regardless of whether we run. what happens if I only have GAS and I want to use the blockchain, but free?

[igormcoelho]

what happens if I only have GAS and I want to use the blockchain, but free?

In fact, this proposal is not free anymore, but heavy discount on recently claimed gas (which is much like being free 😂 ). But if you only have GAS, you would need to pay full price...

Can we solve this @shargon ? ideas?
The only way I see now, the Native GAS contract should hold enough NEO for their "users", so that the generated GAS is enough to pay for their operations 😂

We should have free tx regardless of whether we run.

In fact this proposal works for any kind of contract, not just native NEO/GAS. Any contract holding enough NEO and with a registered redistribution mechanism can allow its users to operate the gas generated by it. It's like having a quota on the GAS generated by the contract, with an easy mechanism to validate this information (we can do this during Verification without needing to execute any script).

[Tommo-L]

Good idea, I have some question about it.

Q1: How do we charge if the script calls multiple contracts?
Q2: If the above method is adopted, the price will close to zero. Is this good or not?
Q3: Although we already have a massive discount (say 99%), I'm still worried that for a user who has just received NEO and wants to transfer it right now, he may still be unable to transfer it.

[igormcoelho]

Excellent questions @Tommo-L ! I'll start upside down (easiest to hardest):

Q3: Although we already have a massive discount (say 99%), I'm still worried that for a user who has just received NEO and wants to transfer it right now, he may still be unable to transfer it.

This is easy. The discount 99% is just a random number... as long as we define the purpose of the discounted tx, e.g., "we want users to transfer 1 NEO two times per day", the discount needs to account for how much gas 1 NEO will generate in such period (12 hours), and give such a discount that such a fraction of GAS would be still enough for that. Discount can be as great as we want it to be. If we think that 1 NEO / 12h is too cheap, it could be 10 NEO / day (thus 1 NEO / 10 days), everything is possible.

Q2: If the above method is adopted, the price will close to zero. Is this good or not?

Price will go to zero? I don't know... only if no utility is left for gas. I think that GAS should be required for complicated executions, this proposal just covers very basic ones, and with a big usage timelimit for users. Maybe this is good for users that have NEO, cannot simply buy GAS (or don't quite know how), or just want to vote... maybe it should be one free tx / month, it's already so much better. Big frequent operations should require GAS, this is certain.
So, it's good! (for me I'm convinced at least 😂) Since we will strongly increase usability and easyness to adopt the platform for most users. The discounted price will only compete within a limited space in blocks (currently the "free tx" space), and discounts can only be used once, since the GAS change would become "regular GAS" (user would need to wait until new CLAIMED gas is generated).

Q1: How do we charge if the script calls multiple contracts?

This is the hardest. I've been thinking on some solutions, none of them are perfect until now. The "trivial" solution would be to organize CLAIMED gas in several slots of user account, thus making a difference between where the GAS came from, and where the change would go. This is good, because Contract owners will get their GAS back, and users can only execute contract-specific things with that GAS, and the obvious bad reason is that it becomes "too complicated" (similar to old times utxo, but slightly better). The platform could track which "type of GAS" is spent on each contract (to correctly deduce them), but I'm pretty sure this will imply on a necessary simplification where each account could appear only once at most on each block, or even on the mempool (otherwise it gets even more complicated to keep track of so many simultaneous "possible discount double-spents").

Honestly, when someone is sponsoring another one, benefits generally need to revert to only that specific reason (otherwise it's not that useful), so every approach that allows contracts to sponsor users will eventually lead to some similar situation where "one gas is not necessary the same as other gas". As long as people cannot change these "discounted gas", no new crazy market can appear, so I believe it's important to strongly tie this to execution-only, and every other usage just makes user lose the discount.

[shargon]

What do you think about lock neo if you want a free tx?

[Tommo-L]

U1) someone who operates thousands of tx per day?
U2) someone who transfers some times in a day?
U3) someone who transfers once in a while (few days)?

For me, I'd like to use this method to solve the U1 case, some contracts can lock or staking some NEO for cheaper price, like USDT contract, third-party oracle, dex, and other defi contracts, etc.

It's a bit like the exchange's ladder charges. From business perspective, it is good to consider lower fees for vip customers.

[igormcoelho]

What do you think about lock neo if you want a free tx?

It's another intersting perspective @shargon ... if we force people to lock Neo, they can have some sort of increased GAS generation rate. And these "extra GAS" could only be used for contract execution, and lost when NEO is removed from staking.

For me, I'd like to use this method to solve the U1 case, ...

This way, contract holder could also stake lots of NEO to guarantee its thousands of free tx, based on extra generated GAS. Do you think exchanges would make this effort of staking some NEO, to guarantee low cost on its operations @Tommo-L ?

[Tommo-L]

Do you think exchanges would make this effort of staking some NEO, to guarantee low cost on its operations

😂 I think they will, that's how they treat their VIP customers. Here is the Huobi tiered fee.