This is Part 3 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," or "Part 2: Fat - Fatter apps and transactions," you can read them now.
Part 3: Acid - Safety with more flexibility
Software engineers who have studied database design will be familiar with the ACID properties of a database: Atomicity, Consistency, Isolation, and Durability. These four properties together provide a guarantee that database transactions are processed reliably, making applications more secure, highly resilient, and easy to reason about.
Algorand has historically been designed to be a particularly safe and elegant distributed database at two different levels. The base level is the global ledger itself, and on top of that is the state maintained by each stateful application.
It is in this second, application-level that the next version of the AVM, v13, relaxes a long-standing isolation measure that only the app that owns a box can read from and write to it. Developers will be able to build apps more flexibly now that boxes can optionally be opened up to direct access from other applications.
New capabilities
This upgrade introduces two new application parameters: FamilyBoxAccess and ForeignBoxReads. The first is a parameter that enables an app’s boxes to be read and written by other applications in the same “family,” as defined by having the same creator. The second enables an app’s boxes to be read, and only read, by any other application.
These parameters can be set by calling a new opcode app_params_set that acts on the application executing this opcode. This is a new paradigm insofar as these are opcodes run by an application to modify itself, rather than being performed by a transaction.
This means two things:
-
The procedure for enabling family box access or foreign box reads involves two steps: first updating the code to include the relevant opcode and then subsequently running that code.
-
An application that has no way to update its code will not be able to use these operations on itself because it has no way to update its code in the first place to include these opcodes. Intentionally immutable apps can stay that way.
For apps that have enabled this access, a whole set of box access opcodes have been added to the AVM that take both an app ID and box key so that boxes in other applications can be reached. All of this is strictly optional, however, and patterns involving app data that is kept private from other on-chain apps are still possible.
With these new capabilities, applications that previously needed to provide getter and setter methods for other apps to access data in their boxes can forgo a lot of that code by opening up family or foreign box access instead. Combined with the fact that applications can be twice as large, this opens up a lot more bytecode headroom to design protocols that are split across fewer total apps and need less glue code to make them all work together.
One interesting tidbit about family and foreign box access is that these opcodes can be run at any point and it takes effect immediately, so it is now possible to enable and subsequently disable this access within the currently executing application call. This has the potential to unlock “flash” possibilities where this shared state access is enabled, used, and then disabled, all within the same transaction.
New protections
The AVM was originally designed with safety in mind, and one deliberate decision was to prevent reentrancy, meaning that smart contract applications are not allowed to call themselves or be called more than once in a given transaction. A single-transaction app execution sequence like A→A is disallowed, as is a sequence like A→B→A.
Forbidding reentrancy eliminates the need for developer discipline around a class of bugs that can occur in program logic, a class of bugs that have at times been footguns for developers when writing EVM smart contracts, which do allow reentrancy. While the ability to do contract reentrancy can enable interesting callback patterns and other capabilities, there is a risk of a contract’s data being in a state that is unexpected or should be impossible because it is only partially done executing. This can lead to, and has contributed to, exploits in escrow contracts holding funds for protocols on other chains.
The AVM allowing apps in the same family to write the same boxes could create the potential for a similar class of bugs, but this risk is mitigated by two new restrictions for apps that have enabled FamilyBoxAccess:
-
The applications involved must be related in a “family” defined by a shared creator address. It seems safe to assume that multiple applications deployed by the same address have been designed in such a way that this access won’t be abused. That said, it is incumbent upon app developers to ensure family box state is handled properly in a set of applications that use it.
- If an application outside the same-creator family sits between two writes to state owned by that family, the AVM will reject the current application call.
Stay tuned for Part 4 in this series: “Heat: Cooking with simulate,” 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.