Smart Contracts, EVM Design, and Consensus Mechanisms in Blockchain

Web3.0 aims to create a trust‑less interaction model based on deterministic software logic, which heavily relies on blockchain and smart‑contract technology.

Nick Szabo first defined a smart contract in 1994 as a computerized transaction protocol that executes contract terms while minimizing the need for trusted intermediaries.

Smart contracts must be verifiable, observable, and executable. They can reduce legal barriers and transaction costs.

02 From Bitcoin Script to Smart Contracts

Bitcoin supports smart contracts via a very simple stack‑based scripting language called script . It lacks variables and only has a single stack.

1 2 OP_ADD 3 OP_EQUAL

This script pushes 1 and 2 onto the stack, adds them (producing 3), pushes another 3, and then checks equality. Bitcoin script is deliberately non‑Turing‑complete (no loops) to avoid the halting problem, which would otherwise risk network paralysis.

Work‑arounds for the lack of Turing completeness include time‑outs (e.g., Fabric’s timeout) and gas‑based metering (Ethereum).

Gas and Transaction Fees

Ethereum introduces a gas metering system: each executed opcode consumes a certain amount of gas. The transaction fee is calculated as:

Transaction Fee = Gas Price * Gas Used (Gas Used <= Gas Limit)

Gas prevents infinite loops and spam transactions while reflecting the computational cost of contract execution.

03 EVM‑Based Smart Contracts

Ethereum provides the high‑level language Solidity and the Ethereum Virtual Machine (EVM), a stack‑based VM that executes opcodes independent of underlying hardware.

Typical EVM opcodes include PUSH1, ADD, EQ, etc. Example Solidity contract:

contract Counter {
function compare() external returns (bool) {
uint a = 1;
uint b = 2;
return a + b == 3;
}
}

Compiled with Solidity 0.1.5, the bytecode fragment is:

0x600060006001915060029050600381830114

Mapped to opcodes:

PUSH1 00
PUSH1 00
PUSH1 00
PUSH1 01
SWAP2
POP
PUSH1 02
SWAP1
POP
PUSH1 03
DUP2
DUP4
ADD
EQ

Simplified to:

PUSH1 0x1
PUSH1 0x2
ADD
PUSH1 0x3
EQ

The final stack result is 1, confirming that 1 + 2 = 3.

04 Design Trade‑offs in Smart‑Contract Development

White‑list mechanisms illustrate trade‑offs between simplicity, on‑chain storage cost, and decentralisation.

Simple on‑chain mapping:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.6;
import "@openzeppelin/contracts/access/Ownable.sol";
contract Artist is Ownable {
mapping(address => uint256) whitelistQuota;
function setWhitelistAddressQuota(address account_, uint256 quota_) external onlyOwner {
whitelistQuota[account_] = quota_;
}
function isWhiltelistAddress(address account_) public view returns (bool) {
return whitelistQuota[account_] > 0;
}
}

Storing thousands of addresses on‑chain can cost tens of thousands of dollars.

Signature‑based white‑list avoids on‑chain storage:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.6;
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
contract Artist {
using ECDSA for bytes32;
address private _signer;
constructor(address signer_) { _signer = signer_; }
function isWhitelistAddress(address account_, bytes memory signature_) public view returns (bool) {
bytes32 hash = keccak256(abi.encodePacked(account_));
return hash.recover(signature_) == _signer;
}
}

Merkle‑tree based white‑list combines low on‑chain cost with provable inclusion:

import MerkleTree from 'merkletreejs';
import keccak256 from 'keccak256';
class MerkleProofTree {
tree: MerkleTree;
constructor(addresses: string[]) {
this.tree = new MerkleTree(addresses.map(a => keccak256(a)), keccak256, {sort: true});
}
getRootHash(): Buffer { return this.tree.getRoot(); }
getProof(address: string): string[] { return this.tree.getHexProof(keccak256(address)); }
verify(proof: string[], address: string) {
const rootHash = this.getRootHash();
const nodeHash = keccak256(address).toString("hex");
return this.tree.verify(proof, nodeHash, rootHash);
}
}

Solidity verification:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.6;
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
contract Artist {
bytes32 private _merkleRoot;
constructor(bytes32 merkleRoot_) { _merkleRoot = merkleRoot_; }
function isWhitelistAddress(address address_, bytes32[] calldata proofs_) public view returns (bool) {
return MerkleProof.verify(proofs_, _merkleRoot, keccak256(abi.encodePacked(address_)));
}
}

05 Engineering Practices for Smart‑Contract Lifecycle

Because EVM bytecode is immutable after deployment, upgrades require proxy patterns. A transparent proxy forwards calls via delegatecall , keeping storage in the proxy while logic resides in a separate implementation contract.

The team built a contracts repository based on Hardhat to enforce CI/CD, code review, linting, ABI generation, and Go client generation. The workflow includes MR submission, automated testing, artifact publishing, and optional upgradeability checks (storage layout, constructor compatibility).

06 Consensus and the "High‑Energy Chain"

Traditional consensus algorithms (Paxos, Raft) assume non‑malicious nodes, while blockchain must tolerate Byzantine faults. Bitcoin and early Ethereum use Proof‑of‑Work (PoW), where miners solve SHA‑256 puzzles.

Proof‑of‑Stake (PoS) replaces computational work with stake‑weighted random selection, reducing energy consumption.

The "High‑Energy Chain" combines PoS, Proof‑of‑Authority (PoA), and an optimised PBFT. The three‑phase flow (Propose → Prevote → Precommit → Commit) requires >2/3 votes to finalise a block, improving efficiency while adding stake‑based voting weight and a white‑list of authorised validators.

About the Team

The authors are senior engineers from Bilibili, contributing to distributed time‑series databases, message queues, long‑connection services, and now focusing on Web3, smart contracts, and the High‑Energy Chain ecosystem.