An Overview of the Hyper­ledger Saw­tooth Frame­work

Hyper­ledger Saw­tooth is a mod­u­lar plat­form for build­ing, de­ploy­ing and run­ning dis­trib­uted ledgers, which pro­vide dig­i­tal records (such as as­set own­er­ship) that are main­tained with­out a cen­tral au­thor­ity or im­ple­men­ta­tion. Let’s take a quick look at it.

OpenSource For You - - Contents - By: Swap­nil Kulka­rni The au­thor is an open source en­thu­si­ast with ex­pe­ri­ence in blockchain, cloud na­tive so­lu­tions, con­tain­ers and en­ter­prise soft­ware prod­uct ar­chi­tec­tures. He is a tech­nol­ogy hob­by­ist and writes at cloud­na­tivetech.word­press.com.

Hyper­ledger Saw­tooth is a blockchain frame­work that uses a mod­u­lar plat­form for build­ing, de­ploy­ing and run­ning dis­trib­uted ledgers. Such dis­trib­uted ledger so­lu­tions can use var­i­ous con­sen­sus al­go­rithms, de­pend­ing on the size of the net­work. Ini­tially con­trib­uted by In­tel, Hyper­ledger Saw­tooth uses the Proof of Elapsed Time (PoET) con­sen­sus al­go­rithm, which pro­vides the scal­a­bil­ity of the Bit­coin blockchain with­out the high en­ergy con­sump­tion. PoET al­lows for a highly scal­able net­work of val­ida­tor nodes. Hyper­ledger Saw­tooth is de­signed for ver­sa­til­ity, with sup­port for both per­mis­sioned and per­mis­sion­less de­ploy­ments.

Saw­tooth is the only Hyper­ledger project that pro­vides the dis­trib­uted state agree­ment, which means that you can trust every node in the sys­tem to un­der­stand in­for­ma­tion in the same way. It is the only frame­work that pro­vides the abil­ity to cre­ate adapters for any kind of trans­ac­tion logic which means, for in­stance, that you can now run Ethereum Vir­tual Ma­chine code, like So­lid­ity, com­pile it and then run that on a Saw­tooth based net­work.

The func­tional el­e­ments of Hyper­ledger Saw­tooth

Trans­ac­tion val­ida­tors val­i­date trans­ac­tions. In Hyper­ledger Saw­tooth, val­ida­tors ap­ply blocks that cause a change in the state. More specif­i­cally, val­ida­tors val­i­date trans­ac­tion blocks and en­sure that trans­ac­tions re­sult in state changes that are con­sis­tent across all par­tic­i­pants in the net­work.

Trans­ac­tion fam­i­lies are smart con­tracts in Hyper­ledger Saw­tooth. They de­fine the op­er­a­tions that can be ap­plied to trans­ac­tions. This al­lows for flex­i­bil­ity in the level of ver­sa­til­ity and risk that ex­ists on a net­work. Trans­ac­tion fam­i­lies are of­ten called ‘safer’ smart con­tracts, be­cause they spec­ify a pre­de­fined set of ac­cept­able smart con­tract tem­plates, as op­posed to pro­gram­ming smart con­tracts from scratch. Hyper­ledger Saw­tooth’s trans­ac­tion fam­i­lies can be writ­ten in many lan­guages, in­clud­ing JavaScript, Java, C++, Python and Go, which al­lows flex­i­bil­ity for busi­nesses to bring their own trans­ac­tion fam­i­lies. Trans­ac­tion fam­i­lies con­sist of both trans­ac­tion pro­ces­sors (the server-side logic) and clients (for use from Web or mo­bile ap­pli­ca­tions).

Hyper­ledger Saw­tooth or­gan­i­sa­tions run a node that in­ter­acts with the Hyper­ledger Saw­tooth net­work. Each node runs at least three things:

The main val­ida­tor process

The REST ser­vice lis­ten­ing for re­quests

One or more trans­ac­tion pro­ces­sors

Each or­gan­i­sa­tion that en­ters the Hyper­ledger Saw­tooth net­work runs at least one node and re­ceives trans­ac­tions sub­mit­ted by fel­low nodes.

A trans­ac­tion pro­ces­sor is the server-side busi­ness logic of trans­ac­tion fam­i­lies, which acts upon net­work as­sets. Hyper­ledger Saw­tooth sup­ports plug­gable trans­ac­tion pro­ces­sors that are cus­tomis­able based on the spe­cific ap­pli­ca­tion. Each node within the Hyper­ledger Saw­tooth net­work runs a trans­ac­tion pro­ces­sor, which pro­cesses in­com­ing trans­ac­tions sub­mit­ted by au­tho­rised clients.

Trans­ac­tion batches are clus­ters of trans­ac­tions that are ei­ther all com­mit­ted to state or are all not com­mit­ted to state. As a re­sult, trans­ac­tion batches are of­ten de­scribed as an atomic unit of change, since a group of trans­ac­tions is treated as one and is com­mit­ted to the state, as one. Every sin­gle trans­ac­tion in Hyper­ledger Saw­tooth is sub­mit­ted within a batch. Batches can con­tain as lit­tle as a sin­gle trans­ac­tion.

In Hyper­ledger Saw­tooth, the jour­nal main­tains and ex­tends the blockchain for the val­ida­tor. It is re­spon­si­ble for val­i­dat­ing can­di­date blocks, eval­u­at­ing valid blocks to de­ter­mine if they are the cor­rect chain head and for gen­er­at­ing new blocks to ex­tend the chain. Trans­ac­tion batches ar­rive at the jour­nal, where they are eval­u­ated, val­i­dated and added to the blockchain. Ad­di­tion­ally, the jour­nal re­solves forks, which oc­cur due to dis­agree­ments over who com­mits a block. Once blocks are com­pleted, they are de­liv­ered to the ChainCon­troller for val­i­da­tion and fork res­o­lu­tion.

The net­work layer is re­spon­si­ble for com­mu­ni­cat­ing be­tween val­ida­tors in a Hyper­ledger Saw­tooth net­work, in­clud­ing per­form­ing ini­tial con­nec­tiv­ity, peer dis­cov­ery and mes­sage han­dling.

The global state con­tains the cur­rent state of the ledger and a chain of trans­ac­tion in­vo­ca­tions. The state for all trans­ac­tion fam­i­lies is rep­re­sented on each val­ida­tor.

The process of block val­i­da­tion on each val­ida­tor en­sures that the same trans­ac­tions re­sult in the same state tran­si­tions and that the re­sult­ing data is the same for all par­tic­i­pants in the net­work. The state is split into names­paces, which al­low flex­i­bil­ity for trans­ac­tion fam­ily au­thors to de­fine, share and re­use global state data be­tween trans­ac­tion pro­ces­sors.

The con­sen­sus in­ter­face in Saw­tooth

Con­sen­sus in Hyper­ledger Saw­tooth is mod­u­lar, which means that the con­sen­sus al­go­rithm can be eas­ily mod­i­fied. Hyper­ledger Saw­tooth pro­vides an ab­stract in­ter­face that sup­ports both PBFT and Nakamoto-style al­go­rithms. To im­ple­ment a new con­sen­sus al­go­rithm in Hyper­ledger Saw­tooth, you must im­ple­ment the dis­tinct in­ter­face for the fol­low­ing. Block pub­lisher: This cre­ates new can­di­date blocks to ex­tend the chain.

Block ver­i­fier: This ver­i­fies that can­di­date blocks are pub­lished in ac­cor­dance with con­sen­sus rules.

Fork re­solver: This chooses which fork to use as the chain head for con­sen­sus al­go­rithms that re­sult in a fork. These in­ter­faces are used by the jour­nal com­po­nent. The jour­nal ver­i­fies that all the de­pen­den­cies for the trans­ac­tion batches are sat­is­fied. When ver­i­fied, com­pleted batches are checked for va­lid­ity and fork res­o­lu­tion and then, they are pub­lished within a block.

In­tro­duc­ing Proof of Elapsed Time (PoET)

The con­sen­sus al­go­rithm com­monly used in a Hyper­ledger Saw­tooth net­work is the Proof of Elapsed Time, or PoET, which im­par­tially de­ter­mines who will com­mit a trans­ac­tion to state us­ing a lot­tery func­tion that elects a leader from many dif­fer­ent dis­trib­uted nodes.

Hyper­ledger Saw­tooth’s PoET al­go­rithm dif­fers from the Proof of Work (PoW) al­go­rithm im­ple­mented by the Bit­coin blockchain in that PoW re­lies on vast amounts of power, while PoET is able to en­sure trust and ran­dom­ness in elect­ing a leader, with­out the high power con­sump­tion. PoET al­lows for in­creased scal­a­bil­ity and par­tic­i­pa­tion, as every node in the net­work has an equal op­por­tu­nity to cre­ate the next block on the chain.

How Proof of Elapsed Time (PoET) works

To start with, each val­ida­tor within the net­work re­quests a wait time from an en­clave or a trusted func­tion. This is where the ‘elapsed time’ comes into play. The val­ida­tor with the short­est wait­ing pe­riod for a spe­cific block is appointed the leader and cre­ates the block to be com­mit­ted to the ledger. As a re­sult, a truly ran­dom leader is elected and the

amount of power or type of hard­ware you have will not give you an ad­van­tage. Us­ing sim­ple func­tions, the net­work can ver­ify that the win­ning val­ida­tor did in­deed ‘win’, by prov­ing that it had the short­est time to wait be­fore as­sum­ing the lead­er­ship po­si­tion.

Proof of Elapsed Time is rev­o­lu­tion­ary in its abil­ity to achieve dis­trib­uted con­sen­sus us­ing a lot­tery func­tion. This not only al­lows for easy ver­i­fi­ca­tion and fair­ness within the net­work, but also for in­cred­i­ble scal­a­bil­ity. With­out the heavy costs of par­tic­i­pat­ing in con­sen­sus, any block can par­tic­i­pate in the net­work. One of Hyper­ledger Saw­tooth’s main ad­van­tages is that it al­lows the size of the net­work to scale, i.e., with PoET it can nearly sup­port lim­it­less nodes in the net­work.

Use cases

Hyper­ledger Saw­tooth is a blockchain frame­work with po­ten­tial in IoT, man­u­fac­tur­ing, fi­nance and en­ter­prises. It sup­ports di­verse re­quire­ments, in­clud­ing both per­mis­sioned and per­mis­sion­less de­ploy­ments and a plug­gable con­sen­sus al­go­rithm. This frame­work also pro­vides a rev­o­lu­tion­ary con­sen­sus al­go­rithm, Proof of Elapsed Time (PoET), that al­lows for ver­sa­til­ity and scal­a­bil­ity suited for a va­ri­ety of so­lu­tions which can be broadly clas­si­fied with dif­fer­ent in­fras­truc­tural re­quire­ments, such as:

Per­mis­sioned and per­mis­sion­less in­fras­truc­ture Mod­u­lar blockchain ar­chi­tec­ture

Scal­a­bil­ity, which is good for larger blockchain net­works due to higher through­put

Many lan­guages for trans­ac­tion logic

Hyper­ledger Saw­tooth is an open source project, where ideas and code can be pub­licly dis­cussed, cre­ated and re­viewed. All code is avail­able on GitHub and there are a num­ber of ways that you can get in­volved with the Hyper­ledger com­mu­nity, par­tic­i­pate on the mail­ing lists, start or join a meetup or join the dis­cus­sion on Rocket.Chat, as the fol­low­ing ref­er­ences in­di­cate.

Fig­ure 1: The con­sen­sus in­ter­face in Saw­tooth

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.