EVM Storage

Introduction

Blockchains are, at their core, distributed databases. This means they have to persistent data between transactions.

On EVM based blockchains, this data is stored, per contract, in a key-value store called the storage layer.
Both the keys and the values in this layer are 256-bit numbers and the keys are referred to as storage slots.

Accessing Storage

The Ethereum Virtual Machine (EVM) has a two instructions for accessing storage: SLOAD and SSTORE.
Using these instructions, a contract can read and write to specific storage slots.

This is all well and good, and technically achieves the goal of storing data between transactions, but it's not very user friendly.

Enter Solidity.

Solidity is a high-level language that compiles down to EVM bytecode. In solidity, the developer defines contracts in much the same way as classes in object-oriented languages. This means that the developer can define variables and functions on the contract.

When the contract is compiled, any variable that isn't constant is assigned an appropriate number of slots in storage. The developer can then access these variables in the contract the the solidity compiler handles the messy business of fetching the value stored.

SendBlocks Storage Triggers

Here at SendBlocks we want to make it as easy as possible for developers to build on the blockchain.
To that end, we've combined the power of realtime blockchain analysis and static solidity parsing to allow our users to set triggers on changes in specific contract variables.

Slot Triggers

The most basic type of storage trigger is a slot trigger. This trigger is set on a specific storage slot and will fire whenever the value in that slot changes.

Contract Analysis

Assuming a contract's source is available, we can parse the solidity code (using Analyze Contract) and determine which variables are stored in the contract's storage layer. This information is referred to as the contract's storage layout.

Once analysis is finished, the storage layout can be retrieved using the Get Analyzed Contract endpoint and storage triggers can be set on the contract's variables (as opposed to the raw storage slots).

Variable Triggers

Assuming a contract was previously analyzed, by you or someone else, you can set a trigger on a specific variable in the contract. This is done by using the variable name directly and so allows you to completely ignore the underlying storage slots.

Mappings and Dynamic Arrays

Solidity has two special types of variables that are stored differently than normal variables: mappings and dynamic arrays.

By setting triggers on these types of variables, you will be notified whenever a specific key/index is added, removed, or changed. Keep this in mind when setting your triggers and make sure to get a firm grasp on the data they come with.