Apricot Phase Five: PC Atomic Transfers, Atomic Transaction Batching, and C-Chain Fee Algorithm…
Apricot Phase Five: P<>C Atomic Transfers, Atomic Transaction Batching, and C-Chain Fee Algorithm Optimizations
Apricot Phase Five will activate on the Fuji Testnet at 10 a.m. EST (3 p.m. UTC) on Wednesday, November 24th. The Avalanche Mainnet activation time will be announced in the coming days.
This evening, the pre-release code was published for Phase Five of the Apricot Upgrade (“AP5”), which will activate at 10 a.m. EST (3 p.m. UTC) on Wednesday, November 24th on the Fuji Testnet. Note, this pre-release code only works on Fuji. If you run it on Mainnet, it will exit on startup.
Pending a successful AP5 activation on Fuji, the Avalanche Mainnet AP5 activation time will be announced and the official AP5 AvalancheGo release (v1.7.0) will be published.
This upgrade includes protocol optimizations that are not compatible with AvalancheGo versions < v1.7.0. If you run a node on Fuji Testnet, it is recommended that you update your software to AvalancheGo >= v1.7.0 before the activation time on Fuji. If you are a Mainnet node operator, there is no action required until the official AvalancheGo@v1.7.0 code is published.
P<>C Atomic Transfers
Avalanche uses an abstraction called Shared Memory to facilitate the movement of AVAX and ANTs (Avalanche Native Tokens) between the C-Chain, P-Chain, and X-Chain. In Shared Memory, all in-flight transfers are represented as UTXOs that can be consumed asynchronously by whichever chain the UTXO owner(s) calls `ImportTx` on. However there is one BIG exception, users can only go between X<>C and X<>P. This means someone trying to stake AVAX they received on the C-Chain has to travel through the X-Chain to get to the P-Chain. This extra step adds additional fees, complexity, and latency to the C<>P transfer process (one of the most common flows on the Primary Network).
Starting in AP5, users can consume UTXOs in Shared Memory on ANY Chain. This means you can now export funds from C and import them directly into P, or vice versa. This new functionality makes it easier to build interesting cross-chain mechanisms on the Primary Network and makes it easier for integrators that can’t index the X-Chain’s DAG to support staking.
Atomic Transaction Batching
When the Avalanche Network launched, the number of Atomic Transactions that could be processed in any block (on both the C-Chain and P-Chain) was capped at 1. When there is more than 1 pending transaction in the mempool, users can encounter uncharacteristic delays as they wait for their transaction to eventually be prioritized (sorted by AVAX burned) and included in a block. This throughput was sufficient for the first year of the network’s existence but has started to become a bottleneck. Since the start of Avalanche Rush, there has been a ~7–8x increase in the number of Atomic Transactions on the Primary Network each day (often coming in surges).
Starting in AP5, C-Chain and P-Chain blocks will contain multiple atomic transactions. For initial launch, this is limited to ~10 Atomic Transactions per block but could be increased in subsequent upgrades as usage increases. Paired with P<>C Atomic Transaction support, this upgrade will massively improve the cross-chain transfer UX.
C-Chain Fee Algorithm Optimizations
In Apricot Phase 3, dynamic fees were added to the C-Chain using an algorithm called “Moderato” (which targets a specific network utilization over time). This algorithm was parameterized to target 10M units of gas consumption every 10 seconds. Apricot Phase 4 introduced Snowman++ and Block-Based fees to reduce the amount of contention on the network and to encourage validators to batch transactions into fewer blocks, however, it left the target gas consumption and block production rate unmodified. We ran a large number of simulations to generate the parameter set used in AP4 and AP5, but there is nothing quite like the real world!
Although AP4 succeeded in greatly reducing contention on the C-Chain, we saw the minimum gas price oscillate at a higher rate of change than in our simulations. From one minute to the next, we observed changes of 20–50%. This directly impacted the experience of some users who saw their transactions “stall” as the minimum gas price jumped by the time their transaction made it into the mempool. Those users would then need to wait for the minimum gas price to go down before they would see their transaction included into a block (unless they “sped up” their transaction using their wallet).
Starting in AP5, Moderato is now parameterized to be ~66% more stable, target 15M units of gas consumption per 10 seconds, and better regulate block batching (less blocks that are more full). The additional gas price stability should make transaction construction more reliable, the increased target gas consumption should reduce the average gas price, and increased block batching should increase the number of transactions that are processed at a given gas price. Over the next few months, we will continue to pursue EVM optimizations that justify the further increase of target gas consumption.
Useful Links
- Apricot Phase Five Upgrade code can be found here.
- A tutorial for upgrading your node is available here.
- If you have any questions, please connect with the Ava Labs developer team here.
FAQ
How do I upgrade my node?
The process to upgrade to AvalancheGo v1.7.0 is the same as any other upgrade. If you build from source, run the build script as before. If you use the pre-compiled binaries, invoke them as before. If you use the installer script, use that as before.
Once you start AvalancheGo v1.7.0, you do not need to do anything else. More information on updating a node can be found here. As a reminder, it is best practice to have a backup of your staking key/certificate.
I use Metamask. Do I need to change anything?
No.
Do I have to upgrade my node?
If you don’t upgrade your validator to v1.7.0 before the Avalanche Mainnet activation date (which will be shared in coming days), your node will be marked as offline and other nodes will report your node as having lower uptime, which may jeopardize your staking rewards.
Is there any change in hardware requirements?
No.
Will updating decrease my validator’s uptime?
No. As a reminder, you can check your validator’s estimated uptime using the `info.uptime` API call:
I think something is wrong. What should I do?
First, make sure that you’ve read the documentation thoroughly and searched the FAQs. It might answer your question somewhere. If you don’t see the answer, go to our Discord server and search for your question. If it has not already been asked, please post it in the most appropriate channel.
Apricot Phase Five: P<>C Atomic Transfers, Atomic Transaction Batching, and C-Chain Fee Algorithm… was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.
