PRJ701

Final Project Journal Posts

PRJ701 – 16/09/2018 – Adding MEN to my Stack, Perpetual Inventory and More Accounting

Rationale: “The Ethereum Blockchain just isn’t cutting it for storing the Inventory data and accounting records… I need another form of non-volatile storage to hold all the inventory data and accounting records, one that’s fast, supports ACID and doesn’t have a confirmation popup for every insert or update in a transaction.”

Impulse: “Hey, I’ve got a great idea!”

Rationale: “Oh really? What is it??”

Impulse: “Let’s try to teach ourselves how to use MongoDB in an afternoon and use that to store all the inventory data and accounting records!”

Rationale: “Hmmm… That doesn’t sound like the best idea… trying to implement MongoDB could be more complicated than just learning how to u…”

Wreckless Decision Making: “LET’S DO IT!!!”

Problems With the Solo Blockchain Back-End

I have mentioned in a previous posting that I wanted to try and eliminate the need for a “traditional” centralised back-end database in my app, however, after attempting to implement the accounting functions into the app using only the blockchain, I ran into a few issues.

I believe most of these issues are a limitation of the Ethereum platform for my application, however, they were enough for me to reconsider my options when it came to achieving more “completeness” with the functions that I want to implement in the prototype.

Making “Inserts”

Ultimately, the big issues come from the speed (or lack of) of the Ethereum blockchain, the lack of ACID “transactions” and the gas system.

To implement the perpetual inventory system in conjunction with trying to create and maintain the accounting records I need to do multiple additional operations for:

  1. Creating an Invoice
  2. Signing an Invoice
  3. Paying an Invoice
  4. Receiving Payment for an Invoice

Essentially for the first two functions, I need to update the inventory numbers (current SOH and total current value) and for all three I need to add the appropriate debit and credit entries to the appropriate ledger accounts.

The obvious choice for consistency in this situation would be to bundle all of these operations together in a single “transaction” for each function which for the last 3 functions would actually be okay. The issue arises when creating an invoice which requires the following actions:

  1. Post the Invoice to the Blockchain
  2. Calculate the Average cost of each inventory item
  3. Transfer the cost of each item and the sale price to the ledger accounts
  4. Update the inventory

Sounds simple enough, however, when we break up the logic of this “transaction”, it looks more like this:

  • Update Invoice Struct with New Invoice Details
  • For each invoice line
    • Convert bytes32 into a string
    • split string by the delimiter into an array of SKUs
  • For each SKU in SKU array:
    • Get the current inventory values (SOH and Total value) from Inventory Struct
    • Calculate average cost and store in a local variable
  • Update Accounts Receivable Account – debit the invoice grand total
  • For each SKU in SKU array:
    • Guessing that it gets to about here before:
    • ———-EXCEEDED BLOCK GAS LIMIT ERROR———-
    • Update SKUs Sales Account – credit line total
    • Update SKUs COGS Account – credit SKUs average cost
    • Update SKUs Inventory Account – credit SKUs average cost
  •  For each SKU in SKU array
    • Update Inventory Struct – deduct qty and (average cost * qty)

And here we can start to see the problem, to do all of this in one “transaction” and keep it atomic requires that all of the computation is done on the Blockchain side, which, as it turns out is quite a heavy burden for the Ethereum blockchain, too much in fact as I kept getting the error shown above in red.

Splitting this function up into smaller parts would allow it to “work” however, this implementation would mean the transactions are not atomic and could result in inconsistencies with the records and when it comes to accounting, that is simply not tolerable, not to mention the long wait times as each portion needs to be completed in sequence and the MetaMask popups for each one, over 5 of them actually…

Performing “Selects”

Another issue I have been having is to do with retrieving (“selecting”) data from the blockchain, it is cumbersome at best and a nightmare any other time.

Despite refactoring as best I could, just getting a list of all the invoices and turning it into “human-friendly” information takes 5 different functions, that doesn’t include actually displaying them on screen or allow for any kind of filtering (i.e. dates, companies, status) every single invoice needs to be pulled from the blockchain into memory and processed locally each time, with less than 100 “test” invoices it takes about 40 seconds, now imagine doing that for a corporation with hundreds of thousands of invoices.

Then imagine a company with thousands of inventory items and ledger accounts… pulling ALL of that information down to perform operations on just a few would be ridiculous.

And alas, this is where I have had to make an important decision and I have come to a major finding in trying to build my project.

Implementing the “Extended” MEAN Stack

1 Traditional MEAN stack

Traditional MEAN Stack

In order to combat the issues with the Blockchain, I decided to implement the rest of the MEAN stack (as I am already using Angular.js for the front-end) which as shown above includes: MongoDB, the Express framework, Angular.js and Node.js.

As I will also be using Ethereum as a back-end, I have coined my current set up the MEEAN stack, shown below.

2 Modified MEEAN stack

“Extended” MEEAN Stack

This allows me (and potentially many other developers that use this (or the MERN stack which uses the React framework instead of Angular)) to do many things that are otherwise not possible while using Ethereum as the sole “back-end” or database.

The main function that the MongoDB serves is to provide a lightning fast non-volatile storage solution with each entry containing a “pointer” to the information stored on the Blockchain. So, for example, the Inventory Ledger accounts records for an item would look something like this (i’m yet to finalise the design) in the MongoDB database:

{
accountCode: 601
name: [SKU/Item name] Inventory
category: Asset
debits:
  {
    {
      date: 12/09/2018,
      amount: 200,
      blockchainTransactionHash: 0xabcd1234567890
    }
    {
      date: 15/09/2018,
      amount: 200,
      blockchainTransactionHash: 0x2468abcdefghij
    }  
  }
credits:
  {
    {
      date: 13/09/2018,
      amount: 200,
      blockchainTransactionHash: 0xlmno0987654321
    }
    {
      date: 16/09/2018,
      amount: 200,
      blockchainTransactionHash: 0xpqrs2468135790
    }  
  }
}

This would allow me to do a few things, firstly, I can query the MongoDB and return only the records within a specific date range (i.e. the current or previous reporting periods) and secondly I can use the “blockchainTransactionHash” value to validate the records.

Perpetual Inventory System

I will also be using the MongoDB for the inventory system, currently, I have implemented the “sales” side of the inventory system which means when an invoice is created the inventory items document is updated with the new numbers (SOH and Total Value) and all of an items transactions are stored as a sub-document, it looks like this in the database:

I am yet to finalise where the invoice numbers will be coming from in the system (currently it is using only one incrementing number on the blockchain which means that companies cannot have their own numbering schemes) so the “Ref” field doesn’t contain the invoice number yet but this provides an audit trail for where the inventory is coming from or going to.

What Else Can it Do?

Another example of where this could be used (although I won’t be implementing it), it to monitor the blockchain and check each new block as it is added to determine whether it contains any transactions, and make a records of all the blocks that do alter a balance with the date and block number, this would allow me to see the “historical balance” of a blockchain account for a particular period (something that is currently not possible with Ethereum alone).

Considerations

There are, however, still a few things to consider with this stack design particularly for an accounting application. The main one is that, yes, it is still possible for there to be an inconsistency between the records on the Blockchain and in the MongoDB, the risk of this could potentially be reduced by using a messaging service like RabbitMQ but that definitely falls into the “work that could be done in the future” basket.

I hate to keep going back to this, however, EOS has a MongoDB plugin built-in which would actually do all of this for me but I have come too far with the Ethereum development to switch over now and still there are no great tutorials on building a front end for an EOS dApp.

Is MongoDB Really Viable for an Accounting Application in 2018?

Anyone reading this that has developed an accounting system might be thinking, but Corben, MongoDB is an awful choice for an accounting database! And, up until version 4.0 that may have been true.

One of the biggest arguments has been that MongoDB didn’t have ACID support for multi-document updates, which is inherently a trait that is required by an accounting system, however, this all changed on the release of MongoDB version 4.0 when they introduced proper multi-document “transactions” with full ACID support, meaning that, just like a relational database, all records are updated or everything is rolled back.

Another argument is that relational models are the perfect design for storing accounting data because, unlike most real-world data, accounting data is actually tabular and fits extremely well into a relational model. And actually, I have to agree with this argument, a traditional relational database would most likely be a better fit for my application, however, I believe that MongoDB will handle it just fine and I went with this option for two main reasons:

First and foremost, because over the last few years I have had a lot of interaction with SQL databases including MS Access, MySQL and SQL Server, but thus far I have never used MongoDB or any NoSQL databases for that matter, so I’m doing it for the experience (another plus is that this also gives me experience using NodeJS and Express).

And secondly, because it just seemed much easier to implement into my current stack, no need for creating a normalised design, working out joins or Object Relational Mapping.

This late in the game trying to add the kind of complexity that would come with an SQL design is a bad idea, plus my experience in using the various SQL systems as well as various programming languages translated rather easily to MongoDB as the concepts are similar but, in my opinion, far simpler, which meant I really could pick up the necessities in an afternoon, learning to use Express and the MongoDB API (and Mongoose) to build a RESTful API was actually much harder, but a lot of fun.

Goals for Next Week

Phew! This brings me to the conclusion of another week and to making plans for next week, this week was quite heavy although I have not moved forward much it has involved a lot of problem-solving, causing me to neglect my DAT701 assignment quite a lot (Sorry Nick! and myself 😓) but next week, unrelated to the Project: I need to finish my DAT assignment.

Related to the project, I need to really get cracking on the back-end of the accounting system and finish up the inventory system so I can finally get some data in! Only 3 weeks behind schedule…

this-is-fine.0

But the delay has come because I now realise that the back-end of the accounting system needs to be functional (i.e. capturing the necessary data in the ledger accounts and inventory) at the time invoices are being created, signed and paid so I cannot begin to add test data until this is functional so that will be the only goal for next week.

Advertisements

PRJ701 – 09/09/2018 – Accounting, Accounting and more Accounting

I stated last week that I wanted to increase the number of Blockchain accounts and products that I have in my system and to finally start generating test data, however, this week I have spent a great deal of time refreshing and trying to extend my Accounting knowledge so that I can analyse/organise the transactions into debits and credits against the appropriate accounts, I had a meeting with Sandra to discuss some details and she provided me with some learning material to work through.

The reason that I did not start generating the test data this week is that I feel like I may need to modify my current system further to include additional information about each transaction in order to get the accounting side of thing correct.

Initial Gathering Transaction Information

At the beginning of the week, I started working on gathering and organising the information that relates to the different invoices, this resulted in me plotting the information on a couple of graphs

accountingDash

First Display of Accounting Dashboard

The “Accounting Dashboard” is a new section of my web application that will most likely “tie-in” with the other Accounting sections (Balance Sheet and General Ledger) as a single page app because they will all require fetching the same invoice data from the blockchain to generate.

Meeting with Sandra

Chart of Accounts and Inventory Systems

In my meeting with Sandra, we went over the chart of accounts that I added to last weeks post, and we discussed the logistics of accounting around inventory and the “triple entry” example I posted.

In the example (re-posted below) I provided, it assumes a perpetual system for accounting for inventory, which, in laymen’s terms, means that each inventory item is accounted for at the time of a sales entry.

triple entry example

The advantage of this is that accounting for inventory is done in “real time” meaning that, at any given time a business will know the value of their current available inventory. However, the trade-off is that accounting with this kind of system is logistically more complex.

At the time Sandra suggested that I should instead use a periodic system in order to simplify the accounting. As the name suggests, in a periodic system inventory is accounted for (reconciled) in periods rather than item by item, which would remove the need to account for the inventory at the time of the “sale”.

The disadvantage of this is that the inventory is not accounted for in “real time” which takes away slightly from the original idea of completely real-time automated accounting, however, shifting from a periodic system to a perpetual system could be left as a “pending” or “incomplete” use-case for the prototype.

In saying that, Sandra later sent me an email explaining how I could actually use a perpetual system instead, I have only skim read it so far so next week I will read it properly and look at how I can implement this.

The “Ultimate”(…or just better) Blockchain Idea for Business Use

It is stated in my proposal that my research is based on an “idealistic and theorised” scenario where businesses would utilise a shared platform for mutual benefits. However, I have not really provided a great context for this system, but this is something that I discussed with Sandra so I thought that I should share my ideas.

infoGraphicChains

How the System Should Work

The above infographic outlines a basic representation of how the system would work in terms of transferring “value” on a national or international basis, solving what I call the “volatility problem” of current cryptocurrencies such as Ether or Bitcoin.

In my view, the biggest problem with current cryptocurrencies is that their “value” fluctuates wildly, which means that making purchases in these currencies poses a huge risk of either paying far too much or, less likely, far too little.

This happens because 1 Bitcoin/Ether will not be worth the same amount today as it is tomorrow, or sometimes even in a few hours, this means that if you purchase something with $100NZD worth of bitcoin today, that same amount of bitcoin could be worth $200NZD tomorrow, which essentially means that you paid twice the intended price. (see this video where Olaf Carlson-Wee explains how he “accidentally” made some of his friends “thousands and thousands of dollars” just for buying him pizzas in exchange for what was then only $20USD worth of bitcoin).

The difference with my design compared to the current volatile cryptocurrencies is that, in this design, 1 local “token” would always be worth 1 denomination of the local currency, nothing more and nothing less.

For this to work, every country would need its own local “side chain” for exchanging its local token and a global chain would be needed to manage international transfers making sure they are made at the current global exchange rates. There would also need to be a system in place where tokens could be exchanged for fiat currencies.

This would work well for business to business transactions, however, when it comes to general consumers dealing with a business (which far exceeds the scope of my project but was worth a thought), it could be imagined that they too would have access to the local chain and use it in a similar way as they currently do with their banks, either with an account to account transfer or possibly even an “EFTPOS” like transaction using either specialised cards or, more likely, NFC payments from a digital wallet on their smartphones.

Logistics of Purchasing

poFlow

Purchase Order Cycle

This is just a basic flow diagram of purchase orders, showing Company A sending a PO to Company B. The idea is nothing new and it is something that also greatly exceeds the scope of my project but I feel that it is worth a thought for additional context. Thinking that this entire flow could also be tracked on a blockchain as a part of the overall system could mean that inventory could potentially be easily serialized, tracking products from the original order right through to the sale.

In “theory” this information could be used to remove the need to either calculate a weighted average cost or using the Fist in First out (FIFO) method for the Cost of Goods Sold accounting entries, however, this is something that I really don’t know enough about to speculate so I could be completely wrong with this.

Accounting, Accounting, Accounting

This is where the bulk of my work has been this week. I have been focussing on how I will integrate the accounting side of the system and what information I need to gather, what information I may need to have fixed “demo” data for to make the general ledger/balance sheet “complete” and how I can automate the process as much as possible.

accountingCert

Lynda.com Bookkeeping Certificate

I completed a basic Bookkeeping course on Lynda.com to refresh and extend my knowledge, which gave me a shiny Lynda certificate, so yeah… I’m practically a fully Certified Accountant now… right? 😎🤣

On a more serious note, the original idea of my project was to make the whole bookkeeping process automated and immutable, however, thus far I have simply made an extremely basic invoicing system with integrated payments that do have an immutable audit trail but this system couldn’t realistically select the appropriate accounts for an invoice. As my learning progresses in the accounting side of the system, I am coming to realise that I may not be able to completely automate the bookkeeping process in a way that would scale for generic use by any kind of business.

This is not to say that I think that it would be impossible, however, I just now believe that it would also require the assistance of some form of AI/Machine Learning, which is another step way, WAY outside the scope of my project, however, platforms like botkeeper and SMACC come to mind.

Nonetheless, I will focus on the main objective of my project and aim to deliver a triple entry system as a point of discussion around how businesses *could* use this kind of system to potentially automate their bookkeeping.

What I need to remember for my project thus far seems fairly basic and comes down to four main things, three are shown below, with the 1) basic accounting equation, 2) the effect that debits and credits have on the different types of accounts, 3) what kind of balance each account type has and the 4th thing, not shown below, is knowing which accounts to use for the various functions of my system.

debits and credits increase or decrease

Reference Material (Accounting Equation, When to Debit or Credit and Typical Balance Type)

Goals for Next Week

It feels like my progress has slowed down considerably this week with only minor achievements, however, I feel like my knowledge is improving and that will help me in the long run.

I do feel as though I am behind schedule slightly and I will need to focus to stay on track, however, I now also have my DAT701 assignment to complete so that will no doubt take away from my work on the project for the next couple of weeks.

Next week my biggest objective is to jump back into coding so that I can attempt to get the information from the invoices turned into debits and credits on various accounts and toy with what changes I need to make to get things moving.

PRJ701 – 01/09-2018 – Transactions, Refactoring, Accounting and the Xero Demo Company

This week has been another busy one, most of my time has been spent on learning and refactoring while I consider my options to overcome the current issues I am facing. Because tomorrow is Father’s Day in New Zealand and, being that I am a proud father (with a fantastic father of my own), I look forward to spending that day with my family, so I am shaking things up and posting this a day earlier than I have been. So let’s jump into it!

Arbitrary Transactions

One of the goals that I set for myself last week was to complete the “Make a Payment” page of the application and to work on the “transaction list”. The first part of this goal was actually surprisingly easy in comparison to everything that I have done so far! I made a simple UI, and wrote some, again, surprisingly simple code, which allowed my application to send Ether from one account to another with a custom “data” field.

make a payment ui

Basic Make Payment UI

This is the basic UI that I came up with, it allows the user to select an account from their “list of accounts”, enter an optional reference number for the payment, select the accounting categories and write some notes about the transaction. Once the user clicks “Submit” this information gets “packaged” up using this code:

transaction code

Packaging the Transaction

First, the code runs off to another function to make sure the users’ input is valid, once this check is done the transaction is put into a variable, that includes the basic to/from and value but it also includes a “gas” value, which is specific to Ethereum and is a necessary evil, but the magic happens in the “data” field. Here, the reference number, the categories and the notes get turned into a reversible hash which will eventually be stored on the blockchain as part of the transaction. Once this is done the transaction variable is sent to this function:

transaction code 2

Sending the Transaction

Which actually sends the transaction to the Blockchain. This was all well and good, and super simple! The problem, however, arose when I looked at trying to get the transaction details back from the Blockchain, as it turns out, when it comes to arbitrary transactions like this, there is no simple way of retrieving all the transaction related to a specific account (on the Ethereum platform… +1 for the EOS platform 😮 ) This is something I spent hours on and actually managed to crash my laptop a couple of times trying to accomplish.

Because these transactions are not “indexed” you cannot simply call a function that returns them, this means that in order to get all of the transactions related to a specific account, you need to run all of the blocks, right from the genesis block all the way to the current (“latest”/”pending”) block, through a series of “if” statements.

What’s the big problem with that? Well, it is extremely slow and it seems to require a LOT of computing power to scan more than a couple of thousand blocks. When I attempted to scan my entire local blockchain (consisting of just over 150,000 blocks) Chrome ended up eating 100% of both my RAM and my Processor, grinding my computer to a halt and eventually crashing Chrome along with the test web server as well.

The good news, however, is that if you already know the transaction hash, you can get all the transactions details really quickly. But how do you ensure that the hash is known? Well, there would be a few options here. Ethereum does store and indexed log of information when an “event” is emitted on a contract, this means that:

  1. We can use a Smart Contract to handle the payment OR,
  2. We can send a Smart Contract the Hash after the transfer confirmation

Another option would be to store the hash in some other form of database at the time of the transaction, however, since I am aiming to remove the need to do this, and this is a limitation of the Ethereum platform which could be solved in the future or with a different platform, I first opted for option 2 above.

You may notice that inside the snippet above of the “submitPayment” function that there is another function call circled in red, this essentially makes another call to a new smart contract that I created which stores the transaction hash. One problem with this is that it requires another confirmation from the MetaMask plugin and if the user was to click “Cancel”, or even if the contract call failed, then the transaction hash would be lost.

As this is a limitation of Ethereum I chalked this clunkyness up to the application being a prototype and this allowed me to produce a list like this:

transaction list ui

List of Transactions with Categories, References and Notes.

But this is where I decided to stop for the moment so that I could take some time to do some more research and evaluate where I was going (which I will discuss more below in the “Accounting” section).

Refactoring

Before I got stuck into my research I took a long hard look at my code thus far and thought to myself… WHAT AN ABSOLUTE MESS!!!

  • Messy/unformatted code
  • Random console.logs everywhere
  • Unnecessary variables
  • Repeated code
  • Code in places it shouldn’t be

My application had it all and all sorts of other over complications so, before proceeding to make it more complex, I decided I needed to spend some time simplifying what I had, making it more efficient and easier to read.

This took a considerable amount of time, however, I felt it was well worth it in the end and will make my life easier moving forward.

Refactoring doesn’t usually lead to adding new features, however, a natural side effect of my refactoring process also helped me to partially achieve one of my other goals from last week, and that was enabling the use of multiple accounts in the application so I could really start sending “invoices” to different accounts and see this reflected in the list of invoices.

The Xero Demo Company

So, before moving forward with further development, I wanted to do some more research into the Accounting requirements before I started developing things that were potentially an unnecessary waste of time.

What better way to do that than to evaluate a real, well polished, application that does many of the things that I’m aiming to achieve in my project. Enter Xero, you know, only one of the best accounting applications around at the moment. Xero is kind enough to have an offer available to students which allows them to start a free trial to use and explore their applications features with a demo company (this is also available to everyday users as well) which is something that Sandra mentioned to me in our first meeting.

Looking at the overall layout and features of Xero really opened my eyes as to where I needed to be going and, to my surprise, I already had a lot of the necessary information bouncing around my application to produce some of the reports, I just need to organise it! (more in “Accounting” below)

Seeing the way that Xero can directly integrate a business’s bank account also got me thinking of ways that Xero could integrate Blockchain into their system, other than with Veem (insert shameless plug in case someone from Xero happens to read this and wants to hire me 😉 ).

Accounting

After reviewing what I have completed so far and looking at a real accounting solution, the logistics of my system have started to organise themselves far better in my head and I feel that, from here on, I will be referring to Xero’s features and layout more often to keep me on track.

More on the “make a payment” page: Since looking at the Xero application I have decided that I will remove this from the scope of my prototype, this is because I feel like I can achieve my project goals adequately without this feature and, for the purpose of my prototype, things like utility payments etc. can be achieved with a bill (aka an invoice) if necessary.

More on organising the information: In order to organise the information that I have, I need to create a basic Chart of Accounts that debits and credits will be going in and out of, this is what I have come up with so far:

Chart of accounts proto

First Iteration Chart of Accounts

I would like to check this off with Sandra and see if she thinks that it would be suitable for the system I am creating or, even better, if it could be simplified.

Another idea I need to wrap my head around is how the triple entry would “look” to put it in a visual context, take the example below, which shows a simplified version of how the triple entry would work if Company B was to purchase an inventory item from Company A on account (aka using my applications invoice system).

triple entry example

Triple Entry Example for Purchase of Inventory

My next challenge will be collecting and organising the information from the current system so that I can display it in a way that makes sense in terms of the “double entry system” using the support of the triple entries, depending on the account that is currently logged in with the MetaMask extension.

Finishing Sent and Received Invoices

After refactoring my code and enabling the ability to send invoices between different accounts instead of just using the single test account, it was time to finish up the front end. Now when a supplier opens one of their sent invoices they can see the status at the top, and the header colour changes depending on the supplier (not overly fancy but small steps and… it’s only a prototype 😀 )

And, as I included in last weeks post, the receiver of the invoice can sign (approve) and pay the invoices with the floating options on the side.

Goals for Next Week

Next week I would like to expand the number of accounts that I can “interact” with within the system. The end goal of the project is to have a small business transactional environment so I will be primarily focused on populating just one or two of the “companies” with test data while the other “companies” will be there to provide “diversity” and certain types of bills/invoices. I would also like to change/expand the current product list to something larger and more realistic.

Both of these goals should be much easier to achieve after refactoring as I now have company and product details stored in JSON files instead of being dotted all over the place which makes adding companies or products as simple as adding another block in the JSON file.

Once I have all of that in place, I will reset my local Blockchain and, finally, start populating it with the test data, then I can get more seriously started with working on the accounting side of the application.

PRJ701 -26/08/2018 – [insert great blog title here]

Another week down and another round of progress towards the end goals. This week has been eventful, I had my first meeting with Sandra and participated in the first seminar session, as well as made some more progress in terms of the development of the project artifact and contemplating a decision around the virtual environment portion of my project.

Meeting with Sandra

As mentioned above, I had my first meeting with Sandra, in this meeting we discussed my overall project and my main objectives for the project, we also discussed the potential implications of my project being taking from a prototype into production on a wide scale, which was an exciting prospect for us both.

We also briefed over the potential change I am considering (more on this below) and I demonstrated what I had achieved so far.

After my meeting with Sandra I feel even more excited to work on this project and feel extremely confident that she will be a fantastic supervisor overall. Further to this, having the additional support of her advanced Accounting knowledge to support my fairly basic and limited existing knowledge fills me with even more confidence.

Another Potential Change to my Original Proposal

I stated in my previous blog that my main goal and focus for this week would be to set up the virtual environment and deploying the Blockchain across the multiple hosts.

My initial plan was to run multiple instances of Ubuntu within different subnets and connect them with one (or more) instance(s) of VyOS, however, after my discussion with Sandra I have started contemplating a change in my plan to remove the virtual environment component from the overall scope of my project.

The primary reason I am considering dropping this component of my project is because I am unsure if it will really add any great benefit towards the actual end goal of my project, my reason for including this component as part of my project in the first place was purely so that my project made strong use of all the knowledge I have accumulated throughout my studies so far (from Infrastructure, Software Development and, most importantly, Information Systems).

The second reason I am considering removing it from the project is that it is a large amount of work to add on to an already rather large project with potential of running into more considerable roadblocks while trying to get the Blockchain nodes communicating over the virtual network.

The third, and final, reason I am considering removing it from the project is that, even after working on for another full week, my platform is simply not ready to be deployed “permanently” (without modifications etc.) and this may be an issue that will be ongoing throughout my project as my research and development continues and requirements (inevitably) change.

So as it stands, I have decided to put this portion of my project on hold and focus purely on the payments and accounting systems and if nearing the end I still have some time I will reconsider building the virtual environment as I can always deploy the nodes with a copy my local “test net” Blockchain.

Seminar Session

As I mentioned last week, I had the first seminar session and Thursday. The seminar session was interesting to attend but, to my surprise and despite it being a compulsory session, there seemed to be many people who did not attend.

It was interesting to hear what other students are doing with their project and how they are progressing so far and it seems like most people are making good progress. I was interested to hear about what other students planned to do with Blockchain, and I look forward to seeing what results they have come up with in the next seminar.

Other projects I look forward to learning more about are the Ben’s AI integrated website, Benji’s Car configuration website and Will’s more tradtional web app.

Back-End Work, Signing and Paying

The back-end work this week primarily consisted of adding two functions, signInvoice and payInvoice, the first function is important from an accounting perspective because this essentially acts as the invoice authorization, and the second is important for… well… making the invoicing system useful? Some would even say that it is essential functionality.

In all seriousness though, the main function here is signInvoice as the payInvoice function was trivial to write at best and is not overly special, now customers can pay invoices, great! What’s important about the sigInvoice function is that it makes use of the Blockchains cryptography to authorize the invoice.

It works using a Public/Private key pair, where the customer uses their private key to “sign” an arbitrary message (example shown below), which is then recorded on the Blockchain as a) an encrypted string which acts as the “signature” and b) a verified transaction. This “signature” can then be retrieved from the Blockchain and decrypted. This ensures that the authorization is authentic because it can only be decrypted using the customers public key and if the keys don’t match then the signing will fail.

7 signature

Code for Example “Signature”

The above code snippet shows the example “signature” that I have come up with, this may not be accurate or contain enough information, however, when run through the function it takes a string like this:

Formal Approval for Invoice Number: 996782431 – Amount Payable: $22,632 – From: Company A – Account: bb1a3d0f52fa761fc48eb16c9fd8eb02385c8e70 – To: Company B – Account: 6044ca16e88a572900871b4f3ce791f710f6072f

And turns it into a hash like this:

0xc30a6ecc1af1fb39adeb443914cc0a4bccd4a31169048dc7bdb9ceb536b5c9cf5282b156b2f84defdb6d35e902fda4e9c5b14ca570202e4b70cd8e1fc3ad2a9c1c

Which can then be decrypted using the buyers public key for verification that the invoice was in fact approved by the buyer.

Front-End Work

In contrast to last weeks Back-End focus, this week has been all about getting information from the back end to the front end, making sense of it and displaying it in a clear format, as well as cleaning up my “testing” functions and turning them into proper functions.

Listing Invoices

After last weeks progress of being able to publish invoices to the Blockchain and get basic details back into the console, it was time to get those details into the front end.

The first step was to get the list of invoices, I assumed that this was going to be a trivial task as I was already able to get the details of each invoice individually, so I assumed I would be able to run a for loop and get all the invoices, then I would just need to format and display it, however, I had to do some additional learning about JavaScript Callbacks and Promises as well as Synchronous and Asynchronous programming.

The problem was that when the code ran, it would not wait for a response from the Blockchain before continuing, this meant that variables were left undefined while the code attempted a concurrent call to the Blockchain (which it doesn’t handle well). After some research I figured out how to get the code to wait for a response and eventually, ended up with a list like this:

1 Listing Invoices

Listing all Invoices

Success! Next, it was on to displaying all the details in my invoice template, again, this was not quite as simple as I first anticipated.

Because I was already getting all the invoice details I figured that I could simply pass the variables containing the details to a new window and use AngularJS to bind them to the various elements of the invoice template.

As with many things, this was easier said than done. The hardest part was sending the variables to the template window, however, after some further research I managed to do it using some more Angular magic ($window.open) and spent quite some time working with the bindings. The end result:

2 Invoice Template

Invoice details retrieved from the Blockchain

A fully functional, dynamic HTML invoice template. If only my descriptions were more… descriptive… 😉 Now that I could open the invoices, I needed to add the basic accounting functionality (signing and paying).

To do this, I added a small options card to the side of the invoice template which has different states depending on the invoice state, and will eventually change depending on whether the active account is the “supplier” or the “customer”, but small steps for now!

This slideshow requires JavaScript.

Goals for Next Week

Now that I have the invoicing system mostly up and running, I want to focus of using it from the different perspectives, currently it is very much in a testing type scenario where I am only using one Blockchain account to act as both the supplier and customer (to themselves) so I would like to alter this so that I can switch accounts and filter information depending on the active account.

Also, I would like to start working on the “Make a Payment” page of my app, where one account can send payments to another and include classifications for the payments.

If I manage to get all of that done, then I would like to start working on getting lists of transactions for the accounting side of the app.

According to the planned schedule in my proposal, I was aiming to start populating the Blockchain with test data next week as well. This will all be dependent on my progress and may need to be pushed back to the following week.

PRJ701 – 19/08/2018 – Proposal Approved!

Wow, here we are at the end of week 4 already! However, on Friday (the 17th) evening I received the fantastic news that my proposal had been approved and my supervisor will be Sandra!

This means that the last few weeks of researching and learning have put me off to a great start with my project. Now I hope to continue that momentum and keep things on track with my timeline, although, all of the tasks that I’ve set for myself have been taking far, far longer than I anticipated (as they normally do when experimenting and learning new things) so I am not as far along as I had hoped but I am hoping to pull that back next week (we should always be hopeful right?).

Back-End, Solidity Development

So my first task this week was to get started on the Back-End of my system. For this, I need to use Solidity to generate a “smart contract” that will essentially act as the “invoice”.

Thinking from a high-level, an invoice is essentially a contract between two parties, for example:

  • Party ‘A’ agrees to:
    • supply party ‘B’
    • with ‘X’ goods/services
    • for ‘Y’ price
  • and,
  • Party ‘B’ agrees to:
    • pay party ‘A’
    • ‘Y’ amount
    • for receiving ‘X’ goods/services

Now, I needed to design a way to take the information from my Front-End template and store it in the smart contract. The greatest challenge with this is that, because an invoice does not have a defined number of lines, I cannot specify a defined invoice structure, further to this, Solidity does not support relational modeling very well (because it was not designed to).

String Arrays and Solidity Limitations

In my initial attempt, I wanted to use an array of strings inside the invoice struct that would hold the line details as a delimited list, however, upon trying to put this into action I ran into another limitation of the Solidity language, which is that (at this time) it does not support passing an array of strings to, and returning them from, functions. Obviously, that ruled this option out (or so I thought, more on this later).

Relational Modeling in Solidity and Breaking ACID

My second idea was to attempt using the slightly more complicated method, found here, to create a sort of “relational” structure inside of the contract, utilizing multiple structs (one for the main invoice and one for the individual lines) and creating a sort of “primary/foreign key” relationship between them. For the start this seemed like a promising option, however, it was only after creating the contract and attempting to test it/integrate it with the front-end that I realised a fatal flaw of this design, it leaves the possibility of incomplete data being written to the blockchain and, particularly for my use case, that is not a risk that can be taken.

The reason for this is that each write to a struct has to be made as a separate transaction, one for the primary invoice details and another for each line of the invoice and once a transaction has been made it cannot be rolled back, so, for example, an invoice with two lines would require three transactions:

  • Tx1 Invoice Header Details
  • TX1 First invoice line
  • TX3 Second invoice line

and if Tx1 was successful, it is permanently on the chain, but if Tx2 fails, then Tx3 is successful, there would be an invoice that is missing a line, the record would be incomplete. This scenario is simply unacceptable for my application.

Further to this, submitting the invoice feels like an old Windows Vista security prompt nightmare because there is a prompt to confirm each individual transaction and, as far as I’m aware, it is by design, and there is no way to avoid this.

It would be an ideal scenario if I could do both the invoice details and the lines in a single transaction, but I cannot find a way to do that using this design so, because of this, I have decided to move on from this solution and look for another alternative.

Maybe a Solidity/Web3 guru might read this one day and post a comment with a potential solution for future use? always hopeful 😉

Additional Cryptography?

Another thought that I did have was finding/using some sort of two-way hash function to turn the entire invoice into an encrypted hash and simply store the hash on the Blockchain which I could then retrieve and decrypt locally to get all of the invoice details. This option would probably require a substantial amount of additional research and really exceeds the scope of this project but it was worth a thought.

Bytes Over Strings

After furthering my research and developing my knowledge, it has become apparent to me that, in general, Solidity appears to prefer the use of Byte type variables over String types, this got me thinking again about using an array of delimited information and I realised that Solidity can, in fact, handle passing an array of Byte types to and from functions so, as it turns out, I could have simply substituted the array of strings for an array of bytes and it would have worked perfectly at the start of the week!

Well… Almost perfectly, the one small issue is again due to hitting limitations within Solidity. This is because the byte “string” cannot be longer than 32 characters, which as you can see below, means some information gets lost, see on “line 3” for the freight that the quantity and discount get cut off, this should be a simple fix though.

sendingDetails

Invoice to be Sent

fetchingInvoiceDetails

Basic Invoice details in the console

Overall I am pretty happy with my progress this week. I can now, finally, successfully submit an invoice to the test network and retrieve its details, even if I can only see them in the console at this point, it’s one step closer.

Front-End Work

Although most of the work this week has been “back-end” focused, I did have some basic goals for the front-end this week too, I wanted to complete the Invoice Template and I wanted to create a menu to help me mentally scope the pages that need to be available in the prototype and their functionalities.

Menu_v1

First iteration menu for the Prototype Application

This is just a rough brainstorm of which menu options will need to be available and working in the prototype. I have split it into two categories:

  • Accounting
    • Transactions will list all transactions and their classifications
    • Balance Sheet will look at specific accounts
    • General Ledger will look at all the accounts
  • Invoicing
    • Create Invoice is where the bulk of my work has been so far, it shouldn’t need much explanation
    • Sent/Received Invoices will list all invoices either sent or received…
    • Make a payment will be for general business to business payments/expenses without invoices, maybe?
Tax_Invoice_Template

Blank Invoice Template

I didn’t want to spend too much time on the invoice template as this is just a simple prototype, this is what I slapped together, it’s not overly pretty but it is functional. When the user clicks on the invoice details button (sent/received) this is what will pop up.

Goals for Next Week

Gosh, things are moving fast! According to my initial plan, next week I need to start working on the virtualized environment and look into how I am going to deploy the multi-host multi-node blockchain network so that will be goal number one for next week.

To successfully deploy the distributed network also means that I would need the platform to be developed enough that I am able to send invoices, process their payments and also send other arbitrary payments, of which, I can currently only send invoices. So, I feel like I am slightly behind in my schedule and need to start working hard to catch up and get these elements completed as quickly as I can, so working hard on the platform will continue to be on the priority list, most notably, being able to make payments on the invoices and making any other arbitrary payments.

Also, the first seminar session will be on Thursday next week (the 23rd) which I am looking forward to as everyone will be sharing their progress and going more in-depth about their projects and I’m sure will be interesting to hear more details about what everyone else is doing.

PRJ701 – 12/08/2018 – Continued Research and Prototyping

It has been a relatively slow week this week as I am still awaiting approval for my proposal, however, I am hoping to hear back about it by the end of the coming week. In the meantime, I have been doing further research into meeting the requirements of my project and the development tools available.

Ethereum Learning

So far I have been researching “smart contract” development and looking into ways of storing the invoice details, one of the challenges is thinking about how I am going to be storing the structure of a multi-line invoice inside a smart contract, so far I have two ideas:

  1. Use an array of delimited strings inside of the invoice struct
  2. Use a “relational” method with multiple structs (more information here)

Both of which present their own unique challenges.

Front End

On top of my Ethereum learning, I have been working on designing the front end prototype, the greatest challenges here were:

  1. Making a template that allows new lines to be added dynamically
  2. Calculating the totals across the multiple lines and,
  3. Enforcing the error handling constraints

For this, I have opted to use AngularJS as it is somewhat familiar and there is a multitude of tutorials and other resources available for making dynamic HTML/JS invoices with Angular. Here is what I have come up with so far:

1 Invoice Creation

The basic idea in this template could be adapted for small/independent businesses or larger/corporate businesses/enterprises. I have designed it with the thought that the product section would be linked to a database with set products at fixed prices, which can then be adjusted with the discount field.

Currently, the design allows for multiple lines to be added and calculates the totals (line totals, overall subtotal, GST (at 15%) and grand total) in real time as variables are adjusted and error checking is done on submit (so you cannot submit an invoice with no product lines, cannot submit blank lines, must select a customer and enter a payment due date).

As the aim of my project is to create a simple prototype I won’t be diving too much further into complex features or systems, however, you could imagine in larger scenarios that the invoicing system could be integrated into a purchase order/dispatch system, both of which would be linked to some sort of product catalogue database or in smaller scenarios the user could enter product descriptions and costs manually.

But for now, I am happy with what I have. Next, I will need to design the back-end and figure out how to capture this information and I will need to figure out how to retrieve it also so that I can display it in a list, something like this:

2 sent invoices

Then I will need to figure out how to generate a complete invoice when the user clicks the “Details” button.

Currently, I am working on the invoice template and will then start working on the back end. Once that is done I’ll start work on linking it together and, finally, the accounting stuff.

PRJ701 – 05/12/2018 – Pending Approval

This week has been a busy one, pending approval of my proposal I have been spending a lot of time looking for learning resources and doing preliminary research around the different blockchain platforms that are available and how I could use them to develop my project.

Deviating from my Proposal Already

Choice of Blockchain Platform

In my proposal, I mentioned that I would like to use the EOS platform as a base to build my project on. The reason for that is because the EOS platform can process transactions much, MUCH, faster than any other platform (which is absolutely crucial for fast-paced business environments), and deploying a private blockchain which allows the exchange of currency types other than the usual (ETH or BTC) is really very easy.

Through my research and resource gathering for this platform, I managed to deploy a single-node test-net, use the CLI to set up some wallets and accounts and transfer some currency between accounts, write a basic smart-contract (however, I could not figure out how to compile and deploy it) and write a web-app that made the most basic calls to the Blockchain (transfer, list accounts).

The problem with trying to use this platform is that it is (essentially) a brand new platform (the final release version only launched in mid-June) so there are very few resources available to learn how to develop my idea on it. In fact, there are no full end-to-end resources for the EOS platform (yet) and piecing together the very few resources that are available has proven to be extremely difficult. Further to this, there are also very few development tools available for this platform and the ones that are available are rather unrefined and very time-consuming and difficult to use.

If I had more time for the project I would look to persevere with this platform as I believe that it is superior, however, because my time is limited for the project I have decided to switch to the Ethereum platform and use that to develop my project. This should be adequate as it is only a proof-of-concept project which could later be ported over to EOS to make it faster.

Prototype Application Platform

Another thing I mentioned in my proposal was that I would like to develop a prototype application to interact with the blockchain using C# or C++. This would mean I would have ended up with a desktop application that performed the basic required functions.

After a lot of research (for both the EOS and Ethereum platforms) I have found that there are far more resources (and development tools) available for creating web-based applications in comparison to desktop applications, therefore, I have decided to create a web-based prototype instead. This will mean that I am working with some basic HTML, CSS, and JavaScript, which are all languages that I have some experience with, and, as I will be using the Ethereum platform I will also be using Solidity, which will be a new language for me and Web3js, which is also new to me.

Ethereum Learning

Test Blockchain Setup

As I plan to set up a multi-host multi-node Blockchain environment for this project I will need to learn how to set up the Blockchain and launch the nodes, for this I plan on using the Geth client and possibly multiple Ubuntu Virtual Machines in VMWare.

However, we all need to start somewhere and, as this is my first time using these tools, I opted to start with a basic 2-node setup on my Windows 10 Installation. This went relatively smoothly and I ended up with two nodes running on different ports on the same machine, as well as a “bootnode” which is essentially like a router for the main blockchain nodes (it helps them connect to each other).

Geth-Test-Network

This was all made super easy to understand thanks to this guide on Hackernoon.

Learning Solidity and Web3js

Once I had my test network running I decided to dive into learning the basic requirements for developing the web application. For this, I will be using a variety of tools that, so far, all come together really, really, well. These include:

  • Visual Studio Code (As an IDE)
  • NodeJs (as a CLI package manager)
  • Truffle Framework (an Ethereum specific development tool that makes some hard things super easy)
  • and more

In playing with these I have managed to create a couple of simple apps, one that is essentially a voting system (just to get me familiar with the tools, if you’re willing to sacrifice a couple of hours check out the tutorial video I followed) and I then took the knowledge I gained from that to adapt the basic HTML dApp in this tutorial series to a Truffle/JavaScript web-app.

instructor-tutorial

Neither of these tutorials relates directly to my project, however, they were a good starting point and I should be able to use this knowledge to create the invoicing section of the web-app, from there I will need to do some more learning for the General Ledger generation (including brushing up on the required accounting knowledge) and finally migrate it all over to the multi-host network (provided that my proposal is approved of course images).

In the meantime, I’ll keep looking for resources and get started on the invoicing system, which are my current goals for next week.

PRJ701 – 26/07/2018 – Project Proposal

Project Title

Blockchain: A framework for autonomous accounting

Preferred Choice of Supervisor

Sandra Dyke. The reason I would like to request Sandra as my supervisor is because she has a background in Business Accounting and, although I will be relying on my own knowledge of the subject, I believe she would be able to offer me the best guidance on the specifics surrounding the accounting side of my project. I am yet to discuss my project with Sandra.

Secondary Choice of Supervisor

Mark Caukill. Mark introduced me to Blockchain for the first time in his NET603 class and it is my understanding that Mark has also had some first-hand experience in working with Blockchain and I believe this experience would allow him to give me the most effective guidance if Sandra is unavailable. I have briefly mentioned my project to Mark but have not formally discussed it with him.

Fundamental Project Goal

This project aims to utilize Blockchain Technology and simulate a business to business transactional environment based on a shared distributed database and develop a prototype system or application to analyse the database and extract the required information to automatically generate a general ledger for each simulated business.

Statement of Major

I am majoring in Information Systems and this project will extend my Information Systems knowledge by giving me experience working with a new style of database that could potentially play an important role within many businesses in the future. Furthermore, the hands-on development of an Information System specifically for the business use case of accounting will further develop my skills in Systems Analysis and Design. Finally, this project presents an opportunity for me to leverage the other major skills I have been developing during my time at NMIT from the NET602, NET603 and SDV601 courses I have completed as electives.

Background

Since the beginning of my second year studying at NMIT I have been fascinated with Blockchain Technology and the possible applications of this technology within business and the future. I have researched this technology every chance I have had during my studies and I would love to develop a system with it first-hand. Therefore, I have chosen to focus this technology on business accounting to provide a cost saving technological solution to an essential age-old business process, I am focusing particularly on the Bookkeeping side of accounting to reduce the scope of the project and keep it a manageable size.

Double entry bookkeeping become the gold standard of basic accounting shortly after the publication of the book “Everything about Arithmetic, Geometry and Proportions” by Luca Pacioli in 1494. Now, over 500 years after the original publication, this method is still considered a “modern” accounting technique.

This method works exceptionally well, however, it has some limitations, this method can be costly and time consuming, in some cases this cost can outweigh the benefits, particularly for a small to medium business. Furthermore, this method requires that both parties keep their own separate records of the same transaction and finally, periodic third-party audits can be inaccurate and unreliable as falsified records can easily be concealed and in some cases the credibility of auditors could be questioned.

Blockchain offers a potential solution to these limitations by introducing the concept of “triple entry bookkeeping”. This concept is like the double entry method because each entry would still consist of a debit and a credit, however, the consensus mechanism of the Blockchain platform provides the third entry, a cryptographic signature which verifies the transaction. (Brandon, 2016)

With triple entry bookkeeping there would, technically, be three parties involved with any transaction. Just like traditional transactions there will be the payer and the payee, however, the Blockchain network could essentially act as a trusted third party, verifying that the transaction is trustworthy and authentic. The greatest advantage of this is that the mutually shared ledger “could, to a large extent, replace the auditor in confirming the accuracy of the [businesses] accounting” (Byström, 2016) and, rather than updating bookkeeping records periodically, updates would occur in real-time. This also means that both the payer and the payee would automatically have identical copies of the record which lowers the overhead of bookkeeping and could enable businesses of all sizes to receive the benefits of the triple entry system at little to no cost.

I have chosen to focus my project on the bookkeeping side of accounting, however, the project aims to prove the concept that, in the future, technology could entirely replace all forms of human accountants, from bookkeeping and auditing through to CPA’s, forensic accountants and general financial advisors.

Project Activities

The research for this project will be partially idealistic, based on a theorized scenario that assumes multiple businesses would utilise a shared platform to gain mutual benefits. I will be using a Design Research approach to create the artefacts and conduct an analysis of the end results.

This project will consist of the following activities:

  1. Preliminary Research and gathering resources
    • This will involve gathering information about which Blockchain development platforms are available, deciding on the best platform for the project and finally gathering the required resources to build the test environment.
  2. Build the Transactional Environment
    • In this activity I will set up a virtualized environment, creating virtual implementations of each “participant” as well as developing the underlying base of the Blockchain and implementing this into the virtual environment. This will require researching what information, other than the transaction, is required to be stored on the ledger.
  3. Populate the Transactional Environment
    • Once the environment is in place, I will begin to populate the ledger with transactional data that will simulate business to business transactions. This activity will be ongoing and will overlap other activities.
  4. Build and test a proof of concept application
    • For testing purposes, I will develop a basic prototype application. I will then test the application within the virtualized environment and record the outcome(s).

To finalize the project, I will:

  1. Evaluate the results/outcomes
  2. Draw conclusions and identify future directions/recommendations
  3. Complete the final report

Skills Required

  • Time management – Possibly the most important skill for any project with a limited time frame. I will need to work hard to ensure I stay on track for the project.
  • Problem Solving – This is a skill that is hard to gauge and difficult to teach, however, I believe it is something that I am naturally very good at and it will be essential while working with technologies, software and programming languages that will all be relatively new to me.
  • Research – This is another essential skill for gathering important information and aiding in problem solving.
  • Networking in a virtualized environment – I have been developing this skill in my networking electives and have the base knowledge required to develop a virtual test environment.
  • Software Development – I have some base knowledge in C# prior to beginning the project which I will need to develop further throughout this project.

Anticipated Outcomes

  • A Blockchain “framework” that supports the “triple entry bookkeeping” concept.
  • A proof of concept application that provides the basic and essential bookkeeping functionality.
  • A project report containing the outcome(s) of the project and recommendations for the future.
  • A project poster for the poster evening.

Required Resources

  • A Blockchain development platform – These are typically free to obtain and use under open source licensing. I am considering the EOS platform although this could be subject to change during the preliminary research.
  • VMWare Workstation Pro or alternative – Provided as part of an NMIT partnership program. My requirements will most likely be achievable with my personal computer.
  • Visual Paradigm and Visual Studio – Provided as part of an NMIT partnership program.

Possible Limitations and Issues

  • Limited Timeframe – This project must be completed over the course of a single semester, limiting the available time to complete this project. This may pose an issue given other commitments including other study, part-time work and family commitments.
  • Learning Curve – I will be working with many new concepts in this project. I believe that I am capable of handling the learning curve, however, some areas could be harder than first anticipated and could lead me to fall behind in my work.
  • Coding Block – An issue that any coder has potential to face, encountering unexpected problems that require excessive time to produce a solution.
  • Lack of development information/resources – As I will be working with some relatively new technologies, locating useful resources for guidance during development may be difficult.

Anticipated Timeline

Post-approval from the committee, I will aim to spend a minimum of 30 hours per week working on this project. The number of hours may increase or decrease, depending on my current state in the project.

Week Beginning Task Hours
1 23 July Finalize Proposal. Await Approval from IT Project committee. 5
2 30 July Begin preliminary research and gathering resources. 30
3 6 August Finalize choice of Blockchain development platform.

Begin Report Writing.

Begin development of Blockchain platform.

30
4 13 August Continue developing Blockchain platform. 30
5 20 August Continue developing Blockchain platform.

Construct virtualized environment framework.

SEMINAR SESSION 1 – AUG 23

30
6 27 August Finalize Blockchain platform and implement into virtualized environment.

Begin populating the ledger with test data.

30
7 3 September Begin constructing test application.

Continue populating the ledger with test data.

30
8 10 September Continue constructing test application.

Continue populating the ledger with test data.

30
9 17 September Continue constructing test application.

Continue populating the ledger with test data.

30
10 24 September Continue constructing test application.

Continue populating the ledger with test data.

30
Term Break Finalize test application, implement into virtual environment and test.

Continue populating the ledger with test data.

30
Final week of populating ledger with test data.

Final tests with test application and recording results.

30
11 15 October Prepare information for final report.

Report Writing/Poster Development.

30
12 22 October Report Writing/Poster Development.

SEMINAR SESSION 2 – OCT 25

35
13 29 October Report Writing/Poster Development.

JOURNAL DUE – NOV 2

35
14 5 November Report Writing/Poster Development

REPORT DUE – NOV 8

35
15 12 November Poster Development

POSTER EVENING – NOV 15

15
  Estimated Total Hours 485

Anticipated Ethical Issues

No ethical issues anticipated in this project.

Statement of Ownership

This project will be based on/created for software and/or development platforms with Open Source Licenses. All base platforms will remain the intellectual property of their respective creator(s) and subject to the terms under their Open Source License agreement. All original content produced for this project by Corben Ferris will be produced honoring the original Open Source License agreement and will remain Open Source under the GNU General Public License GPL-3.0.

References

Brandon, D. (2016). The BLOCKCHAIN: The Future of Business Information Systems? International Journal of the Academic Business World, 10(2), 39. From http://jwpress.com/IJABW/Issues/IJABW-Fall-2016.pdf#page=28

Byström, H. (2016, March 2). Blockchains, Real-Time Accounting and the Future of Credit Risk Modeling. From http://project.nek.lu.se/publications/workpap/papers/wp16_4.pdf