Ethorse project update — February 5, 2018
Since the last update from two weeks ago, we at Ethorse have been very focused and working hard on the design and the development of the product. There is a lot of expectation and hype for the Mainnet release of the dApp. We want to live up to that and ensure Ethorse is set for a successful takeoff. User fund security and usability has been our top priority. We want to create a great impression for everyone who is going to use it. Below are the items we have been working on.
We introduced a betting controller contract on top of the race contract which controls all the actions that are performed from spawning the race to setting up the race on time. We automated the recovery of unclaimed winnings (ether) from the races that are older than 30 days. This completes the entire flow of the betting contract. With this, we have made the race as well as the manning — entirely automated, secure and trustless.
Optimizing the contract has always been one of our top priorities. This time we have a significant update in this section. Every single variable and literal were skimmed through to make it as gas efficient as possible thereby making the race contract much more lightweight (about 20% more efficient). Loose variables are packed into a structure. We have also made a few changes to the logical statements which are optimal and covers as many corner cases as possible.
Bridge for Smart contract — frontend
Ethorse-bridge is a new implementation that is going to be very helpful to reflect all the actions from the blockchain (race contract and controller) on the frontend. The frontend which runs on ReactJs cannot listen to events emitted from the blockchain all the time. Ethorse-bridge, a middleware built using NodeJs, ExpressJs and web3 listens to the race spawning events and serves the data to the frontend. This ensures that every time a user visits the dApp, they will have the list of latest races to bet on. All without any manual intervention.
Improved Race Navigation
The introduction of middleware also made it possible to easily get and store information from blockchain to be reused later. This enables users to seamlessly navigate and switch between races to view the results and claim winnings from the past races. For this details such as contract address of the race spawned, race spawn time, and race duration are served through an API to the frontend. The data and the parameters are used to categorize the races and display them as a collapsible tree on the sidebar.
Ethorse dApp is undergoing a major facelift in terms of UI. An intuitive interface is being built using all the feedback we have collected so far. We have added a new member to the team to help with UI/UX improvements. Below is a screenshot of what the new design looks like. It is being implemented with HTML, CSS and ReactJS. The skeletal design has been reworked from the ground up. In the race table, a new field will be introduced for users to see the coin that is winning (or won for past races) with its % price gain. The existing material theme, colors and element styles have been changed to custom styling and adaptation of semantic-ui for several components.
UI updates — Continue to implement the new UI design
Testnet hurdles — As you may have noticed, we did not have a race running on Ropsten testnet for the last few days. This is because of the Oraclize.it services being down for the Ropsten Testnet. Many developers have reported this issue. Their services have been consistent for the Mainnet and they are fully supporting it. Just to assure everyone, in case we have any such issues in Mainnet, our refund mechanism will kick in automatically to enable refund to the bettors. However, in order to test the dApp, we need a fully working Testnet version. We are currently looking at different Ethereum testnet where Oraclize is more consistent. Rinkeby is a stable network, but since the RPC does not expose internal transactions, it won’t help us with debugging. We are working on using Kovan Testnet, which looks like a possible solution so far.
Release — We are trying to work with a few code auditing companies and private auditors to review our code. The testnet related issues mentioned above are causing some delays with testing and auditing. After it is done, we will be releasing the dApp in a Testnet for users to play with it for a few days before the Mainnet release. We will be having a public developer bug bounty as well. The team is continuing to work hard to release the dApp on the Mainnet by the end of February. We are still positive about the mainnet release in February. We appreciate your patience and support.