Jurisdictional Agility in BEOS
As some of our readers may remember, BlockTrades was contracted by Terradacs to develop the BitShares EOS (BEOS) blockchain. BEOS is a fork of EOS that is focused on business applications and is closely aligned with the BitShares distributed trading blockchain (for those not familiar with BitShares, it could be called the parent of both Steem and EOS, since they both evolved from the BitShares code base). Today I wanted to share some info about one of the upcoming features we’re adding to BEOS that is near to completion: jurisdictional agility.
What is jurisdictional agility?
Jurisdictional agility is the ability to specify “where” you want your blockchain transactions to take place. In existing blockchains, your transaction is usually processed by a random block producer with a server in an unknown location. This adds uncertainty to the basic questions of “where did my transaction take place?” and more importantly, “what legal code applies to my transaction?”.
How is jurisdictional agility being implemented in BEOS?
In BEOS, block producers can publish the regions in which they are located, and users can specify one or more optional jurisdictional regions in which their transaction is to be processed. When a user specifies a jurisdiction for a transaction, that transaction will be delayed until it can be processed by a block producer in one of the regions specified.
To account for the increased potential delay this causes, the expiration time for a transaction with a jurisdiction requirement is automatically increased from the standard 30s expiration time to 200s. If there is currently no block producer producing in one of the requested regions, the transaction will expire and fail after 200s.
How does jurisdictional agility benefit business transactions?
By allowing users to specify where their transactions are processed, BEOS users can gain more legal certainty as to the laws that govern their transactions. This is very similar to the way businesses specify the governing legal jurisdiction in a typical written contract. This can be very important when disputes arise over a payment, for example. Arguments about what region has jurisdiction over a transaction can also be expensive, so the additional clarity provided by a jurisdictionally-aware blockchain can benefit all parties concerned, as it avoids wasteful legal wrangling.
Example using the Greymass wallet to pick a jurisdiction for a transaction
We contributed several changes to the open source Greymass wallet to support selecting jurisdictions for BEOS transactions. Below are screenshots of these changes.
Block producer view showing Block Producer in Portugal
Buy RAM dialog with option to specify jurisdiction where purchase takes place
Dialog for selecting allowable jurisdictions for a transaction
Transaction history showing where transaction was processed (Denmark in this case)
Note that in this case, the UI displays both the requested jurisdictions and the actual jurisdiction where the transaction occurs. This can be important in the case where a user has specified multiple allowable jurisdictions and it later becomes a question of which jurisdiction was ultimately selected.
When Jurisdictional Agility?
We plan to rollout jurisdictional agility for BEOS in the next week or two. The blockchain updates and the associated UI changes are currently undergoing final testing. I'll make another post for those interested in the technical details (i.e. blockchain API calls) at that time.