EMVPARTY discussion: Gas cost for contract execution

[something]

I’ll probably run into some internal maximum of this forum s/w, sorry…

@rubensayshi

1. Burn XCP as gas.the old testnet-only EVM on CP does this
   …
   From my perspective this would heavily promote hodling XCP instead of using it.

It depends on the price ;-). If it’s cheaper to burn XCP than running EVM on a comparable platform, it would promote the burning of XCP until such time the price advantage is gone.

@rubensayshi

2. Freeze XCP for a X amount of time as gas cost

We can’t freeze the XCP exchange rate, so this doesn’t do much in terms of stability and predictability of SC gas cost.
It may promote “hoarding” of XCP when the price is seen as good, but since there’s no easy way to figure out easily when to buy/sell so ultimately contract users would probably prefer something simpler.

@rubensayshi

3. XCP dividend XCPC

Well this doesn’t pay for gas (execution of SCs) so it doesn’t reward all the right people.

How many servers do we need to run SC’s and how many SC’s (assuming resources required by the “average” SC) can a single server execute? Do we expect all CP servers to execute all CP contracts?

I think we can’t (shouldn’t) discuss payments before we know the costs. A clearer problem statement, substantiated with some testnet metrics, would be highly desirable, IMO.

@deweller

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

Okay, but is everyone fine with the actual servers not getting paid at all for the execution of SCs? I can’t say I like that.
CP servers already don’t get paid and it’s somehow assumed that they are maintained by folks who “make money anyway”.
Maybe it’s not possible to do anything about this from a tech side, but I’m asking because above I asked a related question: do we expect that the most powerful CP server will be able to execute all SCs and not fall behind? If not, who’s going to tell 10 smaller nodes which contacts to pick?
This is another example why performance tests with gas-guzzling SCs should be done.

@deweller

1. Calculate gas based on a percentage of the total supply of XCP.

Sounds fine, except that if you deploy an SC to operate it for a while (say 1 year) you can’t know how much it’s going to cost you, so you’d have to either buy up a year supply of gas (XCP) or have dynamic pricing for your customers (would they be okay with that?).

@CryptoHustle

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.

I like your thinking, but as before I’d like to know why everyone assumes CP servers are free.
I’d like everyone (who has an opinion) to offer their estimate of resources and cost required to run a CP server that can process all SCs without falling behind.

@robby_dermody

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.

And who burned BTC the first time around.

@davidpbrown

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.

In real life terms, if it went deflationary, it would become too expensive to run SCs so demand for gas-related XCP would drop until such time XCP becomes cheap enough.

Other points:

• Imagine the unimaginable: in 3 year’s time BTC can do 5 times as many transactions, etc. The cost of running a CP server node that can execute all SCs in near-real time becomes $500/month. What then? One server goes down, CP SCs stop executing.
• Same scenario, but there’s no single x86 server that can execute all SCs
• The price of XCP drops to 90% or jumps 10x so gas becomes ridiculously cheap or expensive. Noone can afford to run a server, or pay for gas, on CP.

@innov8r

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.

I am also wondering why we’re not considering BTC more. Maybe a mix of sorts (say, 0.1 XCP to create a SC, and a separate charge to execute it), but this still doesn’t meet my own goal of rewarding server owners.

@CryptoHustle

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.

Sounds great as long as you’re not the one who has to pay for the server that executes SCs. It’s like when end users are complaining that bitcoin tx fees are too damn high.

Someone correct me if I’m wrong here, but does anyone think it’d be a good idea to have only 2-3 CP servers that can execute SCs? That sounds terrible to me.

@robby_dermody

• Have it set by POS vote, or dev vote

POS vote is potentially dangerous.

I like the idea of dynamic parametric formula, maybe a combo that includes BTC (current hash rate, perhaps) if part of payment could be in BTC.

@JPJA

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%

I need to study this (I deliberately haven’t, to be able to approach this with an open mind) but if contracts can be activated only by BTC tx that make use of it, the cost of BTC tx should be able to prevent EVM exec spam.

@innov8r

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.

I share your opinion on this.

@Consensus

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.

Agreed.

Post-BTC planning should be out of scope - it’s way beyond anyone’s capability, BTC is the core XCP technology and a hard fork would be required in any case, so why bother?

@rubensayshi

The main problem for me with burning BTC is that it burns BTC ,… something we’ve tried to avoid as much as possible (apart from the initial BTC → XCP burn).
It would also tie the price of XCP to BTC, or at least a ceiling, if the execution of a contract would cost 3 XCP or 0.0003 BTC then depending on the price of BTC and XCP people will choose the cheapest, I’m not very good at economics, but afaik that should more or less fix the XCP price to the BTC price.

I know I’ve seen 1-2 complaints about CP burning BTC, but most people realize it increases the value of BTC for everyone and overwhelmingly there’s no bad feeling about that.

It wouldn’t tie the price of XCP to BTC, IMO. If “1 gas” costs ( 2 * bitcoin_core_recommended_tx_fee) + ( 0.0001 XCP * unit_of_work), then they can’t choose the cheapest.

@rubensayshi

Personally I think the gas cost should be a formula of the total XCP supply, I just suck at math … so need some1 to come up with a formula.

Okay but that’s just 1 piece of the puzzle. In that case the price (in US$) would vary wildly so we need another piece - how to change the formula dynamically so that SC owners get a reasonable degree of predictability and be able to justify deploying their SCs on CP.

@davidpbrown

The value of an XCP is already a function of the total XCP supply.

It was $0.7 and it was $7 and within months it could be something entirely different. If you have an app that has 2 SCs and consider where you want to run this, and then figure it may cost you anywhere between $170 to $1,700 per year, it’s not a fun decision to make. Even if you prefund your SC, if XCP goes up 5x, you’d spend 5x more than you planned.

@Consensus

The problem with Counterparty is you’re forced to buy an altcoin to use it.

Do you mean metacoin? Altcoins are currencies that don’t use the BTC blockchain.

I don’t think using a metacoin is a problem. Gas fees in XCP would make XCP more liquid and narrow the spread which would also be good for the DEx and other applications and use cases. (I think a mixed payment in BTC and XCP would be even better, but even in that scenario there’s XCP).

@rubensayshi

And most important; it would eventually result in running out of XCP because if it still costs 1 XCP to run a contract once we only have 1 XCP left then we’d be done …

But it was mentioned above that the cost could drop to 0.00001 XCP or lower.

@rubensayshi

In contrary to XCP, the BTC price won’t be influenced much by the cost of running a smart contract, while the XCP price will be influenced by it because apart from speculation it’s the only other variable for it.

Yes, and XCP being much smaller, it’d gyrate wildly. That’s why I’m in favor of a combined BTC + XCP formula.

@Consensus

But note that it’s very conceivable Bitcoin Core will take care of making the BTC burns more costly by discriminating against burns in various ways.

Why would they want to discriminate against burns?

@Consensus

Note using the DEx to establish the BTC gas burn rate doesn’t affect the XCP gas burn rate at all. So if anything goes wrong there, it’s just more incentive to acquire XCP.

I would like to add here to what @robby_dermody said above, that it could be dangerous to reference DEx prices.
That would be true, but only initially. As people start crawling DEx for good deals, the price should eventually become stable. I would not exclude the possibility that a stable BTCXCP market would be created on the DEx if one knew that SCs reference the price. For example, let’s assume someone sells XCP for a low price. They would be sold immediately. If someone sells XCP for a price that is 5% or more expensive than elsewhere, and SCs must buy it, many would buy elsewhere and create a slightly lower sell offer on the DEx because they could still make money this way.

@Consensus

Gas should be cheap, but if XCP is gas, then the price of gas is dependent on the price of a deflationary asset.

There’s no need to make gas cheaper than the prevailing price for comparable work. Cost (in terms of compute resources) is roughly the same as on Ethereum (since the code is the same) and nothing is free.

Can @rubensayshi or @robby_dermody create a CP EVM benchmark suite (pick some popular contracts, add them to counterparty-lib repo?) so that we have a way to evaluate the cost in compute resources? I’d love to kick tires this way, and in the meantime I’ll start reading about how ETH does costing to prepare for part 2 of this discussion

Edit: I did some googling and put my notes in this post below. Those who are new to this problematic can check it out to save some time.

Contract pricing references

Theory Low level: http://gavwood.com/paper.pdf (Chapter 5; starting on page 7) (relevant part is provided at the bottom) Documentation (Frontier version): https://ethereum.gitbooks.io/frontier-guide/content/costs.html Practice Default - 10 szabo for 1 gas or 100,000 gas = 1 ETH Fee estimates - using Ethereum JavaScript and JSON-RPC API Estimates are just very rough (can be much less precise than Bitcoin tx fees) estimates as execution paths depend on inputs EVM compute operations are listed …