5.5.2 Algorand
The Algorand Reach connector generates a set of contracts that manage one instance of the DApp’s execution.
It uses finite on-chain state: two integers and one byte string. The DApp consists of one application, one contract-controlled escrow account, and many contract-controlled handlers for each of the publications of your Reach program. During compilation, the connector produces intermediate outputs for each of these contracts. These contracts embed references to each through their template arguments, which is done automatically by the Reach standard library implementation.
It relies on versions of algod that support TEAL 3, such as the Algorand BetaNet 2.5.2 release from mid-March 2021. It uses the Algorand indexer version 2 to lookup and monitor publications; in other words, it does not rely on any communication network other than Algorand itself.
Algorand uses the Keccak256 algorithm to perform digests. Its bit width is 64-bits.
Non-network tokens are compiled to Algorand Standard Assets (ASAs).
Specifically, the Token type refers to the id of the ASA.
Reach programs that use non-network tokens deployed on Algorand are inherently vulnerable to a denial-of-service attack due the ability of Algorand accounts to "opt-out" of a token.
For example, if a program has a consensus step where Alice will receive 1 gil and Bob will receive 2 zorkmids, either Alice or Bob can prevent this step from executing by opting out of (respectively) gil or zorkmids.
(An "opt-out" is performed by sending an Asset Transfer Transaction (axfer) with a non-zero AssetCloseTo field.)
You can alleviate this problem by ensuring that any non-network token transfers occurs as the last consensus steps of the program and may be executed in any order by the recipient of the funds.
We hope that future versions of Algorand will provide a facility for preventing these denial-of-service attacks.
Views are compiled to client-side functions that can interpret the global and local state of the Algorand Application associated with the DApp. This means they are sensitive to the particular compilation details of the particular Reach program. We hope to work with the Algorand community to define a standard for views. Views expand the on-chain state to include the free variables of all values bound to a view.
Linear state is compiled into Application Local State. This means that participants that must explicitly "opt-in" to storing this state on their account (which increases their minimum balance.) The Reach standard library will do this automatically when connecting to Reach generated contracts, but other users must be specifically programmed to this. This "opt-in" requirement means that DApps with linear state deployed on Algorand can deadlock and be held hostage: Suppose that Alice transfers 10 ALGO to a contract in step one, then in step two, the consensus must store a value associated with Bob, and then she can receive her 10 ALGO back, then the program terminates. On some networks, Alice can perform these two steps completely on her own and she is in complete control of her funds. However, on Algorand, running this program requires that Bob "opt-in" to storing values for the application. We hope that future versions of Algorand will allow other parties to pay the fees to "opt-in" to applications to prevent these kinds of deadlock attacks.
This connector does not support different deployModes and treats them all as 'constructor'.
The connector provides a binding named ALGO to
backends.
Backends must respect the following environment variables: