Oyster Web Node Demo

Today’s update will cover the work completed between July 29th — August 3rd, 2018.

Oyster has a very exciting development to share with the community. The Oyster development has finished an example of how the background processes of the web node script will work when it’s used on browsers.

For those unfamiliar with the purpose of web nodes in the Oyster infrastructure, web nodes ultimately try to get some genesis hashes so that the web nodes can treasure hunt. There are other things the web nodes want as well to aid in their treasure hunting quest, such as broker node addresses (Think of broker nodes as more people that it can ask for treasure maps).

The web node demo can be found here: https://demo.oysternodes.com/

Here is how the web node demo works:

The web node attempts to buy a broker node address from a broker node whose address it already has. The broker node selling the address will give the web node some Proof-of-work (PoW) to do as the “price” of getting the address.

The web node completes the PoW and notifies the broker node whom it is transacting with. That broker node checks the tangle to verify the work was completed, then sends the web node the broker node address if all is well.

The web node now has a new broker node address. It tries to buy a genesis hash from this broker node. The broker node again charges the web node to do some PoW to get it.

The Webnode completes the PoW, notifies the broker (who verifies the work) then gives the web node the genesis hash.

Now the web node can hunt for treasure. It has the genesis hash and the number of chunks and is thus able to build the data map (aka all the tangle addresses where the transactions for the file are located).

The web node builds the data map, queries the tangle for each transaction, and does PoW to reattach all of them. While it’s doing this PoW it is checking if any of the messages contain treasure, by trying to decrypt the messages.

When the web node finishes, it should have found a treasure and completed reattachment of that file. It sends a “claim treasure” request to the broker, who would initiate transactions on the ETH blockchain to claim the PRL if the demo was doing this with a real ETH key (the demo is just using a dummy key, so the broker just responds with “success”).

The Oyster team is very excited to share this demo with the community, and we are looking forward to receiving feedback and comments regarding this demo.

General Development Work for the Week

This week, the team has continued work on database improvements to support the increase in file size on Oyster Storage. The team continued work on removing the data_maps table entirely out of MySQL. All data_maps data will instead be stored in Badger, a Key:Value database written in Golang. The team has also been working on backend changes necessary for the brokers that will be used for the web node demo. To support many people visiting the page as well as seeing the web node do its treasure hunting, the broker node needs to re-use genesis hashes and PoW assignments that it has already given the web node. Furthermore, the team focused on query optimization for purging complete data maps, as well as debugged production issues.

The development team also continued work on the web interface codebase’s migration to TypeScript by documenting Oyster’s architecture and brainstorming further improvements. Additionally, the team has been working on experimenting with different solutions to address the scalability bottlenecks of file uploads. For example, the team has been working on offloading some work to AWS Lambda to increase the throughput of uploads of file chunks.

As always, we encourage our community to post any questions or comments regarding these development updates to our Reddit or Telegram channel.