UNITS: Reimagining Transaction Processing Systems for Privacy and Scale

At the heart of the Finternet, UNITS brings together scalability, privacy, and cryptographic integrity.

Introduction: The Finternet Vision

Finternet represents a paradigm shift in how we think about digital identity and value. At its core, Finternet aims to develop a user-centric system where individuals can tokenize their credentials and assets, empowering them to utilize these tokens in programmable workflows. What sets Finternet apart is its user-first approach—placing individuals at the center of their financial ecosystem with full ownership verification capabilities.

Within this ambitious initiative lies UNITS (Universal Information Tokenisation System), Finternet's transaction processing system, which forms the foundation for tokenization and transactions. UNITS has been architected with three critical requirements:

1. High Throughput: Capable of processing billions of transactions daily

2. Instant Verifiability: Enabling real-time system auditing without waiting for multi-day or multi-month expensive audit periods by external auditors

3. Privacy by Default: Preserving confidentiality while maintaining system integrity

In this article, we explore how UNITS leverages different design constraints to optimize and tailor existing blockchain architectures to its specific needs. We will:

1. Begin with an overview of Finternet and UNITS

2. Examine the current state of blockchains and ZK rollups

3. Analyze how Finternet's design constraints differ from traditional approaches

4. Detail our implementation using the Starknet Stack

   • Benchmark performance results

   • Horizontal scalability achievements

5. Present current UNITS Engine developments and our roadmap ahead

The Current State of Decentralized Blockchains

Traditional decentralized blockchains have excelled in solving write access control lists (ACLs), providing robust mechanisms for determining who has access to transfer tokens or change states. They achieve this through consensus mechanisms that validate transactions and state transitions before they're committed to the ledger.

However, these systems struggle with read ACLs—controlling who can access and view data. The core issue stems from their verification model: most decentralized blockchains verify transactions through re-execution. This approach fundamentally undermines privacy since all transaction data must be shared with every validating node that joins the network.

Consider Ethereum or Bitcoin—to validate the current state, new nodes must download and process the entire transaction history. This transparency is a feature for public trustlessness but becomes a limitation when privacy is required. As mentioned in our UNITS technical doc:

If we divide permissions into two types - read and write, then most of the current blockchain world ONLY enforces write permissions. This means, it's impossible to change state of a token without authorization from the owner of the token themselves.

However, one of the criteria of being a public blockchain is that nodes can join the network permissionlessly and replicate the state of the chain on their hardware. As a result, there's no merit in defining read permissions. The entire state of any public chain can be synced on anyone's hardware and there's no confidentiality of state.

While there's promising research in Fully Homomorphic Encryption (FHE) that would allow computation on encrypted data in a decentralized manner, these technologies haven't yet reached production scale in terms of performance and available tooling.

Evolution Through ZK Rollups

Zero-Knowledge (ZK) rollups represent a significant architectural evolution in blockchain technology. To understand their innovation, we must first grasp the power of zero-knowledge proofs.

The ZK Primer

Zero-knowledge proofs are cryptographic methods that allow one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. In practical terms, this means proving the output of a program is specifically S without revealing the inputs used to generate that output. For a deeper understanding of this fascinating technology, we highly recommend watching this explanation by Eli Ben-Sasson, co-inventor of ZK technology.

What makes ZK proofs particularly valuable for scaling is their verification efficiency. While generating proofs might be computationally intensive, verification typically requires only logarithmic time (logn) relative to the computation being proven.

ZK Rollups: The Scalability Breakthrough

Rollups leverage this verification efficiency to scale blockchain throughput. Instead of executing all transactions on the resource-constrained base layer (like Ethereum), transactions are processed off-chain in a "rollup" and only the cryptographic proof of valid execution is posted to the base chain. This architectural pattern reduces the computational burden on the base layer while inheriting its security guarantees. This is a heavily researched field today, with multiple ZK Rollups already live on Ethereum - you can find a comprehensive list on L2Beat's scaling summary.

Screenshot from the L2beat website showing top ZK Rollups on Ethereum by Total Value Locked

The Privacy Paradox in Current Rollups

Here's where nuance becomes important: despite utilizing zero-knowledge technology, most ZK rollups today aren't truly "zero-knowledge" in the privacy sense. They use validity proofs (a superset of ZK Proofs) to ensure computational integrity but deliberately make transaction data public.

This design choice isn't due to technical limitations but rather aligns with the decentralization ethos. If the rollup operator were to suddenly disappear, the public availability of transaction data would allow anyone to reconstruct the system and continue operations. This data availability guarantee ensures that users aren't locked into a single service provider.

Finternet's Different Design Constraints

Finternet operates under different constraints than public blockchains or traditional ZK rollups, which opens new architectural possibilities. Here are the key distinctions:

1. Privacy Model: The initial implementation adopts a private-to-operator model where the UNITS operator maintains read access to all data while enforcing user-specific read permissions.

2. Write Access Control: The UNITS operator has no write access to data, with any manipulation or duplication of data being instantly detectable through cryptographic proofs (similar to traditional ZK rollups).

3. Single Operator Model: The architecture only requires UNITS being operated by a single entity (contrary to public blockchains). Finternet, however, can support multiple UNITS instances all composable, allowing market forces to reduce single point of failure

Taking this from our UNITS technical doc (view here):

If we divide permissions into two types - read and write, then most of the current blockchain world ONLY enforces write permissions. This means, it's impossible to change state of a token without authorization from the owner of the token themselves.

However, one of the criteria of being a public blockchain is that nodes can join the network permissionlessly and replicate the state of the chain on their hardware. As a result, there's no merit in defining read permissions. The entire state of any public chain can be synced on anyone's hardware and there's no confidentiality of state.

Leveraging the Starknet Stack for UNITS

Given these unique constraints, the Finternet team identified Madara, an open-source implementation of the Starknet (SN) Stack, as a potential match during the UNITS benchmark exercise. This decision, during the proof-of-concept, is grounded in both technical capability and proven cryptographic expertise.

Starknet stands as one of the oldest ZK rollups on Ethereum, developed by StarkWare—a company founded by co-inventors of foundational zero-knowledge technology. The SN Stack leverages Cairo, a domain-specific programming language designed specifically for efficient zero-knowledge proving.

Cairo's similarity to Rust makes it accessible to developers while offering unparalleled efficiency in ZK proof generation. This efficiency is critical for UNITS, as it directly impacts infrastructure costs when operating at scale. StarkWare's benchmarks demonstrate Cairo's advantage in proving performance compared to other ZK-capable languages. The cost of proving is expected to be one to two orders of magnitude cheaper with Starkware's latest prover Stwo and Cairo compared to other provers and VMs.

Image showing Starkware's next gen prover's (Stwo) performance compared to other ZK VMs

Benchmark Performance of SN Stack for UNITS

Our team conducted extensive benchmarks to validate the SN Stack's suitability for UNITS' ambitious throughput requirements. The results were impressive - you can find detailed benchmark results here:

• We achieved 7,282 transactions per second (TPS) with merkleization enabled

• Without merkleization, the system pushed even further to 15,000 TPS

• The benchmark processed simple transfer transactions designed for parallel processing

• All transactions were ZK-proven with their final state published on Ethereum

Left: screenshot taken from Voyager explorer connected to a Madara deployment
Right: screenshot of Madara logs

These metrics significantly exceed typical blockchain throughput, confirming that the SN Stack can handle the billion-transactions-per-day scale required by UNITS. Importantly, all these transactions maintain the critical security property of being ZK-proven, ensuring that execution integrity is mathematically verified.

Merkleization: Centralized vs. Decentralized Approaches

The performance difference between merkleized and non-merkleized operations highlights an important advantage of UNITS' design. Merkleization is the process of recursively hashing database entries to produce a single root hash representing the entire state, which is essential for creating verifiable proofs of state.

In a decentralized context, merkleization must happen synchronously because:

1. One leader processes transactions

2. The leader merkleizes the data

3. The leader shares the entire block (transactions + merkle root) with the network

4. Nodes come to consensus on this block

5. The next leader builds on top of the previous block

The new leader cannot begin until all nodes have reached consensus on the previous block, creating a time constraint that limits throughput.

In UNITS' centralized context, the operator can continue processing transactions with merkleization happening completely asynchronously, as there's no time boundary enforced by a defined block time. The only requirement is to merkleize fast enough to avoid lagging behind the chain. By adding sufficient compute resources, this can be done without impacting performance, allowing UNITS to achieve higher throughput.

Difference in merkleization in a decentralised vs centralised setup

Horizontal Scalability: Proof of Concept with DynamoDB

Most blockchain architectures weren't designed with horizontal scalability in mind. They typically operate as vertically scalable systems interfacing with monolithic on-disk databases like RocksDB or PebbleDB. This approach works adequately for many blockchains because:

1. They haven't reached throughput levels that necessitate horizontal scaling

2. They face other bottlenecks from consensus mechanisms or hardware requirements that make database scaling a secondary concern

Finternet doesn't share these limitations. UNITS is being designed for horizontal scalability from first principles, which delivers benefits beyond just transaction throughput:

• Regulatory Compliance: Horizontal partitioning facilitates compliance with data localization requirements like GDPR by enabling geographic isolation of specific data

• Resilience: Distributed architecture prevents single points of failure

• Resource Efficiency: Workloads can be balanced across commodity hardware rather than requiring high-end single machines

While there's interesting and ongoing work in the CRDTs space that explores similar consistency and scalability trade-offs, horizontal scaling itself is a well-researched problem in the web2 domain. The purpose of this proof-of-concept is to explore how a scalable database like DynamoDB can be adapted to existing blockchain infrastructure. This is an early-stage prototype meant to demonstrate feasibility—we still need to dive deeper to uncover limitations and refine this approach further.

DynamoDB Integration for Horizontal Scaling

Our proof-of-concept integration of Starknet's Blockifier with Amazon DynamoDB demonstrates the horizontal scalability potential of UNITS. The Blockifier is the component of the SN Stack that takes sequenced transactions and processes them by calling the CairoVM. It includes optimizations for parallel transaction processing and interfaces with storage through a trait-based abstraction, making it independent of the specific database used as long as the database implementation satisfies the required interface.

This exploratory work was specifically designed to test whether UNITS instances could scale horizontally rather than being bound to one vertically scalable instance. You can find the implementation details in our blockifier_dynamodb_bench repository.

This approach is particularly valuable in scenarios where:

• A UNITS deployment spans multiple jurisdictions with naturally partitioned transactions

• Compliance requirements like GDPR's data localization must be handled within a single UNITS chain

• Scalable database solutions (like Cloud Spanner's multi-region configuration) must be leveraged

The implementation uses optimistic concurrency control to enable parallel execution:

1. During transaction execution, all state reads are tracked

2. When committing state diffs to DynamoDB, the transaction includes conditions ensuring read values haven't changed

3. If any value has changed, the DynamoDB transaction fails, preventing state conflicts

This model enables multiple transfer generators to run in parallel while maintaining state consistency, effectively scaling the sequencer horizontally through multiple instances. Our benchmark tests confirm that this approach maintains transaction integrity while allowing horizontal scalability inside UNITS.

First three terminals on the left show 3 blockifier instances running in parallel and processing transactions. The last terminal shows the live TPS happening on DynamoDB. Watch video demo here.

Current Development: UNITS Engine

The current focus of development is the UNITS Engine, a privacy-preserving layer that connects to a ZK provable stack. Currently, we're working on integration with Madara, while ensuring the Engine maintains read access controls and connects with other components of the Finternet Stack.

Diagram depicting privacy preserving flows across programs in UNITS

The UNITS Engine, which you can find here, implements a comprehensive API layer for interacting with the system. Its key capabilities are:

• The operator maintains privacy between participants

• Participants can define and enforce their own privacy rules

• The operator has read access to all data by design (a pragmatic choice given current technology limitations)

• Future integration with Fully Homomorphic Encryption (FHE) is possible as the technology matures

Key Functionality

1. Universal Identity System

   • Every entity can have an identity - users, applications, assets, and more

   • Each identity can have credentials attached to it

   • Flexible identity management with customizable permissions

2. Decentralized Directory Integration

   • Direct connection to DeDi (Decentralized Directory)

   • Users can request credentials from issuers on the decentralized directory

   • Seamless credential verification and management

3. Asset Tokenization and Compliance

   • Users can tokenize their assets on UNITS

   • Support for programmable compliance flows that govern asset transfers

   • Customizable rules for asset movement across users

4. Verifiable Proofs of State Change

   • UNITS provides ZK proofs that state changes only occur through execution of programs deployed by asset issuers and users

   • Users and token issuers can verify that their deployed programs - whether for compliance, authentication, or other rules - execute exactly as specified

   • No state changes can occur outside these predefined programs

The Engine's architecture ensures that while maintaining privacy between users, every state transition is provable and verifiable, creating a robust foundation for the Finternet ecosystem.

Conclusion: A New Paradigm for Financial Infrastructure

Finternet's UNITS represents a fundamental rethinking of transaction processing systems. By carefully analyzing the strengths and limitations of current blockchain architectures and making strategic design decisions, UNITS delivers:

• Privacy-preserving transactions at unprecedented scale

• Cryptographic verification without sacrificing performance

• A foundation for user-centric financial applications

As the financial world continues its digital transformation, systems like UNITS that balance security, privacy, and performance will become increasingly critical. Finternet's approach demonstrates that by challenging assumptions and leveraging cutting-edge cryptography, we can build transaction processing systems that truly put users first.

The journey toward a fully realized Finternet ecosystem continues, with UNITS providing the solid foundation upon which the future of user-centric finance can be built.

---

This blog has been authored by Apoorv Sadana (Founder, Karnot)

The author would like to thank Siddharth Shetty and Dr. Pramod Varma (Co-creators of The Finternet Lab), along with the many individuals and experts who contributed valuable insights and feedback during the development and review of this piece.

---

Follow the development of the UNITS Engine on GitHub and visit finternetlab.io to learn more about the initiative.