by Robert Andrews April 18th, 2018
This page proposes the technical infrastructure for Stratis from an IT perspective and a Value Added Features perspective.
Stratis is a blockchain designed to reach businesses who desire blockchain integration. Their model seeks to attract corporate use cases that require the ability to integrate or design blockchain derived services. The normal integration costs (without Stratis) in the blockchain space are very high, primarily due to the rarity of good blockchain programmers. Blockchain programmers are rare because they need to not only have years of c++ and QT experience, but they must be proficient in niche technologies like Berkeley DB (a flavor of database), Bitcoin communications protocols, Bitcoin Script protocols, Coinbase security, Hash functions, Encryption, Cryptocurrency domain knowledge, debugging, RPC functions, and have real world finance knowledge - among other things. (As an example, I personally programmed for 20 years as a Microsoft c# programmer and it still took me a solid year to become proficient in blockchain programming.)
Stratis, Otoh, promises to attract more common (but not less valuable) c# programmers to fill the void. This should technically create lower cost blockchain solutions, provide more programmers per total blockchain budget, and provide higher quality average blockchain programmers (with more IT hands on deck).
The plain vanilla benefits for migrating biblepay to stratis are: we become one of the first cryptocurrencies with a stratis blockchain sync daemon, a biblepay UI, more programmers, more parallel debugging, better support, a higher quality product, and therefore the ability to add cutting edge value-added features into the core. (In contrast to struggling to add cutting edge features - since it is easy to have a ticket backlog and shortage of IT experts with high devleopment costs). This stratis mixture should technically result in a rise in market value, as from an investor perspective, rarity and novelty provide value, and high quality provides more shareholder value.
The plain vanilla "stratis port" would entail the following: A biblepayd stratis daemon (syncing with c# compiled code against .NET-Core), and a biblepay-UI (Angular and NodeJS). Most devs who are already apprehensive about working on the bleeding edge will stop here, port the actual c++ code to c# in order to create a running daemon, and modify the Stratis breeze-UI to work with biblepay.
However, I believe this platform gives us the opportunity to think outside the box, and create a much richer experience in order to accomplish much more "while the engine is on the floor". (IE while the guts from biblepay are strewn around the garage).
One of the barriers in bitcoin-qt programming is the necessity to learn the QT-UI niche, and also learn the format of Crypto data (IE Transactions, vouts, vins, UTXOs etc). My addition to stratis (not alternative), is to add in an SQL data-sync daemon, for Biblepayd-stratis -> Mysql. And, remove breezed (the UI), and instead add a model-view-controller web hosted UI that is hosted directly from biblepayd-stratis (on the local machine). The reason for this is: This particular solution, that is proposed to be included in the Project, as a UI layer, would appear to a new developer as the following: A cross-platform Kestrel MVC web-app, displaying grid data on 25-75 web pages, with data living in a standard MySQL database. Meaning that the plethora of c# programmers could handle modifications to this element of the project. This is value add step 1.
Next we have biblepayd-sync for MySQL. The proposal here is to add a thread to Stratis, with the ability to replicate the Blocks table, the Transaction table, the Wallet, System data, Governance data, Storage data, and any Corporate data (driven by business needs) into mysql in real time, with a sync percentage announced. This syncer would be generic enough to adapt to new blockchain tables (IE tables added in the config), and would auto-recover when things go down and come up, or if a resync occurs. The idea here is to allow standard DBAs to help biblepay write and maintainthe data interface between the biblepayd daemon and the UI, therefore popular certified DBAs could contribute to biblepay by writing reports, stored procs, ansi queries, etc. Note that these reports would not only drive the standard UI, but would allow corporations to extend the Branded UI for their own business. For example, the overview page would be populated by querying the system table, the overview transaction list by an sql query from WalletTable data. And a Mom-and-pop shop could add a page with a Widget report that pulls mysql data and is bound to the weblist through a new menu option they create.
All of this is leading up to a very important feature we gain (other than popular programmers): The ability for biblepay to service corporate blockchain integration requests fully - in harmony with part of Stratis original goal. Stratis wants to consult with companies who need turnkey solutions. Our niche would be gaining corporate interest to provide an entry point for a backoffice or any company to interface with the blockchain specifically with Biblepay. Let me give an example of our value add if we had the above technology: Lets say ShopRite, an African grocery store, wants to sell BiblePay gift cards at the front counter. With stratisd, the learning curve would be relatively high, in that ShopRite would need to tell their internal programmer to learn crypto. However, let us imagine that we have stratisd with mysql-sync built in, and an MVC web UI. In this case, if ShopRite has one c# programmer, odds are high that this person has the proficiency to query the mysql database from query analyzer and write reports. Then ShopRite may add a custom page to the MVC class in-house for a special ShopRite only feature. In addition, since the code is in c#, their programmer may write a query to create daily ShopRite crypto reports (based on the mysql data), and they can Spend the crypto using our Mysql interface (IE insert a spend record, we pick it up and spend it). Imo, this not only extends the Stratis vision, but enhances it in a unique way.
Proposed Stratis infrastructure:
Port Biblepayd to Stratisd (this involves porting the BibleHash, AES encryption, MD5, X11, KJV bible, Genesis Block, Tx Storage field, CPID signing, Block Checking, PODC, etc) Port Biblepay-QT functions to Stratis-MVC compatible (for customized pages) and for Create Stratis-MVC Web Application to host a Web Wallet Interface on http://localhost:7007 for example (MVC will have common.js, jquery, callbacks, events in stratis, and ability to add customer customized code created by customer) Create Stratis-mysqld sync application (this app pushes data from stratisd into mysql, and is smart enough to recover, and also updates the system table with frequently changing information used on the Stratis UI) The MVC-UI will also allow rich graphs and grids and extensible menus to be added to the MVC core app, so that the UI layer can be enhanced and extended without breaking hardcoded functionality. An example is a simple report of CPIDs: 1) Add data to the MySQL Menu table. 2) Add a namespaced function to create a weblist and display data based on an MySql query. 3) Ensure the menu table row points to the new function. When the user restarts the wallet, the menu function will be available. The viewport will automatically contain the "section" (corresponding to the section executing) with the web rendered widget.
Many will be pleasanty surprised to learn that Stratis is not only a Microsoft technology! Technically c# is a cross-platform opensource language. The proprietary confusion comes into play with runtimes. .NET 4.6 for example is a Microsoft runtime. Since Stratis was built on c# .NET-Standard 1.6, it is technically a cross platform solution! Meaning this solution will be able to be compiled on both windows and linux in the future. In addition, the MVC Web Hosted UI above is part of .NET-Standard 1.6, so it too will be cross platform! (There are currently a few functions in the solution that may not port to linux during the first releases, but I am confident those can be resolved.)