Inter-contract Analysis
TSA allows to analyze intaraction of several contracts. This can be done in custom-checker or inter-contract modes.
If you want to use a message which was generated in some contract as an input of some other contract, you need to set communication scheme.
It is a JSON file that is passed with --scheme CLI option.
Communication Scheme Format
The expected JSON is an array of contract handlers (one handler for each contract).
1
2
3
4
Contract handler:
- id: Int
- inOpcodeToDestination: Map<String, DestinationDescription>
- [optional] other: DestinationDescription
The keys in inOpcodeToDestination are hex strings of length 8 that represent opcodes (the first 32 bits of message body).
Field other specifies destinations of messages
that were generated by contract id when its input message body
either had length less then 32 bits or started with opcode that wasn’t specified in inOpcodeToDestination field.
Message destinations can be described in two formats: linear and out_opcodes. The chosen format is specified with type field.
1
2
3
Linear destination description:
- type: String = "linear"
- destinations: Array<Int>
destinations must be an array that has the same size as the expected number of sent messages. The contents of the array are ids of destinations contracts.
1
2
3
4
Destination description based on out opcodes:
- type: String = "out_opcodes"
- outOpcodeToDestination: Map<String, Array<Int>>
- [optional] other: Array<Int>
outOpcodeToDestination is a map where keys are hex strings of length 8 that represent opcodes of the outgoing messages.
If an outgoing message has length less than 32 bits or its opcode isn’t specified in outOpcodeToDestination, then its destination is described with other field.
The arrays in the values of outOpcodeToDestination and in other field mean that all given contract ids are considered potential receivers.
Usually the receiver is one concrete contract, in this case the array size must be one.
Example: scheme for jetton-wallet
Contract 1: jetton-wallet 1 owner.
Contract 2: jetton-wallet 1.
Contract 3: jetton-wallet 2.
Contract 4: jetton-wallet 2 owner.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[
// Contract 1 sends all messages to contract 2
{
"id": 1,
"inOpcodeToDestination": {},
"other": {
"type": "out_opcodes",
"outOpcodeToDestination": {},
"other": [2]
}
},
{
"id": 2,
"inOpcodeToDestination": {
"0f8a7ea5": { // op::transfer
"type": "out_opcodes",
"outOpcodeToDestination": {
"178d4519": [3] // op::internal_transfer
}
}
}
},
{
"id": 3,
"inOpcodeToDestination": {
"178d4519": { // op::internal_transfer
"type": "out_opcodes",
"outOpcodeToDestination": {
"d53276db": [1], // op::excesses
"7362d09c": [4] // op::transfer_notification
}
}
}
},
// Contract 4 doesn't send any messages
{
"id": 4,
"inOpcodeToDestination": {}
}
]