Digix Dev Update — 17th July 2017 – Digix – Medium
The INBlockchain conference saw other founders from Sia Coin, ZCash, GXS, EOS, 8btc.com, OmiseGo, imToken and other notable Chinese projects sharing about their project and plans.Li Xiaolai
I’m traveling to Beijing over the next two days to discuss and meet with consulting and research groups to discuss in greater depth the outreach of Digix in China for our upcoming relaunch of DGX.
Anthony Eufemio (CTO)
Last week I completed work on the KYC microservice and have handed the API over to Chris for the front-end work. I’ve also finished work on our trusted price feed system which allows us to feed real world prices into the DigixCore Marketplace contracts for ETH to DGX token purchases.
This week I will be creating the Solidity contracts for the DigixCore Marketplace which uses the trusted price feeds as well as fixing some minor bugs that were discovered during the first week of round 2 of the security audits for our DigixCore 2.0 contracts.
Chris Hitchcott (Core Dev)
Last week, I re-implemented the user interface for the KYC system (as the backend has an updated API), which included adding proper routing for spectrum via react-router-4 and creating some useful additional components (like a menu system and generalised image-upload-and-resize). I also added `hdPath` support for sigmate, updated/optimized webpack config for spectrum and spent some time figuring out why we couldn’t replicate the results of some tests in different environments and added tests to cover this in future — FYI, troubleshooting revealed that testrpc 4.0 doesn’t use `sign` in the standard way and thus creates a malformed hash.
This new KYC UI is now implemented as a dapplet and is thus integrated with Spectrum, which is proving to be a powerful combination even for contractless apps. You can take any react(-redux) application (in this case, ruby-authenticated app) and easily inject all of Spectrum’s features (including signing transactions, reading from Ethereum blockchains, becoming a Progressive Web App).
One example of how this is powerful: when submitting documents to the KYC service, you’ll be asked to perform a “Proof of Webcam” step, which will require you to write down a verification code on a piece of paper, showing it along with your face and ID to a webcam. The webcam stuff isn’t new (see the UI demo from last year), but now that we’re inside the Spectrum environment, what more secure way of generating a verification code than to use Ethereum? Users write down the latest block number as well as a truncated hash of the latest block to make it difficult to fake a webcam submission, just like vitalik did. Spectrum made this easy as we already have a web3 connection and can connect it to any component with a one-liner; `export default web3Connect(Component)`.
That was easy…
Then just render `verification_code` for the user; a yet-to-be-tarted-up view of the webcam verification step.
The other side to this is the admin (back office) approval process for KYC submissions; similarly, we grab the block data within Spectrum (via web3-redux) and automatically cross-check the submitted code to ensure it matches with the real block hash. Admins, just like users, are authenticated with a ruby backend which they use to approve users and update the KYC database. Within the same UI they can send a transaction to Ethereum to whitelist KYC addresses (using the Spectrum accounts system; even via a hardware wallet). Way more secure than a centralized server, and pretty much just as convenient. I reckon hybrid “centralized-decentralized” apps (“happs”?) like this will be commonplace in the Ethereum ecosystem for integrating parts of a system with private servers (such as the private KYC user data, in our case). And we haven’t gotten started with authentication via ECrecover ;)
This week I will be completing the admin (verification approval) side of the KYC process and “tarting up” this dapplet ready for beta testing next week.