Skip to main content

Alphabill EVM Partition

Solidity and the Ethereum Virtual Machine (EVM) were hugely significant contributions to the community. It is possible to celebrate these inventions while recognizing their limitations. Ethereum's implementation of smart contracts has one major limitation—it is based on shared memory, that is, it assumes a shared global state. This enables composability of smart contracts, but comes at the cost of scalability. Since the state is global, it must be able to be stored and manipulated in its entirety on every validator. This implies that the overall global state can never grow larger than can be processed by a single machine, and that computation cannot take place in parallel.

Alphabill implements an EVM partition as a system-defined partition as shown below. This partition enables developer to deploy Solidity programs, however, this partition is not shardable, due to the limitations described above.

Multiple EVM Partitions

For scalability, the Alphabill architecture allows multiple EVM partition instances to operate in parallel. Smart contracts deployed in different EVM partitions do not share memory and cannot call each other directly. Interoperability is enabled by exchanging proofs which can be verified due to the common root of trust.

Implementing an AMM Smart Contract​

In the above figure tokens live in the User Token Partition and an Automated Market Maker (AMM) contract lives on the EVM Partition. The mechanism to call a smart contract works without actually moving the token, only the predicate on tokens is changed to allow the smart contract to verify that it is the new owner.

The proof of a token being in the required state is sent to the contract with a subsequent transaction order, that is, the first transaction order is sent by the user to the token shard to lock the token (locking here means that only the specified smart contract can unlock it). A second transaction order is sent by the user to the smart contract address which includes the transaction request to the smart contract as well as the proof that the token has been locked.

A simplified constant product AMM contract would have two token pools in contract memory, with identifiers (the state tree address) of the tokens locked and sent by liquidity providers.

A user who wishes to swap tokens will send a transaction order to the contract's Swap() function, with locked token proofs as an argument. The contract will then calculate the amount of returned tokens from the pair using the constant product formula, and create unlocking proofs in its memory and terminate. Post block creation, the user can use the unlocking proof to claim ownership of the returned tokens.

Here is simplified pseudo-code:

function SwapToB(tokensA_in):
invariant = poolA * poolB // the product of pool sums is kept constant
new_poolA = poolA + tokensA_in
new_poolB = invariant / new_poolA
outB = poolB - new_poolB // sum of returned tokens B
transferTokenBTo(sender, outB) // creates unlocking proof(s)

The liquidity providers add new tokens to the contract pair-wise in order to maintain the exchange rate. When users see arbitrage opportunities they can make token swaps, which will bring the exchange rate close to the real world exchange rate.