Part of an oracle’s worth is how well the security measures protect against attacks. These attacks come in many different shapes and sizes and can target everything from the smart contracts on the blockchain to the node operators themselves. An important factor of designing a reliable oracle is then to take this risk into account and design a system that is resilient and secure, and part of doing so is to maintain a comprehensive test-suite against all manner of attacks. This screenshot captures part of that test suite.
The “NFT” function portrayed for Charli3 is the digital identity of the nodes. The continual action at “failing” is showing our security measures preventing simulated attacks from altering oracle data on the blockchain along every step of the aggregation process. By actively considering attacks like these, simulating them, and ensuring that we have strong countermeasures in place we can be sure that a trusted consensus value can be produced and distributed to the consumer without disruption.
Each test lists the total time it took to perform the specific test, which can all be run in an automated manner for each update, or change, made to our codebase. Automation is important for security processes. By re-running every test each time we add a new feature, we can be sure that our changes don’t accidentally reintroduce a fixed bug or allow for attacks. The execution of this battery of tests took 55 seconds, less than a minute to ensure peace of mind for security measures.
Security considerations such as these are just part of what we have to manage to deliver a great oracle service and are a key aspect that is taken very seriously. Knowing that this aspect is properly managed lets us offer our services for consumers to use, secure in the knowledge that our oracle nodes will be safe from attacks as they provide quick, reliable data feeds.
