EMVPARTY discussion: Gas cost for contract execution


#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.


#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.


#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.


#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?


#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…


#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.

#21

I don’t see any technical reason why BTC burning couldn’t be done in place of XCP burning.

Every XCP spend requires BTC anyway to pay mining fees, so you’re always in need of BTC to execute smart contracts on Counterparty. You might as well go the whole 9 yards and pay for smart contract execution outright in BTC.

Imagine the marketing value of this:

“With Counterparty, you can execute Ethereum smart contracts directly on the Bitcoin mainchain using BTC only, without ever owning an altcoin”

This would be absolutely phenomenal for Counterparty.


#22

I think you might be on to something. However, you must consider the incentives of the Counterparty Node operators. By burning XCP they would be aware of an immediate economic incentive to hold XCP. You can argue that the same is the case with BTC, but BTC is not and will not be in a deflationary situation for a long time (decades).

An interesting compromise would be that it costs XCP to establish a smart contract and that it costs BTC to execute it. This goes some of the way to encouraging Counterparty Node deployment and reducing the barrier to entry for end-users. You still have appropriate spam prevention on computing operations.

I’ll have to think more about this.

EDIT: Also, it is actually quite elegant to have the Counterparty Protocol decoupled from the underlying blockchain (in this case the Bitcoin |Blockchain). By using XCP in place of BTC for different functions it can keep the Counterparty Protocol shielded from issues within the Bitcoin Blockchain. E.g. We don’t want an issue with Bitcoin that enables someone to execute near infinite smart contracts for near zero cost, crippling the Counterparty Network. A seamless liquid exchange mechanism between XCP and BTC is my preferred solution and it could be quite frictionless to the end-user.


#23

Yes, I imagine publishing smart contract code to the Counterparty ledger might need to cost XCP, but if it’s technically feasible to do in BTC, then it too should be payable in BTC. Of course, these things should also be payable in XCP at the same time.


#24

The EVM should be based on XCP and then capable of not being dependant on Bitcoin. BTC is becoming too political and rather at odds with its creators intent. If BTC goes too far in the wrong direction, having capability to move XCP to whatever is the better major chain, would be a real strength. Going further then, you could consider that a user’s choice of coin should be irrelevant but I prefer the other perspective, that CounterParty could become active on multiple chains… Litecoin CounterParty could be linked into the BTC CounterParty… etc, it just needs that extra step of flexibility that might be possible. I see no good reason to not use XCP and prefer BTC and limit the options, that just locks CounterParty to BTC even more.

JPJA’s suggestion looks good to me. The limit on step up and step down in price is not too fast and not too clever than it can be manipulated. It’s simple and clear and by rights should just work well. In the case that there is a clear issue that arising for XCP - where demand outstrips XCP because a price differential, then that can be considered but surely the price of XCP will fairly match the use of EVM and other CounterParty capability.

We see now then why above some calls for use of BTC… because BTC is not reflecting the demand on the EVM… and would perhaps then be then a lever to manipulate the EVM because the gas price wouldn’t respond. At least that’s my interpretation, following from suggestion of locking in the price but perhaps there’s more flexibility than I’m understanding. Still I can’t see why CounterParty devs and community would not want to see XCP acknowledged and prefer BTC in a way that limits us in the future.

It seems that suggestion to use BTC is as wild as the opposite - creating a new gas coin… but why, just stick with the established XCP and run with it… experiment and adapt. CounterParty isn’t just a BTC add-on, it should be more ambitious than that.