BGX Bluepaper MOCK

ABSTRACT V 1.0 2018.03.27

BGX Blue Paper, v 3.0 Breaking Down of the BGX Platform Technology

BGX_BLUEPAPER_3.0 0 ABSTRACT V 3.0 2019.01.09

ABSTRACT

This document describes the technological understanding of the BGX Platform, the integrative distributed ledger for a new generation of business networks. The first open- source distributed ledger focusing on digital assets, BGX provides a seamless and easy integration between businesses – using decentralization to construct shared economic mini-ecosystems. The core differentiators of the transformative BGX distributed network is the hierarchal topology of nodes, the ability to exchange digital assets in reloadable transactions, not just currency, the anchoring of the system, its unique API capabilities, and the dual token system. Among particular importance is the F-BFT Consensus that enables the hierarchal topology, as well as unlimited horizontal and vertical scalability of the network’s throughput. The data processed by the network is placed in a special structure of the DAG (Di- rected Acyclic Graph) instead of blocks; it has the ability to grow in several directions simultaneously, unlike a blockchain. The main theses of the presented model: • Commitment to open and decentralized solutions that allow the use of technology for the benefit of society, aimed at safety and free use; • The main technological solutions essentially depend on the business model and the customer value proposition, the technology and architecture should be maximally harmonized with business priorities; • There is no universal panacea for building the architecture of a modern distributed technological system; to build sustainable solutions, it is necessary to find a compromise between scaling, security, decentralization and the cost of the solution; • The blockchain revolution continues, in addition to popular first-generation networks such as Ethereum and Blockchain, advanced solutions such as IOTA, HASHGRAPH / HEDERA and STELLAR appear. The computational model of new solutions must be based on rigorous mathematical concepts and use provable approaches.

The BGX NetworkBGX_BLUEPAPER_3.0 1 CONTENT V 1.0 2018.03.27

CONTENT ABSTRACT ...... 1 CONTENT ...... 2 1 INTRODUCTION ...... 4 1.1 BGX Project Scope ...... 4 1.2 BGX Group Innovation Approach ...... 4 1.3 Blockchain 3.0 ...... 5 1.4 The BGX Platform ...... 7 1.4.1 The BGX function ...... 7 1.4.2 Platform tokenization ...... 8 1.4.3 Usage scenarios ...... 9 1.4.4 Content of the platform ...... 12 1.5 Outlook on the blockchain market of 2019 ...... 13 2 TRANSACTIONAL SUB-SYSTEM ...... 13 2.1 Payment Process ...... 13 2.1.1 BGX Platform as a Payment System...... 13 2.1.2 Stable coin approach ...... 15 2.1.3 Payment scenarios ...... Error! Bookmark not defined. 2.1.4 Life cycle of the transaction ...... 15 2.2 Prerequisites for the formation of a consensus protocol ...... 18 2.2.1 Bitcoin Blockchain and its mechanisms for protection ...... 18 2.2.2 The Byzantine Generals Problem ...... 19 2.2.3 Implementation of the consensus mechanism ...... 19 2.2.4 Scalability attempts ...... 21 2.2.5 Consensus models in distributed systems ...... 22 2.2.6 Approach of BGX Processing ...... 25 2.3 BGX Payment Protocol ...... 29 2.3.1 Internal and External Processing ...... 29 2.3.2 Transaction Structure ...... 29 2.3.3 Hashing and Signing of Transaction ...... 30 2.3.4 Validation and verification of transactions ...... 30 2.3.5 The Base Layer ...... 30 2.3.6 Algorithm protection ...... 31

BGX_BLUEPAPER_3.0 2 CONTENT V 3.0 2019.01.09

3 ARTIFICIAL INTELLIGENCE ...... 32 3.1 Machine Learning Approach ...... 32 3.2 BGX Fraud Detection Math Model ...... 34 3.2.1 Model Inception ...... 34 3.2.2 Fuzzy Neural Network ...... 36 3.2.3 The Resume ...... 39 4 PLATFORM ARCHITECTURE ...... 40 4.1 Design Approach ...... 40 4.1.1 Architecture as a Policy ...... 40 4.1.2 Business Process Overview ...... 42 4.1.3 Referencearchitecture ...... 44 4.1.4 Stakeholders and Actors ...... 48 4.1.5 Assumptions ...... 49 4.2 BGX Network ...... 49 4.2.1 BGX Node ...... 49 4.2.2 Node Interactions ...... 51 4.2.3 Transaction Verification ...... 53 4.2.4 Node Authorization Channel ...... 54 4.3 User privacy...... 55 4.4 Interoperability ...... 56 APPLICATION 1: CONSENSUS TYPE ...... 58 APPLICATION 2: DISTRIBUTED TRANSACTION SYTEMS ATTACKS ...... 60 APPLICATION 3: DECENTRALIZATION PLATFORM DESIGN DESCISION ...... 61 APPLICATION 4 KEY TERMS ...... 61

The BGX NetworkBGX_BLUEPAPER_3.0 3 INTRODUCTION V 3.0 2019.01.09

1 INTRODUCTION 1.1 BGX Project Scope BGX is a decentralized solution that eliminates intermediaries and excess costs, while allowing businesses to easily attract new partners.

BGX is irreplaceable in dealing with competitive threats in a customer-facing industry, a market with a large number of participants, a conflicted environment, and where digital data and goods are involved.

BGX unites businesses that sell related goods. A national marathon event opens up a top node on BGX. A running store joins the ecosystem and every time someone signs up for the marathon, they get “run points” to spend at the running store. A gym chains joins the circulation. Then come podcasts, fitness brands, sport events, advertisers... united by the common customer they share. Developing this infrastructure would take years for each industry, each business. Not with BGX.

BGX unites businesses that sell unrelated goods too. A coffee shop chain awards 3 “cup points” for every $1 spent inside. These cup points can be redeemed at one of the four national telecom providers, who joined the coffee shop’s ecosystem. Every customer that buys a coffee at the chain now has a subsidized phone bill. That’s added value other coffee chains can’t offer. Meanwhile the telecom giant gets recommended to a customer, new and old, every time they buy a coffee at the large chain. That’s a serious advantage in a saturated phone service market. Each new business participant in the ecosystem makes it grow and adds value.

BGX unites businesses down the value chain, optimizing logistics, allowing businesses instant data analysis and statistics on their franchises and offices.

BGX allows the most far-seeing business in a saturated market to step back, open a top node, and start earning from directing data and customers between what used to be its competitors, but are now its business clients.

Whatever the use case may be, the versatile, scalable, and integrative nature of BGX allows companies to build synergetic ecosystems, without the need to develop the technological infrastructure or thousands of relationships themselves.

1.2 BGX Group Innovation Approach BGX is a Canadian – Swiss group of companies developing the BGX processing platform, aimed at processing the data and transaction exchange in a B2B2C approach (business-to-business-to-customer). Decentralization is a growing part of today’s economy. It helps cut out inefficient intermediaries; improve security, trust, and privacy; solve many information flow problems; and bring businesses and individuals together to create value. By its very nature,

The BGX NetworkBGX_BLUEPAPER_3.0 4 INTRODUCTION V 3.0 2019.01.09 business cannot be fully decentralized, as that would cause a lack of management and profit motivation. That is why we believe that businesses will become quasi-decentralized. The adoption of distributed ledgers to solve real problems will skyrocket, once projects launch that are technologically and economically capable. At the same time, businesses will remain distinct and defined entities. With that in mind, we are building a blockchain for businesses. Blockchain, or more broadly – distributed ledgers will continue to grow beyond their most basic and currently most prominent use for cryptocurrencies. Instead, they will solve problems in any area and industry that requires cooperation between a multitude of parties or management of big data. We are seeing this transformation now, with a new generation of industry-focused blockchains gaining ground in more than the mere transfer of money. We are not maximalists, but our vision is that distributed ledgers will take their rightful place to make the economy more equitable and efficient. With each new business participant, the BGX Network is posed to provide increas- ingly greater value into the future. There will be other distributed business networks – some will occupy their own niches, others will fail to gain traction. Distributed solutions will become mainstream and giant corporations will have to take the leap – or they will not survive competing with the ones that do.

For now, BGX is aiming at increasing its applicability, building up its value, and addressing problems in specific market niches that only decentralized solutions are able to resolve. Even with mainstream adoption bringing in some new, and sometimes strong competitors, BGX will undoubtedly grow in the value it can bring to its share of the global economy of businesses.

BGX is a modern team of professionals, ready for economic challenges, using new models for the development of financial infrastructure. We look forward to building the future of B2B cooperation and bringing along all of our early supporters, investors, and partners with us to success.

1.3 Blockchain 3.0 Blockchain is a special data structure implemented in the form of a linked list (block chains), usually implemented as a distributed system, where a copy of the list is stored on many computers (nodes) and synchronized by a special protocol. The Blockchain solution was proposed by the legendary founder of the network of the first successful Bitcoin-Satoshi Nakamoto crypto currency in the form of a practical implementation of bitcoin as its public transaction ledger. Although many of the technological solutions were laid in the first implementation of the protocol (block encryption, the solution of the double-spending problem, currency mining), for a while the approach remained an application to Bitcoin and an integral part only of this decision. This time, which can be called a generation of Blockchain 1.0, for several years the crypto community

The BGX NetworkBGX_BLUEPAPER_3.0 5 INTRODUCTION V 3.0 2019.01.09 tested the system for various types of attacks and looked for vulnerabilities in the proto- wheel, and around the original system there was an access infrastructure for Bitcoin nodes - wallets, programs for mining. In 2013, the young founder of the magazine Bitcoin Magazine Vitalik Buterin suggested a new concept of the blockchain network - Ethereum. The main difference of this system was the ability to perform small unchanged programs - smart contracts. Ethereum was launched on July 30, 2015 and revealed a new generation of block systems - Block- chain 2.0. It was Ethereum that brought blockchain technology to a new level, allowing distributed computing as part of the new economy. This led many projects to realize their own virtual currency, including secondary tokens. The growth of the crypto economy over the next few years brought into use a whole pool of technological solutions, some of them were aimed at solving applied solutions, others were looking for new and more efficient algorithms. The main problems of previous solutions, including Ethereum and Bitcoin, were identified with the growing number of users: • Insufficient performance. The performance of the majority 1 of popular blockchain systems remains a big issue. For comparison for big fiat funds2:

Solution Transactions per second Fee (USD) Bitcoin 3-7 tx/sec $2 - $11.38 Ethereum 20 tx/sec $0.01 - $0.1 USD PayPal 193 tx/sec 4.2% (Outside US) Visa 24,000 tx/sec 1.43% - 2.3% Western Un- 30 tx/second $22 (Wire Transfer) ion

• Significant volatility, stopping the use of cryptocurrencies as a payment method in everyday use; • The complexity of the interfaces and the lack of Compliance mechanisms (refund protocol);

1 There are exceptions, for example Ripple (1,500 Tx / sec) and NEM (4,000 Tx / sec) achieve such a performance due to a significant limitation of decentralization, and Stellar (1,000 Tx / sec) and IOTA (13-15,000 Tx / sec), they are discussed below 2 Direct comparison of rates and transaction costs between fiat systems and crypto-currency services is difficult: crypto systems use the payment method - push, and credit cards - pull method (account data is transferred to the recipient, and it requests a write-off from it), cryptosystem authentication is decentralized, and in the system of systems, as a rule, centralized

The BGX NetworkBGX_BLUEPAPER_3.0 6 INTRODUCTION V 3.0 2019.01.09

• Low level of flexibility, manifested in the rigidity of some protocols and impossibility, for example, to change the previously published smart contract, even with the consent of the parties.

Analyzing the situation, we can say that the main advantage of the blockchain systems of the first two stages - the ability to function in an untrusted network, implemented through sophisticated consensus-building protocols (such as Proof-Of-Work or Proof-Of- Stake), is also their vulnerable place, reducing the processing speed of transactions, and in the case of PoW, complementing the system with useless energy expenditure. Basically, Blockchain 1.0 created an economic basis - the crypto currency, Block- chain 2.0 brought the concept of smart contracts. The next generation of cryptosystems went right to the implementation of applied tasks, the formation of a secondary market, which also requires its own infrastructure. Such systems can be called Blockchain 3.0. The concept of Blockchain 3.0 is based thus on the fundamental fact that e-currency can reflect value, created by users of the system, that is, the value of the ecosystem. By its nature, such a value is decentralized, and therefore used crypto systems should be decentralized to some extent. New application systems (Filecoin, Namecoin, Wanchain) supplemented with solutions such as IOTA (blockchain for Internet of Things), Stellar and Hashgraph / Hedera may differ significantly from the initial principles of building a classic bitcoin network, however, they continue the same line for decentralization in the distribution of value created by users. We can say that the Blockchain 3.0 systems have the following specific features:

• Have an open architecture (developed by the community, have intelligi- ble auditable processes); • Supported by an internal currency that reflects the value that they operate on; • Use a decentralized mechanism for approving transactions (cons-sous); • Use decentralized computing and do not have a single point of failure; • An integral part of the system is the API, which allows application systems to interact with the core in a unified way (interoperability); • Have a performance corresponding to the load profile adopted in the corresponding domain.

1.4 The BGX Platform 1.4.1 The BGX function The BGX Platform aims to simplify alliances between businesses by providing a technological and economic infrastructure for establishments of quazi-open economic spaces, ecosystems, common spaces of value.

The BGX NetworkBGX_BLUEPAPER_3.0 7 INTRODUCTION V 3.0 2019.01.09

• EFFECTIVE BUSINESS INTEGRATION o BGX developed the technological infrastructure to allow businesses attract partners that share the same customers, data, or value creation opportunity with them. The initializing business has control over who joins their ecosystem, but could leave it open for a company in any region, of any size, and in any market to join and contribute its customers, data and value.

• INSTANTANEOUS DATA CLEARING o Without a decentralized database like BGX, businesses have no ability to process all of the data coming from their omni-channel interactions, their social media engages users, or even in their own complicated supply chains. With BGX, there is no need to hire an army of financial analysts or integrate complicated software that is already obsolete once it’s fused into the company’s processes. With BGX, data is stored securely and insight is available fast for the right business decisions.

• DIGITAL GOODS o BGX is one of the only decentralized ledgers that allows the transfer of not just finances, or device data, but also any kind of digital good. That enables businesses to take advantage of the additional opportunities connected with offering more value to their customers, or earning from processing purchases on digital content. The product was implemented in the original alpha release as an open source code for the network under the Apache 3.0 license, as well as a set of white-label instruments, such as mobile applications. 1.4.2 Platform tokenization For the functioning of the platform, a special economic model is implemented - a binary system consisting of two tokens with different characteristics. The unique two-tier system maintains the balance between the interests of commercial sites and consumers of digital content The first token is the DEC Token.

• The DEC Token is an ERC-777 token. It will be held by the nodes and sold on exchanges. • The DEC Token will be used by nodes to emit secondary BGT Coins which are used for inter-platform transactions. • There will be 42,615 mil DEC emitted. The one-time emission occured in Novem- ber 2018.

The BGX NetworkBGX_BLUEPAPER_3.0 8 INTRODUCTION V 3.0 2019.01.09

• As an individual or business, you can acquire DEC Tokens on any of the listed exchanges or directly from BGX. • Embedded growth mechanics include limited supply, consistently rising demand (as system grows), and a buy-out initiative from the nodes. • DEC Token will follow a strict no-scam ideology. That means that BGX is fully transparent and proactively open about any distribution of its Token.

The second token is the auxiliary white-label “BGT” Coin.

• The BGT Coin is emitted by the top node in each ecosystem and used within the economic ecosystem that node leads to transfer value. • The BGT Coin can take many forms. It may convey loyalty miles sold by airlines, minutes sold by telecom, coins, points, any calculable value. • Each node will be able to emit the amount of BGT Coins proportional to the value of the DEC it is holding and placing in escrow. • Atomic swaps allow exchanging these sub-tokens within the system from one ecosystem to another for zero fees. • Individuals may acquire BGT Coins as rewards from businesses, or buy them using cryptocurrency, fiat funds, or DEC Tokens. • This two-tier system satisfies both investor interests in volatility and consumer interests in stability.

The tokens are non-fungible. This enables maximum transparency and protects all holders from crypto-exchange scams and price manipulations.

1.4.3 Usage scenarios The BGX Platform is targeted to bring the most benefit to enterprises existing in complicated systems with many other participants – be that competitors, customers, sup- pliers, regulators, or others. While that is a broad definition, BGX decided to focus on several distinct verticals, chosen for their technology readiness and potential use case benefit: DIGITAL RETAIL Customer-facing businesses are under immense pressures. Cooperation with other businesses for customers, product creation, experience enhancement, and offering added value is the only way to survive under increasing pressure of globalized online competitors and new waves of technology-informed consumers. Digital transformation, internet-native consumers, and market saturation are creating challenges and opportunities for all customer- centric businesses.

Profits on core products often fall faster than costs of making them. Innovation is difficult to perform in most large corporations, which are being pushed by younger, dis- ruptive projects. The companies that thrive in this environment are those that are capable of adapting their business model to the new conditions.

The BGX NetworkBGX_BLUEPAPER_3.0 9 INTRODUCTION V 3.0 2019.01.09

The essential part of a successful modern business model is cooperation. Airlines fall alliances that help them direct the flow of customers. Telecom companies are branching out into digital media, placing monetizable content into the consumer devices they already have access to.

However, this process is painstakingly slow. One-on-one deals take long to form and are ineffective. While building a coherent ecosystem of loyal customer communities, business partners, omni- channel communication, data utilization – that can take years.

SUPPLY CHAIN

Current supply chains are filled with inefficient intermediaries, delays due to errors, audits and paperwork, fraud, inefficient inventory management, and lack of transparency. That adds to costs at every checkpoint, which trickle down to dramatically diminish profit margins. Emergence of computers has caused dramatic shifts in the supply chain industry in the 1980s. Almost thirty years later, blockchain presents itself as a new vehicle of sweeping change. With its ability to track information in an immutable, secure, transparent – and importantly decentralized way, blockchains can take on recording, tracking, assigning and linking functionalities.

The BGX Network is a step further. By enabling ecosystems for many business participants, yet at the same time optimizing their inter-connections, BGX goes beyond just transfer of data to building effective, transparent relationships between vertical participants at every step of the chain.

HEALTH & WELLNESS

Ongoing digitization of records, increased cooperation, and an overflow of smart devices have generated an increased need for handling data. Yet, for the most part, it remains siloed, unshared, and out of the hands of consumers.

In the environment of increasing interconnectedness, digitization, and 360 ◦ view of the individual, businesses in the health and wellness industry remain disconnected – both from the customer and from the possibilities of working together.

Siloed data leads to extreme inefficiencies and heightened costs across healthcare, while also causing sport and fitness businesses to lose profit opportunities from co-branding and co-promotion.

Meanwhile, many traditional establishments are competing with digital alternatives. Gyms and fitness centres see attendances decline in favor of online fitness classes and tutorials. Mobile fitness apps often have more health data on the user than the nearby hospital or the insurance company insuring their health. The digital experience and digital convenience are credible threats to the old business models of health-related organizations, both reactive ones (like health providers and pharma) and proactive ones (like sports, fitness and nutrition).

The BGX NetworkBGX_BLUEPAPER_3.0 10 INTRODUCTION V 3.0 2019.01.09

Even companies that realize these threats have high entry barriers to digitizing and almost no method to integrate data or other parties into its business model. That is where the BGX Network comes in.

SOCIAL MEDIA

Despite the tremendous value of intertwining connections and information high- ways on social networks, there have been few solutions to add an economic layer on top of the myriads of social links. The major monetization options remain centralized in forms of data and ads, while the largest profit opportunities remain untapped.

Almost every successful social media platform features trillions of connections between millions of individuals and thousands of businesses.

These connections have changed the way data is monetized and evolved the ef- fectiveness of advertisement. They helped form trust networks between acquaintances that elevate the value of product reviews and recommendations. Endorsements by influencers and extremely targeted ad control have worked wonders for businesses and social media platforms.

However, this major flow of value and profit has been the result of only two types of connections: ads to platform and ads to the major platform participants. The myriads of connections between individuals and individuals and businesses have remained largely outside of social media purview. Meanwhile, the social structure that these platforms have is a significant advantage over e-retailers, “real world” sellers, and even financial institutions that process transactions.

If the pre-existing individual connections on a large social media platform would be combined with a transaction-processing layer, that would give access to potential earnings rising from the trillions of these social connections. This revenue flow would dwarf the top skimming layer of ad provider and data relationships.

If such a transaction network can process financial payments, then any social media that implements it would become the most powerful financial institution that exists to date. But if such a transaction network can also process content delivery and open doors to businesses, then the social media platform to implement it would become an integral and a large part of the world’s economy as a whole.

Social media platforms cannot develop such a network cheaply. However, applying a decentralized ledger level on top of the platform would enable it to earn from its millions of already decentralized users starting from within few weeks.

Moreover, the decentralized ledgers solve another problem. Trust and privacy, which has always been a point of pain for such networks and would become especially so, when social connections could evolve into economic ties. Managing information flow,

The BGX NetworkBGX_BLUEPAPER_3.0 11 INTRODUCTION V 3.0 2019.01.09 differential anonymity and privacy have always been some of the key advantages of blockchains and decentralized networks as a whole.

The past blockchains could not solve these problems. They were not scalable, could not support microtransactions, and processed nothing beyond currency. Integrating into them was difficult for both the businesses and the individuals; on the economic side, it required use of the volatile cryptocurrencies; on the technological side, it required months of integrative efforts.

FINANCE SECTOR Despite the hype, blockchain solutions have been largely unequipped to solve the problems of the finance sector. However, expensive chains of intermediaries, inefficient data control, and problems with trust and fraud have withered away much of the industry’s true profit potential. The financial sector is riddled with complications. Even basic credit card payments by a consumer at a retail store may be processed by up to five intermediaries, the inefficiencies of each adding to the total cost.

Cross-border payments are subject to significant red tape and complications.

Management of data has evolved into a burdensome task done with the help of enterprise-level software, which becomes obsolete by the point of implementation. Even with the help of an army of analysts and the heavy-duty software, many insights remain out of grasp and unavailable to optimize decisions at the time they’re made. This in its turn increases risk.

Fraud is rampant at every stage of the process and instituting controls to prevent it is both expensive and frequently ineffective.

Competition for business integration opportunities remains fierce, yet the process of acquiring business customers remains slow and tedious.

1.4.4 Content of the platform

The most recent release of the BGX Platform is the v 0.5 titled “KOWABUNGA!”, which features several key components:

• Unique F-BFT Consensus, which makes the network uniquely topological (supportive of real-life business relationships), secure, and both horizontally and vertically scalable. The Consensus has been praised in several research papers published on reputable academic resources.

• Alpha Release. A fully operational network with 10k tps / second, reloadable transactions (not just currency, but any digital good or data),

The BGX NetworkBGX_BLUEPAPER_3.0 12 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

graphic database architecture, innovative smart anchoring DEC tokens, two white-label mobile applications, a network dashboard for viewing transactions, integrative AIRBRIDGE API, and a virtual machine image for easy testing by businesses. To view the release: take a look at our DEMO. The next release will include an improved BGX Network composed of a greater number of nodes / business participants, AI ORACLES, white-label mobile applications, the F-BFT Consensus that runs the system, DAG ledger system, and an improved AIR- BRIDGE API. 1.5 Outlook on the blockchain market of 2019 2019. The Year. As the sector clears of opportunistic low-quality projects, institutional players and enterprise-level solutions will dominate the technology. “2018 ‘Cleared the Noise’, 2019 Will Be the Time for the Big Players” – PwC. Blockchain applicability. Integration becomes easier. Clearance & settlement, IOT and insurance lead the way in adopting enterprise-level systems, according to analysts. “Blockchain is one of the seven technologies insurers must master for digital transformation […or] new market entrants will do what Amazon has done to retail” – EY. Technology. 2019 will be revolutionary in UX and adoption support. Integrating decentralized solutions will get easier, enterprise-friendly, and multi-faceted. “It is incon- ceivable that [blockchain] remains desktop-first when clearly the most important computing devices are mobile. And this is clearly changing.” – Coinsquare Challenges. Blockchain technology is still maturing and implementation is slow. Some sectors, especially supply chain, are investing far less than expected. “By 2023, 90% of blockchain-based supply chain initiatives will suffer blockchain fatigue for lack of strong use cases.” – Gartner Outlook. As business-ready solutions offer greater usability and integration, higher institutional attention will give blockchain the necessary boost in 2019. “Blockchain is at an inflection point, with momentum shifting from “blockchain tourism” and exploration to the building of practical business applications” – Deloitte 2 TRANSACTIONAL SUB-SYSTEM 2.1 Transaction Process 2.1.1 BGX Platform as a Transaction System The main task of BGX is to ensure the transfer of information between business participants is processed in an effective, secure, low-cost and decentralized way. This information may be the transfer of monetary units (as a typical financial transaction), the corresponding delivery of a digital good or service (full e-commerce cycle), or just shared and analyzed data, enabling various participants to cooperate more closely.

The BGX NetworkBGX_BLUEPAPER_3.0 13 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

The transaction system of BGX has several key advantages: • Reloadable transactions. Transactions can take any form – be that transfer of numeric value (white-label currency), delivery of receipts, delivery of digital goods or services, whatever they may be, or transfer and receipt of data.

• Barrier-free. Financial transactions often go through several intermediaries. Some add costs, such as processing financial institutions, sender and received banks, differing currencies; while others add risks and borders – national policies, cross-industry divides, regulations. All of these are circum- vented on the BGX Network.

• Transparency and immutability. Transactions may be easily tracked and analyzed in the immutable DAG ledger, without sacrificing privacy. This simplifies internal auditing, alleviates legal risks, and avoids millions in expenses larges enterprises often undertake in clearing and reconciliation.

• Anchored processing. Even non-financial, non-IT organizations have an option to open a node and support the network by processing transactions. This opens possibilities of new revenue streams from commission.

Financial transactions on the platform are done by the white-label “BGT” Coins that may take any form, denomination and title that the ecosystem leader gives them. The total supply of these Coins is limited by the holdings of DEC tokens by the nodes, which cost fiat funds to acquire. This limitation and the bounds placed on the Coins to be only internal to the platform avoid hyperinflation that could have risen from oversupply or investor interest. The F-BFT Consensus ensures that each transaction goes through several rounds of validating and ensures security from the common attack vectors. BGX overcame several challenges when creating the platform: • A clear and compact economic model was developed, which would ensure both the financial health of the system, and the capability of all of its participants (nodes and BGX itself included) to earn;

• Implementation of a decentralized system, in which processing is performed not by a single node belonging to a single entity, but by a series of parallel servers that synchronize data by a certain algorithm (consensus);

• Construction of a truly interoperable architecture capable of carrying out payment operations both in crypto currency and in fiat funds, at the same

The BGX NetworkBGX_BLUEPAPER_3.0 14 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

time taking into account ecosystem boundaries and possible competition between these ecosystems or nodes within them;

• Ensuring compliance with regional legislative framework, including KYC (Know-Your-Customer), AML (Anti-Money-Laundering) procedures and the preservation of personal data;

• High transaction speed – starting from 10,000 tx / sec and infinitely scalable by both adding new nodes (horizontal) and adding processing power to the nodes (vertical). 2.1.2 Stable coin approach As previously described, the platform uses a binary tokenization in which DEC Tokens and BGT Coins are two parts of the monetary system and support each other. The table below describes the differences in the use of tokens.

Table 1 Token Properties # TERM DEC (anchoring token) BGT (transaction token) BGT (White label – can 1. Label DEC change its name) Defines the economy of the plat- Means of exchanging value form, works with investments, 2. Purpose between participants in the supports the stability of the work ecosystem of nodes Anchored platform. Currently Ethereum; could be changed to 3. Issue Platform any widely supported blockchain The BGX Platform or non-blockchain enterprise system. 109, at the same time, limited (is- Unlimited, is released as far as 4. Emission sued once, then limited to the provided by BGX amount issued) 5. Decimals3 18 18 ERC-777 (when tied to 6. Standard --- (custom algorithm) Ethereum) 7. Base Price 0.03 USD 0.01 USD – 0.1 USD 8. External Exchange Yes No Yes Yes – on BGX through DEC; 9. Internal Exchange on the Google Play and iOS platforms for fiat funds Yes, each node must have a re- 10. Reservation No serve for operations 11. Management BGX Wallet, Ethereum Wallet BGX Wallet

2.1.3 Life cycle of the transaction The “Transaction” is one of the central entities of the platform and is attached to the user and the corresponding processing nodes. Each registered user of the system has several attributes, some of which form his profile (user data, general information, etc.) – while others are responsible for the identification and financial information of the user.

3 Integer mathematics is used – up to 10-18

The BGX NetworkBGX_BLUEPAPER_3.0 15 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

The user’s account has a special value, representing his financial status in the context of certain types of settlements. The user’s transactions may be tracked by address in the BGX Dashboard, as is done with popular blockchains, and similarly to them – the user’s identification remains hidden, with only the address being publicly associated with each transaction and balance. For further description, it is necessary to distinguish only three of the user’s account data items: • Account ID – public key (address) referred to in the course of financial transactions; • Balance – integer4, representing the currency available in the user's account (including DEC, or any of the white-labeled BGT Coins) • Account Type – type of account, characterizing the account currency and its capabilities (DEC by default). The main task of any processing platform, including BGX, is the provision of transactions for the user and external agents of the system. When a transaction is made, Party 1 gives the command to transfer information (funds, data, digital goods) from their account to another party’s given address. If the transaction is successful, the result could include: • Receipt for the transaction and transfer of data; • Change in account balances in the corresponding currency of the transaction; • Receipt of data and digital good and / or service. Simplifying, a transaction can be represented as a set of the following attributes: • Transaction ID – the number that characterizes a unique transaction in the BGX system; • Source Account - the account that initialized the transaction (sender's account); • OPS - a list of transactions within a transaction (one or more), for example, an operation to transfer funds to another account. Each operation has its own set of attributes; • FEE - commission for a transaction that ensures its completion (it is paid by the initiator-sender). All transactions are ultimately stored in a single registry - LEDGER, representing another entity of the transactional subsystem. LEDGER represents the state of the BGX system at any given time, including the recording of all transactions and the status of all accounts of the system. Simplified, LEDGER can be understood as a special data structure corresponding to a large sparse table.

4 An integer of a sufficiently high bit is used, corresponding to the bit width of the DEC Token.

The BGX NetworkBGX_BLUEPAPER_3.0 16 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

In case the transaction is successful, it is recorded in the LEDGER, if it is rejected (for example, there are not enough funds in the account), it remains only in a special journal. In this case, each transaction must be signed (authorized) by the user who initiated it. Total transaction life cycle:

Figure 1 Transaction Lifecycle

• USER INITIATION – actions on the side of the client’s application, when the user decided to commit a transaction; • CREATION – formation of a transaction record and preparation for its transfer to the system; • VERIFICATION – verification of the correctness of the transaction formation (the presence of the filled mandatory attributes, validity of addresses and signatures). In this step, the transaction can be rejected; • SUBMISSION – transfer of the record to the server part of the system; • PROPAGATION – distribution of the transaction throughout the system (for example, for all nodes in the case of BGX); • RESOLUTION – the resolution of contradictions in the system (in the event that several identical transactions are coming - the choice of the only correct transaction for the system); • APPLICATION – application of the transaction - change of account balances; • SAVE IN LEDGER - record of the current state. Note that the transaction process is similar to any type of transaction and any type of user – corporate or individual. However, if the transaction includes goods and services that were paid for and sent through a link, the link itself will not be available for download from the public ledger, except by the user who made the payment.

The BGX NetworkBGX_BLUEPAPER_3.0 17 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

The described chain of actions does not have any unique features and is applicable even in the case of centralized systems, for example, in a banking environment. How- ever, in the case of a distributed system, the problem arises of synchronizing the state of all nodes, finding a consensus between them. 2.2 Prerequisites for the formation of a consensus protocol 2.2.1 Bitcoin Blockchain and its mechanisms for protection Working with distributed sources has a long history. Even before the arrival of crypto currency, the basics of replicating distributed databases and network file systems were formulated. Since the beginning of 2009, the world has been presented with the first crypto currency - Bitcoin, the most successful part of its implementation, according to general opinion, was the use of the protocol blockchain. Blockchain - the structure and protocol of data storage implemented as a linked list of blocks, each of which has a hash of information stored inside it, a current and a link to the hash of the previous block. This circumstance makes it impossible to change the already formed block without changing the entire chain, built from the very first block, called genesis. This storage structure has a number of advantages when storing information in an environment without trust. A number of other possibilities aimed at maintaining the structure itself and its performance supplemented the idea of Bitcoin, in addition to the structure of the blockchain, by a number of cryptographic functions. In essence, this system stores a flow of transactions within itself, in the course of which, an additional currency (bitcoin) is issued in favor of a network of enthusiasts - miners. Information is stored as a blockchain, each block contains transactions, each block header contains hashes 5 each of the transactions, as well as the header hash of the previous block. As a result, an un-modifiable chain of blocks is formed, allowing you to see all transactions while maintaining the anonymity of those who are behind these translations. Each bitcoin network node is deployed by the corresponding user-miner on its computer (hardware) and contains a complete copy of the entire blockchain. Miners, named by analogy with the extraction of minerals ("mine" bitcoins), work with nodes to include transactions in the new block. Such work obeys certain rules and requires a large amount of computational work done by the miner: the calculation of a hash of a special kind, which requires a search of a large number of variants in the calculation of all hashes. The reward for packing the unit was received by the one who formed it first in the form of new bitcoins. Such a system leads to competition between different miners for the right to form a block and get bitcoins, and simultaneously to the high stability of the process of

5 A special irreversible function that computes a certain key of limited size on the basis of elliptic functions, uniquely representing the initial data.

The BGX NetworkBGX_BLUEPAPER_3.0 18 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09 generating transactions, the appearance of a method for decentralized processing of transactions, the exchange of data between nodes (consensus nodes), and resistance to attempts to substitute information. The way to achieve consensus through computing is called Proof-of-Work (PoW). Thanks to PoW Bitcoin is able to function on millions of computers, but has a number of drawbacks: it leads to a significant slowdown in synchronization operations (more than 10 minutes per block formation), and is accompanied by a useless energy waste. 2.2.2 The Byzantine Generals Problem In 1982, a group of scientists (Leslie Lamport, Marshall Pease, Robert Shostak) published a document, which describes the reliability problem in a decentralized system. In the "Problem of the Byzantine Generals" the authors proposed a thought experiment: "Imagine that a group of generals, each commanding part of the Byzantine army, sur- rounds the enemy city. Generals can communicate only as messengers, but in order to conquer the city, they must agree on a bit-you plan. The problem is that one or more generals can be a traitor, who tries to distort messages and sabotage the plan. The question is, how many treacherous generals can be in the army, so that it can still act as a single force? The proposed solution proved that the system (the Byzantine army) can remain reliable if it is certain that 2/3 or more generals remain reliable. The task can be transferred to nodes in a distributed system, however, everything is much more complicated here, for a long time the task seemed unsolvable. The solution appeared in 1999, when Miguel Castro and Barbara Liskov introduced a practical algorithm of Byzantine fault tolerance (PBFT). PBFT can handle a huge number of direct peer-to-peer (or distributed) messages with minimal latency. This means that programmers can create secure and fault-tolerant private distributed networks. Since 1999, PBFT has been implemented in various ways, and it has been refined in several technological approximations. The previously mentioned Proof-of-Work method is a re- finement of PBFT - to check the transactions of other participants of the system, users must repeatedly run the corresponding algorithms. 2.2.3 Implementation of the consensus mechanism The founder of Ethereum, Vitalik Buterin, posed a special clarification 6 of the terms “decentralized” and “distributed” systems. For this, three dimensions were introduced • Architectural (de)centralization – number of computers the system consists of, how many of these computers can fail simultaneously, while the system continues to work • Political (de)centralization – How many individuals or organizations ultimately control the computers, of which the system consists

6 The Meaning of Decentralization, Medium

The BGX NetworkBGX_BLUEPAPER_3.0 19 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

• Logic (de)centralization – do the interface and data structures look more like a monolithic object or as an amorphous group of objects? This is a simple heuristic: if the system can be cut in half, including providers and users, will the both halves continue to work as independent units. Answering these questions, the system can be built up as decentralized and distributed to some extent. At the same time, its architecture and topology will be different from the point of view of the decisions made regarding the number of nodes, the order of the decisions made, the tasks to be solved, load profiles. According to the well-known DCS theorem, decentralization, consensus and scalability form a triangle that limits the chosen solution: the more complex a consensus is and the more decen- Figure 2 DCS Theorem tralization, the more difficult it is to achieve the required performance of a distributed system

The implementation of the synchronization mechanism between nodes in a distributed system (consensus mechanism) in a more general approach is determined by the following parameters 7: • Decentralized governance: a single central authority cannot provide the completion of the transaction. • Quorum structure: The nodes exchange messages in predetermination (paths that can include stages or levels). • Authentication: this process provides means for verification of the identity of participants • Integrity: it provides a check on the integrity of the transaction (for example, mathematically using cryptography). • Non-repudiation: provides means for verification of whether the alleged sender has really sent the message. • Privacy: this helps to ensure that only the intended recipient can read the message • Fault tolerance: the network works efficiently and quickly, even if some of nodes or servers are not working or are working slowly. • Performance: takes into account bandwidth, persistence, scalability and latency Whichever type of parameters is used, it is necessary to take into account their mutual influence on each other, as well as the correspondence of the existing algorithm of the domain.

7 Consensus: Immutable agreement for the Internet of Value, KPMG, 2016

The BGX NetworkBGX_BLUEPAPER_3.0 20 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

2.2.4 Scalability attempts The problem of scaling, and productivity in the narrow sense, the speed of processing transactions is one of the sharpest and hinders the practical application (see 1.3 Blockchain 3.0) of distributed solutions, especially in those areas where higher transaction processing speed (BGX focus) is required. The problem of performance is directly derived from the architecture of the classic blockchain. Indeed, despite the significant advantages of blockchain architecture, such as fault tolerance, strong security assurance, political neutrality and authentication, this is achieved through scalability. A solution in which each node should be ready to process any transaction becomes weaker with the growth of nodes and the number of processed transactions due to the delay in exchange between nodes. At the same time, the mechanism for achieving consensus is the most vulnerable link, the critical path in the distributed system performance model. The solution to this problem can lie both in additions to the existing architecture, and a more radical change in the very principle of the algorithm due to all the compromises in terms of decentralization or the complexity of the mechanism. The most common ways to solve the problem: • Optimization of data structure, as a result - a decrease in the volume of processed and transmitted data. SegWit, which optimizes the data storage structure in the Bitcoin and some other currencies (Litecoin, Vertcoin), is on this path, in particular; • Optimization of block size – for example, increasing the block size in Bitcoin to 2 MB - increasing the block size will raise the processing speed of transactions, as more transactions will be included at a time; • Off-chain state channels – the formation of secure computing outside the blockchain network with subsequent saving of results to the network. In fact, it works in three stages: a. Fixing the state through some mechanism (for example, a smart contract and a multi-caption), b. Data exchange between the two participants in the attraction of the network, c. Granting the state back to the blockchain network, closing the channel and unlocking the state. The implementations of this method are the Lightning Network and Raiden; • Sharding8 – segmentation of the processing, similar to how the process of how the distributed data is distributed. Transactions are clustered by different shards and, depending on the cluster, are routed to a different server. This approach has found application, in particular, with federative consensus. However, in general, this approach is not applicable to all applied tasks; • Plasma9 - an approach in which payment channels are created through built-in smart contracts (sidechains). Although the approach seems to be

8 How to Scale Ethereum: Sharding Explained 9 https://plasma.io/

The BGX NetworkBGX_BLUEPAPER_3.0 21 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

similar to Off-chain state channels, its fundamental difference is in using built-in mechanism mechanisms. In the Plasma project implemented over Ethereum, the Proof of Fraud mechanism is built-the logic of smart contracts, which allows in the event of an attack to quickly withdraw funds from the side-chain to the main block, protected by a full-fledged mining; • Off-chain computation – Another approach that takes the calculation of transactions outside the core network. An example of such a solution is the network TrueBit. Using additional nodes, Solvers processes smart contracts outside the main network, a deposit is credited to Solver's account. In the case of a successful resolution, the Solver is rewarded. Otherwise, the deposit is withdrawn, and the conflict is resolved in the main network at the expense of mining, the so-called Verification Games; • Changing Consensus Algorithm - within the framework of this approach, the very architecture of data synchronization between nodes is changing. Recently, new models have been widely spread, substantially raising the speed of data processing. 2.2.5 Consensus models in distributed systems Data storage in a distributed environment and related technologies are closely related to the concept of DLT – DISTRIBUTED LEDGER TECHNOLOGY, system of an agreed set of data, divided into several (or many) nodes. The most common use is the storage of information about transactions, although this technology has been successfully applied to other types of information. The main task is to build a consensus that ensures reliable storage of a single transaction (without its duplicates), recognized by all (most) nodes as true, and, therefore, recognition of its value. To date, there are many other methods of consensus building outlined in the APPENDIX 1: CONSENSUS TYPES. After Bitcoin, other developers focused on finding alternatives to a classic PoW. Bitcoin has proved the practical applicability of the blockbuster model built on these principles, withstood many attacks and demonstrated considerable resilience. However, in addition to the inevitable impact on scalability, the PoW consensus mechanism has other limitations: it is quite energy-intensive and requires a significant pool of supporting miners. The methods of protocol acceleration listed in 3.2.4 Scalability attempts do not suit all tasks, and in this connection a number of other promising developments have appeared. Main groups of consensus groups 10: • Proof-of-Work (PoW). Advantages - reliability, sustainability and decentralization. Disadvantage: a poor performance. Implementation: Bitcoin, Ethereum, Litecoin, Dogecoin; • Proof-of-Stake (PoS) - The advantage is energy saving and the possibility of acceleration, disadvantage - high risks of branching. Implementation: Dash, Ethereum (project), Wave, Wainchain;

10 SoK: Consensus in the Age of Blockchains

The BGX NetworkBGX_BLUEPAPER_3.0 22 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

• Delegated Proof-of-Stake (DPoS) – is different from PoS by the choice of validators. The downside is the partial centralization of the Implementation: Steemit, EOS, BitShares; • Proof-of-Weight (PoWeight) - the best way to store information (the more difficult, the better). Implementation: Algorand, Filecoin, Chia; • Byzantine Fault Tolerance (BFT) - includes the subgroups PBFT (Practical Byzantine Fault Tolerance) and FBA (Federated Byzantine Agreement). Im- plementation: Hyperledger, Stellar, Dispatch, and Ripple. The downside is the fact that it is semi-trusted; • Directed Acyclic Graphs (DAGs) - storage of data not in blocks, but in nodes of the directed graph. Implementation: Iota, Hashgraph, Raiblocks / Nano

The most promising solutions are given below.

Table 2 Consensus Implementation # Implementation Key Features Realization 1 Ripple consensus The participants themselves, not technology, determine Ripple, 2012 ledger11 integrity. Ripple sends messages with open peer-to-peer This approach led to the broadcasts. In a larger network, there are subnets of col- fact that transactions can lective trust approaches called unique node lists (UNLs), be performed in seconds, so the system is a kind of federation. The Ripple consen- rather than 10 minutes or sus mechanism requires that 80% of the authorized more, required in health nodes (supermajority of nodes) on the UNL subnet (and testing systems. not in a larger system) agree to confirm the transaction The protocol was the im- petus for the development of the protocol Inter Ledger 2 Stellar consensus It is based on the so-called federated Byzantine agree- Stellar 2014 protocol (SCP)12 ment (FBA), which uses "quorum slices": each node Stellar is LDT, SCP does chooses which other nodes to trust. The sum of all these not require large pro- individual elections is a quorum of consensus at the sys- cessing power, the maxi- tem level. In the FBA, each participant knows about oth- mum transaction band- ers that he considers important. In the end, a sufficient width is 1000 tps, the av- network accepts a transaction that the transaction is set- erage confirmation time tled for a Stellar network transaction is 5 seconds 3 Corda13 Consensus is achieved at the transaction level, verifica- R3 CEV LLC, a consor- tion affects both validity and uniqueness - it requires that tium of several leading fi- the transaction be the consumer of all its input states (in- nancial and technology put states). Corda is positioned as a distributed registry, companies, including developed for financial services and is a private ledger. Credit Suisse, Goldman Smart contracts - Java, Kotlin Sachs, J.P. Morgan & Co, UniCredit and the like 4 RAFT14 It was developed on the basis of the older Paxos protocol HydraBase – Facebook, in 2014. The task of achieving consensus is related to the InfluixDB management of a cluster of computing systems with a di- vision into subtasks - the choice of the leader (voting), the replication of protocols.

11 The XRP Ledger Consensus Process 12 The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus 13 Corda: An Introduction 14 The Raft Consensus Algorithm

The BGX NetworkBGX_BLUEPAPER_3.0 23 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

# Implementation Key Features Realization 5 Tangaroa15 / Scala- Byzantine Fault Tolerant variant of the Raft, closed con- Juno/Kadenа, Private bleBFT sensus mechanism, focused on private blockers. De- Blockchain, 2016 clared performance ratio> 7000 tps 6 Sieve16 The SIEVE consensus protocol is designed to handle the The protocol is used, in nondeterminism of the network code. It can create differ- particular, in Hyperledger ent output data when performing different replicas in a dis- Blockchain Fabric 17, for tributed network. SIEVE processes transactions specula- overloading and the use tively, and then compares the results by replicas. If the of various consensus pro- protocol detects a minor divergence among a small num- tocols ber of copies, divergent values are sifted. If the discrep- ancy occurs over several processes, then the transaction is rejected 7 Ethereum Casper18 The Casper protocol is implemented as a specific PoS The introduction of the hy- protocol, aimed at accelerating Ethereum. The protocol brid method in Ethereum introduces special nodes - validators, which put their share on the airs for approved transactions, however, if the transaction, to which they have failed, then the entire share is withdrawn. 8 Tendermint19 The PBFT option (Bracha's Byzantine reliable broad- Cosmos Network, is posi- cast). Unlike the classic PBFT, where the client sends a tioned as network of new transaction directly to all nodes, the client in Ten-der- Blockchains mint transfers their transactions via the Gosip protocol. 9 Proof of Elapsed PoET is designed to be used on a certain type of com- Part of the project Intel Time puter with the so-called Trusted Execution Environments Sawtooth Lake (TEE). The protocol uses the SGX trusted calculation module 10 Quorum20 The protocol uses a smart contract to test the blocks. The Cakeshop trust model defines a set of n nodes of "voters" and a certain number of "block maker" nodes whose identities are known to all nodes. Implemented on top of peer 11 The Tangle21 The Internet of Things protocol is implemented on top of IOTA the DAG - directed acyclic graph, in IOTA each user is a miner, to confirm the transfer of two available ones. Al- lows the use of instant channels (Flash Channels) with high bandwidth, which are bi-directional and fuzzy. This allows the parties to make transactions at high speed, without waiting for a normal confirmation time. The current processing speed is 400 tps. 12 Hashgraph22 Implemented over DAG (does not have blocks and does Hedera Hashgraph not contain corresponding restrictions), using GOSSIP (Gossip about Gossip) protocol, divided into 3 rounds - connection (2/3 aggregate nodes), voting, collection of consensus. It is characterized by high speed and reliability. The method is patented.

15 Tangaroa: a Byzantine Fault Tolerant Raft 16 Non-Determinism in Byzantine Fault-Tolerant Replication 17 Architecture of the Hyperledger Blockchain Fabric 18 Casper the Friendly Finality Gadget 19 Tendermint: Consensus without Mining 20 Quorum Advanced Blockchain Technology 21 IOTA WP 22 THE SWIRLDS HASHGRAPH CONSENSUS ALGORITHM

The BGX NetworkBGX_BLUEPAPER_3.0 24 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

# Implementation Key Features Realization 13 Nano/RaiBlocks23 Achieves consensus through a weighted vote on conflict- RaiBlocks ing transactions. This consensus system provides faster and more deterministic transactions while maintaining a strong decentralized system, implemented on top of the DAG, transactions are processed without charges with PoS voting 14 Byteball24 Uses DAG to store transactions, if necessary, the Byteball Byteball.org transaction can be confirmed by a third party, has the option of private transactions (dark bytes) 2.2.6 Approach of BGX Processing 2.2.6.1 Main Concept The technologies mentioned above solve the problems of processing and consensus in different ways. Currently, the development of this area is growing rapidly, there is no single settled solution. From the point of view of BGX, the most serious problem is a significant increase in transaction speed and clearing. Receiving crypto currency even outside BGX can seriously slow down the turnover of funds (in practice it can take up to a week and cost up to 30% of the transaction. The p2p channels (discussed in 3.2.4 Scalability attempts), used for the acceleration of payment, seriously increase the speed of transactions, however, the basic principle of technology is violated - it is impossible to simultaneously change the state of the system in all its nodes. There are some discrete intervals in time, in which the system is not synchronized. Analysis shows that at the same time there are at least two possibilities for a significant breach of security – • Conducting transactions of third parties through already established chains of reliable users (and this is now up to 80% of all illegal actions with cryptocurrencies), • The ability to include third parties as an additional node of the Blockchain system with the participation of an unscrupulous partner of the debugged chain. It is clear that without solving security problems, it is impossible to talk about the practical use of these technologies, because even with the existing centralized clearing system, with strict control of operations on central servers, banks lose hundreds of millions of dollars in fraudulent transactions. Another problem that can significantly complicate the application of the technologies under consideration is the modernization of processor architectures used for mining and clearing. Due to the recently discovered vulnerabilities of standard servers to hacking heavy applications, the whole ecosystem of processors is being upgraded. This leads to the following problems:

23 RaiBlocks: A Feeless Distributed Cryptocurrency Network 24 Byteball: A Decentralized System for Storage and Transfer of Value

The BGX NetworkBGX_BLUEPAPER_3.0 25 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

• Many of the used applications stop working efficiently, which further exac- erbates performance problems; • Standard libraries used for optimization, because of the architecture pecu- liarities of new processors, stop working efficiently on certain transaction sizes or with certain correlations in the data. All this requires a very high qualification of the user when drafting the program, which negates the very idea of libraries. It seems to us that solving these problems requires an integrated approach to technology, based on the creation of hybrid systems with several mechanisms to ensure an acceptable transaction speed and a specified level of security, based on a rigorous mathematical model. In order to solve this, the following concept is suggested: • At the node level - use several virtual servers that make up the site complex (a.k.a. virtual supercomputers); • Construction of topological structure of nodes, when the transaction processing logic itself is implemented in a certain cluster and only then spreads to the entire network (similar to FBA Stellar); • As a basic layer for storing information, use of the advantages of DAG structures that do not require mining and block building; • Separation of processing into internal BGT tokens and external, carried out in the parent network (Ethereum) and through the payment gateways

2.2.6.2 Node System Level The paradigm of the "Virtual supercomputer"25 is based on the ideas of Apache Spark and is being developed for 10 years to accelerate the calculations on hybrid systems, provides a reliable technology platform for solving the problems of efficient acceleration of computations. The idea is not only to virtualize all the main components of the system, but also to create a mandatory entry point - the API for each node. This allows, on the one hand, to manage the entire virtual ecosystem, and, on the other hand, to ensure reliable isolation of transactions within the selected set of nodes, without allowing third-party users there. The use of virtual processors instead of real ones is a key element in the acceleration of distributed systems, since different nodes of the distributed system use different processors, and load balancing of different processors in a distributed system is very complicated. Moreover, in modern computing systems based on GPGPU, it is virtualization that is the only way to effectively use a large number of cores. Network virtualization is a necessary element for creating secure connections, and VPN technology is an indispensable element in the organization of user access to

25 Constructing Virtual Private Supercomputer

The BGX NetworkBGX_BLUEPAPER_3.0 26 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09 confidential data. But it's important to go further and use network virtualization to create a completely isolated node system that must ensure transaction security and reduce the time of data pairing on nodes, which is key to accelerating transactions. In all modern data processing systems, the presence of a distributed file system is a necessary element for real-time data processing. However, as soon as it comes to working with data at different nodes, standard tools dramatically slow down their performance, to the extent that data loss is sometimes possible. Therefore, the most important step in our approach is the creation of a virtual shared memory based on a virtual network of transaction nodes. This step slows down the exchange rate within the physical memory of the hyperlink, but significantly increases the exchange rates between remote nodes. After that, we can already build a distributed virtual file system with the usual means, but on a virtual shared memory. This circumstance makes all nodes in the chain equal in rights and substantially simplifies the interface of data on the nodes. To provide access to the virtual distributed system thus obtained, a user interface (API) is provided. It has two functions. One is the configuration of a distributed system under a given chain of transactions. The second is to create a closed data transfer environment, in which only legal representatives of the chain participate.

2.2.6.3 BGX Network Topology The protocol regulates the processing of network users' payments (the purchase of BGT Coins) in IAP, the exchange of BGT Coins to freely convertible DEC Tokens, the synchronization of data within the network between separate structural units of the network, the distribution of content (all these processes are combined below into processing). Topologically, the network consists of components: • NODE - the active unit that supports the BGX network, includes one or more virtual servers, depending on the host profile. The following functional groups serve as profiles: verification of financial transactions, authorization of users, support of the content storage system, support of application APIs. Depending on the configuration of the network, it is possible to combine profiles or separate them (only some profiles can function). A set of active profiles on a dedicated server is called a role; • OPERATORS - individuals or organizations that control the operation of nodes that set up servers and receive remuneration for their work; • CLIENTS - program modules (terminal applications, including mobile applications and web clients) interacting with the network through the API; • USERS - end users of the network: consumers of content and services, third parties (external systems).

The BGX NetworkBGX_BLUEPAPER_3.0 27 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

Figure 3 Nodes, Operators, Clients and Users All information on the network, with the exception of the user profile, which can be stored in local nodes, is global and is distributed throughout the network. However, the process of operational processing is performed in separate clusters, groups of nodes, topologically related to each other. The nodes for processing are registered on the network and receive the HASH identifying node processing. By verifying the transaction, the node signs it, which in turn makes it possible to match the received transaction and the node. The nodes are registered in the network in a certain order, forming an ordered structure of the merkle-DAG type. Nodes that have direct connections (parents and leaves) constitute a special group - a cluster. The cluster distributes processing operations amongst itself and has the ability to delegate operations from node to node. Figure 4 The merkleDAG of Nodes The client application interacts with the entire network through a dedicated cluster, getting a list of servers of its cluster, and also for stability – the neighboring ones

When connected to a network, the client selects from a given list a random address (and in case of unavailability, the next one is selected). At a given interval, the list of such servers is updated. To prevent double-spending attacks (see below), the cluster keeps a version of all the balances for each account. If no nodes of the processing cluster are available, the account is transferred to another cluster from the recalculation of all balances.

The BGX NetworkBGX_BLUEPAPER_3.0 28 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

2.3 BGX Payment Protocol 2.3.1 Internal and External Processing Since BGX uses a double token system, transactions can be divided into the following groups: • The DEC token operations: receiving of tokens, their exchange for crypto currency or fiat funds. Processing is performed on Ethereum and requires the deduction of commissions of the respective networks. Payment by fiat funds or third-party crypto-currencies is carried out through special listen- ers of third-party networks. Each node has its own address, compatible with ERC20 tokens, allowing to process BGX; • Exchange of BGX to BGT or other internal tokens is done using the course setup mechanism. When BGX exchange rate is changed, the exchange rate calculation is carried out by the head node of the network and distributed along all clusters; • Direct purchase of BGT for crypto currency or fiat funds is carried out using payment gateways. The resulting currency is spent on buying BGX to ex- pand the processing volume of each of the nodes. 2.3.2 Transaction Structure Each user and operator has an account on the network that itself presents a set of ID (unique), a user profile (extension ID, may be absent), one or more addresses, a set of operations supported by this account, as well as individual scoring that characterizes the account's reputation (calculated using MLA - Machine Learning Algorithm). Each address is represented by a unique pair of keys, one of which is private, and the other is public. The private key serves to access the address and manage its balance. The following attributes are also attached to the address: • Balance (the amount that is on the user’s account); • The currency in which the balance is calculated; • Transaction history by address. Interaction with users is reduced to the processing of transactions - atomic units used in processing. Transaction can consist of transferring funds from one account to another, as well as delivering content to the user's address. Ultimately, the user accesses his account through the Wallet view, either in a separate application, or indirectly through functions built into the end application. Each transaction contains the following information: • Title (includes timestamp, hash transactions and service information); • The address of the sender; • The address of the recipient; • The contents of the transaction (amount, currency, link to the content, links to related transactions);

The BGX NetworkBGX_BLUEPAPER_3.0 29 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

• Verification counter (signatures). 2.3.3 Hashing and Signing of Transaction A transaction created on the client side is used to create a package for processing, which is transferred to the BGX network. The transaction must be signed by forming a hash that is built using the hash function of creating a fixed-length hash package from the transaction, the packet is signed using the sender's private key and the ECDSA algorithm. The private key of the signer is linked to the public key according to the usual cryptographic rules, so that the verified signature can be checked by a third-party service. 2.3.4 Validation and verification of transactions Any generated transaction must be verified by the client, and then is sent to the system via an API located in one of the nodes providing it, and placed on the pending transaction verification stack. Validation of the transaction is reduced to verifying the completeness of filling the structure, as well as the formation of HASH of transaction. In the case of a successful connection, the transaction is forwarded to the unacknowledged operations queue on the dedicated server and distributed over the network in accordance with the algorithm described below. At the same time, user / address scoring is increased by 1, in case of deviation of the transaction scoring decreases. Verification is reduced to checking the validity of addresses (correctness of their existence and absence in the black list), the presence of the amount on the account and other conditions for the passage of the transaction. Verification is carried out in several rounds (three by default), during each round, the transaction must be checked at least 2/3 of the servers in the cluster of nodes (the number of checks may decrease based on user scoring, the higher the scoring, the faster the transaction is processed). To participate in the verification, the node must have some Reserve Found Deposit (RFD) in BGX, it is assumed that in the future the BGX main fund will be distributed in favor of the nodes. For the verification of the operation, a standard commission is charged (10%, the developer receives the remaining 90%). Of the collected commission, 60% remains a cluster and is distributed among the nodes that participated in the verification. 40% is assigned to developers (transferred to a non-profit development fund). 2.3.5 The Base Layer All successfully verified transactions are distributed to all nodes of the system in the form of Distributed Ledger, a single distributed database in the form of a directed list of acyclic graphs (DAGs).

The BGX NetworkBGX_BLUEPAPER_3.0 30 TRANSACTIONAL SUB-SYSTEM V 3.0 2019.01.09

DAG-based processing allows you to avoid using blocks to record transactions and overcome the scale limitations inherent in public blockchain systems. In DAG networks, increasing the number of nodes has a beneficial effect on overall performance. Since the graph is directed, its edges go in only one route. DAG uses sorting in a certain order. Tech- nologies based on DAG are aimed at limiting the width of the graph. Such algorithms help to avoid problems Figure 5 Directed Acyclic with the selection of old transactions in the chain as Graph parent transactions.

The formal processing of the insertion (approval) of a transaction taking into account the scoring is carried out as follows. Let G = (V, E) be the directed acyclic graph containing the transactions. Each of the transactions v ∈ V has a weight, measured by the weight function ω (v): V → N, defined by the sender of the transaction. Then the transaction is confirmed for L rounds at the maximum scoring d, if:

max( ∑ 휔(푣): ∀ 푝푎푡ℎ 퐴 푒푛푑푒푑 푎푡 푎 푎푛푑 ∀푣 ∈ 퐴) ≥ 퐿푑, 푤ℎ푒푟푒 퐿 ≥ 2 푣 This equation confirms that a higher valued transaction will be verified more quickly than less - the path of its insertion will be shorter than with a smaller scoring. The insertion algorithm for the most loaded path can be estimated by the linear time function O (| V (F) | + | E (F) |), where F ⊂ G is a directed acyclic subgraph 푣. In terms of the algorithm, a topological sorting F is done, for the topological sorting DAG 26 estimation 푠표푟푡 휏 is linear. 2.3.6 Algorithm protection 2.3.6.1 The Double-spend Attack Possibility The double-spend attack (DSA) is the starting point for considering the reliability of the algorithm. The following provisions of the algorithm prevent DSA: • Each cluster stores the version of calculated balances for each account; • Distributed Ledger is updated globally - within the entire BGX network; • Suspicious transactions are posted to a separate list using MLA; • New transactions are validated against the balance of accounts; • Verify the signature of all legitimate transactions;

26 Directed Graph

The BGX NetworkBGX_BLUEPAPER_3.0 31 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

2.3.6.2 Spam Attack Since the commission in the system is fixed, a potential attacker can send fast, small transactions, increasing the system load without experiencing consequences him- self. Since the system does not use PoW, this can lead to network overload and the failure of the cluster. To prevent mass mailing of messages: • the minimum transaction size is set (= 1 BGT); • when the maximum transaction package from one address is reached, a delay (pause) occurs.

2.3.6.3 Sybil Attack An attack on a node can potentially affect the operation of the entire network. To prevent it: • Nodes form a special topological order that prevents transaction verification by an arbitrary node; • During the verification process, each node re-signs the transaction; • During repeated rounds of verification, in addition to verification of transactions, there is also a verification of previous signatures;

2.3.6.4 Man-in-the-middle Attack • Interception of packets in open channels is excluded by encryption of traffic over SSL / TLS. • In addition, a special function is performed by the MLA / AI subsystem, by eliminating the atypical behavior of the user, based on the pattern of its behavior; • The use of separate identification servers (KYC / AML) further prevents the interception of information and its substitution, critical information is separated from the transactional subsystem. 3 ARTIFICIAL INTELLIGENCE 3.1 Machine Learning Approach The hype behind the blockchain industry was unfortunately accompanied by the army of dishonest users who are trying to exploit the system. Professional ecosystem participants may experience great losses, if not protected. The blockchain itself is well protected at the stage of passing the transaction, but the user's wallet, the terminal device, creates opportunities for the theft of money and information, and further effective concealment. The appearance of a large number of non- professional users is faced with the problem of the security of the end device. From our point of view, it is necessary to introduce intelligent systems that have the ability to adapt to changing conditions, provide the necessary level of protection for all legal participants of the platform while maintaining the convenience of its use.

The BGX NetworkBGX_BLUEPAPER_3.0 32 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

The best potential is in machine learning technology, which can flexibly adapt to existing threats. Systems based on Machine Learning (ML) technologies look for patterns in the behavior of users and identify customers who behave "unusually" and can be as- sessed suspicious in accordance with certain rules and empirical anomalies. Since no explicit statistical analysis can unambiguously determine whether a transaction is fraudulent, such systems at the output give the probability of fraud. For their functioning ML systems are trained - training, during which an array of input data is analyzed, usually large enough from the number of already accumulated data, after which a neural network or a similar mechanism is able to apply empirical rules for self-analysis of new data. The training process is divided into two types of "training": controlled and uncontrolled. Controlled machine learning involves choosing a random sample and manually classifying the transaction as either a fraudulent or not a fraudulent transaction. Records classified manually are used to create an algorithm for classifying new records as fraudulent or not fraudulent. Uncontrolled machine learning does not use manual identification as a starting point for the algorithm. Instead, volumetric metrics are introduced that allow us to evaluate the efficiency of the algorithm by indirect indications. In some cases, only one method is used, in others, their combination. For example, PayPal uses uncontrolled training to work with the history of buying individuals, defining templates and introducing new rules to prevent repeated violations. As a result, the level of fraud with PayPal earnings is 0.32 percent, which is much lower than the average for the financial translation industry - 1.47 percent. However, in absolute terms, the situation remains sad - PayPal handles roughly 27 $ 28B transactions per month. With a fraud rate of 0.32 percent, PayPal and its customers each month lose 89.6 million dollars for fraud. The LexisNexis study 28 shows that 79 percent of all losses from fraud are associated with Friendly Fraud (fraud by forgetfulness or negligence) and Chargeback Fraud 29. Such frauds can be monitored using LM, their early diagnosis can save 707,840 USD.

27 PayPal's total payment volume 28 True Cost of FraudSM Study, LexisNexis, 2016 29 See also: Friendly Fraud vs. Chargeback Fraud: Knowing the difference is paramount

The BGX NetworkBGX_BLUEPAPER_3.0 33 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

In addition, unlike deterministic models for blocking suspicious transactions, ML can significantly reduce costly false positives and manual verification time. For example, IBM's solution reduces such false alarms by analyzing the relationship between transactions that are supposedly intentional fraud and actual fraud. Such connections allow a 40% reduction in false alarms of the system.

Figure 6 IBM Fraud Detection Architecture A feature of the BGX platform is that a large number of participants makes it sen- sitive to attacks on the wallet, DDOs attacks, identity theft, trust degradation, fake user accounts, bots, etc. That is, threats are associated not only with payments, but with a common data infrastructure. Since the model of threats to the transactional system is dynamic, an effective method of calculating transaction risks in real time and building clusters on large data sets is needed, allowing you to select absolutely confident transactions, suspicious (or simply erroneous) transactions and transactions that are rejected as fraudulent. To select such clusters, you need to search for implicit templates that group transactions by some similarity. This task belongs to the group of soft computing techniques, which includes Artificial Neural Networks (ANN) and Fuzzy Systems (FS). Each of the ANN and Fuzzy techniques has its own advantages. In the first case, the overall dynamics of the system is higher, but its control and analysis is more difficult, in the second the more rigid model of rules requires considerable attention of the supporting staff. Given the distributed nature of transactions and the need to integrate the mechanism into a decentralized system, it seems optimal to use a hybrid version - the Fuzzy Neural Net- work.

3.2 BGX Fraud Detection Math Model 3.2.1 Model Inception In accordance with the transactional model, each user has one or several accounts with a fixed address in the system from which he sends transactions to the system. The user's behavior thus generates a stream of events to which parameters such as IP address, georeferencing, the sent amount, binding to the node from which the transaction "enters" the BGX network, and so on. In fact, the task is to construct a dynamic model for the behavior of a particular (dedicated) user and to identify deviations from this behavior.

The BGX NetworkBGX_BLUEPAPER_3.0 34 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

And also, the resulting permissibility of the transaction or its deviation. The proposed model is based on the combination of ANN type ADALINE and FUZZY Logic30. From the point of view of deterministic logic, a transaction is either legal or fraudulent. The application of fuzzy logic leads to some probabilities of assigning a transaction to a particular class and requires a specific mathematical base31.

Login is a transaction τ(Xn), defining a set of parameters Xn ={x1, x2, …, xn}, (1) whose composition is variable and restricted with some m (n < m). The parameters accumulate in the system and ultimately determine the depth of the model - the volume of potential inspections. The system also contains a set of inspec- tion rules Ri , each of which can be described by a logical construction or a likelihood function. The rules transform the given parameters into the characteristic function μ (X) - membership function, which determines the occurrence of the transaction τ in a particular cluster (set) A and defined on the interval [0, 1]. This function is defined as

휇퐴(푥): 푋 → [0,1] ∀푥 ∈ 푋 (2) Rules can be mandatory and optional and defined at the stage of system normalization. For each rule, its weight - ωi is determined, the weight of the rule determines the degree of its importance for making a decision. The weight of a rule is defined on the set [0, 1], the set of rules is normalized:

푙 ∑푖=1 휔푖 = 1, (3) where 푙 defines the set of weights for all rules Wl

The logical process of building relationships between the source parameters and the final outputs is described by the Generalized Modus Ponens (GMP): • Fact x = A*32, • Implication33 IF (х = А) THEN (у = В), • Conclusion у = В*.

For the following, s-norm operator is also important. It implements the fuzzy set combining function (logical OR), which has commutative and associative properties:

30 Constructing a Mathematical Model of Fraud Detection System in Online Banking V. K. Ablekov*, A. A. Krasnopevtsev, and A. V. Mamaev 31 Masoumeh Zareapoor, Seeja.K.R, and M.Afshar.Alam, “Analysis of Credit Card Fraud Detection Techniques: based on Certain Design Criteria”, International Journal of Computer Applications (0975 – 8887) Volume 52– No.3, August 2012 32 A * means more than A, that is, fuzzy formulas (GMP) 33 A binary logical bunch, which, in its application, is close to the expression "if ..., then ...".

The BGX NetworkBGX_BLUEPAPER_3.0 35 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

푆(휇퐴(푥), 휇퐵(푥)) = 푆(휇퐵(푥), 휇퐴(푥)) (4) 푆(휇퐴(푥), 푆( 휇퐴(푥), 휇퐶(푥)) = 푆(푆(휇퐴(푥), 휇퐵(푥), 휇퐶(푥)))

Finally, if n fuzzy sets form an intersection, then their membership function is calculated using the harmonic mean: 휇 푛 (5) 퐴1 ∩… ∩ 퐴푛(푥)= 1 1 ,∀푥 ∈푋 +⋯+ 휇 휇 퐴1(푥) 퐴푛(푥)

3.2.2 Fuzzy Neural Network To build the model, a relatively simple ADALINE (Adaptive Linear Neuron) architecture is used, but the model can be generalized to more complex architectures. De-facto, network type ADALINE is an adaptive linear weighing adder with a delta output. The combination of a neural network and fuzzy logic makes it possible to combine learning opportunities with customizable

Figure 7 ADALAINE Structure decision rules.

The life cycle of the system consists of 6 stages:

1. Normalization of fuzzy set of input parameters; 2. Fuzzification, assessment of the degree of implementation of the rules; 3. Calculation of the contribution of the rule set; 4. Summation of contributions of fuzzy rules, decision-making; 5. Training of the neural network; 6. Self-organization and configuration of a fuzzy model.

Below are the listed stages, consecutively considered. 3.2.2.1 NORMALIZATION OF THE FUZZY SET OF INPUT PARAMETERS The problem of normalization reduces to determining the set of weights ωi. For their normalization, let us single out a set of mandatory rules Rr (6) 푅푟 = ⋃ 푅푖 , ∀푅푖: 푅푖 ∈ 푅푙 푖 ∈ 퐴

Then the weight function: 휔 ( ) 퐴푖 ( ) (7) 푔 푎푖 = → 푊푟 = 푔 푎푖 ∀푎푖: 푎푖 ∈ 퐴, 휔푎푖 ∈ 푊푙 ∑푗∈퐴 휔푗

3.2.2.2 FUZZIFICATION, ASESSMENT OF THE DEGREE OF RULES IMPLEMENTED At the stage of fuzzification, the degrees of belonging of the numerical values of the input parameters of the rule Ri to the input fuzzy sets:

The BGX NetworkBGX_BLUEPAPER_3.0 36 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

( ) 휇푅푖 푥 , ∀푥: 푥 ∈ 푃푅푖, где 푃푅푖 - set of rule parameters 푅푖 (8)

Applying GMP for each rule, we get the membership function: 휇 ∗(푥) 퐵푖 Having the logical rule IF (x = A) TO (y = B), apply Mamdani's implication operator 34:

휇푅(푥, 푦) = min(휇퐴(푥), 휇퐵(푦)) , 푅: 퐴 → 퐵 (9)

The surface of the membership function μ_R (x, y) is obtained from the cylindrical extensions of the sets A (x) and B (y) to the Cartesian product X ✕ Y. For a given input value, we can go over to the two-dimensional membership function of the implication μ_R (x ^ *, y ), which is a special section of the full three-dimensional μ_R (x, y). The projection of the function μ_R (x ^ *, y) onto the {μ, y} plane is the result of the derivation for the given rule and is denoted by μ_ (B ^ *) (x). In practice, the membership function 휇퐵∗(푦) can be defined without compu- ∗ ting a three-dimensional function 휇푅(푥 , 푦) ∗ due to equality 휇푅(푥 , 푦) = 휇퐵∗(푦), these functions can be obtained by truncating the membership 휇퐵(푦) up to the level ( ∗). 휇퐴 푥 Figure 8 Simplified Calculation

Thus, in stage 2, a modified membership function is generated as an output {휇 ∗(푦)} . 퐵푖 3.2.2.3 CALCULATION OF THE CONTRIBUTION OF EACH FUZZY RULE For each fuzzy rule from the set of rules, the contribution to the decision making ( ) is calculated on the basis of the function 휇푟푒푠푖 푥 using the formula: 휇 (푥) = 휔 휇 ∗(푥) (10) 푟푒푠푖 푖 퐵푖

Here 휔푖 ∈ 푊푟 is the normalized weight of the rule, determined at the stage of normalization. The adjustment of the set of weights of the rules W_i occurs at the stage of ( ) learning the neural network. At this stage, the final conclusion is {휇푟푒푠푖 푥 } 3.2.2.4 SUMMING OF CONTRIBUTIONS OF FUZZY RULES, DECISION-MAKING The contribution of a set of rules to the decision making is made by summing all the resulting membership functions: 푟 ( ) ( ) 푦 푛 = ∑ 휇푟푒푠푖 푥 (11) 푖=1

34 http://uni-obuda.hu/users/fuller.robert/nfs3.pdf

The BGX NetworkBGX_BLUEPAPER_3.0 37 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

We limit the output of the neural network to three clusters: Legitimate, Suspicious, Fraudulent. Then the decision-making푦∗(푛) is based on the decision-making function f(y): Legitimate, if b < 푦(n) ≤ 1 푦∗(푛) = 푓(푦) = { Suspicious, 𝑖푓 푎 < 푦(푛) ≤ 푏 (12) Fraudulent, 𝑖푓 0 ≤ 푦(푛) ≤ 푎 where a and b is the threshold for recognizing the transaction as fraudulent and suspicious, respectively.

3.2.2.5 NEUTRAL NETWORK TRAINING Typical training procedures are used to teach the neural network. Using the Least Mean Square method allows you to override the set of weights. To do this, the error value is added to the current weights and the necessary iterations are carried out. The error is calculated as the deviation of the solution from the reference signal d(n).

∗ 휔 (푛 + 1) = 휔 (푛) + 휇 ∗ (푥) ∙ (푑(푛) − 푦(푛)) (13) 푖 푖 퐵푖 If, for example, the reference signal is d (n) = 1, then it is necessary to normalize −1 the weight using the inverse mapping푔 : 푊푟 → 푊푙 :

∗ −1 휔푖 (푛 + 1) 휔푖(푛 + 1) = 푔 ⌊ 푟 ∗ ⌋ (14) ∑푖=1 휔푖 (푛 + 1) As a result, at this stage, we get an updated set of weights Wi, used in subsequent iterations. Finishing this stage, we get an updated set of weights Wl used in subsequent iterations. 3.2.2.6 SELF-ORGANIZATION AND CONFIGURATION OF THE FUZZY MODEL The iterative process is organized as follows. The first iteration is done with the membership function 휇퐴(푥) = 1 for all rules. Next, the membership functions μA(X) are recalculated for all Ri rules. The rule setting input is y (n) and the set of input variables { Xn } . Rules of adjusting the membership functions: A. Transaction is legal, every rule input parameter generates a fuzzy set of error Ej, given by an asymmetric exponential membership function by the formula:

푥 − 푚 푙 휇(푥) = 푦(푛) exp ⌊− | | ⌋ , ∀푥푗 ∈ 푋푛 휗훿휌 + (1 − 휗)훿푙 (15) 1 𝑖푓 푥 ≥ 푚, for 휗 = { 0, 𝑖푓 푥 < 푚

There are three variables controlling the yield of the reduced formula: • m (center). is given by the input variable;

The BGX NetworkBGX_BLUEPAPER_3.0 38 ARTIFICIAL INTELLIGENCE V 3.0 2019.01.09

• l (exponent, changing the form of the function). Allows you to configure each rule separately; • δ_ρ, δ_d (the distance from the center to the left and right branches, respectively). Allows you to configure each value separately.

The introduction of y (n) in the definition of the membership function will allow both training of the system and restoring in case the transaction was deemed fraudulent.

B. Suspicious or fraudulent transaction. The built-in error-membership functions in the first step are combined with each other, giving rise to a number of errors E. The combining takes place according to the Gamacher's s-norm operator with the parameter ϒ= -1

휇퐴(푥) + 휇퐵(푥) − (훾 − 1)휇퐴(푥)휇퐵(푥) 휇퐴 ∪퐵(푥, 훾) = (16) 1 + 훾휇퐴(푥)휇퐵(푥)

By virtue of the properties of the operator of the s-norm, the union occurs pairwise in an arbitrary sequence:

휇퐸(푥) = 휇퐸1∪…∪퐸푡 (푥) = 푆(… 푆(휇퐸1, 휇퐸2) … , 휇퐸푡 ) (17)

To find the membership function of the next iteration, we use the intersection operator of sets on the basis of the mean harmonic:

휇퐴(푥)휇퐸(푥) 휇(푛 + 1) = 휇퐴∩퐸(푥) = 2 (18) 휇퐴(푥) + 휇퐸(푥)

The final output of this stage is the membership set of functions функций 휇푅푖(n+1), which are used in subsequent iterations.

3.2.3 The Resume The general model is shown in the figure below. The above model shows good performance and the ability to proactively monitor threats. However, perhaps the most significant advantage of the provided system is the presence of weights that are replicated within the BGX network, which enable us to analyze the data for each user in a distributed environment and dynamically adjust the operation of the system.

The BGX NetworkBGX_BLUEPAPER_3.0 39 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 9 ADALINE MODEL WITH OUTPUT DELTA

4 PLATFORM ARCHITECTURE 4.1 Design Approach 4.1.1 Architecture as a Policy BGX is developing as open source software. This means that, it does not only provide a source code, but also it gives the ability to any developer or group of developers to join the encoding of the product and make changes to it. The peculiarity of such development is the problem of unaccounted interactions of some modules with others, interaction between teams and processes, and the policy of ensuring the quality of development. While centralized development follows the logic of the business processes of one organization, in the case of decentralized systems, the management of software architecture takes over the management role. The chapters above describe such important parts of the system as the consensus protocol, as well as the basic construction of the artificial intelligence system. These parts constitute the selected chapters of the architectural description of the system; this chapter describes a more general view of the system, which represents it as a set of related components and modules interacting with each other, as well as with the external environment. This description does not replace and is not equivalent to the Software Require- ment Specification (SRS) or the Software Architecture Document (SAD), but instead, this phase describes a common manifestation describing approaches to designing and implementing the platform. Software architecture is a very simple concept, intuitive to most developers without any special explanation. Over the past 30 years, a significant conceptual framework has been gathered on the principles and approaches of architectural design. There are doz- ens of architectural frameworks, a set of standard solutions for organizing code, data and common processes. Some of the most important are:

The BGX NetworkBGX_BLUEPAPER_3.0 40 PLATFORM ARCHITECTURE V 3.0 2019.01.09

• ISO / IEC 42010 - establishes a conceptual model for describing the architecture through viewpoints, notations, metamodels; • ISO / IEC / IEEE 15288: 2015 and ISO / IEC / IEEE 12207: 2017 describe the process of designing software systems based on the life cycle; • Attribute-Driven Design (ADD) - architecture design based on KPI; • Such architectural approaches as ZachmanFramework, DODAF, GERAM, Kruchten’s 4+1, TOGAF describe the construction of complex information systems for Enterprise solutions; • Concepts RM-ODP, IBMSOMA – describe the approaches to implementing distributed applications and service solutions; • ServiceOrientedArchitecture (SOA) Metaphors, Microservices, Web 2.0, CloudComputing - describe the direction of development of the concepts of designing modern dynamic systems. The concepts presented above contain useful fundamental concepts, however, the design of the BGX platform requires some additions that take into account the peculiari- ties of the crypto economy. Any software architecture describes only the reflection of the processes in which people are involved, in the center - the relationship between people. Therefore, the changes that occur should be reflected in the relevant decisions. Decentralized economy35requires a special approach in the design of systems and solutions. The basis is the economic and technological shifts caused by the loss of monopoly on access to information on the one hand, and on the other, the general shift of economic chains aside Information – Money– Information. This can be described as "decentralization 2.0’’36, when following "platform" solutions37, such as Airbnb and Uber, the following transformation is taking place - the P2P economy, eliminating intermediaries, including software solutions. Having the opportunity to conduct business in the virtual world, millions of new subjects entered the economy, "miners" in the broad sense of the word. Another new concept -InternetOfValue38, reflects the above formula Information- Money - Information. Its essence is the virtualization of the processes of exchange between economic participants, when the value of correct and accurate information begins to be commensurable with the value of certain objects of the virtual world. Moreover, material objects are converted into the transmitted information, just like the airplane tick- ets can be delivered directly to the user's smartphone and then associated with the flight, quite realistic. This way, the delivery of digital goods and services on the BGX platform is carried out not through a single entry point, but hundreds (thousands) of other participants

35 Hilarsky, Steemit,The Rise of Decentralized Economy 36Decentralization 2.0: Beyond the semi-monopolies of Uber and Airbnb 37Accenture, Platform Economy: Technology-driven business model innovation from the outside in 38Deloitte, The Internet of Value-Exchange

The BGX NetworkBGX_BLUEPAPER_3.0 41 PLATFORM ARCHITECTURE V 3.0 2019.01.09 competing with each other, saving on command and other corporate expenses, which inevitably leads to a decrease in the cost of such operations. Returning to architecture, it should be noted that specific software solutions reflect the economic interests of the participants, and if these interests differ from monopoly companies, then the software solutions should be different. To summarize, we can derive the main theses of the proposed concept: • The architectural strategy is derived from the business objectives of building the system, reflects the economic model and runs the red thread through the whole concept of the product, as a development policy; • The decentralized nature of the BGX platform requires the use of appropri- ate design patterns (see below) that support the model of independent system management by different participants; • Features of the ecosystem for which the system is projected dictates the working profile of the system (the number of participants, the nature of the interaction). On the basis of the profile, the attributes of the projected system (such as scale, performance, security) are selected; their target parameters determine the layout of the system and the interaction protocols. 4.1.2 Business Process Overview BGX Network is initiated by BGX Group, which at the initial stage retains its focus on the development of the platform and its promotion, carries out a coordinating action. However, as the platform develops, BGX Group's influence will decrease, and the Com- munity's influence will increase. A reference was already made to V. Buterin's article39, in which he explains the difference in terms of decentralization and distribution. The system can be decentralized and not distributed, and vice versa: everything depends on the rules of decision-making, as well as the tasks to be solved.

39Vitalik Buterin, The Meaning of Decentralization

The BGX NetworkBGX_BLUEPAPER_3.0 42 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 10 Different Network Topology BGX is built as a distributed and decentralized system. This means that the platform is built on nodes (each of which) is managed by one or more operators with different economic interests and competing with each other, and the data is distributed among these nodes. All development is conducted with open source, for the deployment of nodes there is no need to be authorized in some centralized organization. At the same time, the ideology of the system incorporates a system for protecting the interests of developers in the form of a percentage of the commission collected by the nodes. This allows us to identify the BGX hybrid organization occupying an intermediate position between the decentralized organization - the DAO and the Foundation. For the presentation of business processes that reflect the platform, you can use the operational framework formulated by W. Mougayar40:

40William Mougayar, An Operational Framework for Decentralized Autonomous Organizations

The BGX NetworkBGX_BLUEPAPER_3.0 43 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 11 Operational Framework

4.1.3 Reference architecture Designing decentralized and distributed applications has a long history. For a long time, the main focus was the construction of centralized, but distributed systems with parallel computations. In this direction, there are established patterns of design, formed standard expectations. We note some of the most significant projects: • ApacheSpark - an open-source software framework for distributed processing of unstructured and poorly structured data, which is part of the ecosystem of Hadoop projects; • MapReduce — it is a framework for computing some sets of distributed tasks using a large number of computers (called "nodes") that form a cluster; • Intel Parallel Studio - a package for the development of parallel software developed by Intel; • CUDA (Compute Unified Device Architecture) — hardware and software architecture of parallel computing, which allows to significantly increase the computing performance due to the use of Nvidia graphics processors; • OpenCL (Open Computing Language) — a framework for writing computer programs related to parallel computations on various graphic and central processors.

The BGX NetworkBGX_BLUEPAPER_3.0 44 PLATFORM ARCHITECTURE V 3.0 2019.01.09

All these projects were guided by managed systems, subordinated to the general organizational logic. For such systems, a mathematical base and a general ontology are well developed. Many of the created algorithms and approaches can be applied to manage decentralized applications. At the same time, the absence of "manual" manageability of decentralized applications raises specific problems of consensus and the formation of trusted calculations in a trustless environment. Solutions based on blockchain technology brought new technical features: • Immutable "public ledger" • Transparency and audit in relation to transactions; • High stability due to the storage system, at which each node stores a complete replica; • Distributed Consensus - Data Consolidation Manage- ment Mechanism without a dedicated central node • The use of protocols such as Gossip for data dissemination (protocol for propagation) and a separate Figure 12 Change Relation- protocol to achieve consistency of data - consensus) ship's Model

Suggested Satoshi Nakamoto algorithm for constructing a blockchain41combined various solutions into a single Bitcoin ecosystem and proved the practical possibility of using it. At the same time, Bitcoin's classic blockbuster was built for the modeling of a financial instrument (crypto currency), without binding to a certain domain area - a common use platform. Similarly, Ethereum brought the distributed computing infrastructure and reliable proving mechanism, but direct transfer of its solutions to practical problems is impossible. Practical implementations have a number of parameters that require a special approach: • What is the trade-off between Performance, Reliability and Scalability? The solution to this question is impossible without understanding the workload profile of the system (for example, the BGX platform is characterized by frequent, distributed micro-transactions and a relatively small number of supporting ecosystems); • How is coordination between independent nodes carried out? Many solutions, for example, a significant number of crypto-exchanges are essentially centralized organizations that support the overall ecology of blockchain solutions, but are managed by a specific organization in the interests of the shareholders of this organization. This is possible for private financial

41Often also called the Nakamoto Consensus, which is understood as PoW and related technologies.

The BGX NetworkBGX_BLUEPAPER_3.0 45 PLATFORM ARCHITECTURE V 3.0 2019.01.09

institutions, however, access to a large-scale market with a large number of types of participants is not possible with such a model - one cannot build the right motivational model for such type of solution; • What mechanism is used to process transactions, is mining necessary? In fact, for a large number of decisions, mining with its high energy costs and a decrease in network performance is not necessary. Such consensus mechanisms as Proof-of-Stake, Prof-of-Importance, FBA - cannot be built in isolation from the business model. For example, the implementation of Tangle in IOTA is focused on the Internet of Things and is not suitable for the digital content industry; • How are participants communicating? Bitcoin and Ethereum still have a limited number of API implementations, allowing final developers to focus on implementing high-level solutions. For BGX, the API opens significant pro- spects for the implementation of related solutions and common integration capabilities. According to current perception, ICSA specialists42in the architecture of the solution (see APPLICATION 3: BLOCKCHAIN DESIGN DESCISION), in practice, one should choose from multiparameter classes of decisions that take into account the cost of implementation, productivity and flexibility against parameters such as data structure, consensus protocol, tradeoff between security and scaling. The methodology of constructing a balanced architectural solution for decentralized systems is given in the frameworkк43by Chad Decker. According to the proposed approach, the development of the architecture of a decentralized system is defined as the set of decisions on the main parameters of the product:

Table 3 Blockchain Architecture Framework LEVEL CHAPTERS Architecture of inte- System manage- 3 Network architecture gration ment architecture 2 Committers Data architecture Consensus Business Architec- 1 Legacy Software Architecture Security architecture ture To summarize, we can suggest the following model of architecture: Virtualization. The use of nodes as a group of virtual servers, allowing to encap- sulate the heavy logic of data consolidation with respect to application interfaces; Decentralization. Data storage and processing should be decentralized and distributed, which ensures not only the necessary motivation of the ecosystem participants, but also the necessary scale of the platform.

42 Xiwei Xu, Ingo Weber, Mark Staple and others,A Taxonomy of Blockchain-Based Systems for Architecture Design, ICSA, Australia, 2017 43Blockchain Architectures and Disciplines for DLT

The BGX NetworkBGX_BLUEPAPER_3.0 46 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Incentivized. The presence of nodes in the support of processing should be supported by the Reward model in accordance with their contribution to supporting the infrastructure. At the same time, the number of these nodes must correspond to the equilib- rium between the proper level of scaling, the computational capabilities of the nodes, and the degradation of the platform due to forks; Hybrid Consensus. For the digital goods & services market, it is optimal to construct a hybrid consensus combining the possibilities of public blockchain (Ethereum) and built on a consortium-based mechanism. Such a mechanism makes it possible to use the Stable coin-approach in combination with the proof-of-concept PoW-launch BGT is limited to the amount of BGX funds that underlie each node; Reliability. The stability of the system must be ensured by centralization and the mechanism of rotation of nodes (their interchangeability). Open Source. The platform code, the decision-making system, the distribution of financial flows should be as open as possible in order to become attractive to enterprises and developers. Network of nodes: Blockchain is a network of computers. Each computer on the network that makes the processing power of the network is called a node. In fact, blockchain translates to a network that has super-computing power. Enhanced security. The security system is built on the basis of a risk model (attacks) that takes into account the security of terminal access (through the use of AI), as well as a reliable encryption algorithm for data using the public key method (public key - private key) Different Views. The projected system must support a presentation for design- time and real-time views (a.k.a Developers View).

The BGX NetworkBGX_BLUEPAPER_3.0 47 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 13 BGX Reference Architecture

4.1.4 Stakeholders Table 4 Main Stakeholders # Stakeholder Description Business node holders that open an ecosystem, surrounding themselves 1. Ec osystem Leaders with other businesses to share data or customers. Establish the currency used within the ecosystem. Businesses using the advantages of the BGX Network to operate stores of 2. Cl ient-Facing Businesses digital goods or services Businesses that operate nodes to earn commission from processing trans- 3. Tx Processing Businesses actions 4. Da ta Processing Businesses Businesses that use the BGX Network for their internal data clearing End users of digital goods or services, accessing the network primarily 5. Cu stomers through mobile applications Banks, other financial institutions, or public blockchains that anchor the 6. An chored Payment Networks main token, giving it value, and earning from being the economic backbone of the system Regional regulators in the international network. Regulations and law compliance is enabled through a special “license to operate” given to the nodes 7. Re gulators by ecosystem leaders for compliance with the KYC, AML, data and other rules. The company that built the BGX Network. Without controlling the network 8. BG X Technologies AG (decentralized structure), BGX earns from building auxiliary services to business consumers, selling DEC Tokens and data. Advertisers and similar entities who purchase data collected through the 9. Da ta Consumers platform to raise their business value. The developer community contributing to the open-source BGX project and 10. De veloper Community earning DEC tokens as a “developer bounty”. A community of influencers – leading economists, mathematicians, media, 11. Inf luencer Community and others that help improve and advance the BGX Network.

The BGX NetworkBGX_BLUEPAPER_3.0 48 PLATFORM ARCHITECTURE V 3.0 2019.01.09

4.1.5 Assumptions Table 5 Architecture’s Attributes # Attribute Value Description Mobile (Android, iOS) + Practically, 80% will fall on Android 1. Client Software web The platform consists of independent nodes that interact 2. Network Type Decentralized & Distributed with each other over TCP / IP The number of nodes will continuously increase in 5 3. Network Nodes Up to 10,000 years Transaction During the first period of the work of the platform, no 4. Up to 10,000 TPS Speeds more than 2K TPS are assumed Consortium (Modified F- The closest implementation is the Stellar Consensus 5. Consensus Type BFT – Federated Byzan- Protocol, the individual elements of the COTI (The Trust tine Fault Tolerance) Chain Consensus) Client -Server In- Mobile applications interact with the server through the 6. Rest API teraction Multiple Instance Rest API C++, JAVA, MEAN stack Hybrid implementation depending on the type of compo- 7. Technology Stack Apache Spark nent included in the platform After the initial release of the platform, the platform is High, modularity, micro- 8. Flexibility supposed to be developed by the distributed community service approach of developers A significant number of transactions require interaction 9. Interoperability High with external networks and payment systems (BTC, Pay- ment Gateway) The system must be resistant to the failure of individual 10. Availability 0.99999 nodes, including the initial BLOBs Architec- The data is stored using the IPFS architecture 11. IPFS ture 4.2 BGX Network 4.2.1 BGX Node BGX NODE (Substrate Node) - the universal building block of the BGX Network in transaction processing. Another important feature of the node is its autonomy in the decentralized structure of the BGX network. The deployment and operation of the BGX node is performed by the entity in certain economic interests - obtaining a significant portion of the commission. Between nodes, competition can and should be, supporting the consensus mechanism on the part of the network.

The BGX NetworkBGX_BLUEPAPER_3.0 49 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 14 BGX Node in general view The main features of the node architecture are as follows: • Each node consists of several virtual servers that perform a limited functional task: transaction verification, content delivery, user authorization. The boundaries of the node are considered to be the boundaries of the trusted environment, the internal network for servers is trusted and uses standard security procedures; • Each node potentially has a full set of virtual servers that perform a full set of BGX network functions. In practice, this is limited by a lack of consensus for transaction verification (several verification rounds performed by different nodes), as well as economic expediency. So some of the nodes - can provide external connection of clients (via API), others - carry out transactions (processing), others - work only on the delivery of content; • To work, the node must be registered on the network (to receive a parent node) and generate its hash, necessary for signing all critical operations. The communication channel with the parent node is called the Node Au- thorization-Channel and confirms all operations of the daughter nodes. Also, the dissemination of information (obtaining IP and hashes of nodes for the exchange of information is made on this channel); • Each node can have one or more daughter nodes, forming together with them a cluster - a single environment in which the transaction can be verified if there is a quorum (enough servers for carrying out the necessary number of rounds).

The BGX NetworkBGX_BLUEPAPER_3.0 50 PLATFORM ARCHITECTURE V 3.0 2019.01.09

4.2.2 Node Interactions The BGX network represents the basis of a platform that allows the performing of distributed processing, reaching of consensus (to coordinate data for a distributed network). The above mentioned is a consensus model, here are technical data on interaction of separate network entities. The overall organization of the network is determined by its functionality: • The main objective of the network is to support the processing of transactions in a distributed network. Transactions meaning exchange operation (value-to-value), including but not limited to the purchase of internal tokens, the delivery of content, the sale and exchange of in-app goods (IAP), the delivery and accounting of ad- vertising, the formation of prize funds, overdraft for users, etc. • The network is supported by nodes - full-featured BGX infrastructure objects, each of which is equipped with full functionality and is able to implement the functionality of the entire platform independently (depending on the configuration); • Each node consists of several virtual servers that provide the necessary functionality (in accordance with the concept) of the "virtual supercomputer"); • Nodes interact with each other and with the outside world using messages that make up transactions and service messages; • Nodes support the transfer of funds from site to site using distributed reserve funds in BGX ERC20 tokens tied to the Ethereum network; • For interaction with external cryptosystems (Bitcoin, Ripple) and payment systems, special Implant systems (a.k.a Payment Gateways) are used; • Nodes are relatively independent, however, organized into a MerkleDAG structure that orders the server into a tree structure that stores special hashes: to sign transactions and other important messages, you need to validate the corresponding hash built from the parent node called the genesis node; • Nodes linked by a direct hash function ("immediate relatives") form a cluster. The cluster facilitates addressing, the protocol determines the allowable number of nodes in that cluster; • Consensus is designed in such a way that verification takes place mainly in the cluster, except for the situation of unavailable nodes. Verified transactions are added to the DAG structure and distributed along the entire network.

The BGX NetworkBGX_BLUEPAPER_3.0 51 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 15BGX Network

Within the network, information is organized as a set of several virtual cross-networks segregated by the type of information. In fact, such virtual subnets connect virtual servers of the same type. For convenience, such links are called Virtual Links. There are several types of Virtual Links:

Table 6 Virtual Links The transaction enters the network through the entry point defined by the API in the list of unapproved transactions (part of the DL), the servers verify the Transaction ⟶ transaction for a certain number of rounds, on each of which the transaction is 1. Verification signed. If there is not enough quorum in the cluster, the transaction is transferred to the neighboring cluster through the parent cluster node Once the transaction is accepted, it is entered into the Ledger (DAG) structure and propagated between the nodes according to the following scenario: after the counter reaches a successful verification of the set value, the last verifying Ledger Distri- ⟶ node tries to insert the transaction into the DAG structure, in case of success, 2. bution the changed record is transferred as a parameter of the change function in the parent node, which in turn passes the changes to its child nodes and its parent node The system uses the Differential privacy model (see 4.5 Differential privacy), one of the conditions of which is the depersonalization of data in the main in- 3. -⤍ KYC/AML formation flows. In this regard, personal data are allocated to separate servers that support several models of KYC - from complete anonymity to confirmation of citizenship These flows represent the movement of the file content from storage to deliv- ⟶ IPFS/Content 4. ery to the user's mobile device.

The BGX NetworkBGX_BLUEPAPER_3.0 52 PLATFORM ARCHITECTURE V 3.0 2019.01.09

The figure below shows the main components of the model. To emphasize the complex nature of each of the nodes, the name Substrate Nodes is entered. In accordance with the legend, it shows the passage of the transactions in independent nodes that belong to different clusters.

Figure 16 Substrate Nodes and Virtual Links

4.2.3 Transaction Verification Transactional mechanism is the central focus of this system and covers several stages of processing, including: • Formation of a transaction (obtaining information about its main attributes and filling in the required form); • Validation (on the client and on the server) - checking that the transaction is generated correctly; • Verification of the transaction (verification that there are necessary conditions for the transaction - for example, sufficient funds, no fraud, correct signatures, no double waste); • Saving and distribution of the transaction on the network.

The BGX NetworkBGX_BLUEPAPER_3.0 53 PLATFORM ARCHITECTURE V 3.0 2019.01.09

The main verification work is performed by the node that is responsible for the necessary checks and "negotiates" the transaction according to the consensus protocol. For these purposes, the site includes special virtual servers responsible for processing. As part of this processing, the node receives a new transaction from Shared Mempool, which receives new transactions, checks the transaction and transfers it, if successful, back to the Mem- pool with an increase in the round counter. When the quorum (pre- rounds) is reached, the transaction is by consensus, and distributed to the DL. The discarded operations after several rounds are de- leted from Shared Mempool.

Figure 17 Node Processing

4.2.4 Node Authorization Channel Nodes normally interact within a cluster with a signature by their hash of messages. In a separate way, the situations of adding a new node are controlled, as well as the loss of the parent node by the cluster. To do this, when adding a node, the architectural pattern "Discovery Pattern" is used. In this case, the addition of a node is accompanied by a node request (generally random) to the parent node, a hash signature and a message of its data, and a further distribution of the node registry, as shown in the figure below. In case of loss (failure) of the parent node, the tree is rebuilt according to the "Fed- eration Pattern" template, in which information from the node that "discovered" the loss of the parent information is transmitted through a series of intermediate brokers, which serve as other nodes, to the potential receiver, after which randomly selects a new parent. Each broker in turn recheck the existence of a node.

The BGX NetworkBGX_BLUEPAPER_3.0 54 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 18 Internal Node Interaction

4.3 User privacy Currently, the public blockchain networks declare absolute anonymization of transfers. However, the question of data privacy should be evaluated in its integral effect, to what extent user data is protected in the case of a wide range of user scenarios. Since direct access to crypto transactions, especially in terms of exchanging with fiat means is difficult, users use centralized exchanges and crypto organizations that require the use of KYC / AML procedures. The biggest problem is not the procedures themselves, but the leakage of personal data due to the lack of built-in data protection mechanisms. BGX's privacy policy is based on several important principles: • Transactions on the platform are completely separated from the user's personal data, identification is placed in a separate pool of virtual links, so that information is not transferred from node to node, except for dedicated servers for processing such information at the cluster level; • The handling of confidential information cannot be unified for the entire platform due to differences in regulations at the regional level; • When processing and aggregating data, the approach differential privacy44, according to which for any open data set, additional processing is performed with the addition of random information that does not distort the main data, but prevents the identification of personal characteristics or preferences; • If KYC / AML servers are deployed as part of the nodes, the transactions passing through them receive an additional signature, guaranteeing the passage of the corresponding procedure.

44Introduction to Differential Privacy, Berkley, 2013

The BGX NetworkBGX_BLUEPAPER_3.0 55 PLATFORM ARCHITECTURE V 3.0 2019.01.09

Figure 19 Processing with differential privacy

To build the differential privacy model, «a quantitative datacentric»45, designed for mobile environment is suggested. 4.4 Interoperability One of the biggest issues of architecture is the interaction with the external environment. From the side of terminal devices (users), such a solution is the creation of a universal API containing standard methods of transaction management. A similar solution, as part of the ecosystem for decentralized solutions is offered by Stellar. The BGX platform follows the same architectural solution. To implement a single API server as part of the nodes, it is suggested to follow the following principles: • Implementation of the server API based on the RESTful API approach, the next common SOA model implemented as a web service, available through XML or JSON; • The core API core is part of the general BGX protocol and is built using public keys to identify user transactions; • If used on the KYC / AML node side, all data is subject to end-to-end encryption; • Client implementation must support the API kernel even if it is extended by third-party services.

45A Quantitative Datacentric Approach to Differential Confidentiality Analysis

The BGX NetworkBGX_BLUEPAPER_3.0 56 PLATFORM ARCHITECTURE V 3.0 2019.01.09

The Payment Gateway (Bridge Server) plays the opposite role. Such a server is an external system client and provides protocol negotiation, being an implant to the BGX network from outside the system. The most difficult issue of using the Payment Gateway is the construction of a motivational scheme and interaction between nodes in the case of the implementation of several competing gateways. To ex- clude additional processing and the appearance of additional latency associated with this, such gateways are implemented as independent services integrated with the BGX Figure 20 API Server & Gateway network based on the licensing of individual nodes.

The BGX NetworkBGX_BLUEPAPER_3.0 57 APPENDIX 1: CONSENSUS TYPE V 1.0 2018.03.27

APPENDIX 1: CONSENSUS TYPE

Table 7 Consensus types # Type Description Proof of work is currently the most common and best example of a consensus mechanism for blockchain technology. Miner must solve a mathematically complex problem on the new block before he can add a block to the book. The solution is then sent to other miners and checked by them before they are taken into their own copies of the detachment. The mechanism for solving a com- 1. Proof-of-Work plex problem is known as "proof of work". The health check mechanism dictates that the nodes should use the plug that carries the largest amount of work, and it is unlikely that the two competing forks will generate the next block at the same time. With bitcoin, the extraction difficulty is inversely proportional to the target and dynamically changes throughout the life of the system. The delay with bitcoin is 10 minutes (per block), also called the block frequency, and the block size set in bitcoin is 1 MB. Proof-of-share (PoS) is an alternative approach to proof of work, requiring much less CPU calculations for development. In PoS, the node's chances of clearing the next block are proportional to the balance of that node. PoS operates in the DAO (Decentralized Au- tonomous Organization). Ethereum is working on DAO, a public blockbuster that provides a decentralized virtual machine for perform- 2. Proof-of-Stake ing peer-to-peer controls using its own Cryptocurrency Ether. The DAO provides its participants with a token that is proportional to their investments, representing voting rights and property rights. The PoS protocol has its strengths and weaknesses, and actual implementations are quite complex Algorithm for practical Byzantine fault tolerance (PBFT) provides a solution to the problem of Byzantine generals, which works in asynchronous environments, such as the Internet. PBFT includes a three-phase protocol and the concept of a primary (master) node Practical Byzantine Fault Tol- 3. that acts as a coal miner. The leader can be changed by the voting mechanism by the rest of the network, if he shows arbitrary be- erance (PBFT) havior. PBFT works on the assumption that less than one third of the nodes are faulty (f), which say that this requires at least 3f + 1 nodes. The consensual Ripple algorithm uses "collectively trusted subnets" called "Unique Node Lists" (UNL) to cope with the high latency 4. Ripple that typically characterizes BFT-tolerant systems. To reach consensus, a node must only request its own UNL instead of the entire network. It can tolerate damage to less than one-fifth of its nodes (stability 5f + 1) Tangaroa, a version of the Byzantine fault-tolerant (BFT) Raft algorithm, is used as a consensus mechanism in Juno. Tendermint provides BFT tolerances and is similar to the PBFT algorithm, but with a stricter guarantee of the results returned to the client when 5. Tangaroa more than a third of the nodes are faulty and allows a dynamically changing set of validator sets and leaders that can be rotated cyclically among other optimizations In Multi-Chain, ministers included in the whitelist add blocks to the chain cyclically, with some degree of indulgence, to allow malfunc- tioning of the nodes. A network parameter, called "Intelligence spacing", is used to calculate the number of blocks that the miner should wait before trying to run the command again, otherwise the block will be rejected. The low value of the mining diversity param- 6. Multi-Chain eter means that several miners need to cooperate in order to take over the network. If the number of collaborating miners is equal to or greater than the number of blocks that each miner must wait before attempting to restart the mine, then there is a possibility that this will happen. Conversely, a higher value of the mining diversity parameter ensures that more permitted miners are included in the turn, which makes it difficult for the minority to capture the network Sieve, the mechanism used in the HyperLedger Fabric project, allows the network to detect and remove possible nondeterministic 7. Sieve queries, and also to reach consensus on the state of the output of the proposed transactions The consensus Raft algorithm is easier to understand than the other algorithm and is used for the replicated log. Raft is superior and 8. Raft more efficient than Paxos, a family of protocols for resolving a consensus in a network of unreliable processors. RAFT is used in BigChain DB PoET is a lottery protocol based on reliable execution environments (TEE) provided by Intel Software Guard Extensions (SGX) to 9. Proof of Elapsed Time meet the needs of large groups of participants. It is used in the Intel Sawtooth Lake project Quorum Voting is the adaptation of the Ripple and Stellar consensus protocols and serves to satisfy the needs of applications requir- 10. Quorum ing immediate transaction. It is used in the Intel Sawtooth Lake project

BGX_BLUEPAPER_3.0 58 APPENDIX 1: CONSENSUS TYPE V 3.0 2019.01.09

The Federated Consensus ensures that all participants agree to a single transaction log on the network. A block is received if it is signed by the specified number of block subscribers. This is implemented using the M-of-N multi-signatures rule, where M is the num- 11. Federated Consensus ber of signatures required to accept a block, and N is the number of block subscribers. For each of the subscribers of block N, the program specifies the public key and is passed in the arguments. The value of the parameters M and N can be set according to business requirements. Consensus programs are written and executed by the virtual machine Chain A hybrid approach that combines both proof of work and proof of interest is called evidence of activity. The best example for explanation is Peercoin (PPC), which uses the initial consensus to confirm the work in conjunction with the consensus test. By combining the 12. Proof-of-Activity two consent models, you need to use much less energy for network maintenance, and the risk of attack is also lower by 51 percent. Authorities that have a higher level of evidence are easier than those who extract using pure computing power, but immediately turn their Peercoin into another digital currency The Evidence of the Importance Consensus is used to determine who will calculate the next unit. The importance of the account is determined by the number of coins it contains, and the number of transactions made with and from this account. The POI 13. Proof-of-importance is different from other initiatives that use a sharing model that does not take into account the overall network support. It is used in the NEM ecosystem Consolidation of the Keyless Signature Infrastructure (KSI) subsystem is achieved using a core, a distributed synchronized machine responsible for reaching a consensus on the upper value for each aggregation period, storing it in the calendar database for a long 14. KSI Consensus time, and returning it to the aggregation network. The core maintains the exact value of the clock, which is provided to customers as the release time of each signature token. The calendar database is distributed using "dumb" caching layers for expander servers to verify the markers of the signature Identity proof is a cryptographic proof (a data block) that says that some user knows the private key that corresponds to the approved identifier and is cryptographically tied to a specific transaction. The idea is that each member of a group can create a proof 15. Proof-of-Identity of identification (simply a piece of data) and present it to anyone (for example, to a processing node).

In the research work of Wustrow and VanderSloot, a theoretical crypto currency called DDoSCoin is proposed that uses the malicious "Proof-Of-Work" negotiation mechanism that rewards DDoS (Distributed Denial of Services) participants with DDoSCoins. Proof-of- 16. Proof-of-DDoS DDoS works by having miners who create a large number of TLS connections to the target web server and use signed server re- sponses as a proof of connection In proving the bandwidth, the node receives payment on the hard disk. The more space on the hard drive the node has, the better your chance to get the next block and get a reward for the unit. In the system of evidentiary power before extraction, the algorithm 17. .Proof-of-Capacity generates large data sets, known as "graphs", which the node stores on its hard disk. The more sites a node has, the better your chance to find the next block in the chain In proving the proof-of-burn node "burns" coins, sending them to the address where they remain irrevocably. By making sure that the 18. Proof-of-Burn coins never come to earth, the node receives a lifetime privilege for my work in the system on the basis of a random selection process. The more coins burn, the more chances to be chosen for my next unit When cross-faulted (XFT), the protocol simplifies attack patterns and can tolerate both non-standard (Byzantine) failures and network failures (asynchronous). XFT can help in creating robust protocol schemes that can tolerate machine failure errors regardless of the number of network failures and failures, when the number of machines that are defective or fragmented is within the threshold value. 19. Cross-Fault Tolerance (XFT) XFT protocols can also provide the right service, even if Byzantine errors do occur, if most of the replicas are correct and can communicate synchronously with each other. In the XFT protocol, most nodes cannot be controlled by the enemy and simultaneously create network partitions, which can occur in asynchronous Byzantine fault tolerance (BFT)

The BGX NetworkBGX_BLUEPAPER_3.0 59 APPENDIX 2: DISTRIBUTED TRANSACTION SYTEMS ATTACKS V 1.0 2018.03.27

APPENDIX 2: DISTRIBUTED TRANSACTION SYTEMS ATTACKS Double-spending attack is the successful use of the same funds twice. Distributed systems (in particular Bitcon or other 1 DOUBLE-SPENDING Public DLTs) are protected from double-spending attacks by verifying each transaction that is added to the chain of blocks, to ensure that the funds contained in the transaction have not been previously spent. 2 RACE ATTACK Receiving a transaction by the end service, which has 0 confirmations, potentially leads to a double spending The type of attack in the peer-to-peer network, as a result of which the victim connects only to the sites controlled by the 3 SYBIL ATTACK attacker. 4 FINNEY ATTACK Attack involving miner, implying the re-inclusion of an unverified transaction in the block If an attacker controls more than 50% of the blockchain's network capacity, the probability of Finney's success is 100%. Due 5 >50% ATTACK” to the fact that an attacker can generate blocks more often than the rest of the network - he can create his own chain of blocks, until it becomes longer than the "honest" part of the network. DENIAL-OF-SERVICE Sending a large number of "junk" data to a node that processes transactions can complicate its operation 6 (DOS) A client program that allows a user to access the network and perform operations with its own resources can be attacked 7 CLIENT ATTACK by stealing a private key or password with which it is encrypted

BGX_BLUEPAPER_3.0 60 APPENDIX 3: DECENTRALIZATION PLATFORM DESIGN DESCISION V 3.0 2019.01.09

APPENDIX 3: DECENTRALIZATION PLATFORM DESIGN DESCISION According to the “A Taxonomy of Blockchain-Based Systems for Architecture Design”

IMPACT DESIGN DECISION OPTION Fundamental Cost Performance Flexibility properties Efficiency Public blockchain ★★★ ★ ★ ★ Blockchain Scope Consortium/ community blockchain ★★ ★★ ★★ ★★ Private Blockchain ★ ★★★ ★★★ ★★★ Blockchain ★★★ ★ ★ ★ GHOST ★★ ★★ ★★ ★ Data Structure BDAG ★ ★★★ ★★★ ★★★ Segregated Witness ★★★ ★★ ★ ★ Proof-Of-Work ★★★ ★ ★ ★ Security- Proof-of-retrievability ★★★ ★ ★ ★ wise Proof-of-stake ★★ ★★ ★★ ★★★ Consensus BFT (Byzantine Fault Tolerance) Protocol ★ ★★★ ★★★ ★ Bitcoin-NG ★★★ ★ ★ ★ Scalability- Off-chain transaction Protocol wise ★ ★★★ ★★ ★★★ Mini-blockchain ★★★ ★★ ★ ★★ Security- X-block confirmation ★ ★ ★ ★★★ Protocol Con- wise Check-pointing ★★★ ★★★ ★★★ ★ figuration Scalability- Original block size and frequency ★★★ n/a ★ n/a wise Increased block size/Decrease mining time ★ n/a ★★★ n/a Merged mining ★★★ ★★ ★ ★ Security- Hook popular blockchain at transaction level wise ★★ ★ ★★ ★★★ New generation Proof-of-burn blockchain ★ ★ ★★★ ★★ Scalability- Side-chains ★★★ ★ ★ ★ wise Multiple private blockchains ★ ★★★ ★★★ ★★★

APPLICATION 4 KEY TERMS # TERM DESCRIPTION

The BGX NetworkBGX_BLUEPAPER_3.0 61 APPLICATION 4 KEY TERMS V 3.0 2019.01.09

Anti-Money Laundering and Counter Terrorism Financing (AML/CTF) legislation and regulation aims to Anti-Money Laundering and Counter Ter- prevent money laundering and the financing of terrorism by imposing a number of obligations on the fi- 1. rorism Financing (AML) nancial sector, gambling sector, remittance (money transfer) services, bullion dealers and other professionals or businesses that provide particular regulated services An Application Programming Interface (API) is a technical interface to a web service or programming lan- 2. Application Programming Interface (API) guage library that exposes functions or methods in the interface to be able to be invoked by clients using a programming language Bitcoin Bitcoin is a peer-to-peer payment system invented by an unidentified programmer, or group of program- 3. mers, under the name of Satoshi Nakamoto. Block A block in a blockchain is the container of transactions. Each block contains a timestamp and a link to the 4. previous block Byzantine-Fault-Tolerant (BFT) Consensus: a mechanism for achieving fault-tolerant consensus. It has BFT Consensus 5. stronger consistency guarantees than Nakamoto consensus, but requires a known and smaller maximum

number of participants 6. Consortium blockchain A private blockchain deployed and operated by a consortium of organizations Digital currency is an Internet-based form of currency or medium of exchange distinct from physical (such 7. Digital currency as banknotes and coins) that exhibits properties similar to physical currencies, but allows for instantaneous transactions and borderless transfer-of-ownership A Decentralized Autonomous Organization (DAO) is a special kind of Smart Contract. A DAO is code that Distributed Autonomous Organization operates as a decentralized autonomous business model for organizing both commercial and non-profit 8. (DAO) enterprises (generally in a financial way). The legal status of a DAO is uncertain. A specific DAO called ‘The DAO’ ran as an investment vehicle on Ethereum in 2016, but failed because of poorly-understood smart contract code. Ethereum is a public blockchain-based distributed computing platform, featuring smart contract function- 9. Ethereum ality. It provides a decentralized virtual machine, the Ethereum Virtual Machine (EVM), which can execute peer-to-peer contracts using a token called ether. In Software engineering and systems engineering, a functional requirement defines the observable input/ Functional requirement 10. output behavior of a system or its component, for example, calculations, technical details, data manipula-

tion and processing and other specific functionality that define what a system is supposed to accomplish. As smart contracts execute, they use computational resources in many participating nodes. To limit re- source utilization and compensate for the use of these resources, some blockchains such as Ethereum 11. Gas charge ‘gas’ for the execution of smart contracts. Gas is usually paid for with the blockchain’s digital currency. More demanding smart contracts use more gas, and blockchains may impose a limit on the amount of gas that can be used per transaction or per block A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes. Hashes 12. Hash are nonreversible: if some data is hashed, it is impossible to recover the data from the hash value alone. However, if the data can be guessed, then its hash values can be used to confirm that the data was originally hashed Not able to be changed. Blockchain data cannot in practice be easily changed because it is continually replicated across many different locations and organizations. Blockchains are tamper-evident. Attempts 13. Immutable to change it in one location will be interpreted as fraudulent and an attack on integrity by other participants, and will be rejected

The BGX NetworkBGX_BLUEPAPER_3.0 62 APPLICATION 4 KEY TERMS V 3.0 2019.01.09

The internet of things (IoT) refers to devices, sensors, motors, and other electronics connected to the internet. The rising rate of computational power in parallel with their falling cost foreshadows a potentially 14. Internet of Things (IoT) significant and increasing trend of adoption, with many billions of devices expected to be deployed in the coming years The ability of a system to work effectively with other systems. This will typically involve sharing or access- 15. Interoperability ing data or services, through defined interfaces. Know your customer is the process of a business identifying and verifying the identity of its clients. The term is also used to 16. Know your customer (KYC) refer to the bank regulation which governs these activities In a Proof of Work blockchain, the processing nodes which collectively operate the blockchain are 17. Miner known as miners The Nakamoto Consensus mechanism is used in Bitcoin and other blockchain systems. When there are Nakamoto Consensus 18. multiple alternative versions of the blockchain ledger, the Nakamoto Consensus mechanism favors the

longest chain Non-Functional Property Non-Functional Properties are criteria that can be used to judge the performance of a system, and include 19. performance, scalability, and security In systems engineering and requirements engineering, a non-functional requirement is a requirement for Non-Functional Requirement 20. a Non-Functional Property. These requirements specify criteria about the performance of a system. They

are contrasted with functional requirements The inability to deny a previous claim. On a blockchain, the immutability of historical transactions which 21. Non-repudiation are cryptographically signed means that there is always strong evidence that those transactions were performed by someone with control over those cryptographic keys. Conventionally, a bank does not have a ledger jointly shared with another bank. Instead they create internal accounts intended to mirror the accounts held at the other bank. The other bank holds dual sets of 22. Nostro/vostro accounts accounts, and these ‘nostro/vostro’ accounts can be periodically reconciled to check and maintain consistency between the two banks. A jointly-shared distributed ledger, perhaps implemented using a blockchain, is an alternative to this conventional approach An oracle is a trusted person or program that creates a record on the blockchain about some event or 23. Oracle condition in the external world Proof of concept (POC) is a realisation of a certain method or idea in order to demonstrate its feasibility Proof of Concept 24. or a demonstration in principle with the aim of verifying that some concept or theory has practical poten-

tial A proof-of-stake (POS) is a type of consensus protocols used by blockchain systems, where the proba- 25. Proof of Stake bility of mining a block is dependent on varies how much digital currency is controlled by the miners Proof-of-Work (POW) is a type of consensus protocols used by blockchain systems, where the probabil- 26. Proof of Work ity of mining a block is dependent on how much work is done by the miners A blockchain operated by a private entity or consortium, with no or limited access by other parties, and typically with a small number (tens or hundreds) of processing nodes operating the blockchain. In this 27. Private blockchain context, compared to public blockchains, technical optimisations may be used to improve the latency and throughput of the blockchain, and BFT consensus mechanisms may be used to provide stronger guarantees about the completion of transactions 28. Private Key See Public Key. A blockchain operated as a public peer-to-peer system. Parties are usually identified by pseudonymous 29. Public blockchain public/ private keys, and a form of Nakamoto consensus is typically used to allow a large number (thousands) of processing nodes to operate the blockchain

The BGX NetworkBGX_BLUEPAPER_3.0 63 APPLICATION 4 KEY TERMS V 3.0 2019.01.09

In cryptography a public key is a published number which is used as a parameter in an encryption func- 30. Public Key tion, to encrypt and check signed messages. Public keys are paired with secret private keys, which are used to decrypt and sign messages Security (information security, cybersecurity) is a collection of Non-Functional Properties, which classi- 31. Security cally include Confidentiality, Integrity, and Availability, but can also include properties such as Privacy, Non-Repudiability Sharding is a technique of breaking apart a database or blockchain into separate independent pieces. If 32. Sharding the pieces are truly independent, they can be processed concurrently, which can significantly increase the throughput of the overall system In blockchain technology, a smart contract is a program that is recorded on the blockchain ledger and executes as part of transaction validation on the blockchain. In addition to executing the logic encoded in 33. Smart contract (blockchain) the program, smart contracts can carry digital currency or control access to other digital assets or tokens recorded on the blockchain. Some blockchains allow smart contracts to be arbitrary Turing-complete programs, while other blockchains only allow more limited programs Smart contracts are computer programs that facilitate, verify, or enforce the negotiation or performance 34. Smart contract (legal informatics) of a legal contract State channels are a design pattern for the use of smart contracts to adjudicate on the completion of an off-chain protocol. Participants first jointly commit to this smart contract. Then they exchange a series of 35. State channels messages off-chain about which may be too confidential or rapid or large to perform on the blockchain. The final state of the off-chain exchange is submitted back to the smart contract, which resolves final exchange of assets on the blockchain 36. Trusted In dependable systems, being trusted means being relied upon to achieve some purpose 37. Trustworthy In dependable systems, being trustworthy is the quality of having good evidence for being dependable In computability theory, an instruction set or a programming language is said to be Turing complete or computationally universal if it can simulate a Turing machine. The Church-Turing thesis is that all such 38. Turing complete languages have equivalent computational power. Programs in a Turing-complete language can be arbi- trarily complex, and there is no mechanism to automatically determine the correctness of all programs in a Turingcomplete language In software and systems engineering, a use case is a list of actions or event steps, typically defining the 39. Use case interactions between a role (or actor) and a system, to achieve a goal

The BGX NetworkBGX_BLUEPAPER_3.0 64