Implementation of jurisdictional agility in BEOS blockchain

Preface: A while back I made an introductory post that described how jurisdictional agility (the ability for blockchain users to choose in which jurisdiction their transaction takes place within a geographically distributed network) functions on the BEOS blockchain. This is a follow-up post that describes how this functionality is implemented in BEOS and is primarily intended for a technical audience (blockchain architects and programmers).

Management of block producer jurisdictions in BEOS

BEOS block producers can publish the regions (one or more jurisdictions) in which they are located, and users can specify one or more jurisdictional regions in which their transaction is to be processed.

A BEOS jurisdiction is defined by a unique id code (uint16), a unique name (a lowercase string of less than 256 characters), and a description (a string of less than 256 characters). Jurisdictions are stored as blockchain state data in two C++ multi-indexes: jurisdiction_dictionary_object and jurisdiction_producer_object.

BEOS has a default list of jurisdictions for countries based on ISO 3166 country codes plus the European Union (code 10000) and International Waters (code 10001). Additional jurisdictions can be created by “burning” 1000 BEOS (paid to eosio.null).

The blockchain software for jurisdictional agility does not know anything about logical associations between jurisdictions. For example, the blockchain does not know that Warsaw is located in Poland. So a block producer (BP) must separately publish that it is in Warsaw, Poland, and the European Union in order to be able to process transactions destined for all three of these jurisdictions.

A BP can change its jurisdictions in two ways: 1) directly calling the updateprod action on the eosio.system contract with its set of jurisdiction codes or 2) by calling the update_jurisdictions action defined in the optional gps plugin. This latter method allows a mobile BP (e.g. a block producer on a ship) to use a gps receiver to get its current coordinates then call update_jurisdictions to convert those geo coordinates into one or more jurisdictions which contain those coordinates.

If a BP maintains BP nodes in multiple jurisdictions (e.g. a node in the US and a node in China), they should only publish the jurisdiction(s) of the node that will be producing their upcoming block. This adds predictability to users about what jurisdictions are available in the upcoming round of blocks and makes it possible to determine what jurisdiction was used to produce any block based solely on the jurisdiction history published by the block producers.

eosio.system contract actions for managing jurisdictions

The eosio.system actions below are called by block producers to add new jurisdictions and specify their jurisdictions.

The eosio.system contract also has special actions that can only be performed by the contract owner. These actions are for blockchain configuration (for example, to configure the initially supported jurisdictions and set the fee for creating new jurisdictions).

get_producer_jurisdiction_history

This method returns the jurisdiction changes for a given producer in a given period of time. from_date and to_date are optional. If from_date is not defined, it is set to the beginning of the epoch. If to_date is not defined, it is set to the current time.

Deployed now on BEOS blockchain

All of the above functionalities are fully deployed on the latest version of the BEOS blockchain. Together, they enable both stationary and mobile block producers to publish the current jurisdictions in which they operate and for blockchain users to pick and choose among available jurisdictions to specify where they want their transactions to take place.

This sounds fantastic Dan and we wouldnt expect anything else from such a good dev. I have to admit that im not tecnical enough to understand all of the details, but i love the concept of jurisdictional agility in BEOS.

At Build-it we appreciate How-to tutorials, that being said, we heartily appreciate the time and effort @blocktrades spent in publishing this masterpiece, which is why we've curated this article with a 100% vote from our @build-it.curator account.

That being said, in an attempt to pass this useful information to other technologists out there, could you add the #how-to tag to the list of your tag thus getting more eyes on this work.

A very complete technical information. It is definitely aimed at computer experts in the blockchain programming branch. However, as an average user of the platform, I can appreciate the improvements offered by BEOS blockchain, which seeks to broaden the range of action of the service provided to create an efficient experience for investors and customers in general. I loved the way of writing this document, in addition, in each subtitle a vital point related to the jurisdictional alternative and zoning is developed where the client can choose to have their transaction carried out. I believe that this can positively influence the interoperability of the system, since, the closer the consensus nodes are located, the speed should be greater, generating confidence and security. I congratulate the @blocktrades team for sharing such a brilliant document.

We have to reindex our node after the EOS hardfork and reindexing EOS takes quite a while nowadays. Plus, we had a problem during our first reindex, so we had to begin another one (started on 10/10). It's about half way through the reindex now, so I guess it will be up around 10/18.