How we validate code
Over the last few weeks we’ve codified and tested a more formal process for validating smart contract code. Writing blockchain code is a high-risk task for two reasons:
First, the code cannot change once it has been deployed (although, we do have a versioning system in place to allow iteration within our products).
Second, the logic etched in to the blockchain is fundamentally financial software, potentially responsible for millions of dollars of losses if something goes wrong.
Given that, it is no surprise that one of our core values is producing secure and reliable codebases. We use many tools — some software, some process and some cultural — to ensure we release well-tested and validated code.
Here is a selection of some of the tools we use:
- Static analysis and formal validation to verify quality and detect high-risk areas early.
- Aesthetic preferences and cultural rules to reduce communication barriers (i.e., linting and formatting)
- Rigorous testing systems — automated checks represent more than 90% of the total codebase on smart contract development.
- Assertions and invariants, to catch unexpected state.
- Staging environments and automatic validation procedures (CI/CD) to catch errors early.
These tools provide confidence in our smart contract code and to catch errors before they have a chance to negatively impact any users.
However, the most important tool in our arsenal (by a landslide) is our internal audit and review process.
Every line of code, but especially every line of smart contract code, is tested and reviewed by multiple developers before it goes to production. With the highly sensitive smart contract code, this process has been tough to define “finished.”
At times, internal review would sit having had multiple reviews without certainty that this was “done”. To resolve this deadlock problem, we assembled a “last step” process checklist. The new process is automatically required when any immutable blockchain code changes.
This ensures the code has been validated across dimensions such as:
- logic
- typing, mathematics and implementation
- event logging correctness, completion
- permissions correctness, completion
- automated testing procedure and coverage
- common errors, known issues and gotchas
Upon completion, there are just two outcomes: the iconic “looks good to me” sign-off or (when sensitive or risky functionality is detected) a trigger for escalation — either directly to the executive team or formal validation from external eyes.
This tool will continue to iterate as we discover new gotchas or need to add other systems to the pipeline. Testing this week, however, showed that the formal process provides repeatability and confidence in the review process.
Dev Notes
A few quick notes about what went on behind the scenes this week.
🎁 Rewards
+ redeem process is complete
+ integrating latest set of smart contract changes
+ testing and auditing contract changes to use less gas and a much smoother UX (no wait required)
+ integrated config service for mulit-target builds💳 Pay
+ reset gas to recommended after form submission
+ major UX improvements for paying with tokens
+ started implementing redesign
+ checksum validation improvements
+ always render checksummed addresses where possible🎁💳 Both
+ cleaned up form error labels
+ fixed logo sizing issue on some browsers
+ new feature: transaction status bars in header
+ switching over to yarn to prevent lockfile issues
+ improvements to smart contract audit process
That’s it for this week! If you have any questions, be sure to join our Discord channel, tweet to us on Twitter or chime in on the /r/BlockCAT subreddit!
