Dynamic plasma discussions

Development
21

Yes. I’ll coordinate with you and help you get it done.

I agree. Anyway the ext-chain will be on devnet/testnet first.

1 Like
22

How can I help with this?

23

For the dynamic plasma implementation we’ll need a fairly good ASIC-resistant algorithm. Afaik MrK proposed RandomX - Proof of work algorithm based on random code execution.

I’ve done some research and arrived to the same conclusion: RandomX is the best option. I’ve also found a project that offers a Dart wrapper for it. I think it’s mandatory to have full support for every client from day 1.

1 Like
24

I used RandomX for a year to CPU mine some shitcoins. During that time I never had any issues with it.

1 Like
25

I’m out of my depth here, but these comments made me wonder if the rate should be related to bitcoin as an external reference point, in some way.

26

Isn’t the dynamic plasma made in order to avoid the network to clog by making computationally expensive transactions more plasma demanding than simpler ones? If that’s the case I don’t see why you would need to relate to Bitcoin or an admin in any way. It’s just a layer of adjustable difficulty with two markets: electricity and QSR.

1 Like
27

In the Dev Meeting #2 today, @MoonBaze proposed a solution to Dynamic Plasma. I will paste his ideas below. You can see the conversation starting here on Discord.

After thinking about it for a while, the question “How can we implement an anti spam mechanism?” transformed to “How can we make sure that a regular user can still make a transaction if the network is spammed?”. Implementation options that I considered were:

  1. Charging a fee for opening an account (so an attacker could not generate new addresses and spam from them). Every account would have a number of free (plasma / pow) transactions an epoch and after that they would have to pay for something like a slot of 200 (e.g) txs. So if someone wants to spam the network it would cost them.
    Cons: hard to implement, exchanges would have to pay, making it harder to integrate

  2. Changing the PoW algorithm with something like RandomX which is harder to brute force and sorting txs by their pow, but someone with some rented hardware could still keep the PoW to a level that is hard enough for a regular user, even half an hour of something makes the network unusable.
    [7:35 AM]

  3. Making the network feelessless . Removing plasma and pow, we would have something like ethereum but maybe qsr will decrease in value, we already are a feeless transaction.

  4. Having 3 as a seed, (this one I like the most and I already started playing with it), we could introduce optional fees. Think of a congested network with PoW / Plasma transactions by a malitios actor, one could send a transaction with some fee and have higher priority than him. The algorithm of sorting transcations in a momentum could have the following priority: embedded send, embedded receive, txs with fees, txs with total plasam, hash. In regular conditions no one has to pay but in a congested network you could and the attacker would just waste his resources. The fee level must be chosen to a level that if the attacker wants to spam the network with fees transactions it would still cost him (something like 200 base fee level will cost 1 znn)

What do you think? I already have implemented these fees and increased momentum by accountBlock sizes rathed than lenght. I tested with 1600 accBlocks per momentum already.

28

Please, before anyone responds to this proposal, please read the entire discussion here. We had an informative discussion and that will help the community understand the issues.

1 Like
29

The idea of introducing a fee seems like an interesting solution to overcome 100% network utilization. Over time the network could migrate to a fee model if block space is fully utilized like other chains. Is that good or bad?

My question is, does the original network architecture contemplate a transition like this. QSR was designed to launch Pillars and process TX. If QSR stops becoming fuel for the network, what does that do to the usefulness and value of QSR? It will change the dynamics of QSR in our network. We need to fully understand that impact.

Also, if we design a system with a fee but allow PoW / QSR to overcome the fee we now need to design a system that takes into account 3 variables: fee, PoW and Plasma.

In a separate conversation, @georgezgeorgez threw out the idea of using a fixed allocation for PoW. For example, 25%. So PoW would consume no more than 25% of network utilization (or block space?) and Plasma 75%. I’m regurgitating that idea to start the conversation here.

30

MoonBaze: I have read some of the ideas on the forum, using a plasma cap or something similar would just not work. An attacker would outPoW a regular user

I’d like to second bzed’s petition for a more granular and in-depth explanation of what you see as the shortcomings of the PoW+Plasma anti-spam mechanism envisioned by founding developers. Some of us can’t really offer implementation/technical solutions of workarounds for any specific problem, but we can certainly help play the role of a malicious actor / regular user and brainstorm alternative solutions not considered or fully explored.

Here are some thought-provoking arguments:

Attack Cost

From what I was able to understand, one of MoonBaze’s recurring arguments was making sure an attacker/spammer would suffer an economic loss. In a feeless network, where transactions only require a dynamic amount of PoW or Plasma, both have a cost associated to them. PoW = electricity for sha256 / computational resources for RandomX. Plasma, although reimbursed at a later point in the future, also has a significant cost. An attacker would need to buy QSR, and freeze the capital in order to generate Plasma. This is a significant cost that cannot be understimated at the scale of clogging the network. QSR is a volatile asset and it will be locked for a minimum period of time we can control, the price when the attacker is done spamming might have changed significantly, especially if he successfully breaks the network.

Additionally, there are other variables we can consider to deter a malicious actor, for instance:

  • QSR Min Lock-up time
  • accountBlock age / trust score (an account that has been a network participant for longer might require less resources to get a transaction through the mempool i.e good aliens get fast lane subscription)

Finally, I would like to mention that the goal is not to prevent network congestion but deterring a malicious actor from congesting the network.

31

I think one of his concerns was that it would be easy to spam the network with CPU / Plasma and overcome the ordering system we develop.

32

I don’t understand the need to have fee when the cost of sending a tx is here no matter the state of the network. What does it change ? If I want to attack a network with a dynamic plasma leveraging pow and QSR I rent pow ressources or and buy QSR. If you make it not feeless I buy enough to spam and that’s it. How it is economically harder to attack ? You don’t freeze you capital with QSR, you can dump it later and QSR price is relatively volatile, for now.

Beside the same argument can be directed toward the capital you’re trying to get your hand on through your attack: its price is unpredictable, especially if the attack is made public, and so the capacity of reimbursement of the electricity cost is a bet.

33

In my mind, CPU / PoW is just a fall-back mechanism so that new accounts don’t require to have fused Plasma in order to submit a transaction under normal conditions of available block space. If network is congested, PoW goes out the window as a meaningful way to transact on the network, plasma will be required.

As you said, all that matters in this situation, is the ordering system we develop. If I’m at account block 5k and you are a new account trying to spam the network and the Blockspace plasma threshold (gas price) to include a transaction in the block is 100 plasma. We will both submit a transaction with 100 plasma fused in, yet mine could be seen by the network as superior, let’s say by multiplying my account block with the fused plasma, effectively making my transaction have 500K fused plasma. Good luck matching that as an attacker.

This is just a crude idea, but we have options. That’s my point. QSR/Plasma is not a freebie resource.

1 Like
34

The times I’ve fused QSR, it locks the QSR for a min amount of time. Granted, a malicious actor could prepare an attack by fusing the QSR, then just waiting out the min lock time before unleashing the attack, but at least we’ll see it coming with on-chain analysis :joy:

2 Likes
35

Hard to say. A malicious actor could accumulate over weeks or even months and only fuse at random times and random amounts.

My point is that anything can be attacked but you got one too with the 500k plasma exemple.

“QSR/Plasma is not a freebie resource.” and as I said before, feeless is a marketing narrative. We already have fee.

1 Like
36

Going over Moons comments from today.

The thing is that not all account blocks use that much Data so we could use the remaining space to insert other account blocks. Rather than capping the momentum by 100 acc blocks, no matter the size, we could cap it by the maximum size a momentum has now 100 * (440 + 16384) / 440 ( size of a regular send block) could take us up to ~3800 regular send / receive account blocks per momentum

If someone wanted to spam the network with 3800 send/receive TXs constantly and each address had 100QSR that’s 380,000. That’s not much to fill the network. And if someone has 2m QSR to fuck with us they could allocated 526 qsr per address. That is an annoyingly large amount. that means users would need to fuse more then 526 to process a transaction.

But to Georges point, if we are successful forget spam, that will be the network usage. Blocks will be full. under this scenario, how do your get your TX processed if you don’t have 526 qsr?

37

Maybe TXs should be allocated a time of waiting. Sort of like a QSR multiplier. The longer a TX waits, the plasma multiplier goes up. That way if all TXs have 500 fused, someone trying to process a TX with 200 fused will eventually get processed.

2 Likes
38

That looks elegant

39

From chatGPT

Proposed System for Transaction Processing on Zenon Network:

  1. Priority Queue: Implement a priority queue for transactions. Transactions with higher PoW or more fused QSR get higher priority.
  2. Dynamic Thresholding: Set a dynamic threshold for PoW and QSR based on network usage. When network usage is high, increase the threshold, ensuring only high PoW or fused QSR transactions are processed.
  3. Hybrid Processing: For transactions that don’t meet the high threshold of PoW or fused QSR, allow them to combine both. For instance, a transaction with moderate PoW can be boosted with some QSR fusion to meet the threshold.
  4. Fallback Mechanism: In extreme network congestion, allow a fallback mechanism where a certain percentage of transactions are processed based purely on first-come-first-serve, ensuring that all users have a chance for their transactions to be processed.
  5. Feedback Loop: Continuously monitor the network and adjust the thresholds based on feedback. If transactions are getting delayed or the network is not congested, lower the thresholds.
  6. Client-Side Processing: Encourage clients to perform PoW or fuse QSR before sending transactions, especially during high network usage times. Provide clear guidelines and tools for clients to estimate the required PoW or QSR for quick transaction processing.

This system ensures that transactions with higher PoW or fused QSR are processed faster, maintaining the integrity and efficiency of the Zenon Network, especially during high usage times.

1 Like
40 
from queue import PriorityQueue

class Transaction:
    def __init__(self, pow_value, qsr_fused):
        self.pow_value = pow_value
        self.qsr_fused = qsr_fused

    def __lt__(self, other):
        return (self.pow_value + self.qsr_fused) > (other.pow_value + other.qsr_fused)

class ZenonNetwork:
    def __init__(self):
        self.transaction_queue = PriorityQueue()
        self.POW_THRESHOLD = 10  # Initial threshold for PoW
        self.QSR_THRESHOLD = 10  # Initial threshold for QSR fused

    def adjust_thresholds(self, network_usage):
        if network_usage > 80:  # High network usage
            self.POW_THRESHOLD += 5
            self.QSR_THRESHOLD += 5
        elif network_usage < 30:  # Low network usage
            self.POW_THRESHOLD -= 5
            self.QSR_THRESHOLD -= 5

    def add_transaction(self, transaction):
        if transaction.pow_value >= self.POW_THRESHOLD or transaction.qsr_fused >= self.QSR_THRESHOLD:
            self.transaction_queue.put(transaction)
        elif transaction.pow_value + transaction.qsr_fused >= self.POW_THRESHOLD:
            self.transaction_queue.put(transaction)

    def process_transaction(self):
        if not self.transaction_queue.empty():
            return self.transaction_queue.get()
        else:
            return None

    def fallback_mechanism(self, transaction_list):
        # Process a percentage of transactions based on first-come-first-serve
        percentage_to_process = 0.1  # 10% as an example
        num_to_process = int(len(transaction_list) * percentage_to_process)
        for i in range(num_to_process):
            self.transaction_queue.put(transaction_list[i])

    def client_side_processing(self, transaction):
        # Encourage clients to perform PoW or fuse QSR
        if transaction.pow_value < self.POW_THRESHOLD and transaction.qsr_fused < self.QSR_THRESHOLD:
            print("Consider increasing PoW or fusing more QSR for faster processing.")
        else:
            self.add_transaction(transaction)
1 Like