Engineering the L3COS multi-tier blockchain protocol
and application layer
L3COS defined an operating concept with three classes of participant. Aetsoft engineered the protocol implementation and built the institutional applications above it, from Q2 2019 to Q2 2020.
L3COS brought Aetsoft a concept for a blockchain operating system with three classes of participant: governments, enterprises and individuals. Each class was admitted on its own terms and secured by its own consensus model, over one shared ledger. Aetsoft designed the technical architecture and built the software, from the protocol implementation and the account and asset controls through to contract execution, testing and the applications above it.
001
ClientL3COS, a blockchain operating system designed around three classes of participant
002
ChallengeTurn a three-tier operating concept into a working protocol and the institutional applications above it
003
SolutionProtocol engineering across consensus, accounts, permissions, assets and contract execution, with a full application layer
004
EngagementQ2 2019 to Q2 2020
One ledger, three classes of participant
The concept L3COS brought was a three-level consensus operating system, where a national government, a corporation and a private citizen could transact on one ledger without being treated as the same kind of participant. L3COS had spent years developing that operating concept. In Q2 2019, Aetsoft was engaged to design the technical architecture and build the working platform.
Most enterprise chains permission the whole network and apply one consensus model to everyone, which produces an even network of unequal participants. This design went the other way. Each class was admitted on its own terms, held its own authority, and was secured by its own consensus mechanism. That is unusual, and harder to build than it sounds.
Consensus decides who writes the next block. Permissions decide everything else, and on a network designed for government participation they carry most of the load. Permissions are modelled around accounts and organisations, with keys acting as signing instruments. An account can be controlled by a weighted combination of other accounts and keys. An action goes through once the combined weight crosses that account's threshold.
Each account also carries an owner authority for recovery and permission changes, alongside an active authority for routine operations. The result mirrors how an institution signs. A company account could require its board, and any board member could carry an additional signing requirement.
Hierarchies like that are awkward in practice. Evaluating one can take unbounded time, and two accounts can end up each waiting on the other. Aetsoft bounded the traversal and added detection for circular approval dependencies, so deep structures stay predictable and a cycle is caught before it locks anyone out.
The asset model was designed to support controlled issuance and transfer. An issuer could define who may hold a token, restrict the markets it trades in, and restrict transfers between holders. They could also maintain a fee pool, so that users pay fees in the asset they already hold. Collateralised assets track an external price feed.
Three consensus models
001
Proof of Government
Proof of Government secures the top level. It holds 195 predefined accounts, one for each country, activated when that government joins. There is no stake and no auction, so admission works more like an authority based scheme than proof of stake. Each account runs a full node and signs blocks.
Control is split by multisig across the executive, legislative and judicial branches, so no single office could act for a country alone.
002
Delegated Proof of Stake
Delegated Proof of Stake secures the operational level for enterprises. Block producers are elected by approval voting and take turns on a fixed rotation. Committee members propose parameter changes, which stakeholders can reverse during a review period.
Admission was not open. Producing blocks depended on standing as a recognised entity, not on votes alone.
003
Proof of Storage
Proof of Storage secures the individual level, where people earn by hosting data. A storage agreement fixes duration, provider count and disk space at the start. Availability is then policed by challenge and response. The contract issues pseudo-random requests, the provider answers with specific nodes of a Merkle tree built from the original file, and the answers are checked against values recorded at upload. Files stay encrypted and are addressed over IPFS.
A provider that stops answering loses its earnings while the data is replicated elsewhere.
Execution
Sequential execution and a metered smart contract engine
Ordered business logic runs on a single thread, with validation and network handling moved to the edges so the sequential path carries only the work that must be sequential.
Above it sits the contract engine. It is a stack machine with a 256 bit word, and it keeps storage separate from volatile memory. Execution is metered in a unit called L3CG, which bounds the work any single call can do. Frequent operations are handled natively by the protocol, and the engine carries custom smart contracts, including those written in Solidity. Most transactions never reach it.
Aetsoft built the tests alongside it: unit tests in C++, integration and smoke tests in Python covering contract loading and execution, and performance testing.
The application layer
A protocol on its own gives an institution nothing to do. Aetsoft built the layer that makes it operable.
The business process management system
This ran the everyday work of the platform.
A company applied to join. The system took it through screening, recorded who approved it, and wrote the account to the chain. Later, two companies agreed a deal. The system gathered the approvals each side needed, checked that everyone approving was entitled to, and only then let the contract move any money.
Nothing moved forward until the right people had signed. The chain already knew who was allowed to sign what, so the work was in connecting a business process to that, so each stage could check the one before it.
The deposit management system
This tracked money that sat outside the platform.
The funds themselves stayed in accounts elsewhere. The chain held a record of who owned what, with rules about who could hold it and where it could move.
Keeping the two in step was the hard part. The outside balance and the on-chain record had to agree at all times, not once a night. A record that drifts from the money it represents is worse than no record at all.
Everything else
Aetsoft also built the marketplace, the supply chain module, the exchange, the block explorer and the dashboards for each type of user, plus the connections to the screening providers.
The government dashboard covered registering and suspending companies and approving network changes. The company dashboard covered issuing assets, trading and voting. The individual dashboard covered holding assets and providing storage.
Aetsoft's engagement ended in Q2 2020. Later products and announcements fall outside this engagement.
Design decisions
and trade-offs
-
Decision
A separate consensus model for each participant class.
-
Why
Governments, enterprises and individuals are admitted on different terms and cannot be secured by one rule.
-
Trade-off
acceptedCross level transactions need deliberate handling.
-
Decision
One shared state beneath three consensus models.
-
Why
Separate ledgers would not provide one authoritative state across participant classes.
-
Trade-off
acceptedEvery tier interaction has to be reasoned about explicitly.
-
Decision
Ordered logic on one thread, parallel work at the edges.
-
Why
Ordering decides correctness, so the sequential path carries only what must be sequential.
-
Trade-off
acceptedThroughput on that path is bounded by a single core.
-
Decision
A metered contract engine with common operations handled natively.
-
Why
Common transactions avoid interpreter overhead.
-
Trade-off
acceptedTwo execution paths to maintain and keep in step.
-
Decision
Storage proved by challenge and response
-
Why
Trusted reporting would not provide cryptographic evidence that the data remained available.
-
Trade-off
acceptedContinuous verification traffic for as long as data is held.
-
Decision
Bounded traversal and cycle detection in the permission hierarchy.
-
Why
Deep authority structures must stay computationally predictable.
-
Trade-off
acceptedA ceiling on how deep a hierarchy can go.
Results
“Aetsoft's professionalism was impressive.”
Executive, L3COS. Verified Clutch review.
A working protocol with three consensus models, a shared state, a hierarchical permission system and a metered contract engine, delivered in one engagement from Q2 2019 to Q2 2020.
Working modules across the application layer, from institutional workflow and deposit management to the marketplace, exchange, dashboards and explorer. Unit, integration, smoke and performance tests were built alongside the protocol.
Frequently asked questions about multi-tier blockchain protocol
-
What is a multi-tier blockchain architecture?
It is a design where different classes of participant operate under different admission and consensus rules on one shared ledger, rather than under a single model applied to everyone. L3COS uses three levels.
-
What did Aetsoft build for L3COS?
Aetsoft engineered the protocol implementation and the ecosystem above it. That covered three consensus models, the account and permission system, the asset controls, and the contract engine with its tests. It also covered the applications, from institutional workflow and deposit management to the marketplace, exchange and participant dashboards.
-
What was the L3COS protocol written in?
The protocol core is C++, chosen for control over memory layout and execution order. Go carries the surrounding services, where concurrency and network handling matter more. Contracts are written in Solidity and executed by a metered engine built into the protocol.
-
How is Proof of Government different from Delegated Proof of Stake?
Delegated Proof of Stake selects block producers through token weighted voting, so support determines who produces. Proof of Government fixes membership at 195 accounts, one per country, activated when a government joins. Admission is by sovereign accession rather than by stake.
-
How long did Aetsoft work with L3COS?
From Q2 2019 to Q2 2020, covering protocol engineering and application development in one continuous engagement.
Aetsoft builds protocols and the systems that make them usable: consensus, permissions, asset controls, contract execution and the applications above them. See how our blockchain development work covers each layer.
