Frankenstein’s Monster

So after some deliberation during our team meeting this week we came to a couple key decisions, namely about technology and architecture. We have decided to implement the server RESTful API as an in-between for the mobile application and the blockchain. We also decided with certainty that we will be using Flutter for the mobile application, Node.js for the server-side, and Hyperledger Sawtooth for the blockchain. Nobody else on the team has experience making a RESTful API, and I have taken a CS 493, where we deployed such a server using Node.js on the gcloud platform. So there will be an interesting dynamic early on in our project, namely creating Frankenstein’s monster. 

The current plan, from my understanding, is to take the code I have for a server API and bastardize it as we see fit to fit our needs. From there, I will be making the mobile application from scratch using Flutter libraries for anything too complicated, like the integration of QR-code reading and generation. This shouldn’t take too much effort, but it will probably be fairly unwieldy and unorganized to start, which I guess is somewhat natural. The server side will undoubtedly be extremely awkward for the first portion of the winter term, especially considering that the other group members will likely be working on that portion. The blockchain section will basically not be touched by me, which I’m fine with because I would rather focus on expanding the skills I already have. But this leaves the majority of the project in this really funny state of being put together out of bastardized code that I have written for other classes, just trying to get it to all fit together. While I’m sure there will be more to it than that, its still interesting to think about how all of my classes have come together to this point and how useful the skills I have picked up along the way are. 

Architecture Discussion

So, in my mind, one of the primary flaws, or rather a lack of consideration up until this point, is how exactly our application is going to talk to the blockchain backend. Throughout this process I had always pictured the application talking directly to the blockchain. I guess I had been considering the blockchains use as a simple database. However, this isn’t correct in either form or function. While it is true that the blockchain will hold the data and is a database in that sense, accessing the data is significantly more obtuse than accessing elements of a simple database. 

So I took this thought and looked at the Hyperledger Sawtooth API. The API shows that you can setup the blockchain implementations as a RESTful API server. This is near perfect for our group, but the issue remains that the specific calls you can make to the API are limited, and we will be unable to change those calls to more application specific ones. This would leave the bulk of the data accessing and storing in the hands of the application, and that’s a lot of heavy lifting for a mobile application, at least in my mind. So I think the secondary approach is what our team should consider.

Basically I would create a RESTful API webserver that would handle all calls from the application to access the data in the blockchain. This would keep a solid separation of responsibilities in my mind: the application as the the front end, the server as the controller and backend, and the blockchain as the database. In addition to the solid seperation, this would allow for ease of access for future development. If our project partner wished to later access the blockchain with a website or some other application, this RESTful API server would make the interactions a lot simpler and would still work just as well for our application. The only concern that our project partner brought up is the extra security risk, but we’ll discuss that another time.

A Deeper Look

This week I took the time to sit down and really take a hard look at Hyperledger Sawtooth, the blockchain technology our group will be using for the project. Hyperledger is the open source blockchain technology that is hosted by the Linux Foundation. Basically, Hyperledger is trying to create stable frameworks and tools so that the blockchain technology is accessible to businesses for any number of use-cases. Our group chose the Sawtooth at the request of our project partner.

Hyperledger Sawtooth is a blockchain system that was designed to be used by enterprises for creating and operating distributed ledger applications and networks. Sawtooth stands out from other Hyperledger systems because it allows for permissionless networks as well as permissioned ones. This allows for networks to be used for both private and public affairs. For our project, this works out well because we do not need to hide any information, so we would want to setup a permissionless network. This will allow anyone to hop on and view the data as they see fit. One of the key goals of our project from the start has been transparency of transactions, and a permissionless network allows us to do just that.

Sawtooth is currently one of the less represented technologies underneath the Hyperledger umbrella. One company that is using it similarly to our goal is Scan Trust. Scan Trust utilizes copy-proof QR codes to give different company supply chains traceability and transparency. They used Sawtooth to allow users to trace things using the blockchain technology so that there is a guarantee of no tampering and complete clarity of transactions. So after implementing the changes and using Sawtooth, users now log all data on the blockchain and the data is then accessible through the QR codes on each product. This is a near exact implementation that our group is looking for.

Narrowing Scope

After last weeks meeting and having done the project requirements documentation, there was a distinct issue with the application that I was beginning to see. To me, the scope of the project was not specific enough. We were trying to tackle and application that was explicitly for tracking expensive wines with incredible detail and accuracy. At the same time we wanted an application that could be widely used by wineries to provide the majority of their customers with general wine information. These two project end-goals were at direct odds with each other in my thinking. So I went to our project partner and expressed this dilema.

The project partner was clear: general and wide use is more important than specificity that helps only a small group. So we restructured the project requirements based on this feedback and I think we finally nailed the project on the head. Overall, wineries will be able to add wines that they have created and generate individual QR-codes for each bottle. There will be some general fraud detection based on some location data that is given whenever a QR-code is scanned by a phone, but the fraud detection takes a backseat to the general use case of “a consumer scans a QR-code and gets the information on the wine”.

There was some minor disagreement among the team; nothing to be concerned about, but some clarification was still in order. The general consensus that the team came to was if a user had location data enabled, they would be able to mark that they had bought the wine bottle, if they input their own information. The application would then check to see if the wine bottle was being “purchased” at the same location as the last time it had been purchased. If this was the case, the new data would overwrite the old data, and that data would never be officially added to the bottle’s history. This allows for people who truly care about the wine bottle’s transaction history to continue to keep track, while also being user friendly enough for the general customers.

Partner Meeting and Clarification

This week was our first “face-to-face” encounter with our project partner, Jim. He seems extremely motivated and enthusiastic, which is fantastic. Jim is a big proponent of blockchain technology and thinks it’s going to be utilized across many different industries, and I agree. Jim has found a niche market that can use this technology and really show it off. Thankfully we got a lot of clarification out of the way with our first meeting, and our fourth member has been confirmed to be alive and well.

Jim’s project is actually fairly straightforward and simple: create an application that can scan QR-codes on wine bottles, reach into the blockchain for data pertaining to the bottle, and display it to the user. Wineries would upload the data they want displayed. Consumers could get more information about the product they want to buy. It’s simple and usable.

The real fun comes in with making each bottle an individual QR-code. This allows the calls to the blockchain to also collect data from the application while it is in use. The most useful application being location tracking the scan and comparing it to any scan made on the same bottle within a set amount of time. If the bottle was scanned in multiple states within an hour, then the wine would be deemed fraudulent and any consumer that scanned that QR-code in the future would be warned.

Furthermore, with tracking where and when these scans are taking place, then it would be a simple matter to compile this data and provide it back to the wineries so they can judge where their product is selling best. More information with the wine makers will help to support their business, and the information provided to the consumer has the opportunity to allow for direct-to-consumer interactions from the wineries. While the product seems simple, it could have some profound and lasting effects on the industry. With being able to track potential fraud, as well as helping cultivate the relationship between creator and consumer, I cannot wait to see how this project shapes up.

Team Meeting and Initial Contact

So this week was the first we met our teams and sent out the initial email to our partner. Two of my teammates were on top of the ball so the three of us were able to hammer out some details and decided to move forward with project management via Trello and team communication via Discord. We all seem to get along together well and I’m excited to work with each of them. Unfortunately, we have yet to make contact with our fourth group member, and it is now the Sunday of week 2. Hopefully this member can seek out contact soon so that we can get them involved with the group work that needs to be done in the coming week.

An email was also sent to the partner who proposed this project. We asked some basic questions and have already heard back from him. There is a meeting setup for early next week so we can really get down to some brass-tacks and hammer out details of what exactly they are looking for. He suggested we watch the movie “Sour Grapes” to understand the issue in the wine industry. Basically, between 2003 and 2006, a man managed to defraud the wine industry for millions of dollars by making fake bottles of expensive wines with printed labels and concocting fake wines by mixing cheaper wines together.

Our project partner wants to attack this problem by creating a technology that allows end-users to scan a QR-code and see all of the information about an individual bottle of wine, including the entire shipping chain so that you know exactly who had possession of the wine between the winery and the store you are buying it at. I think there will need to be more involved within the app, for example a feature where a person can propose to buy the wine from the winery or provider and then scan a QR-code from the current owner of the wine so the transaction is logged in the blockchain that keeps all the information secure and up-to-date.

Overall, I am extremely excited to be working on this project and am really happy with my group. It’s going to be an exciting year.

My Journey So Far

Hi, I’m George Mistkawi and I am currently nearing graduation in OSU’s Computer Science program. To put myself through school I work as a sushi chef, and have been working in the kitchen industry for 8 years now. If you ordered sushi at Portland City Grill on the weekend anytime between 2015 and 2018, I was probably the guy making it. I was in charge of the sushi station at PCG for 3 years, and then moved on to Bamboo Sushi SW and later to Bamboo Sushi Lake Oswego. Cooking is a deep passion of mine, but I want more regular hours and better pay, so hopefully once I finish this year out I can move on to a more stable career in software development.

My school career has taken a lot longer because of balancing course work with full-time work, but this will be my last year. I transferred to OSU from Portland Community College where I took several elective courses to learn the .NET framework and C#. This knowledge helped me get an internship working for ODOT through an OSU program, where I further polished my .NET framework skills. At this point I’m a little rusty, but the .NET framework was probably my favorite to work with. I really like to work with the back-end because I don’t really have an eye for design.

I’m really hoping to get some solid practice in this year for the professional environment, and I can’t wait to get started on the capstone project. Here’s hoping this school year turns out excellent.