EMVPARTY discussion: Gas cost for contract execution

Development
1

So we published the plan / timeline for the release of the EVM onto Counterparty mainnet earlier this week: http://counterparty.io/news/proposal-for-ethereum-smart-contracts-on-counterparty-mainnet/

There’s a couple of topics that need discussion, the biggest of them being; what should we use for gas

Please keep this topic about this question, I’m creating topics for each subject, so try and keep details about the other subjects in those topics!

Other topics:

Contracts on Ethereum require a payment of gas to execute them, this is a mechanism to put a cost to the complexity of the contract.
The EVM determines while it’s running, per opcode if it has enough gas to continue running, so an infinite loop (while 1 < 2: dosomething;) would eventually run out of gas and exit and the creator/executor of the contract will have paid for the execution.

Ethereum uses it’s native asset, ether (ETH), as gas (and has a dynamic cost on how much ETH to use).
The gas used to create/execute contracts on Ethereum goes to the miners that are running nodes.
Each Ethereum block rewards the miners for the execution and has a base reward to bring more ETH into circulation and to circulate used ETH.

When the EVM runs on Counterparty there’s a few significant differences from Ethereum:

  • Counterparty doesn’t have miners, the gas used can’t go to the people running nodes.
  • Counterparty’s current native asset, XCP, doesn’t have any new creation mechanisms, the burning of BTC for XCP has long been disabled and apart from many in the community most likely being opposed to changing one of the fundamental rules of Counterparty (similar to BTC’s 21mil supply cap), many are also opposed to burning BTC (again).

There’s a few options we already came up with:

1. Burn XCP as gas.
the old testnet-only EVM on CP does this

This would slowly decay the total XCP supply, it would require either a (new) mechanism to bring back more XCP into circulation or it would require a dynamicly lowering cost which scales with the XCP supply to avoid never reaching 0 XCP.
From my perspective this would heavily promote hodling XCP instead of using it.

2. Freeze XCP for a X amount of time as gas cost
Freeze XCP for a X amount of time as gas cost, releasing it back to the original owner afterwards, and the cost will be the ‘opportunity cost’ of having your XCP locked.

To me this option sounds like it the cost is high ‘enough’.

3. XCP dividend XCPC
Automatically payout a dividend (for now called XCPC, for lack of a better name) to XCP holders based on how much XCP they hold every X amount of time (eg; having 100 XCP you’d get 100 XCPC every week).
To avoid the supply of XCPC ramping up quickly while there’s not many contracts yet this should have a cap (eg; max 1x or 2x the amount you get every X amount of time).

This sort of resembles a PoS coin with minting.

For all options there’s also the question; how does it affect the current usage of XCP for named asset issuance, though I think once a solution is chosen for the gas that the problem with issuance isn’t that hard to deal with for any of the options.

I’d like to stress that this isn’t my area of expertise, I’m a code monkey, not an economic! I hope others in the community can be more helpful in this discussion!

2

Here something what I think:

I think this is good in long term because it will give value for hold XCP if supply go down all the time really slowly. Also when registered asset amount grow unique asset name registering coming more expensive if that stay in same 0.50 XCP. So if you want unique asset name years later you will pay it more. Because XCP have burned already I don’t like idea it can do again. Also sub assets register can stay cheaper or even come cheaper IF there is example 0.25 XCP fee for register subasset what go down after time or so.

This I like also when there start coming much contracts what are running all the time there need to buy XCP from markets. But if we think situation where we have really much contracts running all the time that can make running new contracts really expensive when too much coins are sametime locked.

This I don’t like much. Then only what you can do with XCP is register assets.

3

The freeze option seems to be the most novel route. I don’t know of any staking systems that have complimented the underlying “coin”, Reddcoin being one I can think of immediately.

4

Burning XCP as gas has been the implied (if not stated) plan for quite a while. Going back on that now would be a significant turn around.

I’m in favor of burning XCP as gas and dynamically decrease the gas cost as XCP supply dwindles.

Is it easy to track the total gas burnt in the last, say, 100 blocks? Maybe gas becomes cheaper if less people are using it.

So, in summary:

  1. Calculate gas based on a percentage of the total supply of XCP.
  2. (Maybe) Make gas even cheaper if the total XCP burnt as gas in the last 100 blocks is low.

Obviously I’m hand-waving over the details here, but I think it is doable. I’m not sure #2 is necessary.

One other thing: IF smart contracts take off, the XCP value will increase even if it isn’t burnt as gas. The reason is that people will need a liquid token to buy things with. XCP is by far the most liquid and trusted token on Counterparty.

(I know, I know you are probably thinking that TOKENLY is the most valuable token, but you are wrong. For now. :slight_smile: )

2 Likes
5

I think XCP should be burned as gas for several reasons:

1 unit of XCP is divisible by 100 million so even though the supply is capped at 2.6 million, you could make the cost of fuel super cheap and never run out. The added deflation would help increase the value of XCP, yet people would still need to spend them to execute contracts and create tokens.

If you make fuel costs cheaper than Ethereum it could give Counterparty a competitive advantage.

Using XCP would create more demand and increase liquidity in the markets. XCP used to be in the top 5 marketcap and fell down to 25. The markets need a boost in trading volume and a bull market will attract new users into the space. Some of these new users will want to build DAPPS on this platform, which is good for Counterparty and Bitcoin.

Creating a new token is another form of inflation and would likely encourage hoarding XCP due to “staking”. Using XCP directly encourages people to use them. Many bitcoins were burned to create XCP so we should maximize this resource to its fullest potential.

6
  1. Burn XCP as gas.

I don’t see a benefit in either of the other options. Those running contracts will need to set a price that others will consider worthwhile supporting - both running the scripts and buying those contracts.

Option 2 and 3 just add a layer of complexity that risks pushing users away for no added benefit.

OP hasn’t really made obvious why 2 and 3 should be considered. Surely the contracts will lock in enough resources to honor their contract… or stop running where the owner hasn’t fuelled the contract well enough… or where what fuel there is doesn’t find a supplier to work that contract.

A clear signal to the wider world that [1. Burn XCP as gas.] is the intention will be consistent with default expectation; consistent with what allusions have been made in the past; and will be a big positive attractor to CounterParty.

1 Like
7

I vote for #1 - Burn XCP as gas.

During the initial months:
Simply hardcode the XCP gas price(s). If it later turns out that running contracts is too expensive (may happen if XCP increases in value) or the load on servers is too high, then the price can be adjusted by either
a) a hardfork, or
b) have a special dev multisig address broadcast the new gas price(s)

Later (when the kill-switch) is removed:
Let the gas price adjust dynamically. If more computational steps are performed on the whole network than a hardcoded threshold, then increase the price. If less than a threshold, decrease the price.

8

hmm…at this point I’m not really in favor with the idea of burning XCP.

I see the potential (considerable) downsides as:

  • It’s an irreversible thing, and that XCP won’t be coming back. Especially if any dynamic cost algo is too liberal (a distinct possibility) we could encounter significant deflation of the supply. On the other hand, hardcoded costs are inflexible and potentially involved to change (e.g. a protocol update to modify the costs can be very disruptive, especially during an initial tuning period, where the costs may be modified a number of times as more data rolls in).
  • A deflating XCP supply could very well encourage hoarding.
  • A deflating XCP supply would put more pressure on the idea of doing a second issue of XCP, or something similar. This is a moral hazard and goes against the social contract we have with everyone who burned XCP.
  • It’s higher risk option than freezing the XCP, and less forgiving. To me, it makes sense to minimize the risk as much as possible, especially at first.

The other option (stake token) is also more forgiving than burning XCP, but adds a good deal more complexity.

Just my two cents…I may change my mind here. :slight_smile:

9

I favor burning XCP as gas.

  • Lowering the money supply is good for investors
  • Dynamically adjust this cost according to use/price/etc is a good idea
  • We do NOT need any new assets
  • Freezing XCP is too confusing and complicated
10

Surely “XCP isn’t coming back” and “deflating XCP supply”, are trying to control what should not be controlled.

The only worry would be if XCP was to run to zero. I don’t see that deflation would hold for very long before seeing a push back against that. The deflation you fear, I wonder, would happen quickly and then stop - so there’s a risk of volatility and perhaps even some pump and dump contract that exploits that but my default is optimistic - I don’t see the benefit in being pessimistic and controlling markets. The whole point of contracts and market for XCP is that demand will match reality.

I’m not sure I understand Option 2 to Freeze XCP, beyond what I would expect contracts would necessarily do to ensure collateral against commitments they make.

Guessing the liability, is a liability… let the risk float free and have the market sort it out. The worst case is the XCP real world price rises and draws attention. XCP surely is fractional enough to absorb that and I would expect is well distributed by now not to be contentious relative to any hoarding - good luck to those who gambled/supported and won the bet.

XCP is a route to drawing in community and perhaps more devs, so the risk of its value rising comes with benefits perhaps?

I’m happy to default to what the devs consider is best as they know the risks and tech better than I do but would suggest there is benefit in making available real capability that is not limited by devs fear of what might go wrong. A testnet won’t get real world use as quickly as it might; I wonder better on mainnet with the obvious unnecessary caveat suggested wherever that’s needed that users of alpha EVM should research the risk and take that risk on as their own - ensuring their contracts are limited and fail safely.

Lastly, I’m still stuck wondering how XCP would go out of control deflationary, in the case that XCP necessarily holds real world value that rewards real resources that action those contracts. So long as the providers of resources are not neglecting their own interests and accepting work at a loss, why would there be a problem?

11

I think I must be not understanding the OP on option 2.

Users want control and visibility of spend and any receipt of reward for work.

Perhaps 2 is just a step towards what I would expect is needed anyway, by way of a rate limiting capability - that is that a user can limit the spend over time on a contract, without that sucking an account dry - from either their mistaking the contract or through some bug in the EVM.

Perhaps then freeze is the wrong term and limiting spend over time, limits risk… and if someone wants to spend more they get round that by setting multiple accounts against the contract but then we see complexity in trying to anticipate use… but that dampens risk, so is it worth it?

12

the freeze option means that any XCP used as gas (not used by the contract to do sends) will be taken out of circulation for X amount of time and you won’t be able to use again until it unlocks again, I agree that it’s also my least favorite option.

about the XCP burning which many seem to be in favor of;
It would naturally require an automatically adjusting gas cost to ensure we don’t deplete the XCP supply (and should probably also affect asset issuance cost).
Robby and mine main concern is that it will heavily promote hoarding XCP instead of using it.

13

Let’s not forget - if we could use Bitcoin (BTC) as fuel we would, for simplicity if nothing else. Indeed that is precisely why XCP was introduced - for the technical reason that the Counterparty Protocol cannot escrow BTC directly. Where BTC cannot be used, XCP should be.

With a liquid market between BTC and XCP, the line between them blurs anyway. It is very likely that solutions will be implemented (e.g. using the DEx or off-chain services) where it looks to the end-user like they funded the contract with BTC anyway.

As such, I think the focus needs to be on how best to devise the model of using XCP as fuel. There are many subtleties to this. True, a naive approach could have detrimental consequences but that is no reason to shy away from the problem by introducing additional needlessly complex solutions.

Aside:

8 decimal places of XCP divisibility (current spec.) will go a long way.

3 Likes
14

Generating a proof-of-stake token rewarded to XCP holders will encourage more hoarding. Users will simply hold XCP just to accumulate the asset token. Using XCP directly will actually give it more utility and encourage its use.

Money was burned to create XCP and it is one of the few tokens/coins that was launched fairly without a pre-mine/ICO. We need to add more utility and value to XCP to attract new participants in this ecosystem.

Since XCP is divisible by 100 million we technically have 262 trillion units to work with. The cost could be set relatively low or dynamic to adjust to the market value.

What XCP needs most right now is a solid bull trend in the markets. Liquidity has been dead over the past year and its marketcap dwindled to 25th place. Innovation is important and so is a healthy market, especially since this is financial tech. The lack of liquidity tells me that people are already hoarding and the instant selling pressure on each price spike tells me there are many bagholders.

Use XCP directly, make it deflationary and make it cheaper than Ether to run DAPPS and there will be a whole new demand placed on the markets. XCP has the potential to be a real competitor to Ethereum because it leverages Bitcoin’s blockchain.

If we stimulate the markets then new entrepreneurs, start-ups, investors, traders, users and developers will be attracted into the space.

1 Like
15

There are several good arguments in this thread for burning XCP as gas.

If we go down this route, I would think we would adopt the same gas fees schedule as what ethereum uses: http://ether.fund/tool/gas-fees – this is how much specific EVM instructions consume, in gas

The other factor is the gas price, which is how much each unit of gas costs in XCP. here is ethereum’s: http://ether.fund/tool/gas-price

So it seems the main question is how gas price is determined: statically or dynamically, and if dynamically, what is the approach used?

With Ethereum, the gas price costs are effectively dynamic, as they are set by individual miners, as the minimum price they would include contracts in a block for. See https://www.reddit.com/r/ethereum/comments/494sug/high_gas_price_is_killing_ethereum_projects/d0q0p28

As our model is not the same as ethereum’s because with CP we don’t have miners, and CP nodes effectively have no individual level of choice on whether they perform a contract execution or not – if the contract execution request passes some deterministic, network-wide criteria, then all network nodes must perform the execution in order to maintain ledger consensus.

Given that, there are some options for a dynamic minimum gasprice model:

  • Have it set by POS vote, or dev vote
  • Have it set by the protocol on a specific time interval, based on certain parameters…options include: amount of XCP currently in existance, amount of EVM computation over last X period of time, block height, XCP market price as published from an oracle or from the DEX (both methods have issues), and so on
  • Have it hardcoded, and set via an (forced) update of the software
  • (One could say having it set by consensus of node operators, but that wouldn’t work due to the possibility of sybil attacks and the current absence of a P2P link between CP nodes)
  • (Also, any model that takes into account XCP price in my opinion is fragile (especially so if coming from an oracle), and easily manipulated (especially so if coming from the Dex)

The optimal gas price must be high enough to function as an effective spam deterrent, preventing potential DOS vectors (i.e. spamming contract executions), and must be low enough to not prohibit the use of smart contracts functionality. It must also be cognizant of the total # of outstanding XCP and take that into account, especially as the supply is progressively burnt up. Being “cheaper than Ethereum” for execution cost may have some value here, as well…

In determining the viability of burning XCP for gas, I’d like to get opinions on how gasprice can best be determined from folks… ideas?

2 Likes
16

Because Counterparty doen’t have miners and all CP transactions need Bitcoin dust. How smart contract “transactions” are moved/verified, doing Bitcoin miners there anything? Maybe stupid question but I try understand how that all working :slight_smile:

Why not give Gas for Bitcoin miners who want mine Counterparty transactions or Smart Contracts transaction like side chain?

Probably I am only too stoned today, but if someone can tell how it working :grinning:

17

I know too little of how Ethereum works.

Who does the EVM computation?.. Is that a concious decision to adopt that work and if so, could the gas price for that work not increase to a point that someone takes it or until it caps out against a limit set by those offering the work? If there is just a pool of work and a pool of EVM computation, then it’s harder to see what is the best simplest option.

I think avoiding anticipating price is wiser. If the price of gas is cheap, then more work gets done and the only ones that suffer are the ones doing the work. So, I don’t know if it’s like wages or literally that you’re trying to set the price of oil. That analogy Ethereum makes to gas being the oil in the machine, seems at odds with distributed power and wealth, in that it’s not obviously being determined at a local level but by some central authority - albeit perhaps some algorithm over the sum total.

Would a simple answer be that contracts can offer a range of gas price they are willing to pay and workers then offer a range within which they would accept work… with different types of work perhaps being proscribed in units=the fees schedule.

18

There is no individual choice or variance at the CP node level — when it comes to consensus sensitive code execution, they all do the exact same thing, 100% of the time (and they must, or the network forks). Applied to the EVM, this means that each node must run each EVM contract execution, otherwise they get out of sync with eachother and the network forks.

This is different than the Ethereum model, where an individual miner chooses which contract executions end up in a block. There are no miners in Counterparty, just nodes that read and decode the CP transactions out from each mined block, validate them, and effect them due to some deterministic set of rules which must match across the nodes. Those specific rules, however, can allow and reject transactions based on some arbitrarily complex criteria. I would say that this model makes inputting certain “market forces” into the mix a bit more difficult, but not impossible.

Ruben and I are in the process of finding a macro econ/math genius that can help us in creating a set of formulas for how best to price gas and draw down the XCP supply. We have some ideas here, but doing this right is very complex as there are multiple factors at play that must be balanced, and extensive simulations must be run to ensure that the mechanics function predictably with a wide variety of inputs…

1 Like
19

Could we do something whereby XCP is consumed until 20% or 30% remain, and thereafter put more XCP into the system, for example through burning again, or through weekly disbursments to holders a la PoS? It won’t freak people out about an increase in supply because 80% must be consumed first, which will presumably take many many years

20

A suggestion for a dynamic price:

  • Every X blocks, e.g. 100 (around 17 hours)
  • Count the amount of gas fees consumed within last X blocks by
    ** counting the number of step, stop, suidice, sha3, etc
    ** multiplying each count with its cost
    ** summarizing everything
    ** formula: total_gas_fees = #step*1 + #stop*0 + ... + #transaction*500
  • A hardcoded high threshold must be set
    ** Discussion needed to determine
    *** Roughly how much computation time is acceptable for EVM for an average block (0.5 sec? 1 sec? 5 sec?)
    *** Testing is needed to find an estimate number of gas costs that result in this execution time
    *** The HIGH_THRESHOLD is hardcoded to the protocol once and for all (changing it would require hard fork)
  • If total_gas_fees > HIGH_THRESHOLD then increase the gas price by 7%
  • A hardcoded LOW_THRESHOLD is also needed. It can e.g. be ``HIGH_THRESHOLD / 2`
  • If total_gas_fees < LOW_THRESHOLD then reduce the gas price by 7%

Concerns

  • At a sudden surge in EVM usage, the gas price will not respond immediately. It takes about five days for the price to double. This is only a problem in very extreme cases. Say the threshold is geared to 1 sec/block. A 60x increase means one minute processing per block. Eventually the gas price increases enough to force contract executions to drop. A sudden increase of 600x ++ will cause nodes to spend more than 10 minutes per block and the nodes will be increasingly far behind and cause disruptions for a very long time.
  • For the same reason, a price does not prevent memory overflow and similar errors.
  • If very low EVM usage for some time, the price will settle at a very low level. An attack will be cheap. I suggest a hardcoded MIN_GAS_PRICE for this reason.
  • Another reason for a MIN_GAS_PRICE is that if the price drops to 7 satoshis it will never be able to increases again (due to rounding).

Conclusion

  • Let the gas price depend on usage. The optimal usage must be determined by testing and hardcoded to the protocol. Under normal conditions the price will change predictably and ensure that servers run smoothly while users pay a fair price. Some hard limits are needed because the price does not adjust instantly and some attacks are possible.
1 Like