-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARC56: Extended App Description #258
Changes from 17 commits
ef5f338
6beb9f9
a18a968
1265709
1b19b76
45a4f6a
96bf578
8c983a1
a4c523e
f6a62f0
358a65b
d9046e1
9a5e445
ef47b89
8e3499b
b02c3c1
2a5eb6f
cebfc7d
e6115f0
fd8fe2a
89a6c0c
35fd3fc
8572596
ac0a9b1
05cd0d5
ab956a7
22372b2
8ee7866
f82a2fa
ad5d033
e540d92
7b3982b
f30b5f6
59edfa8
7f5816a
9908f86
faf5f4b
506acbd
d8d4c46
6bc830c
da85edf
3ef93fc
e577cfb
58a133d
aa79e86
35a19b3
3476dad
1e31ba0
19c6269
017c6e3
d58be41
9ba13f1
20369ed
027462f
12e3a53
8e2db8d
9a3f705
1cde499
9b0205c
1eccf65
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,322 @@ | ||
--- | ||
arc: 56 | ||
title: Extended App Description | ||
description: Adds information to the ABI JSON description | ||
author: Joe Polny (@joe-p) | ||
discussions-to: https://github.com/algorandfoundation/ARCs/issues/258 | ||
status: Draft | ||
type: Standards Track | ||
category: ARC | ||
created: 2023-11-14 | ||
requires: 4, 22, 28 | ||
--- | ||
|
||
|
||
## Abstract | ||
This ARC takes the existing JSON description of a contract as described in [ARC-4](./arc-0004.md) and adds more fields for the purpose of client interaction | ||
|
||
## Motivation | ||
The data provided by ARC-4 is missing a lot of critical information that clients should know when interacting with an app. This means ARC-4 is insufficient to generate type-safe clients that provide a superior developer experience. | ||
|
||
On the other hand, [ARC-32](./arc-0032.md) provides the vast majority of useful information that can be used to <a href="https://github.com/algorandfoundation/algokit-cli/blob/main/docs/features/generate.md#1-typed-clients">generate typed clients</a>, but requires a separate JSON file on top of the ARC-4 json file, which adds extra complexity and cognitive overhead. | ||
|
||
## Specification | ||
|
||
### Contract Interface | ||
Every application is described via the following interface which is an extension of the `Contract` interface described in [ARC-4](./arc-0004.md). | ||
|
||
```ts | ||
/** Describes the entire contract. This interface is an extension of the interface described in ARC-4 */ | ||
interface Contract { | ||
/** The ARCs used and/or supported by this contract */ | ||
arcs: number[], | ||
/** A user-friendly name for the contract */ | ||
name: string; | ||
/** Optional, user-friendly description for the interface */ | ||
desc?: string; | ||
/** | ||
* Optional object listing the contract instances across different networks | ||
*/ | ||
networks?: { | ||
/** | ||
* The key is the base64 genesis hash of the network, and the value contains | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This description should probably be added to the networks key above otherwise you don't see it in intellisense |
||
* information about the deployed contract in the network indicated by the | ||
* key. A key containing the human-readable name of the network MAY be | ||
* included, but the corresponding genesis hash key MUST also be defined | ||
*/ | ||
[network: string]: { | ||
/** The app ID of the deployed contract in this network */ | ||
appID: number; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
}; | ||
}; | ||
/** Named structs use by the application */ | ||
structs: { [structName: StructName]: StructFields }; | ||
/** All of the methods that the contract implements */ | ||
methods: Method[]; | ||
state: { | ||
/** Defines the values that should be used for GlobalNumUint, GlobalNumByteSlice, LocalNumUint, and LocalNumByteSlice when creating the application */ | ||
schema: { | ||
global: { | ||
ints: number; | ||
bytes: number; | ||
}; | ||
local: { | ||
ints: number; | ||
bytes: number; | ||
}; | ||
}; | ||
/** Describes single key-value pairs in the application's state */ | ||
keys: { | ||
global: StorageKey[]; | ||
local: StorageKey[]; | ||
box: StorageKey[]; | ||
}; | ||
/** Describes key-value maps in the application's state */ | ||
maps: { | ||
global: StorageMap[]; | ||
local: StorageMap[]; | ||
box: StorageMap[]; | ||
}; | ||
}; | ||
/** Supported bare actions for the contract. An action is a combination of call/create and an OnComplete */ | ||
bareActions: { | ||
/** OnCompletes this method allows when appID === 0 */ | ||
create: ('NoOp' | 'OptIn' | 'DeleteApplication')[]; | ||
/** OnCompletes this method allows when appID !== 0 */ | ||
call: ('NoOp' | 'OptIn' | 'CloseOut' | 'ClearState' | 'UpdateApplication' | 'DeleteApplication')[]; | ||
}; | ||
/** Information about the TEAL */ | ||
sourceInfo: SourceInfo; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** The pre-compiled TEAL that may contain template variables. MUST be omitted if included as part of ARC23, but otherwise MUST be defined. */ | ||
source?: { | ||
/** The approval program */ | ||
approval: string; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** The clear program */ | ||
clear: string; | ||
}; | ||
/** ARC-28 events that MAY be emitted by this contract */ | ||
events?: Array<Event>; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** Template Variables */ | ||
templateVariables?: { | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** The name of the template variable as it appears in the TEAL */ | ||
name: string; | ||
/** The type of the value expected in the template variable */ | ||
type: ABIType | AVMBytes | StructName; | ||
}[]; | ||
} | ||
``` | ||
|
||
### Method Interface | ||
|
||
Every method in the contract is described via a `Method` interface. This interface is an extension of the one defined in [ARC-4](./arc-0004.md). | ||
|
||
```ts | ||
/** Describes a method in the contract. This interface is an extension of the interface described in ARC-4 */ | ||
interface Method { | ||
/** The name of the method */ | ||
name: string; | ||
/** Optional, user-friendly description for the method */ | ||
desc?: string; | ||
/** The arguments of the method, in order */ | ||
args: Array<{ | ||
/** The type of the argument */ | ||
type: ABIType; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** If the type is a struct, the name of the struct */ | ||
struct?: StructName; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** Optional, user-friendly name for the argument */ | ||
name?: string; | ||
/** Optional, user-friendly description for the argument */ | ||
desc?: string; | ||
/** The default value that clients should use. MUST be base64 encoded bytes */ | ||
defaultValue?: string; | ||
}>; | ||
/** Information about the method's return value */ | ||
returns: { | ||
/** The type of the return value, or "void" to indicate no return value. */ | ||
type: ABIType; | ||
/** If the type is a struct, the name of the struct */ | ||
struct?: StructName; | ||
/** Optional, user-friendly description for the return value */ | ||
desc?: string; | ||
}; | ||
/** an action is a combination of call/create and an OnComplete */ | ||
actions: { | ||
/** OnCompletes this method allows when appID === 0 */ | ||
create: ('NoOp' | 'OptIn' | 'DeleteApplication')[]; | ||
/** OnCompletes this method allows when appID !== 0 */ | ||
call: ('NoOp' | 'OptIn' | 'CloseOut' | 'ClearState' | 'UpdateApplication' | 'DeleteApplication')[]; | ||
}; | ||
/** If this method does not write anything to the ledger (ARC-22) */ | ||
readonly: boolean; | ||
/** ARC-28 events that MAY be emitted by this method */ | ||
events?: Array<Event>; | ||
/** Information that clients can use when calling the method */ | ||
recommendations?: { | ||
/** The number of inner transactions the caller should cover the fees for */ | ||
innerTransactionCount?: number; | ||
/** Recommended box references to include */ | ||
boxes?: { | ||
/** The app ID for the box */ | ||
app: number; | ||
/** The base64 encoded box key */ | ||
key: string; | ||
/** The number of bytes being read from the box */ | ||
readBytes: number; | ||
/** The number of bytes being written to the box */ | ||
writeBytes: number; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should readBytes and writeBytes and app be optional? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made app optional but kept readBytes and writeBytes as mandatory to enforce that at least one of them is given. The other can just be 0 |
||
}; | ||
/** Recommended foreign accounts */ | ||
accounts?: string[]; | ||
/** Recommended foreign apps */ | ||
apps?: number[]; | ||
/** Recommended foreign assets */ | ||
assets?: number[]; | ||
}; | ||
} | ||
``` | ||
|
||
### Event Interface | ||
|
||
[ARC-28](./arc-0028.md) events are described using an extension of the original interface described in the ARC, with the addition of an optional struct field for arguments | ||
|
||
```ts | ||
interface Event { | ||
/** The name of the event */ | ||
name: string; | ||
/** Optional, user-friendly description for the event */ | ||
desc?: string; | ||
/** The arguments of the event, in order */ | ||
args: Array<{ | ||
/** The type of the argument */ | ||
type: ABIType; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** Optional, user-friendly name for the argument */ | ||
name?: string; | ||
/** Optional, user-friendly description for the argument */ | ||
desc?: string; | ||
/** If the type is a struct, the name of the struct */ | ||
struct?: StructName; | ||
}>; | ||
} | ||
``` | ||
|
||
|
||
### Type Interfaces | ||
|
||
The types defined in [ARC-4](./arc-0004.md) may not fully described the best way to use the ABI values as intended by the contract developers. These type interfaces are intended to supplement ABI types so clients can interact with the contract as intended. | ||
|
||
```ts | ||
/** An ABI-encoded type */ | ||
type ABIType = string; | ||
|
||
/** The name of a defined struct */ | ||
type StructName = string; | ||
|
||
/** Raw byteslice without the length prefixed that is specified in ARC-4 */ | ||
type AVMBytes = 'bytes'; | ||
|
||
/** Mapping of named structs to the ABI type of their fields */ | ||
interface StructFields { | ||
[fieldName: string]: ABIType | StructFields; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It occurs to me that this format requires property order to be maintained to be able to map them to the underlying tuple type. Are we comfortable that will always be the case across all languages? https://www.rfc-editor.org/rfc/rfc7159 says (emphasis mine):
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this a choice for the HLL. The struct have to have a specific order for ABI encoding, so the HLL can either implement an ordered struct or not expose ways of iterating keys/values (like in TEALScript) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But this spec determines the format of the json file? If the json file is an object and the programming language parsing it doesn’t implemented ordered iteration of object keys you are hosed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah right ok I see what you are saying. So I think it should be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Spot on I think |
||
} | ||
``` | ||
|
||
### Storage Interfaces | ||
|
||
These interfaces properly describe how app storage is access within the contract | ||
|
||
```ts | ||
/** Describes a single key in app storage */ | ||
interface StorageKey { | ||
/** Description of what this storage key holds */ | ||
desc?: string; | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** The type of the key */ | ||
keyType: ABIType | AVMBytes | StructName; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why does StorageKey have keyType? Isn't this for singular, known values? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes but I figured it's still useful to know the type for things like explorers and frontends There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So it's intended to indicate the encoding of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I'm a bit confused about what There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh wait, I think I see. So what should this and the Needing to have key as a base64 reduces the human readability of these files... I wonder if keyType should allow for a raw string to be used? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this would be the equivalent? key: Buffer.from('my key', 'utf-8').toString("base64"),
keyType: 'bytes', There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But then that doesn't let explorers etc. know that the key is actually a (non-ARC4) string? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be confusing to have some keys be ASCII encoded and some keys be base64, thus everything base64 makes the most sense to me. I'm not sure if human readability is all that important. If you want to make it human readable just through it into Lora (once supported). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Human readable is a nice feature though - makes it easy to see things at a glance, I've certainly found that useful in the past. Regardless if that's supported or not, it probably makes sense to support a keyType of Also, similarly we should probably have a key type of avm_address or similar to denote when you use the public key bytes of an address directly (i.e. non-ARC4 encoding). |
||
/** The type of the value */ | ||
valueType: ABIType | AVMBytes | StructName; | ||
/** The bytes of the key encoded as base64 */ | ||
key: string; | ||
} | ||
|
||
interface StorageMap { | ||
/** Description of what the key-value pairs in this mapping hold */ | ||
desc?: string; | ||
/** The type of the keys in the map */ | ||
keyType: ABIType | AVMBytes | StructName; | ||
/** The type of the values in the map */ | ||
valueType: ABIType | AVMBytes | StructName; | ||
/** The prefix of the map, encoded as a utf-8 string */ | ||
prefix: string; | ||
} | ||
``` | ||
|
||
### SourceInfo Interface | ||
|
||
This interface gives clients more information about the contract's source code. | ||
|
||
```ts | ||
interface SourceInfo { | ||
joe-p marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/** The line of pre-compiled TEAL */ | ||
teal: number; | ||
/** The program counter offset(s) that correspond to this line of TEAL */ | ||
pc?: Array<number>; | ||
/** A human-readable string that describes the error when the program fails at this given line of TEAL */ | ||
error?: string; | ||
} | ||
``` | ||
|
||
### Template Variables | ||
|
||
Template variables are variables in the TEAL that should be substitued prior to compilation. Template variables **MUST** be an argument to either `pushints` or `pusbytes`. Using these opcodes is important to ensure that the program does not add them to the constant blocks. | ||
|
||
#### Examples | ||
##### Valid | ||
``` | ||
pushints TMPL_FOO | ||
pushbytes TMPL_BAR | ||
``` | ||
|
||
#### Invalid | ||
|
||
Template variables MUST use pushints or pushbytes | ||
|
||
``` | ||
int TMPL_FOO | ||
byte TMPL_BYTE | ||
``` | ||
|
||
Template variables MUST be the entire argument | ||
|
||
``` | ||
pushints 123TMPL_FOO | ||
pusbytes 0xdeadTMPL_BAR | ||
``` | ||
|
||
## Rationale | ||
ARC-32 essentially addresses the same problem, but it requires the generation of two separate JSON files and the ARC-32 JSON file contains the ARC-4 JSON file within it (redundant information). The goal of this ARC is to create one JSON schema that is backwards compatible with ARC-4 clients, but contains the relevant information needed to automatically generate comprehensive client experiences. | ||
|
||
### State | ||
|
||
Describes all of the state that MAY exist in the app and how one should decode values. The schema provides the required schema when creating the app. | ||
|
||
### Named Structs | ||
|
||
It is common for high-level languages to support named structs, which gives names to the indexes of elements in an ABI tuple. The same structs should be useable on the client-side just as they are used in the contract. | ||
|
||
### Action | ||
|
||
This is one of the biggest deviation from ARC-32, but provides a much simpler interface to describe and understand what any given method can do. | ||
|
||
## Backwards Compatibility | ||
The JSON schema defined in this ARC should be compatible with all ARC-4 clients, provided they don't do any strict schema checking for extraneous fields. | ||
|
||
## Test Cases | ||
NA | ||
|
||
## Reference Implementation | ||
TODO | ||
|
||
## Security Considerations | ||
The type values used in methods **MUST** be correct, because if they were not then the method would not be callable. For state, however, it is possible to have an incorrect type encoding defined. Any significant security concern from this possibility is not immediately evident, but it is worth considering. | ||
|
||
## Copyright | ||
Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth indicating the default should be
[4, 28, 56]
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a comment saying all contracts implicitly support 4 and 56. IDK if we can say if all contracts support 28 if no events are emitted (and same for 22 with readonly)