It does not make sense, isn’t it?
Most of the Ethereum-based DeFi are collateralized loans. The ETH price drop on March 12 triggered these DeFi lending agreements; as the price of collateral fell rapidly, thresholds were crossed on these agreements, initiating large-scale liquidation.
In order to prevent assets from being liquidated, DeFi users needed to make up positions by transferring more collateral to the loan agreement, increasing the collateral ratio to prevent liquidation (also avoiding collateral being auctioned at a discount).
These activities caused a surge in transaction volume on Ethereum, network congestion, and a surge in gas fees.
In order to initiate an ETH transfer or smart contract execution on Ethereum, you’ll need to pay transaction fees, aka gas.
The price a user will pay a miner for a unit of computation (similar to the price per liter of gasoline) is included in each transaction. If market factors (congestion) increased the lowest price per unit of computation a miner may accept, users may find that their transactions are not being included in a block.
Every transaction on Ethereum blockchain contains two fields related to gas:
the gas limit - the maximum limit of computation units the transaction can consume (if the transaction will consume more gas than this limit, Ethereum will throw an error and this transaction will be reversed)
the gas price - the unit price of the computing resource
The users need to set a gas limit because it’s impossible to accurately measure the total computation required by one transaction before it is actually executed by the nodes. When Ethereum blockchain is congested, you may find that your transaction is pending for a long time, and in order to complete it, you may need to increase the gas price.
The actual amount (in ETH) that is charged as a transaction fee is not (gas limit * gas price), but (gas consumed * gas price).
A Weird Trip
Let’s think about a road trip and look at some numbers:
You add 50 liters of gas (gas limit) for the trip
During the trip, you consume 20 liters of gas (gas consumed by transaction)
Current gas price is $3 per liter
Initially you need to pay $150 (50 liters * $3 per liter) to fill up the car, but in the end your cost for the trip is only $60 (20 liters * $3 per liter). You will be refunded $120 at the end of the trip. Sounds perfect right?
However, what will happen if you only add 10 liters of gas (gas limit), which is not enough for you to complete the whole trip?
On Ethereum, you won’t break down halfway, but instead will be sent back to where you started. The transfer amount in a transaction will be returned to the original account, but the transaction fee is not refundable, even if the transaction failed.
We have seen these DeFi user scenarios emerge during the ETH market crash:
Case 1: I want to send a transaction, but the transaction fees have fluctuated substantially due to network congestion and I don’t know how high I need to set my transaction fee. If the setting is low, the transaction will not be accepted by the blockchain; if the setting is too high, I will be distressed over the extra money spent.
Case 2: I have enough ERC-20 assets (USDT, DAI, etc.) but I don’t have enough ETH in my wallet to pay the gas fees. I can send ETH from other wallets, but I’ll also need to pay an extra high transaction fee to complete the transfer. If my ETH is currently on an exchange, this is even worse, as exchanges may have paused withdrawals due to the price crash.
In both scenarios, transaction fees are the real pain points.
Can we have a more accurate and certain way to calculate transaction fees?
One of the reasons for the variation in transaction fees on Ethereum is because the blockchain functions as a world computer. As execution is moved to each node, the design of on-chain computation prevents accurately measuring the total computation required by a transaction before it is actually executed on the node. This is why users are required to set a gas limit, instead of providing an exact amount of gas that the transaction will use.
Nervos CKB in contrast, adopts a design that utilizes off-chain computation and on-chain verification. The blockchain acts more like a judge instead of a world computer. As long as the transaction is verified and meets the relevant rules, the transaction can be executed on-chain.
This also means that the explicit state changes are known before the transaction is submitted to CKB and the resources that will be consumed in the verification of this transaction can be accurately calculated by the transaction sender.
The CKB VM (virtual machine) will evaluate the transaction at its most basic (instruction) level. The exact resources to be consumed for all instructions is included as the transaction is shared among nodes, the amount of resources [gas limit, or “cycles” in CKB] is known prior to the transaction being included in the blockchain.
RISC-V is the instruction set architecture selected for CKB VM. Unlike other blockchain virtual machines, CKB VM is an emulation of an actual CPU.
On CKB, you only need to set the gas price, without worrying about the gas limit:
CKB transaction fee = cycles (a fixed number after transaction construction) * price per cycle
So in the CKB world, making a transaction is like planning a trip in the real world. Once the starting point and the end point are determined, fuel consumption can be determined and now all this is required is the unit price of the fuel.
If you want your transactions to be packaged and processed quickly by miners, you only need to increase the price paid per cycle.
What will happen if CKB experiences network congestion?
You have sent a transaction with a low cycle price, and it will not be packaged into a block due to high demand for the scarce block space. To get your transaction processed, you will only need to send another transaction with a higher cycle price.
The prior transaction with the low transaction fee will be invalidated when the node verifies the new transaction, and the transaction fee from the old transaction will not be consumed.
What can be used to pay the transaction fees?
Currently, most Layer 1 only accept transaction fee payment in the native token of the blockchain (ETH, for example).
While it is technically possible to pay transaction fees in non-native currencies on other blockchains, CKB has been designed to allow any kind of user-defined tokens to be used to pay transaction fees. Through the use of designs such as Open Transactions, you will never encounter the difficult situation of having tokens but being unable to send transactions during a market crash.
Using Portal Wallet to buy Starbucks (burger king, and Didi..) in China - video by Daniel Lv who ordered an Grande Americano without ice using 558 CKB.
Nervos applies the RFC (Request for Comments) process for implementing every building block of the protocol. There were 24 Previous RFCs that can be found here.
If you are curious about why a design in CKB is what it is now, please post your questions in this repository.
(#2038) The RPC error now uses different error codes and returns the detailed error information in the data field
There are also a bunch of new RPCs and new fields for existing RPCs, see the CHANGELOG for details
(#2152) This version also has migrated the database schema. It will run automatically when the new version starts the first time.
Polyjuice [an Ethereum on CKB solution]
Support CHAIN_ID and DIFFICULTY op codes
Update integration script
Capsule [development framework for creating smart contract scripts in Rust for CKB]
Change layout of rust contract
Upgrade bundled lumos indexer version to 0.7.4 to support connecting node via https
Muta [layer2 framework on CKB]
SECBIT Labs [Zero knowledge proof toolkit for CKB]
Lay2 [pw-sdk, build dApp on CKB and run them everywhere]
Obsidian Labs[developer IDE]
Synapse [browser wallet and keyper agency]
Synapse Extension v0.0.15 is released
Bug fix: Fix unable to send anyone can pay transaction that has capacity less than 61
UX improvement: Fill type hash into UDT management form if user click the name from UDT list, to make it easy to manage UDTs
BlockABC [onchain CKB and web auth]
GrowFi [token swap functionality]
Obsidian Systems [CKB integration with ledger wallets] - github
Summa One [BTC/CKB interoperability] - github
LeapDAO[EVM-compatible sidechain framework for Nervos] - link
New Grants Proposal - N/A
The Nervos Foundation currently runs a grants program for builders. check out the scope and how to apply.
If you like it - share it, if you hate it - share it so more ppl can hate it. Happy Friday :)
CKB Weekly is curated by a group of people who witnessed Lina’s birth and started this to record her growth. Any views expressed are personal and do not represent an official position of the Nervos project. Got updates or articles you would like to include? Any feedback or other suggestions? Let us know by replying to the email.
If you are interested in contributing, welcome to join the review group on TG.