A while has passed since I posted some initial ideas for a dynamic plasma solution. Since that time I have gained a better understanding of our network’s implementation and received feedback from the community on those ideas. Based on this I have revised the initial ideas, hopefully bringing us closer to a first version of dynamic plasma.
I will be referring to the initial dynamic plasma ideas as V1 and to the revised ideas as V2.
Problems with dynamic plasma V1
The plasma recharge concept
The main criticism for V1 has been towards the fused plasma recharge concept. The main arguments against it are the following:
-
Adds unnecessary complexity without bringing much benefit.
-
Bad UX for users, since the recharge rate is determined by the network and the user cannot affect it.
-
Not really needed to achieve the goals of dynamic plasma.
I think these arguments are reasonable and I think that at this stage a recharge mechanism is not necessary for dynamic plasma. If such a mechanism were to be included, we may be trying to solve problems that don’t exist. This is not to say that such a mechanism can’t be added later on, if there is a demonstrable need for it.
Balancing fused plasma and PoW plasma
In V1 I proposed that fused plasma and PoW plasma could be balanced by adjusting the DifficultyPerPlasma parameter, but this has some issues:
-
Conceptually, the
DifficultyPerPlasmaparameter determines the difficulty of plasma on the account chain level. Using this parameter to balance the usage of fused plasma and PoW plasma on the momentum ledger level messes with this concept. -
The value of
DifficultyPerPlasmais dependant on the used PoW algorithm. If we switch to another algorithm, like RandomX, then theDifficultyPerPlasmavalue will have to be adjusted. -
In order to be able to balance fused plasma and PoW plasma usage, the value of
DifficultyPerPlasmawill fluctuate, but when an account block is validated on the account chain level a hardcodedDifficultyPerPlasmavalue will have to be used. This will result in two separateDifficultyPerPlasmavalues - one for the account chains and one for the momentum ledger, which is not ideal.
Revised ideas for dynamic plasma (V2)
The main goals that this revised concept for dynamic plasma aims to achieve are the following:
-
Ensure that one resource (PoW or fusion) cannot be used to access all of the network’s resources in perpetuity.
-
Allow users to bid for account block confirmation via an auction mechanism.
-
Keep the design simple.
Balancing fused plasma and PoW plasma usage
To achieve the first goal, a pricing mechanism is introduced for the two plasma resources. This means that fused plasma and PoW plasma have their respective prices that are determined algorithmically by the network. The resource prices set a minimum price on fusion and PoW that an account block has to “pay” in order for the block to be eligible for inclusion in a momentum.
For example: A regular send account block requires 21,000 base plasma. If a user is generating the required plasma with PoW and the current price of PoW plasma is 1.25, then the minimum amount of PoW plasma required for the account block to be eligible for inclusion in the next momentum is 21,000 * 1.25 = 31,500 PoW plasma.
Example of the pricing algorithm for PoW plasma, when the PoW plasma usage target is 25% of the momentum’s maximum capacity:
| Momentum Height | PoW Plasma Usage | Next PoW Plasma Price | Price Change |
|---|---|---|---|
| 1 | 25% | 1 | 0% |
| 2 | 50% | 1.05 | 5% |
| 3 | 50% | 1.16 | 5% |
| 4 | 50% | 1.22 | 5% |
| 5 | 100% | 1.34 | 10% |
| 6 | 100% | 1.47 | 10% |
| 7 | 100% | 1.62 | 10% |
| 8 | 100% | 1.78 | 10% |
Example implementation of the algorithm that calculates the price of a plasma resource:
const MIN_RESOURCE_PRICE = 1
const MAX_PRICE_CHANGE_RATE = 0.1
const PRICE_CHANGE_DENOMINATOR = 20
function calculateResourcePrice(currentPrice, usedBasePlasma, targetBasePlasma) {
const changeRate = Math.min(((usedBasePlasma / targetBasePlasma - 1) / PRICE_CHANGE_DENOMINATOR), MAX_PRICE_CHANGE_RATE)
const newPrice = currentPrice * (1 + changeRate)
return newPrice >= MIN_RESOURCE_PRICE ? newPrice : MIN_RESOURCE_PRICE
}
PoW base plasma & fused base plasma
Base plasma is an abstraction that represents computational resources. In order to balance how much of the network’s available computational resources can be used by PoW and fusion, there has to be a mechanism to associate PoW and fused plasma usage with base plasma. Currently there is no concept of fused base plasma or PoW base plasma on the network, so a mechanism to calculate a nominal base plasma value for the resources is needed.
Example of calculating nominal base plasma values for an account block:
function calculateNominalBasePlasma(block, fusionPrice, workPrice) {
const effectiveFusedPlasma = block.fusedPlasma / fusionPrice
const effectivePowPlasma = block.powPlasma / workPrice
const totalEffectivePlasma = effectiveFusedPlasma + effectivePowPlasma
const nominalFusedBasePlasma = effectiveFusedPlasma / totalEffectivePlasma * block.basePlasma
const nominalPowBasePlasma = effectivePowPlasma / totalEffectivePlasma * block.basePlasma
return [nominalFusedBasePlasma, nominalPowBasePlasma]
}
Note: The resource plasma values are divided with the resource’s price in order to calculate how much resource plasma is used without the mandatory plasma demanded by the resource’s price. If this is not done, then a discrepancy in resource prices will skew the amount of base plasma that is allotted to a resource.
Prioritization of account blocks
When a pillar determines which blocks to include in a momentum, it will use the following formula to calculate a priority value for an account block and sort the blocks according to this value. This allows users to bid for account block confirmation when the network is congested:
const priority = (block.fusedPlasma / currentFusionPrice + block.powPlasma / currentWorkPrice) / block.basePlasma
A pillar still has the ability to leave out blocks from a momentum at its discretion, but the network will only consider a momentum valid if all the included account blocks pay the minimum required fusion and work prices.
Note: The maximum priority an account block can have is the priority of the oldest uncommitted account block in the account chain. This is because if there are multiple uncommitted account blocks in an account chain, the sequential ordering of the blocks must be preserved.
Embedded account blocks
Currently embedded account blocks have infinite plasma. Because of this I think it is easiest to leave embedded blocks unaffected by dynamic plasma. This means that embedded account blocks will always be included in a momentum up to a hard limit (that should not every be reached under normal conditions).
The extra resources needed to process embedded account blocks are already paid for by the user blocks that send the commands to the embedded contracts.
Estimating plasma fees
In V1 I proposed the usage of an Ethereum style algorithmic base fee mechanism (EIP-1559). This mechanism can be used with the revised version as well, but it is not mandatory. The benefits of this mechanism have been discussed in the V1 thread.
If the algorithmic fee estimation is not used, then we will need to create another way to estimate fees, such as using historic fee data, so that wallets can show users accurate fee estimates.
I’m in favor of the algorithmic base fee mechanism, since it simplifies fee estimation and relieves us from the burden of building a separate fee estimation mechanism into the node.
Dynamic plasma simulator
A simple simulator for dynamic plasma V2 can be found here: https://dynamic-plasma.netlify.app
The simulator can be used to simulate how the usage of fused plasma and PoW plasma affects the resource prices.
The simulator has the following configuration:
-
A momentum’s maximum allowed base plasma is 4,200,000 (200 regular account blocks)
-
The fused base plasma usage target is 25% of the maximum base plasma (1,050,000 plasma / 50 regular account blocks)
-
The PoW base plasma usage target is 25% of the maximum base plasma (1,050,000 plasma / 50 regular account blocks)
This configuration allows for algorithmic fee estimation, since the combined usage target of fused base plasma and PoW base plasma is 50% of the maximum allowed base plasma.
Open items
PoW and fusion usage targets
What PoW and fusion usage targets are reasonable? Right now it’s clear that only a small amount of transactions are sent with PoW plasma, which would suggest that the PoW usage target could be relatively small. But using a small target for PoW plasma means that fused plasma becomes cheaper to use, which may not be desired when the network’s throughput is saturated.
An equal split between the plasma types is arguably the most fair and unopinionated choice since ultimately we don’t have data that would show how the plasma types are utilized in a congested network. The usage patterns may be very different compared to a nearly empty chain. But I’d like to hear if there are other viewpoints.
Integer vs floating point math
The calculations used in the simulator rely on floating point math but it might be a good idea to try to avoid floating point math in favor of integer math to avoid potential rounding issues.
