Architecture Overview
  • Welcome to Arcology Architecture Overview
  • Introduction
  • Streamer
  • Executor
  • Scheduler
  • Arbitrator
  • P2P
  • Frontend
  • Gateway
  • Pool
  • Signature Verifier
  • Core
  • Consensus
  • Merkle
  • Eth API
  • Storage
Powered by GitBook
On this page
  • Architecture
  • Benefits
  • Terminology

Introduction

PreviousWelcome to Arcology Architecture OverviewNextExecutor

Last updated 8 months ago

Blockchain can't defy the laws of physics—higher TPS demands more computational resources. In centralized systems, horizontal scaling is effective, but most blockchain projects use a single-thread, monolithic design (e.g., Geth for Ethereum) limited to one machine and core, hindering support for high-performance applications.

Architecture

Arcology is a high-performance, general-purpose system that requires a flexible, scalable, and loosely coupled architecture. An ED microservice architecture meets these needs, with key modules provided as independent, easily scalable services.

Event Broker

An event broker is middleware that connects and mediates communication among different modules. It follows a pub/sub model to receive, cache, and route messages to and from handlers. The broker is both inter-thread and inter-process, facilitating communication within the same process and across threads of multiple processes. This design enables cluster deployment, ensuring maximum scalability and flexibility.

Arcology features a specialized event broker known as Streamer, specifically designed to manage internal communications. For more information, please refer to .

Event Handler

An event handler is responsible for processing events received from the event broker. In Arcology, all major components, such as the transaction pool, EVM, StateDB, and others, are wrapped as event handlers. In Arcology, modules only communicate asynchronously via the event brokers and operate independently, with minimal awareness of one another. This design effectively decouples the functional modules.

Benefits

This design improves resource utilization and facilitates intra-node horizontal scaling, which involves adding more instances of the same module to manage increased workloads. In addition, depending on specific needs, an Arcology node can be configured to be either cost-efficient or performance-optimized.


Terminology

Node

A node is a combination of hardware and client software that function as an independent entity on Arcology network. For all other blockchains, a full node is usually a copy of client software installed on one machine, either physical or virtual.

Node Cluster

An Arcology node could also mean a group of machines connected by high-speed networks with multiple instances of functional modules installed. These machines will function just like one.

Client Software

An Arcology client is the software system that supports the functionality of an Arcology node. It can be installed on a single machine or a cluster of machines, depending on the configuration.

Intra-Process Broker (Streamer)

Streamer is an event management system built for Arcology. It's using the pub/sub pattern to work with multiple event handlers. A Streamer instance may also be connected to an inter-Process event broker (like Kafka) to handler event transmission across processes.

Inter-Process Broker (Kafka)

Arcology uses Apache Kafka to connect different Streamer instances.

Service

A service is a logical unit of worker threads(event handlers) connected by a Streamer instance. A service can be deployed, operated, and accessed independently.

Worker Thread(Event handler)

A worker thread is a functional unit doing a specific job independently of other workers. Worker threads are connected one Streamer instance. A worker acts on a certain combination of events and may also generate some events and send them to the Streamer instance as well.

this link
alt text