[Feature] Pay for fee using public credits

[HarukaMa]

🚀 Feature

As we have public native tokens now, we might consider allowing users to use public credits to pay for the transaction fee.

Motivation

This might help achieving #1753, where the user could only pay what the finalizers actually consumes (and potentially storage costs as well), plus a fixed priority fee, instead of providing a fixed amount, then derive the priority fee by subtracting the minimum required other fee.

Implementation

Maybe by adding a new fee_public transition for credits.aleo and do the fee part in the finalizer just for implementing the feature, but doing in this way wouldn't help in the above situation (we still have a fixed transition input).

Maybe by subtracting the specified fee directly from the account mapping and adding a mapping operation without external finalize sources (essentially a built-in finalizer without the accompanying transition).

Are you willing to open a pull request? (See CONTRIBUTING)
Depends...

[howardwu]

We discussed the idea to use public credits for the fee.

There are several tradeoffs that are made in doing this. For one, using public credits means we will need to introduce a (numeric) nonce for each transaction and enforce they monotonically increment for each transaction. The problem is, that transactions do not contain the caller's address (for privacy) and as such, there is no mechanism to track their nonce by design.

In addition, should a nonce become possible to be tracked, it comes with two major drawbacks:

1. Increased tracking of the user's activity
   • Because introducing a nonce would introduce the first traceable identity on the protocol-level, we now would be allowing users to be tracked across their transactions.
2. Reduced concurrency of applications
   • Because the nonce would be used to enforce a monotonic counter that increments once per block (similar to smart contract platforms), this would imply that a user can only call a program once per block. Currently, Aleo allows users to call a program as many times as they wish in each block (because the fee is designed as a record).

Because of these major tradeoffs, we decided not to pursue public credits, until a better design (than what existing ledgers like Ethereum have chosen) is proposed.

[HarukaMa]

That make a lot of sense, thanks for the answer.

should I close this issue for now?

[howardwu]

I think it can be closed for now.

I'll add one more comment for all readers:

There needs to be much better UI/UX-based web or client based services to help users detect, decrypt, manage, and join/split their Aleo credits. This would help to mitigate and offset usability concerns for including the fee in each transaction.

We're open to working with teams that want to build out such services, especially in a privacy-preserving manner, as we believe this is a core component to a thriving developer ecosystem for Leo and Aleo instructions.

[HarukaMa]

Closing as not planned for now.

[howardwu]

Reopening this issue as we may have come up with a way to support public fees without sacrificing concurrency (because of the nonce), and without introducing replay attack concerns.

[howardwu]

The MVP for this feature has been implemented in #1867.

There remains much more work needed to do to ensure safety and stability of this feature.

[howardwu]

Closing since we now support public fees.