Oyster Web Node PoW Demo

Taylor French
5 min readMar 19, 2018

--

In a previous post, we mentioned that we would be sharing a demo of the web node portion of the Testnet performing the Proof of Work necessary to push Oyster transactions to the Tangle. We are pleased to announce that a demo video of this procedure is available here. The remainder of this post details the inner workings of this demo video and gives a brief overview of the progress made regarding the web node infrastructure of the Oyster protocol.

However, before touching on this demo video, we have a small announcement regarding the scheduling of releasing updates. As many readers are aware, the Oyster team typically releases news every Friday. Whilst we would like this to be the norm we are more focused on the quality of the communication rather than the frequency. In the future, updates will still be frequent, but they will not necessarily be released on a Friday, or in strict, seven-day increments.

Demo Video In-Depth

In case some readers are not entirely familiar with the Oyster protocol’s architecture, the following paragraph provides a basic introduction to the broker node-web node interaction.

The web node script is what website owners implement on their sites to earn revenue via the Oyster protocol. When the web node script is present on a website, the browser of users visiting this website becomes an Oyster-enabled web node. These newly enabled web nodes do proof-of-work (PoW) for broker nodes and other web nodes for three types of items in return: additional broker node addresses, additional web node addresses, or genesis hashes. The PoW done for this item eventually leads to the web nodes earning PRL (directly or indirectly), which is sent to the website owner. A more detailed explanation of these interactions can be found starting at the tenth page of the Oyster Pearl (PRL) whitepaper.

In our demo video, the web node initiates a transaction with the broker node. The broker node then sends an array of items to the web node, and the web node chooses one item from this array, communicating its choice back to the broker node (for demo purposes, the web node selects the first item in the array). The broker node responds to the web node with a ‘PoW invoice’ containing a chunk of data to attach to the Tangle, a trunk and branch transaction to approve, and an array of hook node IP addresses to use for broadcasting. Because web nodes are not full IOTA nodes, they cannot broadcast the transaction themselves, and so an API method available on the hook nodes is used to broadcast the transactions instead.

A diagram showcasing the interaction between a web node (left side nearest the numbers) and a broker node (right side of diagram). During Step 1, the web node queries the broker node for a list of items. Then, in Step 2, the broker node returns a list of items for the web node to choose from (e.g., genesis hashes, web node addresses, broker node address). In Step 3, the web node has chosen an item from the list, and communicates its choice back to the broker node. Finally, in Step 4, the broker node sends the web node a PoW invoice that must be completed to receive the desired item.

Once the PoW invoice (work response) has been sent from the broker node, the web node calls the prepareTransfer method from the IOTA iota.lib.js library and assembles the following pieces into a tryte string:

  • an address
  • a message
  • a value of 0
  • a tag that can be any valid tryte value
  • a seed (required for the method used, but ignored)

Currently, only the address and the message matter for our purposes.

Once the tryte string has been prepared, PoW from the web node is performed via a PoW method available from the IOTA curl.lib.js library on the trytes, as well as the branch and trunk transaction initially sent over from the broker node. The curl.lib.js PoW method used allows the web node to perform the PoW without being a full IOTA node. The PoW performed calculates a nonce value and adds this value, as well as the trunk and branch transaction, into the tryte string.

With this modified tryte string, the transaction is ready to be attached to the Tangle. Using the hook node IP addresses that the broker node sent to the web node when it sent the PoW invoice, the web node iterates through these hook nodes, calling an API method that we have added to the hook nodes that broadcasts transactions done by other nodes. The trytes are sent to each of these hook nodes in the list, and subsequently, these hook nodes broadcast the trytes to the Tangle.

Future Improvements

The Oyster development team has done extraordinary work in completing the ‘A’ and ‘B’ sections of the Oyster Testnet. Listed below are a few improvements the development team plan to implement for the Oyster Mainnet.

The broker node’s backend will be rebuilt entirely using Golang. Once this change is completed, the broker node will be able to send real PoW invoices associated with ongoing file upload to web nodes. Currently, the broker nodes are sending dummy PoW for the web node to complete (the trunk and branch transactions associated with the dummy work are still authentic IOTA transactions, though).

Additionally, future iterations of the Oyster protocol will allow broker nodes to specify a “PoW magnitude,” meaning that for some items, the web node may have to do more than one PoW calculation. The web node will have the option to decline to do the PoW, but for now, web nodes just complete the PoW automatically.

Finally, subsequent iterations of the web node script will communicate to the broker node that the PoW has been completed, and the broker node will then confirm the transaction on the Tangle with the correct message and address. Currently, the broker node does not verify this, as Oyster owns all the nodes in the network.

Summary

The release of the web node PoW demo video showcases the constant improvements made to the Oyster protocol as well as the steady progress towards Oyster’s Mainnet release. If there are questions or comments regarding the web node PoW demo, or any other topic covered within this update, we encourage our community to post them in our reddit or our Telegram knowledge channel.

Author’s note: I would like to extend my gratitude to the Oyster development team for supplying technical clarification for many of the topics covered in this update.

--

--