Replace PoW with useless tokens

Protocol Design
#1

[Note: I have modified / improved the suggestion in subsequent comments, scroll down to see my later ideas]

PoW is useless and wastes energy. Let's replace it with useless tokens.

This is not a joke.

You want Nano to be feeless at any cost. Alright, got it.

You want users at countries where 1 cent is not considered disposable change to be able to use the service without worrying about fees. Got it.

Many of these users only have mobile phones (and probably not very fast ones) that wouldn't be able to compute PoW. So your solution is to compute it and gift it to them (I'll ignore for now that this kind of service is highly susceptible to abuse).

So instead of donating useless computing power and electricity (which costs money and causes carbon emissions), why not donate useless tokens instead?

Design tokens that can't be used for anything other than as a burnable "gas" for performing a transaction. One token = one transaction.

Now you might think: Everything has value. These tokens would be traded eventually.

I'm not a finance person (more of a computer science person), but I don't think anything is impossible. Let's try to shift the effort for a minute from things like memory hard PoW and precomputed attacks to considering the idea of a token that is useless by definition - the only thing that it can do is be burned to perform a transaction.

This should be the worst possible token for investors: infinite supply, arbitrary price decided by software, not tradable anywhere, could lose its entire value at any second. As useless as tokens in a theme park that's in the process of filing for bankruptcy.

This shouldn't be that hard?

Here are some ideas: the token will be materialized by burning a small amount of Nanos to some predefined bogus account. The token will have versions like v1, v2, v3 etc. that would increment with software upgrades. Once the version is upgraded, all the tokens of versions one before the current one would become completely useless (for example upgrade form v2 -> v3 causes v1 to become useless). Tokens cannot be traded between versions. This means the tokens would have to be bought only for short-term use.

I haven't spent a lot of time in considering the specifics of this kind of idea, but I think people with different backgrounds than mine (like finance and economics) could easily come up with even better solutions. As a technical person I understand the development cost of implementing a secondary "balance" (albeit it would only be a simple integer, 4 bytes suffice) but I want to put that aside for now because I believe the effort would certainly be worth it if it proves to be effective.

#2

Isn't this equivalent to fees or proof of burn?

#3

It is close, but not exactly. The idea is to try to somehow design a token "embodies" the same qualities as PoW and can be gifted between accounts.

It can only be used for one purpose (gas for a transaction), maybe even only for the particular account that it is issued for (so it is not possible to sell it at all).

I guess the primary pattern would be that it would be gifted from a service similar to the current distributed PoW service. But instead of donating computing power, volunteers would donate funds that would be be burned in exchange for tokens that can only be used by a particular account for a limited amount of time.

Now it may seem expensive to "burn" money, but the amounts would be so little and possible comparable to how much it currently costs to pay for the PoW electricity.

Something along that lines. I'm still pretty vague about this. I'll need to consider this more.

#4

Alright, maybe something like this:

User A wants to buy some Gas tokens for user B.

User A issues a "send" transaction to user B but instead of sending Nanos they set a Boolean value in the block that causes the funds to convert to Gas tokens instead.

User B accepts the transaction and their Gas token balance is now increased (no change to their main balance).

(and if user C wants to buy Gas tokens for themselves they send a similar transaction, but to themselves)

Something like that.

#5

I'll try to rephrase the concept in a clearer manner:

  • Gas tokens are tokens that are designed such that they will always be "free" - meaning that honest users would never be required to purchase them themselves and will always be able to get them at no cost from a fountain (maintained by donors who are incentivized to contribute these funds to increase the value and user base of the currency).

  • Gas tokens cannot be transferred between accounts. They can only be bought (either by the account owner or by a secondary account). New accounts require Gas tokens to be bought for them using real money (I've demonstrated an implementation approach for that in the previous comment).

  • The maximum amount of Gas tokens may be limited for each account (they can't be hoarded).

  • The price of Gas tokens can be literally changed by randomness! and can also vary by parameters like stake, account history, transaction rate of the account, overall network congestion etc.

  • Gas tokens can vanish without any warning! Literally by random chance!

The idea is to design these tokens to be so terrible to buy and hold so that individual users would not be incentivized to purchase them. However, because of those same "broken" properties they can be made so cheap that fountains wouldn't require a fortune to be maintained. The only ones who would be incentivized to buy such a broken asset would be the donors who understand that these same broken qualities guarantee the integrity of the network as a whole as well as maintaining the low price.

It is still possible that attackers would be willing to buy them despite all of these "guards".

The question is, how low can we go? what would be the cheapest price that can still deter attackers?

  • 1 cent per token means 100$ per 10,000 spam transactions (not a serious attack)
  • 0.1 cent per token means 100$ per 100,000 spam transactions (more serious attack)
  • 0.01 cent per token means 100$ per 1,000,000 spam transactions (quite serious attack)
  • etc.

(of course the token can become several times more expensive for accounts with a history of high-transaction counts, low stake etc. I'm giving these numbers as rough baselines to consider)

Another way to analyze this is to look at other networks with super-cheap transaction fees and see how many attacks they actually get (assuming they have an active userbase).

#6

There is delegated PoW. We implemented Nano in the Kaiak wallet for KaiOS. You can consider these phones to be low end. It works fine and is as fast as an Android or iOS wallet. So, I don't see the problem here.

1 Like
#7

Iteration 3: prepaid token contracts

I've spent many hours working on this and I think I'm making some progress:

The previous approach had the price of each token being determined at the time they are bought. The problem with this is that attackers could still manage to take advantage of this by buying the tokens very cheaply, right before the price rises due to the attack.

The obvious solution would be to have transactions consume variable amount of tokens (including fractional amounts) that are determined at the time of the transaction, but I think I have a better idea that will also be very useful for the fountains:

Instead of buying tokens at the current token price, the fountains will issue a contract where they pay x amount of Nanos for each of the n tokens that are issued.

For example, the fountain will issue a contract where they provide credit for 5 tokens at a maximum price of 0.1 cents each (or equivalent Nanos). The contract doesn't expire, but will have a minimum token count (5 seems like a reasonable number) to prevent the network wasting resources at unnecessary "buy tokens" transactions.

The client will accept this contract, but will only be able to make use of it if the token price is below 0.1 cent.

If the network is congested, they will have to either wait until it clears or load another contract instead (for simplicity, there can only be one gas token contract at a time). The tokens that are thrown away are not refunded (it is technically possible to trace back and refund to the original issuer but it would take too many resources, and would require spending tokens by itself).

This may seem like a waste but the fountains can be abused in many other ways. Also, the fountain can look at the account's ledger and decide to ban it from receiving further tokens.

Now attackers who want to flood the network would have to "guess" the future token price before they start the attack. Most likely this would be a very effective measure so attacks will be reduced considerably (and thus the token price can remain very low).

#8

This sounds like fees with a lot of extra steps.

6 Likes
#9

These are technically not fees since they are not payed to anyone. There are not much extra steps. It may only seem like it since I've developed it quite a bit (at least 20 hours of work were put to this). The "contract" I describe is only 5-6 bytes added to the block (current balance of tokens [1-2 bytes] and price of each token [4 bytes]).

It is derived from the idea of proof-of-burn, but builds a more sophisticated scheme on top of it that is potentially very effective against attacks, as well as designed to drive the token price to a very low value.

The tokens represent burning of a Nanos, however they allow the burning to be also performed by a secondary account. This allows the tokens to be fully subsidized by an external entity like a fountain (the design goal is that virtually everyone will use the fountain to obtain tokens - thus the tokens would be effectively free).

The base price of the token is zero. The price only rises if the network activity crosses some threshold (as well as individual aspects relating to the particular account). Every transaction requires spending a token (including buying tokens). The price of the token is determined by an algorithm. The user has to buy the token for at least the current price to perform a transaction. Tokens bought at lower price cause the transaction to be rejected. Tokens bought at higher price do not give any advantage (there is no prioritization based on the price paid - this is deliberate to drive the price down).

Users, as well as the fountains, have to pre-pay for at least 5 tokens at a set price. This is a very deliberate design that is meant to reduce network processing and as well as to drive the price down. Because users have to buy the tokens beforehand, in bulk, they are more likely to wait for the price to go down than buy another whole set, and waste the remaining tokens they bought, in case the price goes above it. The same is true for wasting tokens provided by a fountain (which may cause the user to be banned).

The fountain will buy n tokens at a set price (what I describe as a "contract"). If 90% of the users rely on the fountain exclusively, then when the price goes higher than the price the fountain pays, the users will effectively "stand in line", the fountain would be now be regulating the network using this simple measure.

This design is meant to be very strong at preventing attacks. Possibly much stronger than proof-of-work. The requirement to pre-pay for the tokens means that the attacker must "predict" the future price (the price during the attack itself) to carry out an effective concentrated attack. The attacker also has to buy 5 times the amount of tokens they may need for a multi-account attack. These tokens are not refundable.

A more sophisticated attacker may try to use the "buy tokens" transaction itself as the attack vector, but that transaction also requires already having a usable token, or deducting one of the tokens bought. In any case they will need to use some estimate of the future price and a lot of money may be wasted. Also, the, "emergency" price can also be randomized which may make it even harder (even if they manage to predict the average "emergency" price half of their transactions would be rejected).

#10

The point being here: If you introduce some kind of incentive structure or token for payment or whatever, you are going to get some kind of fee. People can sell these kind of tokens or however you want to call them. And that is the problem. PoW is something everyone is able to do. Dynamic PoW isn't perfect, true. That is why we should think about something to support it. But introducing some kind of incentive is a bad idea.

#11

The token is not transferrable between accounts. Cannot be refunded. Cannot be incremented.

Also, maybe "token" wasn't the right word, it acts more like a "point", "credit" or "voucher".

I have made 3 different variants of the idea in this thread. I apologize if it creates confusion. I don't think I have done a good job at summarizing it so far since I developed the idea as I went, throughout multiple comments.

The base reasoning behind this suggestion is that proof-of-work, in sense, acts a lot like an "asset" or some sort of "token". It has various qualities that may be possible to be captured using the concept of proof-of-burn.

Users of the network in countries without access to banking (and very low purchasing power) most likely would also have a very low-cost phone that wouldn't be able to run proof-of-work at a reasonable time (and probably no PC or laptop). Nano's current solution is that they rely on a distributed network of volunteers who donate computing power and "gift" them the PoW solution.

In a sense, that is not that different from a fountain. I'm trying to explore the idea that instead of donating computing power they could donate funds to a fountain, that would be burnt and converted to "tokens" (aka "points" / "credits"). I describe these "tokens" as useless since they cannot be, transferred, sold or refunded.

The goal is to see if it is possible to disincentivise users to pay for them using their own funds, and instead get them exclusively from fountains (with some exceptions for special "emergency" cases). Also I've shown this system can be made more resilient to attacks than PoW (including multi-account attacks).

#12

This is a fee. See the NEO blockchain for reference; they have a GAS token that you accumulate simply by holding NEO, and which acts as your token. It is worthless except for paying for transactions.

Except it isn't. It is worth $11/GAS on coinmarketcap, with a market cap of more than 5% the market cap of NEO. In the end, it is just a more complicated fee.

https://coinmarketcap.com/currencies/gas/

#13

I incidentally discovered the NEO blockchain yesterday and read about its fee system as well. Although superficially the concept may seem roughly similar this is not intended to be a anything like NEO's GAS.

I'm not sure how you got to that conclusion (given you read my last 3 or so comments). I also personally don't think it is healthy for a community to become so negatively opinionated about some concept (here the word "fee") to the point it turns to a taboo or "bad word". Same for other concepts like proof-of-burn, proof-of-authority, proof-of-autonomy etc. Great projects are usually open to investigate (at least hypothesize) about making the best of all sorts of ideas. A lot of the time successful "out of the box" innovation comes from things that initially looked unwanted or even unthinkable.

The system I describe is not actually a system of tokens (initially it did start that way but later it evolved into something quite different). It is a system of burn credits that are generated by burning Nanos, and are generated exclusively for an individual account, either by account owner or by a secondary account. These credits are not generated by the network (though I have considered that as well and I think it is an interesting future direction to investigate).

The burn credits are intended act as "fines" for users who want to "bypass the line" to get better service in times of congestion (otherwise they are not needed).

  • If the network is not congested, users can get great service with a burn credit of 0$, as good as anyone else, even with higher burn credits (in that case they probably wouldn't need to acquire any credits at all).

  • When the network becomes congested enough, users will need to provide a higher burn credit to get reasonable service, or they'll have to wait until it goes down.

  • The burn amount isn't used for prioritization. It's a threshold. If the credit is under the threshold. The transaction is rejected. If above, it is accepted. Higher-than-minimum burn value doesn't provide better service. This is actually more similar to the system of variable PoW difficulty than to conventional fees.

  • As I've mentioned in my previous comment, these credits are not transferrable, not refundable and not incrementable (which makes them very different from conventional "tokens"). They also have to acquired in bulk for network efficiency (this property can also act as a potentially strong measure of protection against attacks, which I detailed in length in previous comments).

I suggested these burn credits can be issued by a fountain / faucet, and for that to be a way for them to be fully subsidized. The way they are issued is using a special transaction where one side (the fountain or any secondary account) creates an outbound transaction with Nanos and marks them to be only be pullable as credits. The receiver then fulfills them as credits by the count and value they were issued for.

I understand this thread can become long and confusing read for some people, since it shows the concept evolving over multiple iterations and with different terminology.

If there's enough interest I can open a new issue and present this concept with more precise terminology and wording.

I don't want to "spam" the forum with multiple threads. Would you recommend that to be a good idea?

#15

Hi Rotemdan, I've been reading this thread, I think it's an interesting concept and I definitely agree that everything should be considered (I assumed the team is very busy with more pressing issues). I'd like to ask a couple of questions:
What are the precise steps that I would need to go through to get these burn 'tokens'.
Do I need an additional wallet, do I need to visit a burn faucet everytime I want to make a transaction?
If the tokens are arbitrarily cheap, what is to stop me from just getting high value ones, thus bypassing the whole proof of work prioritisation (if I were a spammer).
If the tokens are free, what is to stop a spamer (ie. how does this replace PoW?)
How much nano are you envisioning being burnt etc?

I'm not going to lie, this does sound like fees to me but with the capability to donate them.
The "Nano 2.0" proposal also makes PoW obsolete anyway. I think that proposal has a lot of merit.

#16

Some background:

I had several previous original suggestions about improving several aspects of proof-of-work (something I'm generally very interested in!). In particular about encryption based hashes, and timestamp-free proof-of-recency (a trustless approach for dealing with precomputed attacks). I spent a large amount of time on that.

At some point I felt I've reached some sort of a dead end and decided to take a turn, go "out of the box" and explore what can be done using currency instead. This thread actually started as a half-joke. The title was written in a way that was intentionally silly so people wouldn't take it too seriously. I was not initially sure it would turn out to be something valuable or interesting but I had some sort of a hunch.

After about 50 cumulative hours of thinking about this, I came to an interesting direction that I'm not sure has been explored by other projects. I understand that Nano has the "Feeless" mantra which they effectively committed themselves to after dozens of interviews and public appearances. That's okay with me, although I repeat that this is not technically a system of fees! (Anyway this could be useful for other projects. I could maybe suggest it to the xDai project).

The idea is actually inspired by proof of work! In its core it is very similar to how variable proof of work difficulty works. You could take the same mechanism and apply it back to PoW and instead of "tokens" or "credits" use "proofs". It is just that units of currency are much easier to scale (and greener) than computations, so I chose to use them.

Also remember PoW costs money to operate (electricity and equipment). Those same funds could be used directly for the same purpose (xDai developers believe users could afford 100s of transactions for 1 cent - which is not very far from PoW operational costs - though they haven't really proved that it works in practice since the network hasn't really become popular yet).

I'll start with describing it using proofs of work (though probably a strange approach otherwise), since it seems like the "LOOKS LIKE FEES with SUGAR on ToP!" FUD seems to cause users of this forum to get a brain-freeze and stop being open and imaginative about things.

The way proof-of-work currently works is that there's some difficulty level that's required. This difficulty level can change based on network congestion and other aspects (could also be individual for the particular account).

Now imagine you'd enhance the standard PoW with a system like this:

  • Allow anyone to compute PoW to as many digits as they want.

  • Require at least 5 proofs to be precomputed ahead of time (they have to be computed in bulk) and have special transaction where they are submitted to their ledger such that a separate credit "balance" is incremented, one for each proof (the credits includes the difficulty of the proofs as well, difficulty has to be equal for all proofs - this all takes no more than 5-6 bytes in each block).

  • Design an algorithm that determines the instantaneous required difficulty based on network conditions (each node computes it independently with potentially a sub-millisecond resolution).

  • Instead of using difficulty for prioritization, entirely reject proofs with difficulty lower than the current threshold and accept ones equal to or above (no special advantage for higher difficulty).

  • And what if the difficulty of the proof that is sent is somewhere at the boundary? (where some nodes may accept it and some don't?) It will propagate through the nodes that accept it. If the propagation stops at some point, it is thrown away. Otherwise it will get to be voted on (and the ordinary voting rules apply). (To make the voting work - nodes would also propagate blocks with proofs whose difficulty is slightly below their own threshold - some negative variance would be accepted)

Now what is happening is that during an attack, difficulty rises exponentially. This system causes attackers to have predict the future difficulty before they start the attack. Otherwise most of their requests will be rejected and they've wasted a lot of resources for nothing.

"Normal" users have the advantage that they don't plan on sending tens of thousands of blocks, only a few, so they can choose a difficulty level that would give them a level of service that's sufficient when there is no ongoing attack (if there is an attack they'll have to wait).

The idea is that this system will reach an equilibrium such that there's going to be some measure of difficulty that'd would give good service overall to honest users as well as serve as a good deterrent for attackers. This difficulty level would also be estimated by the distributed proof of work service so that it can ensure good service for its users.

Users who have special "emergency" transactions and want to get immediate service (without waiting for the difficulty to go down) can "cut in line" and compute PoW with higher difficulty than what is provided by the free service.

You may say that the attackers would simply take advantage of this and intentionally cause the overall difficulty to become higher by sending spam blocks only when the network is not congested. This "slow" attack will not cause the network to freeze but just make everything unnecessarily more "expensive". This problem actually exists on all popular networks, including ones using fees. (For example it has been claimed that Binance is partially responsible for making the Ethereum fees go sky high by "abusing" Ethereum with large amounts of transactions - possibly to promote their own centralized smart chain as an alternative). There are various approaches to mitigate this (for example giving "discounts" based on stake, etc.)

Now so far I've talked only about proofs of work. You may ask if it is even reasonable that proofs of work would become so difficult at times, or that users' PCs (mobiles are mostly out of the picture here) would be required to many minutes or even hours just for sending one transaction?

Of course it is not realistic. That's probably why nobody ever suggested it. However if you replace "PoW" with "Burned currency" and "Distributed PoW" with "Faucet" it starts to make more sense.

Other interesting analogies?

  • With PoW we keep talking about the threat "specialized hardware" like ASICs and GPUs. In currency? the "ASICs" are those people from countries with high-purchasing power the "Mobiles" are people from poorer countries. This discrepancy is actually much better! If several cents are not a lot of money for you? donate them to have less fortunate users be able to use the service. No need to invest in specialized hardware, or even for a PC or an internet connection. Zero emissions as well.

I could go on to give more details about the exact way this could be implemented: I mean exactly how the credit transactions would work and specific fields in the block would be set. How the algorithm would determine the difficulty / burn cost on an instantaneous basis. How propagation and consensus would work. How faucets could randomize the burn value to create a "queue". How to deal with surges of requests etc. There is a lot of detail but I don't feel motivated to continue. I don't think anyone here would actually read it or care about it. I've spent an enormous time already on this (this comment itself took several hours of work).