This is Part 2 in a series of posts looking at the wide variety of new capabilities for developers in the Algorand 5.0 upgrade. If you missed "Part 1: Salt - cryptographic capabilities," read it now.
Part 2: Fat - Fatter apps and transactions
This consensus protocol v42 allows many things to be much fatter: transactions, notes, application arguments, applications themselves, and logic signatures have all been given higher size limits that go far above what Algorand has supported in the seven years since genesis.
Fatter apps
We’ve doubled the maximum size of applications. After hearing your feedback about bumping up against the ceiling on the size of application bytecode, we’ve raised that ceiling by two times, from 8 KB to 16 KB. This is implemented by providing four additional program pages beyond the previous limit of three. Now you can add up to seven additional pages for a total of eight 2 KB pages.
This new limit allows both new, bigger applications and existing ones to be updated to add additional pages. As long as the app is updatable, existing ones can be updated to add more pages for more code. If you have an application that was blocked by its app size, that blocker is now removed.
Additionally, when updating an app, developers can now, for the first time, expand an app’s global state schema, which had always been immutable prior to this upgrade.
In both cases, the app updater must take on a new app role, SizeSponsor, that bears the minimum balance requirement (MBR) for the app’s entire extra program pages and global state slots. This role is necessary because the creator account may not be able to cover the increased MBR, so the updater who makes the change to extra program pages or expanded global state must be assessed the whole MBR, if different from the creator. Box MBR is unaffected by this change.
Fatter args
In addition to supporting larger application sizes, the protocol will now also allow up to 16 KB total of application arguments in calls, up from 2 KB. This upgrade will make it much easier to get large amounts of data into applications, particularly if you are trying to load data into big boxes. Notably, this limit also enables one application call’s arguments to hold an entire 16 KB program, equivalent to the new limit with all extra pages, if you have an application that implements a design pattern such as a factory or a self-updating application.
Fatter LogicSigs
LogicSig programs were previously limited to 1,000 bytes per transaction, pooled across the group, with a grouped maximum of 16,000 bytes. Now the maximum size can be achieved with just one transaction. What was only achievable before by grouping 16 transactions, an approach that can break composability with other applications in the ecosystem that need group space for their own transactions, can be done in a single transaction on 5.0. This new capability means that anything you may have designed that was using extra transactions to achieve a large stateless program can now be rebuilt using a single, large transaction for a more elegant and composable design.
Fatter fees
What will all of this cost, you may wonder? Firstly, know that anything that could be done on Algorand before protocol v42 can still be done at the same cost. Existing solutions don’t need to change anything for the transactions they craft because the fee changes provide a free allowance that covers all the capabilities that were previously included in a transaction. This consensus upgrade does not change the minimum fee cost of anything, so it is not a breaking change for transactions that were possible on previous versions.
However, now that expanded capabilities are possible, fees will be charged by a new, dynamic “usage” concept that tallies up protocol resource consumption for an entire transaction group. A group’s usage can be learned by simulating it, which will take into consideration all top-level outer transactions as well as all inner transactions generated by application calls. Because the transactions generated and their exact sizes may vary at runtime, we advise not to try to recreate fee accounting logic in your applications and instead rely on simulate to confirm actual fee costs. I’ll elaborate on this in Part 4 of the blog series.
Stay tuned for Part 3 in this series: “Acid: Safety with more flexibility,” coming later this week.
What do you want to build on Algorand 5.0? Join our Discord server to meet other developers building PQ solutions, fat apps, box families, and more.
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 the completeness, accuracy, reliability, suitability, or availability of the blog or the information contained in it 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, fees, or timelines are forward-looking and subject to change, including subject to community adoption, and are not commitments. 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. All third-party names and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement.