diff --git a/404.html b/404.html index 0edc79a..daf92b1 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index 73ff352..dbeb39c 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index 41ea6dc..1dff5e3 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index eb4dc17..ec2aae0 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index 7a37f38..3298d4f 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index c180b4f..3830cdd 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index 1f677aa..21d4c87 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html index 2b4b403..7093a45 100644 --- a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html +++ b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index db5095d..e056f3f 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 488ed33..74ae919 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index d7e75c1..c1be4a8 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index ea7e508..adcfaf1 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index ab122f5..3edf613 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0045-nft-deposits-asset-hub.html b/approved/0045-nft-deposits-asset-hub.html index 131e2f0..7fbee1e 100644 --- a/approved/0045-nft-deposits-asset-hub.html +++ b/approved/0045-nft-deposits-asset-hub.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index 761fba2..fdd8c16 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index 5cc92ec..6e483d1 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index 8574dba..c9fc827 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 74adaf3..4de6fa7 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/approved/0078-merkleized-metadata.html b/approved/0078-merkleized-metadata.html index 2244236..7ece31c 100644 --- a/approved/0078-merkleized-metadata.html +++ b/approved/0078-merkleized-metadata.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index 83546fd..2df1a53 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index 83546fd..2df1a53 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/print.html b/print.html index 936f195..0a1f005 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -444,6 +444,204 @@ The following other host functions are similarly also considered deprecated:

Future Possibilities

After this RFC, we can remove from the source code of the host the allocator altogether in a future version, by removing support for all the deprecated host functions. This would remove the possibility to synchronize older blocks, which is probably controversial and requires a some preparations that are out of scope of this RFC.

+

(source)

+

Table of Contents

+ +

RFC-0066: Add EVM+ink! Contracts Pallets to Asset Hub for Polkadot

+
+ + + +
Start Date14 January 2024
DescriptionA proposal to add EVM+ink! Contracts to Asset Hub for Polkadot to support Polkadot Rollups and larger numbers of EVM/Coreplay smart contract developers and their users on Polkadot Rollups and AssetHub for Polkadot.
AuthorsSourabh Niyogi
+
+

Summary

+

This RFC proposes to add the two dominant smart contract programming languages in the Polkadot ecosystem to AssetHub: +EVM + ink!/Coreplay. The objective is to increase DOT Revenue by making AssetHub accessible to +(1) Polkadot Rollups; +(2) EVM smart contract programmers; +(3) Coreplay programmers who will benefit from easier-to-use smart contract environments.
+These changes in AssetHub are enabled by key Polkadot 2.0 technologies: +PolkaVM supporting Coreplay, and +hyper data availability in Blobs Chain.

+

Motivation

+

EVM Contracts are pervasive in the Web3 blockchain ecosystem, +while Polkadot 2.0's Coreplay aims to surpass EVM Contracts in ease-of-use using PolkaVM's RISC architecture.

+

Asset Hub for Polkadot does not have smart contract capabilities, +even though dominant stablecoin assets such as USDC and USDT are originated there.
+In addition, in the RFC #32 - Minimal Relay Chain architecture, +DOT balances are planned to be shifted to Asset Hub, to support Polkadot 2.0's +CoreJam map-reduce architecture.
+In this 2.0 architecture, there is no room for synchronous contracts on the Polkadot relay chain -- +doing so would waste precious resources that should be dedicated to sync+async composability.
+However, while Polkadot fellows have concluded the Polkadot relay chain should not support +synchronous smart contracts, this is not applicable to AssetHub for Polkadot.

+

The following sections argue for the need for Smart Contracts on AssetHub.

+

Defi+NFT Applications need Smart Contracts on AssetHub

+

EVM Smart Contract chains within Polkadot and outside are dominated by defi + NFT applications. While the assetConversion pallet (implementing Uniswap v1) is a start to having some basic defi on AssetHub, +many programmers may be surprised to find that synchronous EVM smart contract capabilities (e.g. uniswap v2+v3) on other chains are not possible on AssetHub.

+

Indeed, this is true for many Polkadot parachains, with the exception of the top 2 Polkadot parachains (by marketcap circa early 2024: Moonbeam + Astar) who do include the EVM pallets.
+This leads to a cumbersome Polkadot EVM smart contract programming experience between AssetHub and these 2 Polkadot parachains, making the Polkadot ecosystem hard to work with for asset-related applications from defi to NFTs.

+

The ink! defi ecosystem remains nascent, having only Astar as a potential home, and empirically has almost no defi/NFT activity. Although e.g. uniswap translations have been written,

+

An AssetHub for Polkadot deployment of EVM and ink! contracts, it is hoped, would likely support new applications for top assets (USDC and USDT) and spur many smart contract developers to develop end user applications with familiar synchronous programming constructs.

+

Rollups need Smart Contracts on AssetHub

+

Polkadot Data Availability technology is extremely promising but underutilized.
+We envision a new class of customer, "Polkadot Rollups" that can utilize Polkadot DA far better than Ethereum and other technology platforms.
+Unlike Ethereum's DA which is capped at a fixed throughput now extending to EIP-4844, Polkadot data availability is linear in the number of cores.
+This means Polkadot can support a much larger number of rollups than Ethereum now, and even more as the number of cores in Polkadot grows. +This performance difference has not been widely appreciated in the blockchain community.

+

Recently, a "Blobs" chain has been developed to expose Polkadot DA to rollups by senior Polkadot Fellows:

+ +

A rollup kit is mappable to widely used rollup platforms, such as OP Stack, Arbitrum Orbit or StarkNet Madara.
+A Blobs chain, currently deployed on Kusama (paraID 3338), enables rollups to utilize functionality outside the Polkadot 1.0 parachain architecture by having rollups submit transactions via a rollup kit abstraction. The Blobs chain write interface is simple blobs.submitBlob(namespaceId, blob) with a matching read interface.

+

However, simply sending blobs is not enough to power a rollup. End users need to interact with a "settlement layer", while rollups require proof systems for security.

+

Key functionality for optimistic rollups (e.g. OP Stack, Arbitrum Orbit) are:

+ +

Analogous functionality exist for ZK-rollup platforms (e.g. Polygon zkEVM, StarkNet Madara), with high potential for using the same Blobs+AssetHub chains.

+

While it is possible to have the operations in EVM Contracts translated in FRAME pallets (e.g. an "opstack" pallet), we do not believe a pallet translation confers significant benefits.
+Instead, we believe the translation would require regular updates from the rollup platform, which have proven difficult to implement in practice.

+

ink! on AssetHub will lead to CorePlay Developers on AssetHub

+

While ink! WASM Smart Contracts have been promising technology, the adoption of ink! WASM Contracts amongst Polkadot parachains has been low, in practice just Astar to date, with nowhere near as many developers.
+This may be due to missing tooling, slow compile times, and/or simply because ink!/Rust is just harder to learn than Solidity, the dominant programming language of EVM Chains.

+

Fortunately, ink! can compile to PolkaVM, a new RISC based VM that has the special capability of suspending and resuming the registers, supporting long-running computations.
+This has the key new promise of making smart contract languages easier to use -- instead of smart contract developers worrying about what can be done within the gas limits of a specific block or a specific transaction, Coreplay smart contracts can be much easier to program on (see here).

+

We believe AssetHub should support ink! as a precursor to support CorePlay's capabilities as soon as possible.
+To the best of our knowledge, release times of this are unknown but having ink! inside AssetHub would be natural for Polkadot 2.0.

+

Stakeholders

+ +

Explanation

+

Limit Smart Contract Weight allocation

+

AssetHub is a major component of the Polkadot 2.0 Minimal Relay Chain architecture. It is critical that smart contract developers not be able to clog AssetHub's blockspace for other mission critical applications, such as Staking and Governance.

+

As such, it is proposed that at most 50% of the available weight in AssetHub for Polkadot blocks be allocated to smart contracts pallets (EVM, ink! and/or Coreplay). While to date AssetHub has limited usage, it is believed (see here) that imposing this limit on smart contracts pallet would limit the effect on non-smart contract usage. A excessively small weight limit like 10% or 20% may limit the attractiveness of Polkadot as a platform for Polkadot rollups and EVM Contracts. A excessively large weight like 90% or 100% may threaten AssetHub usage.

+

In practice, this 50% weight limit would be used for 3 categories of smart contract usage:

+ +

We expect the first category to dominate. If AssetHub smart contract usage increases so as to approach this 50% limit, the gas price will increase significantly. This likely motivates EVM contract developers to migrate to a EVM contract chain and/or rethink their application to work asynchronously within CoreJam, another major Polkadot 2.0 technology.

+

Model AssetHub Assets inside EVM Smart Contracts based on Astar

+

It is essential to make AssetHub assets interface well with EVM Smart Contracts. +Polkadot parachains Astar and Moonbeam have a mapping between assetIDs and "virtual" EVM Contracts.

+ +

We propose that AssetHub support a systemic mapping following Astar: +(a) Native Relay DOT + KSM - should be mapped to 0xFFfFfFffFFfffFFfFFfFFFFFffFFFffffFfFFFfF on AssetHub for Polkadot and AssetHub for Kusama respectively +(b) Other Assethubs assets should map into an EVM address using a 0xffffffff prefix +https://docs.astar.network/docs/learn/interoperability/xcm/integration/tools#xc20-address

+

The usage of the above has been made code-complete by Astar:

+ +

Polkadot parachains Astar and Moonbeam adopted two very different approaches of how end users interact with EVM Contracts.
+We propose that AssetHub for Polkadot adopt the Astar solution, mirroring it as closely as possible.

+

New DOT Revenue Sources

+

A substantial motivation in this proposal is to increase demand for DOT via two key chains:

+ +

New Revenue from AssetHub EVM Contracts

+

Enabling EVM Contracts on AssetHub will support DOT revenue from:

+ +

New Revenue for ink!/Coreplay Contracts

+

Enabling ink! contracts will pave the way to a new class of AssetHub Smart Contract Developers.
+Given PolkaVM's proven reduced compile time and RISC architecture enabling register snapshots, it is natural to utilize these new technical capabilities on a flagship system chain.
+To the extent these capabilities are attractive to smart contract developers, this has the potential for bringing in new DOT revenue from a system chain.

+

Drawbacks and Tradeoffs

+

Supporting EVM Contracts in AssetHub is seen by some as undercutting Polkadot's 1.0 parachain architecture, both special purpose appchains and smart contract developer platform parachains.
+We believe the lack of growth of parachains in the last 12-18 months, and the high potential of CorePlay motivates new options be pursued in system chains.

+

Maintaining EVM Contracts on AssetHub may be seen as difficult and may require Substrate engineers to maintain EVM Pallets and manage the xcContracts.
+We believe this cost will be relatively small based on the proven deployment of Astar and Moonbeam.
+The cost will be justified compared to the potential upside of new DOT revenue from defi/NFT applications on AssetHub and the potential for utilizing Polkadot DA for Polkadot rollups.

+

Testing, Security, and Privacy

+

Testing the mapping between assetIDs and EVM Contracts thoroughly will be critical.

+

Having a complete working OP Stack chain using AssetHub for Kusama (1000) and Blobs on Kusama (3338) would be highly desirable, but is unlikely to be required.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

The weight limit of 50% is expected to be adequate to limit excess smart contract usage at this time.

+

Storage bloat is expected to kept to a minimum with the nominal 0.01 Existential Deposit.

+

Ergonomics

+

Note that the existential deposit is not 0 DOT but being lowered from 0.1 DOT to 0.01 DOT, which may pose problems for some developers.
+Many developers routinely deploy their EVM contracts on many different EVM Chains in parallel. This non-zero ED may pose problems for some developers

+

The 0.01 DOT (worth $0.075 USD) is unlikely to pose significant issue.

+

Compatibility

+

It is believed that EVM pallet (as deployed on Moonbeam + Astar) is sufficiently compatible with Ethereum, and that the ED of 0.01 DOT pose negligible issues.

+

The messaging architecture for rollups are not compatible with Polkadot XCM.
+It is not clear if leading rollup platforms (OP Stack, Arbitrum Orbit, Polygon zkEVM) could be made compatible with XCM.

+

Unresolved Questions

+

It is highly desirable to know the throughput of Polkadot DA with popular rollup architectures OP Stack and Arbitrum Orbit.
+This would enable CEXs and EVM L2 builders to choose Polkadot over Ethereum.

+ +

If accepted, this RFC could pave the way for CorePlay on Asset Hub for Polkadot/Kusama, a major component of Polkadot 2.0's smart contract future.

+

The importance of precompiles should

(source)

Table of Contents

and much more...

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

I've created the stateful multisig pallet during my studies in Polkadot Blockchain Academy under supervision from @shawntabrizi and @ank4n. After that, I've enhanced it to be fully functional and this is a draft PR#3300 in polkadot-sdk. I'll list all the details and design decisions in the following sections. Note that the PR is not 1-1 exactly to the current RFC as the RFC is a more polished version of the PR after updating based on the feedback and discussions.

Let's start with a sequence diagram to illustrate the main operations of the Stateful Multisig.

multisig operations

@@ -959,10 +1157,10 @@ pub type PendingProposals<T: Config> = StorageDoubleMap< -

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Standard audit/review requirements apply.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

Doing back of the envelop calculation to proof that the stateful multisig is more efficient than the stateless multisig given it's smaller footprint size on blocks.

Quick review over the extrinsics for both as it affects the block size:

Stateless Multisig: @@ -1026,17 +1224,17 @@ We have the following extrinsics:

| Stateless | N^2 | Nil | | Stateful | N | N |

So even though the stateful multisig has a larger state size, it's still more efficient in terms of block size and total footprint on the blockchain.

-

Ergonomics

+

Ergonomics

The Stateful Multisig will have better ergonomics for managing multisig accounts for both developers and end-users.

-

Compatibility

+

Compatibility

This RFC is compatible with the existing implementation and can be handled via upgrades and migration. It's not intended to replace the existing multisig pallet.

Prior Art and References

multisig pallet in polkadot-sdk

-

Unresolved Questions

+

Unresolved Questions

- + -

(source)

-

Table of Contents

- -

RFC-0076: Increase maximum length of identity raw data values from 32 bytes

-
- - - -
Start Date20 Feb 2024
DescriptionIncrease the maximum length of identity raw data values from 32 bytes
AuthorsLuke Schoen
-
-

Summary

-

This proposes to increase the maximum length of identity raw data values from a 32 bytes/chars limit to either a 64 bytes/chars limit or a 128 bytes/chars limit.

-

Motivation

-

Background

-

At the moment if you upload a file and pin it to IPFS storage you get an IPFS Content Identifier (CID), which is the unique ID of the file in the IPFS Network. That CID may be used to retrieve the file again via a standard IPFS interface and gateway from anywhere.

-

CIDs are reasonably short regardless of the size the underlying content and are based on the cryptographic hash of the content.

-

IPFS providers may default to using and recommending using CIDv1 [0] when using SHA256 generates a CID 46 bytes long, rather than CIDv0 [0] that generates a CID 59 bytes long, however CIDv0 may be be the preferred choice for minting and storing NFTs on-chain since it is cheaper.

-

Further, the URI protocol + CID for CIDv0 (ipfs://Qm...) will be 7+46=53 chars while for CIDv1 (ipfs://baf...) it will be 7+59=66 chars [1], so neither CIDv0 nor CIDv1 have a CID that supports a maximum length of 32 bytes, which exceeds the maximum 32 bytes/chars limit for bytes/string fields of their Polkadot on-chain identity.

-

Problem

-

If you want to set a Polkadot on-chain identity, users may provide raw data values of their email address "email" field, which may be longer than 32 bytes/chars (e.g. abcdefghijklmnopqrstuvwxyz@me.com or longer), and either just a CID or the URI protocol + CID associated with a legal document, as the value of the "legal" field, and the URI protocol + CID associated with the profile image to associated with their on-chain identity, as the value of the "image" field, however each field can only store a maximum length of 32 bytes/chars of information [3]. They may also want to set a custom value in the "additional" field, which currently only stores a maximum length of 32 bytes, since it currently has a FieldLimit.

-

Possible disadvantages of the current 32 bytes/chars limitation:

- -

Solution Requirements

-

The maximum length of identity raw data values should be increased from the current 32 bytes/chars limit at least a 59 bytes/chars limit (or a 66 bytes/chars limit) to support IPFS CIDs that are either CIDv0 or CIDv1.

-

They maximum length of "additional" field values should be increased by the same amount.

-

Stakeholders

- -

Explanation

-

If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide an email address or a website domain name that is longer than 32 characters, or try to use the IPFS CID (which may be associated with a file such as a document or image), then they will encounter this error:

-
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Data.Raw values are limited to a maximum length of 32 bytes
-
-

Increasing maximum length of identity raw data values from the current 32 bytes/chars limit to at least a 59 bytes/chars limit (or a 66 bytes/chars limit) would overcome these errors and support IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

-

Increasing the maximum length of "additional" field values would also overcome these errors and should be increased from the current 32 bytes/chars limitFieldLimit by the same amount.

-

Drawbacks

-

Performance

-

If Polkadot on-chain identities are able to store raw data values greater than the current maximum length of 32 bytes, then each identity may want to use the maximum (or more) amount of "additional" custom fields or more, which would impact storage and performance on the network.

-

Testing, Security, and Privacy

-

Implementations would need to be tested for adherance by checking that IPFS CIDs that are either CIDv0 or CIDv1 are supported.

-

No effect on security or privacy has been identified than already exists.

-

No implementation pitfalls have been identified.

-

Performance, Ergonomics, and Compatibility

-

Performance

-

It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

-

To minimize additional overhead the proposal suggests at least a 59 bytes/chars limit (or a 66 bytes/chars limit) since that would at least provide support for IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

-

Ergonomics

-

It alters exposed interfaces to developers and end-users since they will now be able to provide IPFS CIDs that are either CIDv0 or CIDv1 as the values of Polkadot on-chain identity raw data input fields. Optionally 66 bytes/chars limit could be established to optimise for the usage pattern end-users, since that may be more intuitive to them, as it would allow users to provide a link (e.g. URI protocol + CID) rather than just the CID.

-

Compatibility

-

Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

-

Prior Art and References

-

Prior Art

-

No prior articles.

-

References

- -

Unresolved Questions

-

Why can't we increase the maximum length of Polkadot on-chain identity raw data values and the "additional" field limit from 32 bytes/chars to an even longer maximum length than proposed of 128 bytes/chars?

- -

Relates to RFC entitled "Increase maximum length of identity PGP fingerprint values from 20 bytes".

(source)

Table of Contents

-

Drawbacks

+

Drawbacks

The primary drawback is a reliance on governance for continued treasury funding of infrastructure costs for Invulnerable collators.

Testing, Security, and Privacy

@@ -2124,7 +2210,7 @@ number of Candidates, can handle updates over XCM from the system's governance l

Performance, Ergonomics, and Compatibility

This proposal has very little impact on most users of Polkadot, and should improve the performance of system chains by reducing the number of missed blocks.

-

Performance

+

Performance

As chains have strict PoV size limits, care must be taken in the PoV impact of the session manager. Appropriate benchmarking and tests should ensure that conservative limits are placed on the number of Invulnerables and Candidates.

@@ -2134,7 +2220,7 @@ to compete in a bond-based election rather than a race to claim a Candidate spot

Compatibility

This RFC is compatible with the existing implementation and can be handled via upgrades and migration.

-

Prior Art and References

+

Prior Art and References

Written Discussions