Algorand MCP

--- arc: 23 title: Sharing Application Information description: Append application information to compiled TEAL applications author: Stéphane Barroso (@sudoweezy), Fabrice Benhamouda (@fabrice102) discussions-to: https://github.com/algorandfoundation/ARCs/issues/80 status: Final type: Standards Track category: Interface sub-category: Application created: 2023-01-11 --- ## Abstract 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](arc-0004.md)), and as extended by future potential ARCs). ## Specification 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 <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>. > 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.json` representing the contract metadata (as described in [ARC-4](arc-0004.md)), and as extended by future potential ARCs). * **MAY** contain a file with the basename `application` followed by the extension of the high-level language the application is written in (e.g., `application.py` for PyTeal). > 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 `approval.teal` and `clear.teal`, that are the compiled versions of approval and clear program in TEAL. * Note that `approval.teal` will not be able to contain the application information as this would create circularity. If `approval.teal` is provided, it is assumed that the *actual* `approval.teal` that is deployed corresponds to `approval.teal` with the proper `bytecblock` (defined below) appended at the end. * **MAY** contain other files as defined by other ARCs. ### CID, Pinning, and CAR of the Application Information The <a href="https://github.com/multiformats/cid">CID</a> allows to access the corresponding application information files using <a href="https://docs.ipfs.tech/">IPFS</a>. The CID **MUST**: * Represent a folder of files, even if only `contract.json` is present. > You may need to use the option `--wrap-with-directory` of `ipfs add` * Be a version V1 CID > E.g., use the option `--cid-version=1` of `ipfs add` * Use SHA-256 hash algorithm > E.g., use the option `--hash=sha2-256` of `ipfs add` 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 <a href="https://ipld.io/specs/transport/car/carv1">Content Address Archiver (CAR)</a>( 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 `arc23`). > Example: for the above CID `bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte`, the binary CID corresponds to the following hexadecimal value: > > ``` > 0x0170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 > ``` > > and hence the encoded information byte string has the following hexadecimal value: > > ``` > 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 > ``` ### 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 <a href="https://developer.algorand.org/docs/get-details/dapps/avm/teal/opcodes/#bytecblock-bytes">`bytecblock`</a> with a unique byte string equal to the encoding information byte string. > For the example above, the `bytecblock` is: > > ``` > bytecblock 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 > ``` > > and when compiled this gives the following byte string (at least with TEAL v8 and before): > > ``` > 0x26012961726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 > ``` 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 `bytecblock` to 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) The `bytecblock` **MAY** be placed anywhere in the TEAL source code as long as it does not modify the semantic of the TEAL source code. However, if `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 `bytecblock` opcode 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. The `bytecblock` **MUST NOT** contain any additional byte string beyond the encoded information byte string. > For example, the following `bytecblock` is **INVALID**: > > ``` > 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: ``` 0x2601296172633233 ``` which is then followed by the 36 bytes of the binary CID. Indeed, this prefix is composed of: * 0x26, the `bytecblock` opcode * 0x01, the number of byte strings provided in the `bytecblock` * 0x29, the length of the encoded information byte string * 0x6172633233, the hexadecimal of `arc23` 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). If the `bytecblock` opcode encoding changes, software that extract the encoded information byte string from compiled TEAL programs **MUST** be updated. ## Rationale 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. ## Reference Implementation 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](../assets/arc-0023/main.py). A Folder containing: - example of the application [application.py](../assets/arc-0023/application_information/application.py). - example of the contract metadata that follow [ARC-4](arc-0004.md) [contract.json](../assets/arc-0023/application_information/contract.json). Files are accessible through followings IPFS command: ```console $ 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. ## Security Considerations CIDs are unique; however, related files **MUST** be checked to ensure that the application conforms. An `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 Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.