State Rent vs State Staking

[ilblackdragon]

Moved from https://commonwealth.im/near/proposal/discussion/380-state-rent-vs-state-staking

State is the most important resource of the blockchain network. This is what all nodes in the network need to maintain and what they all come with consensus.

There are two major ways to charge for storage without undercharging (what happens now on ETH):

• Charge state rent
• Require some amount of $NEAR token on the account to occupy a byte.

There are also more complex alternatives, like what EOS is using, where RAM (their name for state) needs to be bought explicitly at the current market price. Price then fluctuates depending on the available RAM. These kinds of mechanics lead to lots of weird market manipulations and disadvantaged developers.

State Rent

State rent mechanics is when we charge each block some amount of $NEAR from the account for the occupied size. For example if account is 1kb, and price is 7e-15 $NEAR for block / byte, we will be deducting 7.168E-12 $NEAR per block or ~0.00022 $NEAR per year.

Pros:

• Developers who need to deploy their contracts and applications, that might be taking ~100kb - 1mb of space will be paying in as-you-go mode.

Cons:

• Account balance becomes "virtual", because we are not updating it all the time as we charge. Currently for example in NEAR - we never show the real balance still.
• Accounts must be deleted when rent runs out. This creates both weird user experience and potential vectors where attacker will try to drain user's account in some way, delete their account and re-create account with the same name to get all of their resources. Simplest way is to get user to sign a tx that will transfer all of their assets to some lending application, leaving account without enough to pay for rent and then by taking over the account - receive all their funds back.
• We have some weird code around validators, to make sure they have enough money to pay for rent.
• Even though we can burn these fees, at the end it doesn't require to have that much balance on accounts - removing this as a Token Sink.
• Price is fixed in $NEAR

State Staking

Alternative model in the simplest form is to require some amount of $NEAR on account's balance to store 1kb of data.

This means that total supply of $NEAR will map to some amount of storage. For example 1B of tokens maps to 1TB. This is roughly 1 $NEAR for 1kb of storage.

Specifically, the mechanics will work next time:

def process_transaction(account, tx):
   ... do actual work ...
   if sizeOf(account) > account.amount * config.price_of_bytes:
       fail_and_revert(tx)

(e.g. replacing check_rent function with different condition and removing apply_rent completely with extra fields from the account)

Pros:

• Improves user experience around account ownership: doesn't require to deduct balance (if you have 10 $NEAR, you will still have 10 $NEAR in a year), doesn't have account deletion problems due to low balance. Tx that reduce your balance below required to store data - will just fail with meaningful error.
• Creates very solid Token Sink, both because of useful storage and "excess" of $NEAR.
• Creates lending and borrowing market for $NEAR for storage purposes.
• Price can adjust as we add more storage into the system by adding extra shards.

Cons:

• Making user-centric contracts where we deploy 500kb contracts would require a large enough balance (e.g. 500 $NEAR) and to store any extra data that might require more .
• Developers now required to have a larger amount of $NEAR to deploy their contracts. There might be more considerations around pricing over time that they must consider.

The last item is actually very interesting, because it creates new opportunity for something similar to Polkadot's "Initial Parachain Offering".

Let's say developer expects to need 10Mb of storage for their application but they don't really have expected amount of $NEAR.

On one hand, they can borrow it for their contract (this can be implemented in trustless way, to not require collateral on such loan).

On the other hand, developer can sell their third-party token for $NEAR or for loaning $NEAR for some period of time. Benefits of such approach:

• $NEAR holders have an alternative way to lend or provide their tokens in exchange for new application token which gives a way to participate in the new ecosystem on top of $NEAR and capture value there as it grows.

• These $NEAR token holders immediately interested in success of such application and become it's promoters. This also removes some of the tensions between third-party tokens and native token-based applications. Like Bancor vs Uniswap, where Uniswap which doesn't have it's own token is preferred by community because it didn't create "another token". There are few models for such third-party tokens to even further reduce this tension.

Balance between validators staking and using $NEAR for storage will be maintained via the fact that as more storage is required - more $NEAR won't be staked but will be allocated for storage. This means that each staked $NEAR will capture bigger portion of inflation.

Additionally, we will need to have a clear program to onboard developers initially. For example grants to developers who built interesting applications on TestNet to provide them with grant funds to launch on MainNet.

Thoughts?

[ilblackdragon]

@evgenykuzyakov re: storage required for user contracts.

How big change is to make user contracts point at existing deployed contracts.

E.g. developers normally deploy a contract (requiring once to stake $NEAR for storage), and then when they create user accounts (or deploy sub-module to the user's contract) - they will just point at this existing contract.

I saw you suggested to burn $NEAR for deploy forever - how does that evaluate vs leveraging the same as staking $NEAR?

I think the only problem of accessing contracts across shards, meaning this contract needs to be available on all shards.

[evgenykuzyakov]

I saw you suggested to burn $NEAR for deploy forever - how does that evaluate vs leveraging the same as staking $NEAR? I think the only problem of accessing contracts across shards, meaning this contract needs to be available on all shards.

You're right. It should be deployed on all shards, which makes fee non-trivial since you pay for a single shard, but it's deployed everywhere. At the same time it can go to permanent read-only storage that doesn't have to be in the state, but instead can be stored somewhere else.

How big change is to make user contracts point at existing deployed contracts.

E.g. developers normally deploy a contract (requiring once to stake $NEAR for storage), and then when they create user accounts (or deploy sub-module to the user's contract) - they will just point at this existing contract.

Again it doesn't solve sharding issue. Assuming we launching with the current plan, it may be possible to postpone the issue after the mainnet.

Still I'd prefer to burn funds once. It would create a new field in the trie that points to the permanent contract codes by something like col::PERMANENT_CONTRACT+contract_hash. Then account will be able point to any permanent contract for free without deploying it. It'll work for a single shard, with multi-shard environment, this storage has to be replicated on every shard.

[MaksymZavershynskyi]

I agree with @evgenykuzyakov 10kb for 10N is too low, it will prevent user contracts, we should be offering at least 100kb for 1N, or even better 1Mb for 1N. With 10kb for 10N it is going to be 1 contract per organization building on us, at best.

Also, as @evgenykuzyakov said, the problem is that the code needs to be duplicated across shards. But even within a single shard, we don't want user contracts to proxy through (point at) some central contract, because it will immediately inflate our traffic by 3x through receipts (i.e. decrease per-shard TPS by 3x), will make the overall DevX much more complex, and will increase the UI latency by 3x.

[ilblackdragon]

Discussion with @evgenykuzyakov offline:

• User contracts can point at existing contract hash. E.g. we will need to add action to DeployHash(hash). If this hash exists on this shard - it will execute that code, otherwise will fail. E.g. no proxy needed. For sharded network - just need to deploy the same contract on all shards (which with fixed sharding that we have right now is possible). Going forward this is where common contracts can come in.
• My suggestion is to benchmark 10TB for 1B $NEAR -> e.g. ~0.0009 $N per byte or 1kb per 1 $N. The user contracts problems is addressed above. If this is too expensive - we can lower the price. But we definitely should not be ever increasing the price, hence let's start more expensive.

FYI, 1MB for 1 $N would target ~953TB of storage :)

[MaksymZavershynskyi]

Discussion with @evgenykuzyakov offline:

• User contracts can point at existing contract hash. E.g. we will need to add action to DeployHash(hash). If this hash exists on this shard - it will execute that code, otherwise will fail. E.g. no proxy needed. For sharded network - just need to deploy the same contract on all shards (which with fixed sharding that we have right now is possible). Going forward this is where common contracts can come in.

Our DevX went from "you can deploy and execute any simple program on us" to "you need to have a very large amount of assets to do that, or you need to loan using some other token as a collateral, or someone else needs to deploy the contract for you but you "point at them" through the hash and this contract needs to be deployed on all shards". Imagine explaining all that to a person who comes to us and wants to write and run a simple program, because they've been told Near is a developer-friendly blockchain.

Remember that we are trying to target Web2 developers. So image a Web2 developer comes to us who wants to write a simple dApp, they need to do either of the following:

• Have >100N (because our contracts are >100kb) -- this is extremely expensive;
• Have some collateral in other tokens. How many Web2 developers that we are trying to convert have various tokens available for collateral loan?
• Have someone else do it for them;
• Do not deploy their contract, but instead "link" to another contract already deployed to the blockchain. But they wanted to build their own contract, instead of linking to someone else's!

I think this is a really really bad DevX, much worse than the disadvantages created by the state rent.

• My suggestion is to benchmark 10TB for 1B $NEAR -> e.g. ~0.0009 $N per byte or 1kb per 1 $N. The user contracts problems is addressed above. If this is too expensive - we can lower the price. But we definitely should not be ever increasing the price, hence let's start more expensive.

1kb per 1N is extremely expensive.

FYI, 1MB for 1 $N would target ~953TB of storage :)

Then state staking is unfeasible the way it is currently proposed. We either need to allow 1 petabyte state or require 100N per deployed contract. This calls for a different design.

[abacabadabacaba]

I don't like the idea of state staking. If we implement state staking, this is what will happen:

There will be some users which have a lot of money, and there will be some users that need a lot of storage. Therefore, there will be a market for lending money for state staking.

This market will essentially be state rent, just implemented on a different level. It will be worse than state rent implemented natively by the blockchain. The only advantage it will have is that developers that have a lot of money will be able to use their own money instead of borrowing.

If we implement trustless borrowing, we must deal with the question: what happens if the borrower doesn't pay on time? Should we force the money out of his account (and delete the account if it doesn't have enough money to pay for its storage)? This is the same problem that we have with state rent – switching to state staking doesn't really solve it.

For me, the main benefit of state rent is that it matches the economic reality: it costs validators resources to maintain the state over time, and the cost is proportional to state size × time. Therefore, with state rent, users pay for the resources that they actually use.

Here is how some of the problems with state rent can be solved:

• Virtual balance: it is easy to compute the real balance at any point in time. If the balance recorded in the state is b, rent paid until time is t_p, current time is t, account size is s and price per byte per time unit is p, the current balance is b-ps(t-t_p).
• Account can be deleted: we can add a requirement that rent must be paid for at least the next n blocks (where n is a parameter), and revert any calls after which this is violated. Even if an attacker finds a way to drain the user's account, he cannot reduce the balance below what is necessary to pay for n blocks, so the user has at least n blocks to sort this out before the account is deleted. Also, it would be great if we had some kind if account ID that is not reusable (i.e. if an account is deleted, it is not possible to create a new one with the same ID), but this is a different issue.
• Price is fixed: doesn't really have to. We can allow validators to vote on the price, as well as any other economic parameter.

[janedegtiareva]

Is there a spec on how we would surface data on state staking to developers? We need to plan the changes to developer tools.

[janedegtiareva]

For devx, at the absolute minimum we will need to handle these use cases:

• as a dev deploying contract, I want to have meaningful messaging if there is insufficient balance
• as a dev, I want to see how much of my balance is inaccessible because it's been staked
• a ton of documentation explaining this pricing model.

[evgenykuzyakov]

For sharded network - just need to deploy the same contract on all shards (which with fixed sharding that we have right now is possible). Going forward this is where common contracts can come in.

It's should be addressed automatically in the future, but doesn't have to be fixed right now. Basically with S shards in order to permanently deploy a contract of size C bytes, you need to pay S * C * P, where P is the price per byte for single shard state. You wouldn't need to think which shard it's going because it'll need to be handled automatically though global storage.

We assume that permanently deployed contracts are going to be resharded without extra cost. Because effective price P will decrease proportionally to number of shards increase.

My suggestion is to benchmark 10TB for 1B $NEAR -> e.g. ~0.0009 $N per byte or 1kb per 1 $N. The user contracts problems is addressed above. If this is too expensive - we can lower the price. But we definitely should not be ever increasing the price, hence let's start more expensive.

The math is wrong: 10 * 2**40 / (10**9)) is about 10995.1 bytes per $N, so 10$N gives you about 107.3Kb. It's still more than our average contracts, but it's at the same magnitude as our contracts.

With sharding the price per byte is going to decrease, so 10$N will be enough for most default contracts.

Our DevX went from "you can deploy and execute any simple program on us" to "you need to have a very large amount of assets to do that...

It's still going to be possible to deploy contracts on testnet which is the default way. Once you believe you have a contract worth deploying, the developer should acquire capital.

There will be some users which have a lot of money, and there will be some users that need a lot of storage. Therefore, there will be a market for lending money for state staking.

We can make restrict state staking to unlocked balance only. Then if you have a free balance, better delegate it to a validation staking. So storage/state staking will not be rented out.

---

Storage amount based on balance is simpler and safer

Overall this change will makes computation much simpler than the current rent taking. DevX improves because you don't have to worry about your contract disappearing and all data getting deleted. If a contract doesn't function anymore because it's out of available storage, ANY user can fund it and it will receive more storage immediately. But the state is not going to be deleted. This will make it more secure.

Shared contracts

With sharded blockchain we'll have to move to a world where contracts state is sharded. Ideally it's sharded per user, so shared contracts will become important. With current state rent I don't see a way to support shared contracts economically.

[bowenwang1996]

With current state rent I don't see a way to support shared contracts economically.

How is it different with state staking?

[evgenykuzyakov]

How is it different with state staking?

You burn S * C * P tokens to deploy a contract. It's equivalent to create an account on every shard and deploy code them and never touch these accounts again.

[bowenwang1996]

I see. That is definitely appealing

[evgenykuzyakov]

as a dev deploying contract, I want to have meaningful messaging if there is insufficient balance

With fixed rate of byte per $N, we'll be able to easily compute it on the front-end or through RPC.

available_storage = int(account.balance * rate) - account.storage_used

as a dev, I want to see how much of my balance is inaccessible because it's been staked

locked_balance_for_storage = int(account.storage_used / rate)

a ton of documentation explaining this pricing model.

We'll have to update documentation to update rent towards fixed rate.

[MaksymZavershynskyi]

To remind us, the reason why we started discussing State Staking as a replacement of State Rent is because we considered virtual balance and account deletion a bad DevX. State Staking would've been a good replacement if it was cheap (which what I thought was the case) but 10N per standard contract is too much and now we are coming up with multiple workarounds. Now we consider making the way we deploy contracts to testnet different from the way deploy contracts to mainnet. This contributes to already growing gap between front-facing DevX that we present in the slides and the DevX that people experience when they are building real projects on us. Also, are we going to start integrating it into near-shell and devtools? For example, will near-shell automatically provide developer some loan when they attempt to deploy a contract, if yes where the collateral will be coming from? Even if don't want to integrate it in Applayer (cc @vgrichina , @kcole16 ), explaining it would take a lot of resources from the DevX team (cc @potatodepaulo ). Remember that slide that we have that shows how many steps Ethereum developer needs to go through to deploy a contract, it looks like our DevX is getting closer to it (cc @ilblackdragon ).

We can make restrict state staking to unlocked balance only. Then if you have a free balance, better delegate it to a validation staking. So storage/state staking will not be rented out.

This is an assumption that validating is going to be more profitable than renting. We cannot know at what rate state is going to be rented out by the third-parties. As with AWS there are going to be multiple rent models: reserved storage, ephemeral storage, long term, short term storage, low vs high availability storage. There is a good chance at least one of them will be more profitable than validating. If it will all that bad DevX of state rent that we were trying to fix will be coming back but in more convoluted way since it will be built on L2, as @abacabadabacaba suggested.

It's should be addressed automatically in the future, but doesn't have to be fixed right now. Basically with S shards in order to permanently deploy a contract of size C bytes, you need to pay S C P, where P is the price per byte for single shard state. You wouldn't need to think which shard it's going because it'll need to be handled automatically though global storage.

This is an assumption that we will be able to come up with a good global storage design. I think it might be an extremely challenging problem to solve because global storage in its nature is the opposite to the sharded state. If we are saying that shard contract will be somehow able to link to contracts deployed on the global storage then it will be the "contract yanking" that we wanted to avoid.

Overall this change will makes computation much simpler than the current rent taking.

This is the main reason why state staking is appealing to me -- the design is simpler from the perspective of the runtime spec, and if the cost was not so high that we needed to have workarounds the DevX would've been better than the state rent DevX. Alas, the cost is high and we are coming up with multiple complex workarounds that take a toll on our DevX.

---

Also, on a different but relevant note. @evgenykuzyakov , it seems like you proposing an alteration to the state staking design, where the tokens would need to be permanently burnt to buy storage. How will people resell the storage they don't need anymore? Also, how are going to avoid state fragmentation?

[janedegtiareva]

as a dev deploying contract, I want to have meaningful messaging if there is insufficient balance

With fixed rate of byte per $N, we'll be able to easily compute it on the front-end or through RPC.

available_storage = int(account.balance * rate) - account.storage_used

as a dev, I want to see how much of my balance is inaccessible because it's been staked

locked_balance_for_storage = int(account.storage_used / rate)

a ton of documentation explaining this pricing model.

We'll have to update documentation to update rent towards fixed rate.

Are we 100% sure the rate is not going to change? I think it would be better if this info came from the node and tools just displayed it.

[evgenykuzyakov]

I think App layer doesn't need to a lot of changes, so long as we increase the default balance from 10$N to 100$N for developers.

We'll have to remove all AppLayer logic related to rent. And make separate error type when you don't have enough storage stake/balance to complete an action.

10N per standard contract is too much

Why is it too much?

With 1B total supply on 1 shard. At 10$N you have 100M contracts.

With better contracts design (no JSON, no std) you decrease contract size to 20Kb, which is about 5X reduction.

By adding more shards, you scale storage linearly as well, so with 8 shards. You need 8 times less $N for the same amount of storage.

Also, on a different but relevant note. @evgenykuzyakov , it seems like you proposing an alteration to the state staking design, where the tokens would need to be permanently burnt to buy storage.

This is only for shared contracts and it needs a NEP for itself.

[bowenwang1996]

Actually how is 10TB determined? Why couldn't it be 100TB for example? It seems much better if we have 1N for 100kb so that most contract will only cost around 1N to deploy.

[DanielRX]

To add to the existing discussion, how would "deleting" old state work in both models? With rent, since it's per block, you just get charged less over time. With staking, you can "reduce" your stake in this case? Just wanting to clarify that my assumptions are correct

EDIT: Along this vein, would a "honeymoon" period for staking help at all? Much like "renting a house with the intent to buy it after 5 years". This would allow devs to start deploying without massive upfront lock up. So the first N blocks you must stake Y per byte, and then after N blocks, the stake moves to Z where Z > Y. Preventing usage of the contract until the Z is locked up may be an issue itself however

[ilblackdragon]

@nearmax There are few points:

• Even in Web2 developers need to pay to run applications. Here the model for payment is different, but remember that developers will need to acquire $N either way - that's how they paying fees. Dev tools won't be able to loan them $N or give it to them. They will need to find a way how to convert the money they have (fiat, other crypto, in-game items, etc) into $N themself. Our dev experience for TestNet and MainNet will always be different.
• The application you are deploying to MainNet, should store value (tokens, assets, valuable data). E.g. we are not talking about generic database - blockchain is a database with very specific properties. Adding $N to cover for this to align incentives between validators, developers and other token holders makes a lot of sense.
• To be specific, there is a huge disconnect in economics of blockchains when non-native tokens are involved (same for NFTs, same for valuable data). For example $BAT stored on Ethereum actually doesn't pay for it's security, only $ETH holders do. Making sure we have aligned incentives between validators, developers and token holders is extremely important. Also that we have a way for new tokens to interact with existing eco-system in non-parasitic way.
• We can achieve similar alignment with state rent as well, just need to increase price way up. But here DevX of state rent comes in - just FYI our current App Tooling and even NEAR Core don't actually implement state rent correctly.
• No single place in our UIs / CLIs actually shows correct balance right now !!! FYI @janedegtiareva Because balance should be deducting every block (and if we charge a fair bit, it will be very visible). Explaining that is actually not straightforward to normal users - we actually completely punted on this across all of our UIs.
• Inflation as a mechanics to deduct % while maintaining face denomination is way more preferred.

@abacabadabacaba Yes, state rent can be added on top and that was my original thought as well - why go around if we can directly go state rent. The problem again with state rent is virtual balance. We do have it implemented right now, but we actually completely misrepresent it in our UIs and outputs. It's also unclear that the state rent model we implemented is better vs might be third-party token rent or a loan mechanics. So overall, I would prefer to allow to experiment with that on contract layer.

@bowenwang1996: I used ~1-2% of $NEAR will be used for storage to start with. We were targeting 100GB of actual storage per shard. With 1 shard, it's 100 * 2**30 / 0.01 ~= 10TB of target storage. If more $NEAR is captured in storage, validators have a huge incentive to stock up on more hard drives as it will increase demand on $NEAR.

@janedegtiareva :

• Here are errors: https://github.com/nearprotocol/nearlib/pull/268 they are pretty much the same as for rent.
• Just current rate should be used (taken from config that node serves). Formula's that @evgenykuzyakov wrote apply from there.

@DanielRX Not sure what you mean by deleting old state. You can always delete any account if you have full access key to it, which will remove all data as well attached to it. In case of state rent we also allow to delete accounts which don't have enough rent to cover for next X blocks by anyone.

Btw, Nervos is using similar model - https://docs.nervos.org/basic-concepts/economics-of-ckb.html

[MaksymZavershynskyi]

Even in Web2 developers need to pay to run applications. They will need to find a way how to convert the money they have (fiat, other crypto, in-game items, etc) into $N themself. Our dev experience for TestNet and MainNet will always be different.

There is a huge difference between buying 0.001N and 10N:

• The bounce rate will increase drastically. Even AWS understands that so they give free tier that can be used to run real services. We won't be able to have an analog of free tier;
• It makes our fight with sybil resistance much harder, for example it now becomes very profitable to grind the PoW faucet, because now PoW faucet has to dispense much larger quantities;
• The token distribution becomes more complex. We now have to distribute much larger quantities to the developers, or make their development experience much harder (through proxies) undermining our image of DevX-friendly chain.

The application you are deploying to MainNet, should store value.

The value of the application is not correlated with its state size which makes it a bad surrogate metric. Bad surrogate metrics create perverse incentives, e.g. people hoarding storage, renting and re-renting storage, storage aggregators, etc. It is better to have no incentives than perverse incentives, because perverse incentives make system more complex, e.g. we will be getting complex third-party contracts in our system that try to do various strategies with storage rent.

To be specific, there is a huge disconnect in economics of blockchains when non-native tokens are involved.

We won't be able to make ERC20/721 tokens to pay for the network security anyway, because their value will not correlate with the storage they occupy. So we need to capture the value somehow else, how about we increase the fee for the "hot" contracts, e.g. those that are touched frequently? We might need to have fee depend on the hotness of the contract anyway, e.g. to fight cold-cache attack.

our current App Tooling and even NEAR Core don't actually implement state rent correctly. Explaining that is actually not straightforward to normal users - we actually completely punted on this across all of our UIs.

So we should solve the problem of our tools being buggy rather than change the internals of nearcore. It seems like we agree that people will implement L2 state rent models independently on whether we choose state staking or state rent. Our tooling will have to work with virtual balance and account GC whether it is going to be native or third-party. If our wallet, cli, devtools will not support popular third-party state rent mechanics then someone will for implement tools that will. This problem will not go away with state staking.

It's also unclear that the state rent model we implemented is better vs might be third-party token rent or a loan mechanics. So overall, I would prefer to allow to experiment with that on contract layer.

This is the strongest argument for state staking. Our current state rent is supposed to represent the actual bare-metal cost (S3 or EBS), but since validators will be able to change this fee it won't represent bare-metal anymore, unless we create an incentive for state rent to be close to metal. Any ideas how we can create such incentive? It is unlikely we can implement state rent correctly without seeing the actual active usage of our blockchain, which creates a chicken and egg problem. And even if we do, there are multiple rent models, people will implement these other models on top of our state rent.

---

How about we use hotness of the contract to capture its value, since contract state does not correlate with its value?

If we go with state staking are we going to:

• Throw away our faucets?
• Not have token distribution mechanics?
• Support third-party state rent mechanics in our Applayer?
• What do we do with abandoned accounts, do we store them forever?

[ilblackdragon]

Overall, would love to hear more from folks building on us how they thinking about this. Because state rent DevX is pretty poor and has a lot of negative effects.

Also, I do think economics is still interesting with state rent if we set price for rent to be somewhere around 7e-12 $N/block/byte, e.g. 0.0006 N per KB per day or 0.22 N per KB per year. It can go down over time as there are more usage.

We still would have an issue that there are no alignment between native token and third-party tokens. See the issue described - https://gist.github.com/ilblackdragon/21e8a5cfe0fff5bb1b2272e4d626344c

There is a huge difference between buying 0.001N and 10N

Obviously depends on the price. E.g. at lower prices $0.001 and $10 is not that different (it's actually very hard to buy fractions of cents).

The bounce rate will increase drastically. Even AWS understands that so they give free tier that can be used to run real services. We won't be able to have an analog of free tier;

We do have "free tier" with TestNet. MainNet is by definition paid to prevent sybil or ppl can apply for various developer programs that different network participants should run.

It makes our fight with sybil resistance much harder, for example it now becomes very profitable to grind the PoW faucet, because now PoW faucet has to dispense much larger quantities;

Yeah, I'm actually not convinced that PoW faucet make sense either way. It's not really Sybil resistant in the current state. To make it reasonable, it needs to be a VDF, and amount of NEAR should be lower than cost of renting EC2 instance for the same time. E.g. for 1 minute of VDF we should dispense less than $0.0007 in NEAR. Currently VDFs for 1 minute will be super expensive to verify on-chain. So we will need SNARK or STARK for it. @evgenykuzyakov

The token distribution becomes more complex. We now have to distribute much larger quantities to the developers, or make their development experience much harder (through proxies) undermining our image of DevX-friendly chain.

Not sure we need much larger amounts vs what were planning to. For developers 10-100N is not even that small. For example, Handshake dropped 4300 HSK to each developer ($0.1 VC round, $0.15-$0.3 on market).

Actually as side note, most of our contracts are proxies at the start (due to lock ups), so we already should be figuring out our UserX and DevX around that @kcole16 @potatodepaulo Probably would be good to create some design patterns and NEPs.

The value of the application is not correlated with its state size which makes it a bad surrogate metric.

Agree. Sadly there is no way to directly tax the value, which we kind of need to do. Also checkout https://gist.github.com/ilblackdragon/21e8a5cfe0fff5bb1b2272e4d626344c for current problems with Ethereum.

The indirect way is actually to require the application to launch their own token and allow them to pay some with inflation of that token to the token holders for security. The state staking model actually provides the way to do it.

people hoarding storage, renting and re-renting storage, storage aggregators, etc.

Storage is not a separate thing, so really you just talking about lending and borrowing $NEAR tokens, Compound-like applications (lending aggregator), and HODLing $NEAR (which obviously means that they will delegate it because that's just pure return with possibly no risk given validators that provide riskless delegation).

It is better to have no incentives than perverse incentives

Not clear why these incentives are perverse, where they align better token holders and validators vs developers incentives. Which current model doesn't really provide.

e.g. we will be getting complex third-party contracts in our system that try to do various strategies with storage rent.

Again, there is no storage rent, there is only borrowing $NEAR or buying $NEAR for your own third-party tokens (e.g. similar to initial coin offering but actually aligning around utility).

how about we increase the fee for the "hot" contracts

Seems like we should be decreasing price for "hot" contracts - they are both in cache vs "cold" contracts need to be loaded / re-compiled. Also you want to incentivize more usage on contracts, not less. Otherwise L2 solutions will become more preferred. But overall, this sounds complicated from implementation (even just computing "hotness" of contract is complicated) and from explaining to ppl.

We won't be able to make ERC20/721 tokens to pay for the network security anyway, because their value will not correlate with the storage they occupy

Yep, unclear how to do this outside of expecting ppl to issue their app token (for example where as NFTs are exchanged, the contract buys and burns it to capture value) and using it as a taxation mechanics in exchange for lent $NEAR.

So we should solve the problem of our tools being buggy rather than change the internals of nearcore.

Internals are wrong too :)

Our tooling will have to work with virtual balance and account GC whether it is going to be native or third-party.

Not really, it's just borrowing/lending, you don't need any tooling on top of what the apps themself will provide or virtual balances.

but since validators will be able to change this fee it won't represent bare-metal anymore

Validators, even though can change whatever, really need a coordination to do this - e.g. a reason.

Throw away our faucets?

Our faucets always were just a temporary to distribute some initial tokens. We can still use the ones that make sense - like we were planning to fund Beta program users to create accounts.

Not have token distribution mechanics?

We still distribute tokens to the parties that we want to engage. Like developers and initial set of users via wallets.

Support third-party state rent mechanics in our Applayer?

No support needed as far as I see - I'm open to be convince otherwise.

What do we do with abandoned accounts, do we store them forever?

They paying for themself, so yes. It's really hard to distinguish between account that is abandoned and account that is inheritance for next generation and will be uncovered in 100 years.

I want to reiterate - here is how I steal all your money, NFTs and tokens with state rent:

• You land on a page that suggest you send your tokens to a Compound-like app.
• The Compound app is totally great, valid, security audited and you can check with you peers that ppl have been using it.
• The page suggests you send your funds there to make sweet returns
• You sign transaction with your wallet and observe how your $NEAR holdings increase inside that app

What happened, is that you just sent all your funds and didn't keep any $NEAR for covering rent. Now I'm deleting your account, recreate with the same name and... asking Compound to return funds for this account. Just got all $NEAR and everything else this account owns.

We can fix this problem as well - through blocking account recreation for 6 month for example by keeping account_id and keys around or hybernation of the state via state_root for given account and then allowing people to restore it. Requires fixes to nearcore and pretty invasive change to state storage.

[bowenwang1996]

We can fix this problem as well - through blocking account recreation for 6 month for example by keeping account_id and keys around or hybernation of the state via state_root for given account and then allowing people to restore it. Requires fixes to nearcore and pretty invasive change to state storage.

Does that actually fix the problem? If I were a regular user I would be happy to see my tokens accruing interest and just leave it in the app. Then an attacker can for wait for the required amount of time and then execute the attack.

[ilblackdragon]

@eriktrautman suggests to think next way:

NEAR MainNet is bare metal AWS.

One can build a centralized Heroku solution. Where developers come in, sign up with credit card and deploy their apps. This solution deploy apps on developers behalf, lends them NEAR, allows to manage apps, etc.

If developers want to move out from this centralized solution for whatever reason - they can. Just need to buy or borrow these tokens.

[ilblackdragon]

Somewhat off-topic here, but want to mention for @potatodepaulo and @amgando. Also @k06a and @kcole16 can correct me based on Ethereum experience.

Generally, here how I would expect the process of development to happen:

1. Developer prototypes some things on TestNet, easily deploys their app there using faucet for testnet tokens.

Developer can get some initial testing of the product done, but there are no financial operations there.

There is also a split between types of applications:

• Apps that require users to input money first, like DEXs, prediction markets and others. These apps will have a way less usage on TestNet.
• Apps that are more to store various data for user, including games and social stuff. They can test pretty well on TestNet, as they don't have a large drop off. These apps probably also will not require users to have their own accounts even on MainNet until later.

2. When time comes to deploy to MaInNet, there are few things that usually required from a serious app, developer needs to decide on the governance of your application. Note that application can go from one model to anther (from centralized and upgradable to DAO / non-upgradable):

   • Are you going to maintain it in centralized way (hence the Heroku-type solution described above works really well).
   • Right now this is kind of our default way. But this doesn't match any financial applications, because otherwise whoever maintains can steal all the funds from the contract.
   • You are planning to have a DAO or some other governance model. Here you need to issue your own token, create this DAO or find existing DAO (my ideas for Governance as a Service). E.g. Maker, 0x model.
   • Going forward we will need a lot of information how to actually approach this. E.g. how to issue tokens, what are different ways to maintain upgradability via a DAO, etc.
   • I need to write more about this, but the idea with GaaS is to allow for new apps to get some professional DAO governance participation. This is where borrowing NEAR comes in nicely - new app issues a token, and allocation portion to GaaS, which in terns lends NEAR to cover for storage rent.
   • There won't be any updates, this is the final version. E.g. deploy without access key. May be not day 1 but you will remove this keys before users actually will be using this contracts. This is true for apps like Uniswap.
   • In this case you really want to make sure your app is bullet proof, need security review and other steps. At this point also acquiring some amount of $NEAR to power this app is not as meaningful.
   • There will be no "pay for users" in this model - it will be user-paid apps.
   • Need to think a bit about this mode, when we have contracts that might have funds locked but become useless due to issues / errors. This also might be worse considering in the context of GaaS, where these non-upgradable apps are still managed by GaaS.

[MaksymZavershynskyi]

Pasting my comment from Slack:

• I disagree that new markets is a good idea. From the very beginning our strategy was — if we see some good L2 solution that everyone is using then we implement it in L1. We did this with account names, we did this with cross-contract calls (as oppose to simple message passing in other sharded blockchains), but extracting state rent from L1 into L2 goes in completely opposite direction.
• I also disagree that state staking makes our UX better. It only makes it better in short term, soon we will have lots of L2 state renting solution that every Applayer component will have to support and it will be worse DevX because these will be third-party state rent solutions.

However, I agree that it is unlikely we can implement state rent correctly, since we don’t know the market yet and what will be the preferred state rent model. Therefore I agree we launch state staking.

[MaksymZavershynskyi]

@ilblackdragon @evgenykuzyakov I suppose it also means we are moving account names to account name staking too, since we don’t want to have virtual balance and other disadvantages of renting? The problem with account names staking is that we cannot guarantee that the price will only go down. In fact, it is more likely to go up, because we expect the popularity of the network to increase which will make short account names more scarce and therefore valuable. Unfortunately, our state/account staking relying pretty heavily on the assumption that the cost will only go down, because otherwise accounts are going to be wiped out.

[SkidanovAlex]

One more thing to consider is that state staking is not much different from just paying for stake.

I.e. if we require 1Ⓝ per 10Kb, we can just make one pay 1Ⓝ for that storage, and if they free it up, give them that 1Ⓝ back. This is simpler because a) all the balance on the account can be used, improving the UX and b) the logic on our end is way easier because we don't need to care at all about the balance -- fewer possible error conditions, less logic.

[evgenykuzyakov]

One more thing to consider is that state staking is not much different from just paying for stake. I.e. if we require 1Ⓝ per 10Kb, we can just make one pay 1Ⓝ for that storage, and if they free it up, give them that 1Ⓝ back. This is simpler because a) all the balance on the account can be used, improving the UX and b) the logic on our end is way easier because we don't need to care at all about the balance -- fewer possible error conditions, less logic.

When you return the storage, at what price should you get money back? It only works for fixed rate forever

[ilblackdragon]

For @SkidanovAlex idea of pay for storage upfront with burn and receive it back later when freed up, here are issues:

• If price for storage changes (which we expect it to go down, as we increase number of shards, hardware getting cheaper) - ppl will loose their money.
• given our model, as a user or developer of UI you will need to predict how much storage will your transaction take across all of the contracts you are touching. It is similar to gas in this sense, but now adds another complicated parameter to estimate. (this is because we need to deduct from your account and then carry that balance across shards)
• If I paid for storage of data in contract X, and then contract X feed that storage for whatever reason - who should receive the freed money?
• This change will be pretty dramatic - changing transaction format, receipts to keep track how much storage is attached, and a ton of side effects (like CreateAccount() action right now doesn’t require balance attached, but now we will need to add that and more)

[ilblackdragon]

@evgenykuzyakov :

we can bootstrap the price initially, basically provide more storage for a single shard. E.g. we provide 10tb originally for one shard. It's maybe a lot for one shard, but it's not going to be fully used until we switch to multiple shards. Let's say our target is 2tb per shard, then we can keep stake rate the same when we shard the chain until we get at least 5 shards

@nearmax :

• I disagree that new markets is a good idea. From the very beginning our strategy was — if we see some good L2 solution that everyone is using then we implement it in L1. We did this with account names, we did this with cross-contract calls (as oppose to simple message passing in other sharded blockchains), but extracting state rent from L1 into L2 goes in completely opposite direction.
• I also disagree that state staking makes our UX better. It only makes it better in short term, soon we will have lots of L2 state renting solutions that every Applayer component will have to support and it will be worse DevX because these will be third-party state rent solutions.

However, I agree that it is unlikely we can implement state rent correctly in L1, since we don’t know the market yet and what will be the preferred state rent model. Therefore I agree we launch state staking.

I suppose it also means we are moving account names to account name staking too, since we don’t want to have virtual balance and other disadvantages of renting? The problem with account names staking is that we cannot guarantee that the price will only go down. In fact, it is more likely to go up, because we expect the popularity of the network to increase which will make short account names more scarce and therefore valuable. Unfortunately, our state/account staking relying pretty heavily on the assumption that the cost will only go down, because otherwise accounts are going to be wiped out.

me:

We can’t increase price ever for anything - even if it’s stake rent for account names. Yes, for account names - we are going to have an auction to offer them. We can’t increase price for holding it over time.

@nearmax

Then we cannot proceed, because there is no chance we can guess the correct pricing for account names or the correct price formula for the account names, before we actually have a real market.

It is very likely we will underprice account name holding so there will be squatting which will undermine the account name scheme entirely. We should prohibit creation of account names shorter than say 20 characters and maybe dispense short account names through some authority contract if we really need (no auction, because people will squat account names through auction). Once we have a real market for long enough we can introduce a decentralized contract for dispensing short account names based on whatever rule we choose in the future.

me:

squatting account names is not really bad - because it creates an additional market where people who are squatting also going to be doing marketing for us to actually attract interest for people to value and buy them. I do agree that our naming cost is going to be off - and I actually would even vote for removing it at this point. Having a fair auction with slow release of names (hash(name) % 52 weeks for example) that will enable people to bid on names and gain adoption of time would allow to achieve main goal of marketing this IMO

see https://github.com/nearprotocol/NEPs/pull/45/files for placeholder to intergrate auction for TLAs.

@evgenykuzyakov

I think we can increase Account Stake Rate, but it doesn’t solve the squating problem. It only solves that the active short names have to keep enough balance. Basically if your account has less balance than needed, then you can issue any transaction from it

@nearmax

I would remove Account Naming Stake entirely, there is no chance we can guess even the ballpark of the pricing correctly, so it is not much better than having a random formula/number there.

squatting account names is not really bad - because it creates an additional market where people who are squatting also going to be doing marketing for us to actually attract interest for people to value and buy them.

When we say that something creates an additional market another way to see it is us moving one of the L1 features into L2 and delegating this problem to the ecosystem developers, which goes against our DevX strategy. By the same argument we should remove everything from the runtime and become Cosmos.

@bowenwang1996

I think it might be better for the purpose of upgradability to keep account name staking. It is easier to upgrade config than to upgrade code.

@nearmax

We are using formula there, we would have to upgrade the code to change the formula. Also, we won’t be able to increase the cost in the config because it will nuke the accounts and so having this value in the config does not solve the entire problem.

me:

Basically if your account has less balance than needed, then you can issue any transaction from it

If your account has less balance than needed - anyone can delete it.

I would remove Account Naming Stake entirely

Agree

When we say that something creates an additional market another way to see it is us moving one of the L1 features into L2 and delegating this problem to the ecosystem developers

Not sure I understand your point here. Markets are the main use case for blockchain. The more markets are built on top of our blockchain the better.

we should remove everything from the runtime

Ideally we would have our runtime as smart contract. This way we could keep extending and trying new things easier.