🔵Part 4｜Technical Architecture and Innovative Design

Part 4｜Technical Architecture and Innovative Design

4.1 Overview of the overall technical architecture

StarChain adopts a full-link architecture system optimized for high-frequency entertainment transactions, including:

• HPOS consensus mechanism (Hybrid Proof of Stake)

• High-concurrency transaction sharding engine

• SLApp Smart Contract Low-Code Application Platform

• SCaaS (Smart Contract as a Service)

• Built-in burning billing model (supports multiple fee recovery and destruction channels)

• On-chain data visualization and application analysis module

This architecture focuses on solving three key problems:

⏱ High-frequency trading throughput bottleneck; ⚙️ Real-time application interaction response needs; 🔥 Application layer profitability and on-chain value closed loop.

4.2 HPOS consensus mechanism overall architecture (designed for high-frequency entertainment)

HPOS = Hybrid Proof of Stake

Intranodes only need to communicate with a small number (hundreds) of nodes in the same shard, greatly reducing storage, computing, and communication costs. Therefore, blockchain sharding is considered an important solution to improve the scalability and operational efficiency of blockchain. Based on blockchain sharding technology and consensus mechanisms such as POH, this paper proposes a new HPOS consensus mechanism. This section will describe the overall architecture of the HPOS consensus mechanism.

4.2.1 The HPOS mechanism integrates the following key components:

⛓ 1. PBFT

It guarantees 1-second transaction confirmation and strong consistency, and is suitable for real-time interactive entertainment scenarios, such as lottery draws, battle settlements, etc.

🧮 2. POH

Introduce a sequential proof mechanism similar to Solana to generate transaction ordering through a timestamp chain, improve TPS and reduce conflicts.

🎲 3. VRF

Provide on-chain verifiable fair randomness for on-chain entertainment, guessing, lottery and other applications, and build "on-chain trusted entertainment logic".

📣 4. NPOS

A committee of validators is chosen to generate blocks for the blockchain, and selection is based on the stake held by the validators, with those holding more stake having a higher chance of being selected. Once elected, validators take turns generating and validating blocks in a random manner.

4.2.2 Node type and selection mechanism

In the HPOS consensus mechanism, participating nodes are divided into general user nodes (GU), shard sequence generation nodes (SG) and shard sequence verification nodes (SV).

• Sequence Verification Node (SV)

SV nodes are responsible for verifying the transaction sequence generated by SG and broadcasting the results within the shard. Usually, the SV has the same computing power as the SG and can replace the SG when the SG fails.

• General User Node (GU)

In the HPOS consensus framework, GU does not directly participate in the consensus, but is randomly assigned to different shards and learns the latest status of the entire network through the P2P network.

• Sequence Generation Node (SG)

SG is responsible for sorting transactions within its shard, building a shard transaction sequence, broadcasting the transaction sequence within the shard using the Gossip protocol, and maintaining communication with SG nodes in other shards through the Kademlia protocol. Assume that the number of participating nodes in the blockchain system at a certain moment is n, and the number of participating nodes in each shard is m=c*log n (c is a constant, usually set to 20). If one SG node is set for each shard, the data simulation results are shown in Figure 1. SG needs to send the generated transaction sequence with digital signature to SV. According to literature results, the number of ECDSA (elliptic curve digital signature) generated per second by current advanced GPUs is about 10 times that of SV nodes, so the number of SV nodes in each shard can be set to 10 (with the same computing power).

^{_{Figure 1: Simulation of the number of shards and the number of nodes in a shard (n ranges from [1,000-100,000], with a step size of 2000).}}

HPOS consensus has certain requirements on the hardware performance of SG and SV, so the hardware performance of the node must be proven when it first enters the system. The proof mechanism is similar to POW, and the first 11k nodes are selected from n nodes. Subsequently, by running the NPOS protocol, the top k nodes with the most votes are selected from the 11k candidate nodes to form the network-wide consensus committee, and the remaining 10k nodes form the network-wide supervision committee, which can effectively avoid the "tragedy of the commons". With the help of VRF, each SG node and every 10 SV nodes will be randomly assigned to different shards, thus avoiding the collusion problem caused by fixing SG and SV in the same shard.

4.2.3 System startup period

The system startup period mainly includes the identification of SG and SV nodes and the process of allocating nodes to shards. To ensure a smooth startup period, a startup committee (IC) will be established during the system startup phase, consisting of 1/2 n nodes randomly selected from the n nodes in the entire network. Each node is randomly assigned to a shard based on its public key address when the system starts, and sends the shard number to the nearest IC node. All IC nodes aggregate the collected shard number information into a hash routing table, which is subsequently maintained by the shard's SG node.

During the system startup phase, the IC will organize and generate a network-wide consensus committee and a supervisory committee. The specific generation mechanism is as follows:

IC will verify the proof of work of the first 11k nodes out of the n nodes in the entire network, and determine k SG nodes and 10k SV verification nodes respectively. Iteration period: After the startup period, the system enters the iteration period. The time interval between each iteration is T, where T represents the first iteration. At the beginning of each iteration, the shards that SG and SV are responsible for are reallocated through the VRF function.

Note: During the iteration period, any user node is randomly assigned to a shard when entering the system. The transaction sequence generation node (SG) and 10 transaction sequence verification nodes (SV) within the shard together constitute the transaction verification sequence group. Each SV node verifies shard transaction sequence fragments in parallel, and the verification speed is usually 10 times the generation speed. When all SV nodes complete the verification, the verification results will be sent with signatures. If the independent verification results within the shard do not match the transaction sequence constructed by SG, SV will send an "alarm" to other nodes in the shard and run the PBFT protocol for re-verification. If more than 7 verification results are consistent, the SG is judged to be "faulty" and the SV with the most votes during the startup period will temporarily take over the SG until the next iteration to elect a new SG node. Under the HPOS protocol framework, each shard maintains a unique shard transaction sequence, but a unique transaction sequence is no longer set for the entire network. The transaction sequence of the entire network is simply the concatenation of the transaction sequences of each shard, and the transaction sequences between shards do not need to be sorted.

4.3 Concurrent execution and sharding optimization

StarChain has designed a two-layer mechanism based on state partitioning and independent sharding of the execution engine:

• State Sharding: Users/accounts write independent sub-states concurrently to avoid conflicts.

• Execution Parallelism: Multiple TXs are submitted to the execution engine synchronously and processed concurrently in a logical order.

• Local consensus group scheduling: prioritize high-frequency interactive scenarios (such as StarLotto and StarPoker) for group execution to improve response efficiency.

This mechanism ensures that StarChain can handle tens of thousands of transaction requests per second, meeting the throughput required for Web3 entertainment-level applications.

4.4 SLApp（Smart Contract Low-Code Application）

SLApp aims to build a smart contract platform that supports visual development, automated deployment, sandbox execution, and plug-in expansion.

SLApp proposes a visual development solution for low-code smart contracts, which greatly reduces the development threshold of smart contracts and provides possibilities for the rapid prosperity of the developer community. Low-code is a visual application development technology that extracts common business processes, logic, and data model modules in the development process to quickly build applications in the form of graphical building blocks. Therefore, developers of different experience levels can create smart contracts through graphical interfaces, drag-and-drop components, and model-driven logic. This technology not only eliminates the need for non-technical developers to write code, but also provides professional developers with the ability to customize their code.

Advantages of low-code technology:

• Learnability

Low-code or zero-code features greatly reduce the difficulty of learning programming languages. Especially the zero-code development platform, even business personnel who do not understand programming languages ​​can quickly learn and develop applications.

• Rapid Development

Through the development of a large number of components and encapsulation interfaces, combined with the IAAs and PAAS layer capabilities of cloud computing, development efficiency is significantly improved. Low-code can improve development efficiency by more than 30%, while zero-code can increase it several times while significantly reducing development costs.

• Code Quality

Low-code or zero-code platforms automatically generate (compile) executable code with better code quality than the industry average, more controllable errors (bugs), and higher security. Through SLApp, developers do not need to build DApp from scratch, but can directly reuse modules to quickly deploy interactive products on the chain.

4.5 SCaaS（Smart Contracts as a Service）

SCaaS is an automated deployment and operation and maintenance solution proposed by SLApp. Its technical solution inherits the idea of ​​serverless architecture and applies it to the service governance of smart contracts. Serverless smart contract programs do not run 24/7, but wait for requests to arrive, start instances to process requests, and shut down after completion.

SCaaS technical advantages:

• Maintenance-free: No server hosts or processes need to be managed.

• Pay as you go: Actual cost is determined by usage.

• High Availability: Built-in high availability support.

• Elastic scaling: Automatically scale and configure based on load, ranging from zero to unlimited.

Developers can directly publish to the entire network by submitting code/low-code. SCaaS technology runs the WASM virtual machine in the blockchain, providing developers with a sandbox-safe and efficient operating environment without restrictions on development languages ​​and with complete scalability.

4.6 WASM virtual machine

WebAssembly (WASM) is a binary instruction format based on a stack virtual machine. It is designed as a portable compilation target for multiple programming languages. It has the characteristics of small size and fast loading, and supports the deployment of client and server applications.

WASM advantages:

• Efficiency

WASM is small in size and loads quickly, and can fully utilize hardware capabilities to achieve native execution efficiency.

• Security

WASM runs in a sandbox environment and strictly abides by the same-origin policy and browser security policy.

• Open Source Standards

WASM is designed with a standardized text format to facilitate debugging, testing, and learning, while supporting the modular system interface WASI.

SLApp is compatible with Solidity/Vyper smart contract languages, and supports general languages ​​such as C/C++/Rust/Go/C#/Python. Sandbox technology ensures that smart contracts are safe, independent, lightweight and efficient. WASM is undoubtedly the best choice.

^{_{The following figure is a simple flow chart of SLApp’s implementation of smart contracts:}}

To sum up, SLApp attempts to provide a blockchain smart contract product that is easy to develop, automatically deployed, data secure and efficient in operation, from development process to deployment and maintenance, through cutting-edge technologies such as low-code, SCaaS and WASM.

4.7 API / SDK Development Toolset

StarChain opens the following support tools to the developer community:

• 🔧 SDK (Solidity/TypeScript/Python)

• 🔗 RESTful API / GraphQL data interface

• 🧩 Modular on-chain component packages (such as RNG, dividend pool, prize mechanism, etc.)

• 📊 Block Explorer + DApp Console

All tools support the full-process development collaboration of “quick launch → hot start → user growth”.

4.8 Block browser and on-chain monitoring visualization module

StarScan (official block explorer) has the following features:

• Visualization of on-chain account/contract transaction records

• DApp distribution and interaction intensity heat map

• Node distribution + block efficiency monitoring

• GAS Burning Ranking (View the Most Profitable DApps)

• Real-time statistics of developer revenue

Subsequently, the StarChain DAO governance and destruction progress visualization module will be integrated to achieve a “visible value flow” for the entire chain.