Shorthand
Discussion participants: Makoto Takemiya, Andrei Lebedev, Nikita Puzankov
neI also don’t think rejected transactions should be in a block. Is there a good reason to have them there?
Otherwise it is possible to replay a rejected transaction, and it may be committed, e.g. when someone got enough assets after some time if there were no assets when the transaction was initially rejected
I didn't catch that
I see
Unfortunately it also has the problem of filling up the blockchain
Potentially for free
If this was in bitcoin, for instance, one person could add petabytes of transactions for free and no one would be able to use it. Sora faces this potential problem
I wonder how this problem is solved in other networks. Because your concern is valid, and it should be already solved somehow.
I think it isn’t solved. I think if something is replayed, you can just pay twice (assuming you created a new transaction).
In another blockchain project we had a timestamp with each transaction and there’s a threshold required. I forget the number, but if a transaction was, say, 3 hours old, it would be ignored.
I think we can do this in Iroha2. I haven’t said all my plans yet, but I want to incorporate something like a network time service, like the other blockchain project had.
The same thing is also present in Iroha. But it is quite possible to do this spending attack in a short timeframe.
That way nodes can try to reject transactions that are outside the time. Sure, but it is not our problem, but the sender’s :)
that what I was talking about with concept of TTL for tx processing
What do you mean?
Like a usual packets on internet - Time to Live
Yes, For example, it could be like 10 minutes or something configurable. I think this is the best way.
TL;DR
To prevent transactions "spamming" (with transactions that will be rejected by validation, but accepted and stored in queue before for some period of time) we may introduce Transactions Time to Live and clean up queue when this time comes.
12 Comments
Vadim Reutskiy
The proposal from Iurii is that the client needs to have the possibility to send proposed TTL with each transaction.
In case of the transaction was not added to the block in the proposed TTL period, it should be discarded.
Nikita Puzankov
I think we can work with it, but we will make a restriction that proposed TTL is less or equal to the system TTL, is it okay Iurii Vinogradov?
Makoto Takemiya
One other thing to remember, and Vadim should also know this from his work on Byacco, is that for some use cases (particularly that have tx fees), it is desirable to store failed transactions because you have to display these to the user in a mobile app. It is very confusing to users if you send a tx, but then it doesn't appear or disappears from your tx history.
Ethereum solves this by happily taking the tx fee from failed transactions and then storing the tx in the blockchain forever. For Sora and Byacco, where there are tx fees, this makes sense and is required by many applications. For use cases with no tx fees, then it is maybe not an acceptable solution because then one person can fill up a blockchain for free, which is something that should never happen (but maybe rate-limiting can be some solution for this).
Nikita Puzankov
Based on your stories behavior depends on the application layer logic and maybe too high level for Iroha? We had an assumption that we don't need to store rejected transactions in Iroha 2.0 or we now should consider possibility to store them?
Makoto Takemiya
Unfortunately we should store them I think, after I talked to mobile app devs. However, only for txs that have been able to pay the tx fee successfully.
Egor Ivkov
I don't think we have a concept of a tx fee now in Iroha2, is it something that should be introduced? Or maybe it can be left to the app developers, I guess they can do it with ISI events.
Nikita Puzankov
Makoto Takemiya - can you add them to this RFC and we will discuss details?
Nikita Puzankov
So why do we need them here and why problem is more complex than it seems.
TL;DR - we work a lot with raw requirements on the early stages of our project, keeping and growing technical dept, playing with design and refactoring. Right now it's phase when we need very detailed requirements and very well-targeted design decisions based on them.
Egor Ivkov
Also if we store rejected tx what about the transactions that were dropped because of TTL. Should they also be stored? From what I understand, it is better not to store them, as the whole point of the TTL was to prevent spamming, so in this case I guess it is better to simply drop them.
Egor Ivkov
This way we will only store the rejected transactions that did not pass stateful validation.
Vipin Bharathan
The challenge of writing user friendly apps in most blockchains (for example) seem to be very real. The happy path when transactions are fine and are accepted into the blockchain is solved and user/client app is notified properly.
In Ethereum, when the transaction is malformed (i.e. not proper according to rules setup in smart contracts) and the transaction reverts with a proper revert reason, it is almost impossible to capture this and display to the user, because they might have made an error and proper feedback should be provided so that they can correct their error. I do not know whether this works properly in Inroha.
Spamming with bad transactions are of course prevented by gas in Ethereum; but in other settings (i.e. private Ethereum with no gas) this is a challenge.
In addition to spamming, there can be other reasons why the transaction is malformed; the only other solution seems to be to prevent submission of transaction, using mirror logic in the client that can check many conditions that are checked in the smart contracts; this is highly undesirable; as it requires duplication of logic and not being able to keep the expressions of business logic synchronised in the client and the smart contracts.
Nikita Puzankov
Thanks Vipin Bharathan- we will do our best to find a good way to solve these issues.