Release v5.15.0

Astar Network (Polkadot)
1

Hello everyone,

we will share a few pieces of info for the upcoming v5.15.0 release that is bound tomorrow, on 27th of July, 2023. We decided to do this since it brings quite a bit of changes for the node operators, dApp users & developers, and regular users.

1. Breaking CLI Change (Client)

Some of the WS params that have been kept for backwards compatibility have been either completely removed or renamed (PR). Both HTTP and WS server have been behind a single port for quite some time now, and this is just a cleanup of legacy parameters. The default port, 9944, services both WS and HTTP requests.

Node operators should make sure to adjust their scripts for starting the node. Please refer to the linked PR or the refreshed Astar documentation (will be merged on the 27th of July).

2. Remote XCM Account Derivation Update (Builders)

When sending a Transact message from one chain to another, the message origin on the destination chain will be different than the one on the origin chain. E.g. if Alice sends an XCM sequence containing Transact from some parachain to Shiden, the instruction will be executed as if Alice_derived executed it. This isn’t new and has been supported on Shibuya for quite some time.

The update is in how these derived addresses are calculated.
Previous approach wasn’t stable, and as a result, when XCM v3 came out it changed the derived address. This isn’t good since users need to be able to rely that the derived address will remain the same. This PR introduced a more stable & configurable way of calculating derived addresses.
It’s been integrated into Shibuya and Shiden for now.

Shibuya supported the legacy, not-stable, approach so this is heads up to all developers utilizing this feature - the derived address will change after the next runtime upgrade.

Shiden hasn’t had this feature enabled before, so there are no breaking changes, only a new feature.

For those who use xcm-tools binary, it has also received an update to cover the new account derivation scheme.

Astar docs will be updated with explanation about how these addresses are derived & how to use the new xcm-tools.

3. Ethereum Transaction Accounting For PoV Size (Everyone)

This is a big & important update since it brings a new dimension to how EVM gas is calculated.

To give a brief introduction:

  • each block is a finite resource, and we can only put so many transactions into them
  • block is bound by two dimensions:
    • ref_time - execution time; how long does it take to execute the whole block on a CPU
    • PoV_size - how much data has to be sent to Polkadot validators to validate the block
  • so far, Ethereum only accounted for ref_time, which gets converted into gas
  • this is problematic since if an Ethereum transaction consumes 1% of available ref_time and 50% of available pov_size, it will only pay for the 1%
  • the new change will take a look at both resources, and charge the one that was consumed more
  • using the above example, it would mean user pays for the 50% of the consumed block capacity, instead of 1%

Support for this has been added in frontier via this PR.

How Does This Impact Me?

There are 3 possible scenarios which can happen after the upgrade.

  1. Gas remains same as before (some deviations possible since we’re also switching over to Shanghai configuration)
  2. Gas increases because transaction consumes more PoV_size resource than ref_time
  3. Transaction is no longer possible because it exceeds maximum allowed PoV size.

The third scenario is extremely unlikely, but not impossible.
However, it should have been impossible for such transaction to even work in the past since block containing such transaction couldn’t be validated by the relay chain.

If developers are worried about such scenario, they are encouraged to try their smart contracts on Shibuya where the runtime upgrade will be applied first.

Maximum PoV size for a transaction is ~3.75 MB. This limit is imposed by the relaychain (Polkadot & Kusama) and therefore must be respected.

4. Reserve Balance & Existential Deposit

Reserve balance will no longer contribute to the existential deposit (ED).
Assuming ED is greater than zero, this simply means there cannot be an account whose balance is fully reserved, without any free balance.

We don’t expect this to impact anyone but it’s a change worth noting.

Release

As usual, you can find all releases on the Github page here.

Astar docs update PR will be merged after release has been made.

8 Likes