Polyfungible-v2 time constraint

[bart-kuma]

Current Problem

It's a bit hard to handle the UI/UX for NFT sales in poly-fungible-v2 based contracts because it uses block-height as the time constraint for time dependant functions instead of block-time.

While listing an NFT for sale, the seller has to provide how long a token should be listed (timeout). block-height is used to check the timeout. To calculate the block height for the timeout,

1. The seller will pick a date
2. Now we have to convert the date to seconds seconds = selected-time - current-time
3. Then to number of blocks blocks = (seconds / average block-time)
4. We have to add the blocks to current-block-height timeout = current-block-height + blocks and send it to the contract.

Now while displaying the timeout after the token listing has completed, we will have to convert the block-height back to user-understandable time format. To do this,

1. We have to convert the timeout block-height back to seconds seconds = (current-block-height - timeout) / average block-time.
2. Add the seconds to the current epoch and then show it to the users.

This method has cons like,

1. The calculated timeout while displaying for the users will not be the same as the seller selected while listing.
2. The average block time may be inconsistent. Therefore the timeout can happen before the seller's expected time.
3. Displaying the block height directly to the user is not a good practice and affects the UX of the marketplace.
4. The calculated time may not be the same for users in different time zones.

Proposal

To use block-time as the constraint to validate time dependant functions because it will be a lot easier for marketplaces to display time, and it serves the same purpose as the block-height in validating the expiry of the token listing.

Files to be changed:

1. Need to change the condition based on block-time in ledger contract
2. Need to change the type of timeout from integer to time in poly-fungible-v2 interface

I will be happy to collaborate for implementing these changes.

References

I'm sharing some discussions in the eth community regarding block-time vs block-height.

• https://ethereum.stackexchange.com/questions/18576/how-time-difference-can-be-calculated-by-block-number-and-how-it-is-different-fr
• https://ethereum.stackexchange.com/questions/24348/how-do-we-use-block-number-as-opposed-to-block-timestamp-for-measuring-time?noredirect=1&lq=1
• https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/
• https://ethereum.stackexchange.com/questions/15047/solidity-timestamp-dependency-is-it-possible-to-do-safely

[kitty-kad]

I like this proposal. I know other blockchains tend to use block height often, but here it seems good to use block-time.

Especially since block time and time based operations are natively supported in Pact,

[Luzzotica]

I, too, am a fan. I haven't interacted too much with frontend development for Marmalade tokens, but I suspect those two things caused you more than a little bit of a headache. How can we push this forward?

[bart-kuma]

I, too, am a fan. I haven't interacted too much with frontend development for Marmalade tokens, but I suspect those two things caused you more than a little bit of a headache. How can we push this forward?

Hey, yeah, it caused much trouble during development. I have already mentioned the files that need to be changed. And I have implemented the same changes in my dev environment, which is ready to launch. I have some demo videos in our discord. The only issue will be pushing it to the chain, as interfaces are not upgradeable. It has to be a new interface, something like poly-fungible-v3.