Runtime Verification enters a protocol verification agreement with PlatON blockchain
Runtime Verification is excited to announce a new engagement with PlatON Networks, a privacy-protecting new generation of public chain sponsored by the LatticeX Foundation (Singapore)
PlatON was forked from Ethereum, reborn with a brand new consensus algorithm and PlatON POS (proof of stake). The focus of this engagement is the formal modeling of PlatON’s Concurrent Byzantine Fault Tolerance…
Runtime verification of the component behaviours in the distributed system - The embedded approach
We’ve covered the basics of our runtime verification workflow in a previous post – now it’s time to see it in action. To keep things simple, the monitor will only check whether a message that arrived to the BeagleBone is always followed by a response. A simple statechart to achieve this can be represented as:
We start from a state of no previous messages. If a message arrives, the message broker raises signal one. This state has an entry action: if the state remains active after 500 time units have passed, it raises signal three. We decided to define a single time unit as one milisecond for the BeagleBone. This means that if a response isn’t sent after half a second, the statechart will enter an error state (for debugging and videos, we’ve used two seconds). If the response was sent, we return to the first state and the process starts over.
This monitor can be expressed in our Xtext language as depicted in the following code.
After the statechart is described, we need to map it to the corresponding C++ monitor – luckily, the latter can be done with a click in Eclipse. Transformation are developed with the help of Xtend. We are using low level monitors with minimalistic C++ code to fit in the memories of embedded systems. Generating such code is easier than writing it by hand, just take a look at this snippet:
Finally, we need to write small bits of glue code to connect the component to the system being monitored – mostly mapping the signals to their corresponding messages. We’ve put together a small system with the functionality of the above statechart, where we’re sending messages and controling the replies of the BeagleBone, which then enables certain pins’ outputs to light up leds. The first led is lit when we’re in the second state, where a message has already arrived but haven’t been answered yet. The second led signals reaching an error state. We’ve sent a message that was answered, and then a message which was not – as such, we reached an error state.
