BitShares EVM integration, Solidity contracts in a private Graphene fork

How Aetsoft embedded
an EVM in a private BitShares fork

Get in touch now

Solidity contracts held and moved native assets in a BitShares-derived chain, with no bridge and no token standard in between.

BitShares shipped without a virtual machine. Its logic lives in fixed operations compiled into the node binary, so a developer could build only what the core team had already written.

Starting in 2017, Aetsoft forked the BitShares codebase, embedded an Ethereum Virtual Machine, and turned contract calls into first-class chain operations. Development of the internal platform continued through Q2 2019.

001

Research context

Aetsoft internal Layer 1 protocol RnD.

002

Technical question

Can a Graphene chain execute Solidity contracts against its own native assets?

003

What was built

An embedded EVM, a system contract bridge into native assets, and a gas model layered on the existing chain fee.

The question:
where do you put code on a chain with nowhere to put it?

BitShares is fast, and it is opinionated. Every action is a typed operation with a fixed evaluator compiled into the node. Transfers, limit orders, asset issuance.

If the operation exists you can use it. If it does not, you fork the node and ship a new binary to every witness.

That design is part of why the chain runs one second blocks. It also meant a developer could only ship what the core team had already written.

Ethereum answered the same question with a virtual machine and a charge for the cycles. By 2018 that had produced a large body of tested Solidity code, and none of it would run on a Graphene chain.

The assets were the reason to close that gap from inside the node. On a Graphene chain, user issued assets and market pegged assets are objects in the chain state. Move them out to an execution environment elsewhere and they arrive as representations of themselves, with whatever bridge produced them standing in the path. Keep the execution inside and a contract holds the asset.

So the machine went into the evaluator. Aetsoft embedded the EVM libraries from Aleth, the C++ Ethereum client, and a contract call became a chain operation running do_evaluate and do_apply the way a transfer does.

Pic

Ethereum answered the same question with a virtual machine and a charge for the cycles. By 2018 that had produced a large body of tested Solidity code, and none of it would run on a Graphene chain.

The assets were the reason to close that gap from inside the node. On a Graphene chain, user issued assets and market pegged assets are objects in the chain state. Move them out to an execution environment elsewhere and they arrive as representations of themselves, with whatever bridge produced them standing in the path. Keep the execution inside and a contract holds the asset.

So the machine went into the evaluator. Aetsoft embedded the EVM libraries from Aleth, the C++ Ethereum client, and a contract call became a chain operation running do_evaluate and do_apply the way a transfer does.

Architecture

Two identity systems over one object graph

Embedded EVM execution inside a BitShares block and operation evaluator

Graphene addresses objects as a triple of space, type and instance. The EVM addresses everything as twenty bytes. Solidity assumes the second and will not compile against the first.

Aetsoft mapped one onto the other. Every address in the chain corresponds to exactly one twenty byte value, and the mapping runs both ways. Contracts then got their own object space at 1.16.x, created by ordinary accounts sending bytecode, with transaction receipts landing in a space of their own at 1.17.x.

Contract accounts came out of that as a new kind of participant. They hold assets and receive transfers. They hold no keys, so they cannot sign or broadcast. Graphene's permission model had carried nothing like it before.

A system contract as the way into native operations

Solidity could now run. On its own that would have produced a chain where contracts talk to contracts and ignore everything the host was good at.

The system contract closed that. It sits at a predefined address. Calling it from Solidity reaches eleven native operations, covering balances, transfers by asset symbol, and asset creation.

The useful part is the addressing. Solidity asks for an asset by its symbol. Ethereum has no equivalent, because outside ETH every asset there is a separate contract whose address you have to know first. Anyone doing smart contract development against a custom chain meets that difference early.

Gas on top of a fee model that already worked

BitShares charges a flat fee per operation, set by the committee, and splits the proceeds so referrers and workers get paid. Ethereum meters each opcode. Both models had to survive the merge.

Aetsoft kept both. A contract call costs the operation fee plus gas, at a price the committee sets the way it sets every other chain parameter. The fee half flows into the existing distribution machinery untouched. Callers supply their own gas limit at the call site, the way an Ethereum transaction does.

Undo sessions, and the part that was genuinely hard

Graphene keeps a stack of state sessions so the node can unwind blocks during a chain reorganisation. The stack is sized as the head block minus the last irreversible block plus one, and when it is full the oldest entries drop off the front.

EVM semantics need a revertible frame per call, and a contract calling a contract calling a contract needs one per level. Aetsoft used the same undo stack, opening a session at the start of every call and sub-call and merging or reverting it on return.

Those two uses collide. Reorganisation safety wants the oldest sessions kept. A deep call chain pushes many new ones. Under the normal ceiling, the second evicts the first while the contract is still running.

The fix was blunt and it held. Raise the ceiling to 9,999 for the duration of a call, then restore the previous value. That is the class of problem that only appears once the machine is inside the chain.

Deciding what counts as a transfer

Ethereum still carries a split here. Sending ETH to a contract runs its fallback function. Sending an ERC-20 token runs nothing, because the token is a separate contract updating its own ledger. Later standards were proposed to close that gap, and ERC-20 remains the one in use.

In the blockchain platform the assets are native, so value arriving at a contract is visible to the chain whatever the asset is. Every asset triggers the fallback, core or otherwise. The gap closed by itself.

Which raised a question the team had to answer deliberately. Issuing an asset puts new units on a balance, and that balance can belong to a contract. Should issuance run the fallback?

The engineering team also had to decide what should happen when new assets were issued directly to a contract. Aetsoft considered rejecting such transactions, because issuance would update the contract’s balance without running its fallback function. Then the team ultimately allowed it: transfers triggered contract execution, while issuance changed the balance without calling contract code.

Solidity bytecode executed as a native chain operation. Contract code and contract state sat in the chain's object database. The evaluator read that state during execution and committed the result back to it, with no separate EVM state field added to the block header.

What the build demonstrated

Contracts held the chain's native assets, moved them by symbol, and issued new ones, with no token standard in between.

Frequently asked questions about EVM in a private BitShares fork

  • Can you add smart contracts to a blockchain built without them?

    Two common approaches exist. You can host a virtual machine beside the chain and bridge assets across to it, or you can embed the machine in the node so that contract calls become native operations. Aetsoft took the second approach on a Graphene codebase, which let Solidity contracts reach native assets with no bridge in the path. Either route is worth settling before the architecture is fixed, and it is a common starting point for blockchain consulting work.

  • How do gas and fixed operation fees work together?

    Both models stay. The chain keeps its committee set operation fee and its existing distribution logic, and gas is metered on top at a gas price the committee also sets.

  • Why does a seven year old research programme still matter?

    Because the same problem keeps arriving in new clothing. Chains that start with a fixed operation set tend to meet a business needing logic the core team never wrote. Putting an execution environment inside the node remains the route that keeps contracts holding native assets.

Working on an execution layer, a custom chain, or protocol level blockchain development?
Contact sales
Pic

Reusable verification on a healthcare blockchain

Logo
Pic

Product engineering for StreamWolf

Logo
Pic

Kaltura live Cloud TV platform

Logo
Pic

EVM in a private BitShares fork

Logo
Pic

Multi-tier blockchain protocol

Logo
Pic

Securities
tokenization platform

Logo
Pic

Velocity Career
Labs

Logo
Pic

Engineering inside BitShares Core

Logo
Pic

Blockchain core development for an EVM layer 1

Logo
Pic

AI assistant for loyalty management

Logo
Pic

VPLedger: a layer 1 blockchain

Logo
Pic

Balancer AMM for a better token access

Logo
Pic

DEX aggregator

Logo
Pic

CEX-DEX hybrid crypto exchange

Logo
Pic

DEX for PSP

Logo
Pic

Performance monitoring solution for green energy

Logo
Pic

Blockchain Loyalty Platform

Logo
Pic

STO platform

Logo
Pic

Digital currency solution

Logo
Pic

Blockchain voting solution

Logo
Pic

Car eService book

Logo
Pic

DAO space

Logo
Pic

NFT marketplace for creators

Logo
Pic

Metaverse rooms sports

Logo
Pic

Metaverse rooms

Logo
Pic

FreeStyle NFT

Logo
Pic

Data provenance solution

Logo
Pic

Internet-of-crops platform

Logo
Pic

DLT solution for smart logistics

Logo
Pic

Pipe trading platform

Logo
Pic

Tea exchange platform

Logo
Pic

genEOS

Logo
Pic

BitShareScan

Logo
Pic

Crypviser

Logo
Pic

Decentralized trading platform

Logo
Pic

DEX mobile wallet

Logo
All case studies