Shorthand

Discussion participants: Makoto Takemiya, Andrei Lebedev, Nikita Puzankov

Makoto Takemiya

neI also don’t think rejected transactions should be in a block. Is there a good reason to have them there?

Andrei Lebedev :

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

Nikita Puzankov :

I didn't catch that

Makoto Takemiya

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

Andrei Lebedev

I wonder how this problem is solved in other networks. Because your concern is valid, and it should be already solved somehow.

Makoto Takemiya

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.

Andrei Lebedev :

The same thing is also present in Iroha. But it is quite possible to do this spending attack in a short timeframe.

Makoto Takemiya :

That way nodes can try to reject transactions that are outside the time. Sure, but it is not our problem, but the sender’s :)

Nikita Puzankov :

that what I was talking about with concept of TTL for tx processing

Makoto Takemiya :

What do you mean?

Nikita Puzankov :

Like a usual packets on internet - Time to Live

Makoto Takemiya :

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.


  • No labels

12 Comments

  1. 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.

    1. 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?

  2. 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).

    1. 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?

      1. 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.

        1. 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.

        2. Nikita Puzankov

          Makoto Takemiya - can you add them to this RFC and we will discuss details?

          1. Nikita Puzankov

            So  why do we need them here and why problem is more complex than it seems.

            1. We do not have "fees" in Iroha, it's more high level requirement in my opinion (may be considered in a separate PR) and we should not be aware about it on this level.
              1. Introduction of Fees entity in Iroha will require additional hardcoded logic in some parts of the application
              2. The requirements about Fees may differ from project to project
            2. Our design decision to do not store rejected transactions were aiming to do not store unnecessary information on the blockchain (modern concepts store only proofs on the chain, so think about it)
            3. Mobile or Web applications developers may need to see history of all user actions - Queries, Instructions - failed or not, but we should define the full list of these requirements (even if it will be not a stable list, but temporary) for future discussion. 
              1. It can be done on application layer - by having some mechanism to listen for rejected transactions and store them in infrastructure accounts assets or by holding them on the user's devices or by any other means, but to make a decision we need to talk with stakeholders and make some business analysis.
              2. Transactions may fail by many reasons, some of them (like validation stage or consensus voting) can be depicted on peers side, but network issues, malicious peers and some other cases will not provide such an ability. Right now I can't see what type of failures and how should be depicted in app (also why only mobile app? what about web?).

            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. 

  3. 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.

    1. Egor Ivkov

      This way we will only store the rejected transactions that did not pass stateful validation.

  4. 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. 

    1. Nikita Puzankov

      Thanks Vipin Bharathan- we will do our best to find a good way to solve these issues.