Basic Design

Contract Application Binary Interface (ABI)

The ABI is the mechanism by which external applications and other contracts interact with Ethereum smart contracts. Think of it as the "bridge" between two different systems, allowing them to understand and interpret each other's data.

Encoding

In order for this "bridge" to work effectively, we need a way to package (or encode) data so that both sides can understand it. This encoding process involves taking the data you want to send, and transforming it into a format that the Ethereum Virtual Machine (EVM) can understand and process. However, this encoding is not "self-describing". What this means is that the encoded data doesn't contain metadata about what kind of data it represents (like whether it's a number, a string, etc.).

Schema Requirement

Because the encoding isn't self-describing, a schema is necessary to decode it. A schema is like a blueprint or a guide; it tells you what type of data to expect and how to interpret it. For example, if you know that the encoded data represents a string followed by a number, you can decode it correctly.

Assumptions

1. Strongly Typed Interface Functions: This means that the data types for the inputs and outputs of a contract's functions are explicitly defined and not ambiguous. For instance, a function will specifically state that it takes in a uint256 (an unsigned 256-bit integer) rather than just "some number".

2. Known at Compilation Time and Static: The contract's interfaces (i.e., the functions it exposes for interaction) are defined and unchanging once the contract is compiled. They aren't determined dynamically at runtime.

3. Availability of Interface Definitions: If Contract A wants to call a function on Contract B, Contract A needs to know how to properly call that function. This means that Contract A should have the ABI for Contract B available at the time it's compiled.

What's Not Addressed

The specification doesn't cover scenarios where a contract's interface might change during runtime or is only known when the contract is running. This kind of dynamic behavior is outside the scope of the standard ABI.

In simpler terms, the ABI is like a translator that helps two parties (a contract and an external actor) understand each other. For this translator to work effectively, both parties need to agree on a "language" or format, and this agreement is established using a schema. This "language" doesn't change once it's set, ensuring consistent interactions.