Dynamic plasma development stages:
1 order txs (sorted by plasma)
2 replace the current PoW with RandomX
3 find a way to balance PoW and QSR fusing
Source: Telegram: Contact @zenonnetwork
The thing with any dynamic plasma + any PoW algorithm is that an adversary will always be able to accumulate some QSR for fuse and also very performant hardware to compute some hashes until the nonce is found. We must have the assumptions that the attacker could even be state level at some point and could have an insane amount of money and resources. Imagine we are in full bull market and someone spams the network, because they have a short or for every other reason, ( if we have fees it would be in our interest because they would buy a lot of ZNN to spam with fees ) then it would be unusable, just like it happened to Solana a lot of times. Even renting some CPU / GPU / ASIC for like 10k$ / month would be able to PoW to fill al the account block slots in a momentum and it’s not even that much money for an attack that lasts a month.
Adding this feature of optional fees would render this attack useless as any user could pay the base fee and frontrun the pow/fuse txs. As I said earlier, if the spam attack is with fees, it’s in our interest because they have to buy znn and they also burn them which creates deflation. As george pointed out, in a fully usable network, it could reach a point where anyone just pays the fee to be first. I don’t see a problem having fees here as it is much easier for a user to do something in order to be included. If the algorithm still required pow / plasma in that situation the user would have 2 options: 1) buy QSR (how? the network is congested) and he would have to fuse some more (how? the network is congested) 2) acquire some more processing power so one could compute the required PoW ( users just want to click and get it done, no one has time to do such things for a tx). Both options really seem impractical.
One could say, in order to pay fees you have to receive ZNN first and he would be correct but in practice not many actions happen on accounts with 0 ZNN, it’s only one receive rather than receive QSR and fuse QSR. Maybe we could create a feature so that the sender could pay the fee for the receiver and this issue is solved ( another option here would be to give receive blocks higher priority than sends but this creates an attack vector, I could explain in detail later).
Whether or not we become a network where all the users pay the fee for a tx it’s for the free market to decide. Personally I don’t think it would happend so often and even so, I don’t consider it is a bad thing.
Later edit: Think about the Bitcoin network with block mining and us having a PoW mechanism for txs. A regular user would have to race against all the processing power of the attacker. The point at which the waiting time would increase it’s up to the attacker’s money / resources. If we cap the time (like btc 10 min) it’s even worse as it gets easier for the attacker. He could maintain even an waiting time of 1 hour. It’s still a lot (now could be ok, because nothing happens but I don’t want this in the next bull). Fees fix this. Let him use 5 ZNN as fees for all the txs. I don’t mind
Thanks for the in-depth reply. I clearly see how a fee directly prevents an attack in the first place, as the malicious actor would consider the associated costs of the attack.
I just want to point out that we also have other tools at our disposal that Bitcoin and other networks don’t have. Namely, the governance module + AZ. Consider the points brought up by ChatGPT, particularly Dynamic Thresholding, Fallback Mechanism, Feedback loop, heck even Hybrid processing sounds like a good idea. George has brought up multiple times the idea of the network being able to edit variables through the governance module. Could we use this to our advantage by allowing us to change the “rules” of the game to mitigate an attack vector?
The best defense is not a solid codebase with no exploits/bugs, but our ability to remain flexible/agile to patch them and pivot while maintaining our Decentralization ethos. It has luckily worked out for Bitcoin so far, being a robust codebase that is very hard to change. But what would happen if someone cracks it? We’ll see Bitcoin 2.0 and it will be messy. I think we have better tooling than Bitcoin to remedy a crisis of that magnitude.
Imagine a situation where someone is attacking the network, make it state level if you want, North Korea wants aliens to stop transacting. They have unlimited resources and are smart, accumulated QSR for years (benefitting us temporarily. Again, QSR is not a freebie) and have unlimited hashing power. The attack commences, network is instantly congested, aliens panic, Zenonhub’s anti-spam bot detector goes off. Pillar submits a governance proposal to immediately ban offending addresses from the network. Even dormant pillars instantly vote yes. It’s a spork type emergency, so it activates in 24 hours instead of 2 weeks. How you ask? I have no clue, but maybe George added some extra fields in the governance schema to do just that. Instantly accounts are banned from the network and not allowed to even dump their QSR because nodes will not process the transactions from the blacklist.
Perhaps a little of a crazy idea and even completely stupid or impossible, but again, my goal here is to help us think outside the box. QSR is not a freebie. Slash his ass for spamming our network with plasma. And make plasma the determining transaction ordering factor over PoW if it’s already not the case, as technically it should be easier (and less benefitting to us) for an offender to rent hashing power than to buy QSR.
Edit: All of this relies on us being able to identify malicious activity. If that’s not a possibility, my whole premise falls apart.
georgezgeorgez —
There is no difference between an attacker and a normal user
From the perspective of the network
The network doesn’t know that it’s an attack, but will the humans behind the pillars be able to tell the difference?
1 Like
What you state is true for every crypto: with enough money one could attack Bitcoin, Ethereum, anything.
I like the fact of bringing in fees if you compare it to the BTC mempool. In the last couple of months we’ve experienced a significant rise in the use of blockspace and the increase in fees paid to be included in a block, mainly because of Ordinals. Even when increasing the fee, the network still depends on the settlement time of a new block.
A fast lane would ensure the user to be included, and just as in Web2 time equals money. I think we’re heading in the right direction if we’re going to discuss the option to include fees through a ZNN burn (maybe donate to the A-Z fund or simply burn the supply) in order to further utilize the network in case of a bull market and/or successful product.
I really appreciate the interest to find a solution.
Dynamic Thresholding, Fallback Mechanism, Feedback loop, heck even Hybrid processing sounds like a good idea. George has brought up multiple times the idea of the network being able to edit variables through the governance module
-
Dynamic Thresholding I said in my latest message why this won’t work
-
Fallback Mechanism, Feedback loop, heck even Hybrid processing these would require some determnistic processing which would make the attacker know what tx is going to be accepted based on some on chain seed. Randomness on chain is very hard to achieve
The best defense is not a solid codebase with no exploits/bugs, but our ability to remain flexible/agile to patch them and pivot while maintaining our Decentralization ethos.
This is very wrong in my opinion, the best defense are both. When they are building a huge tower they are not like “it doesn’t matter if it’s sketchy, we have the fire department nearby to intervene when it falls”
But what would happen if someone cracks it?
I don’t think that introducing a very powerful mechanism that would allow an user to send a tx even though the network is spammed cracks a network
Zenonhub’s anti-spam bot detector goes off. Pillar submits a governance proposal to immediately ban offending addresses from the network. Even dormant pillars instantly vote yes. It’s a spork type emergency, so it activates in 24 hours instead of 2 weeks
This is slashing / blacklisting which just won’t work because we have the freedom to create millions of addresses
There is no difference between an attacker and a normal user
From the perspective of the network
The network doesn’t know that it’s an attack, but will the humans behind the pillars be able to tell the difference?
That’s why this optional fees solution doesn’t care. It lets the regular user decide what to do in case of a spamming attack, not the network, not the pillars nor the governance module.
This is not true for every crypto. I don’t think anyone can out hash all bitcoin miners. We are talking about spamming attacks. They have no mechanism against it but no one does it because it costs the fees.
I was going back through TG looking at some of the guidance Kaine gave us.
From the beginning the core devs designed a network that is “feeless”. Kaine believes the architecture balances security, scalability and decentralization.
He also said:
I can perfectly understand how a fee will resolve the issue of sustained attack. But I cannot help but think adding a fee will disrupt the architecture of the network. The value / utility of QSR is to launch Pillars and process transactions. If we are under attack or the network is fully utilized, users will pay a fee and the utility of QSR will change. What does that do to the architecture?
Kaine references a difficulty adjustment mechanism like BTC. He also references ordering TXs by plasma and balancing PoW and QSR fusing. I cannot find anywhere where he references fees. But I just view this as guidance, not direction.
Why not create a system of lanes?
Lane 1 = PoW
Lane 2 = QSR Fused
Lane 3 = Fast lane
The width of the lanes can adjust, like the BTC difficulty adjustment. The sum of the width of lanes = total throughput.
During low bandwidth, lanes adjust so that all throughput is utilized - meaning if the PoW lane is full (congested) but the QSR lane is not, the QSR lane gets narrower and the PoW lane gets wider. This happens until both lanes are full.
By changing to RandomX, it could be harder and irritating to attack the network b/ you need a bunch of CPUs. And you cannot point ASICs at it.
When both lanes are full and TXs are getting delayed I think we have a few options:
- Add PoW + Fused QSR to determine order - meaning a user can do both
- Add a time based multiplier to the PoW + Fused QSR weight. The longer someone waits, the larger the multiplier becomes. Meaning if I fuse 100QSR at Time1 and you fuse 200QSR at Time5 eventually my 100QSR weight will be larger than the 200QSR weight and the TX will get processed.
By adding a time multiplier to the fuse / pow weight eventually the TXs will get processed. TXs will get processed even if under attack or network utilization is full.
Do we need a fee if we can design the system to process all TXs? Will someone spam the network endlessly for no benefit knowing all TXs will get processed. Maybe the fast lane is based on fused QSR - some larger amount. So if you fuse X QSR you are put into the fast lane automatically and have access to first come first serve. The width of the fast lane adjusts with the balancing algo so lane width of fast / QSR / PoW all move together.
Believe it or not, chatGPT is pretty good at helping think through some of these issues.
1 Like
I read a lot about fast lane but it mostly look like a bumped fee level. What stop an attacker to pay millions and spam the fast lane ? A highway can be crowded.
The most elegant option I’ve seen so far is adding a T variable so a user’s tx plasma weight increases with time no matter what the network state is and will be confirmed at some point.
The fast lane idea is just a fee market and fee markets can be congested and push regular users out. Do we want to offer yet another L1 where in case of success we all rush the fast lane for a 10$ per tx because even there it’s congested? Moonbaze assuming a user wouldn’t just sit and wait for 1 or 2 minutes for a tx to confirm is just what it is: an assumption.
Every kind of attack has a cost. Adding another layer of fee and branding it as fast lane just move the cost elsewhere and does not seem to solve much.
Im not seeing where we do need to add the third lane using fees. Aquiring QSR or dedicated hardware is a real cost and in a dynamic system that can raise/lower the required Plasma and/or PoW over time based on usage, it would add up to be a significant one.
Then the ability to balance between the two lanes and some sort of time weighted multiplier to push txs thru should give the flexibility to maintain a usable network during high usage or coordinated spam.
1 Like
How does networks like visa and MasterCard deal with spamming?
Acquirer networks and merchant accreditation
1 Like
Ya, users cannot spam. they will be blocked immediately and removed from the network.
1 Like
Dust attack on KAS. Their fees are very low. Apparently it’s costing a few cents a day to attack the network causing hard drive usage to grow quickly.
1 Like
Here is their solution
The basic idea is to require that transactions charge fees if they have “excess” outputs: if a transaction has k inputs and n outputs where n>k, it must pay a fee of n-k kaspa. However, since typical transactions have one input and two outputs (due to the change address), applying this rule directly will greatly increase fees paid by ordinary users. We avoid this by allowing transactions with at most two excess outputs that are not paying the increased fees, but only allowing one such transaction per block . To avoid a DoS attack where an adversary spams the network with such transactions, preventing honest transactions from being chosen, we always choose the transaction whose latest input is the earliest . Additionally, we still want to allow mining pools to pay block rewards to many users. We achieve this by exempting transactions from the increased fees if at least one of their inputs is a coinbase UTXO. A transaction that is currently accepted will be henceforth denied if the following three conditions hold
- It has k inputs and n outputs, with n-k>2
- The fee paid the transaction is less than n-k Kaspa
- None of the inputs to the transaction are coinbase UTXOs
In particular, any application that creates transaction of this form will have to either refactor the compounding of transactions or increase the fee.
2 Likes
Reflecting on our convo in the dev meeting, how do we create a feeless ordering system that does not differentiate between spam and real traffic? We only consider valid transactions.
KAS is getting dust attacked for a few cents a day. Maybe the attackers are short KAS and want to crash the network. Who knows. Looks like KAS is preventing the attack by keeping fees low for one “honest” tx per block and they are processing txs on a first in first out order. They are on a utxo model so they are using the number of inputs vs outputs to help classify “honest” transactions. They seem to be removing miners from this classification. The network now charges larger fees to txs that don’t meet the “honest” category.
We face the same issue, only we have two ways to process txs (PoW and fused qsr). We are not utxo so we cannot track inputs vs outputs to classify “honest” transactions. Also, kas mentions the risk of running out of HD space to keep all the spam txs.
Ideas for NoM:
- Can QSR fuse duration impact the ordering of txs? Meaning if you agree to fuse longer, does that increase the fuse weight?
- Adjustable lane width for PoW / QSR will help prevent PoW overcoming the network, but that will not prevent a PoW attack from inundating PoW txs and slowing them way down.
- first in first out weighting should help honest txs get processed.
- can we implement a “fast lane” with higher fused QSR rather than paying a fee. This can be a governance variable set by voting.
- Can we limit the PoW per tx so that each tx requires a CPU? This could make a PoW attack much harder. No idea if this is possible.
A problem that RandomX introduces is that it makes browser-only onboarding into zenon infeasible, since it’s not viable to compute RandomX in a browser environment: RandomX/README.md at master · tevador/RandomX · GitHub
This means that any browser based wallet will need to have a dependency to an additional “pow-generator” program running locally, or external pow-as-a-service or plasma-as-a-service infrastructure, which can complicate the onboarding experience.
2 Likes
In the current architecture I don’t think that transaction PoW secures the block-lattice ledger by adding weight. It is used only if you don’t have enough plasma.
What does that do to the architecture?
We will just have optional fees, nothing is changed.
Lane 1 = PoW
Lane 2 = QSR Fused
Lane 3 = Fast lane
This priority changes nothing as the network can still be attacked by PoW.
Add a time based multiplier to the PoW + Fused QSR weight. The longer someone waits, the larger the multiplier becomes. Meaning if I fuse 100QSR at Time1 and you fuse 200QSR at Time5 eventually my 100QSR weight will be larger than the 200QSR weight and the TX will get processed.
This actually creates an even easier attack vector. I can just spam the network with txs with a relatively low pasma / pow and in time they could all magnify. Basically we just add a delay.
I think chadass is just trolling.
We cannot have dust attack if we choose the base fee optimal. I though of 1 ZNN / 200. Which is 200 txs with base fee to reach 1 ZNN. If we also increase the capacity of momentums then it just won’t be feaseble economically. Or if they do it won’t last long and it will help all holders by buying a lot and burning a lot.
I think that we do not have the man power to build such a complex algorithm as dynamic pow that would work perfectly, having into consideration everything nor do we have the time / money until the next bull market. Optional fees is just easier and a more elegant solution to implement and I repeat, the problem it solves it’s not only “How to protect the network from spam attack” but also “How could a regular user use the network in case of a spam attack”.