Anthony Eufemio, CTO of Digix Global, the smart asset company tokenizing gold on Ethereum, today provided the newest development update in regards to the highly anticipated marketplace platform launch. Of chief importance right now, the CTO mentioned the upcoming third security audit and the refactoring work needed to get the codebase ready for it.
During the first two audits, Digix wanted the audits to focus on the consumer-facing portions of its code, which includes the following:
- DGX Gold Token Contract (ERC-20 token)
- Token transfers
- Token “transfer from” and approvals
- Recasting tokens for a specific gold bar from the minter pool.
- Gold asset explorer
Additionally, the CTO wanted to get some feedback regarding the modular contact patterns (made possible through Digix CACP/ICS contracts).
Splitting contract code into different contracts based on their function which may fall in one of the following categories, which allows for the following:
- Storage: these are contracts that act as our persistence layer where data can be written to the contract in one transaction and can be read by other transactions or calls at a later date.
- Controller: these are contracts that contain the logic behind the code and can read from and write to the storage contracts through CACP enforced access controlled writer functions.
- Interactive: these are contracts that have functions that can be directly called by other external contracts as well as through web3/JSONRPC sendTransaction and calls.
- Service: these are contracts that provide some commonly used functions such as doing demurrage rate calculations, signature verification, and others.
- Libraries: solidity libraries that provide common low-level functionality that can be used anywhere in the ICS stack.
- Function level access control (groups based, account based, mutex based, or state based)
- Contract address forward and reverse lookups which will allow Digix to determine which external contract is invoking the given contract’s function allow the contract to allow or reject the call based on the access control.
- Allows deploying complex code that would normally not be possible due to Ethereum’s per-block gas limit.
- Allows upgrading certain components to fix bugs and add functionality in the future.
CTO of Digix Anthony Eufemio said:
“These are all great things that CACP/ICS provides our contract development efforts but the biggest caveat is that this design makes it difficult to properly write unit tests. All of the issues that were brought up during our first and second audits have since been resolved except for the most glaring one which is the lack of unit testing. The reason for this is that writing unit tests in CACP/ICS is not a trivial exercise…”
A simple test of a controller contract would require the following steps:
- Deploy a new ContractResolver instance
- Deploy the underlying storage contract that the controller contract uses.
- Deploy controller contract.
- Configure ContractResolver to use the main tester account as the address for the calling interface contract.
- Check assertions
- The amount of test boilerplate code that is needed to write just to test a single function would make the test related code base larger than the actual code base itself if they are to aspire for near 100% test coverage.
This week Digix is working towards finding a middle ground solution to its testing woes which involves some of the following:
- Identifying portions of the code that can be DRYed up further.
- Expanding the functionality/scope of storage contracts to handle low-level state rules (i.e. StateMachine library) which can be easily tested.
- Writing generic tests for interface contracts and storage contracts that satisfy what’s needed to have full coverage.
- Focusing on refactoring controller contracts which is where we need 100% coverage.
The goal is to have a golden code base with 100% coverage of mission-critical portions of the Digix code base and 100% sanity check coverage for non-critical portions of the code.
Marketplace Platform
More updates provided from Chris Hitchcott, Digix Core Developer announced the progress this week of a newly skinned marketplace to make it more closely match with Digix branding (screenshots seen above). The skin includes components to improve UX, integrating the Digix semantic UI theme, adding visuals to the landing page (a big slideshow banner with login overlay), adding the Terms & Conditions, styling charts, the various other UI tweaks.
Developers also progressed with backend updates to the routing system to deal with redirects, and wiring up various hard-coded URLs to prepare the app for different staging environments.
Additionally, the development team has prepared a short survey to help them determine the prominence of copy on the marketplace landing page, based on feedback from potential DGX holders.
Hitchcott finished the update by saying:
“Pending the updated contract API…the final step for publishing a live marketplace (for user testing of purchasing DGX) is to integrate the new contracts and deploy this updated app — plus maybe one or two additional minor iterations of UI tweaking here and there, and recording a walk-through video. This week I am wrapping up by working on the PoA system, pending the updated contract API.”