In particular, I think I read somewhere that it is in the planning to put an expiration on market order. I think this is required because of the pruning of transactions and this is different than with 2.0+.
Of course, adding expiration will require to set a new default value for the number of blocks before expiration happens. This default needs to be defined for each different transaction type that requires expiration.
Here below is a suggestion.
Add a new input parameter which would multiply ->
- the default number of blocks before expiration; and
- the default blockchain fee.
Such kind of new parameter to expiring transactions would be very much more convenient for the users, as they could pay and decide in advance for how long they wish “to rent data space” on the blockchain. Also, this could also significantly increase transaction fees to the forgers on the network.
I mean also that without such new input parameter, there will always be a complaint that expiration does not fit a user need.
What is the plan about this issue for 3.0+? Does another solution than the one described above is planned?
I hope the solution retains by Jelurida will be more convenient than the one that is currently provided for “leasing”.
Any other ideas about this issue is also welcome to be post below.
1 Like
You probably read that here - Introduction to Ardor v3 | Jelurida
We still need to invent the rules by which the data in the state tree to expire. We don't have a plan set in stone.
The way I understand you suggestion is that the higher fee the user pays to the forgers today, the longer his/her data stays in the state tree. It's a good idea and probably this will be the essence of the rules indeed - because it is more simple to implement than other approaches. But notice that this approach is not completely fair - the data in the state tree is a burden for all future participants in the network, while the profit is for the few current forgers (if they are different from the transaction creator). So we will probably also add some max limit on the expiration.
2 Likes
I got your idea.
Here is another proposition.
In any case (with max limit or not), a renew transaction option (with the possibility to set a new and different expiration limit [as cost on blockchain may change since last transaction]) would be good to implement too so that details of the initial transaction does not have to be provide ever again. If the renew transaction is trigger before the end of the limit, the transaction data should stay on ţhe blockchain until next limit. Is this making sense?
This would be usefull also for leasing as an example. Its not convenient to always enter the same information over and over again.