bluzelle white paper v 1 -...

!

WHITEPAPER Release 1.0, August 1, 2017

Written By Neeraj Murarka, CTO Bluzelle Networks

&

Pavel Bains, CEO Bluzelle Networks

1. Table of Contents

1. Table of Contents 2............................................................................................................................

2. Summary 4..........................................................................................................................................

3. About Bluzelle Networks 6..............................................................................................................

3.1. Mission 6.....................................................................................................................................

3.2. History 6......................................................................................................................................

3.3. The Evolution of Bluzelle 7......................................................................................................

4. The Current State Of Database Services 8......................................................................................

4.1. The Past: Single-System Database Model 9...........................................................................

4.2. The Present: Cloud Database Model 10....................................................................................

5. The Future: Bluzelle Decentralized Database Model 11................................................................

5.1. Problems and Solutions 12.........................................................................................................

5.2. Key Features 15............................................................................................................................

5.2.1. Performance 15....................................................................................................................

5.2.2. Reliability 16.........................................................................................................................

5.2.3. Scalability 16........................................................................................................................

6. Marketing & Distribution Strategy 18..............................................................................................

6.1. Target Market 18..........................................................................................................................

6.2. Regional Focus 18........................................................................................................................

6.3. Enterprise Market 19...................................................................................................................

6.4. The Bluzelle Developer Community 19...................................................................................

7. Application of Bluzelle for Fintech 20..............................................................................................

8. Bluzelle’s Ecosystem 22......................................................................................................................

8.1. Developer Marketplaces 22........................................................................................................

8.2. Developer Environments 22.......................................................................................................

8.3. Blockchains 23..............................................................................................................................

8.4. Operating Systems and Browser Tools 23................................................................................

8.5. Payment Bridges 23.....................................................................................................................

9. How Does Bluzelle Work? 24.............................................................................................................

9.1. The F Function 25........................................................................................................................

Private and Confidential by Bluzelle Networks !2

9.2. The G Function 25........................................................................................................................

9.3. What is a Bluzelle Participant? 26.............................................................................................

9.3.1. Consumer 26........................................................................................................................

9.3.2. Producer 26...........................................................................................................................

10. The Bluzelle Token 28........................................................................................................................

10.1. Bluzelle ERC-20 External Token 29.........................................................................................

10.2. Bluzelle Network Token 29......................................................................................................

10.3. BNT Consensus Ledger 30.......................................................................................................

10.4. Bluzelle Token Gateway 31......................................................................................................

10.5. Revenue 32..................................................................................................................................

10.5.1. Granularity 33....................................................................................................................

10.5.2. Rewards Mechanisms 33.................................................................................................

11. Bluzelle Technical Overview 35.......................................................................................................

11.1. Bluzelle Harvesting Agent 36...................................................................................................

11.2. How long does data stay on the network? Does it expire? 36.............................................

11.3. What is a node? 37.....................................................................................................................

11.3.1. Node minimum requirements 38...................................................................................

11.4. What is a leader node? 38.........................................................................................................

11.5. Universal Bluzelle Locator 38..................................................................................................

11.5.1. Farmer Node Identification 41.........................................................................................

12. Roadmap 43........................................................................................................................................

12.1. MVP Feature Set 43...................................................................................................................

12.2. Post-MVP Roadmap 43.............................................................................................................

13. Credits 45............................................................................................................................................

13.1. Authors 45...................................................................................................................................

13.2. Contributors 45..........................................................................................................................


2. Summary Blockchain technologies are propelling the next generation of the Internet, known as the

Internet of Value. In the current Internet, the technologies are centralized which leads to

extensive challenges in security, scalability, and privacy. In the blockchain powered New

Internet, everything from infrastructure to the consumer applications (DApps) themselves are

decentralized. Without these decentralized components, the New Internet would not be able to

run efficiently and scale to massive use. The table below shows how the New Internet relates to

the Current Internet.

Bluzelle Networks Pte. Ltd. and it’s technology platform, called Bluzelle, fills a need and is

complementary to the other components to make the New Internet complete. Bluzelle is a

decentralized service that provides on-demand, scalable databases. It is for software developers

who are dissatisfied with the costs, limited scalability, and complexity of existing database

systems. For example, unlike running an AWS Mongo server, Bluzelle is low-cost, quick to

deploy, provides high performance, and has a solid scalability path. Bluzelle is the right fit

because it provides enterprise-grade database services at a price for all Decentralized

Application (DApps) developers.

Bluzelle uses idle computer hardware by incentivizing people to rent out their resources to

create a decentralized crypto-economic database network.

The producers (aka farmers) provide resources in the form of CPU processing power, memory,

permanent storage, and network connectivity to enable database shards to be stored with

Ecosystem Components The Current Internet The New Internet

Applications Facebook Status

Operating System Microsoft Windows Ethereum

File storage Amazon S3 Filecoin

Database storage & management Oracle BLUZELLE


sufficient replication to guarantee availability and redundancy. Producers demonstrate they

successfully stored data by responding to Bluzelle’s “proof of storage” and “proof of

redundancy” challenges, and upon a successful challenge, are rewarded with Bluzelle Tokens

(BLZ).

The consumers (software developers) use Bluzelle's database services provided by the collective

of producers, and in turn pay for these services using the Bluzelle Tokens. They have control

over attributes that dictate how and where their data is shared and stored. These attributes

affect the BLZ cost for these services.

Moving forward it should be noted that all references to the company is Bluzelle Networks and all

references to the product is Bluzelle.

Feature Description

Highest privacy Bluzelle employs cryptography and sharding techniques to provide a privacy guarantee.

High reliability Bluzelle redundantly stores tiny pieces of data on nodes across the globe, eliminating any single point of failure.

Enterprise scalability Bluzelle stores data in a unique, distributed and intelligent manner that is able to provide enterprise-level scalability.

Data immutability Bluzelle leverages blockchain technology so that once data is stored to such a network, it is impossible to change that data.

High performance speeds Bluzelle dynamically adjusts the number and location of nodes sharding the consumer’s data to meet performance metrics.

No intruders Bluzelle’s use of consensus is the only method by which updates to the network can be accepted as the “truth”.

Low cost Bluzelle operates no data centers and has zero capital costs. All computer resources are provided by participating “farmers”.


3. About Bluzelle Networks

3.1. Mission Our mission is to improve the lives of a billion people through blockchain. We believe that

blockchain-powered applications are a key catalyst for financial inclusion.

3.2. History Starting in 2014, Bluzelle Networks saw that for the world to get better financial services, banks

and insurers would require new technical infrastructure. Their legacy systems were expensive

to maintain, and blockchain based applications would provide better and cheaper products for

end customers. We created as a middleware technology with application libraries that abstracts

the complexities of managing blockchain applications. Just like Oracle made it easier for

enterprises to manage relational databases, we made it easier for enterprises to manage the

blockchain. Over the past 15 months, our proven technology has met real business needs

through numerous fintech projects including:

➢ An Ethereum-based KYC Shared Ledger for a consortium of international banks.

➢ An Ethereum-based insurance platform for major Asian insurer MSIG.

➢ An Ethereum-based consumer mobile insurance product by AIA.

➢ A Ripple-based cross border payments POC for Temenos - a world-leading core banking

system with thousand of customers.

➢ Channel partnerships with KPMG, Microsoft, British Telecom and Happiest Minds to

bring Bluzelle to their portfolio of customers.

Bluzelle Networks was named to the Global Fintech 100 by H2 Ventures and was appointed by

the World Economic Forum as a Technology Pioneer for 2017. Previous winners include Google,

Spotify, Twitter, AirBnB amongst others.


3.3. The Evolution of Bluzelle Working with enterprise customers revealed one critical challenge for widespread adoption of

blockchain applications: the management of large amounts of data. By evolving our technology

to include data management services, we target all software developers, including small to

medium businesses. We provide all developers with an enterprise-grade database management

service at an economical price.

Bluzelle is a decentralized service that provides on-demand, scalable databases. It is for software

developers who are dissatisfied with the costs, limited scalability, and complexity of existing database

systems. Bluzelle is low-cost, quick to deploy, provides utmost performance, and has a solid scalability

path. Bluzelle provides enterprise-grade database services at a price for all DApp developers.


4. The Current State Of Database Services Our world is driven by software, automation, and connectivity that requires the generation,

management, storage, and retrieval of enormous amounts of data. Traditionally this has been

solved with a database that requires (1) a server to host on, (2) a database management system,

(3) an administrator, and (4) the high costs to implement and manage them. Cloud computing

marginally improved upon this. However, features like resilience, replication, availability, non-

repudiation, transparency, immutability, performance, and data integrity were not guaranteed

and often not even an option.

“Business leaders demand next-generation applications and new insights to drive more intelligent

engagement and better decisions. To get there, enterprise architects need to design an agile technical

architecture that can scale automatically with capabilities, such as databases, that are always available to

support new initiatives. It takes enormous time, effort, and coordination to provision new databases today

because of a lack of resources to meet the administration challenges of rolling out complex clustered

systems.” Forrester Research, 2017 Market Overview Database As A Service

To address this problem, emerged the Cloud Database and Database-as-a-Service (DBaaS)

market. Demand for these services is high across a multitude of industries, including: financial

services, government agencies, academic sector, healthcare and life science, media and

entertainment, professional services, telecom, and manufacturing. According to Markets and

Markets, Cloud Database and DBaaS is expected to grow at a CAGR of 67.30% to $14.05 billion

by 2019. There are four primary drivers of demand for DBaaS:

➢ Consumer personalization apps. DBaaS offers the ability to store, process, and access

customer data in the cloud to support consumer personalization applications from

Facebook to Minecraft to the thousands of products being launched each month.

➢ Internet-of-things (IoT) applications. DBaaS enables developers to build IoT

applications that keep data from connected devices in the cloud. For example,

manufacturers with equipment attached with tracking and monitoring devices to their


products can push their data to the cloud rather than trying to build their own storage

solution.

➢ Mobile apps. DBaaS offer a great platform for storing, processing, and accessing unified

data to support quicker deployment of mobile applications. In addition, cloud databases

can adapt to seasonal usage demand and unpredictable workload growth.

➢ Line-of-business (LoB) collaboration. DBaaS platforms help different LoBs collaborate

by storing commonly used data in the cloud, which can then be accessed by internet

browsers or portable devices including smartphones, tablets, and wearables.

Cisco forecasts that from 2012 through the end of 2017, global data center traffic will triple from

2.6 zettabytes (1 billion terabytes) to 7.7 zettabytes. With all these applications producing more

and more data, past and present database management services are under-equipped to meet the

needs of businesses.

4.1. The Past: Single-System Database Model The original database model has the application, database, filesystem, and file storage hardware

(i.e., hard drive) all on the same physical machine. It is a simple, straightforward arrangement

that came with severe limitations and shortcomings:

➢ Limited to expensive vertical scaling (scaling up) as the only option when more

performance was needed. Hardware goes up exponentially in price as more powerful

hardware is needed. With vendor lock-in, you are limited to whatever options given to

you.

➢ Single source of failure on many levels: hard disk, operating system, database, or

application. If any of these failed, the whole system crashes and becomes unavailable,

and possibly with no quick recovery unless manual backups were made.


➢ No privacy -- this model was primitive，and anyone who managed to get physical or

remote access had complete access to all data in plaintext format.

➢ No immutability -- anyone with access to this machine could change the truth by just

modifying the only copy of the database in existence.

➢ Performance limitations -- everything is running on a single machine and is therefore

sharing the CPU, network, and storage resources -- there is a ceiling on how much

performance can be attained in this limited operating environment.

4.2. The Present: Cloud Database Model The 2000’s cloud model was a major leap forward, compared to the single-system model. It

spread out the load across multiple machines so that increases in scalability, performance, and

speed were now possible. This became a more complex environment where there was now

dependence on a cloud provider, the ensuing costs, the management and synchronization of

multiple machines, and still a single point of failure -- the load balancer :1

➢ Like the single-server model, there is no privacy. Any breaches of any of the servers in

question give the hacker immediate and complete access to all data.

➢ The points of failure have simply been moved. Even though one or more servers could

come down, if the load balancer does down, the whole system goes down.

➢ Expensive and cumbersome -- every time horizontal scaling (scaling out) is needed,

entire new machines need to be provisioned. This requires an IT dept or managed

services, both of which are expensive. New licenses for OS’s and software are also

needed.

➢ No immutability. Like the single-server model, if anyone has access to any of the load-

balanced machines, they can change the truth by modifying any copy of the database.

Whether intentional or accidental, all changes are recorded without question.

There can indeed be multiple load balancers, but scaling out to multiple load balancers reduces the issue and does not resolve it.1


5. The Future: Bluzelle Decentralized Database Model

2

Bluzelle is a decentralized NoSQL database service that provides on-demand, scalable databases

based on the CRUD service model. It is for software developers who are dissatisfied with the 3

costs, limited scalability, and complexity of existing database systems. Unlike running an AWS

MongoDB server, Bluzelle is low-cost, quick to deploy, and provides utmost performance. In

mathematical terms, it employs a proof of redundancy and storage.

Bluzelle uses idle computer hardware by incentivizing people to rent out their resources to

create a decentralized crypto-economic database network.

Bluzelle complements other decentralized platforms. Existing decentralized solutions cover file

storage and decentralized turing-complete application processing. For example, decentralized

file systems such as InterPlanetary File System (IPFS) and Storj are excellent partner services for

storing large files. However there is still an unfulfilled requirement for a decentralized database

service. Bluzelle is this missing piece, completing the picture: a feature-complete, decentralized

computer system.

Inspired from https://securityledger.com/2015/01/ibm-and-samsung-bet-on-bitcoin-to-save-iot2

CRUD = Create, Read, Update, Delete, the core functions in any database service.3


Bluzelle capitalizes on the benefits of blockchain technology by executing horizontal database

scalability (scaling out) on an unprecedented scale. Bluzelle employs key characteristics of

blockchain to create an ecosystem that consists of metaswarms of nodes acting collectively to 4

dynamically store data with partial replication to maximize the performance of its on-demand

scalable databases. One key difference is that Bluzelle does not have a universal state for the

entire network -- Bluzelle uses swarming. Combined with its rewards system and proofs, 5

Bluzelle implements swarm-level consensus that, when reached, guarantees data integrity.

Key product goals:

➢ Support large numbers of concurrent users (millions per second).

➢ Capacity of petabytes or more, growing linearly as farmers are added.

➢ Optimal response time and performance, irrespective of user location.

➢ 100% availability – no downtime.

➢ A fluid and dynamic technology that responds to changes in demand and environment.

Bluzelle’s mantra: Your data should be where your users demand it, not where your provider stores it .

5.1. Problems and Solutions Before Bluzelle, enterprise architect professionals and software developers seeking database

services had one of two choices: (1) running their own database servers and managing all the

aspects, or (2) using existing managed database services. Neither choice was ideal as both led to

multiple problems that centered around cost, scalability and performance. The table on the

following page outlines the specific problems and features of Bluzelle.

Bluzelle at the high level is a swarm of swarms of nodes.4

Post-MVP Bluzelle roadmap5


Customer Problem Bluzelle Features

Privacy:

Existing service providers cannot guarantee privacy. They store all the data in its entirety in one or many locations without any encryption whatsoever. These legacy systems were never designed to provide privacy. Yet businesses in most sectors are expected to provide a level of privacy.

Bluzelle employs cryptography and sharding techniques to provide a privacy guarantee. All data is split into data shards. It is then encrypted. It is finally distributed with redundancy across a decentralized network. Since the consumer alone holds the keys, the consumer alone owns their data. No outside company can access or control the consumer’s data, unlike traditional cloud data providers. Privacy is always an issue whenever using external database services, and limits the options and scope of software projects that require guaranteed privacy levels.

Bluzelle implements a concept of “privacy by design”. When new applications are built using Bluzelle as their database, the application automatically becomes secure, minimizing the attack vectors against that application’s ecosystem. This is a discouragement to would-be hackers.

Reliability:

Storing data on one or even multiple servers either on-site or with a traditional cloud data storage provider carries reliability risk such that if this provider’s network or hardware fails or is breached, the data may be destroyed or become inaccessible. Yet guaranteed data availability is necessary to meet the uptime requirements of the SLA’s for most software endeavours.

Bluzelle stores tiny pieces of the data (shards) on swarms across the globe using a fog computing model. Each shard is replicated onto multiple nodes (all the nodes in the leaf swarm), to guarantee reliability and redundancy (if one copy of a shard is lost, there are multiple backups ). This eliminates any single point of failure and ensures the highest possible uptime, superior to what is possible from traditional database service providers.

Scalability:

Achieving mass scalability (on the scale Bluzelle provides) is a logistical impossibility for existing data storage services. Existing solutions require the explicit provisioning and management of expensive and complex new database cluster server instances (horizontal scaling) when increases in scale are necessary. Clustering requires numerous components and creates a single point of failure that jeopardizes availability. The alternative is vertical scaling, where the costs of hardware go up exponentially. These are significant capital expenditures of effort, time, and cost, which means achieving scale is a long, painful, and high-friction activity. Ultimately, most of these solutions do not scale linearly -- doubling the number of nodes does not double the capacity of the network.

Bluzelle’s algorithm splits up and stores the database’s data into shards that are each delegated to one of the leaf swarms on its network using a combination of jump consistent hashing, Kademlia distributed hash tables, and both horizontal and vertical data partitioning. This ensures that a database dynamically scales as needed, even as it grows. A consumer of Bluzelle’s services can decide exactly what level of scalability is needed, on a “just in time” basis, using a sliding scale that is highly granular, following a “pay as you use” model. Bluzelle provides scalability exactly how and when the consumer needs it, enabling the consumer to micromanage the level to which they need scalability in a “self-service” context. As more nodes (i.e. resources) are added, network capacity goes up accordingly, in a linear fashion. So if the network needed to reach a certain metric (i.e: million writes per second), it is highly attainable with sufficient nodes. The Bluzelle micro-economic model dictates that if the demand for it is there, this metric is achieved.


Immutability:

It is vital that data, once stored with certain values, becomes permanent and irreversible. With traditional database service providers, there is no mathematical and technological guarantee of immutability. A software glitch or deliberate breach could result in data being reverted, tampered with, or removed, with no means for restoration. This is a serious issue in the financial industry. For example, a bank needs to have assurance that their stated holdings are 100% accurate , and that the database cannot spontaneously either undo their ownership of said holdings, or totally delete any trace of this relationship. In fact, the database should be so trusted and secure in can be used as evidence in legal proceedings.

Bluzelle leverages blockchain technology, so that once data is stored on such a network, it is impossible to change that data, if the IVH index is set to a plural value. New data can be added, or old data can be updated as the latest “version” of the data. However, the “old” data remains available in its original, immutable form, for the purposes of audit, rollbacks, and restoration, if necessary. Immutability is an option, not a requirement. Developers have the option to decide if they need it or not, and to what degree, using the “Immutability and Versioning History” index value when creating data on Bluzelle.

Performance:

Traditional database services have performance weaknesses when access to read and write data needs to be consistently fast. Traditional database services are subject to slowdowns, breakdowns, and bottlenecks due to conditions of the network, the nature of the requests, the location of the requests, or the amount of data being transacted. This is in fact a key reason why systems fail -- their inability to get timely access to data, due to fundamental performance weaknesses inherent in traditional database services. Access to data for both read and write operations needs to be consistently fast, irrespective of the conditions of the network, the nature of the requests, or the amount of data being transacted.

Bluzelle dynamically adjusts the selection of nodes responding to requests for the consumer’s data. This is done using AI-inspired search and optimization algorithms that adjust the distance from requestors to the actual nodes within a swarm that serve up the requested data.

The consumer pays for and therefore defines how much performance they expect. Bluzelle makes these changes on the fly to maintain the service levels requested. Bluzelle’s performance algorithms autonomously respond to requests as well as network conditions, adjusting parallelism of worker nodes and geo-proximity of data as needed.

If the data requirements for a consumer increase in a specific geographical area, the number of worker nodes serving that data in geo-proximity to where the requests are made increases , restricted only to nodes storing the specific shards relevant to those requests . This is analogous to how Content Delivery Networks have helped improve the performance of access to files for websites with global reach, but with the added twist that data partitioning both vertically and horizontally combined with replication of shards onto multiple nodes ensures load is dynamically distributed across the replicated nodes, adjusting automatically to operating conditions.

Integrity:

Traditional database services are architected to protect from software and hardware failures but not from “illegal” updates to the data due to an intrusion or accident. The sole job of each clustered server instance is to accept the updates from other servers, lacking any protocol to verify the authenticity of such updates and react accordingly. A bad actor could introduce data updates that favour them yet are illegal and contradictory to the data clustered on the network. The new data would get mirrored and accepted as the new global truth.

Bluzelle’s use of blockchain technology ensures consensus is the only method by which updates to the network can be accepted as the “truth”. Every node in the Bluzelle network that shards the data in question participates in its parent swarm’s consensus process and only if consensus is achieved does an update be accepted. This eliminates any chance a rogue node unilaterally introduces ad-hoc changes. It also ensures the reversion of disallowed changes.


5.2. Key Features

5.2.1. Performance

Bluzelle’s unique and proprietary swarming techniques were designed with performance in

mind. Bluzelle can reduce latency by retrieving data from the nearest nodes on the leaf swarm,

and/or increase speed manyfold by retrieving data in parallel from the fastest nodes on the leaf 6

swarm.

For example, let’s consider a group of swarms that a collection of data shards would each be

assigned to, and from which we are retrieving the data. Each swarm consists of its own

collection of nodes, spread out in some distribution that is random, by design.

Once the swarms are identified, Bluzelle uses distance-measuring algorithms, with respect to

the client requesting the data, to determine which are the optimal nodes in each swarm that

make the most sense to retrieve the shards from. Such distance-measuring algorithms are

beyond the scope of this paper, but typically use heuristics to determination which worker

nodes amongst a swarm’s nodes are closest to the user.

In parallel, multiple worker nodes from each swarm are asked for data, and the responses are

then received and ranked by Bluzelle. All responding nodes get rewarded in micropayments of

Bluzelle tokens, while the actual worker nodes who “won the race” within each swarm get a

proportionally higher reward.

Pricing:

Existing cloud data services are expensive due to the high capital costs necessary to run multiple, international cloud data centers. The hardware required is typically high-end machines that have multiple CPUs with multiple cores as well as sophisticated SANs. This model has a cost structure that goes up substantially when requirements such as scalability, redundancy, and performance are made.

Bluzelle operates no data centers and has zero capital costs. All computer resources are provided by participating “farmers” who each can use commodity, multi-core hardware. Bluzelle’s technology exploits natural economies of scale that provide the scalability, redundancy, and performance needed by database services’ consumers.

Post-MVP Bluzelle roadmap requiring historical speed metrics data for nodes.6


5.2.2. Reliability

Using the concept of fog or swarm computing, Bluzelle follows a model where every piece of

data is 100% replicated in a single leaf swarm amongst a swarm of swarms. So while the data is

only in one swarm, that swarm’s nodes are aplenty and are geographically dispersed, immune

to localized outages caused by either natural or human-related events.

All the nodes in a swarm duplicate the exact same data shards, providing 100% replication. This

level of redundancy results in guaranteed reliability within the Bluzelle swarming model.

Namely, if one node or even multiple nodes are lost, as long as a majority of the nodes are

available , the swarm continues to operate normally, and all its data is available. 7

The data owner has the option to specify how many backups in time are desired. This means 8

that even if data is legitimately overwritten, older versions of the data are available for

restoration, up to a point specified by the data owner. The resulting fees to store this data

increase as well, due to the increased resource requirements of keeping older versions.

The Bluzelle model completely obviates the concept of a single point of failure and ensures the

highest possible uptime.

5.2.3. Scalability

Scalability is possible both horizontally or vertically. Bluzelle manages the various strategies

and considerations around the use case of having to increase scale.

With vertical scaling (or scale up/down), you increase the capacity of existing systems

(hardware and/or software) by adding resources to these very systems. This might include

adding more hard drives, RAM, or CPU's, or by replacing these components with bigger,

higher-performing versions.

Refer to the CAP theorem later in this paper7

Refer to the section on Immutability and Versioning History8


With horizontal scaling (or scale in/out), you add more nodes to an existing system. For

example, if you have two mirrored database servers, you scale out by adding more database

server nodes to the cluster, to distribute the load.

Traditionally, due to the expense of managing multiple machines and the complexity of writing

software that can properly distribute over multiple machines, scaling up was a better economic

choice.

In recent times, and thanks to the development of marvels such as Bluzelle, decentralization

technology has entered into the mainstream, where a collection of nodes acting in a cluster

(horizontally-scaled) can act like a single, cohesive super-computer, and therefore provide

scalability that is far more economical than vertical scaling, especially with inexpensive

commodity hardware.

A collection of 10 such machines might be far less expensive than a single supercomputer trying

to do the same amount of processing. More interestingly, a sufficiently large number of the

horizontally scaled machines can be aggregated to provide such a high level of combined

processing that no technology even exists yet for this to be done by any single vertically scaled

system.

The advancement in speed of network connections allows horizontally scaled machines to

communicate with each other such that the traditional downsides of scaling out are mitigated.

A key notable example of horizontal scaling: Google, who has thousands upon thousands of

machines in "farms" that all perform the work that a single machine could never achieve.

Bluzelle is a massive horizontally scaled network. In fact, horizontal scaling is a cornerstone of

its architecture, where every swarm is another “unit” of horizontal scaling at the metaswarm

level. Within every leaf swarm, every node acts as yet another agent of horizontal scaling, at the

leaf swarm level.


6. Marketing & Distribution Strategy

6.1. Target Market Bluzelle is designed with two major audiences in mind:

➢ DApp (decentalized app) developers. This is the fastest growing segment in the

software industry right now. It involves software developers writing applications that

take advantage of other decentralized technologies that are complementary to Bluzelle.

➢ General purpose enterprise or consumer software developers. This refers to developers

that might not even be in the decentralized software space. These developers are writing

enterprise applications, games, productivity software, mobile applications, utility

software, and many other other software products.

6.2. Regional Focus Bluzelle’s headquarters are in Asia Pacific. This region is home to a fast growing startup

community that targets the financial sector - one of the biggest users of database services. These

are ideal customers for Bluzelle’s decentralized database services. These startups require

efficient and low-cost services. Many parts of Southeast Asia are rapidly developing as major

cities and high-growth economies. They are leapfrogging legacy client-server architecture

systems to innovative adaptive and scalable solutions built for the future.

“Asia Pacific is anticipated to aggressively adopt cloud database and DBaaS solutions in the near future.

This is basically due to the increasing focus by small, medium, and large scale enterprises for the purpose

of improving efficiency and productivity via investment in technology.” - TMR Research Cloud Database

and Database as a Service (DBaaS) Market, 2017-2025


6.3. Enterprise Market As mentioned earlier, we already have a growing business providing blockchain-powered

services to the enterprise market. Bluzelle taps into these customers for two things:

1. Test Bluzelle’s features to ensure they are enterprise-grade. The value proposition is to

offer enterprise-level database services at a price that all small-to-medium software

developers can afford.

2. Evaluate enterprises as potential buyers of Bluzelle. Enterprise sales cycles are long but

once the sale is committed the customer is locked in to multi-year contracts. Our

enterprise customers are likely to adopt Bluzelle as they see its benefits. The bureaucratic

overhead is avoided.

6.4. The Bluzelle Developer Community The first release of Bluzelle is planned for April 2018, but we will start building our developer

community within the next thirty days. Servicing software developers has less friction as they

can be engaged online and are passionate about technologies that help them make better

products quickly and easily. Early on, we will get feedback on the product and build the

ecosystem enabling both the producers and consumers of Bluzelle.

We will have an online community site, go to hackathons, host meetup events, and much more.

As a tech company, Bluzelle’s employees have an organic network of peers, friends and

acquaintances who are the target market. These are the seeds of the Bluzelle Developer

Community.

Throughout Asia Pacific (to start), Bluzelle will be doing various developer reach outs to many

of the biggest cities, including: Singapore, Hong Kong, Shanghai, Tokyo, Seoul, Kuala Lumpur,

Mumbai and more.


7. Application of Bluzelle for Fintech Bluzelle Networks used its existing technology to develop and power a KYC Shared Ledger

application for a consortium of international banks. KYC (Know Your Customer) is an

enormous pain point in financial services. The regulatory requirements by governing bodies are

increasing with no signs of slowing down. All this bears a big financial cost on banks.

Furthermore the penalty of non-compliance is expensive and embarrassing .

This KYC Shared Ledger leveraged Ethereum to enable banks to:

➢ Onboard customers faster and cheaper.

➢ Share information between one another.

➢ Manage and update customer data easily.

Once onboarded, the customer’s entire profile is encrypted and stored securely and

permanently to the blockchain, using a proprietary multi-party key encryption protocol that

enables banks to “own” their customers’ private data, only allowing the data to be shared with

other banks that are specifically authorized by the customers themselves.

A database stores and retrieves data, and is designed to allow the definition, creation, querying,

update, deletion, and administration of the data stored within it. The blockchain can be

considered like a hard drive -- it is a rudimentary technology that lets you store 0's and 1's to it,

but with some database features.

Bluzelle Networks created technology so the KYC Shared Ledger could use the blockchain like a

database. This was time-consuming and expensive -- it needed specialized code that connected

business logic with the blockchain - blockchain specialists were needed for both initial

development and upkeep.

By using the new Bluzelle database service, we would port the KYC Shared Ledger intellectual

property into a service that non-blockchain-savvy database developers are familiar with. It


does so by exposing the same API's and following the same standards that established off-the-

shelf database products already follow.

With this decentralized database service, we would have eliminated any need for a team of

costly blockchain specialists. There would have been no blockchain-specific code in KYC, and

therefore the database-related time and effort in KYC would have been reduced by 90%, to the

level that a “regular”, non-decentralized application would have incurred, yet with all the

benefits of decentralization mentioned in this paper.


8. Bluzelle’s Ecosystem Data storage is a fundamental requirement in almost every software product, and storing that

data in a scalable and cost-efficient place that’s easily accessible by the consumer is the holy

grail, thus the demand for Bluzelle is both pre-existing and forthcoming, as well as

indisputable. The opportunity to get Bluzelle into the hands of consumers is tremendous. The

key to consumption is dissemination, and the key to dissemination is making Bluzelle as easy

and natural to use as possible for the target customer: developers.

8.1. Developer Marketplaces Bluzelle is partnering with leading software development ecosystems (typically PaaS) and 9

establishing channel partnerships that share revenue. Notable examples include Heroku, AWS

Elastic Beanstalk, Redhat OpenShift, Google App Engine, and Microsoft Azure. With such

integrations, developers can quickly use Bluzelle’s decentralized database, just as effortlessly as

they can use traditional cloud database offerings - simply point and click. With such

partnerships, Bluzelle is available to the largest developer ecosystems in the world. Billing and

payments are seamlessly done through the channel partner’s existing environment, resulting in

immediate revenues.

8.2. Developer Environments Development environments such as Android Studio, Apple XCode, Microsoft Xamarin and

Visual Studio, Eclipse, IntelliJ, Unity3D, PhoneGap, and Ionic are targeted for plugins and 10

integrations so that developers of both desktop and mobile apps can easily integrate Bluzelle

whenever they have database needs for their games, enterprise applications, etc.




8.3. Blockchains Blockchains play a large role in the Bluzelle ecosystem. Smart contract classes and instances are

deployed directly into Ethereum, Quorum (Ethereum’s JP Morgan cousin), and other related 11

blockchains to enable DApp smart contracts to use Bluzelle for storage needs.

8.4. Operating Systems and Browser Tools Operating-system and browser tools further enhance the developer’s ability to access data, 12

whether it is from a GUI application running on their desktop or a browser plugin that enables

them to quickly store and retrieve table data.

8.5. Payment Bridges Payment bridges enable other forms of currency to be used that convert to and from Bluzelle’s

ERC-20 BLZ token . These improve liquidity, add value to the BLZ token, provide the ability to 13

do micropayments in any suitable currency, and ultimately drive more demand and supply to

the Bluzelle economy.

The key to success here is maximization of Bluzelle service consumption. If consumption is

achieved, production will be achieved. The result is a vibrant economy.





9. How Does Bluzelle Work? Using concepts taken from NoSQL (non-relational SQL), Bluzelle's first incarnation is a key-

value storage that exploits horizontal data sharding partitioning concepts to split databases,

irrespective of size, into smaller, faster, and more easily managed parts called data shards (shard

means "a small part of a whole"). Bluzelle takes this concept and marries it with blockchain

concepts to create a powerful economy of producers and consumers. In modern nomenclature,

it a crypto-economic network. In later versions, vertical partitioning will be added, with the

ability for the consumer to direct how and where partitioning occurs on both axis’.

The producers (aka farmers or miners) provide resources in the form of CPU processing power,

memory, permanent storage, and network connectivity to enable database shards to be stored

with sufficient partial replication across a swarm of swarms of nodes (a metaswarm) to

guarantee availability and redundancy. In later versions of Bluzelle, a smaller, proportional

“stake” will be put up as collateral by a producer as an incentive for them to guarantee

reliability. The stake can be proportionally lost, if sufficient metrics are not met.

Consumers use Bluzelle's database services provided by the collective whole (all the producers),

and in turn pay for the services using the Bluzelle ERC-20 Token (BLZ) and Bluzelle Native

Token (BNT) . They have control over attributes that dictate how and where their data is 14

stored, that will affect the BNT cost for these services.

Initial peer data needed for new nodes or client applications to bootstrap themselves with

Bluzelle uses the Ethereum blockchain (a pre-existing decentralized network) as a basis to get

all associated data in a reliable, scalable, and low-cost way. This approach does not reduce the

degree of decentralization of Bluzelle.

BLZ and BNT tokens can be interchanged using the Bluzelle Token Gateway, described below.14


9.1. The F Function The F function is the logical shard function. It takes in as input the key that is being referred to

and outputs the id of the swarm of interest. The input key can be one of the following:

➢ Single string value representing the literal key in a key-value pair.

➢ Top-level (non-collection) document key id.

➢ A dynasty key . A dynasty key enables a group of key-value pairs to be sharded with 15

the guarantee they end up in the same swarm, an ideal means for performance

optimization.

➢ Index value for a search of documents in a document collection. In this latter case, the 16

result of the F function points to a leaf swarm that contains a list of all keys for

documents that match the search criteria in the right order of the index.

➢ Fully-qualified partition key value for a subdocument that was horizontally 17

partitioned off a collection document.

➢ Literal key value for a collection object.18

9.2. The G Function The G function takes in as input the identification information of a node including its IP 19

address, port number, tunneling information, as well as its hardware resource index . The G 20

function outputs a list of swarm id’s, stating which leaf swarms the node is to join and replicate

data for.

Refer to the section below on Dynasty keys.15




The details of the G function are intentionally not included in this white paper.19

A value on the scale of 1 to 10 on how much resources the machine has. More powerful machines have higher values.20


9.3. What is a Bluzelle Participant? Every participating consumer and producer of Bluzelle are required to independently create

their own Ethereum account, and take responsibility for securing and protecting their private

key. The private key is used to secure access to their ETH and Bluzelle tokens and encrypt their

data. A password of the consumer’s own choosing is used to encrypt all consumer data before it

gets sent out over the network to Bluzelle swarms. Initially, Bluzelle requires the participants to

each have their own Ethereum account and protect their private keys on their own. Bluzelle will

optionally take on this responsibility in later versions. Participants are required to have a

minimal amount of ETH in their account so that outgoing payments of the Bluzelle token can

occur. On the testnet, a faucet is available where participants can get free ETH and Bluzelle

tokens. On the public Ethereum network, each participant is responsible for acquiring their own

ETH and Bluzelle tokens.

Although we delineate the two roles below, it should be noted that there is no technical

difference between what an actual consumer and an actual farmer can do. A consumer could

become a farmer if they start to provide resources, and a farmer could become a consumer if

they start to use resources. The distinction in roles is simply a product of activity choices.

9.3.1. Consumer

The consumer is the user of Bluzelle, and who “consumes” the database services. Users are

typically spending BNT tokens so that they can store and retrieve data, although a user could

get a credit of tokens in later Bluzelle versions, if a farmer failed to meet certain service levels,

via the proportional stake requirement.

9.3.2. Producer

This is the farmer, providing resources to the network in return for earning BNT tokens into

their Ethereum account. Farmers are typically earning tokens. In later versions of Bluzelle,

farmers will be required to put up a proportional stake of BNT tokens, in order to provide a


guarantee on the service levels Bluzelle will provide. This “proof of stake” requirement is 21

common in blockchain technology. In Bluzelle, it will encourage competition by farmers to

provide higher quality services, where farmers with higher service levels can charge more but

also have to put up a higher stake. Producers are all nodes, in the technical context of Bluzelle.

Post-MVP Bluzelle roadmap. 21


10. The Bluzelle Token Bluzelle is powered by two tokens:

➢ Ethereum ERC-20 external token: BLZ.

This externally-tradable token bridges the Bluzelle network’s native BNT token with

Ethereum’s own native ETH token.

➢ Bluzelle Network Token: BNT.

This is a token native to the Bluzelle network. It is internal to Bluzelle alone, and enables

the Bluzelle crypto-economy, where consumers pay in BNT tokens and producers earn

in BNT tokens.

The Ethereum blockchain, while universally accepted as a standard crypto-currency blockchain

that bridges many other ERC-20 tokens like BLZ, operates within the constraints of a

blockchain. It is limited by block confirmation times, as well as mounting transaction costs

every time a transaction is sent on Ethereum. The latency in transactions “completing” and 22

the high cost for each such transaction makes the ERC-20 token unsuitable as a direct

representation of value for Bluzelle’s network transactions.

More succinctly:

Ethereum and its ERC-20 tokens are too slow and expensive for real-time database accounting.

The BNT internal native token exists to enable high-speed, zero-cost, and real-time database accounting.

Therefore, a separation is made. The BLZ Ethereum-compatible ERC-20 external token exists to

represent on exchanges for customers to easily obtain to use the Bluzelle service. The BNT

native token exists within Bluzelle’s network itself, and can be exchanged with minimal latency

and with zero cost. The BLZ and BNT tokens can be interchanged via the Bluzelle token

gateway, described below. The interchange provides a source of revenue for Bluzelle Networks

Inc. itself, while still maintaining a decentralized model.

A transaction is deemed completed once both the database (CRUD) transaction has completed AND the payment has been 22

confirmed/completed.


10.1. Bluzelle ERC-20 External Token Bluzelle employs Ethereum’s ERC-20 standard to manage the tradable token behind its own 23

crypto-economy. Ethereum takes care of the need for a medium to hold, trade, transfer, buy, and

sell the Bluzelle Token (BLZ).

Following are some of the benefits of using Ethereum and ERC-20 in tandem with Bluzelle’s

own software:

➢ Liquidity to exchange BLZ for other ERC-20 tokens.

➢ Ability to buy and sell BLZ for Ethereum’s own native currency, ETH.

➢ A safe and secure environment to store the commodities of value that drive Bluzelle’s

economy.

Ethereum is not used for any means other than as the accounting framework and ledger for the

Bluzelle ERC-20 Token (BLZ). This is contrasted with many other infrastructural products that

use Ethereum also as a state machine. Ethereum’s cost of operation and storage as well as

latency makes it unsuitable and impractical for the purposes of a high-performance database

like Bluzelle. The Bluzelle Network Token (BNT), as described below, is used internally.

10.2. Bluzelle Network Token The BNT token is native to the Bluzelle network only, and therefore does not exist outside of it.

It is the commodity that is exchanged when a consumer pays a farmer for services, when a

penalty is charged, when a stake is put up, or when any other exchange of value occurs within

the Bluzelle network. BNT is therefore not tradable outside of the Bluzelle network. The

balances of BNT for every participant in the network is maintained internally as a special form

of consensus propagated across all the leaf swarms, called the BNT Consensus Ledger. BNT 24

can be transferred between participants on the Bluzelle network.

https://github.com/ethereum/eips/issues/2023

The finer details about the BNT consensus ledger are intentionally not included in this paper.24


When a new participant to the network wishes to use its services as a consumer, they will need

to acquire BNT tokens. The standard method of doing so is as follows:

1. Buy BLZ tokens on a crypto-exchange. Some exchanges might allow the purchase of

BLZ directly from fiat currencies like USD or EUR. Typically, BLZ can be purchased with

other cryptocurrencies like Bitcoin (BTC) or Ethereum (ETH).

2. Send BLZ tokens to the Bluzelle Token Gateway’s smart contract via Ethereum. The

gateway (described below) is both an Ethereum smart contract and a Ripple-style

gateway that enables the interchange between BLZ and BNT, autonomously and

securely. The gateway, in this step, will issue new BNT tokens to the user’s Bluzelle

network wallet, and take custodial ownership over the BLZ tokens.

3. The user now has BNT tokens, and is free to participate in the network as a consumer.

When a producer wishes to “withdraw” their BNT tokens, they use the following steps:

1. Send the BNT tokens to the special Bluzelle network entity called the gateway.

2. The gateway converts the BNT tokens at a fixed value of USD $1 each to BLZ tokens,

and sends these BLZ tokens to the producer’s registered Ethereum wallet.

3. The producer now has the BLZ tokens, and is free to transact with them on the Ethereum

network.

10.3. BNT Consensus Ledger The BNT token exists only within the Bluzelle network. A secure consensus ledger that is 25

updated constantly is maintained and propagated internally by the network. This ledger is

specifically for the purpose of maintaining BNT balances as well as tracking credits and debits.

It is loosely based on concepts taken from the Ripple protocol consensus protocol .26

This ledger is unrelated to the ledger storing Bluzelle consumer database shards.25

https://ripple.com/files/ripple_consensus_whitepaper.pdf26


10.4. Bluzelle Token Gateway The Bluzelle token gateway bridges the Bluzelle network with the Ethereum network, enabling

the flow of value between the two networks. In Ethereum nomenclature, the gateway is an

oracle that connects the two networks together. The oracle is still completely decentralized in

nature, consistent with the decentralized nature of the Bluzelle network. There is absolutely no

need for human intervention, for the gateway to serve traffic in both directions.

On the Bluzelle network side, the gateway is a Ripple-inspired service that can both issue new

BNT tokens and “burn” existing BNT tokens. Unlike Ripple’s XRP, BNT tokens can be issued

and burnt at will, with supply and demand dictated by the market and by the associated peg to

US dollars. This BNT gateway performs the following two functions:

➢ Issue new BNT tokens to Bluzelle network participants who have purchased these

tokens using BLZ ERC-20 tokens.

➢ Burn existing BNT tokens from Bluzelle network participants and notify the ERC-20

smart contract to release custodially-held BLZ tokens to the correct Ethereum wallet.

On the Ethereum side, the gateway is represented by a secured and fully autonomous smart

contract. The smart contract is the custodian of BLZ tokens but is also the sole authority that

requests the BNT gateway to release new BNT tokens to Bluzelle network participants. This

Ethereum-side of the gateway performs the following two functions:

➢ Take custodial access of BLZ tokens, calculate the market USD value of these tokens, and

request the BNT gateway to release BNT tokens to the correct beneficiary Bluzelle native

wallet, on a 1:1 USD peg basis. For example, if BLZ is worth USD $100.00, 100.0 BNT 27

tokens will be released for every BLZ token sent to the gateway .28

The USD 1:1 peg is critical to ensure the Bluzelle network is not affected by volatility of the BLZ token on open markets. It ensure 27

farmers can confidently manage their resources knowing their compensation is always pegged at a fixed fiat currency rate.

For convenience, the fee charged by the gateway is NOT considered here.28


➢ Receive requests from the BNT gateway to release BLZ tokens to the correct beneficiary

Ethereum wallet, taking into consideration the current USD value of BLZ tokens and the

1:1 USD peg value for BNT tokens. For example, if BLZ is worth USD $50.00, 0.02 BLZ

will be released for every BNT token sent to the BNT gateway .29

The Ethereum smart contract charges a fee for every transaction going through it, in either

direction.

10.5. Revenue The BLZ <=> BNT gateway charges 0.10% (10 basis points) as a fee for every conversion going

through the gateway in either direction. The fee is charged in BLZ tokens and is sent to a special

Ethereum wallet owned and managed by Bluzelle Inc. The revenue model is setup such that the

entire ecosystem remains completely decentralized while still providing a revenue model for

Bluzelle Networks Inc. to improve and innovate the network and its associated services.

The fee is charged both on incoming and outgoing transactions. Following are two typical

scenarios:

➢ A user wishes to buy BNT tokens.

1. The user sends 100 BLZ to the BLZ smart contract.

2. 0.1 BLZ is subtracted from the total of 100 BLZ and is sent to the Bluzelle

Networks Inc. Ethereum wallet as a non-refundable fee.

3. The remaining 99.9 BLZ is converted at market USD rates to BNT and credited to

the user’s BNT Bluzelle native wallet.

➢ A user wishes to sell BNT tokens.

1. The user sends BNT tokens to the BNT gateway.

2. The BNT tokens are converted at a USD 1:1 rate, resulting in a conversion

amount of 100 BLZ. 0.1 BLZ are subtracted from the total of 100 BLZ and is sent

to the Bluzelle Networks Inc. Ethereum wallet as a non-refundable fee.

For convenience, the fee charged by the gateway is NOT considered here.29


3. The remaining 99.9 BLZ is released out of custody by the Ethereum smart

contract and sent to the correct Ethereum wallet.

10.5.1. Granularity

Both the BLZ and BNT tokens are highly granular, as this section describes. For simplicity, the

BLZ token is mentioned to explain the granularity, but the same principles apply to the BNT

token as well.

The BLZ token is divisible to 18 decimal places, such that the smallest unit of value is the atto-

Bluzelle, valued at 10-18 BLZ, or more succinctly, 0.00,000,000,000,000,000,1 BLZ . The prefix for 30

“atto” is “a”, so the term “aBLZ” is often used to express values of the currency. Other terms 31

used are femto ( 10-15 BLZ), pico (10-12 BLZ), nano (10-9 BLZ), micro (10-6 BLZ), and milli (0.001

BLZ).

10.5.2. Rewards Mechanisms 32

In future versions of Bluzelle, consumers will be able to provide a numerical parameter that will

indicate their desire for faster results that implicitly means they are accepting a higher cost in

Bluzelle tokens. This higher payment adds to the Bluzelle ecosystem by providing a strong

incentive for farmers to compete to provide greater throughput and lower latency.

For consumers that are particularly conscious of reliability and availability and wish to keep

stronger tabs on this in a pro-active way, there is a means in the API for a consumer to do

random checkups on the “health” of their data, rewarding nodes which respond correctly to

challenge questions . In this context, it would be required for the API to maintain a client-side 33

Merkel tree that allows the consumer to challenge nodes and reward them accordingly.

We comma-separate the zeroes in a non-standard way here, for improved readability.30

Part of the metric system31




Bluzelle is a massive, multi-level, hierarchical peer-to-peer network. Each farming node is a

seed protocol. Each such node (seed) that provides data faster and more reliably gets rewarded

accordingly better. There is therefore a strong incentive for the farmers to deliver their copies of

logical shards in the best way possible, so their chances of winning the data-delivery race

increase. The end result is a better product for the consumer.


11. Bluzelle Technical Overview This section provides an overview of Bluzelle’s technology architecture. For a more in-depth reading with

more details refer to the Technology White Paper.

As described, Bluzelle is a swarm of swarms of nodes. Each swarm of nodes 100% replicates 34 35

the same data, while the metaswarm enables any swarm to talk to any other swarm with at

most log(n) requests, where each swarm’s nodes is each only required to store at most log(n)

entries of data to facilitate inter-swarm communication. Inter-swarm communication is key to

enabling the metaswarm to form a massive, cohesive network that we call Bluzelle.

Metaphorically speaking, there is no single general leading this global army called Bluzelle.

Bluzelle is not led by anyone, which is precisely what makes it completely decentralized.

Bluzelle does have a hierarchy of leadership, but at the highest level there is no singleton of

leadership. In this respect, Bluzelle can’t easily be compared to any earthly human organization.

The sections below explain the components in better detail.

In the nomenclature of networks, each leaf swarm is a network. The metaswarm is in fact a

virtualized construct, and considered an Internet, because it enables each leaf swarm network to

inter-connect. In this vein, Bluzelle is comparable to a completely decentralized Internet,

specifically catering to database services.

Most succinctly, Bluzelle is a decentralized database storage network.

The union of all the data amongst all the swarms in the metaswarm IS this single data storage

model , and the name we give it is Bluzelle.

The swarm of swarms of nodes is more specifically called a metaswarm.34

A swarm of nodes is more specifically called a leaf swarm.35


11.1. Bluzelle Harvesting Agent Bluzelle is ultimately powered by a single piece of software that resides on every node in the

network, irrespective of which swarm that node is in or if the node is a leader or not. That

software is one of the key deliverables from the Bluzelle project. It is a C++-based software that

drives all the logic in Bluzelle and that evolves regularly throughout the lifespan of Bluzelle.

Since the key work that this software does is harvesting of data for customers, it is called the

Bluzelle Harvesting Agent (KHA).

11.2. How long does data stay on the network? Does it expire? Every key-value pair, document, collection, document partition, and collection index comes

with an expiry date. Expiry ensures farmers are residually compensated for storage, and

obsolete data is removed to maximize space availability.

Expiration always carries the time of 23:59:59 UTC . The date of expiry is dynamically set 36

depending on the fee structure the data owner chooses when creating the data. Storing data 37

for the first tier of time comes at a certain cost in BNT tokens. Electing to have the data expire

past this first tier comes at an additional cost. The cost to time function for data expiry is

exponential, ensuring that data generally comes with an expiry that is not unreasonably far into

the future, and where farmers are adequately compensated for storage. It also ensures that

consumers are disciplined in setting expiry dates that are practical. Once stored, data is locked

in with n-tiers of expiry, where extensions change the new expiry date to be precisely n-tiers

into the future from the date of the activity that precipitated the extension.

Data expiry dates get extended by “touching” the data. If a data owner wishes to 38

preemptively “refresh” data, they do so by touching every such data unit. Of course, doing so

Coordinated Universal Time is the global standard by which clocks and time are regulated.36

Post-MVP Bluzelle roadmap. Initially, all data expires within the exact same timespan, using only the first tier.37

Touching includes an update or read.38


comes at a transactional cost that gets passed on as revenue to farmers. The data owner is

responsible for keeping track of which data units they own . 39 40

If a unit of data’s expiry date is reached, then at 23:59:59 UTC on the date of expiry, the data is

purged from all nodes on the leaf swarm storing the data.

11.3. What is a node? The key infrastructural building block of Bluzelle at the “leaf” level is the node, which is a term

synonymous with the farmer/producer, in the Bluzelle cryptoeconomy. The node is the field

agent that is ultimately doing the “physical work” of database storage for Bluzelle customers.

The node itself is a computer system that at a minimum has a network connection, processing

unit, and storage resources. The network connection allows the node to talk to other nodes or

customers. The storage resources are vital to store the database data, which is the “cargo”

carried by and stored by the network.

The node is also responsible for sending out payments to other nodes of Bluzelle tokens (i.e., to

share revenues in replicated scenarios) as well as receiving payments from consumers or other

nodes. As such, the node requires custodial access to the Ethereum private key of the farmer

operating the node.

The Bluzelle node’s software (KHA) is developed as a result of this white paper. Bluzelle is

ultimately a network that is the result of the most fundamental building block of the network --

the node, and the node is a result of a computer system running the Bluzelle Harvesting Agent

.41

To touch all your data, you need to know the key values of all your data.39

A “read all” function will be added in the future, but at great BNT token expense.40

The Bluzelle harvesting agent is the actual computer software a node needs to run to participate in Bluzelle.41


11.3.1. Node minimum requirements

A node is required to meet certain minimum requirements to join Bluzelle as a farmer. Although

there is a baseline for these requirements, these will automatically and dynamically increase

over time as the network and the demand for it grows. Consequently, the minimum

expectations of a farmer will also increase. Micro-economically, this is the model Bluzelle was

modeled upon.

The minimum standing requirements are verified and validated by KHS and the network, when

a node starts up as well as on an ongoing basis for long-running nodes. A key metric and

limiting factor of the node is its capacity to store data -- namely, how much can it store?

11.4. What is a leader node? A special node in every leaf swarm is the leader of that swarm, called the leader node. The

RAFT consensus protocol chooses a leader for the swarm automatically, and that leader remains

in that role as well as playing the role of a field agent doing groundwork until the leader goes

away, at which time a new leader is chosen automatically and democratically. In the human

world, the leader node can be considered the leader of a team of workers “on the ground” doing

field work. This leader is called a manager in corporations and sometimes called a platoon

lieutenant in the army.

As stated above, when a leader node is replaced within its leaf swarm, the swarm’s new leader

is responsible for informing all the subordinate swarms in the swarm’s virtualized metaswarm

about this change in leadership, so they each can update their Kademlia finger tables.

11.5. Universal Bluzelle Locator The Universal Bluzelle Locator, or UKL, is a fully qualified address of some resource located on

the Bluzelle network. It can be loosely be compared to a URL, as is used to locate resources on

the web. Although nodes are a part of the swarm, they still need to be referred to directly in

literal network connections, and for this reason, the UKL exists.


Key Value Pairs and Virtualized User Tables:

Resource Type UKL

Virtualized User Table on Network

Description:

This refers to the entire table of key value pairs belonging to a certain consumer’s Ethereum address on the network as a whole . While it can be an expensive operation, it is nonetheless required if the client wishes to refer to all their data on the network.

In the typical use of this UKL, the network is responsible for figuring out where all the shards of data reside and intelligently gather these shards to gain access to all the data.

Format:

kepler://consumerEthereumPublicKey

Example:

kepler://0xf4833b50b38e1b00e48d94dfbfa560146f91725e

KeyValue Pair on Network

Description:

This refers to the value of a certain key value held by a certain consumer’s Ethereum address on the network as a whole.

In the typical use of this UKL, the network is responsible for figuring out where the data resides, and find the right swarm and node-specific UKL for the data to gain access to the data.

Format:

kepler://consumerEthereumPublicKey:DataKey

Example:

kepler://0xf4833b50b38e1b00e48d94dfbfa560146f91725e:Bluzelle

Internal Only:

KeyValue Pair on specific swarm via Swarm Id

Description:

This refers to the value of a certain key value pair held by a certain consumer’s Ethereum address on a certain swarm, identified by the swarm’s id (also called a logical shard number).

This format will only typically be used internally by the network’s nodes and not by consumers directly or their APIs.

Format:

kepler://integerSwarmId/consumerEthereumPublicKey:DataKey

Example:

kepler://1976/0xf4833b50b38e1b00e48d94dfbfa560146f91725e:Bluzelle


Nodes and Swarms:

Internal Only:

KeyValue Pair on specific node via Physical Node Hash Id

Description:

This refers to the value of a certain key value held by a certain consumer’s Ethereum address on a certain physical node, identified by the node’s own physical hashed identifier.


Format:

kepler://physicalNodeHashId/consumerEthereumPublicKey:DataKey

Example:

k e p l e r : / /Ae71eec5b62b41c7a1bdc57aabebb867a10181eb7891b807086e920213c1ec95/0xf4833b50b38e1b00e48d94dfbfa560146f91725e:Bluzelle

Internal Only:

KeyValue Pair on specific node via Farmer Node Triple

Description:

This refers to the value of a certain key value held by a certain consumer’s Ethereum address on a certain physical node, identified by the node’s hostname/IP and port number.


Format:

kepler://farmerNodeHostnameOrIP:port/consumerEthereumPublicKey:DataKey

Example:

kepler://foo.com:1000/0xf4833b50b38e1b00e48d94dfbfa560146f91725e:Bluzelle

Internal Only:

Specific swarm via Swarm Id

Description:

This refers to a certain swarm, identified by the swarm’s id (also called a logical shard number).


Format:

kepler://integerSwarmId

Example:

kepler://1976


11.5.1. Farmer Node Identification

Each farmer node is uniquely identified by a tuple consisting of the node’s hostname or IP

address and the TCP port number on which the farmer node service is running.

For example, a farmer node at foo.com on port 1000 would have the following tuple:

foo.com, 1000

As a more modular format, a farmer node can also be identified by the unique and consistent 42

SHA3-256 hash of its tuple, known as the physical node hash id.

For example, the SHA3-256 hash of “foo.com:1000” as above is:

Internal Only:

Specific node via Physical Node Hash Id

Description:

This refers to a certain physical node, identified by the node’s own physical hashed identifier.


Format:

kepler://physicalNodeHashId

Example:

kepler://Ae71eec5b62b41c7a1bdc57aabebb867a10181eb7891b807086e920213c1ec95

Internal Only:

Specific node via Farmer Node Triple

Description:

This refers to a certain physical node, identified by the node’s hostname/IP and port number.


Format:

kepler://farmerNodeHostnameOrIP:port

Example:

kepler://foo.com:1000

We hash the information with SHA3-256, making the output unique for intents and purposes.42


Ae71eec5b62b41c7a1bdc57aabebb867a10181eb7891b807086e920213c1ec95 43

This physical node hash id can therefore also be used to refer to the node at foo.com:1000, as is

used in UKL’s.

This physical node hash id is vital in order to ensure that nodes can identify each other within a

leaf swarm uniquely and is also heavily used in the finger tables used in Kademlia hashing.

https://emn178.github.io/online-tools/sha3_256.html43


12. Roadmap We break down the development of Bluzelle into two distinct phases -- the minimum viable

product (MVP), and the post-MVP product releases.44

12.1. MVP Feature Set Initially, Bluzelle implements a subset of the dynamic 2D partitioning mechanisms defined by

horizontal partitioning exclusively. It is a form of horizontal partitioning based on consistent

hashing using homogenous sharding size strategies. Algorithmic categorization is used to

determine which logical shards contain which data and therefore which leaf swarms to assign

the data into.

Bluzelle uses a simpler set of sharding schemes in its initial versions for cost and time reasons.

Initially the consumer is not given the opportunity to fine tune or specify how and where

partitioning occurs nor many other attributes that are in the future roadmap. The goal of the

MVP is to enable consumers of Bluzelle to connect to the system, create objects, use these

objects, and have the back-end systems automatically apply partitioning and sharding

strategies. These will be greatly augmented in future versions of Bluzelle.

The CRUD functions are limited to being able to process one “key-value pair” at a time. This

might not be the most efficient mechanism, but it is easier to implement for MVP purposes.

12.2. Post-MVP Roadmap Bluzelle’s post-MVP roadmap consists of five releases, each named after a scientist. This is a

preliminary plan and will evolve during the course of the MVP’s life cycle. For example, items

may move between the releases listed here. New items might be added and some items might

be removed. A key common attribute is that new functionalities and features will be added with

every release deliverable.

MVP, which is our initial version that is to be released to the public.44


April 2018 - Minimum Viable Product

Features: NoSQL key-value pairs, Bluzelle Harvesting Agent, leaf swarms, consensus, horizontal

partitioning, consistent hashing, CRUD API, Bluzelle tokenization, ERC-20 token gateway, versioning

and backup/restore, dynasty keys

August 2018 - Kepler

Features: PaaS integrations, IDE plugins and integrations, blockchain smart contracts, desktop and

browser and mobile apps for interactive access, import/export from legacy databases, node scoring and

health metrics

December 2018 - Einstein

Features: NoSQL documents, NoSQL document collections, NoSQL document collection indices, NoSQL

document collection partitions, global CRUD operations, batch CRUD operations

April 2019 - Leibniz

Features: Proof of storage Merkel challenges and rewards, proof of stake requirement for farmers, variable

CRUD request pricing, edge caching of data close to requests, request parallelism and hotspot support,

Spartacus attack tolerance

August 2019 - Archimedes

Features: Vertical partitioning, 2D partitioning, variable-cost data expiries, Sybil attack tolerance,

deletion reversibility, proof of redundancy via erasure coding

December 2019 - Turing

Features: Column stores, S/Kademlia improvements, Honest Geppetto attack tolerance, 3rd party

arbitration against Cheating Owner attacks, reverse http tunnelling, tunnel eclipse attack tolerance,

multiparty encryption, complex binary blob storage support

For further details on the Post-MVP Roadmap, please refer to the Technical White Paper.


13. Credits

13.1. Authors Neeraj Murarka, CTO, Bluzelle Networks

Pavel Bains, CEO, Bluzelle Networks

13.2. Contributors Mehdi Abdeh-Kolahchi, Software Engineer, Bluzelle Networks

Nitin Cunha, Software Engineer, Bluzelle Networks

Philip Neves, Software Engineer, Bluzelle Networks

Richard Nistuk, Software Engineer, Bluzelle Networks

Scott Burch, Software Engineer, Bluzelle Networks

Brian Rothstein., Seattle, WA, United States of America.

Dan Harris., Los Angeles, CA, United States of America.

Robin Murarka., Perth, W.A., Australia.

Ryan Fugger., Kelowna, B.C., Canada.


bluzelle white paper v 1 -...

Documents