a brand of Lambda Vision Assets and trust tokenization · Assets and trust tokenization White Paper...

a brand of Lambda VisionAssets and trust tokenization

White Paper 23

OverviewIXXO (a brand of Lambda Vision) is an integrated stack to tokenize trade and

track digital and financial assets in decentralized collaborative networks decentralizedtrading exchanges decentralized teams decentralized access rights decentralizedwebmails platform linked to auditable proofs

We provide a unique API to simplify development blockchain operations file ex-change operations email backend proof management token exchanges and tradingkeys management

Our focus is usability Your opportunity is a unique API to answer all your decen-tralized serverless needs

Contents

1 Lambda Vision positioning 6

11 Mission statement 6

12 Economical Context 6

13 History of the blockchain 6

14 IXXO offering overview 7

2 11 issues blocking user adoption 9

21 ISSUE 1 Transaction prices and duration on programmable blockchains 11

22 ISSUE 2 Massive energy waste 12

23 ISSUE 3 Everyday users still prefer everyday fiat currencies for services 13

24 ISSUE 4 Flat fees for all 13

25 ISSUE 5 Data storage costs 13

26 ISSUE 6 Document accessibility in blockchain logic 13

27 ISSUE 7 User data privacy issues 14

28 ISSUE 8 Blockchain security 14

29 ISSUE 9 Low usability for end users (browser side) 15

210 ISSUE 10 Fee volatility 16

211 ISSUE 11 Low Utility for dApp developers 17

3 Solving issues 18

31 SOLVING ISSUE 1 Ensuring low transaction costs and duration 18

32 Solving ISSUE 2 Reducing energy waste (1000000 time cheaper) 19


34 Solving ISSUE 4 User selected fees 20

35 Solving ISSUE 5 Reduce data storage costs 20

36 Solving ISSUE 6 Improve documents accessibility 20

37 Solving ISSUE 7 Improve Data privacy 22

38 Solving ISSUE 8 Improve Blockchain security 24381 Introducing PoA (Proof of Authority) protocols 24382 The design of a consensus 24383 Risk of validating node collusion (51 attack) 25384 Fraud detection 25

39 Solving ISSUE 9 Improve end user usability 26

310 Solving ISSUE 10 Reduce and stabilize fees 26

311 Solving ISSUE 11 Increase usability for dApp developers 26

4 Market 28

41 The current state of the Ethereum dApps market 28

42 IXXO use cases per content distribution model 29

43 Some examples of IXXO use cases per industry 30

44 Market size and trends 31

45 Money raising through the blockchain 31

5 Revenue and go to market 32

51 Existing customers 32

52 IXXO revenues 32

6 IXXO versus other blockchains 34

61 Features and performance 34611 How IXXO brings performance 34612 Blockchain protocols and performance 34613 Transaction confirmation time 35

62 IXXO vs EOS 35

7 The delivery roadmap 38

71 Features-set planning 38

5

8 Annex 1 Deep dive in the tech 41

81 The MPoA protocol 41811 Accounts and clusters trust 41812 Transactions stored on the IXXO blockchain 41813 Accounts cluster trust policies 42814 Fine tuning fees expenses 42815 Virtual Machine verification 43816 Balance structure optimization 43

82 dAppBox internals 43821 The dAppBox access rights system 44

83 RockEngine Computation on private data 44831 Step by step proofs for total algorithms accountability on private data 45832 RockEngine strengths and upcoming challenges 45

84 IXXO governance 45

9 Annex 2 Benchmarking RockEngine 47

91 Introduction 47

92 State of the art 48

93 Use cases 50

94 Genericity 50941 Compiling scripts from an extended JavaScript (RockEngine v1) and Solidity (Rockengine

v2) 50942 Installing and using RockEngine v1 51943 RockEngine integration with dAppBox and IXXO 52

95 Technical improvements 52951 Test panel 52952 Optimization of the output circuit 53

96 Benchmark conclusion 54

97 Bibliography 54

1 Lambda Vision positioning

11 Mission statement

Streamline decentralized value sharing

12 Economical Context

Our recent business cycle have seen the apparition of ecosystems startup andcorporation collaboration shared data better IT integration among companies cloudbased processes (external to the company IT systems) Wersquove also seen teams beingremote without an office to physically meet Some predict this will lead to decentralizedautonomous organization decentralized organisation the results of a five phases cycle

The blockchain has not become a business platform because of unsolved chal-lenges described in this white paper More than blockchain the integration of P2Pprotocols are able to redefine value sharing in distributed teams

13 History of the blockchain

In January the 3rd 2009 Bitcoin launched an alternative ecash payment system withno central counterpart Instead of just decentralizing payments it occurred we couldalso decentralize script logic Ethereum was launched on this promise on July the 30th2015

This new ldquoworld computerrdquo needed decentralized data and document stor-age later launched with IPFS and SWARM in 2017 Today many blockchains protocolsexist and need to talk together That was made possible by Cosmos Network launchthe March 15th 2019


14 IXXO offering overview

Blockchain platforms having so many issues to be solved before being usable by main-stream users that IXXO simplified a maximum blockchain usage extended blockchainP2P protocol to other protocols usages through a unique API available on demandIXXO kept decentralization in mind on all the toolchain

IXXO publicblockchain Onchain

decen-tralized

exchange

Remotepayment

systems or-chestrationOnchain

gover-nance andauditability

Fast blocktime 5s

Low energycost

dAPpBoxDistributedFile System

Proofof Files

Existence

Proofof Files

Transfers Seamlesslogin

experience

Onchainaccessrights

Privacypreserving

scripts

8 Chapter 1 Lambda Vision positioning

DAPPS DAPPBOX APP

DAPPBOXDISTRIBUTED FILE SYSTEM

SURVEYMANAGER

PRIVATE MAILSERVICES

SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT

APITOKEN ORIG-INATOR API

CALENDERRESERVATION API BLOCKCHAIN

LAYER

PROTOCOL BLOCKCHAIN OTHER BLOCKCHAINS

CLOUD LAYER KUBERNETES

Figure 11 Description of IXXO technical stack

2 11 issues blocking user adoption

The first blockchain (Bitcoin) has been focused on solving the double spend issue ofdigital currencies with no central counterpart involved Later the blockchain was thenused to permanently store proof of documents (hashes)

Blockchain 20 infrastructures (Ethereum Lisk NEO EOS) added programmablefeatures to existing blockchains and improved transaction speed and cost but haveyet to provide an application-creator friendly environment

Despite the web of interconnected issues described in the following schema alot of crypto entrepreneurs have ventured forward create decentralized applicationsUnfortunately user adoption did not follow (section 41 - dApp markets)

The following schema describes the intertwined web of issues on the current blockchainthat need to be resolved for reaching acceptable projects and users usability

10 Chapter 2 11 issues blocking user adoption

Decentralizationissues

Centralizedcrypto

exchanges

Cost ofdata

storage

GovernanceissuesTransaction

duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump

UnregulatedICO prac-

tices

Insidereffect onprotocol

gover-nance

No businesscentric design

No af-fordable

boot-strappingproposal

for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed

Usersprofilesdata ispublic Users

documentsare public

Tokenomicsissues

Cost oftoken listing

Feesvolatility

Concentrationof tokenholders

IT Security issues

51 attack

possibleon smallnetworks


21 ISSUE 1 Transaction prices and duration on programmable blockchains

Figure 21 Money transfer costs for the last 18 months

The price for a simple transaction (ie money transfer) can cost up to $50 forBitcoin and $5 for Ethereum (figure 21)

For a small smart contract application (source) authorizing a transaction by 2 userstotal costs are $ 05 (table 21)

OPERATION FREQUENCY GAS COST USD COST

Contract deployment ONE TIME 536467 $321

Confirmation Actor 1 EACH PAYMENT 46746 $028


Table 21 Costs of authorizing a payment with 2 people on Ethereum for a $300 Etherprice

For web applications smart contract validation would be free while money transac-tions are at least 90 cheaper (Table 22)

For Ethereum the scalability is 20 transactions per second with 3 minutes per trans-action The Ethereum community announced better scalability with Metropolis to bereleased in 2018 Not yet released Metropolis will probably be delayed one more yeara consequence of the difficulty bomb being postponed EIP1234

Some public blockchains solved scalability issues (Stellar EOS and Zilliqa) by reach-


Comparing Micropayments

Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡

Table 22 Leading online payment providers micro-transactions prices

ing 1000 transactions per second

Practical transaction duration (equivalent to transaction confirmation time) of 5seconds have been achieved by PoA network Stellar and EOS although 50 times morethan acceptable web standards for smart contracts interactions

22 ISSUE 2 Massive energy waste

While this issue is not related to usability energy waste has a huge negative impacton the entire planet ecosystem

Figure 22 Bitcoin mining energy waste versus countries energy spending

159 countries cannot afford the energy spending on bitcoin mining (figure 22)Ethereum miners spend 10 times more energy than all electric cars together (20 TWh)


Spending accelerates at a 500 per year rate for Ethereum until october 2018 whereactivity lowered (currently 7TWh)

23 ISSUE 3 Everyday users still prefer everyday fiat currencies for services

Fiat currencies (EUR USD) are yet better valuation metrics tools as pricing most ofthe real world items Blockchains should also support those currencies The blockchaintechnical infrastructure is strongly bound to the adoption of alternative currenciessystems not easy for everyday users

24 ISSUE 4 Flat fees for all

All blockchain operations bear the same security costs in the existing public blockchainsSecuring a document hash or transferring millions of USD are aligned in sharing theblockchain security infrastructure costs while in reality they require totally different levelof trusts

25 ISSUE 5 Data storage costs

Given August 2018 gas prices storing 1 Gigabyte of data on Ethereum would cost$26 million (fig 22 gas costs computation for 1 byte) Storing the same data on thecheapest cloud storage offerings (table 23) would cost merely $ 0002 per month - 10billion times less

$GBmonth all stor-age

Amazon Glacier Azure Blob StorageArchive

B2 Cloud Storage

0004 0002 0005

Table23 Current Cloud pricing for cloud storage

26 ISSUE 6 Document accessibility in blockchain logic

As opposed to centralized web applications decentralized applications on theblockchain cannot orchestrate the reception of users documents proposals for onlineediting of documents or distribution of documents or media files to the user

The most advance initiative to solve this is IPFS a decentralized file system usinga peer to peer protocol derived from Bittorent However IPFS does not meet a keyrequirement of any file system as sudden document disappearance independent fromuser action can occur To avoid this you have to pay a pinning service throughFileCoin for example

While IPFS Filecoin can store documents it does not protect their privacy andcannot integrate document or media updates into smart contract logic


27 ISSUE 7 User data privacy issues

Zero-knowledge proofs (ZKP) are often presented as THE solution to blockchain pri-vacy issues In reality ZKP can only help when answering some TRUEFALSE challengeson user data (such as passwords verification) To allow any algorithm to process privateuser data such as in web applications we need secured multipart computation orEnclave computing two opposite proposals to solve the issue

Currently only the Enigma blockchain tackles data privacy in smart contract opera-tions Enigma first adopted Enclave computing in their first version and intend to switchto Secured Multipart Computation in 2019 ( Voyager Secret Contracts 20)

Enclave computation (on Intel SGX the only provider of Enclave technologywhile AMD only encrypts memory) has a 2000 overhead performance cost on smallcomputations (figure 23) and some open security flaws while not being able to run onsmart phones

Figure 23 SGX overhead for the max algorithm thanks to Danny Harnik

28 ISSUE 8 Blockchain security

For small public blockchains it might be possible to rent services such as NiceHashto setup a 51 attack for only a few hundred thousand USD (table 23)


51 attacks can be very profitable as occurred during the may 2018 attack onBitcoin Gold with $18 million being stolen (figure 24) in a single attack

PoW 51 Attack CostThis is a collection of coins and the theoretical cost of a 51 attack on each network

Name Symbol Market Cap Algorithm Hash Rate 1h Attack Cost NiceHash-able

Bitcoin BTC $11152 B SHA-256 49091 PHs $542898 1

Ethereum ETH $2819 B Ethash 227 THs $189911 3

Bitcoin Cash BCH $908 B SHA-256 3916 PHs $43307 13

Litecoin LTC $326 B Scrypt 254 THs $35698 6

Monero XMR $148 B CryptoNightV7 466 MHs $10514 11

Ethere Classic ETC $129 B Ethash 14 THs $11656 48

Dash DASH $115 B X11 2 PHs $9747 23

Table 23 Credits to crypto51app

Figure 24 Recent (2018) 51 attacks and profitability

29 ISSUE 9 Low usability for end users (browser side)

Generally users of decentralized applications have to perform technical operationsto interact with blockchains through custom tools to be installed Users have to confirm


their actions for all interactions with the blockchain

bull 1 For Ethereum Metamask Chrome plugin has a setup requiring 10 to 20 stepsand depends on Google services availability for setup

bull 2 The Ethereum official wallet Mist requires a few hundred gigabytes and severalhours of setup

bull 3 Opera announced in July 2018 as an integration of crypto wallets into mobilebrowsers has no release date yet

bull 4 Scatter is another chrome browser plugin to store an EOS or Ethereum privatekey With advanced setup users can avoid confirming all step by step blockchaininteractions on EOS blockchains

Users have to use crypto wallets which is disrupting application usage the future of Ethereum has no wallets

Users also have to buy tokens a complex process of hours to weeks due toKYC constraints on exchanges They have to do it for 2 distinct tokens the blockchaintoken and the dApp crypto token this is the economic abstraction issue which solutionis still being designed by the Ethereum community

210 ISSUE 10 Fee volatility

Ethereum suffers from fee volatility with a peek gas spending of $ 27 million just forthe day of July the 2nd That day in order to wait less than 30 minutes users had to paymore than $ 3 This network congestion was apparently mainly caused by a single actorFCoin proposing services for users to optimize their fees

Figure 25 Ethereum fees volatility May to July 2018

In order to fix this the Ethereum founder Vitalik Butterin recently (July 2018) pro-posed a new pricing mechanism for gas fees however this solution has not been imple-mented


211 ISSUE 11 Low Utility for dApp developers

dApp tokens theoretically provide usage liquidity and also enable an ecosystem ofapplications to be built on top of the the use of tokens A lot of dApps financed throughICOs have embraced this ecosystemic dApp-empowered model

In reality however only the ETHER token (ETH) can easily be used by smart con-tract dApps The ETHER balance is available at any time in the smart contract contextfor users and operations on balances are insured by security context binding withoperations callers

This is not at all the case for dApp tokens (ERC20) which can hardly be operatedfrom outside the ERC20 token contracts In order to do that the ERC20 smart contractshould provide allowance to the new dApp contract which is often not possible be-cause of the immutable state of ERC20 contracts except if the token was designed insuch a way from scratch which entails security risks

Even with allowance smart contract to smart contract calls are expensive andrequire a lot of extra work as opposed to using ETH directly

3 Solving issues

31 SOLVING ISSUE 1 Ensuring low transaction costs and duration

IXXO is a fork of the Ethereum blockchain Its current onchain governance givestatus to nodes Using a new transaction type nodes can update other node status fortransaction validation

The following status are implemented Readonly forever A node can only ready the blockchain and cannot udpate

(auditor claiming no interaction with the chain even) Readonly can only read but could be promoted Trading can only send tokens but not interact with smart contracts Standard usual Ethereum account Admin have ability to change status of other accounts according to some

rules Admin nodes are validator nodes (validating transactions to be added in newblocks)

CoreAdmin Have all the rights including minting new native tokens on IXXOblockchain and setting exchange rates (decentralized crypto exchange features)

Our V2 algorithm gives the ability for blockhcain users to choose to be validatedby different type of validating nodes organized by clusters Clusters will be organizedby professionnal activity regulatory finance law etc

This V2 extension is called Mixed Proof of Authority (MPoA) It prevents therisk of centralization by corporate effects all validators looking alike in business termsthey can agree on terms (for blockchain fees for example)

MPoA is creating competition among nodes clusters for fees leading to a virtuouscycle of more security guarantee for nodes for highest fees


IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)

Competing identity clusters will lead to heterogeneous levels of trust for blockchaintransactions each user choosing the required trust level per transaction The blockchainis still able to provide a global homogeneous transaction graph view for transactions ofdifferent trust level (described in the Deep dive in the technology)

Transaction 1 (vali-dated by cluster 1)

Transaction 2 (vali-dated by cluster 1 et 3)


Clusters could be bailiffs notaries hosting companies corporations with reputation(Proof of Reputation) dApps can select their chosen clusters trust level when usingtransactions their apps all clusters are sharing the same blockchain Transaction timefor MPOS is reduced to 3s and estimated scalability reaching 1000 TPS

32 Solving ISSUE 2 Reducing energy waste (1000000 time cheaper)

Not all clusters would mine all transactions and low security level transactions wouldhave a tiny ecological footprint On low assumptions (7TWh) for Ethereum energy

20 Chapter 3 Solving issues

consumption with hundreds of validating nodes deployed IXXO still consumes 1000000times less energy than Ethereum


IXXO blockchain is a preprocessing payment protocol linked to your chosen paymentsystem IXXO is managing the interfaces between spending allowances spendingpurposes and smart contract escrow services based on the blockchain and realpayments based on a payment system such as STRIPE or any other IXXO blockchaincan also hosts usual tokens

34 Solving ISSUE 4 User selected fees

The MPoA (Mixed Proof of Authority) lets the user (application or single user) choosethe cluster associated to the required level of trust and transaction security level Thecluster fees depend on the provided trust and security level

35 Solving ISSUE 5 Reduce data storage costs

IXXO data storage fees depend on the cluster selected to validate the transactionsOn the cheapest validator nodes clusters costs are estimated to be $20 per GB 100000times cheaper than Ethereum

36 Solving ISSUE 6 Improve documents accessibility

Documents external to the IXXO blockchains (referred with links figured as hashes)are stored in a P2P network powered by technology the dAppBox network

The dAppBox network

The dAppBox stack was developed in early 2017 to provide P2P file sharing servicesintegrated with blockchain smart contract logic It has already been successfully de-ployed to be integrated with private customersrsquo blockchains

Access rights to private nodes in the dAppBox network are governed by soliditysmart contracts a guarantee for audit and transparency in access grants or denials Allcontent nodes remain private and each user owns his own data

The dAppBox has been designed to reach 3 goals


Goal 1 Decentralization

Have no business central counterpart de-ciding who can access content

11 Every peer is his own data routercan manage individually his own au-thorized peers

12 No server hosting the access rightscan be compromised legally or ille-gally

13 Easily manage rights transfers toother peers through decentralizedlogic

Goal 2 Traceability

Transparency traceability on content ac-cess rights grant (who is acting who isconcerned when)

21 Every access right modificationis permanently stored in theblockchain

22 Peers are identified by blockchaincryptographic signatures more se-cure than a traditional login pass-word

Goal 3 Usability

Create an open platform where applica-tion owners can integrate their contentdistribution logic

31 Time based rules Temporary andevent based access rights with atimeline

32 Quorum smart contracts can en-able rules decided using a Quorum

33 Programmability permission smartcontracts can be called by the de-centralized application

The dAppBox network and IXXO blockchain interactions

The dAppBox content network and the IXXO blockchains are deployed next to eachother to work hand in hand The dAppBox P2P client needs to have a platform to grantaccesses and to store proofs

The integration goes further in v2 version (Check 7 Delivery mode) where eachcontent folder has a unique Ethereum address with smart contract methods to checkthe onlineoffline status of a given content folder In addition to this in the v2 version thesmart contract can check document availability in the dAppBox network using the hash

The dAppBox uses the IXXO blockchain to store all the proofs of documentrsquoslifecycle


Proofs provided by the dAppBox API Description

Proof-of-existence Prove that a node host a documentlocally andor has anterior ownership on

a documentProof-of-transmission Prove that a document has been

transferred from one identity (IXXOblockchain address) to another

Document quality assessment Track who assessed the quality ofcontent and when

Proof of access grant Prove some content folder has beenshared to who and when

The dAppBox network tightly integrated with the IXXO blockchain allows a multi-faceted approach to program content delivery governed by IXXO decentralized logicwhile maintaining document privacy

37 Solving ISSUE 7 Improve Data privacy

While private content external to blockchain smart contracts logic is organized bythe dAppBox P2P network tightly linked with the IXXO blockchain there is a need todeal with private data in application logic

In case of simple Zero Knowledge Proof use cases (where a function returns yesor no for example is my user under 18 ) some smart contracts already enable suchtests and IXXO will support those While on Ethereum such smart contracts have to bepre-compiled and cannot be run natively on the smart contract engine (thus are notdecentralized they are queried on specific addresses not deployed on every nodes) inIXXO we will enforce decentralized zero knowledge proof contracts

Most practical business use cases need algorithms with a returning value that ismore complex than YES or NO and for that only secured distributed computation canhelp In such frameworks several nodes compute an algorithm simultaneously on theirrespective data that remain private while the returned value becomes public at theend of the process

Since early 2017 IXXO has focused on creating a 2 node distributed computationengine Most of the practical use cases can be answered with 2 nodes collaborating ontheir respective private data finding common items in a list defining matches between2 profiles providing some image or document similarity finding similar documents in adatabase

IXXO initially delivered RockEngine in october 2017 a 2 Nodes distributed securedcomputation engine that can execute any algorithm written in Javascript on 2 remotenodes that have to be online (fig 113) Its performance has been improved since thento offer the best performance over memory size ratio among available open source


alternatives

Figure 31 Multiplying 2 private matrixes on 2 remote nodes with IXXO RockEngine

The challenge in building a secured privacy-preserving computation engine is thememory consumption As all operations and all steps in the algorithms are encryptedthe size of the algorithm in memory is significantly more than in its encrypted formsometimes 100 times more and everything has to remain in memory The RockEngine isable to cut this memory consumption by 3 on significant algorithms such as large matrixcomputation

MultiplicationAlgorithms

RockEngine Bestperformance

of otherframeworks

Improvement

16x16 matrix of64 bits integer

439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392

Open source competitive frameworks compared are listed in the technology section

The RockEngine presentation is available at httpsdappboxioRockchain_RockEngineGenericpdf while the RockEngine performance benchmark comparedto competing frameworks implementing secured computation is available at httpswwwrockchainorgRockEngine_Benchmark_V3pdf


IXXO is currently owning the full Intellectual Propoerty of RockEngine which is not yetopen source

IXXO wants to redesign its RockEngine framework to work inside the solidity engineBy doing so it will provide a software-based (as opposed to solutions based on theavailability of SGX hardware) private node to private node decentralized infrastructure

38 Solving ISSUE 8 Improve Blockchain security

381 Introducing PoA (Proof of Authority) protocolsA centralized PoA network is a network where a central authority chooses to include

new nodes in the current group of validators A famous example of such an approachis Ripple its RippleNet network being used for global international money transfers

A decentralized PoA network lets the community (ie existing validators) chooseto include or exclude a new node in their group IXXO implements this approach byproviding smart contracts for miners to vote on network extension or to ban somewrongdoing validators

Some might argue that PoA protocols are somewhat centralized preferring dPoS (del-egated Proof of Stake) such as for the Lisk Cosmos Network EOS and ARK blockchainsIt is to be remembered that in dPoS protocols nodes only vote to select block producersamong them A stake is only used to select a producer and the real consensus happenson a Proof of Authority level with a few selected block-producing nodes In the dPoSconsensus the staking mechanism ensures that producing nodes are doing an honestjob

382 The design of a consensusThe key point for achieving IXXO blockchain security is to trust the IXXO block-

validators nodes segregated into competing clusters

IXXO protocol offers the selection of 64 clusters The application user or the de-centralized application can choose which clusters validate the transactions Severalclusters can be selected at the same time For example the user can choose to validateits coming transaction by French bailiffs (Proof of Authority) American public notariesand a public blockchain (such as in a cosmos zone on tendermint) The first 2 clusterswill potentially bring legal value to the transaction while the latest public blockchain willbring anonymous confirmation

While the transaction might be validated only by some of the clusters once vali-dated it is accepted by all other clusters

Validating nodes must stake an amount guaranteeing the security of the clusters inan equal manner for each of the validating node Therefore they have a previous busi-ness deal to organize their cluster which fosters proof of authority consensus innovation

38 Solving ISSUE 8 Improve Blockchain security 25

among clusters Clusters can organize their consensus in the way they want (centralizedor decentralized PoA networks) or advertise and market their validating services theway they want (for example through voting and reporting smart contracts on the IXXOblockchain) Decentralized application builders are assumed to choose wisely whichvalidating clusters they would use for any type of operations on their apps

Specific blockchain statistical metrics (such as validating time or fraud detection)lead to the redistribution of all the staked amount of the faulty cluster or part of ittowards other competing clusters proportionally to their stakes Competing clustershave an incentive to monitor their peers for wrong doers in an auto-regulated process

Cluster punishment amount and metrics are voted using the governance proto-col described in the Deep dive in the technology section It involves both tokenholders and nodes in clusters As opposed to dPoS (delegated proof of stake) tokenholders do no vote to select validating nodes but votes for rules to exclude the faultyvalidating nodes

All clusters advertise their fees independently of each other and fees of all theselected clusters in a transaction are accumulated

Stakes guarantee the reservation of a slot in the 64 cluster slots available for aperiod of one year When the slot is released at the following year it goes to the higheststake

383 Risk of validating node collusion (51 attack)Decentralized applications could submit their transactions to many of the 64 avail-

able clusters which compete together for fees and slot availability and have internallya node distribution algorithm Building a collusion in such a disparate and competitivebusiness framework is at least as hard as preventing the current Proof of Work miningpool concentration

In addition once the fraud detected remaining honest clusters have an high incen-tive not to collude since they get the slot staked tokens from faulty clusters The strongerthe wrong doing colluding group the bigger the reward for honest nodes Knowing thisapplications should take small clusters in their validation requests that are not aligned ininterest to join any group of strong wrong doers

384 Fraud detectionIn the IXXO blockchain all clusters operate with absolute finality by design Finality

means that once a block is added on the blockchain it cannot be revoked Even ifsome clusters were based on public blockchains they would use final finality consensussuch as PBFT behind Cosmos Networks

Thanks to absolute finality there canrsquot be block-invalidating attacks revoking atoken spending from one address to some other typically the hacker one


For other live possible fraud attempts IXXO host observers nodes that will pe-nalize wrong doer clusters on detected behaviors This could also be done live assuggested by Vitalik Butterin in a recent (Augst 2018) proposal however IXXO does notneed the manage such a level of complexity as penalizing on staked tokens is enough

39 Solving ISSUE 9 Improve end user usability

IXXO has industralized blockchain node deployment on the cloud It uses Kuberneteson Azure Private keys are stored in a secured vault (Azure vault) similar to a LedgerHQdevice but on the cloud and all transactions are signed offline

Each blockchain user has his own running instance and only the user can access tohis private key and download it IXXO is unable to do so

As a result the decentralized application user can access a dedicated web serverrunning a blockchain node instance for his app and he cannot see the difference fromusual websites since he accesses his decentralized application under an URL such asdappnameiousername

On the dedicated user webserver (created ondemand through Kubernetes de-ployment automation) a crypto wallet is installed for the user to safely manage his owntokens independently from the application

310 Solving ISSUE 10 Reduce and stabilize fees

Clusters are competing together on fees They advertise fees twice a day to thenetwork (thus to all dApps)

dApps in their configuration (the CAS - Cluster Allocation Strategy see 1013) canselect the cluster with the smallest fee at any point in time

Stable fees are provided by healthy competition among clusters possibly lead-ing to segregation on specific use cases not perturbing other use cases in case ofcongestion (such as CryptoKitties)

311 Solving ISSUE 11 Increase usability for dApp developers

In its Ethereum fork IXXO adds the possibility to handle several balances for anunlimited number of tokens The balance function for native tokens is available in API(web3JS) and in solidity


Calling the balance of some token listed on IXXO

addressbalance(rsquoXXXrsquo)

A new transaction has been added to mint a new token type and only specificvalidating nodes can perform this initial mint transaction (a transaction-based tokenemission)

4 Market

41 The current state of the Ethereum dApps market

We analyzed the largest decentralization platform Ethereum to track the top de-centralized applications (DApps) (fig21)

Figure 41 dApps activity per category and per dApp thanks to Chris McCann

Most of the dApps activity are tracked by decentralized exchanges while theremaining are games and mostly ponzypyramid schemes (category Others) Amonggames CryptoKitties gets a third of the game dApp market Games and decentralizedexchanges represent 90 of the legally valid dApps For all those categories represent-ing 75 of the dApp market we have a total count of roughly 7000 daily active usersThe whole dApps user market size is about 3x10eminus6 of the cloud-based social mediamarket with Facebook and WeChat alone accumulating more than 2 billions activeusers daily


A small number of dApps account for almost all the activity while only 25of the dApps have more than 100 transactions in a week The Ethereum dApp ecosys-tem failed to be equally distributed and the dApp activity is highly centralized in lessthan 5 dApps (IDEX ForkDelta and CryptoKitties accounting for more than 50 of alldApp transactions) This is to be compared to the $10 billion market value of EthereumdApp tokens at the end of year 2017 valuing each active dapp user at at least $1 million

Ethereum dApp market is a highly speculative market valuing each active dAppuser at roughly $1 million at the end of 2017 A few dApps (less than 10) account for(more than 80 of all activity dApps activity are centered on games and decentral-ized exchangesBy covering all technical and usability requirements of decentralizedexchanges and decentralized games IXXO total addressable market is 100 of thelegally valid current Ethereum dApps market

42 IXXO use cases per content distribution model

1 Trusted collaborative workplaces


11 Share intellectual property with trustand automatic proofs of intellectualproperty and document transfers

12 Exchange emails with automaticprotections of your secrets

12 Give proven audited consent oragreement

2 Applications integration backbone

Hosts diligently required documents 21 Store privately regulatory docu-ments (insurance contracts risk as-sessment documents) and provesyou hosts them periodically

22 Entertainment distributed networkpay nodes to store big media files

3 Blockchain-based applications

Any decentralized application needingaffordability and usability fiat currencyusage tokenization

31 Surveys forms filling with tokenbased incentives

32 Security Token Offerings with specificliquidity providing features

33 Generation of legal documentswith legal proofs attached to theblockchain

30 Chapter 4 Market

43 Some examples of IXXO use cases per industry

The dAppBox can add several proofs to the distributed file system1 Proof of existence Prove that a file exists on your dAppBox at the time of genera-

tion2Proof of custody Prove periodically that a file exists on your dAppBox (ie your

dappbox hosts a file) 3 Proof of transmission Prove that a file has been transferredfrom one dAppBox to another

The RockEngine also enables an extra proof 4 Proof of instant execution provethat you executed some given algorithm diligently on your private data

This proofs lead to specific use cases per industry

Industry Use cases Other blockchain projects

Finance Track White papermodifications PerformKYC on proven private

documents

ICOs

Wills and Inheritance Release dAppBox contentaccess rights on proven

death certificate

Blockchain TechnologiesCorp

Health Care Share health data todoctors on accident

event

Gem Health Network

Data Storage Private file hosting serviceson the dAppBox network

FileCoin

Automobile Check a carmaintenance history

privately when looking tobuy

Volkswagen amp Daimler

Business and CorporateGovernance

Consolidate industrymetrics with no privacy

breach and companiesaccounting

Online sales Private auctions withRockEngine v2 (in

Community Edition v5)


44 Market size and trends

IXXO delivers the ability to decentralized centralized applications in a user friendlyway the market is all the applications that are rejecting the old centralized model for abetter ecosystem-based application model

Even after a crash of 90 of Ethereum value from its peak in January 2018 allmarket capitalization of all decentralization applications tokens on Ethereum is till morethen $2 billion 4 years only after Ethereum launch This immature market is yet to mature

45 Money raising through the blockchain

Figure 42 ICO token sales

An ICO as a way to raise money that has proven highly successful among start-upsand eventually grew bigger than the traditional venture capital fund raising for a while(fig 43)

Providing support for document hashing and proofs and legal value of blockchainoperations through different jurisdictions associated to cluster authorities IXXO can takeon a significant part of the token (security or utility) crowdfunding phenomena

IXXO provides several ways to improve an ICO process1 To track white paper termsheets and conditions versions of the documents on the

public dAppBox network to keep an historical assessment of what the project manage-ment is changing (available from version 2 Enterprise Edition)

2 To create content evaluation surveys of the white paper through the dAppBoxcontent assessment system (available from version 2 Enterprise Edition)

3 To perform KYC operations by our network of bailiffs operating nodes and validat-ing identities in a batch mode with reduced fees while KYC documents are shared inthe dAppBox network

4 To transfer raised tokens to other blockchains (available in the Business Editionfrom v5)

5 To have facilities to deploy their dApp using the dAppBox and IXXO cloud facilities

5 Revenue and go to market

51 Existing customers

3 customers trusted IXXO for their applications and 2 of them (SunnyLake and ValY-ooTrust) are dedicated to use IXXO as a long term technological partner for the choiceof the technical stack

Teralab is a leading European big data infrastructure provider specialized in in-dustrial data science It used the dAppBox on IXXO to add file transfer certificationsamong their customers peer users (Usage File transfer proofs)

SunnyLake is a startup building a collaborative and data-driven ecosystem for clini-cal research Connected internationally with big players in the field Sunnylake is thebrain studio aiming at creating a world-stage ecosystem for solving inefficiencies intesting producing and delivering drugs worldwide(Usage Content proof content as-sessment dApp automatic deployment on the cloud)

ValYooTrust (French project to be announced) is the first Innovation 40 Market Placebased on proven Trust amp Blockchain It brings many state-level institutions together tofoster innovation and value intellectual property directly in the processes technicalfoundations (Usage Content proof dAppBox API dApp automatic deployment on thecloud)

52 IXXO revenues

IXXO revenues comes from distributed cloud as a service

dAppBox Architect allows the creation of complex networks of dAppBoxes fordecentralized infrastructures

52 IXXO revenues 33

Figure 51 Pricing of dAppBoxes on IXXO registration site

When design a dAppBox network all dAppBoxes hosting costs will be cumulated in

Figure 52 The design of a dAppBox network with access rights

the global distributed network hosting pricing

Figure 53 Hosting custom open source components on a dAppBox network

Each open source has specific extra hosting costs and all open sources are synchro-nized through blockchain glue ie users management and access rights manage-ment

6 IXXO versus other blockchains

The design philosophy of IXXO is not to be the best in class in some specific highlytechnical features (for example having incredibly fast confirmation time) but to coverall required features for the blockchain to be usable in practical use cases

61 Features and performance

611 How IXXO brings performance

IXXO hosts all nodes on Azure Kubernetes optimizes network settings among nodesand benefits from Azure network optimization which has built-in network settings hardto replicate on public internet networks

612 Blockchain protocols and performance

Blockchain Block time (s) Consensus Smart contratlanguage

Scalability

Bitcoin 600(s) PoW none 4 tpsEthereum 15(s) PoW Solidity 20 tps ()Lisk 10(s) dPoS Javascript 25 tpsQtum 150(s) PoS Solidity 70 tps ()Ark 8(s) dPoS NodeJS Java

Python Ruby10 tps

NEO 15(s) PoS C Java 1000 tps ()Stratis 60(s) PoS C 20000 tpsCardano 20(s) PoS C 10-15 tpsEOS 05(s) dPos CC++ 1000 tps ()IXXO (atlaunch)

expected 3(s) MPoA Solidity 1000 tps

62 IXXO vs EOS 35

() Raiden was expected to bring Ethereum scalability to millions transactions per second in March 2018 but has not yet released its mainnet Its last

testnet update was 11th march 2018 Plasma and Sharding are other scalability projects but are more distant solutions

() With the lightning network offchain payment network it is expected to reach 20000 TPS within 1 year to 18 months

() Claimed by Da Hongfei NEOrsquos cofounder

() EOS will support 1000 transactions per second at start EOS developers expect progressive updates to reach 30000 TPS progressively

IXXO is well positioned in terms of confirmation speed (3 seconds block time)compared to others and can scale up to a few thousands transactions per secondusing the initial setup of 2 available clusters with 7 validators nodes each

613 Transaction confirmation timeConfirmation time is effectively a measurement of blockchain speed an essential

feature to get practical business applications

Figure 61 Transaction confirmation time for public blockchains

Thanks to Kubernetes cloud optimization IXXO block time can be 3 seconds atlaunch and can probably be reduced through cloud networking optimizations later on

62 IXXO vs EOS

EOS shows the huge community interest for a working alternative from Ethereumregarding the transaction prices scalability and block time

The EOS ICO was the biggest ever with $ 4 billions raised The EOS massive investmenton a consensus protocol that only rely on 21 operating nodes highlight the fact that ahigh number of mining nodes is not the solution for decentralization In fact it can be

36 Chapter 6 IXXO versus other blockchains

argued that concentration of mining power from Ethereum and bitcoin mining poolsmake those blockchain even more centralized than EOS and IXXO (fig 72)

Figure 62 Mining power decentralization on major blockchains May the 3rd 2018

62 IXXO vs EOS 37

EOS solves many Ethereum issues block time scalability and the ability to talk toother blockchains (InterBlockchain communications) It has also an improved gover-nance system for protocol updates EOS brings a strong framework of distributed rightsmanagement embedded in the blockchain such as for the dAppBox decentralizedpermission system

EOS does not solve practical usability needs for the users itrsquos focused on trans-action duration while transactions costs are free If transferring tokens for free is hard tocompete with hidden costs such as EOS account creation (up to $4 last month) havealso to be considered

EOS consensus and governance if very practical and its fees are cheap (not freeas advertised since hidden undisclosed costs do exist as described above) IXXO isa consensus plateform mostly based on PoA but also authorizing any instant finalityconsensus such as PBFT in a Cosmos Network zone

IXXO is a two-side platform with on one side dApp innovation (dApps compet-ing for users attention) and on the other side validating nodes innovation (clusterscompeting for dApp connection providing extra services such as document hostingand legal services)

As a two-sided platform ecosystem IXXO can foster integrated innovation bothsides and focus on infrastructure and economical model optimization

7 The delivery roadmap

71 Features-set planning

Lambda Edition (released 1 July)1 Blockchain with node status management (readonly trading only admin coread-

min)2 Proof of transfers proof or existence in dAppBox layer (with GUI and API)3 BIP39 folder identity management to provide custom access to content4 Advanced login features on dAppBox( choice of Metamask integrated decen-

tralized login) within a single framework5 Native token in Blockchain get balances in your token in your smart contract

Mint a new token onchain (new EVM opscode)6 Blockchain based access rights managementVega Edition coming1 MPoA protocol advanced business-validation of blockchain transactions intri-

cated into the protocol2 dAppBox V2 with totally secured and private decentralized webmail (in sending

of course but also in storage in authentication)3 Authenticated private data structures that can be moved from peer to peer (such

as surveys data tables etc)The Double Chi Edition1 Private P2P computation on 2 remote nodes

July 2019 middot middot middot middot middot middotbull Lambda

July 2020 middot middot middot middot middot middotbull Vega

July 2021 middot middot middot middot middot middotbull Double Chi

Table 71 IXXO delivery timeline

Bibliography

[1] Ethereum White Paper httpsgithubcomethereumwikiwikiWhite-Paper

[2] Cosmos Network httpscosmosnetworkaboutwhitepaper

[3] Lisk httpsdocsliskiov14docsthe-lisk-protocol

[4] IPFS httpsipfsio

[5] NameCoin httpsnamecoinorg

[6] Enigma Catalyst httpswwwenigmaco

Glossary

Bitcoin Bitcoin is a cryptocurrency a form of electronic cash It is a decentralized digitalcurrency without a central bank or single administrator 11

Ether Ether is a cryptocurrency whose blockchain is generated by the Ethereum plat-form 11

Ethereum Ethereum is an open-source public blockchain-based distributed computingplatform and operating system featuring smart contract (scripting) functionality 411 16 21 28 29

KYC Know your customer (alternatively know your client or rsquoKYCrsquo) is the process of abusiness verifying the identity of its clients and assessing potential risks of illegalintentions for the business relationship 31

8 Annex 1 Deep dive in the tech

81 The MPoA protocol

811 Accounts and clusters trustEthereum accounts have an intrinsic balance transaction count and (possibly

empty) EVM Code They represent smart contracts or individual Ethereum accounts

In the IXXO Ethereum fork it is possible to associate trusted clusters authorizations toaccounts You can define which transactions the account can accept coming from theoutside (Inbound transactions) You can also define the same type of rules for outboundtransactions (from the account to externals accounts)

Once an account has its policies rules implemented the validating nodes rejects oraccepts new transactions sent by the account or received by the accounts accordingto the rules

812 Transactions stored on the IXXO blockchainEthereum transactions stored on the blockchain contains the following fields

1 Nonce the number of transactions sent by the sender2 gasPrice the number of Wei to be paid per gas for all computations in the current

transaction3 gasLimit the maxiumum amount of gas to be used by the blockchain4 to the blockchain address of the recipient5 value the number of wei to be received by the recipient6 init (for smart contract creation only) EVM code to be executed at smart contract

creation - unlimited size7 data message for transaction call - unlimited size8 Some EDSCA signature to identify the sender

42 Chapter 8 Annex 1 Deep dive in the tech

IXXO will add 2 new data fields

9 8 bytes to the Ethereum transaction data structure (which minimal size is about100 bytes) to identify on which of the 64 clusters the transaction has been validatedOne single bit defines whether a cluster has validated the transaction or not therefore 8bytes are enough for all clusters

10 2 bytes to identify the token type It can be 0 for the IXO token or otherdApp registered tokens on the IXXO blockchain (up to 8191)

813 Accounts cluster trust policiesAccounts can define which clusters they trust for inbounds and outbounds transac-

tions They can ask that their transactions be validated by several clusters at the sametime (AND cluster association) They can also choose a validation on only one of thecluster among a group of clusters which is chosen to be the one with the lowest fees forthe transaction at the time of the transaction execution

All clusters associations in this context would lead to 264 possibilities 18 billions ofbillions something impossible to store on a blockchain To reduce the size of the con-figuration while allowing full flexibility for the account user to define a security and feeoptimization strategy we define the following data structure (named CLUSTER ALLOCA-TION STRATEGY the CAS)

1 Transaction direction Can be INBOUND or OUTBOUND - 1 bit2 An ordering of all the 64 clusters A cluster number can be coded on 6 bits the

ordering takes 48 bytes3 8 identical blocks of 8 bytes containing

31 8 bits defining 8 clusters chosen following the order of list 232 1 bit defining if all clusters should validate the transaction or only the cluster

with the cheapest fee (AND or OR strategy)4 A single bit which defines if groups of clusters define in 3 should be put in compe-

tition or all validate the transaction (AND or OR strategy)

Using this approach the account owner have an important flexibility of choosinghow to optimize his fees and other associated services for only a CAS size of 58x2=116bytes

814 Fine tuning fees expensesIt is also possible to send a unique transaction with a CAS message associated In

case the account sending the transaction has no CAS associated it will be allowed withthe given CAS If however it has already once CAS the transaction CAS should be fullycomplaint with the account CAS not to be rejected (having more clusters validationrequired not less)

82 dAppBox internals 43

Applications in IXXO can customize the CAS for all their users accounts in a webadministration interface provided by IXXO cloud facilities

815 Virtual Machine verificationThe first version of the MPoA protocol will validate transactions at their first level only

it will check if the validation of the inbound or outbound transactions are compliantwith the account policY

However it might happen that some previous transactions from which the remoteaccount balance accounts through token holding were done in clusters outside thecurrent account CAS The remote account token balance would then appear partly ortotally illegitimate Operations without tokens transfers are not impacted by this issue(such as proofs or smart contract data storage)

In version 2 all past transactions in history will be checked and if a single trans-action fails to comply to the current CAS the transaction will not be accepted Version1 or Version 2 protocol could be switched ONOFF on the CAS by the account user thusallowing stricter or lesser verification of historical provenance of the tokens dependingon the chosen configuration

This historical provenance conformity will be applied to both native IXO tokensand all others registered dApp tokens on the 8192 slots

816 Balance structure optimizationAll accounts balances are stored in a size optimized structure taking into account

only balances with non zero amount of tokens

82 dAppBox internals

The dAppBox is a peer to peer network infrastructure both for publicusage (documents storage is permanent and public) and private usage(documents are stored on the network and their presence (hash) is certifiedon the blockchain

The dAppBox is a P2P network where all the user files are only stored in devicesowned by the user In order to facilitate the integration of the dAppBox with the IXXOblockchain nodes IXXO cloud services can deploy the user P2P node on the cloudwhile still guaranteeing that only the user can access this cloud-hosted P2P node

In order to upload local files to the remote P2P personal node hosted on thecloud a local software (in the user task bar) can synchronize local folders with theremote personal dAppBox Currently this local tool (called the dAppBox client) is avail-able for Windows and Linux


The other features of the dAppBox are

1 block level file copying Files differences only are synchronized guaranteeingperformances similar to dropbox (also implementing it)

2 File versionning dAppBox keeps track of file versions and associated IXXO proofsare stored on the blockchain so we not only have proof of authorship but also ofdocument editing (who what when)

3 API dAppBox keeps track of file versions and associated IXXO proofs are stored onthe blockchain so we not only have proof of authorship but also of document editing(who what when) It is perfect for collaboration on large files as only the difference issynchronized between nodes

821 The dAppBox access rights systemThe dAppBox maintains content folder level access rights on the blockchain vThe dAppBox features descriptions are available at dappboxio while there is an

old version demo video at First dAppBox alpha release october 2017

Figure 81 The dAppBox GUI

83 RockEngine Computation on private data

RockEngine is a generic Javascript compiler and script execution en-gine It is decentralized by design a RockEngine script runs on 2 nodessimultaneously RockEngine respects nodes data privacy by design


831 Step by step proofs for total algorithms accountability on private data

The true challenge of performing computation on private data is providing proof-of-instant-execution on the private datanode ie ensuring the correct computation hashonestly been done

RockEngine brings software accountability by keeping proofs of what has beenexecuted (with detailed execution paths in the algorithm) at any time (tracked inblockchain block times) by who (given some blockchain identity)

Proofs provided by the RockEngine API Description

Proof-of-instant-execution Describe the complete execution pathsof some given algorithm and store the

merkle root in the IXXO blockchainProof of caller identity Describe who ran the algorithmProof of algorithms input and output Keep a proof of the algorithm input and

output data in the blockchain for eachalgoritm execution (run)

We released a first benchmark on RockEngine performance comparing it to otheropen source framework implementing Yaorsquos Garbled protocol on 26th october 2017and improved the compilation time and execution time since

832 RockEngine strengths and upcoming challenges

The major benefit of RockEngine is its complexity abstraction of the Yaorsquos GarbledCircuit protocol which is otherwise very complex to handle

The new challenges to be met is to switch from Javascript algorithms to Solidityalgorithms and to integrate RockEngine in the IXXO blockchain smart contract en-gine in order to switch transparently from private computation to public blockchaincomputation in the same solidity smart contract script

84 IXXO governance

Debates about blockchain governance involves onchain governance practicesand offchain governance practices

Offchain governance practices let the miners vote for protocol updates crafted bya team outside the blockchain operations Miners could ignore any new proposal (or socalled forks) and continue working on the old version or switch to the new one in thatcase the miners majority will determine the valid chain Ethereum (the current versionbefore Proof of Stake) and Bitcoin use such an approach

Onchain governances practices let blockchain users vote on new features for theblockchain possibly using their amount of coins as a voting weight


Onchain governance came along with new blockchains (Tezos Dfinity) EOS tried tomerge the two approaches by having 3 groups collaborate on deciding the protocol(block producers EOS governance team and token holders constituting the 3 groups)but this led to severe issues and a stalled governance at launch

Two issues with onchain governance are noticed1 As in a plutocracy token-rich voters decide the blockchain future it is centralized

by token-wealth2 Onchain users can arrange to disenfranchise node operators and lower their fees

It is like asking consumers to vote to define supermarkets margins

Offchain governance also suffers from 2 issues1 The onchain users community cannot oppose to a decision taken by offchain

members (largely influenced by the blockchain foundation usually) to update the pro-tocol

2 Miners who can vote are in reality rarely contributing to votes

IXXO in Lambda Version improves POA protocol with onchain node status gov-ernance

MPOA keeps the same spirit but with decentralized onchain governance by clusterseach cluster being specialized into a specific business focus

9 Annex 2 Benchmarking RockEngine

RockEngine is a Boolean circuit compiler meant to be part of the secret smart con-tract Engine developed by Rockchainorg

The secret smart contract Engine is a complete garbled circuit ecosystem thatwill be used inside IXXO smart contract Virtual Machine to perform secure functionEvaluations on private dAppBox data

RockEngine secret smart contract aims to be simple to use while providing per-formances comparable to state-of-the-art compilers which are currently developed forresearch purposes

91 Introduction

Garbled circuits are today the most flexible solution to perform secure function eval-uation (SFE) ie computation of a function whose inputs come from different partieswhich are not willing to share their data with one another

The representation of the function as a Boolean circuit is a basic requirement for SFEto work The principle used by most applications dedicated to garbled circuits is thata high-level representation of a function is pre-compiled into a clear (not encyrpted)Boolean circuit

1 The first party Alice turns this clear circuit into a garbled circuit and encrypts herown input

2 The second party Bob uses oblivious transfer to get his encrypted input from Alice3 They can finally evaluate the function Alice sends the garbled circuit and her

encrypted input to Bob so that he could perform the computation

48 Chapter 9 Annex 2 Benchmarking RockEngine

Garbling and execution of the circuit are usually made in a single step since tra-ditional garbled circuits cannot be safely reused Every time we need to evaluate afunction we use the same Boolean circuit to create a new garbled circuit with newkeys

IXXO secret smart contract engines knowing shared folders addresses of dApp-Box engines will send new garbled circuits to computation end points for every newsmart contract computations

The construction of Boolean circuit is a necessary step We are looking for opti-mal Boolean circuits which are the smallest circuits able to fully represent the givenfunction in order to minimize the computation time on both sides and the bandwidthused in transmitting the circuit That is where RockEngine optimization effort was put

As garbled circuits are still the subject of active research there is still no comprehen-sive and user-friendly solution available to use garbled circuits

IXXO rsquos secret smart contract Engine is meant to solve this problem It providesboth a compiler to create Boolean circuits named RockEnginebuild and an executornamed RockEnginerun

92 State of the art

Several solutions already exist to create Boolean circuitsbull Fairplay 2004 Malkhi et al 2004 which was the first practical implementation of a

generic Boolean circuit compiler and inspired subsequent works It uses a customC-like language as input SFDL

bull TASTY 2009 Henecka et al 2010 It contains tools for both garbled circuits andhomomorphic encryption It uses the Free XOR and row reduction techniqueswhich become standard in garbled circuit researches

bull PAL 2012 It uses SFDL too with considerable optimizations compared to Fairplaybull CBMC-GC 2012 Holzer et al 2012 It uses ANSI C as an input and outputs circuits in

a text format This gives it a compatibility advantage but it has large output filesbull KSS 2012 Kreuter Shelat and Shen 2012 Authors built their garbled circuit software

to show that evaluation of billion-gate circuits is feasible in the malicious model(where in particular the circuit sent could not be the right one)

bull PCF 2013 Kreuter et al 2013 which has LCC as an input format and outputs circuitto a condensed format

bull OblivVM 2015 Liu et al 2015 which compiles inputs into Java files and then usesthe Java virtual machine optimizer

bull OblivC 2015 Zahur and Evans 2015 aims at providing an almost exhaustive range ofprogramming tools to compile Boolean circuits like oblivious RAM while remainingaccessible

bull TinyGarble 2015 Songhori et al 2015 Its compiler is an auxiliary application whichgenerates circuits from verilog files The TinyGarble executable is an improved


version of the program JustGarble which solely performs garblingbull Frigate 2016 Mood et al 2016 which focuses on overcoming problems of speed

and correctness encountered by previous compilersbull CBMC-GC v20 2017 Franz et al 2014 is an optimized version of the software

compiler released in 2012 It outputs less gates than before and its extensionShallowCC provides depth reduction in the circuit

Coding for Boolean circuits is particularly compelling in several ways that have notbeen overcome yet for example the circuit must be bounded which implies that thenumber of iterations for a loop must be decided at compilation time Ethereum SolidityEngine has the same constraints for gas cost assessments thus Solidity is particularlysuited for garbled-circuits meta-description

The most important property regarding the compilation of the circuit is the sizeof the circuit produced which we can break down into four parameters

1 the number of XOR gates which are quick to evaluate during the execution2 the number of non-XOR gates which are the most resources consuming3 the number of wires used which will have a direct impact on the memory used by

the machine performing the later evaluation of a garbled circuit4 the size of the file containing the circuit which depends on the number of gates

and the format used to encode the circuit

When compiling Boolean circuits there is no possibility of hardware-based optimiza-tion as during a classical compilation Thatrsquos why the compilation of Boolean circuitoperates on an abstract layer and is usually much slower than usual program com-pilation The speed factor compared to a standard non-garbling compiler is indeedrelevant to compare different compilers

In Mood et al 2016 Frigatersquos author review PAL KSS CBMC PCF Obliv-C and OblivMThey highlight several flaws and compare them to their own solution Frigate appearsto be significantly faster than other solutions with compile time speedups up to 447xcompared with best previous results while producing circuits with similar gate counts Italso adds its own new functionalities

The latest compiler released CBMC-GC v20 focuses on reducing the number ofgates and the depth of the circuit It starts by writing the circuit a first time beforeperforming an optimization phase In Buescher et al 2017 several authors of CBMC-GCbenchmark their new version with comparisons to Frigate TinyGarble and Obliv-C Theyshow significant improvements for some algorithms in terms of number of gates and sizeof the files produced

In this annex we compare Rockengine to Frigate and CBMC-GC whenever possiblegiven that those two compilers appear to be the most efficient and user-friendly existingsolutions


93 Use cases

94 Genericity

IXXO rsquos Rockengine focuses mostly on usability so that anyone could operate on a circuitwithout going himself through the decoding of a binary file or using a garbling specificlanguage which are tedious The secret smart contracts exploits efficient features of theGo language to encode files and use JavaScript in its first version as an input languageto maximize the number of people able to use it

With the difficulty of controlling infinite loops and other non-Turing complete abstractsin Javascript Rockengine v2 (the secret smart contract engine) is rewritten to use solelySolidty as an input language Solidity being close to Javascript

941 Compiling scripts from an extended JavaScript (RockEngine v1) and Solidity (Rock-engine v2)RockEngine v2 will be available in the Community Edition v5

Letrsquos RockEngine v1 syntax with Frigate and CBMC-GC

For each of the three compiler we provide a basic code sample to resolve Yaorsquosmillionaires problemThis problem which is at the origin of garbled circuits theory is the following two million-aires argue about which one of them is the richest but they donrsquot want to tell eachother the exact amount of money the own

Just solving Yaorsquos millionnaires problem can lead to the ability to conduct privateauctions in a distributed smart contract context along with many other use cases

Yaorsquos millionnaires problem is typically a case where Secure Function Evaluation isvery useful In this case the solutions is a simple SFE with a comparison operator

Listing 91 Millionairesrsquo problem with Rockengine v1$parties = 2$intsize = 16

in_0 = 0in_1 = 0out_0 = in_0 gt in_1

Listing 92 Millionairesrsquo problem with Frigatefine wiresize 32rties 2

edef int_t wiresize intedef uint_t 1 bool

94 Genericity 51

put 1 intput 2 inttput 1 bool

ction void main() output1 = input1 gt input2

Listing 93 Millionairesrsquo problem with CBMC-GCclude ltinttypeshgt

edef int32_t InputAedef int32_t InputBedef uint8_t Output

put mpc_main(InputA INPUT_A InputB INPUT_B) return INPUT_A gt INPUT_B

JavaScript is already very straightforward compared to the other two syntaxesRockEngine v1 uses a syntax such that each input or output is prefixed by either in_x

or out_x where x is the number of the party linked to this variableThe Rockengine compiler simply understands that the wires of all variables whose

names define as outputs should be output to the corresponding parties

RockEngine v1 offers a wide compatibility with many input parameters types suchas Matrixes While it is intended to be ported to Solidity we expect the solidity languageto extend its type system in order to solve business uses cases more easily and in thatcase RockEgine would easily embrace new Solidty types

942 Installing and using RockEngine v1An example of how to use the current RockEngine

1 download the RockEngine repository2 go to the RockEngine folder and compile the main executable with

nstall

3 go back to your gopath (where you installed Go) and compile your first circuit likethis

nRockEngine pathToMyFilemyFilejs

The last command line will output a single file with a ssc (secret smart contract) extensionin the folder of your JavaScript file

Output management has been greatly simplified over open source alternatives suchas Frigate which generates one file for every function as well as a set of other statisticaland information files or CBMC-GC with eleven files produced

On that point RockEngine is fairly easy to use compared to Frigate which createsat least two files one with general information and statistics another for function main


plus one for every other functionIn CBMC-GC the compilation is made with a makefile and systemically outputs many

different files nine text files an executable and a C++ code with the whole representa-tion of the circuit

943 RockEngine integration with dAppBox and IXXO

RockEngine create go objects representing compiled garbled circuits from Javascriptfiles (v1) or Solidity files (v2)

port githubcomAlphaDinoRCRockEnginev1compiler

r circuit pcCircuit = compilerCircuitFromJS(myFilejs)


r circuit pcCircuit = compilerCircuitFromJS(myFilesol)

It is then easy for the dAppBox (written in GO) to use a forwarded one-time gar-bled circuit from a scc file and map local data to it The blockchain synchronizedboth dAppBoxes with block time to run the circuits concurrently resulting in secureddistributed private computations with results proofs and proof-of-instant-execution onthe blockchain

port pc githubcomIXXO RockEnginecircuitInterpreter

r circuit pcCircuit = pcRetrieveFromFile(myFilescc)rcuitin_param1 =1rcuitin_2=param1r result = circuitout_param

95 Technical improvements

951 Test panel

To assess the efficiency of the three selected algorithm we use a test-panel composedof standards algorithm multiplication of large integers and multiplication of matricesThe detail of those algorithms is as followsAlgo 1 16times16 matrices multiplication with 64 bits integersAlgo 2 32times32 matrices multiplication of 64 bits integersAlgo 3 64times64 matrices multiplication of 64 bits integersAlgo 4 256 bits integer multiplicationAlgo 5 1024 bits integer multiplication

In this section we only compare RockEngine with Frigate given that CBMC-GC is notable to perform the required computations within a reasonable time limit (to compile

95 Technical improvements 53

the first algorithm alone the time required is more than an hour)

As the time complexity with matrix multiplication of size 64 is two order of magnitudebigger we consider that CBMC-GC could not be considered as a viable solution forsuch complex calculations at the time being

Moreover it only accepts standard C types which means that we cannot use inte-gers of arbitrary length and algorithms 4 and 5 cannot be used

We also tried to compare RockEngine with TinyGarble but the compilation failedand Songhori et al 2015 suggests that the authors themselves could not benchmarkmatrix multiplication with sizes 16 and above

Overall our tests suggest that apart from RockEngine Frigate is the only compilerable to deal with multiplication of large matrices or very large integersThose are the kind of calculations we are interested in in a commercial use perspectiveand thatrsquos why we compare only to Frigate in this section

Speed performances

Speed is an important matter for compilers for every circuit small enough to be laterexecuted we expect the initial compilation time to be reasonable

Results for this test are given in table 91Testing machine usedbull CPU Intel Core i5-6200U (Dual Core - 23 GHz 28 GHz Turbo - Cache 3 Mo - TDP

25W)bull RAM DDR4 8 Go 2133 MHzbull SSD 120 Go M2 - SATA 6Gbsbull OS GNU Linux x86_64 kernel 4100-32-generic Xubuntu 1704We can observe that RockEngine in its current version is efficient for matrix calculus

but not very efficient yet compared to Frigate in sheer unknown big numbers multiplica-tion RockEngine optimizes the complexity of complex algorithmic problems throughcircuit redesigned and is therefore particularly adapted to real business use casescenarios

952 Optimization of the output circuit

We measure the quality of the output of the three compilers according to the criteriadefined in 92

File size

First we compare the sizes of the files produced which contain the circuits The resultsare given in table 92

On that point it appears that RockEngine brings significant improvements comparedto Frigate in particular for matrices multiplication


Number of wires usedThe second factor that we measure is the number of wires used Those results are givenin table 93 As we can see RockEngine has been optimized in order to minimize thosenumbers which are significantly lower than Frigatersquos

Number of gatesThe number of gates is the most important factor to measure as it determines thenumber of operations to be transmitted and performed during the execution This is alsothe most commonly used indicator

The results are given in table 94 We can observe that RockEngine and Frigate aregenerally similar on gate counts

96 Benchmark conclusion

As we saw in section 95 the first version of RockEngine succeeds at providing perfor-mances comparable or better than the best in the field the Frigate compiler by far thefastest of state-of-the-art compilers available

In addition RockEngine redefines the developer usability level for private computa-tion

97 Bibliography

Buescher Niklas et al (2017) On Compiling Boolean Circuits Optimized for SecureMulti-party Computation

Franz Martin et al (2014) ldquoCBMC-GC An ANSI C Compiler for Secure Two-Party Compu-tationsAEligrdquo In Compiler Construction 23rd International Conference CC 2014 Heldas Part of the European Joint Conferences on Theory and Practice of Software ETAPS2014 Grenoble France April 5-13 2014 Proceedings Vol 8409 Springer p 244

Henecka Wilko et al (2010) ldquoTASTY tool for automating secure two-party computationsrdquoIn Proceedings of the 17th ACM conference on Computer and communicationssecurity ACM pp 451ndash462

Holzer Andreas et al (2012) ldquoSecure two-party computations in ANSI Crdquo In Proceedingsof the 2012 ACM conference on Computer and communications security ACMpp 772ndash783

Kreuter Benjamin Abhi Shelat and Chih-Hao Shen (2012) ldquoBillion-Gate Secure Compu-tation with Malicious Adversariesrdquo In USENIX Security Symposium Vol 12 pp 285ndash300

Kreuter Benjamin et al (2013) ldquoPCF A Portable Circuit Format for Scalable Two-PartySecure Computationrdquo In USENIX Security Symposium pp 321ndash336

Liu Chang et al (2015) ldquoOblivm A programming framework for secure computationrdquoIn Security and Privacy (SP) 2015 IEEE Symposium on IEEE pp 359ndash376

Malkhi Dahlia et al (2004) ldquoFairplay mdash a secure two-party computation systemrdquo InUSENIX Security Symposium pp 287ndash302

97 Bibliography 55

Mood Benjamin et al (2016) ldquoFrigate A Validated Extensible and Efficient Compilerand Interpreter for Secure Computationrdquo In IEEE European Symposium on Securityand Privacy

Songhori Ebrahim M et al (2015) ldquoTinygarble Highly compressed and scalable sequen-tial garbled circuitsrdquo In Security and Privacy (SP) 2015 IEEE Symposium on IEEEpp 411ndash428

Zahur Samee and David Evans (2015) ldquoObliv-C A Language for Extensible Data-Oblivious Computationrdquo In IACR Cryptology ePrint Archive 2015 p 1153


Algorithm RockEngine Frigate

Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s

Table 91 Compared average speed of RockEngine and Frigate on the test panel


Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo

Algo 3 141 Mo 553 Mo

Algo 4 29 Mo 31 Mo


Table 92 Compared size of the output on the test panel


Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240

Table 93 Compared numbers of wires used for each test

97 Bibliography 57

AlgorithmRockEngine Frigate

XOR Non-XOR XOR Non-XOR

Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557

Table 94 Compared numbers of gates used for each test

Lambda Vision positioning

Mission statement

Economical Context

History of the blockchain

IXXO offering overview

11 issues blocking user adoption

ISSUE 1 Transaction prices and duration on programmable blockchains

ISSUE 2 Massive energy waste

ISSUE 3 Everyday users still prefer everyday fiat currencies for services

ISSUE 4 Flat fees for all

ISSUE 5 Data storage costs

ISSUE 6 Document accessibility in blockchain logic

ISSUE 7 User data privacy issues

ISSUE 8 Blockchain security

ISSUE 9 Low usability for end users (browser side)

ISSUE 10 Fee volatility

ISSUE 11 Low Utility for dApp developers

Solving issues

SOLVING ISSUE 1 Ensuring low transaction costs and duration

Solving ISSUE 2 Reducing energy waste (1000000 time cheaper)


Solving ISSUE 4 User selected fees

Solving ISSUE 5 Reduce data storage costs

Solving ISSUE 6 Improve documents accessibility

Solving ISSUE 7 Improve Data privacy

Solving ISSUE 8 Improve Blockchain security

Introducing PoA (Proof of Authority) protocols

The design of a consensus

Risk of validating node collusion (51 attack)

Fraud detection

Solving ISSUE 9 Improve end user usability

Solving ISSUE 10 Reduce and stabilize fees

Solving ISSUE 11 Increase usability for dApp developers

Market

The current state of the Ethereum dApps market

IXXO use cases per content distribution model

Some examples of IXXO use cases per industry

Market size and trends

Money raising through the blockchain

Revenue and go to market

Existing customers

IXXO revenues

IXXO versus other blockchains

Features and performance

How IXXO brings performance

Blockchain protocols and performance

Transaction confirmation time

IXXO vs EOS

The delivery roadmap

Features-set planning

Annex 1 Deep dive in the tech

The MPoA protocol

Accounts and clusters trust

Transactions stored on the IXXO blockchain

Accounts cluster trust policies

Fine tuning fees expenses

Virtual Machine verification

Balance structure optimization

dAppBox internals

The dAppBox access rights system

RockEngine Computation on private data

Step by step proofs for total algorithms accountability on private data

RockEngine strengths and upcoming challenges

IXXO governance

Annex 2 Benchmarking RockEngine

Introduction

State of the art

Use cases

Genericity

Compiling scripts from an extended JavaScript (RockEngine v1) and Solidity (Rockengine v2)

Installing and using RockEngine v1

RockEngine integration with dAppBox and IXXO

Technical improvements

Test panel

Optimization of the output circuit

Benchmark conclusion

Bibliography

OverviewIXXO (a brand of Lambda Vision) is an integrated stack to tokenize trade and

track digital and financial assets in decentralized collaborative networks decentralizedtrading exchanges decentralized teams decentralized access rights decentralizedwebmails platform linked to auditable proofs

We provide a unique API to simplify development blockchain operations file ex-change operations email backend proof management token exchanges and tradingkeys management

Our focus is usability Your opportunity is a unique API to answer all your decen-tralized serverless needs

Contents


















3 Solving issues 18












4 Market 28








52 IXXO revenues 32



62 IXXO vs EOS 35



5







91 Introduction 47


93 Use cases 50





97 Bibliography 54














decen-tralized

exchange

Remotepayment



Fast blocktime 5s

Low energycost


Proofof Files

Existence

Proofof Files


experience

Onchainaccessrights

Privacypreserving

scripts


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

Contents


















3 Solving issues 18












4 Market 28








52 IXXO revenues 32



62 IXXO vs EOS 35



5







91 Introduction 47


93 Use cases 50





97 Bibliography 54














decen-tralized

exchange

Remotepayment



Fast blocktime 5s

Low energycost


Proofof Files

Existence

Proofof Files


experience

Onchainaccessrights

Privacypreserving

scripts


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

3 Solving issues 18












4 Market 28








52 IXXO revenues 32



62 IXXO vs EOS 35



5







91 Introduction 47


93 Use cases 50





97 Bibliography 54














decen-tralized

exchange

Remotepayment



Fast blocktime 5s

Low energycost


Proofof Files

Existence

Proofof Files


experience

Onchainaccessrights

Privacypreserving

scripts


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

5







91 Introduction 47


93 Use cases 50





97 Bibliography 54














decen-tralized

exchange

Remotepayment



Fast blocktime 5s

Low energycost


Proofof Files

Existence

Proofof Files


experience

Onchainaccessrights

Privacypreserving

scripts


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography














decen-tralized

exchange

Remotepayment



Fast blocktime 5s

Low energycost


Proofof Files

Existence

Proofof Files


experience

Onchainaccessrights

Privacypreserving

scripts


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography


DAPPS DAPPBOX APP


SURVEYMANAGER


SERVICELAYER

LOGICACCESS

RIGHT APIPAYMENT



LAYER











Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography








Centralizedcrypto

exchanges

Cost ofdata

storage


duration

Usability

Energeticsystemic

cost

Economicalissues

Token pricepump and

dump


tices


gover-nance


No af-fordable


for startups

Userprivacy

No legalvalue of

smartcontracts

Privacy issues

Undisclosedfounders

trades

Blockchainroadmaps

poorlydisclosed


documentsare public

Tokenomicsissues


Feesvolatility


IT Security issues

51 attack

















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography
















Stripe Paypal

$100 29 of $1=29₡ 5 of $1=5₡

$500 29 of $5=145₡ 5 of $5=25₡


















B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography











B2 Cloud Storage

0004 0002 0005
























Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography



















Dash DASH $115 B X11 2 PHs $9747 23























3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography



















3 Solving issues











IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography


IXXO

Cluster 1 (fees 1)

Cluster 2 (fees 2)

Cluster 3 (fees 3)

Cluster 4 (fees 4)

Cluster 5 (fees 5)


















The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography











The dAppBox network










Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography







Goal 2 Traceability




Goal 3 Usability
























alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography
















alternatives





of otherframeworks

Improvement


439 Kb 34 Mb 793


23 Mb 134 Mb 582


141 Mb 553 Mb 392













































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography











































4 Market






















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography


















30 Chapter 4 Market









documents

ICOs


death certificate



event

Gem Health Network


FileCoin





























52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography





















52 IXXO revenues



52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

52 IXXO revenues 33














Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography








Scalability


Python Ruby10 tps



62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

62 IXXO vs EOS 35











62 IXXO vs EOS






62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography




62 IXXO vs EOS 37



















Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography














Bibliography







Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

Glossary

































































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography





























































84 IXXO governance


















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography















91 Introduction












92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography







92 State of the art

























93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography















93 Use cases

94 Genericity









in_0 = 0in_1 = 0out_0 = in_0 gt in_1



94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

94 Genericity 51












nstall



















951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography














951 Test panel









Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography







Speed performances







File size










97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography








97 Bibliography









97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

97 Bibliography 55






Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography



Algo 1 0159 s 0344 s

Algo 2 1534 s 2459 s

Algo 3 1863 s 1836 s

Algo 4 0181 s 0022 s

Algo 5 251 s 0179 s



Algo 1 439 ko 34 Mo

Algo 2 23 Mo 134 Mo


Algo 4 29 Mo 31 Mo




Algo 1 66 050 147 630

Algo 2 262 722 589 998

Algo 3 1 049 154 2 359 476

Algo 4 2 050 2 560

Algo 5 8 194 10 240


97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

97 Bibliography 57



Algo 1 34 099 200 16 785 410 33 492 993 16 785 412

Algo 2 272 793 600 134 283 266 267 157 505 134 283 268

Algo 3 2 181 824 512 1 074 266 114 2 134 114 305 1 074 266 116

Algo 4 130 052 65 285 131 333 65 285

Algo 5 2 093 060 1 047 557 2 098 181 1 047 557



Mission statement

Economical Context















Solving issues












Fraud detection




Market







Existing customers

IXXO revenues






IXXO vs EOS




The MPoA protocol







dAppBox internals





IXXO governance


Introduction

State of the art

Use cases

Genericity





Test panel



Bibliography

a brand of Lambda Vision Assets and trust tokenization · Assets and trust tokenization White Paper...

Documents

Transcript of a brand of Lambda Vision Assets and trust tokenization · Assets and trust tokenization White Paper...