Why is App.validTransition a pure method?

[MatthiasLohr]

The title already has already the question: Why is App.validTransition a pure method?

I'm currently working on a research paper with an app using Perun. The app is intended to allow a certain dispute transition only of some "prerequisites" are fullfilled in the app contract, which can be set by other methods. However, having the pure keyword, the validTransition method is not allowed to read any state from the app contract implementation, which raises a huge problem for me, because it makes a solution much harder to implement with significantly increased Gas cost.

Is there any (e.g. security-related) reason, why this method has to be pure? Or would it from the conceptual and security point of view (and all other point of views which might be important here) be conceivable to declare it as view method or even leave it open to the implementation?

In solidity a method C overriding a method P can only modify this to more strict (e.g., from view to pure), but not the opposite.

[matthiasgeihs]

It's a good question. We have been discussing this before. As you observed, this ensures that the validity of a transition does not depend on any context other than the channel state. I think you could in principle relax this, but you would have to be careful about the implications, which I am not totally aware of at the moment.

Maybe @sebastianst has something to add here.

[MatthiasLohr]

The problem: I am not able to relax this as long as I compile against the official sources. In order to compile against your sources, the interface has to be relaxed. Solidity allows to implement a view interface method in a pure way, but not to implement a pure interface method as view in the implementing class.

So, would it be considerable for you to changed that in the official contracts?

In my personal opinion, the decision about context dependencies should be made by the app contract developer (assuming he knows what he does...) and not be enforced by Perun.

[sebastianst]

Technically, there's no problem in requiring validTransition to only be a view instead of a pure function. And I can totally see how it can be practical to have view validTransitions. However, it definitely lowers the security guarantees, because the protocols from the Perun papers assume that the app transition solely depends on the channel state, without any side effects from outside data. You can certainly construct funny scenarios if you allow view apps ;)

Nevertheless, I'd support changing the interface method from pure to view because it has practical benefits. But if we do this, it would definitely need to be documented well that pure implementations should be used where possible and that the App developer needs to take great care about security implications when using view functions and that this case is not covered by the vanilla Perun protocols and its security proofs.

[matthiasgeihs]

@sebastianst Thanks for your insights!

@MatthiasLohr Could you give some more detail in which scenario you need external information for the transition function? Just want to make sure we understand the use case well before we apply changes (which certainly have some security implications and should be justified well, there might also be alternative ways to implement what you need...)

[MatthiasLohr]

I'm currently working on an implementation of the FileSale protocol (published in the FairSwap paper bei Dziembowski et al.) combined with Perun. As part of this protocol, there is a "complain" phase, which allows to proof to an escrow smart contract that transferred data was not correct in some way. For this, the smart contract offers methods for conducting this proof.

Theoretically, this data could completely get included in the state information. However, this would lead to a significant increase of Gas to be paid, since everyhing has to be passed serialized to the progress method of the Adjudicator. Also, this leads to a much higher complexity.

My desired approach: If a complain was conducted successfully, the success is stored in a mapping of channelId => bool (pratically, this is implemented not using bool but uint to also save gas cost of the complain execution). The validTransition just checks, if this flag is >= 0.

Contract I'm developing (heavily under development!): https://gitlab.com/MatthiasLohr/bfebench/-/blob/main/bfebench/protocols/state_channel_file_sale/FileSaleApp.sol

The code line trying to access this mapping is currently commented out (currently in L88, might change in future).

[matthiasgeihs]

OK, so you would be running the actual fair swap protocol outside of the channel? I can't say whether I completely understand your scenario. We could have a call to discuss. Feel free to contact me via e-mail regarding that. In the meantime, you could fork the repository and deploy your own contracts for testing.