Ideas for dynamic plasma

Development
41

Assuming we exclude plasma generated by PoW (for simplicity), is it accurate to say the following:

WITHOUT a recharge mechanism, the amount of $qsr owned by a user represents their prorata share of network throughput at all times.

WITH a recharge mechanism, the amount of $qsr owned by a user represents their prorata share of network throughput at a point in time based on network conditions?

I’m just trying to frame the issue so people who are not following the technical details can understand the specific issue we are discussing.

Also, I do want to point out that KASPA was attacked with a dust attack that caused the chain to bloat. They ended up “censoring” valid transactions that they classified as “spam”. However, before applying a patch, their chain was bloated with many GB of data. From what I can remember, the miners attacked the chain with the hopes of increasing fees, but I’m not 100% sure of that.

42

The QSR has to be fused as plasma but yes that would be a highly simplified way of presenting it.

The statement is misleading in my opinion though, since if you’re talking about throughput share per momentum, then without adding additional complexity, you cannot guarantee that in a highly utilized network people with low amounts of fused plasma will ever get their share of bandwidth, since a momentum can only accommodate so many transactions.

So maybe the statement is true in theory, but it’s inaccurate in practice.

I think that’s pretty accurate.

1 Like
43

Let’s assume there’s no transaction cap, allowing nodes to add transactions to a momentum until it reaches the size or time limit.

Now, if someone saturates a momentum with 100K QSR worth of plasma, due to the global dynamic plasma variable multiplier, saturating the next momentum will cost them 200K QSR of plasma. The subsequent cost will double with each saturation attempt. (Note: The numbers used are just placeholders and don’t necessarily need to be exponential either.)

For the attacker, it’s a losing battle, but for the average user, the impact might not be very noticeable.

Consider a user with only 5% of the maximum 5000 fusion units available for an account. This gives them 250 fusion units, providing 525,000 plasma to work with.

Assuming the transaction is 200B at nil dynamic multipliers, it should cost 34,600 plasma. At this rate, the user could make 15 transactions to a Momentum if desired.

However, when the attacker starts saturating, our user can now only add 7.5 transactions, then the next 3.75, and so on. For light to medium user this would be hardly noticeable considering a Momentum occurs every 10 seconds.

An exponential multiplier simplifies the example, but one could use an equation to create a J curve or something along those lines.

This system seems very flexible, performing it’s purpose whether the network has 5K tps or 500K tps. While it makes sense to me, there might be potential logical errors that need consideration though.

Nano, for instance, addresses this issue through ledger pruning.
I believe our advantage lies in the MetaDag. While I’m not certain, if I were to guess, I’d say this design decision is partly intended to address that problem.

Sentinels are highly incentivized, particularly as the ZNN and QSR values, compared to BTC, increase substantially. I estimate that in the future, there will be up to thousands of trustless Sentinel nodes and potentially many millions of trusted Sentry nodes that sync very rapidly with zk-proofs.

1 Like
44

The meta-DAG should be garbage collected as per the Narwhal and Tusk paper. The block-lattice can be also pruned, but I think what matters is the PoW accumulation that enforces the canonical ledger.

The cost of spawning a Sentinel node is 5000 ZNN and 50k QSR. Hundreds of Sentinels is more accurate given the current circulating supply.

1 Like
45

Ah, that makes sense. I had a hard time understanding why we should have PoW links adding weight, to be honest, but as I read that, it clicked for me.

Yeah, I realized that after I posted it too and thought I’d edit it, but then I thought maybe it would not be unreasonable to change the Sentinel requirements once the network reaches certain milestones.
For example, if the combined value of ZNN and QSR has gone up by a factor of 1000 from where it is now, it may be possible through governance to reduce the Sentinel requirements by a factor of 10, or something along those lines.

1 Like
46

I might have been a bit off with this statement in a previous post.

To transition from QSR to plasma, one needs to go through two conversions: QSR to Fusion units and then Fusion units to Plasma.

For instance, let’s say somebody has QSR representing 0.00002% of the total throughput, according to the circulating supply of QSR. The threshold to transact, due to dynamic plasma, at a given moment may be 0.000025%. In such a case, that user would need to complete additional PoW for a node to accept their transaction.

This two-step conversion process is quite cool, as I just realized, especially in the context of QSR price increases. One can adjust the conversion rate of QSR to Fusion units without compromising the conversion ratio of Fusion units to Plasma. This feature is quite brilliant and could allow for dynamic QSR plasma cost as well, especially if we had BTC as a currency that could be queried on the network.

1 Like
47

For plasma requirements to stay relatively low, a simplified mechanism like this requires +1k TPS though, right?

It will take us quite some time to implement all the things you’re talking about. I’m more concerned about how we’re going to prevent spam attacks from crippling our network in the meantime.

I think something like this would be needed so that the amount of sentinels continues to grow with the network.

Yeah we will probably have to consider this at some point. If we want to support a userbase of millions of people, then the current QSR to plasma conversion ratio is too low, since there simply isn’t enough QSR for such a userbase.

48

Yes, I think it would make for a miserable experience if it were 10 TPS.

Removing that transaction cap is a necessity for Dynamic Plasma. I have been trying to figure out what size Momentums are, and I can’t find any info on it.

I searched the Telegram chat for “Momentum size,” and it shows only 8 messages, with one of them being Mr. Kaine saying that a Momentum will have a hard cap. He does not elaborate on whether that will be a hard cap of plasma or megabytes. I’m assuming it is megabytes; that makes more sense to me, but I could be wrong.

This is a mental model that I’m working with at the moment, and it could be inaccurate:

TPS is mostly limited by what nodes can process, i.e., their hardware and bandwidth. They handle the account blocks.

To be able to keep the transactional ledger lean, they really only need to keep track of account frontiers and can disregard accounts with no balance.

Pillars, using the metaDag, can abstract a transaction’s size and cement it. I think you could make a momentum size hard cap of something like 3MB and be able to fit hundreds of thousands of transactions in one. Over 10 years, the DAG would only be around 120 GB.

That’s pretty extraordinary if that is somewhat in the ballpark of accuracy.

1 Like
49

The momentum has to store the headers of the transactions that are included and those make up most of the momentum’s size. I tested that a header is 66 bytes, meaning that a momentum with 100 transactions is roughly 6,600 bytes. So with a limit of 3 MB, this would mean that a momentum could roughly store 45,450 headers, if we’re only accounting for the headers.

But I don’t understand why a megabyte limit would be superior to a plasma limit, since plasma is an abstracted representation of storage and computational complexity, both of which should be taken into account.

The size of a basic account block appears to be around 420 bytes, which is over double than what I estimated earlier.

I’m not sure how you arrived at this figure. If the network is maxed out all the time and if one momentum is 3 MB, then that would mean 25,920 MB per day (8,640 momentums per day) and 94.6 TB in ten years. And that’s only the consensus ledger.

1 Like
50

Wow, I messed up that calculation; it seemed like a really low number. :sweat_smile:

Thanks for correcting that. The 66 bytes for a header is interesting. Suppose we wanted to target maybe 5,000 transactions per Momentum; that would be 0.33 MB. If that was the hard cap… let me do the numbers correctly this time.

0.33 MB per Momentum = 1.98 MB a minute = 118.8 MB an hour = 2.85 GB a day = 1.04 TB a year.

That still seems like a lot (even though assuming 100% Momentum utilization inflates the number by a lot), Dynamic plasma prevents the Momentums from filling consistently.

I’m not sure what would be a reasonable estimate for average Momentum utilization over a year, maybe 40% - 70%?

1 Like
51

Yes, perhaps Plasma works better for the hard cap. Thinking about it that way, it does have advantages. Interesting.

*edit: Maybe the computational cost is already accounted for because embedded transactions have the plasma multipliers in place.

2 Likes
52

To some degree if we can implement a fee now I dont see why we couldnt implement one later if true feeless network is not feasible. we have no daaps… we have nothing to worry about WRT tps and spam right now. I would think we do simplest thing to keep us moving forward (dynamic plasma) and as the platform organically grows we periodically / collectively assess if fees are needed or if we can solve any issues with other means. to me, saying lets slap a fee in our network at this stage seems premature

6 Likes
53

To be clear, I am not a dev but I do understand there are ripple effects to every decision, and this is a pretty big decision - so take this as an uniformed thought on the subject (also remember many pillar owners are not technical so they may be thinking the same thing). I enjoy reading this thread and will continue to follow along. Not 100% opposed to a fee at some point for the benefit of the network but struggling to see why we have to decide on it / implement it now.

1 Like
54

Whatever solution we agree on we should do it quick if we dont want to skip yet another bull run to get some real adoption

2 Likes
55

There is and there will be no real adoption. I agree on the first take though.

56

In regards to the facet of the discussion that pertains to fees being familiar and simple for end users: App developers, wallets, dexs, etc have the option to use feeless PoW/PoS plasma on the backend, while charging fees to the end user, in ZNN or any currency of their choosing. Savvy developers who intend to reach retail will choose to accept fees in the currencies that are most convenient for retail.

If owning QSR equates to owning a stake in network capacity, initiatives that charge fees in other currencies will drive immense value into NoM. Requiring users to pay for services and usage in a specific native currencies such as ETH, ZNN, etc is never going to be the way that this technology goes mainstream, because the mainstream masses use fiat currencies.

See the way brands like Nike are onboarding customers to ETH NFTs, by accepting credit card payments.

Every time a normie buys an NFT with a credit card, more value moves into the cryptosphere. That value may very well move back out when the developer buys a lambo, but the point is that fiat onramps and offramps integrate crypto into the global economy.

Thus, with PoW and QSR based plasma, NoM developers have the freedom to accept payments in any currency they so desire. (See: Gravity Wallet concept.)

57

Is there a way that…

  1. A wallet with zero plasma broadcasts a transaction to a receiving address.
  2. The receiving address looks at the transaction and decides if it fits certain criteria.
  3. If so, the receiving address fuses plasma for the sender.
58

I think this could be possible, like a plasma rental application. You send 10 ZNN to the address, and the application fuses plasma for 2 months, for example.

This wouldn’t be done trustlessly by the network though unless you had an embedded contract that could facilitate it, but one could create an trusted application to do it.

59

Here is an interesting conversations about SOL fees and MEV. It’s a little boring and only somewhat related.

60

This is another discussion of fee markets. It’s a little more related to our discussion here.

One take away for me is these fee discussions on other L1s take years to address and seem to be contentious.

1 Like