Oyster Development Update
Today’s development update focuses on the work completed for the week of June 24th to the 29th.
This week the development team has continued to work on the jobs that use Oyster’s eth_gateway and interact with the Ethereum blockchain. The team finished QAing the claim_unused_prls task from the previous week and are now working on a new task called claim_treasure_for_webnodes. With this task, instead of immediately invoking ClaimPRL() when a Webnode has done the PoW and claimed a treasure, the team will add the claim to a table in the database and have a task run which will call methods needed to claim the PRL for the website owner. This way, if the first attempt to claim the PRL does not succeed, the broker node can keep trying until the PRL are successfully claimed. Also, for various bury/claim operations, the team has to send a small amount of gas to the affected addresses. Over time this could add up to a lot of wasted ETH if the bury/claim calls don’t use all the ETH that was sent. Thus, the team has added a method to retrieve leftover gas if there is enough left to justify making a new ETH transaction to get the leftovers, making the system more economical.
In addition, the team has continued to work on integrating a streamable module for the front-end to handle larger uploads. Additionally, the team has been working to establish engineering practices with the goal of increasing the development velocity and code stability. Furthermore, the team has continued work on the Badger DB integration and fixed several related unit tests that were failing, as well as worked on Code Climate refactoring and unit testing the changes for the next broker node release. Also, the team worked on automating the deployment of the broker nodes in a staging environment
Further work has been completed on the python reference implementation of the ‘rev2’ update to the Oyster Protocol. The team focused on bringing every feature to a functional state (right now metadata works fine for any arbitrary number of files, along with data map generation, password protection, etc.) and documented every function and method using the same standard currently in place for the Oyster development team to improve readability.
The development team has been focusing on optimizing developer activities to increase efficiency and code quality. The team added automated code quality checks on Oyster’s central repositories, so developers have visibility/impact of their pull request on the code base. They also documented how to work with Travis CI locally to simplify debugging of build scripts and created and documented a TypeScript migration plan so the team can start adding types to our code. The team will continue working through the weekend to start boosting the team’s E2E tests. Finally, the team has been working on upgrading to Webpack 4.
Bibox Community Vote
For those community members not yet aware, PRL has been included in the Bibox exchange’s community vote. The top three projects will be listed, and there is currently a 400K PRL voting reward in place if PRL finishes in the top three. Votes are submitted using the Bibox Token (BIX). The reward will be distributed based on the total number of votes, as well as the individual votes per user (i.e., 400k/total votes * a user’s votes).
We ask our community to note that any BIX token used for voting will only be refunded if the project for which a user has voted for does not place in the top three, and subsequently does not win the community vote.
https://medium.com/oysterprotocol/june-29th-development-update-e3f27058f839
