Ideas for dynamic plasma

[vilkris]

First off, thanks for taking the time to look at the formulas. I appreciate it.

@Nostromo

I believe the issue is that, for scaling, the Plasma table needs to be removed, and the definition of plasma needs to correlate with network resources. Having a plasma table with relational constants is very inflexible.

I’m not sure I understand what you mean with “plasma needs to correlate with network resources”, since I think that’s what it does already. As I explained in the initial post, one purpose of plasma is to represent computational resources, and that’s essentially the purpose of the plasma table. The values in the table represent the computational cost of the operation in question. The required amount of computational resources for a given operation should always be the same, so I don’t see why the values can’t be constants.

We only have embedded smart contracts on our base layer, meaning that we should be able to define the plasma requirements as known values. In Ethereum for example, the gas requirements for smart contract operations are calculated based on conversion rates of low-level-computer-operations-to-gas.

Both use hard coded “tables” but ours is highly simplified compared to Ethereum.

The Plasma Base Price formula is essentially the same algorithm that Ethereum uses for the same purpose (EIP-1559).

@Nostromo

We should define plasma, for instance, like satoshi/vbyte for storage and wei/computation. This way, we can determine the real cost of a transaction and represent it in plasma. Then, you might be able to simplify the formulas a bit. I haven’t given it as much thought as you, so perhaps the formula works as is with a plasma/byte-esque definition.

The plasma/resource conversions in our codebase mimic those of Ethereum. For extra data in account blocks we have the following definition: ABByteDataPlasma = 68, which means that every extra byte in an account block costs 68 plasma. The account block base plasma, which is 21,000 plasma, already covers the data/storage cost of a vanilla account block that has no extra data, which is again similar to Ethereum.

So based on this I think the requirement to represent the real cost of a transaction in plasma, is already fulfilled in that sense.

@Nostromo

I wonder about the “c” value: the base price change denominator. How is this one determined?

When targeting half full momentums and when c=8, the maximum base price change between momentums can be +/-12.5%. The bigger the c value is, the smaller the maximum change can be between momentums. The reason I chose 8 is because that is what Ethereum uses and apparently it has worked well for them. Again, the Base Price formula is basically the same as Ethereum’s.

Also, based on the simulations I’ve done, it appears to provide a decent balance between spam mitigation and UX.

@Nostromo

Regarding having a plasma ceiling per momentum (I assume that is what your plasma target of momentum is for?) and nodes, my vote would be with the recommended requirements the developers of Alphanet outlined in the official wiki. We could define a plasma ceiling from there.

Yes, the per momentum base plasma cap is a hard ceiling. Those recommended requirements are not enough to run a public node currently. To run a public node smoothly you need at least 32GB of RAM and more than 4 cores on a dedicated server. Like I said in my previous post, we have issues with the node and our current bottleneck appears to be the P2P layer. In a local network the recommended requirements should be more than enough though.

These node issues are obviously something we need to sort out before we can start considering any significant increase in throughput limits.

The throughput limits can be increased later on, and this is why I previously said that in my opinion increasing throughput isn’t necessarily a high priority right now, taking into account that there is no demand for it. That doesn’t mean that the design decisions we make now shouldn’t carefully take into account how they affect performance and scalability.