CGAS Token and the Neo Smart Economy
On September 4th, 2018, Neo Global Development released a new NEP-5 token called “CGAS”, to serve as a 1:1 GAS equivalent to use with smart contracts.
As I pointed out when creating Master Contract Token (MCT) months ago, GAS (or any UTXO-based) asset has serious shortcomings when it comes to use with smart contracts:
- Smart contracts can’t send GAS
- Smart contracts aren’t automatically invoked when receiving GAS
- A smart contract can’t reject a transfer of GAS for any reason
- Smart contracts can encounter an out-of-GAS fault when simply tallying the GAS inputs if they are too numerous (think about someone who claims GAS frequently, in small amounts)
MCT was designed to replace GAS as a currency, solving all of the problems above, letting GAS retain its value simply as a way to pay system/network fees. On top of this, it reduced smart contract deployment fees by 400 GAS for dApp developers on a budget who were willing to stake some MCT in their contract, solving another long-standing complaint about the Neo ecosystem, the high cost in GAS of smart contract deployment.
But, for whatever reason, NGD decided to develop CGAS as a way to mitigate the problems that MCT already solved. Except, it really only solves issue #1 above. And issues #2 and #3 are still a problem until NEP-7 is deployed on the MainNet. And issue #4 is even exacerbated somewhat by the way that CGAS works.
The CGAS smart contract allows in-contract trading of GAS for CGAS tokens using the conventional mintTokens operation that most ICO-offered NEP-5 tokens use. Because of this, it is possible for a user to invoke the mintTokens operation using a transaction that will run out of the 10 free GAS in execution time, resulting in zero CGAS minted while the GAS is still sent.
Worse still, according to NGD, the CGAS contract does not have the ability for the contract owner to manually intervene and refund GAS lost to the contract either by mistake or by transaction fault state. Those assets will be permanently burned.
So, if you decide to exchange your GAS for CGAS, do so with caution — although multiple Neo wallets support the mintTokens operation, it is not guaranteed that they will check to make sure your transaction will not run out of GAS and cause you to lose your funds forever. As a workaround, you can manually consolidate your GAS inputs by sending all of your GAS to yourself in a single transaction. Then your mintTokens transaction will only have a single input and should not fail for the reason above.
Another issue with CGAS that is of concern is the use of in-contract transaction storage. This is done as a workaround to allow a contract receiving CGAS to know how much CGAS was sent to it (this isn’t an issue in MCT, since the MCT contract invokes the receiving contract’s onTokenTransfer method directly with the information it needs). Other proposals for a direct notification method have been discussed at-length in the Programmable NEP-5 Token Extension proposal.
This in-contract storing of CGAS transaction data in itself may unnecessarily bloat the blockchain storage, but we also have to consider how third-party smart contracts are going to handle potential replay attacks. They will need to also duplicate and store the same transaction information in their own contract, doubling the amount of on-chain storage required for this workaround.
As NEO 3.0 approaches over the next year or two, a lot of these issues may become moot — hopefully NGD can work with the community to improve the ecosystem, taking feedback and proceeding slowly with consensus from all interested parties. It is definitely going to be an interesting journey, ultimately I still think NEO will still be a contender to attact a lot of dApps and take its rightful place in the tier of top blockchain platforms.
