Fractal Scaling

Abstract

The topology of commerce is locally weighted, which means that humans most often transact with others in their own community, and less often transact with others far away. Following this pattern, fractal scaling is Anoma’s approach to scaling that allows users to create local instances of Anoma to fit their local transactional needs. These local instances will be interoperable with each other, allowing users to flexibly move their assets to whichever instance fits their needs. This article describes Anoma’s path to fractal scaling, design goals, and implementation details.

Introduction

While building the Anoma protocol and subprotocols, managing the growth of Anoma protocol usage requires the developers to anticipate what people will use it for in the future, and preemptively address concrete scaling problems that the protocols may run into. Anoma’s fractal scaling approach is designed for a network with a spectrum of transactions with different security needs and different values. Like mathematical fractals, Anoma will scale to have smaller instances alongside the global instance. Following the nature of commerce and humanity itself - that one is more likely to conduct commercial transactions with people who are closer than further away - fractal scaling will encourage users to build a protocol to facilitate the placement of instances of Anoma in local areas. These local instances can then connect to each other, giving users who have launched them the flexibility to recruit their own validators and configure their own security model.

Anoma's Fractal Scaling Approach

Fractal scaling on Anoma refers to the way in which the network will grow, as well as the interdependence of users and roles. Anoma follows the observation that topology of commerce is locally weighted. In essence, Anoma encourages users, to the extent that the developers and the network can, to launch instances of Anoma in local areas to fit their own needs and commercial behaviour. These local instances can connect to each other, as well as the main instance of Anoma that will be launched. In comparison to sharding in Ethereum, where the network splits part of the validator set into different chains (shards) which execute in parallel, fractal scaling differs by allowing those who launch their own instances of Anoma to control them themselves - these can then interoperate with other Anoma instances however they choose, the security model can be configured by the user themselves, and they can recruit their own validators. In other words, in sharding, the topology of the validator set is known and there is a one-size-fits-all security architecture which is controlled by the main chain of the sharded network, while in fractal scaling, the topology is dynamic and not controlled by any particular Anoma instance.

There are two types of scaling, horizontal and vertical scaling. Both are orthogonal approaches, and vertical scaling will be done in any case, this will be through simply making the blockchain faster: using zero-knowledge protocols to compress transactions, improving the database access patterns, requiring validators to buy faster servers and make faster CPUs. This will all be to improve the performance of a single instance of the ledger and complementary to horizontal scaling. Since vertical scaling currently does not address some problems that Anoma will run into, such as the alignment of security and including providers of security into the interdependence web of users in the network, the problem also has to be framed from another angle.

From the horizontal scaling angle, developers can make instances of the Anoma protocol whenever they think is needed, and anyone can launch their own version of it. The goal of Anoma is to provide and enable a mechanism and technical architecture to fulfil users’ real life needs: a way for people to barter and conduct transactions - most of which, recognizing how most people behave, happens locally. It is not viable to have one blockchain that handles all transactions and is controlled worldwide. Security-wise, it is also not ideal to route local commercial transactions to a faraway system, for example a local, USD$5 transaction between friends in Shanghai, to Vancouver, because operators of a faraway system likely do not have local ties to users transacting and token incentives can vary between instances (this point will be elaborated on later in this article). Not only is commerce fractal and local in physical space, but this concept of locality can also apply to social distance, such as gaming communities. For example, Animal Crossing players can gift other players in the community, and some of these players might overlap with another game, such as Stardew Valley, and less with another game like Eve Online. Bunches of people with the same interests are also likely to transact with each other, much like people in the same city.

With this approach, after launching a first instance that is initially global in scale which uses the protocol, users are encouraged to launch different instances of the Anoma protocol using the software that the developers have built which can be modified to suit a community’s needs. Local instances could be launched between friends to settle transactions. On top of this, assets can be transferred to any instance on the network. One can choose the global ledger with higher security for big transactions (since with the MASP, the more transactions, the more secure) and move assets back to a local instance for regular transactions, since high security is not required all the time.

Let’s look at an example of how a transaction works when users are on different fractal instances of Anoma.

Alice lives in Berlin, and most of her assets are also in the Anoma Berlin ledger in stablecoin form of EUR, while the rest are in the global ledger. She decides to visit her friends Bob and Charlie in San Francisco, who have most of their assets in stablecoin form of USD on the Anoma San Francisco instance.

After going to dinner, Bob pays the bill, prompting Alice and Charlie wanting to pay him back with a transfer on Anoma. Because Alice’s funds are mostly on the Berlin ledger, these need to be transferred manually, or the Anoma app automatically transfers this to the San Francisco instance, much like how data roaming works on mobile phones. Both Alice and Charlie would be able to open their apps and press a simple button to transfer funds to Bob, with Alice perhaps going through the extra step of transferring her funds directly to Anoma San Francisco or through the global instance of Anoma.

This example highlights how Anoma expects users to have funds on different instances, and allows users to move them as appropriate when they themselves are moving around in any kind of space, be it virtual or physical, to pay or barter. With Anoma’s app in the future, most of these steps can be automated, or done simply with a press of a button.

Goals of Anoma's Fractal Scaling Approach

There are four goals of Anoma’s fractal scaling, designed around the way humanity and commerce have grown throughout history:

Goal 1: Scale Throughput

Anoma aims to scale throughput by not putting all transactions on one blockchain, much like sharding. By spacing transactions throughout a few blockchains and offloading the main ledger into fractal instances that can run in parallel, the corresponding throughput of the system of a whole is higher. For example, when Anoma Berlin handles mostly transactions in Berlin, as well as local validators validating those transactions, the latency is much lower than if people in New York would be using the Anoma Berlin instance.

Goal 2: Align the Security Provided with the Security Required

The Anoma protocol expects to host a whole spectrum of transactions with different security needs, and different values. People in different situations are willing to pay more or less for the security tied to each transaction. A single ledger is limited to the degree in which it can service varying needs, because it is a one-size-fits-all security, which is not a problem unique to Anoma, but any Nakamoto- or BFT-style consensus.

Fractally scaled local instances should manage properly with the security that most local transactions require with the security provided by Anoma, or through configuring their own security model. Giving users the flexibility to choose which fractal instance is appropriate to their scenario can allow users to select which level of security is most appropriate for their transaction. Due to the nature of the MASP, one might choose the global instance of Anoma for a large important business transfer, due to a higher transaction volume that results in more security.

Goal 3: Validators should be Connected to the Instance they are Running

In an important sense, many of the factors in play determining whether a blockchain is secure are fuzzy - usually local or reputational. In any BFT system where more than ⅓ of validators collude, there is not much, from the perspective of the protocol, that can be done towards Byzantine behaviour, which makes the system susceptible to failures and attacks. This can be detected, but cannot be punished within the system itself - which is a theoretical limitation of any kind of BFT consensus system. Off-chain incentives for validators are essential, because the chain’s ability to handle faults itself is limited.

A simpler way to put this would be that users or people who are real world business entities (more specifically, people with real-world relations with the users of the protocol instance) are less likely to double sign or do anything malicious towards the network, because they have personal reputations at stake, friends involved. This applies to validators in general and is not unique to any group of people. Insofar as there are other kinds of interdependency involved, the network security becomes stronger. If a validator is a for-hire service provider, they are less likely to be integrated into the web of economic interdependence, and would only be taking on their role as a validator on Anoma for the specific proof-of-stake incentives, because there is a limit as to how strong these incentives can be made. People who play important roles running validator and orderbook nodes in the Anoma protocol would be more aligned with the best interests of the network if they were at least partially overlapping with the users of the protocol, or at least that particular instance of Anoma. For this reason, considering scaling and practical security constraints, it is important to align the providers of security with the users of the network.

Goal 4: Reduce Latency

Reducing latency is a goal of every network and especially important for geographical instances of Anoma. By allowing anyone to create their local instance of Anoma, users are already transacting with other users which are geographically close to them, which solves general latency issues that can occur in global instances, such as bottlenecks and higher transaction processing times. If all the nodes of a blockchain are located within 10ms of each other (within the same city) transactions can process much faster

There are some similarities between goals 2, 3 and 4, insofar as they can be summarized as Anoma wanting to align the structure of the network with the content of people’s transactions and the bartering. Ultimately, these three goals want to provide users with a new mechanism that aligns with their already existing patterns of bartering in commerce that already occur on a day-to-day basis. Additionally, goals 2 and 3, while not largely technical, are equally important to reducing latency (4) and scaling throughput (1) as they contribute greatly to the long-term usefulness of the network.

Enabling Fractal Scaling on Anoma

From a technical perspective, in order to enable fractal scaling on Anoma, the requisite interchain protocols have to be written to allow users to go between instances which fit their usage best, and developers will have to anticipate what kind of interactions need to happen on the protocol. Asynchronously, people have to send their assets from one instance to another, and in the future synchronous cross-fractal instance bartering may be possible, making it so that people do not have to transfer their assets from one to another to barter. This means having a modified consensus algorithm for atomic blocks¹. Fractal scaling will also require a software toolkit to be prepared for people to run local instances with local communities.

From a user perspective, Anoma recognizes that the details of the infrastructure will not be relevant to most users with assets on the chain and wanting to conduct transactions. In future, the application and ledger will be expected to automate some processes to allow for a more streamlined user experience, for example, funds automatically transferred to the most convenient local instance for local transactions.

This approach to scaling allows certain subgroups who need more capacity to create according to their needs, using the same protocol. This makes decentralization, security and scalability relatively flexible. Fractal scaling allows Anoma to be both decentralized and secure, because the blockchains likely won’t require much scaling, much like how humanity has scaled as tight knit smaller communities which are interconnected. Additionally, Anoma does not only connect to other Anoma ledgers but also other blockchains, which makes it so that Anoma’s interconnectivity model does not enforce particular security models on connected chains. As a result of this variation of systems, users only have to trust that the ledger they have their assets on is correct.

Conclusion

Anoma’s fractal scaling models the topology of commerce, which follows the fact that most of human commercial behaviour happens locally, close in both a physical or digital sense. The first instance of Anoma, the global instance, will be a demonstration of current Anoma developers’ work in action, and users will be encouraged to create their own instances in parallel, and to recruit local validators who are also connected to the instance they are running. Creators of local instances also have the added benefit of configuring their own security model (even if it is not proof-of-stake), setting up the infrastructure, and creating connections to other instances they think are required.

In practice, in the mid to long term, there will be various Anoma instances around the globe, for example Anoma Berlin, Anoma Shanghai, or even Anoma Animal Crossing, depending on where users are located or what their interests or common transaction experiences are. The pathway for local instances to be launched will be streamlined in order to start servicing local demand. If this is realized, the Anoma protocol instances will be placed at local junctions or local points of density in this space of commercial distance. If the four main goals of fractal scaling are satisfied, user needs can be fulfilled through customized Anoma instances that they themselves have created with low latency, with validators they can trust, and finally, the freedom to choose which instance is suitable for each of their transactions.