SDKs: Replace logicsig langspec checks with self-contained checks

[michaeldiamant]

Problem

After each go-algorand AVM release, all SDKs require updated langspec.jsons + new tests as per https://algorand.atlassian.net/wiki/spaces/SCY/pages/2346844170/Updating+SDK+Langspecs. To minimize work needed per AVM release, the story requests replacing the existing assertions with equivalents (or near equivalents) that do not rely on a langspec.json artifact.

Example existing implementation from py-algorand-sdk: https://github.com/algorand/py-algorand-sdk/blob/f0509ba40f8ca02c02cc254ea80e5bdbfa2aa9a8/algosdk/logic.py#L45. Each SDK provides analogous checks.

The replacement checks must confirm the provided program:

• Is not base64 encoded. Since the input is bytes, a common class of mistake is to supply a base64 encoded input. Other plausible mistakes are to send TEAL source, or empty bytes.
• Contains TEAL bytecode. While the new check won't inspect particular opcodes, it feels prudent to confirm the input resembles TEAL.

As part of the investigation, consider paring down langspec.json to remove unnecessary fields (e.g. budget). We may ultimately create a separate story, but ought to consider the topic while in the neighborhood.

Solution

Dependencies

Urgency

[ahangsu]

The first round investigation result follows:

For Go/JS/Py/Java-SDK: we need to deprecate methods in Logic:

• readProgram
• checkProgram,

deprecate global variables under Logic:

• spec/langspec
• opcodes
• logicVersion
• evalMaxVersion.

Related methods using readProgram: LogicsigSignature constructor and LogicsigSignature.verify.
Related methods using checkProgram: only in template, and template is already marked deprecated.

Solution: implement another sanityCheckProgram method in Logic to substitute readProgram, and replace readProgram in 2 uses under LogicsigSignature.

[ahangsu]

Possible deprecation schemes cross SDKs:

• go: mark code as deprecated, applies for both function, struct and variable: https://stackoverflow.com/questions/7849663/how-do-you-mark-code-as-deprecated-in-go
• py: mark function/class as deprecated: use Deprecation library: https://stackoverflow.com/questions/2536307/decorators-in-the-python-standard-lib-deprecated-specifically, https://github.com/briancurtin/deprecation
• js: mark code as deprecated, applies for method: https://stackoverflow.com/questions/19412660/how-should-i-mark-a-method-as-obsolete-in-js
• java: mark code as deprecated, applies for methods, class def, class variable: https://stackoverflow.com/questions/9031832/how-to-declare-or-mark-a-java-method-as-deprecated

[ahangsu]

Another sub-conclusion from deprecating langspec.json: The readProgram and checkProgram relies on knowledge of opcode size, i.e., how many bytes opcode segment totally occupy.

Without such knowledge, one cannot start meaningful test over byte string like disassemble-alike test, other than checking byte code complying to a certain TEAL version. Some other heuristic need to be figured out, without a list of ops with knowledge of size.

[ahangsu]

JJ made some suggestions:

1. check that first byte is between 0-7 (roughly. goes up with AVM version)
2. check that it doesn’t look b64 encoded, or an encoded algorand address
   a. but both of these are unneeded if you do 1
3. check that it doesn’t contain all ascii printable characters (so it’s not teal source)
   a. this will matter when v10, since programs can start with newline, which is 10.

[michaeldiamant]

Informational: I opened #223 to track following up in a later iteration to remove deprecated fields, methods, classes, and langspec.json resource file.

[michaeldiamant]

For reader ease, here's the associated PRs:

• Deprecation of langspec testcases #225
• Enhancement: Deprecating use of langspec go-algorand-sdk#366
• Enhancement: Deprecating use of langspec java-algorand-sdk#367
• Enhancement: Deprecating use of langspec js-algorand-sdk#632
• Enhancement: Deprecating use of langspec  py-algorand-sdk#371