I couldn’t find another place where Dynamic plasma has been discussed and I know @georgezgeorgez is looking into it, so I created this topic.
@georgezgeorgez, which one of the following approaches do you think would be best?
- an overall network difficulty
- individual difficulty for each account-chain
- a combination of both
I would go with the third option, a combination of both. At the moment we have network-wide hardcoded values.
Transactions happen at account-chain level (block-lattice), while momentums “sync” the dual-ledger.
so “difficulty” has historically referred to PoW requirements
we need a per momentum plasma cap
and then the ability for users to specify an amount of plasma for a tx which gets refunded upon confirmation
there is a plasma cap per account
that all works without pow
what is also needed is a conversion between pow and plasma (the balancing of pow and pos)
there isn’t really an obvious natural balancing mechanism
unless we create a separate lane for pow txs
e.g pow competes for X% amount of network bandwidth
i’m not sure what adjusting difficulty on a per account chain basis achieves
i have some ideas of using sentinel pow to gauge the pow → plasma calculation
but pow plasma will be asic resistant randomX while sentinel pow may make sense to go with sha256 for merge mining infrastructure
What is the reason for a per momentum plasma cap?
So the use would send more plasma than necessary and the plasma that is not consume would be refunded?
Is this a cap for the total amount of plasma an account would be able to hold or a plasma cap on the amount of plasma an account would be able to consume?
There is a mechanism that converts PoW to plasma already. So we could simply adjust the ratio of plasma for PoW and/or change the PoW algorithm.
The PoW to plasma conversion ratio could serve as a control mechanism, so we’d adjust it based on network congestion.
It could be used to rate limit accountchains transaction rate to prevent spamming. We could combine this with a way to limit accountchain creation by forcing every new (with height == 0) accounchain’s first block (height == 1) to be a RECEIVE transaction, this way they would first need to receive something from another address. This way, in case there’s a spam attack, the attacker is also limited from creating countless accountchains, since the attacker’s previous accountchains are also limited.
I don’t understand why or how sentinels would be doing PoW. I was thinking we could use sentinels as oracles instead.
Isn’t the point of dynamic plasma to protect the network against spamming while in case of high usage still allowing transactions to happen in a feeless way (PoW or Fuse QSR).
If we’d eliminate PoW altogether, it would become increasingly difficult to onboard new members who’d need to Fuse QSR in order to make any transactions during high usage. And to Fuse QSR they’d still need to make at least 2 transactions with PoW first.
Here are some posts from Kaine that might be helpful.
1 Like
Made an attempt at completing the initial instructions provided by Mr. Kaine.
The result makes sense and provides an easy and efficient direction for implementation of dynamic plasma:
-
[When producing a momentum, pillars should] order txs sorted [descending] by [the amount of] plasma [used. So that transactions with higher plasma are included first. If the maximum amount of transactions that can be included in the produced momentum is reached, the remaining transactions should remain in the mempool until eventually they are able to be included in a momentum, which would happen when the network usage lowers.]
-
replace the PoW algo with RandomX [which is ASIC-resistant, in order to prevent the network from being spammed by an actor with access to an ASIC]
-
find a way to balance PoW and QSR fusing [so both can be used when creating transactions in order to maintain the feeless properties of the network]
0x provided some responses already.
Why a per momentum cap?
Network growth needs to be bounded to ensure accessibility of full nodes / decentralization. Plasma is a measure of computational resource utilization. A consistent load is efficient and ensures nodes won’t crash. Technology improves over time so we probably can account for that by making the cap subject to governance. Long term some sort of benchmark oracle to target a certain level of consumer hardware.
The plasma cap already exists. Your account gets plasma based on QSR fused. Fusing anymore than 5000 QSR doesn’t do anything. All of the plasma associated with a tx is returned once the tx is confirmed.
Sentinels have been described as the public backbone of the network creating pow links and acting as oracles. Sentinels creating pow links have been described since the whitepaper. Incentivizing pow links incentivizes running a public node which is necessary for tx relay and IBD. It requires some thought to understand why.
Requiring the first tx be a receive on any account chain is not a good idea. Privacy is a big part of the appeal of PoW. Single use addresses have a role. And getting initial funds from an embedded contract, e.g htlc/ptlc require a contract send to start.
Who/what is going to set the pow → plasma rate?
A centralized admin? It should be algorithmic.
And again hardware gets better over time.
1 Like
It’s those responses that I’ve used to write my last message:
Does what I’ve described seem right to you?
What would stop us from adjusting this limit?
You’re right.
Is it because being a public node allows (for example) embedded nodes to connect to them → and when a user sends a transaction they would be first to see that new transaction, → then add a PoW-link to that transaction in order to prove they’ve seen it first → and later on get rewarded based on the amount of PoW they contributed to the chain?
Like you said, It should be algorithmic.
Not necessarily from the start, we could hardcode a rate after running some benchmarks.
Plasma requirements will be higher when the network usage will be higher, so more PoW will also be required.
Once there’s need for an algorithmically adjusted PoW to Plasma rate, it will be implemented.
Yeah your description is good.
The 5000 QSR is a hardcoded limit. There’s nothing stopping us from changing it.
But without a max, it means that people with the most QSR can be guaranteed throughput in every momentum, possibly crowding out everyone else
For the PoW links, yes 
Both the “pow” and the “link” part are very important.
We will have a minimum number of links required, e.g 3
As you said, it means that they will be the public backbone to try to and make themselves available for ephemeral clients such as embedded nodes to be the first to receive a tx
But also because of the minimum links, after they make a pow link on a tx, they are incentived to quickly send it to all other public nodes in the network
(this is critical once the network implements virtual voting)
ephemeral nodes are likely to send their initiated txs to all their peers
the pow is important because creates a criteria for double spend filtering and also it prevents sentinels from hoarding txs
if someone owns multiple sentinels and a pillar, without pow they are incentivized to hoard txs they see first, do all the pow links quickly internally, and then send it to their pillar if it has an upcoming momentum
with pow, that person’s pow likely can’t compete with the pow of the entire network working on those txs
the best chance to get your pow links confirmed, is by sending it to everyone
2 Likes
I’m now starting to understand that we’re talking about different stages of the dynamic plasma mechanism.
You’re already thinking and planning for the version of dynamic plasma that accounts for the innovations in the whitepaper.
On the other hand, I’m considering the first steps we need take in that direction with an emphasis on moving away from the current state.
Current state
The state in which a rather small amount of spamming could potentially hinder network transactions.
Short-term improvements keep us afloat and the long-term vision moves us forward.
1 Like
Putting upper limits on anything plasma-related won’t work. It’d be like if Satoshi decided to put a cap on Bitcoin’s difficulty or on transaction fees to avoid crowding out everyone else.
We’re going to have to choose between the risk of potentially hindering the network due to either high “difficulty” or high spam.
Transaction ordering in momentums shouldn’t necessarily be enforced. The general algo will sort them descending by the amount of plasma included, but if pillars decided to alter the algo and sort transactions in their produced momentums some other way, they could.
If this were the case, pillars might employ some other ways for prioritizing transactions, like prioritizing transactions for their delegators.
2 Likes
There is a fundamental difference between PoW and QSR
PoW is an open system, PoS is not. One can bring additional external resources to compete for PoW.
In our current structure, it is impossible to enforce priority by plasma.
In the future, when we move to virtual voting, it will be enforced.
2 Likes
So there should be upper limits for plasma coming from either QSR fusing/PoW?
My thoughts exactly.
Indeed, the majority will need to order the transactions in the same way so they’ll have the same hash to vote on.
1 Like
Sharing link here written by @CryptoFish regarding the current implementation of PoW and Plasma. I will try to understand this.
2 Likes
@georgezgeorgez @sumamu @0x3639 let’s focus again on Dynamic Plasma. I’m already working on the extension chain and we’ll need a higher network throughput. At least we should remove the hardcoded cap.
1 Like
What needs to change with the structure to make priority by plasma realistic? Or are you just sort of conceding that this upgrade will be a significant change to the network?
@georgezgeorgez what would happen if we simply remove the cap with no additional changes? I assume it would not be a problem until we test the upper limits of the network… And then TXs would queue up and wait.
@aliencoder I read you are targeting Q2 / Q3 for the sidechain. Is it safe to assume you would prefer dynamic plasma to be in place by Sept 2023?
I don’t think that’s a good idea. It is not so simple.
We need dynamic plasma for sure.
But I also don’t see a hard dependency on it for extension chains.
4 Likes