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!
- General discussion: EMVPARTY discussion: Should we have the EVM on CP?
- EVM killswitch safeguard: EMVPARTY discussion: Safeguard killswitch
- Address prefix for contracts: EMVPARTY discussion: Special Address Prefix for contracts
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!