Godwoken V1 Fee Structure

Over the past few days, we have received a lot of community feedback on the new gas fee structure of Godwoken V1 publicly and privately. So first, I would like to thank those who have reached out for constructive conversation.

I felt this would be a good time to reach out to the community and share our current thought process on the gas fee structure, the current implementation in place, and some possible directions moving forward. I encourage everyone to take a few moments to share their thoughts below so that your voice can be heard.

Gas Fee Introduction

Under Godwoken V0, the now legacy version of Godwoken, the system was essentially gasless. This allowed for free transactions by end-users, as well as free deployment of smart contracts to the network. This was also accompanied by restricted deployment. However, with the deployment of Godwoken V1, this restriction has been lifted and anyone can now deploy (or transact) with the network anonymously. We considered this our Godwoken Beta phase.

With this change, a gas fee needed to be introduced.

A gas fee in the L2 Ethereum ecosystem plays two roles.

  1. To pay the cost of settling rollup data to the L1 (Ethereum)
  2. To secure the network against attacks.

In the case of Godwoken, the data is settled down to the Nervos CKB L1. Due to the unique nature of Nervos CKB L1 and Godwoken, those settlement fees reach an incredibly small number. In fact, it is so small that it is not a factor in determining gas costs for Godwoken V1.

However, the gas fee does play a major role in securing the network from attacks. The main concern is an attack by denial of service (DoS). Now that all Godwoken V1 restrictions have been lifted and as it increases in popularity, the attack surface becomes larger. This, unfortunately, is the cost of a public open access blockchain.

Current Gas Fees

Currently, the gas fee is set to 9_000 shannons or 90_000 gwei. This can be seen when looking at the block explorer.

This base gas price then in turn affects all gas-requiring features of the network. (Such as calling smart contracts with functions that require any type of state changes). Read-only operations remain free, as is standard with EVM blockchains. There have been no changes in gas prices per OP codes, and they remain standard. Our goal is to be as close to 100% compatible at all times and therefore, there are no plans to tune things on an OP code gas level.

Using this gas fee of 9_000 shannons, we can do some basic comparisons to other L2 networks, especially other optimistic rollups. If we check https://l2fees.info/ , we can see that we are on par with ZKrollups and are roughly 1/10th the price of other optimistic rollups (Boba, OP, Arbitrum) depending on the exact day and market conditions.

It’s important to look at the 'Send ETH" function, as this is pretty standard across all chains. On Godwoken V1, this is analogous to sending CKB (pCKB on L2). (Please note Metis is not a true rollup).

We chose 9_000 shannons as it set us around 1 cent to send ERC20 tokens on Godwoken. (Given this will fluctuate with the market. We will discuss this more below).

2022-07-12_11_55_36-Transaction_0x24cbabe74dbe4edeaacb90779b5b133c556ed987c7805679f12a08e1df0e2650_-

Once setting the gas fee structure, we need to then look at the lowest cost action that writes to the network. This is likely the easiest attack vector for a DoS attack. In this case, it would be writing a simple log to the network. Likewise, setting the fee also scales up to larger transactions on the network such as swaps, minting NFTs, or even deploying contracts. When we adjust the gas fees, it changes all of these actions, not just one.

It’s important to note that gas usage (and thereby total cost in gas fees) is determined largely by the smart contracts themselves. Well-written smart contracts can drastically reduce gas usage, while poorly written smart contracts conversely can drastically increase them. Therefore the cost of swaps on DEXs are determined by a few factors for example. Network base gas fee, code quality, and limitations of the solidity smart contract language. This makes it very difficult to compare costs across networks for such actions.

The Challenge

Moving forward, the challenge is finding a balance between acceptable gas fees and keeping the network safe. While on the one hand, a network that is too expensive to use is of no use, while on the other, a vulnerable network may be unsafe or inconvenient during essential times.

There is likely no right or wrong answer but acceptable trade-offs.

Suggested Steps Forward

There are a few steps forward that may help secure the network while allowing us to reduce gas fees. Some can be implemented immediately, while others must be added to the short-term roadmap.

It’s important to note that we together are exploring new territory as a cutting-edge optimistic rollup. Often there are no best practices or gold standards yet. And therefore, we should keep in mind that we may need to pivot away from these steps if necessary for the safety or stability of the network. Each is a small step, without any single suggestion being the ultimate solution.

1) Implement a rate limit of 100 requests max per 1 IP address per minute.

This means, that if 1 IP address tries more than 100 requests in a 1 minute period (1 - 2 blocks), it would then be blocked following this. This could reduce the chances of DoS attack from an IP address.

This is possible within the current configuration of the network without additional major changes.

2) Implement a rate limit of 100 requests at the account address level per block

This means that 1 account could not make more than 100 transaction requests per block. This could reduce the chances of DoS attack from a single account address.

This is not currently possible within the current configuration of the network without additional changes and would be needed to be added to a roadmap.

Both steps 1 and 2 are minor security updates and ultimately gas fee is the final and most important line of defense in the network.

3) Introduce a price oracle system that auto balances the USD/CKB gas fee

Currently, the gas fee is set manually by the Godwoken V1 core development team. By introducing an oracle mechanism, CKB gas fees could be reduced/raised as CKB prices rise/fall. This would prevent transactions on the network from becoming too expensive, while still allowing gas fees to be high enough to secure the network.

This is not currently possible within the current configuration of the network and would be needed to be added to a roadmap. In the meantime, the core team could periodically review USD/CKB prices and adjust manually on a set predictable schedule.

4) Reduce Godwoken V1 gas fee incrementally

With the introduction of proposals 1 and 2, the gas fee could be incrementally decreased.

Currently, the fee is 9_000 shannons and after step 1 is implemented, then I propose reducing to 4_000 shannons. Once this is completed and no new further issues have been introduced, we can move on to step 2 implementation of limiting addresses per block. Following this, I suggest moving gas fee down to 1_000 shannons.

5) To be determined

There are still other creative solutions that could be implemented and we will continue to share them here as they arise.

Summary

We hope that this explanation sheds light on the new Godwoken V1 gas fee structure and the reasoning for these changes to make sure we find the optimal balance between acceptable gas fees and the need for network security.

As we continue to work on updates we will take each step incrementally and with purpose. We will constantly measure the results and make sure no new technical issues are introduced into the system as improvements are made. Furthermore, we’ll make sure to keep everyone updated and provide explanations for the latest improvements.

Your input is valued and we encourage you to continue to provide feedback as always for the benefit and long-term success of Godwoken.

8 Likes

Thank you Eric for your diligence in addressing community concerns about gas fees on Godwoken and preparing this well thought out explanation and proposal.

Wanted to comment on a few things:

Using this gas fee of 9_000 shannons, we can do some basic comparisons to other L2 networks, especially other optimistic rollups. If we check https://l2fees.info/ , we can see that we are on par with ZKrollups and are roughly 1/10th the price of other optimistic rollups (Boba, OP, Arbitrum) depending on the exact day and market conditions.

I think an important point to note on this is:

Nervos prioritizes security, decentralization and flexibility.

A natural question that could be asked is: “aren’t other L1’s orders of magnitude cheaper than these L2’s?”

Yes. This is true. With Nervos, we have chosen to pursue a path of layered scaling with the belief that this is the sustainable path over the long run.

Godwoken is an L2 system created because smart contract developers today prefer Solidity and Ethereum (for good reason… tooling, dev experience, libraries, knowledge base, etc.). If preferences change in the future (Move is exciting), additional layers can be created to meet developer needs (and in turn Godwoken can ossify and sunset), with no impact to the L1 protocol.

Additionally, as we see the rise of the “modular blockchain” thesis and systems being booted up purely to store blockchain transaction data (such as Celestia), CKB is perfectly suited to enforce protocol guarantees of higher layers while transaction data can live elsewhere (increasing the economic density of CKB transactions).

Foremost, any user around the world can run a CKB node on their home computer and with a little bit of patience (and a decent internet connection) can verify the history of the chain and follow the consensus process of the network.

There is no heirarchy forced onto the users of the network, there is no technical requirement for an Infura-like network that can be coerced into censorship.

Due to the unique nature of Nervos CKB L1 and Godwoken, those settlement fees reach an incredibly small number.

The small fees to settle Godwoken transactions are partially due to technology (CKB’s use of witness data versus Ethereum’s calldata), however the difference in fees can truly be attributed to an excess of CKB blockspace compared to demand, which is not the case on Ethereum.

  1. Implement a rate limit of 100 requests at the account address level per block

100 sounds high, I can’t see an end user generating more than 1 transaction per block. Would this be a reasonable limit? 100 transactions per block sounds like a back-running bot, which would be great if we could eliminate those.

Want to wrap this up by saying T H A N K __ Y O U __ A G A I N! to Eric, the core team and the dev relations engineers for all of your hard work to bring the fun and convenience of Ethereum dApps to our community. :clap: :clap: :clap: :clap:

6 Likes

I answered on Twitter. #3. automated price oracle wins for me.