ARC-23: Sharing Application Information
Append application informations to compiled TEAL applications
|Author||Stéphane Barroso, Fabrice Benhamouda|
|Last Call Deadline||2023-03-23|
Table of Contents
- Reference Implementation
- Security Considerations
The following document introduces a convention for appending information (stored in various files) to the compiled application’s bytes.
The goal of this convention is to standardize the process of verifying and adding this information.
The encoded information byte string is
arc23 followed by the IPFS CID v1 of a folder containing the files with the information.
The minimum required file is
contract.json representing the contract metadata (as described in ARC-4), and as extended by future potential ARCs).
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.
Comments like this are non-normative.
Files containing Application Information
Application information are represented by various files in a folder that:
- MUST contain a file
contract.jsonrepresenting the contract metadata (as described in ARC-4), and as extended by future potential ARCs).
- MAY contain a file with the basename
applicationfollowed by the extension of the high-level language the application is written in (e.g.,
To allow the verification of your contract, be sure to write the version used to compile the file after the import eg:
from pyteal import * #pyteal==0.20.1
- MAY contain the files
clear.teal, that are the compiled versions of approval and clear program in TEAL.
- Note that
approval.tealwill not be able to contain the application information as this would create circularity. If
approval.tealis provided, it is assumed that the actual
approval.tealthat is deployed corresponds to
approval.tealwith the proper
bytecblock(defined below) appended at the end.
- Note that
- MAY contain other files as defined by other ARCs.
CID, Pinning, and CAR of the Application Information
The CID allows to access the corresponding application information files using IPFS.
The CID MUST:
- Represent a folder of files, even if only
You may need to use the option
- Be a version V1 CID
E.g., use the option
- Use SHA-256 hash algorithm
E.g., use the option
Since the exact CID depends on the options provided when creating it and of the IPFS software version (if default options are used), for any production application, the folder of files SHOULD be published and pinned on IPFS.
All examples in this ARC assume the use of Kubo IPFS version 0.17.0 with default options apart those explicitly stated.
If the IPFS is not pinned, any production application SHOULD provide a Content Address Archiver (CAR)( file of the folder, obtained using
ipfs dag export.
For public networks (e.g., MainNet, TestNet, BetaNet), block explorers and wallets (that support this ARC) SHOULD try to recover application information files from IPFS, and if not possible, SHOULD allow developers to upload a CAR file. If a CAR file is used, these tools MUST validate the CAR file matches the CID.
For development purposes, on private networks, the application information files MAY be instead provided as a .zip or .tar.gz containing at the root all the required files. Block explorers and wallets for private networks MAY allow uploading the application information as a .zip or .tar.gz. They still SHOULD validate the files.
The validation of .zip or .tar.gz files will work if the same version of the IPFS software is used with the same option. Since for development purposes, the same machine is normally used to code the dApp and run the block explorer/wallet, this is most likely not an issue. However, for production purposes, we cannot assume the same IPFS software is used and a CAR file is the best solution to ensure that the application information files will always be available and possible to validate.
Example: For the example stored in
/asset/arc-0023/application_information, the CID is
bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte, which can be obtained with the command:
ipfs add --cid-version=1 --hash=sha2-256 --recursive --quiet --wrap-with-directory --only-hash application_information
Associated Encoded Information Byte String
The (encoded) information byte string is
arc23 concatenated to the 36 bytes of the binary CID.
The information byte string is always 41-byte long and always start, in hexadecimal with
0x6172633233 (corresponding to
Example: for the above CID
bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte, the binary CID corresponds to the following hexadecimal value:
and hence the encoded information byte string has the following hexadecimal value:
Inclusion of the Encoded Information Byte String in Programs
The encoded information byte string is included in the approval program of the application via a
bytecblock with a unique byte string equal to the encoding information byte string.
For the example above, the
and when compiled this gives the following byte string (at least with TEAL v8 and before):
The size of the compiled application plus the bytecblock MUST be, at most, the maximum size of a compiled application according to the latest consensus parameters supported by the compiler.
At least with TEAL v8 and before, appending the
bytecblockto the end of the program should add exactly 44 bytes (1 byte for opcode
bytecblock, 1 byte for 0x01 -the number of byte strings-, 1 byte for 0x29 the length of the encoded information byte string, 41 byte for the encodedin information byte string)
bytecblock MAY be placed anywhere in the TEAL source code as long as it does not modify the semantic of the TEAL source code.
approval.teal is provided as an application information file, the
bytecblock SHOULD be the last opcode of the deployed TEAL program.
Developers MUST check that, when adding the
bytecblock to their program, semantic is not changed.
At least with TEAL v8 and before, adding a
bytecblockopcode at the end of the approval program does not change the semantics of the program, as long as opcodes are correctly aligned, there is no jump after the last position (that would make the program fail without
bytecblock), and there is enough space left to add the opcode, at least with TEAL v8 and before. However, though very unlikely, future versions of TEAL may not satisfy this property.
bytecblock MUST NOT contain any additional byte string beyond the encoded information byte string.
For example, the following
bytecblock 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 0x42
Retrieval the Encoded Information Byte String and CID from Compiled TEAL Programs
For programs until TEAL v8, a way to find the encoded information byte string is to search for the prefix:
which is then followed by the 36 bytes of the binary CID.
Indeed, this prefix is composed of:
- 0x26, the
- 0x01, the number of byte strings provided in the
- 0x29, the length of the encoded information byte string
- 0x6172633233, the hexadecimal of
Software retrieving the encoded information byte string SHOULD check the TEAL version and only perform retrieval for supported TEAL version. They also SHOULD gracefully handle false positives, that is when the above prefix is found multiple times. One solution is to allow multiple possible CID for a given compiled program.
Note that opcode encoding may change with the TEAL version (though this did not happen up to TEAL v8 at least).
bytecblock opcode encoding changes, software that extract the encoded information byte string from compiled TEAL programs MUST be updated.
By appending the IPFS CID of the folder containing information about the Application, any user with access to the blockchain could easily verify the Application and the ABI of the Application and interact with it.
Using IPFS has several advantages:
- Allows automatic retrievel of the application information when pinned.
- Allows easy archival using CAR.
- Allows support of multiple files.
The following codes are not audited and are only here for information purposes.
Here is an example of a python script that can generate the hash and append it to the compiled application, according this ARC: main.py.
A Folder containing:
- example of the application application.py.
- example of the contract metadata that follow ARC-4 contract.json.
Files are accessible through followings IPFS command:
$ ipfs cat bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte/contract.json $ ipfs cat bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte/application.py
If they are not accessible be sure to removed [–only-hash -n] from your command or check you ipfs node.
CIDs are unique; however, related files MUST be checked to ensure that the application conforms.
arc-23 CID added at the end of an application is here to share information, not proof of anything.
In particular, nothing ensures that a provided
approval.teal matches the actual program on chain.
Copyright and related rights waived via CCO.
Please cite this document as:
Stéphane Barroso, Fabrice Benhamouda, "ARC-23: Sharing Application Information [DRAFT]," Algorand Requests for Comments, no. 23, January 2023. [Online serial]. Available: https://algorandfoundation.github.io/ARCS/arc-23.