I N D E X P R O T O C O L

New Generat ionB lockchain P ro ject

CONTENTS

Roadmap 3

Unvei l ing A Cut t ing-Edge Blockchain 4

A Blockchain With Real-World Use Cases 5

The Era Before Index Protocol 6

Index Protocol: The Mission 8

Index Protocol and Global Adopt ion 10

Fast-Paced Transact ion Processing 11

Greenhouse Fr iendly 11

Index Protocol; the Touchstones 12

Neural Consensus Algor i thm 13

On-chain and Of f-chain Comput ing Shar ing 16

Adapt iveDatabase 18

Micro service Structure and Funct ional API 20

Rol lback (Adjustable feature only on request) 22

Biometr ic data as seed for E lectronic Signature 23

Coherence of Transact ional Model 24

Seamless Data Flow 26

Proven Mul t i-Chain Networks 28

Developer Integrat ions for Java and Programming 30

Languages of Common Use

Immediate Steps

Languages of Common Use

A Walk-Through

Index Protocol

32

32

33

3

3

PAGE

ROADMAP

2019Q1

2019Q2

2019

Q32019

Q42019

Q12020

Q22020

Q32020

Q42020

Rel iab i l i t y and demonstrab le safety should be the ha l lmarks of the f ront l ine prota-

go-n is ts of the B lockcha in phenomenon. The assoc iated af teref fects of b lock min ing in

today ’ s wor ld i s a huge demand for comput ing power , env i ronmenta l degradat ion, and

s low pace of t ransact ions . Whi le t ransact ion costs remain h igh for the most part , there

i s an imbalance in the he ight of technologica l progress in re lat ion to opt imal serv ice

de l i very .

Poor t ransact ion process ing t imes ar i se f rom the use of processors of l imi ted output

and capac i ty . By s t i ck ing to the s tatus quo, the wor ld i s so ld a dummy; as an opt ion

ex i s ts in faster B lockcha in vers ions in quantum process ing. In the same ve in , the

bu i l t - in safety mechanism of consensus approva l before major dec i s ions are made on

the B lockcha in a l so s lows the t ransact ion process ing rate . Th is appl ies to both the

Proof of Stake and Proof of Work modes.

The B lockcha in i s a network of interconnected th ings that makes i t poss ib le for data

update f rom connected termina ls . As data gets updated, the ent i re network goes into

a rescan, lead ing to a s lowdown and consumpt ion of more comput ing power and s tor -

age. Th is observat ion i s what makes the B lockcha in present ly inadequate for complex

uses .

In the same ve in , secur i ty layers bu i l t - in to the B lockcha in can only safeguard data , and

i s i l l - s t ructured to ensure recovery of lost co ins . Co ins sent to wrong wal let ad-dresses

and inact ive nodes are a l so not recovered. Mal ic ious accounts are a l so out of the net

as the present s t ructure cannot b lock them.

Not to be forgotten i s the fact that c rypto currenc ies come with d i s t inct conf igurat ion

that makes i t imposs ib le for homogenous un iversa l interact ion.

Unvei l ing

A Cutt ing-Edge B lockchain

The Index Protoco l B lockcha in i s a robust outcome of d ig i ta l technology that can be

used for rea l wor ld appl icat ions . When B i tco in h i t the l imel ight , tech experts began to

exp lore the potent ia l of the B lockcha in, and they rea l i zed that i t s funct iona l i t ies extend

beyond fac i l i ta t ing d ig i ta l cur renc ies .

The cue of fast th ink ing tech ies led to the surge in the number of decentra l i zed appl ica-

t ions that have made i t to g loba l l imel ight . Anyone who asks i f DAPPs are a l ready ava i l -

ab le , should see the l ikes of B i tShares , B i tMessage, and Peerp lays . These have become

known for decentra l i zed exchange funct ions , encrypted messag ing, and t rust less

bett ing. Golem i s a l so known for c loud comput ing and Steemit s tands out as a soc ia l

media p lat form.

Whi le many deve lopers have shown interest in the B lockcha in, the cha l lenge faced up

to the th i rd era was bu i ld ing a B lockcha in app f rom ground up. The work invo lved in

th i s regard posed a cha l lenge to innovators who have to go through the labor ious pro-

cess each t ime.

In the wake of the Fourth generat ion of B lockcha ins , deve lopers have rea l i zed that

opt ions ex i s t for the i r nat ive apps to be hosted. Index Protoco l B lockcha in ef fect ive ly

takes of f th i s burden that innovators and deve lopers have grappled wi th over the years

by complement ing ex i s t ing so lut ions .

Deve lopers wi l l be ab le to use the Index Protoco l B lockcha in to host the i r apps and

deve lop the i r product/serv ice n iche us ing a robust p lat form.

A B lockchain wi th Real -Wor ld Use Cases

The immediate era that preceded the unve i l ing of Index Protoco l had as i t s def in ing

at t ract ion such landmarks as :

•Expedi ted t ransact ion speed

•A grav i tat ion f rom PoS to DpoS

•The at t ract ion of commerc ia l adopt ion

•Use of a consensus a lgor i thm

•Deepened Sca lab i l i t y

•Transact ion fees reduct ion

•Wider Integrat ion poss ib i l i t ies .

As the poss ib i l i t ies of an expedi ted t ransact ion speed emerged in the th i rd generat ion

of B lockcha ins , the promise of the v iab i l i t y of the commerc ia l adopt ion of B lockcha ins

became a rea l i t y .

In the second generat ion, a l though the essence of B lockcha in t ransact ions conquer- ing

nat iona l and cont inenta l boundar ies became a rea l i t y , e f f i c iency was a problem, the

speed of c red i t card process ing exce l led what the B lockcha in could of fer in the Ethere-

um and B i tco in un iverses .

In the th i rd generat ion, B i t share showed some promise, and when R ipp leNet became a

rea l i t y , the capac i ty of the B lockcha in to churn out mi l l ions of t ransact ions per second

br ightened up.

Just when the wor ld was gett ing used to the exc i tement that ex i s t ing B lockcha ins have

a commerc ia l adopt ion poss ib i l i t y , the Index Protoco l has come into the mix wi th the

outstanding fourth generat ion re lat iona l B lockcha in.

The concept of B lockcha in operat ing sys tems can be p laced as an ongoing sphere wi th

commerc ia l usage gather ing momentum. There has a l so been facets of exc i tement wi th

the so many use cases unve i led.

Index Protoco l i s pr imed as a B lockcha in that deve lopers can exp lore in host ing apps

that answer to the i r core se l l ing po ints . Such open source s lant i s the ha l lmark that

def ines the robust arch i tecture , secur i ty and assoc iated innovat ive features .

The E ra Before Index P rotocol

Any appl icat ion that i s deve loped on the Index Protoco l B lockcha in wi l l be ab le to make

use of the prov ided database, a model of operat ion, account permiss ions , account

recovery and mult ip le ind ices .

Index Protoco l capabi l i t ies prov ides you work wi th sor ted data , enables schedul ing

funct ions , manage CPU cores , handle needed authent icat ion and a l l ied key manage-

ment across the p lat form. You wi l l be ab le to focus on your core bus iness funct ions so

that rout ine demands of app admin is t rat ion do not c lut ter your performance and ef f i -

c iency .

There i s no doubt that deve lopers wi l l be ab le to focus on app deve lopment and opt i -

mize the i r ro les wi th Index Protoco l at the background. App users that come on to the

network wi l l be f ree to exp lore the funct iona l i t ies wi thout the hurd le of access fees .

Th is can un lock severa l bus iness potent ia l s and g ive any app an opening for growth and

expans ion of market share .

Index Protoco l has a miss ion that i s not targeted at def in ing B lockcha in technologies

by t rademark, but , rather based on capabi l i t ies . The evo lut ion of the B lockcha in can be

t raced f rom the f i r s t to the fourth generat ion.

The concept of f i r s t generat ion B lockcha ins i s ident i f ied for the i r use of the Proof of

Work1 a lgor i thm in va l idat ing t ransact ions . The resu l tant hard forks2 assoc iated wi th

the p ioneer era of the B lockcha in innovat ions that were not groundbreak ing.

The dawn of a second generat ion B lockcha in s tar ted wi th Ethereum lead ing the era

denominated by smart contracts -based B lockcha ins . The under ly ing at t ract ion of the

era was the capac i ty for i s suance of vary ing tokens on the p lat form.

What the f i r s t and second generat ion had in common was energy – intens ive and poor

speed of t ransact ions . Va l idat ion of newly spawned b locks progressed at sna i l speed

that made a commerc ia l adopt ion of the B lockcha in unatt ract ive .

The major drawbacks of the f i r s t two generat ions of the B lockcha in necess i tated

improv ing sca lab i l i t y , reduc ing energy usage leve l s , and expedi t ing t ransact ion speed.

These apparent drawbacks became the persuas ion for the evo lut ion of the th i rd genera-

t ion of B lockcha ins .

The th i rd generat ion of B lockcha ins was anchored on the updated Proof of Stake a lgo-

r i thm in p lace of the Proof of Work opt ion. Beyond these, of f -cha in sca l ing part ia l or

fu l l centra l i zat ion and graph cha ins a l so featured in th i s era .

What the fourth generat ion sought to do i s to prov ide an exponent ia l leap in t ransac-

t ion process ing t imes. Sca lab i l i t y3 i s a l so a target so that no impediment can l ie on the

path of commerc ia l adopt ion of the B lockcha in. Making the B lockcha in compet i t i ve for

use in more d iverse and complex scenar ios i s the end-game of th i s era .

The demands of d ivers i f ied work env i ronments requi re secur i ty of data , expedi ted

t raceabi l i t y , and data pers i s tence for the B lockcha in to be re levant . Apply ing the con-

cept of re lat iona l databases to complex data s t ructures are inev i tab le for opt imized

B lockcha ins .

As an ep i tome of the fourth generat ion B lockcha in, Index Protoco l expands the bound-

ar ies of present poss ib i l i t ies in data s torage, audi t ing, re l iab i l i t y , secur i ty and appl ica-

t ion decentra l i zat ion. The Neura l Consensus A lgor i thm, which uses ε -d i f ferent ia l

agreement as a subst i tut ion for Proof of Work and Proof of Stake4 approach.

Index Protoco l of fers a h igher leve l of adaptat ion wi th in the B lockcha in by prov id ing

features for integrat ion of ERC20/ERC23 so lut ions . I t a l so a l lows host ing of th i rd party

tokens and co ins integrat ion.

Index P rotocol : The Mis s ion

Index Protoco l has made appropr iate use of ex i s t ing so lut ions that opt imize the B lock-

cha in as an adjunct to i t s d i s t inct se l l ing po ints .

Index Protoco l of fers a s t ructure that s t retches the boundar ies of the B lockcha in as we

present ly know i t . Data layers are enhanced by Index Protoco l in an expedi ted ver i f i ca-

t ion manner that f lows through ent i re organized data s t ructures that have symbol ic

l inks .

Index Protoco l B lockcha in makes ver i f i cat ion of t ransact ions poss ib le wi th in a d i s t r ibut-

ed decentra l i zed sys tem in a coherent manner . The Index Protoco l model d i f fers f rom

what obta ins present ly in the B lockcha in by i t s int roduct ion of a s torage so lut ion wi th

advanced and organized capac i t ies .

Index Protoco l of fers what can otherwise be descr ibed as an adapt ive Cryptographic

Database, which best su i ted for complex data s t ructures . The layers of data would

interact seamless ly to ensure the rea l i zat ion of env i s ioned goa ls .

On the Index Protoco l p lat form, comput ing power i s opt imized as th i s can be shared

between l inked nodes in both on-cha in and off -cha i modes. In th i s manner , the requi re-

ment of speedy process ing wi l l be met wi th a l l the ava i lab le resources at work.

Index Protoco l i s set to win the market as the most AGILE so lut ion for every area of

need and deployment . The AGILE approach5 makes i t poss ib le for a respons ive

f rame-work that draws on exper iences encountered in the course of pro ject deve lop-

ment .

In th i s wise , a l l poss ib le SWOT (s t rengths , weaknesses , opportuni t ies and threats ) are

catered for . So, whatever i s sub-opt imal in the process i s d i scarded or improved upon.

AGILE i s the best approach to sof tware deve lopment as i t makes room for updates and

f ine tun ing f rom concept ion to deployment phases . Th is makes i t poss ib le to respond

to changing market t rends and compet i tors ’ un ique se l l ing po ints . Us ing AGILE makes

i t a sure bet to remain at the cutt ing-edge whi le the product launch i s underway.

Index P rotocol and Global

Adopt ion of the B lockchain

Index Protoco l i s d i f ferent iated by i t s qua l i ty , and that i s a major se l l ing po int that the

market i s open to at the moment. The B lockcha in i s a t t ract ive for use in many facets of

l i fe , but , on ly to the extent that i t meets the requi rements of vary ing bus iness interests .

Speed i s what makes the d i f ference between compet ing B lockcha ins in today ’ s wor ld ,

and Index Protoco l leverages on th i s .

Index Protoco l wi l l process t ransact ions at a faster pace wi th increased part ic ipat ion

lead ing to a h igher process ing t imes. Th is i s a huge p lus for d ivers i f ied bus inesses as i t

increases the capac i ty for t ransact ion process ing. Index Protoco l opt imizes computa-

t iona l s t rength, and the performance of each node on an on-cha in and off -cha in bas i s .

Fast -Paced T ransact ion P rocess ing

Index Protoco l i s Greenhouse-Fr iendly , which t ies to the preva i l ing g loba l sent iment of

s teer ing the B lockcha in away f rom foss i l energy dependency. Index Protoco l i s opt i -

mized to min imize computat iona l power input for t ransact iona l va l idat ion as opposed

to the huge energy needs bu i l t - in for POW (Proof of Work) a lgor i thms.

Index Protoco l subst i tutes Neura l Consensus A lgor i thm6 for POW, and th i s enta i l s a

deepening of l inear sca lab i l i t y . The performance increase wi l l a r i se as the node s ize

increases . A Better performance i s assured in a 100k node network ecosystem with TPS

peak ing at 100k.

When i t comes to reach ing consensus , there i s no se lect ion of a head node, s ince there

are on ly s imple ca lcu lat ions that wi l l a r i se , a lower energy consumpt ion i s assured. Th is

g ives Index Protoco l a greenhouse f r iendly ident i ty .

Greenhouse F r iendly

Index Protoco l pro jects a complete generat iona l sh i f t for the B lockcha in wi th un ique

se l l ing po ints that a im at the understated touchstones :

1. Neura l Consensus A lgor i thm

2. On-cha in and Off -cha in Comput ing Shar ing

3. Adapt ive Database

4. Micro serv ice St ructure and Funct iona l AP I

5. Ro l lback (Adjustab le feature on ly on request )

6. B iometr ic data as seed for E lect ron ic S ignature

7. Transact iona l Model

8. Seamless Data F low

9. Proven Mult i -Cha in Networks

10. Deve loper Integrat ions for Java and Programming Languages of Common Use 12

Index P rotocol : The Touchstones

Index Protoco l adopted the Neura l Consensus A lgor i thm as a resu l t of severa l of i t s

hal lmarks . The ε -d i f ferent ia l agreement (EDA) as the Neura l Consensus i s a l so known,

l everages on the s t rength of l inear sca lab i l i t y . L inear sca lab i l i t y in the consensus a lgo-

r i thm, exponet izes performance as node s ize increases .

1. Neura l Consensus A lgor i thm

A Diagrammat ic L inear F low

Increase in node s ize or more part ic ipat ion won ’ t s low down the network, but , have the

oppos i te ef fect . As node s ize increases , there i s fas ter convergence and log ica l - l y , an

opt imized performance resu l t s .

What s tands out wi th Index Protoco l ’ s prefer red a lgor i thm i s that EDA has a conf igura-

t ion based on micro- rea l numbers , which i s between 0 and 1. Th is takes on the s t rong

points of the preva lent consensus a lgor i thms as they are known and overr ides the i r

assoc iated weaknesses .

When EDA i s put to use in a 100K node network ecosystem, Transact ions per Second

(TPS) peaked at 100K. The de lay in conf i rmat ion of t ransact ions p lummeted by severa l

seconds. Remarkably , a lower computat iona l power i s needed for the out l ined proce-

dure compared to DpoS, PoS and PoW approach.

These are ha l lmarks of the Neura l Consensus A lgor i thm:

•Cont inuous vot ing rep laces d i screte vot ing as used in known consensus processes

•Dif ferent env i ronments are conf igured with d i f ferent ef f i c iency parameters

•Energy sav ing and greenhouse f r iendly

•Operat iona l su i tab i l i t y for a wide-range of network sys tems

•Adjustab le parameters

•Reduced t ransmiss ion overhead

Stee le’s D imens ional Node Representat ion

St ructura l Secur i ty Essence

The use of secured V i r tua l Conta iners for d i s t r ibut ion of nodes i s the s t ructura l se-

cur i ty approach for Coucha in. Any Host machine operator cannot have the needed

credent ia l s for access to nodes wi thout due access , which i s in consonance wi th the

L inux Secur i ty refer ra l .

The use of double access lock i s prefer red so that anyone with guest c redent ia l s cannot

compromise the lock feature .

The double access lock eva luated above i s put in p lace to ensure that nodes not d i - rect -

l y under Index Protoco l management i s secure and not compromised. Th is approach

i so lates the prescr ibed conf igurat ion f rom unwanted intervent ions and runs autono-

mous ly . Index Protoco l i s authent ic wi th a des ign that makes i t inaccess ib le to just

anyone. The secur i ty layout has three major components wi th in the conta iner as shown

above, i t a l so encompasses the Operat ive and Secur i ty layers . There i s the substant ive

Index Protoco l Server compi led code, Index Protoco l C luster asymmetr ic key authent i -

cator , the cha l lenge seed, the server code hash cer t i f i cate as wel l as the t ransact ion

data .

The c luster access cer t i f i cate can be put to addi t iona l use by automat ing conta iner

access c redent ia l s ’ update dur ing the compi lat ion phase by us ing a random pass-word.

Th is wi l l prec lude any inter loper f rom ga in ing access wi thout hav ing the preset input

keys .

Structural Security anchored on Reverse Access Denial

Adopt ive Language

To make Index Protoco l open to a wider spect rum of deve lopers g loba l l y , Index Protoco l

i s des igned to make use of the wide ly known SQL-anchored syntax.

The purpose of th i s approach i s to make i t eas ier for more people to learn Index Proto-

co l bas ics wi thout much ado. Th is wi l l a l so make room for the s tandard pers i s tent-s tor -

age funct ions which i s understandable by a major i ty of deve lopers .

The demands of comput ing power on the B lockcha in i s not in doubt . Th is comes to the

fore in g loba l concerns over the huge energy- intens ive nature of ex i s t ing B lockcha ins .

I f Index Protoco l enables computat ions of f -cha in , i t has to go on in a decentra l i zed

approach. Rea l i z ing th i s , the processes are opt imized in such a way as to ensure that

data integr i ty i s assured

Running computat ions on-cha in has proven to be prohib i t i ve for the Ethereum B lock-

cha in, and th i s exp la ins the h igh gas impl icat ion for t ransact ions . When computat ion i s

therefore enabled of f -cha in , heavy tasks can be suf f ic ient ly executed on those nodes .

Tasks that are data – intens ive l i ke 3D funct iona l i t ies and t ranscoding of v ideos are prac-

t ica l l y imposs ib le in on-cha in modes. These are some of the tasks that can go on

off -cha in to ensure cost sav ings .

Index Protoco l wi l l make i t poss ib le for deve lopers to work around the inh ib i t ions iden-

t i f ied. A range of ver i f iab le computat ions can be t racked us ing too ls7 that make such

poss ib le . A proof of correctness and proof resu l t can be ret r ieved by c l ients us ing less

computat iona l power that i s far less than what an actua l on-cha in computat ion of

t ransact ions wi l l necess i tate .

2. On-Chain and Off-chain Computing Sharing

Index Protoco l i s opt imized to ensure that comput ing i s shared between on-cha in and

off -cha in sys tems. When comput ing i s done off -cha in , pressure and energy demands

reduces on the cha in. The process ing that goes on of f -cha in a l so ensures that a d i s t r ib-

uted s torage i s opt imized at a l l t imes.

S ince the s tored data on-cha in i s access ib le to everyone, the of f -cha in vers ion a l so gets

updated whenever i t rega ins network connect iv i ty . Th is feature of Index Protoco l can

be seen as mul t i -pronged with a d i s t inct innovat ive edge.

Index Protoco l i s capac i tated for indust r ia l , ins t i tut iona l or admin is t rat ive use that ca l l s

for synchrony of complex processes .

Index Protoco l i s pos i t ioned as a t ra i lb lazer in the marketp lace of c ryptographica l l y

adapt ive database so lut ions wi th d i s t r ibuted or decentra l i zed features .

The conceptua l izat ion of Index Protoco l makes i t poss ib le for cha inable ent i t ies to

become sp l i t -cha ins wi th that enta i l d i sparate ent i t ies and records . These ent i t ies

re jo in the parent cha in af ter each t ransact ion-re lated modi f icat ion i s completed.

In Index Protoco l terms, the t ransact iona l co ins a long with a l l subs i s t ing ent i ty on the

p lat form wi l l conform to four ident i f ied tab les :

•Indiv idua l user

•The wal let

•The wal let s tate , and

•The Transact ion

3. Adaptive Database

Each of these out l ined f ie lds are act ivated rec iproca l l y and they wi l l be va l idated inter -

re lated.

An adapt ive Database i s ca l led upon by Index Protoco l so that data l ink ing i s un l imi ted.

Al l act ivated wal le ts on the cha in can undergo ser ies of s tates , but , must be l inked to

a def ined user . The change of s tates wi l l invo lve :

An ex i s t ing s tate - to make va l idat ion poss ib le

An audi tab le l ink to the most recent t ransact ion or major cha in t ra i l

These two work paths makes i t easy to t race the under ly ing bas i s for a s tate change,

mak ing i t poss ib le to avo id or inva l idate dummy or f raudulent t ransact ions . As s t ruc-

tured on Index Protoco l , a f ter a t ransact ion va l idat ion i s made on a sub-cha in, the mod-

i f ied s tate re jo ins the parent cha in .

The immediate ef fect of the Index Protoco l innovat ion i s that for each new t ransact ion,

there must be two hashes : the s tate l ink and the most recent t ransact ion. The a lgor i thm

makes i t inherent that a t ransact ion on ly gets va l idated upon a ver i f i cat ion of the most

recent t ra i l .

The ut i l i t y of the Index Protoco l so lut ion to t ransact iona l va l idat ion opens the door for

an ef f ic ient management of complex data demands. Our technology wi l l be adaptab le

to a l l appl icat ions that requi res g loba l , ins t i tut iona l , indust r ia l , regulatory or sovere ign

demands. Th is i s a s tep forward to an ef f ic ient B lockcha in un iverse .

Index Protocol’s Adaptive Database Model

Re-joInable Split-chains that thrive on Parallel Work

Operat iona l l y , the a lgor i thm that a l lows sp l i t -cha ins for t ransact iona l process ing and

re jo in ing to the parent cha in makes room for work load ana lyzers . In th i s sense, each

c luster that requi res cha in sp l i t t ing wi l l be ident i f ied to g ive room to two secondary

cha ins . I f requi red, these cha ins wi l l re -sp l i t when a h igher than normal leve l of t rans-

act ion requests are rece ived.

On cha in normal izat ion, a l l mul t ip le sp l i t -cha ins wi l l l ink back to the parent cha in and

be va l idated. The beauty of th i s approach l ies in maintenance of safety of t ransact ion

records as para l le l process ing cont inues .

Index Protoco l has a funct iona l i ty based on Server less and Microserv ices model l ing. I t

i s pr imed to prov ide secured and advanced API funct iona l i t ies that adapts to both

approaches in tandem with best pract ices .

Whi le microserv ices has been used as a d i s t inct approach in t imes past , cut t ing-edge

improvements have shown that i t can be merged with a funct iona l AP I to opt imize

sys tem resource and outcomes.

A funct iona l AP I i s v i ta l for Index Protoco l processes as t rad i t iona l AP Is though ef fec-

t ive , are qu i te resource-demanding. A Microserv ices8 API i s in a d i f ferent wor ld as i t

has bu i l t - in capac i t ies that expedi tes autonomous ro les in a fast , qu ick and n imble

manner .

4. Microservice Structure and Functional API

The Microserv ices Approach

The Microserv ices approach that under l ies Index Protoco l makes i t poss ib le for the

component operat ing segments to be se l f -ex i s tent . Th is i s deta i led insomuch as there

are c lear l ines of t ransact iona l respons ib i l i t y .

A typ ica l out l ine wi l l invo lve :

•A database ( d i s t r ibuted in th i s sense)

•Clar i ty of Transact iona l focus

•Running process

•A systems repos i tory

•The Funct iona l AP I

•User Inter face

The broad layout of Index Protoco l coverage area makes i t dynamic to accommodate

expans ion of serv ices as the sca le of operat ions demand.

There i s no doubt that the des ign of Index Protoco l microserv ices makes enough rom

for fau l t to lerance and sys temic i so lat ion. The impl icat ion of th i s prov i s ion i s captured

in the data shard ing mode.

Index Protoco l i s therefore opt imized so that the component parts are :

•Easy to understand

•Adhere to the def ined smart contracts

•Are guarded to prevent database exposure wi thout requis i te c redent ia l s

•Able to i so late fa i led nodes unt i l in tegr i ty i s conf i rmed

•Capable of deployment even i f a minor i ty of nodes are non-funct iona l

•Shie lded f rom system t imeouts assoc iated wi th microserv ices arch i tecture wi th the

sub-cha in process ing innovat ion.

A Frontend View of a Functional Microservices API

When data shard ing occurs , i t does not d i s rupt the database as the const i tuent nodes

have records of the ent i re cha in or a part thereof . The mechanism at work here

s t im-u lates the coord inator node to prescr ibe the data part i t ion read iness . Th is i s done

to make data d i s t r ibut ion opt imal to the ex i s t ing work load.

Based on the tenets of H igh Ava i lab i l i t y , pers i s tence and re l iab i l i t y cannot be compro-

mised even when c luster capac i ty shr inks . As long as ≥ 51% of ava i lab le nodes remain

act ive . In the event of a c luster c rash, the act ive nodes wi l l red is t r ibute the va l idated

data s t ructures . Th is wi l l serve to confront subsequent part ia l c luster c rash-es that

might occur .

Incorporating Data Sharding

Index Protoco l B lockcha in ev ident ly d i sp lays the capac i ty for data shard ing and opt i -

mized para l le l work. Th is i s an ind icat ion of a robust hor izonta l sca lab i l i t y , sys tem res i l -

ience, inherent d i saster recovery , increased secur i ty unappal led h igh ava i lab i l i t y ,

non-ex i s tent s ing le po int of fa i lure9

Our cutt ing-edge technology i s opt imized for ro l lback of t ransact ions that are present ly

imposs ib le wi th the f ront l ine B lockcha ins . Th is wi l l a l low for a rev i s ion to an ear l ie r

s tate that does not ca l l to quest ion the cha in va l idat ion cred ib i l i t y .

I t i s worthy to h igh l ight that fa i lure of ro l lback prov i s ions i s one of the loopholes in the

Ethereum and other Proof of Stake or Proof of Work protoco ls . The ro l lback feature

on ly needs to be enabled for sys tems that requi re i t for appl icat ions and tokens that

requi re i t .

A number of users of ex i s t ing B lockcha ins have had cause to lament over lack of ro l l -

back features . Mi l l ions of USD worth of tokens and co ins are in l imbo10 to date as a

resu l t of th i s .

Index Protoco l i s po ised to have the ro l lback act ivated on request for c l ients who see a

need for such. Whi le some B lockcha in processes do not have a need for a ro l lback,

those that dwel l on token t ransfers and t ransact ions wi l l f ind i t needfu l .

5. Rollback (Adjustable feature only on request)

Freez ing a wal le t becomes necessary whenever there i s suspected act iv i t ies that requi re

interven ing act ion. Th is i s a prov i s ion made poss ib le wi th the AGILE conf ig- urat ion put

in p lace.

When act ivated, ind iv idua l user env i ronments wi l l dec ide on act ivat ion i f i t su i t s sub-

s i s t ing nat ive prescr ipt ions .

User Security anchored Freezable wallets

Ex is t ing research po ints at the use of b iometr ic features for the preservat ion of the

ident i ty of s ign- in integr i ty . The inev i tab le absence of dupl icat ion poss ib i l i t ies us ing

th i s e lect ron ic s ignature opt ion makes i t a t t ract ive for Index Protoco l uses .

There are no two persons that have ident ica l f ingerpr ints ne i ther do the ret ina have

s imi lar metr ics . A whole wor ld of infa l l ib le c redent ia l s t i l l wa i ts to be exp lored on the

b io log ica l ID f ront .

The poss ib le use of ret ina scan, f ingerpr ints and re lated data wi l l be eva luated by the

Index Protoco l team for poss ib le b iometr ic data integrat ion.

The use of b iometr ic data on IOS, Andro id and re lated p lat forms for user safety wi l l be

eva luated whi le cons ider ing the impact on lega l grounds.

6. Biometric data as seed for Electronic SignatureI

Index Protoco l prefer red mechanism wi l l ensure that a l l t ransact ion data get t ransmit -

ted in a t ransact iona l model12 for coherence and data completeness .

Index Protoco l des ign compl ies wi th a l l the requi rements of the ACID13 parad igm,

which i s an acronyms a l lus ion to the log ica l propert ies underg i rd ing a l l t ransact ions .

For any secure t ransact iona l model , the under ly ing technology has to be at tuned to:

• Atomic i ty , which s tates that t ransact ions are ind iv i s ib le in execut ion and that com-

plet ion i s requi red in execut ion. No a l lowance i s made for part ia l or nu l l execu-t ions .

• Cons is tency , which h igh l ights the need for a database to t rans i t f rom a va l id s tate to

another . Pers i s tent data has to a l ign wi th pre-ex i s t ing ru les .

• I so lat ion, which requi res that execut ion of respect ive t ransact ions must be t reated

in i so lat ion. Th is wi l l a l so mean that i f a t ransact ion fa i l s , i t must not inter fere wi th the

fate of concurr ing t ransact ions .

• Durabi l i t y , which a l igns wi th pers i s tence, and requi res that af ter a t ransact ion i s

in i t ia ted, the outcome cannot be indeterminate for any reason whatsoever . In other

words , not even power inter rupt ion, sys tem crash or any other excuse i s permit ted.

7. Coherence of Transactional Model

Index Protoco l co ins wi l l run on the ERC2014 inter face, which wi l l be compat ib le wi th

ERC23 for the purpose of externa l inter face interoperab i l i t y .

Blockchain Interoperabil ity

Index Protoco l i s committed to the inward and outward f low of tokens and co ins on i t s

cha in that or ig inate f rom non-propr ietary cha ins .

ERC20/ERC23-driven Native off-chain adaptors

Index Protoco l wi l l support inter fac ing wi th tokes and co ins in an unhindered f low for

nat ive of f -cha in adaptors to support guests in the course of t ransact ions .

ERC20/ERC23 guest-enabled Native off-chain adaptors

In teroperab i l i t y wi th other b lockcha ins based on Rec iproca l Cha in Conf i rmat ion Index

Protoco l ’ s opt imizat ion wi l l take into cons iderat ion the s tates of compet ing B lock-

cha ins to make i t poss ib le to for exchange of respect ive tokens . Th is wi l l a im at and

ensure t rust and va l idat ion.

The rec iproc i ty of th i s mechanism ensures that the s tate va l idat ion of Index Protoco l

can be shared wi th other b lockcha ins as the ver i f i cat ion need ar i ses . Th is wi l l become

operat iona l v ia a spec i f i c inter face based on a server less feature that takes into cons id-

erat ion a conta iner compi lat ion, which po ints adapters to accommodate other cha ins .

When a t ransact ion i s in i t ia ted, i t has to go through a procedure of acceptance, requi -

s i te contro l , va l idat ion as wel l as the expected pers i s tence.

The procedure of a t ransact ion can be s impl i f ied as fo l lows: A t ransact ion i s re layed for

process ing wi th a l l the needed data prov ided and authent icated by a pr ivate key>

The Index Protoco l c l ient sends the deta i l s of the t ransact ion to the coord inat ion c lus-

ters led by an ass igned node>

The ass igned node sp l i t s the ver i f i cat ion so that a l l nodes wi th a propr ietary lead can

eva luate wi th in the ambit of a des ignated protoco l>

The nodes wi l l eva luate the t ransact ion for data authent ic i ty by check ing for s ignature ,

repeated hash, ava i lab i l i t y of funds, b locked or act ive wal le ts , user ex i s tence, requis i te

wal le t s tates>

What i s generated f rom user ID gets processed into vo lat i le memory as other data f ie lds

of ex i s tent ia l nature gets probed>

8. Seamless Data Flow

At the end of the process ing s tage i s t ransact ion t ransmiss ion to the Topic Message

Queue15 ass igned with a def ined protoco l to the due rec ip ient as def ined. The worker

nodes wi l l rece ive the d i s t r ibuted messages para l le l .

The worker nodes wi l l act on the process ing by ver i fy ing data , eva luat ing assoc iated

condi t ions before proceeding to c reate a new wal let s tate . The process wi l l inc lude

ret r iev ing the processes hash of prev ious re lated t ransact ions in order to use them for

t ransact iona l update. A l l these wi l l be made poss ib le wi th the Neura l Consensus A lgo-

r i thm in p lace to produce a Transact ion Hash16.

A Transaction Hash Outcome Process

Bi tco in and Ethereum are notor ious for s ing le cha in s t ructures wi th the i r remarkable

l imi tat ion of conf in ing t ransact ions to just one cha in.

Index Protoco l recognizes the inh ib i t ion on the pathway of ef f i c iency , and th i s i s the

mot i -vat ion for a mul t i -cha in s t ructure enabled by the Neura l Consensus A lgor i thm.

S ide cha ins , para l le l cha ins and mult ip le cha ins wi l l be enabled to meet the respect ive

needs of entrepreneurs and bus inesses .

Index Protoco l ’ s prefer red arch i tecture i s the heterogeneous forest network that

enables interoperab i l i t y between the d ig i ta l sphere and rea l -wor ld s i tuat ions . Th is

paves the way for resources and assets to be def ined on Index Protoco l , s tored, t rans-

fer red and t ransformed to meet emerg ing and present needs .

Index Protoco l i s resourced for sys tem eff ic iency in two d is t inct ways : The f i r s t e f f i c ien-

cy s tandpoint i s the autonomous sub-cha ins ef fect that makes i t poss ib le to prov ide

resources as requests ar i se to para l le l substant iate data s t reams across nodes and

numerous threads .

When the cha in-sp l i t occurs , i t speeds up ongoing t ransact ions to a log ica l complet ion

and terminates when the output i s added to the parent cha in . The technique at work

here a l lows for a l l b locks wi th in the parent cha in to synchronize in va l idat ing two

d is t inct sub-cha ins us ing two separate incoming l inks .

The second ef f ic iency s tandpoint i s Data Shard ing17, which i s a notab le technique used

for data d i s t r ibut ion between mult ip le nodes . In a data ser ies XYZ with three C luster

Nodes , the data d i s t r ibut ion wi l l fan out as :

- XY

- YZ

- ZX

The order of th i s subdiv i s ion makes t ransact iona l h igher process ing speed to soar ,

g iven that the or ig inat ing data quer ies wi l l opt imize each s tep hav ing impacted just the

subcha in nodes .

9. Proven Multi-Chain Networks

Index Protoco l a l so thr ives on High Ava i lab i l i t y18, which makes i t poss ib le to re ly on an

ef f ic ient c luster type as a cont ingency when a sys tem shutdown renders some nodes

inoperab le .

F lowing f rom the ear l ie r i l lus t rat ion, in an X, Y, Z scenar io , i f Z i s knocked out , X and

Y can be leveraged on to support the B lockcha in and prevent a denia l of serv ice .

The conf igurat ion i s operat ive as long as the number of act ive nodes are ≥ 51%.

In the event of a shutdown that takes of f mul t ip le nodes , the undis turbed c luster wi l l

reorganize data autonomous ly t i l l there i s a complete react ivat ion of a l l nodes .

9. Proven Multi-Chain Networks

The funct iona l l ib rar ies wi th h igh-end propens i t ies for inter fac ing Java Spr ing, Ja-vaS-

cr ipt and other programming languages of common use in Index Protoco l i s a pr ior - i ty .

Whi le deve lop ing the capac i ty for integrat ions i s go ing to be ef fect ive , i t wi l l be based

on market needs coupled wi th c l ient requi rements .

As the testnets for Index Protoco l are unve i led, we wi l l make prov i s ions for the pro-

gramming languages that are h igh ly used in the deve loper marketp lace. Th is wi l l make

i t poss ib le for inst i tut iona l , and enterpr i se- leve l adopt ion of the Index Protoco l of fer -

ing on a un iversa l sca le .

A l ready, apart f rom other cons iderat ions , wide ly sought-af ter too ls l i ke Spr ing19 i s

prov ided for as a feature of our p lat form. Spr ing has a ut i l i t y in i t s use as a conta iner

for Java. The pr ized features of Spr ing i s notab ly in use by Java apps.

Index Protoco l arch i tecture takes into cons iderat ion the ut i l i t y of Java and has a l so pro-

v i s ioned modules for i t s integrat ion. Java i s used for wr i t ing programs and creates

appl icat ions in var ious spheres of l i fe .

Even the less l i te rate of PC users would have made use of Java whenever one program

or the other i s downloaded on the PC. Th is c la r i f i cat ion exp la ins why Index Protoco l ’

Java prov i s ion ing i s a l l - important .

10. Developer Integrations for Java

and Programming Languages of Common Use

For deve lopers , Javascr ipt a l so p lays a huge ro le s ince i t i s a bas i s for bu i ld ing many

apps. Us ing Javascr ipt a longs ide Index Protoco l i s made easy for integrat ion purposes .

Deve lopers wi l l f ind Index Protoco l to be a de l ight to put to use for integrat ion purpos-

es .

Our approach to these aforement ioned processes wi l l be to a l low for propr ietary so lu-

t ions to integrate Index Protoco l into the of f ic ia l MainNet20 as wel l as pr ivate cha ins .

The B lockcha in 4.0 i s the emergent p lat form that Index Protoco l wi l l ut i l i ze for the

launch of i t s tokens . Index Protoco l as an ERC20 token wi l l be re leased to the communi-

ty through an a i rdrop campaign. Our goa l i s to br ing B lockcha in 4.0 wi th in the reach

of everyone across the g lobe.

As an immediate s tep, Index Protoco l wi l l launch v ia a i rdrop as an ERC20 co in. We

be- l ieve the community has a great ro le to p lay in the evo lut ion of Index Protoco l .

P lease fee l f ree to send your ideas across the pro ject . As we exp lore the v iews of a l l

s takehold-ers , we can bui ld the Index Protoco l B lockcha in

Immediate Steps

Index Protoco l i s e f fect ive ly summar ized in the fo l lowing h igh l ights :

A Walk-Through Index Protocol

Fool -proof secure wal le ts access ib le by b iometr ic inputs .

Next Generation Wallet

An opt iona l feature act ivated based on c l ient request

Transaction Rollback

Chain severab i l i t y opt imizes ava i lab le resources .

Divisible Chains

Opt imizes of f -cha in nodes to reduce on-cha in c logging.

Off-Chain and On-Chain Computing Sharing

Supports energy conservat ion by avo id ing repet i t i ve processes that are foss i l -energy

intens ive

Greenhouse Friendly

PoS (Proof of Stake), Dpos, and PoW is substituted by EDA

(ε-differential agreement: Essential ly an ordering of blocks based on continuous voting ).

Neural Consensus Algorithm (ε-differential agreement)

References

1. Proof of Work : https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/

2. Hard Forks : https://www.techopedia.com/definition/32912/hard-fork

3. Scalabil ity : https://www.investopedia.com/terms/s/scalability.asp

4. Proof of Stake : https://bytemaster.github.io/bitshares/2015/01/04/Delegat-

ed-Proof-of-Stake-vs-Proof-of-Work/

5. AGILE Approach : https://docs.microsoft.com/en-us/vsts/work/work-items/guid-

ance/agile-process?view=vsts

6. Neural Consensus Algorithm : https://medium.com/@lisa_ai/see-

les-neural-consensus-algorithm-the-basics-673a41f3a772

7. Using Tools : http://docs.oraclize.it/#authenticity-proofs.

8. Microservices API : https://www.ibm.com/developerworks/websphere/li-

brary/techaarticles/1601_clark-trs/1601_clark.html

9. Single Point of Failure : https://www.ibm.com/support/knowledgecen-

ter/en/SSLT-BW_2.1.0/com.ibm.zos.v2r1.ieaf100/single.htm

10. Are in Limbo : https://techcrunch.com/2017/12/05/parity-ceo-says-shes-con-

fi-dent-that-its-280m-in-frozen-ethereum-isnt-lost-forever

11. Finger Prints, Related Data : https://www.ncbi.nlm.nih.gov/pmc/articles/

PMC5411053/

12. Transactional Model : https://www.slideshare.net/RenelynMecha-

caEspino/transactional-model-of-communacation

13. ACID : https://www.geeksforgeeks.org/acid-properties-in-dbms/

14.ERC20 : https://medium.com/blockchannel/the-anatomy-of-erc20-c9e5c5ff1d02

15. Topic Message Queue : http://knowledgelayer.softlayer.com/articles/mes-

sage-queue-topic-description

16. Transaction Hash : https://support.freewallet.org/support/solutions/arti-

cles/9000097169-what-is-transaction-hash-and-how-to-find-it-

17. Data Sharding : https://docs.microsoft.com/en-us/azure/architecture/patterns/

sharding

18. High Availabil ity : https://docs.microsoft.com/en-us/sql/sql-server/-

failover-clus- ters/high-availability-solutions-sql-server

19. Spring : https://spring.io/19. Spring : https://spring.io/

20. Mainnet: https://www.ethnews.com/glossary/mainnet 34