Enhancing on-chain flavor in Algorand 5.0 — Part 4: Heat

This is Part 4 in a series of posts looking at the wide variety of new capabilities for developers in the Algorand 5.0 upgrade. If you missed the earlier parts, read them now:

Part 1: Salt - cryptographic capabilities

Part 2: Fat - Fatter apps and transactions

Part 3: Acid - Safety with more flexibility

Part 4: Heat - Cooking with simulate

Algorand has a special ability in algod that every chef would envy: the ability to cook a transaction to see how it will turn out, but without actually cooking it. Simulate, a special REST endpoint on the node, can evaluate a transaction as it would be when submitted to the mempool and return rich information about how it was processed, including references required, errors, and fee requirements.

Simulate simulate simulate

Our guidance for developers is simply to leverage simulate as much as practicable and certainly not hard-code anything related to fees.

The driving force behind this guidance comes from a few things:

1. The minimum fee is not going to be enough for all “normal size” transactions anymore because the type of signature now matters, and transactions with PQ signatures will cost more than the protocol’s minFee. Simply using getSuggestedParams from the /v2/transactions/params endpoint will no longer provide your application with sufficient information to prepare transactions successfully. You now need to know if the account for which you are preparing the transaction(s) will be using a PQ signature.

2. Larger apps made possible by this upgrade will require additional references, which can be gleaned from a simulate response.

3. Future protocol upgrades may start to put the currently informational CongestionTax value into action to charge fees above minFee. Transactions will need to be simulated against the current state of the chain, including its degree of congestion, to know accurately what fee will be required.

The way to leverage simulate to have the best experience in your application is to use empty signers together with the allow-empty-signatures option to learn actual resource usage across the group to calculate required fees: total = ceil(min-fee * group-usage / 1,000,000).

This means constructing realistic, unsigned transactions but including the type of signature that will be included once they are signed. With this information, simulate can tell your application what fees are required, pooled across the group, and final adjustments can be made before collecting signatures.

Wallet-dApp Information Sharing

On Algorand 5.0, the happy path for simulate will be to identify that an account is Ed25519 or PQ and then simulate. This is a new requirement in the ecosystem, which has always been able to assume that users have Ed25519 accounts, as that was all there was. Going forward, apps may need to collect this account type information from transaction signers… somehow.

For example, imagine the following workflow: A user with a PQ account in their mobile wallet connects it to a DeFi protocol in their desktop browser through WalletConnect. At some point, the DeFi app needs to find out that the user has a PQ account that requires higher fees. If the app does not ask this account type question before simulating the transaction group, it may succeed in simulate but fail when actually signed with a PQ signature and submitted to a node.

In order for this to be more automated, we foresee a need for new messaging standards between wallets and apps, with different approaches for browser extensions vs. mobile apps. Several long-standing ARC standards involving transactions and signing may need to be revisited and updated for this Post-Algorand 5.0 era in which signatures and fees work quite differently than they have since Algorand’s inception.

Some of the standards that might need to be revisited include, but are not limited to:

• ARC-1 Algorand Wallet Transaction Signing API (needs PQ signature support)

• ARC-5 Wallet Transaction Signing API (Functional) (inherits from ARC-1)

• ARC-25 Algorand WalletConnect v1 API (inherits from ARC-1)

• ARC-27 Provider Message Schema (for browser extension wallets)

• ARC-35 Algorand Offline Wallet Backup Protocol (only handles small Edwards keys)

• ARC-56 Extended App Description (assumption about innerTxn cost)

• ARC-59 ASA Inbox Router (update fee mechanics)

• ARC-60 Algorand Wallet Arbitrary Signing API (only considers Ed25519 signatures)

• ARC-90 URI scheme (makes assumptions about fee mechanics)

We welcome community input in (re)designing the right abstractions for Algorand’s PQ future and invite developers to join the arcs channel in the Algorand Discord server to discuss issues you are facing and potential solutions. We will also be discussing technical standards and ecosystem migration efforts in our Developer Council meetings, to which you may request an invitation in Discord.

Disclaimer: The content provided in this blog is for informational and educational purposes only. The information is provided by the Algorand Foundation and while we strive to keep it accurate and current, we make no representations or warranties of any kind, express or implied, about its completeness, accuracy, reliability, suitability, or availability for any purpose. Nothing in this blog is legal, financial, tax, or investment advice, nor an endorsement, guarantee, or investment recommendation. Technical descriptions are provided as of the date of publication and may change. Any statements about future plans, features, integrations, protocol or consensus upgrades, standards, fees, or timelines are forward-looking and subject to change, including subject to community adoption, and are not commitments. Third-party names and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement. You should conduct your own research and consult a qualified professional before acting on any information here; any reliance you place on it is strictly at your own risk.